Lab Manager – UX Specification

Related Technical Authority: Lab Manager – Technical Specification

1. Purpose

This UX specification governs the user experience of Lab Manager — the module responsible for creating, tracking, and closing out laboratory cases from initial dispatch through to receipt and financial reconciliation. It covers practice staff (lab coordinators, clinicians, practice managers, and finance roles) working across the web portal and surgery tablet, as well as external lab users interacting via the lab portal or email. The specification exists to ensure that every surface presents the right action at the right moment, governance is always visible, and no lab case or invoice can progress without clear 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.

Lifecycle fidelity — the UI must reflect the authoritative Lab Case and Lab Invoice state machines exactly. States that are not declared in the technical spec's state machines must never appear in the UI. Inferred from the technical spec's §3.2 and §3.5 normative state machines.

Attribution always present — every state transition, approval, and exception acknowledgement must display who performed it and when, consistent with the technical spec's §8 immutable audit requirement.

Read-only surfaces are visually unambiguous — the Surgery Tablet and Decon Wall Tablet expose LabRequired and LabCaseReference as read-only fields. The UI must make it impossible for a user to assume these fields are editable from those surfaces. Inferred from technical spec §4.3 and §5.2.

Safety context always present — on every appointment row displayed on the Surgery Tablet and Decon Wall Tablet, LabRequired flags and LabCaseReference values are first-class visible fields. They must never be hidden behind a disclosure control, collapsed into an overflow menu, or omitted when space is constrained. Unreceipted lab cases linked to an appointment must be surfaced visually at all times. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.

3. Design Philosophy

Lab Manager's mental model is a governed case tracker, not a messaging tool or a task list. The primary object is always the Lab Case; everything else — communications, invoices, SLA indicators, appointment links — is contextual detail that radiates from it. Inferred from the technical spec's framing of the Lab Case as the canonical artefact (§3.1).

Empty states: An empty lab case list means no cases have been created for the current filter criteria. The empty state should orient the user toward creating a case or adjusting filters, not imply a system error. Inferred from the web portal's list-and-filter capability in technical spec §5.1 and §13.4.

Error states: The most safety-critical error is a case reaching a state transition it is not permitted to make (e.g. bypassing a lifecycle step, or a Received transition without a follow-up appointment or acknowledged exception). These errors must be surfaced with a clear reason and a clear next action — never a silent failure. Inferred from technical spec §3.2 rule 4 and §13.2 rule 4.

AI suggestions: Lab Manager does not currently embed AI surfaces. If AI summarisation or escalation suggestion is introduced in a future version, it must appear visually distinct from user-initiated actions and require explicit human approval before committing, consistent with technical spec §7. No AI is active in the current design scope.

Multi-step flows: Case creation is a multi-field, governed action (minimum seven required fields per technical spec §3.1). A wizard or stepped form pattern is appropriate to reduce cognitive load and enforce required-field validation progressively rather than on a single submit.

Undo/redo: State machine transitions are immutable once committed (technical spec §3.2). There is no undo for a state transition. Cancellation is a governed terminal action available to authorised roles only. The UI must make irreversibility explicit before a transition is confirmed.

Read-only vs editable surfaces: The Surgery Tablet and Decon Wall Tablet are read-only consumers of lab case data. The web portal is the primary editable surface. Role-based access (technical spec §9) further constrains which fields any given user may edit. Read-only fields must be visually distinct from editable fields on all surfaces.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Lab Coordinators, Practice Managers, Finance Roles, and Clinicians (read-only for own cases). Inferred from technical spec §9 role table.

Key tasks performed here:

• Create a new Lab Case, linking it to a patient, clinician, treatment context, dependent appointment(s), lab entity, and expected delivery date. Inferred from technical spec §4.1.1 and §3.1.
• View the full lab case list, filtered by lab, clinician, status, date range, and at-risk/overdue condition. Inferred from technical spec §5.1 and §13.4.
• Progress a Lab Case through its lifecycle states (Created → Sent to Lab → Accepted → Completed → Received / Cancelled) with governed confirmation steps at each irreversible transition. Inferred from technical spec §3.2.
• View the full, immutable communication timeline for each case (portal messages, email interactions, scanner events). Inferred from technical spec §5.1 and §4.1.2–4.1.3.
• Review, approve, and reconcile Lab Invoices against linked Lab Cases. Inferred from technical spec §4.4 and §3.5.
• Acknowledge the exception when marking a Lab Case as Received without a linked follow-up appointment. Inferred from technical spec §3.2 rule 4 and §13.2 rule 4.
• Configure practice-level SLA thresholds and accounting export triggers via the Admin Control Plane. Inferred from technical spec §13.3.
• View at-risk and overdue case indicators. Inferred from technical spec §5.5.

