Inventory & Compliance Manager – UX Specification

Related Technical Authority: Inventory & Compliance Manager – Technical Specification v2.0

1. Purpose

This UX specification governs the user experience of the Inventory & Compliance Manager module, which provides clinical practices with a governed, end-to-end interface for managing stock, procurement, and regulatory compliance. It covers the surfaces and interactions through which Inventory Managers, Compliance Managers, Clinical Staff, and Practice Managers maintain inspection readiness, prevent stockouts and expiry waste, and complete mandatory compliance tasks. The spec exists to ensure that every UX decision is grounded in the module's non-negotiable governance rules and that the interface supports — without replacing — human accountability.

2. Core UX Principles (Non-Negotiable)

These principles take precedence over visual preferences. If a design choice conflicts with a principle below, the principle wins.

• Action-first — users see the action they need next, not abstract status displays.
• Governance always visible — when AI is involved, users always know what AI did and what they're confirming.
• No dead toggles — every UI control either does something or doesn't appear.
• Calm by default — the interface gets out of the way; alerts are reserved for things that genuinely need attention.
• Progressive disclosure — advanced detail is one click away, not always-on.
• Accountability always attributable — because the technical spec requires every action to be attributable to a named user (§9), the UI must make the acting user's identity unambiguous before any governed action (approval, stock deduction, CD register entry) is confirmed. This principle is inferred from technical spec §9.
• Immutability made legible — Controlled Drug Register entries are immutable once saved (technical spec §12.8). The UI must clearly communicate this before and after saving, so that users understand they cannot edit an entry and must create a correction record instead. This principle is inferred from technical spec §§12.3 and 12.8.
• Compliance task silence is never acceptable — the technical spec states compliance tasks cannot be silently missed (§9). The UI must surface overdue and escalated tasks in a way that cannot be dismissed without acknowledgement. This principle is inferred from technical spec §9.

3. Design Philosophy

The mental model the module embodies is that of a governed operations ledger — every action has an owner, a timestamp, and a consequence. The design should reinforce this by making the flow of governed objects (stock → requisition → order → delivery → ledger update) feel continuous and traceable, not fragmented across screens. This is inferred from the end-to-end lifecycle described in technical spec §4.

Empty states should be instructive: a new practice with no inventory items, no suppliers, and no compliance tasks configured should see onboarding prompts rather than blank tables. Empty states in the Controlled Drug Register must not appear ambiguous — zero entries is meaningfully different from "not yet set up." Inferred from technical spec §§3, 12.

Error states must always offer a next action. A failed goods-received submission, a balance discrepancy alert, or a failed PO approval must never leave the user with only a dismissible error message — there must be a clear path to resolution or escalation. Inferred from technical spec §§4, 12.6, 12.8.

AI suggestions are not described in the technical spec. The system-initiated behaviours described (automatic low-stock alerts, SLA reminders, expiry and recall alerts — §5.2) are rule-based, not AI-generated. These should be visually treated as system alerts, not AI suggestions, and should not carry an AI badge unless a future AI capability is added. Inferred from technical spec §5.2.

Multi-step flows (e.g. goods receipt, CD administration logging, purchase requisition approval) must use a step-indicator pattern so that users know how far through a governed workflow they are before they are committed. Inferred from technical spec §§4, 12.4.

Undo/redo is not available for governed or immutable actions (CD register entries, approved POs, completed compliance tasks). For actions that are reversible (draft requisitions, usage log corrections within a permitted window), standard undo patterns may apply. The distinction must be made explicit in the UI. Inferred from technical spec §§12.3 and 12.8.

Read-only vs editable surfaces must be visually unambiguous. The Controlled Drug Register and completed compliance task evidence are inspection artefacts and must render in a read-only, document-like style that signals permanence. Editable forms must use standard input affordances. Inferred from technical spec §§8, 12.3.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Inventory Manager / Purchasing Lead, Compliance Manager, Practice Manager. This is inferred from the RBAC roles described in technical spec §7.

Key tasks performed here:

• Reviewing and acting on the Inventory Dashboard: stock levels by location, low-stock alerts, expiry alerts, and items linked to upcoming appointments. Inferred from technical spec §6.1.
• Managing the procurement and orders workflow: creating and submitting purchase requisitions, reviewing the approval queue, comparing supplier prices, tracking delivery and back-order status. Inferred from technical spec §6.2.
• Configuring and overseeing the compliance schedule: assigning compliance tasks, reviewing checklist status (green / amber / red), viewing upcoming and overdue tasks, accessing evidence attachments and audit trail. Inferred from technical spec §6.3.
• Managing supplier records: adding and editing approved suppliers, reviewing pricing and contract terms, assessing group-buy eligibility. Inferred from technical spec §3.2.
• Managing inventory item records: creating and editing items, setting reorder thresholds, assigning approved suppliers, managing batch numbers and expiry dates. Inferred from technical spec §3.1.
• Accessing and exporting the Controlled Drug Register and inspection-ready reports (when the Medication & Controlled Drugs extension is enabled). Inferred from technical spec §12.7.
• Reviewing and acknowledging balance discrepancies and missed CD register entry alerts. Inferred from technical spec §§12.6, 12.8.

Layout pattern: the Inventory Dashboard and Compliance Dashboard use a dashboard layout with summary cards and alert lanes. The Procurement & Orders view uses a list-detail pattern. Inventory item and supplier management use a list-detail pattern with inline or modal forms. The Controlled Drug Register uses a chronological, read-only list with a separate governed entry form. Inferred from technical spec §§6.1, 6.2, 6.3, 12.3.

4.2 Tablet App

Who uses it: Clinical Staff and Compliance Managers operating in the practice — logging usage at point of care, completing assigned compliance tasks, and recording CD administration or disposal at the point of action. Inferred from technical spec §§5.1, 7, 12.4.

Key tasks performed here:

• Logging stock usage and deducting quantities from a specific location. Inferred from technical spec §5.1.
• Completing assigned compliance tasks and recording evidence (photos, signatures, or confirmations). Inferred from technical spec §§3.5, 5.1.
• Recording controlled drug receipt, administration, and disposal events in the CD Register at point of action, including witness confirmation where required. Inferred from technical spec §§12.4, 12.8.
• Viewing current stock levels and low-stock alerts for their assigned location. Inferred from technical spec §6.1.
• Submitting a purchase requisition when stock is identified as low. Inferred from technical spec §§3.3, 5.1.

Touch ergonomics: glove-friendly tap targets of at minimum 48 px are required given the clinical setting. Form inputs for CD register entries must be large enough to operate with clinical gloves or while holding documentation. Step-indicator patterns for multi-step governed flows must be thumb-reachable in the lower half of the screen. Inferred from the clinical operational context described in technical spec §§5.1, 12.4 and standard tablet UX practice.

4.3 Mobile App (Patient or Staff)

Who uses it: Staff in transit or away from a fixed workstation — most likely Compliance Managers acknowledging escalated alerts and Practice Managers approving urgent purchase requisitions. There is no patient-facing use case described in the technical spec for this module. Inferred from technical spec §§5.2, 7.

Key tasks performed here:

• Receiving and acknowledging escalated compliance task alerts and overdue order SLA notifications. Inferred from technical spec §5.2.
• Approving or rejecting purchase requisitions where the Practice Manager role requires a timely response. Inferred from technical spec §§3.3, 7.
• Viewing the compliance task dashboard for an overview of outstanding and overdue items. Inferred from technical spec §6.3.

(needs UX writer input — confirm whether mobile is a required delivery surface for this module at Post-MVP tier, or whether web-responsive and tablet cover the full use case)

5. Interaction Model

5.1 Primary Flows

Flow 1: Inventory replenishment (staff-initiated requisition)

Inferred from technical spec §§4.1, 4.2, 5.1.

