Security and Privacy – UX Specification

Related Technical Authority: Security and Privacy – Technical Specification

1. Purpose

This UX specification governs the user-facing and operator-facing experience of the Security and Privacy module across all Primoro surfaces. Because Security and Privacy operates as a platform-wide, non-optional foundation, its UX is largely invisible to end users — its job is to protect without creating friction. The spec covers the surfaces where security controls do become visible: authentication moments, session-management events, consent and privacy notices, admin configuration, and the audit log. It serves three primary roles: patients experiencing authentication and privacy controls on the mobile app; clinical and administrative staff encountering session management on shared tablets and the staff app; and practice admins configuring security behaviour and reviewing audit records via the web portal.

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.
• Security is silent until it must speak — the vast majority of security controls operate transparently in the background; the UI only surfaces security state when the user must take an action (e.g. re-authenticate, acknowledge a session expiry) or when an admin needs to review or configure. Inferred from the technical spec §1: "It operates quietly in the background across every device and workflow — built in, not bolted on."
• No security through obscurity, but no unnecessary exposure — security controls are discoverable by authorised users who need them; they are not advertised to users for whom they are irrelevant. Inferred from technical spec §4.1 privacy-by-design principle: "Data visible only when contextually required."
• Irreversible actions demand explicit confirmation — any action that cannot be undone (session revocation, account deletion, access revocation) must require a deliberate, confirmatory gesture. Inferred from technical spec §13.2 rule 3 and §4.6 right-to-erasure requirement.

3. Design Philosophy

The mental model this module embodies is a trusted, silent guardian. Security and Privacy is not a feature users interact with by choice; it is infrastructure that enforces good defaults so that users never have to think about security hygiene. The design therefore treats most security enforcement as invisible infrastructure, surfacing only at the moments where human attention or action is genuinely required. Inferred from technical spec §1 and §11.

Empty states: The audit log and configuration screens will have empty states only during initial setup. An empty audit log is not normal in production; if shown, it should indicate when logging began rather than implying nothing has happened. Inferred from technical spec §8, which mandates logging of all events from first use. (needs UX writer input — exact empty-state message for audit log on a brand-new tenant)

Error states: Authentication failures, session expiry events, and revocation events must explain clearly what happened and what the user should do next — not just that something went wrong. Security errors must not reveal information that could assist an attacker (e.g. distinguishing "user not found" from "wrong credential"). Inferred from technical spec §4.2 and §13.2.

AI suggestions: This module does not embed AI surfaces. Where AI activity (e.g. from AI Quality Monitor) is recorded in the audit log, the Actor field must visually distinguish AI-generated events from user-generated events so that reviewers can immediately identify AI activity. Inferred from technical spec §7 and the actor_type field in §13.1.

Multi-step flows: Privacy notice and consent capture on first use are multi-step flows. They must be linear, not skippable, and must not mix consent with other onboarding tasks. Inferred from technical spec §4.6. Account deletion is a multi-step flow with an explicit irreversibility warning at the final step. (needs UX writer input — confirmation modal copy for account deletion)

Undo/redo: Audit-significant actions — session revocation, access revocation, account deletion — are not undoable by design (technical spec §13.2 rules 3 and 4). The UI must make this clear before the action is committed, not after.

Read-only vs editable surfaces: The audit log is always read-only. Configuration settings are editable only by practice admins. All configuration fields must be visually distinct from read-only audit data. Inferred from technical spec §9 access control table.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Practice admins and authorised administrative staff. Inferred from technical spec §9, which restricts audit log reading and configuration to "authorised practice admin roles via Access Manager."

Key tasks performed here:

• Review and filter the immutable audit log by EventType, Actor, Target, DeviceId, date range, and RepresentedPatientId. Inferred from technical spec §13.4.
• Export audit records for regulatory inspection. Inferred from technical spec §8: "exportable for regulatory inspection."
• Configure authentication methods permitted for staff and patients. Inferred from technical spec §13.3.
• Configure session timeout rules (inactivity threshold and rota-end auto-logout). Inferred from technical spec §13.3.
• Configure notification privacy defaults. Inferred from technical spec §13.3.
• Configure retention and deletion policies, including evidence-clip expiry. Inferred from technical spec §13.3.
• Configure device-specific behaviour (shared vs personal). Inferred from technical spec §13.3.
• Trigger authorised access to retained evidence clips (for authorised reviewers only). Inferred from technical spec §4.7 and §9.

Layout pattern: The audit log section uses a list-detail layout — a filterable, paginated log list on the left, with event detail on the right. The configuration section uses a form layout, grouped by configuration domain (authentication, session, notifications, retention, devices). Inferred from the distinct nature of the audit log (tabular, filterable data) vs configuration (structured settings) as described in technical spec §9 and §13.3–13.4.

4.2 Tablet App

Who uses it: Clinical staff, decontamination staff, and receptionists using shared in-practice tablets. Inferred from technical spec §5.2 and the presence of TrayReady, TaskCompleted, and WorkflowCompleted EventTypes in §3.2.

Key tasks performed here:

• Authenticate at the start of each session (mandatory before any session begins). Inferred from technical spec §4.3: "Mandatory user authentication before session start."
• Fast login via badge, PIN, or QR code (where configured). Inferred from technical spec §4.3 and §13.3.
• Receive notification of automatic logout on inactivity or rota end — and see a clear, non-dismissible session-ended screen before the next user begins. Inferred from technical spec §4.3: "Automatic logout on inactivity or rota end time" and "Full data wipe between users."

Touch ergonomics: All authentication controls (PIN entry, QR scan target, session-end confirmation) must use touch targets ≥48 px to support gloved use by clinical and decontamination staff. The session-ended / wipe-confirmation screen must be dismissible only by initiating a new authenticated session — not by tapping a "back" or "cancel" control. Inferred from the clinical environment described in technical spec §5.2 and the mandatory-wipe requirement in §13.2 rule 4.

4.3 Mobile App (Patient)

Who uses it: Patients on their personal mobile devices. Inferred from technical spec §5.3.

Key tasks performed here:

• Complete passwordless OTP login on first use and at re-verification. Inferred from technical spec §4.2: "Passwordless login by default (OTP)."
• Optionally enrol biometrics for subsequent logins. Inferred from technical spec §4.2: "Optional biometrics for convenience."
• Review and accept the privacy notice on first use. Inferred from technical spec §4.6: "Clear privacy notices on first use."
• Capture required consent (where regulation mandates). Inferred from technical spec §4.6: "Consent capture where required by regulation."
• Manage notification privacy settings. Inferred from technical spec §4.6 and §4.3: "Secure notification handling with no sensitive content in previews."
• Initiate account deletion (triggering full local data wipe). Inferred from technical spec §4.6: "Right to erasure — GDPR-aligned deletion including full local wipe on account deletion."

4.4 Staff App Mode

Who uses it: Clinical and administrative staff on personal mobile devices running Staff App Mode. Inferred from technical spec §5.4.

Key tasks performed here:

• Perform the hidden activation gesture to reveal the Staff App Mode authentication screen. Inferred from technical spec §4.2 and §5.4: "A hidden staff-mode activation gesture required before any authentication screen is presented." (needs UX writer input — gesture type and discoverability mechanism to be defined with the design team)
• Authenticate via enterprise SSO with MFA inherited from the identity provider. Inferred from technical spec §4.2 staff requirements.
• Receive in-app notification when their session is revoked (e.g. role change, departure). Inferred from technical spec §13.2 rule 13: "Access revocation must apply instantly and globally across all active sessions."

5. Interaction Model

5.1 Primary Flows

Flow 1 — Patient first-use authentication and privacy consent

Inferred from technical spec §4.2 (passwordless OTP) and §4.6 (privacy notice and consent on first use).