Layout pattern: list-detail for the lab case list and case detail view; wizard for new case creation; form for invoice review and approval. Inferred from the multi-field creation requirement (technical spec §3.1) and the list-and-filter requirement (technical spec §5.1).

4.2 Tablet App

Surgery Tablet

Who uses it: Clinical staff (surgeons/dentists) and clinical support staff during or before a surgery session. Inferred from technical spec §5.2.

Key tasks performed here:

• View today's lab cases linked to the current session's surgeries, including cases awaiting receipt. Inferred from technical spec §5.2.
• Read the LabRequired flag and LabCaseReference on appointment headers — read-only, no editing from this surface. Inferred from technical spec §5.2 and §4.3.
• Create a Lab Case from the surgery context (context-aware creation, pre-populated with current session patient and clinician). Inferred from technical spec §4.1.1.

Touch ergonomics: glove-friendly tap targets of at minimum 44×44 px. The LabRequired flag should be a visually prominent, non-interactive indicator (e.g. a badge or icon with a label) so clinical staff can confirm lab status at a glance without navigating away from the appointment view. Inferred from the read-only, at-a-glance nature of the Surgery Tablet surface described in technical spec §5.2.

First-class field visibility: On every appointment row, LabRequired and LabCaseReference MUST be rendered as first-class visible fields — inline in the appointment row, not hidden behind a disclosure, overflow control, or secondary screen. Where a lab case linked to the appointment has not yet been received (i.e. is in any state prior to Received), the appointment row MUST carry a distinct unreceipted-lab indicator (e.g. a persistent highlight or badge) so clinical staff can immediately identify appointments with outstanding lab work. These indicators MUST remain visible even when screen space is constrained; other appointment detail may be truncated first. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.

Decon Wall Tablet (Surgery & Decon Day View)

Who uses it: Decontamination staff viewing the day's appointments. Inferred from technical spec §5.2.

Key tasks performed here:

• View LabRequired flag and LabCaseReference on appointment headers — read-only only. Inferred from technical spec §5.2 and §4.3.

This surface is strictly read-only for all Lab Manager data. No Lab Case creation or update is possible from this surface. Inferred from technical spec §4.3 and §5.2.

First-class field visibility: As on the Surgery Tablet, LabRequired and LabCaseReference MUST appear as first-class visible fields on every appointment row. Unreceipted lab cases linked to an appointment MUST be highlighted with a persistent indicator at all times. These fields and indicators must never be collapsed or omitted regardless of row density. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.

Touch ergonomics: wall-mounted viewing distance suggests larger text for LabRequired indicators and status badges. Tap targets ≥44×44 px if any interactive element is present; otherwise the surface is display-only. Inferred from the Day View's decontamination-room context implied by technical spec §5.2.

4.3 Mobile App (Patient or Staff)

The technical specification explicitly records no patient-facing or staff-mobile capability for Lab Manager (technical spec §5.3 is blank). No mobile app surface is defined for this module at this lifecycle stage. (needs UX writer input if a mobile surface is added in a future iteration)

4.4 Lab Portal (External)

Who uses it: External lab users at labs that have been granted portal access. Inferred from technical spec §5.4 and §9.

Key tasks performed here:

• View and accept assigned Lab Cases. Inferred from technical spec §5.4.
• Update the status and expected due date of an assigned case. Inferred from technical spec §5.4.
• Upload files (e.g. work-in-progress images, dispatch notes) against a case. Inferred from technical spec §5.4.
• Mark a case as complete (dispatched). Inferred from technical spec §5.4.
• Submit a Lab Invoice against one or more completed cases. Inferred from technical spec §5.4.

