Family Profiles – UX Specification

Related Technical Authority: Family Profiles – Technical Specification

1. Purpose

This UX specification governs the experience of creating, managing, and acting within governed family and carer relationships inside Primoro. It covers the staff web portal flows for relationship administration and audit oversight, the patient mobile app flows for invite redemption, delegated session switching, and dependant-context actions, and the tablet app's read-only family-awareness surface. The primary roles served are practice staff (who administer relationships and monitor compliance), guardians and carers (who act on behalf of linked dependants), and, at the point of independence transition, patients themselves.

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
• Delegated context is always explicit — every surface rendering data on behalf of a linked dependant must persistently identify the represented patient; there is no anonymous or ambient delegation. Inferred from technical spec §4.2 and §13.2 rule 8.
• Consent is a first-class UI event — the interface treats consent confirmation as a distinct, visible step, never an implicit side-effect of another action. Inferred from technical spec §4.1 and §13.2 rule 1.
• Revocation is irreversible and immediate — the UI must make the finality of revocation unmistakably clear before the user commits, because the system cannot undo it. Inferred from technical spec §3.2 and §13.2 rule 3 and 6.

3. Design Philosophy

Family Profiles is fundamentally a governance and trust surface, not a convenience feature. The mental model it embodies is: "I am acting on behalf of someone else, and the system always knows who that is." Every design decision should reinforce that the relationship layer exists to enable care — not to blur patient identity. Inferred from technical spec §1.

Empty states: When a practice has no family profiles yet, the staff view presents a clear call-to-action to begin the linking flow rather than an empty table. When a guardian has no linked dependants in the mobile app, the profile switcher is not shown. Inferred from technical spec §5.1 and §5.3.

Error states: Errors arising from failed consent confirmation, invalid invite codes, or revocation conflicts must identify the specific cause and present a concrete resolution step. Vague "something went wrong" states are not acceptable on a governance-critical surface. Inferred from technical spec §4.1 and §13.2.

AI suggestions: When AI surfaces a suggested unlinked dependant to staff, it is presented as a prompt requiring human review — not as a pre-filled action. The suggestion is visually distinguished from staff-initiated actions and carries a clear "suggested by AI" label. Dismissing a suggestion is as prominent as accepting it. Inferred from technical spec §7 and §8.

Multi-step flows: Relationship creation and consent confirmation are multi-step wizard flows, not single-form submissions. Each step has a clear title, progress indicator, and the ability to return to the previous step before the profile is committed. Inferred from technical spec §4.1.

Undo and redo: There is no undo for revocation or immediate-effect permission removal — the UI must communicate this clearly before the user proceeds, using a confirmed destructive action pattern. For non-destructive edits such as member additions or permission adjustments, the user may cancel at any point before submission. Inferred from technical spec §3.2 and §13.2 rules 3 and 6.

Read-only versus editable surfaces: The tablet app is entirely read-only for family context and must be visually distinct from editable staff portal surfaces. Within the staff portal, a profile in Revoked/Archived state is rendered as read-only with all action controls removed. Inferred from technical spec §5.2 and §3.2.

4. Primary Surfaces

4.1 Web Portal

Who uses it: authorised practice staff — typically practice managers, front-of-house administrators, and clinical leads with delegated relationship-management permissions. Inferred from technical spec §5.1 and §9.

Key tasks performed here:

• Initiating a new family profile link (staff-initiated or invite-based). Inferred from technical spec §4.1.
• Reviewing and approving Dentally-assisted link suggestions, where the integration is active. Inferred from technical spec §4.1.
• Modifying an active profile — adding or removing members, adjusting permission sets. Inferred from technical spec §4.2.
• Suspending or revoking a family profile, with confirmation of finality for revocation. Inferred from technical spec §3.2.
• Monitoring pending invite redemptions and following up on overdue items (surfaced via Task Manager). Inferred from technical spec §6.2 and §13.4.
• Reviewing age-based transition events — upcoming, overdue, and completed. Inferred from technical spec §4.3 and §13.4.
• Viewing the full immutable audit log for a profile, filterable by event type, actor, and date range. Inferred from technical spec §8 and §13.4.
• Configuring practice-level settings: permitted roles, default permission sets, invite expiry rules, age-transition threshold, and optional dependant cap. Inferred from technical spec §13.3.
• Reviewing AI-surfaced suggestions for unlinked dependants and recording an accept/dismiss outcome. Inferred from technical spec §7 and §8.