App launch (first use)
  → Display privacy notice (non-skippable, paginated if multi-page)
      → Patient confirms they have read the notice
          → Consent capture screen (where regulation requires)
              → Patient confirms consent
                  → OTP entry screen
                      → OTP verified
                          ↓ success
                          → Optional: biometric enrolment prompt
                              → Patient accepts or declines
                                  → Home screen
                          ↓ OTP failure (max attempts)
                          → Lockout screen with re-request option

(needs UX writer input — OTP entry field label, error messages, lockout messaging, and biometric enrolment prompt copy)

Flow 2 — Patient re-authentication after session expiry

Inferred from technical spec §4.2: "Automatic session expiry and re-verification."

User attempts action after inactivity expiry
  → Current screen is replaced by re-authentication prompt
    (no content visible behind prompt)
      → OTP or biometric challenge
          ↓ success → returns to previous context
          ↓ failure → lockout screen

Flow 3 — Shared tablet session start and end

Inferred from technical spec §4.3 shared clinic tablets and §13.2 rules 4 and 13.

Tablet displays locked / session-ended screen
  → Staff initiates fast login (badge / PIN / QR)
      → Authentication verified
          → Session begins; user's role-scoped data loaded
              ↓ Inactivity timeout reached OR rota end time reached
              → Auto-logout triggered
              → Full session wipe confirmed (no user action required)
              → Locked / session-ended screen displayed
                (cannot be dismissed without new authentication)

Flow 4 — Practice admin configures a security setting

Inferred from technical spec §9 and §13.3. All configuration changes must themselves be logged as SecurityEvents per technical spec §13.3.

Admin navigates to Security & Privacy settings in Web Portal
  → Selects configuration domain (e.g. Session Timeouts)
      → Views current configured values (read-only display)
          → Selects Edit
              → Modifies value(s) in form
                  → Saves
                      → Confirmation step shown
                          (summary of change + irreversibility warning where applicable)
                          → Admin confirms
                              → Change applied
                              → Toast: *(needs UX writer input)*
                              → Change recorded as SecurityEvent (transparent to admin)

Flow 5 — Admin reviews and exports the audit log

Inferred from technical spec §8 and §13.4.

Admin opens Audit Log section in Web Portal
  → Log displayed with default view (most recent events first)
      → Admin applies filters (EventType / Actor / Target /
        DeviceId / date range / RepresentedPatientId)
          → Filtered results update in place
              → Admin selects an event to view detail (list-detail pattern)
                  → Detail pane shows all SecurityEvent fields
              → OR Admin selects Export
                  → Export format selection
                      *(needs UX writer input — format options e.g. CSV, PDF)*
                  → Export prepared and downloaded

Flow 6 — Patient initiates account deletion

Inferred from technical spec §4.6: right to erasure and full local wipe on account deletion.

Patient navigates to Account settings
  → Selects "Delete my account"
      → Step 1: Explanation of what will be deleted
          (local data, account record, notification preferences)
          *(needs UX writer input — erasure scope description)*
      → Step 2: Irreversibility warning
          *(needs UX writer input — confirmation modal copy)*
      → Step 3: Identity re-verification (OTP or biometric)
          → Verified
              → Deletion initiated
              → Full local wipe executed
              → App returns to unauthenticated launch screen

5.2 State Machines (Mirror of Technical Spec § 3)

SecurityEvent records are write-once and immutable — there is no state machine for the event record itself. The technical spec (§3 enriched note) confirms: "There is no state machine applicable to SecurityEvent itself — events are write-once and immutable by definition." The state machines relevant to this module's UX are the session states and the evidence-clip states, described below.

Session states (all surfaces)

Inferred from technical spec §4.2 and §4.3.

Irreversible transitions (revocation, wipe) must not offer an undo option. The revoked and session-expired states must not allow any app content to be visible or accessible. Inferred from technical spec §13.2 rules 3 and 4.

Evidence-clip states (authorised reviewers, web portal)

Inferred from technical spec §4.7 and §9. Visible only to authorised reviewers.