Lab Portal users have a tightly scoped view: they see only their assigned cases and cannot view other labs' cases, practice-internal notes, or invoice approval states beyond Submitted. Inferred from technical spec §9 Lab User role (read/update assigned cases only) and strict tenant isolation in §14.

Layout pattern: list-detail for case overview and case detail; form for invoice submission. Inferred from the task set above and the constrained scope of the Lab User role.

5. Interaction Model

5.1 Primary Flows

Flow 1: Lab Case creation (practice-initiated, web portal)

Inferred from technical spec §4.1.1, §3.1, and §13.2 rule 1.

1. User navigates to the Lab Cases section of the web portal.
2. User selects the action to create a new Lab Case.
3. A stepped creation form opens. Step 1: select patient (FK lookup). Step 2: select treating clinician. Step 3: enter treatment context. Step 4: link dependent appointment(s). Step 5: select lab entity from the Lab Directory. Step 6: set expected delivery date.
4. Required-field validation runs progressively; the user cannot advance a step without completing required fields.
5. User reviews a summary screen before confirming creation.
6. On confirmation, the Lab Case is created in the Created state. The audit trail records the creating user, role, and timestamp.
7. The user is taken to the new case's detail view.

(needs UX writer input — exact labels, step titles, and confirmation modal copy)

Flow 2: Lab Case progression through lifecycle (web portal)

Inferred from technical spec §3.2 state machine and §13.2 rules 2–4.

Created
  └─► Sent to Lab        [Practice or Lab Coordinator initiates]
        └─► Accepted     [Lab portal action or email action link]
              ├─► On Hold (awaiting practice input)
              │     └─► Accepted (returned from hold)
              └─► Completed (dispatched by lab)
                    └─► Received   [Requires: linked follow-up appt OR acknowledged exception]
Cancelled            [Available to authorised roles from most states]

Each forward transition requires a confirmation step in the UI. The Received transition specifically must gate on either a linked follow-up appointment being present or the user explicitly acknowledging an exception, with the exception text recorded in the audit trail. Inferred from technical spec §3.2 and §13.2 rule 4.

Cancellation is a terminal action. It must require a confirmation modal that makes the irreversibility explicit. Inferred from technical spec §3.2 and the general governance principle.

Flow 3: Lab Case receipt with exception acknowledgement (web portal)

Inferred from technical spec §3.2 rule 4 and §13.2 rule 4.

1. User selects Mark as Received on a Lab Case in Completed state.
2. System checks whether a linked follow-up appointment exists.
3. If a linked appointment exists: standard confirmation modal. User confirms. Case transitions to Received.
4. If no linked appointment exists: a blocking modal appears informing the user that no follow-up appointment is linked. The user must explicitly acknowledge the exception and enter a reason. (needs UX writer input — exact modal copy and reason field label)
5. On acknowledgement, the exception and reason are recorded in the audit trail, and the case transitions to Received.

Flow 4: Invoice review and approval (web portal, Finance Role / Practice Manager)

Inferred from technical spec §3.5 state machine, §4.4, and §13.2 rules 9–10.

1. A Lab Invoice in Submitted by Lab state appears in the invoice queue.
2. Finance Role or Practice Manager opens the invoice detail view.
3. Invoice line items are displayed alongside the linked Lab Cases. Reconciliation status is shown (matched / unmatched).
4. If any line item does not reconcile to a recorded Lab Case, the invoice cannot be advanced; a validation message explains the mismatch. (needs UX writer input — exact validation message copy)
5. User reviews reconciled line items and selects Approve. Invoice transitions to Approved.
6. On payment confirmation (external or entered manually), user confirms payment. Invoice transitions to Paid (confirmed).
7. On transition to Paid (confirmed), associate deductions are posted automatically. A notification confirms that charges have been posted. (needs UX writer input — notification copy)
8. Invoice is queued for export to accounting integration.

Flow 5: Email-only lab interaction (no portal access)

Inferred from technical spec §4.1.2.