Layout pattern: list-detail for the family profiles index (filterable list on the left, selected profile detail on the right); wizard for creation flows; full-pane for the audit log view. Inferred from technical spec §13.4 and the multi-step creation requirements in §4.1.

4.2 Delegation Rules (Authoritative)

The following rules govern how carer and guardian identity is preserved and displayed across all delegated surfaces. They apply regardless of which downstream module owns the content surface — Aftercare Manager, Appointment Manager, Digital Forms, or any other integrated module operating within a delegated session.

Dual-attribution is mandatory in all delegated aftercare surfaces. Aftercare Manager's carer-context principle (Aftercare Manager spec §2, §2.1, §3.1, and §8) mandates that wherever a carer is the interacting user, the interface MUST surface dual-attribution context: both the patient on whose behalf the carer is acting and the carer's own identity. Family Profiles supplies this context to Aftercare Manager for every delegated session. Accordingly:

• Aftercare instruction screens displayed during a delegated session MUST show both the patient's name and the carer's name in the session header, not the patient name alone. The acting-as indicator (see §6) fulfils the patient-name requirement; a secondary attribution line MUST additionally identify the carer by name (e.g. "Viewing on behalf of [Patient Name] — you are signed in as [Carer Name]").
• Aftercare conversation threads initiated or continued by a carer MUST carry dual-attribution labelling on each carer-authored message: "[Carer Name] on behalf of [Patient Name]". This attribution is passed from Family Profiles' delegation context to Aftercare Manager at the point the thread interaction is initiated and MUST NOT be modifiable by the carer.
• Read receipts, acknowledgement timestamps, and any "instruction viewed" confirmation events recorded during a delegated aftercare session MUST be attributed to the carer acting on behalf of the patient — not to the patient directly. The display of these events in the Aftercare Manager surface and in the Family Profiles audit log MUST reflect this distinction.

Delegation context must not collapse into patient identity. No surface within a delegated session may present the carer's actions as if they were the patient's own unaided actions. This applies to aftercare content delivery, form signing, booking actions, and waitlist interactions alike. The principle is: the patient's identity is always the clinical subject; the carer's identity is always the acting agent. Both are always visible.

Delegated aftercare permissions are gated by the profile's permission set. A carer may only view and interact with aftercare instructions within the scope of the permissions recorded in the active Family Profile. If aftercare access is not included in the permission set, the Aftercare Manager surface MUST present a clear, non-misleading explanation that aftercare is not available in this delegated context — not an empty state that implies no aftercare content exists. Inferred from technical spec §4.2 and the Aftercare Manager integration contract in technical spec §6.2.

Dual-attribution is an audit requirement, not only a display requirement. Attribution data — carer name, patient name, session context, and timestamp — passed to Aftercare Manager MUST also be recorded in the Family Profiles audit log for every delegated aftercare interaction. This ensures that the audit record in Family Profiles is consistent with attribution records held by Aftercare Manager. Inferred from technical spec §8 and Aftercare Manager spec §8.

4.3 Tablet App

Who uses it: clinical staff and receptionists working chair-side or at the front desk who need family-context awareness without executing relationship-management actions. Inferred from technical spec §5.2.

Key tasks performed here:

• Viewing which patients are linked in an active family profile, to understand who has delegated access and in what capacity. Inferred from technical spec §5.2.
• Confirming the responsible party or guardian for a current appointment or form interaction, to route any paper or verbal consent correctly. Inferred from technical spec §5.2 and §4.2.

Touch ergonomics: all tappable elements ≥ 48 × 48 px; information is presented in a glanceable card format suitable for brief reference rather than sustained interaction. The surface is read-only, so no destructive-action confirmation patterns are required. Inferred from technical spec §5.2 and §14 accessibility note.

4.4 Mobile App (Patient / Guardian)

Who uses it: guardians and carers acting on behalf of linked dependants; patients receiving an independence-transition invite. Inferred from technical spec §5.3 and §4.3.

Key tasks performed here:

• Redeeming a one-time invite code issued by the practice, with consent confirmation as the final step before the profile becomes Active. Inferred from technical spec §4.1.
• Switching between the guardian's own patient record and Active linked dependant profiles via a persistent profile switcher. Inferred from technical spec §5.3.
• Viewing and acting on delegated appointment booking, cancellation, and rescheduling for a linked dependant. Inferred from technical spec §4.2.
• Completing and signing Digital Forms on behalf of a dependant, with guardian-signing clearly labelled. Inferred from technical spec §4.2.
• Receiving and responding to Digital Waitlist offers for a linked dependant, within the same engagement lock window as direct patients. Inferred from technical spec §4.2.
• Viewing aftercare instructions in the correct dependant context, within the guardian's permission set, with dual-attribution visible throughout (see §4.2). Inferred from technical spec §4.2 and Aftercare Manager spec §2.
• Receiving the age-transition notification and, where the user is the patient reaching independence, completing the step to create their own independent account. Inferred from technical spec §4.3.

5. Interaction Model

5.1 Primary Flows

Flow 1 — Staff-initiated family profile creation (direct activation)

Inferred from technical spec §4.1 and §3.2.

1. Staff opens Family Profiles in the web portal
2. Staff selects "Create new family profile"
3. Wizard step 1: Search and select the primary account holder patient record
4. Wizard step 2: Add dependant(s) — search and select patient records; assign role and permission set per member
5. Wizard step 3: Confirm consent — staff records that consent has been verified, records method (verbal / written / digital) and timestamp is captured automatically
6. System transitions profile to Active
7. All parties notified via Communication Hub
8. Staff returns to profile detail view showing Active status and full member list

Flow 2 — Staff-initiated family profile creation (invite-based)

Inferred from technical spec §4.1 and §3.2.

1–4. Same as Flow 1 steps 1–4
5. Staff selects "Send invite" instead of direct activation
6. System generates a secure one-time invite code and triggers Communication Hub to deliver it to the guardian
7. Profile is held in Created / Pending state
8. Staff view shows pending invite with redemption status
9. (Flow continues in mobile app — see Flow 3)

Flow 3 — Guardian invite redemption (mobile app)

Inferred from technical spec §4.1, §5.3, and §13.2 rule 1.

1. Guardian receives invite notification (via Communication Hub)
2. Guardian opens Primoro mobile app and is directed to the invite redemption screen
3. Guardian enters or taps the one-time code
4. System validates code (unexpired, not previously redeemed)
5. Guardian reviews relationship summary: who is being linked, in what role, with what permissions
6. Guardian explicitly confirms consent — this is a distinct, required step, not a checkbox buried in terms
7. System transitions profile to Active
8. Profile switcher becomes available in the guardian's app session
9. All parties notified via Communication Hub

Flow 4 — Delegated session: switching context (mobile app)

Inferred from technical spec §5.3 and §4.2, rule 8.

1. Authenticated guardian opens the profile switcher (persistently accessible)
2. Switcher displays own record and all Active linked dependant records
3. Guardian selects a dependant
4. "Acting as [Patient Name]" indicator becomes persistently visible on every screen
5. All actions (booking, forms, aftercare, waitlist) are rendered in the dependant's context
6. Dual-attribution (carer identity alongside patient identity) is surfaced on all aftercare surfaces in accordance with §4.2
7. Guardian may return to their own record at any time via the switcher

Flow 5 — Staff profile suspension or revocation (web portal)

Inferred from technical spec §3.2 and §13.2 rules 3 and 6.

1. Staff opens the target Family Profile in the web portal
2. Staff selects "Suspend" or "Revoke"
3. For Suspension: confirmation modal explains that delegated access is disabled but the profile is retained; staff confirms
4. For Revocation: confirmation modal explicitly states that this action is permanent and cannot be undone; a new profile must be created to restore access; staff must confirm using a deliberate confirmation pattern (*(needs UX writer input — exact label and confirmation microcopy for the irreversible revocation modal)*)
5. System transitions profile state immediately
6. Delegated access is removed in the same transaction
7. All parties notified via Communication Hub
8. Audit log entry created

Flow 6 — Age-based transition (automated, with user touchpoints)

Inferred from technical spec §4.3 and §13.2 rule 9.