5.3 Empty / Loading / Error / Offline States

Audit log (web portal)

• Empty state: Should not occur in normal production use. If shown (e.g. on a brand-new tenant before any logins), display a message indicating when audit logging began, not an invitation to take action. Inferred from the append-only, always-on nature of audit logging in technical spec §8. (needs UX writer input — exact message)
• Loading state: Skeleton rows in the log list while the initial query runs. Filters remain interactive during load. Inferred from the paginated, filterable nature of the log implied by technical spec §13.4.
• Error state: If the audit log cannot be retrieved, display an inline error with a retry action. Do not display a blank list — distinguish "no results for your filter" from "failed to load." Inferred from the critical compliance function of the audit log.
• Offline state: The audit log requires server connectivity and cannot be used offline. Display a clear offline notice; do not display a stale cached log as if it were current. Inferred from the server-side, append-only nature of audit storage in technical spec §13.1.

Authentication screens (all surfaces)

• Empty state: Not applicable — authentication screens are always pre-populated with the required input type.
• Loading state: Inline loading indicator on the submit control; the input field is disabled while verification is in progress. Inferred from the need to prevent duplicate submissions during OTP verification.
• Error state: Inline error message below the input field. Message must not distinguish between "user not found" and "wrong credential" in ways that assist enumeration. Maximum-attempts lockout shows a distinct screen. Inferred from security best practice implied by technical spec §4.2.
• Offline state: OTP-based authentication requires server connectivity. Display an offline notice and a retry prompt. Biometric unlock of an already-authenticated session may remain available offline (OS keystore). Inferred from technical spec §4.2 and §4.3: "Secure token storage in OS keystore" and "Biometric-protected secure tokens."

Configuration settings (web portal)

• Empty state: All configuration fields have a default value set at platform level; there is no "unconfigured" state visible to the admin. Inferred from technical spec §4.1: "Secure defaults everywhere."
• Loading state: Skeleton form fields while current settings load.
• Error state: If a configuration save fails, display an inline error adjacent to the affected field(s) and do not apply the partial change. Inferred from the need for atomicity in security configuration changes.
• Offline state: Configuration requires server connectivity. Display an offline notice; do not allow local edits that cannot be immediately persisted, as partially-applied security settings could create an inconsistent state. Inferred from technical spec §4.1 and the audit-logging requirement for all config changes in §13.3.

Privacy notice and consent (patient mobile app)

• Empty state: Not applicable — notices are always present.
• Loading state: Full-screen skeleton while notice content loads. The Continue action is disabled until content has fully loaded. Inferred from the non-skippable nature of privacy notices in technical spec §4.6.
• Error state: If notice content cannot be loaded, display a retry option. The patient must not be able to bypass the notice even when offline. Inferred from technical spec §4.6.
• Offline state: Privacy notices should be bundled with the app for resilience, so they are displayable offline. If dynamic content cannot be fetched, display the bundled version. Inferred from the non-skippable requirement in technical spec §4.6.

6. Component Inventory

New components introduced or extended by this module:

• Audit log list — paginated, filterable list of SecurityEvents; appears in the web portal admin area. Supports filter controls for EventType, Actor, Target, DeviceId, date range, and RepresentedPatientId. Inferred from technical spec §13.4.
• Audit event detail pane — read-only display of all fields for a selected SecurityEvent, including payload fields (e.g. SessionId, ApprovedBy, ExpiresAt for SupportSession events). Inferred from technical spec §3.1 and §3.2.
• Session-ended / wipe screen — full-screen, non-dismissible screen displayed on shared tablets after auto-logout and data wipe; can only be exited by initiating a new authenticated session. Inferred from technical spec §4.3 and §13.2 rule 4.
• Fast-login panel — authentication control for shared tablets supporting badge scan, PIN entry, and QR code scan modes. Inferred from technical spec §4.3.
• Privacy notice viewer — full-screen, non-skippable notice display with explicit acknowledgement action; used in patient first-use flow. Inferred from technical spec §4.6.
• Consent capture screen — structured consent flow with explicit opt-in controls; used where regulation requires consent capture. Inferred from technical spec §4.6.
• Security configuration form group — grouped form layout for each configuration domain (authentication methods, session timeouts, notification privacy, retention policies, device behaviour); appears in the web portal admin settings. Inferred from technical spec §13.3.
• AI-actor badge — visual indicator applied to audit log entries where actor_type is AI, to distinguish AI-generated events from user-generated events. Inferred from technical spec §13.1 actor_type field and §7 AI auditability requirement.
• Delegation indicator — visual treatment applied to audit log entries where represented_patient_id is populated, surfacing that the action was taken on behalf of a different patient under a named delegation role. Inferred from technical spec §3.1 RepresentedPatientId and DelegationRole fields.