1. Lab Manager sends a governed notification email to the lab via Communication Hub when a case is Sent to Lab.
2. The email contains single-use action links: Accept / Need Info / Complete.
3. Lab user clicks an action link. The action is authenticated and parsed by Lab Manager, mapped to the Lab Case, and recorded in the case's communication timeline.
4. The Lab Case transitions to the appropriate next state.
5. The practice sees the updated state and the inbound communication in the case timeline.

From the practice side, the UX effect of an email-only lab interaction is identical to a portal interaction: the case timeline shows the event, the state badge updates, and any SLA timers respond accordingly. The difference is invisible to practice staff. Inferred from technical spec §4.1.2 and §12 (build rule 12).

Flow 6: SLA monitoring and escalation

Inferred from technical spec §3.6, §4.2, and §5.5.

1. When a Lab Case transitions to Accepted, the SLA timer starts automatically (no user action required).
2. As the expected delivery date approaches, the case's SLA condition progresses: normal → At-Risk → Overdue.
3. At-Risk cases are visually distinguished in the lab case list (e.g. a warning indicator).
4. Overdue cases carry an overdue indicator. An escalation task is automatically emitted to Task Manager.
5. Practice staff see the at-risk/overdue indicators in the web portal list view and on the Surgery Tablet (for today's cases).
6. Resolving the escalation task is owned by Task Manager; Lab Manager shows the case's current SLA condition only.

(needs UX writer input — exact indicator labels and tooltip copy)

Flow 7: Day-view lab status visibility (Surgery Tablet and Decon Wall Tablet)

Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present' and technical spec §4.3, §5.2.

This flow describes how lab-relevant safety context is surfaced on the Surgery Tablet and Decon Wall Tablet day views. It is not an interactive workflow — it is a continuous display contract that applies to every appointment row on both surfaces.

1. When the day view renders an appointment row, Lab Manager data is resolved for that appointment. If LabRequired is true, the LabRequired flag MUST appear inline in the appointment row as a labelled, visually prominent indicator — not in a tooltip, secondary panel, or collapsed section.
2. If LabCaseReference is populated, it MUST be displayed inline alongside the LabRequired flag, using monospace type to distinguish the machine-generated reference from human-authored text.
3. If the linked Lab Case is in any state prior to Received (i.e. the lab work has not yet been received by the practice), the appointment row MUST display a distinct unreceipted-lab highlight (e.g. a persistent border treatment, background tint, or badge) that persists for the duration of the session.
4. If LabRequired is false or no lab case is linked, no lab indicator is shown and no space is reserved for one.
5. If lab status cannot be retrieved (error or offline), the LabRequired indicator MUST default to a safe fallback state (e.g. LabRequired: unknown) rather than silently displaying as false. This prevents clinical staff from incorrectly assuming no lab work is needed. Inferred from the patient-safety implication of the LabRequired field described in technical spec §4.3.
6. On the Surgery Tablet only, if a LabRequired appointment has no linked LabCaseReference yet, a contextual affordance to create a Lab Case (pre-populated with the current patient and clinician) MUST be accessible from the appointment row without navigating away from the day view.

These display requirements apply equally to the Surgery Tablet and the Decon Wall Tablet. The Decon Wall Tablet omits the case-creation affordance (step 6) as it is a strictly read-only surface.

(needs UX writer input — exact label copy for the unreceipted-lab indicator and the LabRequired fallback state)

5.2 State Machines (Mirror of Technical Spec §3)

Lab Case states

Inferred from technical spec §3.2.

Overdue is a computed condition, not a state. It is displayed as an indicator overlaid on the case's current state badge, not as a replacement state. Inferred from technical spec §3.2 rule 2 and §13.2 rule 3.

Lab Invoice states

Inferred from technical spec §3.5.

5.3 Empty / Loading / Error / Offline States

Web portal — lab case list

Inferred from technical spec §5.1 and §13.4.

• Empty state: No cases match the current filters. Display a clear message explaining the empty result with options to clear filters or create a new case. (needs UX writer input — exact empty-state message and CTA label)
• Loading state: Skeleton rows in the list while data loads. Filter controls remain visible and interactive.
• Error state: If the list fails to load, display an error message with a retry action. Do not show a partially loaded list. (needs UX writer input — exact error message copy)
• Offline state: The web portal requires connectivity; offline use is not supported on this surface. If connectivity is lost, show a connection-lost banner and disable write actions. Read-only display of last-fetched data is acceptable if technically feasible. Inferred from technical spec §14 (offline support is scoped to the Surgery Tablet, not the web portal).

Surgery Tablet — today's lab cases

Inferred from technical spec §5.2 and §14.

• Empty state: No lab cases are linked to today's session. Display a calm, informational message. (needs UX writer input)
• Loading state: Skeleton appointment headers while lab status fields resolve.
• Error state: If lab status cannot be retrieved, LabRequired and LabCaseReference fields should display a safe fallback (e.g. LabRequired: unknown) rather than defaulting to false, to avoid clinical staff incorrectly assuming no lab work is needed. (needs UX writer input — exact fallback label) Inferred from the patient-safety implication of the LabRequired field described in technical spec §4.3.
• Offline state: The Surgery Tablet supports offline capture with deterministic replay on reconnection (technical spec §14). While offline, the last-synced lab case data should be displayed with a clear offline indicator. Write actions (e.g. case creation) should be queued and clearly shown as pending sync. Conflict resolution behaviour during replay is an open question (see §13).

Lab portal

Inferred from technical spec §5.4.

• Empty state: No cases have been assigned to this lab. Display an informational message. (needs UX writer input)
• Loading state: Skeleton list rows.
• Error state: Action-link-based interactions (email-only labs) that fail should display a clear error page with instructions to contact the practice. (needs UX writer input)
• Offline state: Standard connectivity-lost message; no offline mode for the lab portal.

6. Component Inventory

New components introduced or extended by this module:

• Lab Case status badge — displays the current Lab Case lifecycle state with a visually distinct treatment per state. Appears in the case list, case detail header, surgery tablet appointment header. Inferred from technical spec §3.2 and §5.
• SLA / overdue indicator — overlaid condition badge shown on a Lab Case when the computed SLA condition is At-Risk or Overdue. Distinct from the lifecycle state badge. Appears in the web portal case list and surgery tablet. Inferred from technical spec §3.6 and §5.5.
• Lab Case communication timeline — a chronological, immutable log of all communications and lifecycle events for a single Lab Case. Includes portal messages, email interactions, scanner events, and internal notes. Appears in the case detail view (web portal). Inferred from technical spec §5.1 and §4.1.2–4.1.3.
• Exception acknowledgement modal — a blocking modal that appears when a user attempts to mark a case as Received without a linked follow-up appointment. Requires the user to explicitly acknowledge and record a reason. Inferred from technical spec §3.2 rule 4 and §13.2 rule 4.
• Lab Invoice reconciliation panel — displays invoice line items alongside matched/unmatched Lab Cases for Finance Role review. Blocks invoice approval when reconciliation is incomplete. Inferred from technical spec §4.4 and §3.5.
• LabRequired / LabCaseReference read-only field pair — compact, read-only display component embedded in appointment headers on the Surgery Tablet and Decon Wall Tablet. Cannot be edited from those surfaces. Both fields are first-class visible elements rendered inline on every appointment row; they must never be hidden behind a disclosure or overflow control. Inferred from technical spec §4.3 and §5.2, and Surgery & Decon Day View §2.
• Unreceipted-lab row indicator — a persistent visual treatment (e.g. border, tint, or badge) applied to appointment rows on the Surgery Tablet and Decon Wall Tablet when the linked Lab Case has not yet been received. Remains visible for the duration of the session. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.
• Lab Case creation wizard — a stepped form enforcing the minimum required fields for Lab Case creation, with progressive validation. Inferred from technical spec §3.1 and §13.2 rule 1.

Reused from the design system:

• Filter bar / faceted search — for the web portal lab case list. Inferred from technical spec §13.4.
• Confirmation modal — for irreversible state transitions (cancellation, receipt, invoice approval). Inferred from the governance requirements in technical spec §3.2 and §3.5.
• Toast notification — for transient success confirmations (case created, invoice approved, charges posted). Inferred from typical post-action feedback patterns consistent with the module's event surface.
• In-app banner — for persistent at-risk/overdue alerts and offline state warnings. Inferred from technical spec §5.5 and §14.
• Skeleton loader — for list and detail views during data fetch. Standard platform pattern.

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale and body scale to follow the platform design system) Monospace type is appropriate for LabCaseReference identifiers where they appear inline in appointment headers and the case detail view, to distinguish machine-generated references from human-authored text. Inferred from the identifier nature of LabCaseReference in technical spec §3.1.
• Colour: Semantic colour usage should follow the platform design system's success / warning / error / info / neutral convention. At-Risk cases should use the warning semantic colour; Overdue cases should use the error semantic colour; Received/completed states should use the success semantic colour; Cancelled should use a muted/neutral treatment. Unreceipted-lab row indicators on the Surgery Tablet and Decon Wall Tablet should use the warning semantic colour to draw clinical attention without implying an error condition. Inferred from the severity hierarchy implied by technical spec §3.6 and §5.5, and Surgery & Decon Day View §2.
• Iconography: (needs UX writer input — icon set and sizing to follow the platform design system) The LabRequired flag on appointment headers must always include a text label alongside any icon, never icon-only, given the patient-safety significance of the field. Inferred from the clinical context of the Surgery and Decon tablet surfaces in technical spec §5.2.
• Motion: (needs UX writer input — transition usage to follow the platform design system) State badge transitions (e.g. Created → Sent to Lab) may use a brief transition to draw attention to the change, but the communication timeline must never animate in a way that obscures the sequence of events. Audit-significant confirmations must not be auto-dismissed. Inferred from the governance and auditability requirements in technical spec §8.

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 / VoiceOver / TalkBack.