1. System detects that a dependant has reached the configured age threshold
2. Communication Hub dispatches notifications to the patient (invitation to create independent account) and the guardian (notification that access will be revoked)
3. Patient completes independent account creation (flow owned by onboarding/account module — out of scope here)
4. Guardian access is revoked automatically at the threshold
5. Transition event recorded in audit log
6. Staff portal surfaces the completed transition in the age-transition view

Flow 7 — AI-assisted unlinked dependant suggestion (web portal)

Inferred from technical spec §7 and §8.

1. AI detects a potential unlinked dependant (e.g. from Dentally responsible-party data)
2. Suggestion appears in staff portal as a distinct AI suggestion card, visually differentiated from staff-initiated actions, with an "AI suggested" label
3. Staff reviews the suggestion and selects "Start linking" (proceeds to Flow 1 or 2) or "Dismiss"
4. Both outcomes are recorded in the audit log

5.2 State Machines (Mirror of Technical Spec § 3.2)

The following state treatments are inferred from the Family Profile state machine in technical spec §3.2.

No profile state transition may be triggered without the acting staff member's identity being confirmed by their authenticated session. Inferred from technical spec §9 and §13.2.

5.3 Empty / Loading / Error / Offline States

The following states are inferred from the surfaces described in technical spec §5 and the reliability requirements in §14.

Web portal — Family Profiles index

• Empty state: No family profiles exist yet for this practice. Display a brief explanation of what family profiles enable and a single primary call-to-action to create the first profile. Inferred from technical spec §5.1 and §1. (needs UX writer input — empty-state headline and supporting copy)
• Loading state: Skeleton list rows while profiles load. Given the 300 ms p95 performance target, a skeleton is preferable to a full-page spinner. Inferred from technical spec §14.
• Error state: If the profile list fails to load, display an inline error with a retry action. Do not show a full-page error for a recoverable network issue. Inferred from technical spec §14 reliability requirement.
• Offline state: The staff web portal requires connectivity for all read and write operations; an offline banner should indicate that changes cannot be saved and the user should not attempt to initiate relationship changes. Inferred from technical spec §14 reliability and §6 synchronous contracts.

Mobile app — Profile switcher

• Empty state: If the authenticated user has no Active linked dependants, the profile switcher is not rendered at all — there is nothing to switch to. Inferred from technical spec §5.3 and the "no dead toggles" principle.
• Loading state: A brief skeleton placeholder within the switcher while delegated session context resolves. The 300 ms p95 requirement means this state should be transient. Inferred from technical spec §14.
• Error state: If context resolution fails, the app must not silently present the user with their own record as if switching succeeded. A clear error message with a retry option is required. Inferred from technical spec §13.2 rule 7 (no cross-patient data leakage).
• Offline state: If the app is offline, the switcher should indicate that switching is unavailable; the user remains in their last resolved context and cannot initiate delegated actions. Inferred from technical spec §14 and the synchronous enforcement requirements in §4.2.

Mobile app — Invite redemption

• Empty/pre-entry state: (needs UX writer input — introductory copy for the invite redemption screen before a code is entered)
• Loading state: Inline loading indicator while the code is being validated against the server. Inferred from technical spec §4.1.
• Error state: Invalid, expired, or already-redeemed codes must produce a specific, actionable error message directing the guardian to contact the practice. Inferred from technical spec §4.1 and open question §15.2.
• Offline state: Code redemption requires connectivity; if offline, the app should prevent submission and explain why. Inferred from technical spec §4.1 and synchronous consent confirmation requirement.

6. Component Inventory

New components introduced by this module:

• Acting-as indicator — a persistent, prominently positioned banner or header element displayed on every screen during a delegated session, showing "You are acting on behalf of [Patient Name]" with the represented patient's name. Must be perceivable without relying on colour alone. On aftercare surfaces, the indicator is supplemented by a secondary attribution line identifying the carer by name, in accordance with the dual-attribution requirement in §4.2. Inferred from technical spec §4.2 and §14 accessibility note, and Aftercare Manager spec §2.
• Profile switcher — a persistent control in the mobile app allowing the authenticated guardian to move between their own record and Active linked dependant profiles. Only rendered when at least one Active linked dependant exists. Inferred from technical spec §5.3.
• Family profile status badge — a visual badge communicating the current state of a Family Profile (Created/Pending, Active, Modified, Suspended, Revoked/Archived). Used in the staff web portal list and detail views. Inferred from technical spec §3.2.
• Relationship member card — a card component displaying a single family member's role, permission set, and member status within a profile. Used in the profile detail view. Inferred from technical spec §3.1.
• AI suggestion card — a visually distinct card used to surface AI-generated unlinked-dependant suggestions to staff. Includes an "AI suggested" label, the suggestion content, and accept/dismiss actions. Inferred from technical spec §7 and §8.
• Consent confirmation step — a dedicated step in the creation wizard that records the guardian's explicit consent, including method selection and timestamp capture. Distinct from a standard checkbox. Inferred from technical spec §4.1 and §13.2 rule 1.
• Irreversible-action confirmation modal — a modal used specifically for destructive, non-undoable actions (profile revocation; immediate access removal). Explicitly communicates permanence and requires deliberate user confirmation. Inferred from technical spec §3.2 and §13.2 rules 3 and 6.
• Audit log viewer — a filterable, paginated read-only table of audit events for a given Family Profile. Filterable by event type, actor, and date range. Inferred from technical spec §8 and §13.4.
• Age-transition tracker — a view within the staff portal listing dependants approaching, at, or past the configured age threshold, with current transition status. Inferred from technical spec §4.3 and §13.4.
• Invite redemption screen — the mobile app screen guiding a guardian through one-time code entry and consent confirmation. Inferred from technical spec §4.1 and §5.3.

Reused from the design system:

• Form fields with programmatic labels
• Wizard / multi-step progress indicator
• Skeleton loading placeholders
• Inline error messages
• Confirmation modal (standard pattern — extended for irreversible-action variant above)
• Filterable data table
• Toast notification component
• In-app banner component

7. Visual Design Notes

• Typography: (defer to design system scale — no module-specific overrides specified)
• Colour — semantic usage: The Family Profile status badge must use the platform's semantic colour palette: amber for Created/Pending and Suspended states (attention required, not an error); green for Active; grey for Revoked/Archived. Error red is reserved for genuine error states, not for the Revoked state, which is a terminal lifecycle state rather than an error condition. The acting-as indicator must not rely on colour alone to communicate delegated context — it must also include explicit textual labelling. Inferred from technical spec §3.2 and §14 accessibility note.
• Iconography: Use the platform icon set at consistent sizing; no icon-only controls without an accompanying label, particularly on governance-critical actions such as revocation.
• Motion: Transitions should be functional, not decorative. No animation on status badge changes or audit log entries — these are governance signals, not celebrations. 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, VoiceOver, and TalkBack
• The acting-as indicator and profile switcher must meet WCAG 2.1 AA standards as a minimum; the indicator must be perceivable without relying on colour alone, using both colour and explicit text to communicate delegated context. Inferred from technical spec §14 accessibility note.
• The dual-attribution line on aftercare surfaces (carer name alongside patient name) must be rendered in a way that is perceivable by assistive technology — it must not be presented as decorative or visually-only text. Inferred from Aftercare Manager spec §2 and §8, and §4.2 of this specification.
• The consent confirmation step must be operable by keyboard and screen reader without loss of meaning or function, given its legal significance. Inferred from technical spec §4.1 and §13.2 rule 1.
• The irreversible-action confirmation modal must ensure that the permanence warning is conveyed to assistive technology, not only through visual styling. Inferred from technical spec §3.2.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: not specified in the technical spec — (needs product decision)
• Patient names and relationship role labels must not be truncated in narrow viewports; the acting-as indicator in particular must remain fully legible when the dependant's name is longer than an average English name. Inferred from technical spec §4.2 rule 8 and internationalisation considerations.
• The dual-attribution line on aftercare surfaces (carer name and patient name) must also be tolerant of long names and string-length growth; the layout must not collapse either name into an ellipsis or otherwise obscure the attribution. Inferred from §4.2 and Aftercare Manager spec §2.1.

10. Cross-Module UX Touchpoints

All touchpoints are inferred from the integration contracts in technical spec §6 and §10.