1. Staff notices low stock (or is prompted by a low-stock alert)
2. Staff selects item → taps / clicks "Request reorder"
3. System pre-fills requisition with item, quantity suggestion, and preferred supplier
4. Staff reviews and submits requisition
5. Requisition enters Pending Approval state
6. Inventory Manager / Practice Manager reviews in approval queue
7. Approver approves → PO Issued automatically, or rejects with reason
8. Supplier notified (via Communication Hub)
9. Delivery tracked: Partially Delivered → Delivered
10. Staff completes goods-received confirmation (quantity, batch, expiry)
11. Stock ledger updated → item returns to In Stock state
12. Invoice matching step → PO moves to Closed (Billed)

Flow 2: Compliance task completion (clinical staff)

Inferred from technical spec §§3.5, 4.3, 5.1.

1. Staff opens assigned compliance task (from dashboard alert or task list)
2. Task detail shows: what is required, due date, role assignment, evidence requirements
3. Staff completes required action (e.g. autoclave test, risk assessment)
4. Staff records completion: enters outcome, attaches evidence, confirms
5. Confirmation step shown — action is audit-significant
6. Task moves to Completed state; timestamp and user identity recorded
7. Compliance dashboard updates (green status for this task)

Flow 3: Controlled Drug register entry — administration

Inferred from technical spec §§12.3, 12.4, 12.8.

1. Clinician selects the CD item from the medication list
2. System displays current running balance and most recent register entry
3. Clinician initiates "Record administration"
4. Step 1 of 3 — Patient and appointment: clinician selects patient reference and linked appointment/procedure
5. Step 2 of 3 — Quantity: clinician enters quantity administered; system shows updated running balance preview
6. Step 3 of 3 — Confirm and witness: clinician confirms; if witness is required, a second authorised user authenticates
7. Final confirmation screen: shows all entered data, running balance, and immutability warning
8. User submits — entry saved as immutable register record
9. Stock balance updated in real time
10. Register view refreshes; new entry is visible and non-editable

Flow 4: Balance discrepancy acknowledgement

Inferred from technical spec §§12.6, 12.8.

1. System detects discrepancy between expected and recorded running balance
2. Alert surfaces in Compliance Dashboard and (if escalated) via notification
3. Compliance Manager opens discrepancy record
4. Discrepancy detail shows: item, expected balance, recorded balance, delta, timestamp of divergence
5. Compliance Manager investigates — may view register entries and linked administration logs
6. Compliance Manager records acknowledgement and investigation outcome (free text + structured reason)
7. Discrepancy marked as acknowledged; record remains in audit trail

Flow 5: Inspection report generation

Inferred from technical spec §12.7.

1. Compliance Manager selects "Generate report" from the Compliance Dashboard or CD Register view
2. Selects report type: CD Register / Medication stock & expiry / Administration log / Disposal & wastage
3. Sets date range and any additional filters (e.g. clinician, location)
4. System generates report — progress indicator shown
5. Report rendered in read-only preview
6. User exports (PDF or CSV format) *(needs UX writer input — confirm supported export formats)*

5.2 State Machines (Mirror of Technical Spec §4)

Order & Delivery Lifecycle (technical spec §4.2)

State treatments inferred from technical spec §4.2 and the governed procurement rules in §9.

Compliance Task Lifecycle (technical spec §4.3)

State treatments inferred from technical spec §4.3 and the non-negotiable rule that compliance tasks cannot be silently missed (§9).

Controlled Drug Register entry (technical spec §12.3)

Inferred from technical spec §§12.3, 12.8.

5.3 Empty / Loading / Error / Offline States

Defined for each primary surface, inferred from technical spec §§6, 10, and the non-negotiable reliability requirement (§10).

Inventory Dashboard

• Empty state: No inventory items configured. (needs UX writer input — instructional prompt copy and onboarding CTA label). Show a prompt to add the first item or import a catalogue.
• Loading state: Skeleton cards for each stock-level summary tile; skeleton rows for alerts lane.
• Error state: If stock-level data cannot be retrieved, show an inline error with a retry action. Do not show stale data without a staleness warning.
• Offline state: Because the technical spec requires that no inventory or compliance record is lost on connectivity failure (§10), the UI must queue any stock deductions or usage logs made offline and surface a visible sync-pending indicator. Read-only views of last-known stock levels should remain accessible. Inferred from technical spec §10.