The LabRequired field on appointment headers must be conveyed to screen readers with a clear, descriptive label — not just a visual icon — given its patient-safety significance in a clinical setting. Inferred from technical spec §4.3 and §5.2.

The unreceipted-lab row indicator on the Surgery Tablet and Decon Wall Tablet must be conveyed to screen readers as a meaningful status annotation on the appointment row (e.g. via aria-label or a visually hidden text supplement), not as a purely decorative colour change. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.

The exception acknowledgement modal for the Received transition must be fully keyboard-navigable and must not auto-dismiss. The user must perform an explicit action to acknowledge. Inferred from the governance requirement in technical spec §3.2 rule 4.

The communication timeline must be navigable by keyboard and screen reader in chronological order, with each entry's timestamp and actor readable programmatically. Inferred from the immutable audit nature of the timeline in technical spec §5.1 and §8.

9. Internationalisation

Locale-aware date/time/number formatting.

All user-facing strings externalised.

Layouts tolerant of 30% string-length growth (German, French).

RTL support: requirements not specified in the technical spec. (needs UX writer input — confirm whether RTL is required for this module's deployment markets)

Expected delivery dates and SLA thresholds must respect locale-aware date formatting throughout — in the case list, case detail, invoice panel, and tablet surfaces. Inferred from the centrality of ExpectedDeliveryDate to SLA monitoring in technical spec §3.1 and §3.6.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Appointment Manager — the primary bidirectional touchpoint. When creating a Lab Case, the user selects a dependent appointment from Appointment Manager data. The LabRequired and LabCaseReference fields are surfaced in Appointment Manager's Day View surfaces (Surgery Tablet, Decon Wall Tablet) as read-only, Lab-Manager-owned data. Users navigating the Day View will see lab status without leaving the appointment context. Inferred from technical spec §4.3, §5.2, and §6.1–6.2.
• Surgery & Decon Day View — the Day View module's core principle of 'Safety context always present' requires that LabRequired flags, LabCaseReference values, and unreceipted-lab indicators are first-class visible fields on every appointment row. Lab Manager owns the data; Surgery & Decon Day View owns the row layout contract. Both modules must agree on field position, visual treatment, and fallback behaviour. Changes to either module that affect appointment row density or layout must be reviewed against this shared contract. Inferred from Surgery & Decon Day View §2 Core Principle 'Safety context always present'.
• Task Manager — when a Lab Case becomes Overdue, an escalation task is emitted to Task Manager and appears in Task Manager's task surfaces. The user resolves the task in Task Manager, not in Lab Manager. Lab Manager only shows the case's current SLA condition; it does not surface the task's resolution state. Inferred from technical spec §4.2, §6.2, and the explicit non-goal in §11.
• Communication Hub — lab-facing notification emails (reminders, escalations, single-use action links for email-only labs) are sent via Communication Hub, not directly from Lab Manager. From the practice user's perspective, outbound lab communications appear in the case's communication timeline. Inferred from technical spec §6.2 and §4.1.2.
• Financial Insights — Lab Manager posts associate charge data and lab fee metrics to Financial Insights after a Lab Invoice is confirmed as paid. Practice staff do not leave Lab Manager to review these charges; the Lab Invoice detail view shows the posting confirmation. Associate statement rendering is owned by Financial Insights and is not shown within Lab Manager. Inferred from technical spec §4.4, §6.2, and §11.
• Performance Dashboards — Lab Manager emits SLA and turnaround metrics to Performance Dashboards. These metrics are not visualised within Lab Manager's own surfaces. If a user wants to analyse trends, they navigate to Performance Dashboards. Inferred from technical spec §4.5, §6.2, and §11.
• Access Manager — role assignment and RBAC configuration happen in Access Manager, not in Lab Manager. Lab Manager surfaces reflect the current user's role-based permissions without exposing role management UI. The active user's role should be visible in the header on all Lab Manager surfaces. Inferred from technical spec §9 and §10.
• Audit & Compliance — all Lab Case and Lab Invoice state transitions, exception acknowledgements, and cross-module events are emitted to Audit & Compliance as an immutable log. Users with appropriate access can export or inspect the audit log from the Audit & Compliance module; Lab Manager surfaces only the case-level communication timeline, not the full platform audit log. Inferred from technical spec §8 and §6.2.

UX consistency rules:

• The LabRequired badge and LabCaseReference field must appear in the same position and with the same visual treatment on both the Surgery Tablet and the Decon Wall Tablet, as both surfaces are governed by the same read-only contract. Inferred from technical spec §4.3.
• The unreceipted-lab row indicator must use the same visual treatment on both the Surgery Tablet and the Decon Wall Tablet. It must be agreed with the Surgery & Decon Day View module and documented in the shared component specification.
• Escalation tasks created by Lab Manager and visible in Task Manager should carry the Lab Case reference so users can navigate back to the case. The exact linking mechanism is subject to Task Manager's UX conventions. Inferred from technical spec §4.2 and §6.2.

11. Governance & Auditability

Every state transition in both the Lab Case and Lab Invoice lifecycles must display a confirmation step before the transition is committed. Irreversible transitions (Cancellation, Received with exception) must use a modal that makes the irreversibility explicit. Inferred from technical spec §3.2, §3.5, and §8.

The communication timeline on each Lab Case detail view is a visible, immutable record of all interactions — portal actions, email actions, scanner events, and internal notes. It must be visually distinct from editable content (e.g. read-only background, no edit controls adjacent to timeline entries). Inferred from technical spec §5.1 and §8.

Each state transition shown in the communication timeline must display the actor's name and role, and the timestamp of the transition. This attribution must be visible without requiring the user to open a separate audit view. Inferred from technical spec §8's requirement for actor identity and role on all events.

The current user's role and active permissions should be visible in the header on all Lab Manager surfaces (web portal and lab portal), consistent with the RBAC model in technical spec §9.

Read-only fields (e.g. LabRequired, LabCaseReference on Day View surfaces; the communication timeline) must be visually distinct from editable fields. Read-only inputs should not resemble active form controls. Inferred from technical spec §4.3 and the general governance principle.

The exception acknowledgement when receiving a case without a follow-up appointment must be displayed as a discrete, persistent entry in the audit timeline — not as a transient toast. The user who acknowledged it and the reason they gave must be permanently visible on the case record. Inferred from technical spec §3.2 rule 4 and §8.

Invoice approval and associate charge posting are finance-significant actions. The UI must require explicit confirmation for both, and the confirmation step must name the specific invoice and the amount being approved or posted. Inferred from technical spec §4.4, §3.5, and §8.

Although Lab Manager does not currently embed AI, the AI boundaries in technical spec §7 are a governance commitment. Any future AI-generated suggestion must be visually distinct from user-initiated actions (e.g. a distinct badge or border style), and must require explicit human approval before committing. This constraint is pre-declared here so that future AI additions do not require a re-architecture of the governance model.

12. Notification & Communication Patterns

The following patterns are inferred from the technical spec's §5.5, §6.2 (Communication Hub integration), and §3.6 (SLA/escalation lifecycle).

• In-app banner (persistent): Shown in the web portal when one or more Lab Cases are in an at-risk or overdue condition for the current practice. The banner persists until the condition is resolved; it is not dismissible. Inferred from technical spec §5.5 engagement signals and the governance principle that overdue cases represent appointment integrity risk.
• In-app banner (connectivity): Shown on the Surgery Tablet when the device is offline. Indicates that displayed lab case data may not reflect the latest state and that write actions are queued for sync. Inferred from technical spec §14 offline capture requirement.
• Toast (transient): Shown after successful non-critical actions: case created, case state advanced (for non-overdue transitions), invoice submitted. Auto-dismisses after a standard interval. Inferred from the pattern of governed but routine state transitions throughout the lifecycle.
• Push notification (via Communication Hub — NOT directly): Lab Manager emits notification triggers to Communication Hub for escalation events (case Overdue, SLA reminder due). Communication Hub owns delivery. Lab Manager does not send push notifications directly. Inferred from technical spec §6.2.
• Email (via Communication Hub — NOT directly): All outbound lab-facing emails (case assignment notifications, single-use action links for email-only labs, reminders) are triggered by Lab Manager and delivered by Communication Hub. Lab Manager does not send email directly. Inferred from technical spec §4.1.2 and §6.2.
• In-app alert (blocking): The exception acknowledgement modal for the Received transition, and invoice reconciliation failure messages, are blocking in-app interactions — they halt the user's progress until explicitly resolved. These are not notifications; they are governed gates in the interaction flow. Inferred from technical spec §3.2 rule 4 and §4.4.

(needs UX writer input — exact notification copy for all of the above patterns)

13. Open Questions

UX decisions to resolve before this spec is promoted from draft to published.

1. Surgery Tablet offline conflict resolution: The technical spec states that offline capture with deterministic replay is supported on the Surgery Tablet (technical spec §14 and open question §15.1), but the conflict resolution strategy when a Lab Case is remotely updated while the tablet is offline has not been defined. The UX treatment for a sync conflict (e.g. which version wins, how the user is informed) cannot be designed until this is resolved.
2. SLA threshold defaults: The technical spec requires configurable SLA thresholds but specifies no default values (technical spec §15.2). The empty-state and first-run experience for SLA configuration in the Admin Control Plane depends on knowing these defaults. (needs product owner input)
3. Lab portal access determination: The technical spec describes portal access as optional per lab (technical spec §15.3) but does not specify whether the toggle is practice-level, lab-level, or both. The Admin Control Plane configuration UX cannot be finalised until this is resolved.
4. Secure email link expiry UX: Single-use email action links expire after a period not yet defined (technical spec §15.4). The error page shown to a lab user who clicks an expired link — and the instructions given to recover — cannot be authored until the expiry policy is confirmed.
5. Associate chargeback display: The technical spec records that associate deductions are posted after payment confirmation (technical spec §15.5), but the calculation method and configurability are unresolved. Whether and how the Lab Invoice detail view should display a calculated or estimated associate deduction cannot be designed until this is defined.
6. Lab Case cancellation rules: The conditions under which a case may be cancelled, who may cancel it, and whether a cancelled case can be superseded are unresolved (technical spec §15.6). The cancellation confirmation modal copy and any supersession UI depend on these rules being defined.
7. Unreceipted-lab indicator shared contract: The visual treatment and exact position of the unreceipted-lab row indicator on the Surgery Tablet and Decon Wall Tablet must be agreed jointly with the Surgery & Decon Day View module. Neither module should finalise this component in isolation. (needs cross-module design review)
8. (needs UX writer input — confirm RTL language support requirements for the deployment markets of this module)
9. (needs UX writer input — confirm screen reader testing matrix: NVDA, VoiceOver, TalkBack — and which are in-scope for the Surgery Tablet surface specifically)