• Appointment Manager — When a guardian acts on a dependant's behalf to book, cancel, or reschedule, the user is operating within the Appointment Manager booking surface but with the acting-as indicator persistently visible. Delegated waitlist offer cards in the Appointment Manager surface must clearly identify the patient on whose behalf the offer applies. The handoff is contextual: Family Profiles supplies the delegated session context; Appointment Manager owns the scheduling UI. Inferred from technical spec §4.2 and §6.
• Digital Forms — When a guardian completes or signs a form for a dependant, the Digital Forms surface receives the delegated session context and must display the guardian-signing label and the represented patient's name on the form header. Form completion attribution (who signed, on whose behalf, form version, timestamp) is owned by Digital Forms but triggered by Family Profiles delegation context. Inferred from technical spec §4.2 and §6.
• Aftercare Manager — Aftercare content is delivered in the dependant's patient context. The guardian sees aftercare within their delegated session; the acting-as indicator remains visible. In addition, dual-attribution (carer name alongside patient name) MUST be surfaced on all aftercare instruction screens and conversation threads initiated during a delegated session, as required by Aftercare Manager's carer-context principle (Aftercare Manager spec §2, §2.1, §3.1, §8) and by §4.2 of this specification. Aftercare Manager owns the content surface; Family Profiles supplies the delegation context and dual-attribution data for correct routing, permission-gating, and attribution display. Inferred from technical spec §4.2 and §6.2.
• Communication Hub — Family Profiles does not own any notification UI. All invite delivery, transition notifications, revocation notifications, and confirmation messages are triggered by Family Profiles and delivered by Communication Hub. From the guardian's perspective, these arrive through whatever channel Communication Hub is configured to use (push, email, SMS). Inferred from technical spec §6.2 and §11.
• Task Manager — Staff receive Task Manager tasks for pending invite follow-up and age-transition actions. These tasks appear in the Task Manager surface and link back into the Family Profiles staff portal for resolution. Inferred from technical spec §6.2.
• Access Manager — The permission set selector in the relationship creation and modification wizard is populated from Access Manager. If Access Manager is unavailable, the creation wizard must surface a clear error and prevent profile activation rather than silently assigning a default. Inferred from technical spec §6.1 and §9.
• Integrated Payments — Payer attribution for delegated payment actions is emitted to Integrated Payments. No payment UI is owned by Family Profiles; the touchpoint is a data handoff only and should not require the guardian to re-enter payer information already associated with their profile. Inferred from technical spec §6.2 and §11.
• Dentally (PMS) — Where the Dentally-assisted link discovery integration is active, suggested unlinked dependants surface to staff as AI suggestion cards in the staff portal. No Dentally clinical data is shown in these cards — only the suggested relationship and the prompt to review. Inferred from technical spec §4.1 and §6.3.

UX consistency rules:

• The acting-as indicator must appear at the same position across every surface in a delegated session — it must not move between the booking, forms, and aftercare contexts. Inferred from technical spec §4.2 rule 8 and the need for consistent governance visibility.
• Action buttons follow platform conventions for placement (bottom-right on tablet, top-right on web for primary actions).
• Audit-significant actions (consent confirmation, revocation, permission changes) always show a confirmation step regardless of which surface or flow initiates them. Inferred from technical spec §8 and §13.2.

11. Governance & Auditability

The following governance treatments are inferred from technical spec §7, §8, and §9.

• AI suggestions are visually distinct from staff-initiated actions. AI suggestion cards for unlinked dependants use a dedicated visual treatment including an "AI suggested" label. Staff cannot inadvertently act on an AI suggestion without making an explicit choice to do so. Dismissing is as easy as accepting. Inferred from technical spec §7 and §8.
• All audit-significant actions require a confirmation step. These include: profile creation (consent confirmation step), member addition or removal, permission set changes, suspension, and revocation. The confirmation step is not skippable. Inferred from technical spec §8 and §13.2.
• The current user's role and the scope of their permissions are visible in the staff portal header or session context, consistent with platform conventions and the Access Manager integration. Inferred from technical spec §9.
• Read-only states are visually distinct from editable states. Profiles in Revoked/Archived state are rendered in a visually muted, read-only treatment with all action controls removed. The tablet app surface is always read-only and must not present any controls that suggest editability. Inferred from technical spec §3.2 and §5.2.
• The audit log is accessible to authorised staff directly from the profile detail view. It is presented as a read-only, append-only record — the UI must not offer any edit, delete, or reorder controls on audit entries. Inferred from technical spec §8 and §13.2.
• Delegated actions are attributed in the UI. Where a guardian has completed a form or taken a booking action on behalf of a dependant, the attribution ("Submitted by [Guardian Name] on behalf of [Patient Name]") is visible in the relevant record view, consistent with the audit log format. For aftercare interactions specifically, this dual-attribution is additionally required by Aftercare Manager spec §8 and must appear both in the Aftercare Manager surface and in the Family Profiles audit log. Inferred from technical spec §4.2 and §8, and Aftercare Manager spec §8.