Procurement & Orders View

• Empty state: No requisitions or orders exist yet. (needs UX writer input — empty state copy). Show prompt to create the first requisition.
• Loading state: Skeleton rows in the requisition list and order list.
• Error state: If an approval action fails, surface an inline error on the relevant requisition row with a retry option. Do not silently fail an approval — the consequence of a missed approval is a procurement delay.
• Offline state: Approval actions are not permitted offline. Surface a clear offline indicator and queue the action for when connectivity is restored. A draft requisition may be composed offline and queued.

Compliance Dashboard

• Empty state: No compliance tasks have been configured. (needs UX writer input — onboarding prompt copy). Show a prompt to configure the first compliance schedule.
• Loading state: Skeleton for each checklist status tile (green / amber / red summary); skeleton rows for task list.
• Error state: If a task-completion submission fails, preserve the entered data and surface a retry. Do not lose evidence attachments.
• Offline state: Compliance task completion (including evidence attachment) must be queueable offline, given that clinical staff may complete tasks in areas with poor connectivity. Inferred from technical spec §10 reliability requirement.

Controlled Drug Register

• Empty state: A CD Register with zero entries must be visually distinguished from one that has not yet been enabled. If the extension is enabled but no entries exist, show an explicit "No entries recorded yet" state — never a blank page. Inferred from technical spec §12.3.
• Loading state: Skeleton rows in the chronological register list.
• Error state: If a CD register entry fails to save, the user must be immediately informed and the entered data preserved in the form. Given immutability rules, the system must not create a partial or duplicate entry silently.
• Offline state: CD register entries require real-time balance reconciliation (technical spec §12.8). Offline CD register submissions must be blocked, with a clear explanation that connectivity is required for controlled drug recording. Inferred from technical spec §§12.3, 12.8.

6. Component Inventory

New components introduced or extended by this module:

• Stock-level tile — summary card showing item name, current quantity, location, and reorder threshold status. Appears in Inventory Dashboard. Inferred from technical spec §6.1.
• Alert lane — a prioritised, scannable list of active low-stock, expiry, and recall alerts. Appears in Inventory Dashboard. Inferred from technical spec §§6.1, 12.6.
• Requisition row — a list item representing a purchase requisition in the approval queue, showing item, quantity, requester, status badge, and primary action (approve / reject). Appears in Procurement & Orders view. Inferred from technical spec §6.2.
• Supplier price comparison panel — a side-by-side or stacked comparison of supplier prices for a given item, including group-buy eligibility indicator. Appears in Procurement & Orders view. Inferred from technical spec §§3.2, 6.2.
• Compliance task card — a task tile showing task name, due date, assigned role, status badge (green / amber / red), and a primary action (complete / view evidence). Appears in Compliance Dashboard and tablet task list. Inferred from technical spec §6.3.
• Evidence attachment control — a file/photo upload and preview component specific to compliance task and disposal record evidence. Appears in compliance task completion forms. Inferred from technical spec §§6.3, 12.4.
• CD Register row — a read-only, immutable chronological list row showing date/time, transaction type (receipt / administration / disposal), quantity in/out, running balance, patient reference (where applicable), clinician, and witness. Appears in the Controlled Drug Register view. Inferred from technical spec §12.3.
• Immutability notice — a persistent, visually distinct indicator on any record that cannot be altered after submission (CD register entries, completed compliance evidence). Appears adjacent to read-only register rows and completed task evidence. Inferred from technical spec §§12.3, 12.8.
• Balance discrepancy alert — a distinct alert component (differentiated from standard low-stock alerts by severity treatment) highlighting a CD running balance discrepancy and surfacing the acknowledgement action. Appears in Compliance Dashboard and CD Register view. Inferred from technical spec §§12.6, 12.8.
• Governed-action confirmation modal — a reusable modal for audit-significant, irreversible actions (PO approval, CD register submission, compliance task completion). Displays a summary of the action, the acting user's identity, and a clear confirm/cancel pair. Inferred from technical spec §§9, 12.8.
• Step indicator — a multi-step progress indicator used in governed workflows (CD administration entry, goods-received flow) to show current step, total steps, and allow backwards navigation before commitment. Inferred from technical spec §§4, 12.4.