Reused from the design system:

• OTP input field — used in patient passwordless login and account-deletion re-verification flows.
• Toast notification — used to confirm successful configuration saves and export initiation.
• Confirmation modal — used for irreversible actions (session revocation, account deletion, access revocation).
• Inline error message — used on authentication and configuration form errors.
• Skeleton loader — used on audit log list and configuration form loading states.
• Filter bar — used on the audit log list for EventType, date range, and other filter dimensions.

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, monospace usage to be defined by design system team)
• Colour: Semantic colour usage must include a distinct treatment for: AI-actor events in the audit log (to distinguish from User and System events); revoked/expired session states (error/warning semantic colour); read-only audit data vs editable configuration fields; evidence-clip expired state. Specific colour values are for the design system to define. Inferred from technical spec §3.1 actor_type, §4.3 session states, and §4.7 evidence-clip states.
• Iconography: Icon set, sizing, and labelling to be defined by the design system. Icons must never appear without a visible label.
• Motion: Transition usage and animation constraints to be defined by the design system. prefers-reduced-motion must be respected throughout.
• Sensitive-screen visual treatment: Screens displaying PHI must not visually signal their content in the OS app switcher. No specific visual design is required here — the control is OS-level (app-switcher content masking); the design implication is that the app must provide a neutral placeholder view for the switcher. Inferred from technical spec §4.3 and §13.2 rule 6.

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
• Privacy notices and consent flows must meet accessibility requirements so that patients cannot be excluded from consent capture due to assistive technology incompatibility. Inferred from technical spec §14 accessibility requirement: "Privacy notices, consent flows, and notification privacy controls MUST meet WCAG 2.1 AA."
• The fast-login panel on shared tablets must support touch targets ≥48 px to accommodate gloved clinical use, exceeding the standard 44 px minimum. Inferred from the clinical and decontamination environment described in technical spec §5.2.
• The OTP input field must be compatible with password-manager and SMS autofill on iOS and Android, reducing manual input burden. Inferred from the passwordless-first patient authentication model in technical spec §4.2.
• Audit log filter controls must be fully keyboard-navigable and screen-reader-compatible, as practice admins may include staff who rely on assistive technology. Inferred from the admin-facing nature of the audit log in technical spec §13.4.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: required (to be confirmed against supported locale list)
• Audit log timestamps must be displayed in the practice's configured locale and timezone, not UTC, to support accurate inspection and regulatory review. Inferred from the compliance and inspection export requirement in technical spec §8.
• Privacy notices and consent content must be externalisable to support localised versions where patient populations require them. Inferred from technical spec §4.6 and UK GDPR requirements for clear and plain-language notices.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Access Manager — the security module's session-revocation and authentication flows are downstream of role and permission changes in Access Manager. When Access Manager triggers a revocation, the Security and Privacy UX must immediately terminate the user's session and display the revoked-session screen. The user is then directed to contact their practice admin; there is no in-app path to self-restore access. Inferred from technical spec §6.2 and §13.2 rule 13.
• Communication Hub — Security and Privacy sends notification-privacy enforcement signals to Communication Hub. The UX implication is that notification content shown on lock screens and in notification previews is governed by this module's controls, not by Communication Hub's content decisions. Users configuring notification privacy do so within Security and Privacy settings, not within Communication Hub. Inferred from technical spec §6.2 and §4.3.
• Document Hub — when a patient or staff member opens a document, the document viewer is governed by Security and Privacy controls (no local export, no screenshot, access logged). The UX transition is seamless — the user opens a document from Document Hub's UI and encounters the secure viewer without a visible "handoff." Revocation of a time-limited link is surfaced to the user as an access-denied state within the document viewer. Inferred from technical spec §4.4 and §6.2.
• Smart Dashboards — anomaly signals and audit summaries are consumed and presented by Smart Dashboards; Security and Privacy does not own their presentation. Practice admins navigating from Smart Dashboards to investigate an anomaly are taken to the audit log in Security and Privacy settings. The handoff direction is Smart Dashboards → Security and Privacy audit log. Inferred from technical spec §5.5 and §6.2.
• AI Quality Monitor — where AI Quality Monitor triggers an ambient audio inference that results in an evidence clip, the clip appears in the audit log as an EvidenceClipRetained event. Authorised reviewers access the clip from the audit log detail pane; they do not navigate to AI Quality Monitor to do so. The AI actor badge must be applied to all events where actor_type is AI. Inferred from technical spec §4.7, §6.1, and §7.