12. Notification & Communication Patterns

Family Profiles emits notification triggers to Communication Hub; it does not own notification delivery. The following patterns are inferred from technical spec §6.2 and §4.

• In-app banner: Used to surface the acting-as indicator during a delegated session on the mobile app. This is a persistent, non-dismissable banner — it is a governance signal, not an alert. Also used in the mobile app to indicate that the app is offline and delegated actions are unavailable. Inferred from technical spec §4.2 and §14.
• Toast: Used for non-critical confirmations: successful profile creation, successful consent recorded, successful permission update. Toasts are transient and do not block interaction. Inferred from technical spec §3.2 and the calm-by-default principle.
• Push notification (via Communication Hub — NOT directly): Triggered for: new invite delivery to a guardian; age-transition notification to the patient and guardian; revocation notification to all parties. Family Profiles triggers these events; Communication Hub determines channel and delivers. Inferred from technical spec §4.3 and §6.2.
• Email / SMS (via Communication Hub — NOT directly): Same events as push notification above, with channel selection owned by Communication Hub. The one-time invite code is delivered via Communication Hub using the practice's configured channel preferences. Inferred from technical spec §4.1 and §6.2.

13. Open Questions

The following questions must be resolved before this UX spec is promoted from draft to published. Several are carried directly from open questions in the technical specification.

• MFA step-up for sensitive operations. The technical spec (open question §15.1) does not yet specify whether MFA step-up is required for high-risk staff actions (profile revocation, permission modification). The UX pattern for the confirmation modal depends on this decision — if MFA step-up is required, the modal must incorporate the re-authentication step. Inferred from technical spec §15.1.
• Invite expiry and redemption limits. The technical spec (open question §15.2) does not specify default invite expiry windows or maximum redemption attempts. The error messaging on the invite redemption screen and the staff portal invite-status display both depend on these defaults. Inferred from technical spec §15.2.
• Maximum dependants per guardian. The technical spec (open question §15.3) leaves open whether a default cap ships with MVP. If a cap exists, the profile creation wizard and the profile switcher need to handle the state where a guardian has reached the limit. Inferred from technical spec §15.3.
• Suspended state behaviour and reinstatement. The technical spec (open question §15.4) does not define what delegated access (if any) is permitted during suspension, or who may reinstate a suspended profile. The suspension confirmation modal and the Suspended state visual treatment cannot be finalised until this is resolved. Inferred from technical spec §15.4.
• GDPR erasure and audit log retention in the UI. The technical spec (open question §15.5) does not resolve how the UI should represent audit entries that reference an erased patient. If a patient's data is erased but the audit log entry must be retained, the display of those entries in the audit log viewer requires a defined treatment (e.g. anonymised subject reference). This question extends to dual-attribution entries in the audit log where the erased subject may be either the patient or the carer. Inferred from technical spec §15.5 and §4.2.
• Dual-attribution display when carer name is unavailable. If the carer's name cannot be resolved at the time an aftercare interaction is recorded (e.g. due to a data availability issue), the fallback display treatment for the dual-attribution line on aftercare surfaces and in the audit log is not yet defined. (needs product and UX writer input)
• (needs UX writer input — confirmation of the correct placement and persistent visibility approach for the acting-as indicator across all screen sizes and orientations in the mobile app)
• (needs UX writer input — all microcopy for the consent confirmation step, the irreversible revocation modal, the age-transition notification screens, and the invite redemption flow)
• (needs UX writer input — microcopy for the dual-attribution line on aftercare surfaces, including the secondary carer-identity label and the "on behalf of" phrasing in aftercare conversation thread attribution)