Reused from the design system:

• Status badge (neutral / amber / green / red variants)
• List-detail layout shell
• Data table with sort and filter
• Form inputs (text, number, date, select, file upload)
• Toast notification
• In-app banner
• Modal / dialogue
• Skeleton loader
• Pagination controls

7. Visual Design Notes

• Typography: follow the platform design system's established heading scale, body scale, and monospace usage. Monospace is appropriate for running balance figures and PO reference numbers to aid scanability.
• Colour — semantic usage: green = compliant / in stock / approved; amber = due / low stock / pending; red = overdue / out of stock / discrepancy / expired / recalled; neutral / muted = archived / closed / draft. This semantic mapping is directly implied by the green / amber / red checklist status described in technical spec §6.3 and the alert hierarchy in §§5.2, 12.6.
• The Controlled Drug Register and inspection-ready reports must use a document-like visual register — high contrast, dense but legible, with no decorative elements that could undermine their status as legal-adjacent records. Inferred from technical spec §§12.3, 12.7.
• Iconography: use the platform icon set; never use icon-only controls without an accompanying label, particularly for governed actions (approve, reject, complete, submit). Icon sizing must be consistent with the design system scale.
• Expiry dates and recall flags must always be displayed in a visually distinct colour (red for expired / recalled; amber for soon-to-expire) regardless of surrounding context, to ensure they are never missed during a stock review. Inferred from technical spec §§3.1, 12.6.
• Motion: use transitions only where they aid comprehension (e.g. a step-indicator advancing, a toast sliding in). Never animate data tables or register rows — static data should feel stable and authoritative. All motion must respect prefers-reduced-motion.

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large)
• All interactive controls reachable via keyboard
• Focus states visible
• Form fields have programmatic labels
• ARIA used only where native semantics are insufficient
• Touch targets ≥44×44 px on mobile/tablet
• Motion can be reduced via prefers-reduced-motion
• Screen reader tested on NVDA (Windows), VoiceOver (iOS/macOS), and TalkBack (Android)
• Status badges (green / amber / red) must never convey information by colour alone. Each badge must carry a text label or ARIA label so that colour-blind users and screen-reader users receive the same status information. This is particularly critical for the compliance checklist status and CD balance discrepancy alerts. Inferred from the colour-coded status system in technical spec §6.3 and WCAG 1.4.1.
• The Controlled Drug Register's immutability notice must be announced to screen readers when a user focuses on a register row, so that assistive technology users are aware they cannot edit the record. Inferred from technical spec §§12.3, 12.8.
• Multi-step governed workflows (CD entry, goods receipt) must announce step changes to screen readers using ARIA live regions or focus management, so that users relying on assistive technology are not disoriented by view changes. Inferred from the multi-step flow requirements in technical spec §§4, 12.4.

9. Internationalisation

• Locale-aware date/time/number formatting — particularly important for expiry dates, compliance due dates, and PO timestamps, which are inspection-relevant.
• All user-facing strings externalised to localisation files.
• Layouts tolerant of 30% string-length growth (German, French) — form labels and status badges must not truncate in expanded-string locales.
• RTL support: not required at this lifecycle stage, but layout must not use hard-coded left/right directional assumptions that would prevent a future RTL pass.
• Currency display in supplier pricing and PO values must use locale-aware formatting. The module operates in a UK clinical context (CQC, GDC, MHRA references in technical spec §§1, 8), so GBP / en-GB is the default locale, but the formatting layer must be abstracted for multi-region deployments. Inferred from technical spec §§1, 3.2.

10. Cross-Module UX Touchpoints

The following cross-module touchpoints are inferred from the integration relationships stated in technical spec §11.