UX consistency rules:

• The audit log is always read-only on all surfaces. No surface may present audit log data with an edit control. Inferred from technical spec §13.2: "Audit logs MUST be immutable."
• Session-termination events (expiry, revocation, wipe) always replace all content with a dedicated full-screen state. No partial overlays or banners are used for session termination — the interruption must be total. Inferred from technical spec §4.3 and §13.2 rules 3 and 4.
• Configuration changes in the Admin Control Plane always require a confirmation step before being applied. This is consistent across all configuration domains. Inferred from technical spec §13.3: all configuration changes are logged as SecurityEvents, implying a deliberate commit point.

11. Governance & Auditability

• All audit-significant actions shown in the UI include a confirmation step before execution. This applies to: session revocation, access revocation, account deletion, configuration changes. Inferred from technical spec §13.2 and §8.
• Audit log entries visually distinguish actor_type values: User, System, and AI events are rendered with distinct visual treatments (e.g. the AI-actor badge component) so that reviewers can immediately identify who or what performed an action. Inferred from technical spec §3.1 actor_type field and §7.
• Entries where represented_patient_id is populated must surface a delegation indicator showing the delegation role (e.g. Guardian, AuthorisedCarer) so that reviewers can identify delegated actions without needing to open the full event detail. Inferred from technical spec §3.1 RepresentedPatientId and DelegationRole fields.
• Support session events (SupportSessionGranted, SupportSessionExpired) must render the ApprovedBy, ExpiresAt, and SessionId fields prominently in the event detail pane, as these are the fields required to satisfy the Admin Control Plane audit requirement for time-boxed elevated access. Inferred from technical spec §3.2 and §8.
• The audit log export function must produce output suitable for submission to a regulatory inspector. The format and field labelling must map directly to the SecurityEvent canonical data model. Inferred from technical spec §8: "exportable for regulatory inspection." (needs UX writer input — export format options to be agreed with compliance lead)
• The current user's role and active permissions are visible in the header.
• Read-only states are visually distinct from editable states.
• Security configuration screens must display the timestamp and actor of the most recent change to each configuration setting, sourced from the audit log. This makes governance of configuration changes directly visible to admins without requiring them to search the full audit log. Inferred from technical spec §13.3: all configuration changes are logged as SecurityEvents.

12. Notification & Communication Patterns

Security and Privacy does not originate content notifications. Its notification-related role is to enforce privacy controls on notifications originated by other modules. The following patterns apply to security-state events that do require user attention:

• Full-screen interrupt (not a banner or toast) — used for session expiry requiring re-authentication, session revocation, and shared-tablet session end. These are not dismissible without completing the required action. Inferred from technical spec §4.3 and §13.2 rules 3 and 4.
• Toast — used to confirm successful completion of admin configuration saves and audit log exports. Inferred from the low-urgency, confirmatory nature of these outcomes following deliberate admin actions in technical spec §13.3.
• Inline error — used for authentication failures (not toasts, to avoid confusion with success patterns). Inferred from standard authentication UX best practice aligned with technical spec §4.2.
• In-app banner — not used by this module for security events. Security state changes are either silent (enforcement happens in the background) or require a full-screen interrupt. A banner would imply the user can continue their current task, which is not appropriate for authentication or revocation events. Inferred from the "security is silent until it must speak" principle and technical spec §4.1.
• Push notifications — Security and Privacy sends enforcement signals to Communication Hub (technical spec §6.2). It does not originate push notification content. Any push notifications relating to security events (e.g. a patient being notified that their session was accessed from a new device) would be originated and delivered via Communication Hub, not directly by this module. Inferred from technical spec §1 and §2.2.
• Email/SMS — same as push notifications: this module does not originate email or SMS. Inferred from technical spec §2.2: "Orchestrate messaging or notification content — owned by Communication Hub."
• Notification privacy enforcement — on patient and staff personal devices, this module ensures that notification previews on the lock screen and in the notification shade contain no PHI. The control is silent; users are not notified when it activates. Users who wish to change notification privacy defaults can do so in the Security and Privacy settings. Inferred from technical spec §4.3 and §4.6.

13. Open Questions

The following questions must be resolved before this UX specification is promoted from draft to published. Questions marked with (from technical spec) originate in the technical spec's own open questions (§15) and have UX implications; they are reproduced here for completeness.

1. (from technical spec) Audit log retention period — The default retention period and any regulatory minimum or maximum are undefined. The UX implication is that the retention configuration UI cannot be finalised (valid range, default display value, warning thresholds) until this is resolved.
2. (from technical spec) Saved audit log views — The set of required saved filter views for practice admin and inspector use cases is undefined. This directly affects the audit log component design — whether saved views are a first-class feature or out of scope for MVP.
3. (from technical spec) Anomaly monitoring — Whether anomaly detection is in scope for this module or deferred is unresolved. If in scope, it requires new UI surfaces (anomaly alert patterns, anomaly detail views) not covered by this spec.
4. (from technical spec) Fast-login mechanisms on shared tablets — Badge, PIN, and QR are all listed as options. Which are mandatory at MVP determines which input modes the fast-login panel component must support at launch.
5. (from technical spec) Right to erasure vs immutable audit logs — The tension between GDPR right to erasure and the requirement for immutable audit records is unresolved. The UX implication is significant: if a patient requests erasure and their identity appears as a Target in SecurityEvents, what does the admin UI show in those records after erasure is processed? This must be resolved before the account-deletion flow and audit log display can be finalised.
6. Session-expiry warning — The UX spec notes that it is undefined whether a countdown warning is shown before session expiry or whether expiry is silent (followed immediately by a re-authentication challenge). This decision affects the session state machine UI treatment and should be resolved with the design and product team.
7. Staff App Mode activation gesture — The gesture type and its discoverability mechanism for authorised staff have not been defined. This is a critical UX decision with security implications (too discoverable = security risk; too obscure = operational friction).
8. Audit export formats — The formats required for regulatory export (e.g. CSV, structured JSON, PDF) have not been specified. The format affects the export UI design and must be agreed with the compliance lead.
9. Involuntary session revocation messaging — The copy shown to a user whose session has been revoked by an admin (e.g. on departure or role change) has not been authored. This is a sensitive moment that requires careful copywriting.
10. Evidence-clip access UI — The precise entry point and access flow for authorised reviewers to access retained evidence clips from the audit log has not been designed. This requires collaboration between the Security and Privacy, AI Quality Monitor, and design teams.