• Performance Dashboards — The Inventory & Compliance Manager emits stock turnover, expiry/wastage rates, supplier spend, on-time delivery rate, and compliance task completion rate as read-only metrics to Performance Dashboards (technical spec §11). The handoff is data-only: users navigating from a performance dashboard KPI (e.g. a spike in wastage rate) to investigate should be able to deep-link into the relevant Inventory view. The Inventory & Compliance Manager does not render these metrics itself. Inferred from technical spec §11.
• Financial Insights — The module emits stock valuation and supplier spend variance metrics to Financial Insights (technical spec §11). Users in a financial review context may need to cross-reference PO records in this module. The handoff pattern should allow a contextual link from a Financial Insights spend summary to the relevant PO detail view in the Procurement & Orders surface. Inferred from technical spec §11.
• Communication Hub — All outbound notifications — supplier order notifications, escalation alerts to managers, overdue task reminders, and CD discrepancy escalations — are delivered via Communication Hub, not directly by this module (technical spec §§5.2, 12.6). The UX of notification preference management and delivery channel selection belongs to Communication Hub. This module is responsible only for triggering the event and providing the message payload. Inferred from technical spec §§5.2, 12.6 and platform Communication Hub integration patterns.

UX consistency rules:

• Action buttons on tablet appear in the bottom action bar within thumb reach. On web, primary actions appear top-right of the relevant panel or at the bottom of forms.
• Governed-action confirmation modals must use a consistent pattern across all three integration touchpoints — the same modal component used for PO approval, CD register submission, and compliance task sign-off, so that users build muscle memory for the "this is final" pattern. Inferred from technical spec §9.
• Status badge colours (green / amber / red) must be consistent with any semantic colour usage in Performance Dashboards and Financial Insights, so that a user switching between modules does not encounter contradictory colour semantics. Inferred from technical spec §11.

11. Governance & Auditability

Governance is a first-class concern of this module. The following UI treatments are required, inferred from technical spec §§7, 8, 9, 12.

• No AI suggestions in this module. The system-initiated behaviours described in the technical spec (§5.2) are rule-based alerts — low-stock thresholds, SLA timers, expiry date calculations. These must be labelled as system alerts, not AI suggestions. No AI badge should appear. If AI is added in a future version, this section must be revisited. Inferred from technical spec §5.2.
• Audit-significant actions require a confirmation step. The following actions are audit-significant and must present the governed-action confirmation modal before execution: approving or rejecting a purchase requisition, submitting a goods-received record, submitting a CD register entry, completing a compliance task with evidence, acknowledging a balance discrepancy, generating and exporting an inspection report. Inferred from technical spec §§8, 9, 12.8.
• The current user's role and identity must be visible in the application header throughout any governed workflow, so that the user is always aware of the permissions they are acting under. This is especially critical during CD register entries requiring a witness — both the acting clinician and the witness must see their identities confirmed before submission. Inferred from technical spec §§7, 12.3, 12.4.
• Read-only states are visually distinct from editable states. The Controlled Drug Register, completed compliance task evidence, and closed POs must render in a document-like read-only style with no input affordances. Editable records (draft requisitions, in-progress compliance tasks, supplier records) use standard form input styling. Inferred from technical spec §§8, 12.3.
• Immutable records carry a persistent immutability indicator. CD register entries display a permanent, non-dismissible label indicating the record cannot be altered. (needs UX writer input — exact label wording for immutability indicator). Any attempt to interact with an edit affordance that does not exist should surface a brief explanatory tooltip, not a silent non-response. Inferred from technical spec §§12.3, 12.8.
• All audit trail entries are viewable in context. From any governed object (a PO, a compliance task, a CD register entry), users with appropriate permissions can access a timeline of all actions, timestamps, and attributed users without leaving the detail view. Inferred from technical spec §§8, 12.3.
• Expired and recalled items are flagged immediately and persistently. The UI must not allow an expired or recalled item to appear in stock counts without a visible flag. These flags must appear in the Inventory Dashboard, in item detail views, and in any workflow where the item could be selected (e.g. requisition creation). Inferred from technical spec §§3.1, 9, 12.6.

12. Notification & Communication Patterns

The following notification patterns are inferred from the system-initiated behaviours in technical spec §5.2, the compliance task lifecycle in §4.3, and the CD extension alerts in §12.6. All push and email/SMS delivery is via Communication Hub (technical spec §11).

• In-app banner — used for persistent, practice-wide alerts that require acknowledged action: an active MHRA recall affecting a stocked item; a CD balance discrepancy that has not yet been acknowledged; a compliance task in Escalated state. Banners must not auto-dismiss for these cases. Inferred from technical spec §§5.2, 12.6, 9.
• Toast — used for transient confirmation of successful user-initiated actions: requisition submitted, goods received confirmed, compliance task marked complete, CD register entry saved. Toasts auto-dismiss after a standard platform interval. Inferred from technical spec §§4.2, 4.3, 12.4.
• Push notification (via Communication Hub) — used for time-sensitive escalations to mobile/tablet users who may not be actively using the app: compliance task overdue and escalated; order SLA missed; emergency drug level critically low. These are triggered by the system-initiated behaviours in §5.2 and escalation step in §4.3, and delivered via Communication Hub. This module defines the trigger event and payload; Communication Hub owns delivery. Inferred from technical spec §§5.2, 4.3, 12.6, 11.
• Email (via Communication Hub) — used for inspection-relevant notifications and formal escalations: supplier notified of a new purchase order; practice manager notified of an escalated compliance task or CD discrepancy requiring investigation; scheduled report delivery (if configured). Inferred from technical spec §§5.2, 11, 12.6, 12.7.
• SMS (via Communication Hub) — may be used for urgent escalations (e.g. emergency drug critically low, recalled item in active stock) where push notification alone may be insufficient. (needs UX writer input — confirm whether SMS escalation is in scope for this module's initial delivery). Inferred from technical spec §§12.6, 11.

13. Open Questions

• (needs UX writer input — confirm whether the Mobile App is a required delivery surface for this module at Post-MVP tier, or whether web-responsive and tablet are sufficient to cover the identified staff-in-transit use cases)
• The technical spec §12.5 (Storage & Access Controls for the Medication & Controlled Drugs extension) appears to be incomplete — the section heading is present but no content is specified. The UX implications of physical storage access controls (e.g. recording cabinet access, linking physical key handover to a digital log) are unknown. This section must be completed in the technical spec before the UX for that flow can be designed. Inferred from the absence of content in technical spec §12.5.
• (needs UX writer input — define the exact export formats supported by inspection report generation: PDF only, or also CSV/Excel? This affects the report generation flow UI)
• (needs UX writer input — define the witness authentication pattern for CD register entries requiring a second authorised user: does the witness authenticate via their own login credentials inline, or via a PIN/biometric confirmation? This has significant UX implications for the tablet flow)
• The technical spec states that only approved items and approved suppliers may be used (§9). The UX implication — what happens when a staff member attempts to create a requisition for an unapproved item or select an unapproved supplier — needs to be defined. Options include blocking the action with an explanation, or routing a special approval request. This decision must be resolved before the Procurement & Orders flow can be finalised. Inferred from technical spec §9.
• (needs UX writer input — define the onboarding / first-run experience for a new practice setting up their first inventory catalogue and compliance schedule. The empty states for Inventory Dashboard and Compliance Dashboard depend on this decision)
• The technical spec notes that group-buy comparisons are a feature of the Supplier Record (§3.2) and the Procurement & Orders view (§6.2), but does not define how group-buy eligibility is determined or surfaced. The UX for price comparison across suppliers, including the group-buy indicator, cannot be finalised without this definition. Inferred from technical spec §§3.2, 6.2.
• (needs UX writer input — confirm the role-permission matrix for the Controlled Drug extension: specifically, which roles may act as witness for CD administration and disposal, and whether this is configurable per practice or fixed by the system. This determines the witness-confirmation UX pattern)