Recall & Reconnect – UX specification

Related technical authority: Recall & Reconnect – Technical Specification

1. Purpose

This UX specification governs the user-facing experience of Recall & Reconnect, Primoro's care-continuity automation module. It defines how practice staff monitor, act on, and trust the automated recall and reconnect system, and how patients receive and respond to recall journeys via the mobile app. The primary roles served are practice administrators and clinical/administrative staff (via the web portal management dashboard) and patients (via the mobile app).

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 — staff see the patient or journey that needs their attention next, not an abstract system-health summary. Patients see a single clear action (book or ask a question) without having to interpret their recall status.
• Governance always visible — every automated outreach action the system has taken is attributable and readable by staff. Trigger reasons, channels used, and sub-state transitions are never hidden behind a summary count.
• No dead toggles — configuration controls for recall intervals, inactivity thresholds, escalation caps, and fallback channels are only shown to roles that can act on them. Controls that are disabled by platform policy are explained, not silently greyed out.
• Calm by default — recall is a routine care function, not an emergency. The interface reserves high-attention treatments (banners, badges) for genuinely stalled journeys and patients who need personal follow-up. Healthy, progressing journeys are visually quiet.
• Progressive disclosure — the dashboard leads with population-level state counts; per-patient journey detail (channel history, audit trail, trigger reason) is one click away, not always on screen.
• Automation transparency — because the technical spec §6.1 requires the dashboard to surface trigger reason, last message sent, channel used, next scheduled action, and whether automation is active/paused/completed for every patient journey, the UX must make automation legible at a glance without requiring staff to infer state from message threads.
• Relationship-led tone — the technical spec §1 explicitly states a "calm, relationship-led healthcare tone" and §5.2 requires "no guilt or urgency language" in patient-facing outreach; this principle extends to the staff UI, which should frame recall as care stewardship rather than a performance metric.

3. Design philosophy

The technical spec §7 confirms that Recall & Reconnect is a fully deterministic, rules-based module with no AI inference. The design must therefore reflect a system that staff can read and trust as mechanically predictable — not a black box. The mental model to embody is a shared work queue where the system does the routine work automatically and hands off clearly when it cannot proceed.

Empty states: A newly activated practice has no recall population yet. The dashboard empty state should communicate that the system is ready and listening for appointment events, not that something has gone wrong. (needs UX writer input — empty-state heading and supporting copy)

Error states: Because all state transitions are atomic and auditable (technical spec §3.2), error states are surfaced as paused or failed journeys with an explicit reason, never as silent gaps in the population list.

AI suggestions: There are no AI suggestions in this module. The system makes no inferences; it applies configuration. The UI must never imply AI judgement is involved in eligibility or outreach decisions.

Multi-step flows: Staff-initiated actions that affect a patient journey (manual pause, exit, or re-enrolment) are consequential and require a confirmation step. The technical spec §9 notes that MFA requirements for sensitive operations are governed by User & Access / Preferences, so the confirmation pattern for these actions must accommodate a possible MFA challenge without breaking the flow.

Undo/redo: Because the technical spec §3.1 defines the audit trail as immutable and §13.4 prohibits record deletion, there is no undo for state mutations. The UI must make the consequences of an action legible before the user commits, not offer reversal after.

Read-only vs editable surfaces: The management dashboard is predominantly read-only. Staff can trigger a small set of governed actions (manual pause, exit, re-enrolment, task ownership). Template creation and channel configuration are not available here; those surfaces are owned by Patient Outreach Manager and Admin Control Plane respectively.

4. Primary surfaces

4.1 Web portal

Who uses it: Practice administrators, clinical leads, and administrative staff with recall visibility permissions. (needs UX writer input — role labels as they appear in the product UI)

Key tasks performed here:

• View the recall population breakdown segmented by state (Due / Overdue / Inactive), inferred from technical spec §6.1 dashboard requirements and §13.4 filter definitions.
• Monitor live journey sub-state per patient (Notified / Viewed / Engaged / Booked / Needs Personal Follow-up), inferred from technical spec §6.1.
• Identify and act on patients in the Needs Personal Follow-up state, inferred from technical spec §6.1 staff hand-off requirements.
• Review automation health: active journeys, paused journeys, failures, and escalation cap breaches, inferred from technical spec §6.1 and §14 observability requirements.
• Understand why automation has handed off to staff for each individual patient, inferred from technical spec §6.1: "staff must never need to infer state by reading message threads alone".
• Manually pause, exit, or initiate re-enrolment for a patient journey (authorised staff only), inferred from technical spec §9 access control.
• Access the full audit trail for a patient journey, inferred from technical spec §8 and §6.1.
• Apply filters by recall state, outreach sub-state, trigger reason, automation status, journey origin, and date range, inferred from technical spec §13.4.
• Use saved default views ("Needs Follow-up Today", "Stalled Journeys") without manual filter configuration, inferred from technical spec §13.4.

Layout pattern: Dashboard + list-detail. The primary view is a population-level dashboard with state-count summaries; selecting a segment or a patient record opens a detail panel showing the full journey state, automation timeline, and available actions. This is inferred from the technical spec's requirement in §6.1 to surface both population-level and per-patient information.

4.2 Tablet app

The technical spec §6.2 explicitly states that Recall & Reconnect does not expose a primary authoring surface on the in-practice tablet. Recall state and hand-off work items are accessed via the web portal dashboard. No dedicated tablet surface is defined for this module.

Staff who receive a Needs Personal Follow-up work item created by this module will action it via Task Manager, which may have its own tablet surface. That surface is out of scope for this specification.

4.3 Mobile app (patient)

Who uses it: Patients receiving recall or reconnect outreach. Inferred from technical spec §5.2 and §6.3, which define the patient mobile app as the primary delivery channel.

Key tasks performed here:

• Receive and open a recall or reconnect push notification deep-linking into a contextual in-app message, inferred from technical spec §5.2.
• Take the primary action — Book — initiating a booking flow via Appointment Manager, inferred from technical spec §6.3 and integration contract §10.2.
• Take the secondary action — Ask a question — advancing sub-state to Engaged and halting further escalation, inferred from technical spec §6.3 and §5.4.
• View a contextual in-app message with a clear recall or reconnect reason and a single, unambiguous call to action, inferred from technical spec §5.2 and §6.3.

The patient mobile surface is delivery-only for this module; patients do not manage their recall record, view their recall state, or configure preferences here. Channel preferences and opt-out are managed via User & Access / Preferences.

No promotional or campaign content is surfaced through these journeys, per technical spec §6.3 and §2.2.

5. Interaction model

5.1 Primary flows

Flow 1 — Automated recall journey (patient path)

Inferred from technical spec §3.2 state machine, §4.1 trigger model, §5.2 channel strategy, and §13.2 core behaviour rules.

1. System evaluates patient recall eligibility
   ├─ State: Not Due → no action; patient remains in Not Due
   └─ State: Due or Overdue → journey enrolment begins

2. Enrolment event published to shared event bus
   (Campaign Manager applies equivalent suppression on its side)

3. Check: Is Care Plan entitlement Not Yet Available?
   ├─ Yes → trigger suppressed; patient remains Not Due until entitlement unlocks
   └─ No → proceed to outreach initiation

4. Check: User & Access / Preferences — consent and channel preferences
   ├─ Consent absent or all channels opted out → journey pauses; no outreach
   └─ Consent present → proceed

5. Patient Outreach Manager delivers push notification to mobile app
   Sub-state advances to: Notified

6. Patient opens in-app message (without booking)
   Sub-state advances to: Viewed
   Escalation timer starts

7a. Patient books appointment
    → Appointment Manager initiates booking flow
    → Journey exits; terminal state: Booked
    → Loyalty Insights outcome event emitted (if handoff origin)
    → Rewards Manager recall compliance event emitted

7b. Patient replies or sends a message
    → Communication Hub routes reply signal to this module
    → Sub-state advances to: Engaged; escalation halts
    → Staff review; journey may exit or continue

7c. Engagement window elapses without booking or reply
    → Fallback to SMS (if enabled and not opted out)
    → If still no engagement, fallback to Email (if enabled)
    → If all channels exhausted or at escalation cap:
       Sub-state advances to: Needs Personal Follow-up
       Work item created via Task Manager
       Journey halts; re-enrolment requires manual staff intervention

Flow 2 — Staff dashboard: review and act on a stalled journey

Inferred from technical spec §6.1 staff hand-off requirements and §9 access control.

1. Staff opens web portal dashboard
2. Selects saved view: "Needs Follow-up Today" or "Stalled Journeys"
3. Reviews patient list; each row shows:
   — Patient name
   — Recall state (Due / Overdue / Inactive)
   — Outreach sub-state (current)
   — Trigger reason
   — Last message sent + channel
   — Hand-off reason (why automation stopped)
4. Staff selects a patient record
5. Detail panel opens:
   — Full journey timeline (automated actions + timestamps)
   — Escalation history
   — Care Plan entitlement status at trigger evaluation
   — Available staff actions (governed by role):
       [Pause journey] [Exit journey] [Mark as contacted] [View audit trail]
6. Staff takes an action; confirmation step shown
   — Irreversible actions (Exit journey) display a confirmation modal
     with the consequence stated explicitly
     *(needs UX writer input — confirmation modal copy)*
7. Action recorded in immutable audit trail; dashboard refreshes

Flow 3 — Loyalty Insights handoff journey

Inferred from technical spec §4.4 and §10.1 inbound integration contract, and Loyalty Insights §4.1, which designates Recall & Reconnect as a primary action handoff target and permits handoffs to be initiated from both individual patient views and cohort views.

1. Loyalty Insights emits a disengagement handoff event to the shared event bus
   — Handoff may be patient-level (single disengaged patient) or
     cohort-level (a churn-risk segment identified by Loyalty Insights)
   — Each patient record in a cohort handoff is treated as a distinct
     enrolment event; no bulk journey is created

2. Recall & Reconnect receives the event; JourneyOrigin recorded as
   handoff reference (patient-level or cohort-derived)

3. Journey proceeds identically to Flow 1 from step 3 onwards

4. At terminal state (Booked / Needs Personal Follow-up / journey exit):
   → Outcome event emitted to shared event bus:
     handoff reference + terminal state + timestamp
     (Loyalty Insights consumes this event to close the handoff loop)

5. Dashboard identifies this journey as "Loyalty Insights origin"
   (filter: Journey origin = Loyalty Insights handoff)
   — Cohort-derived journeys display the cohort reference label alongside
     the patient name so staff can identify that multiple patients in the
     list share the same originating churn-risk trigger
   — Patient-level and cohort-derived Loyalty Insights journeys are
     visually grouped under the same "Loyalty Insights origin" filter;
     no separate filter value is created for cohort vs. patient source

Receiving a Loyalty Insights cohort handoff — UX considerations:

When a Loyalty Insights cohort handoff results in multiple simultaneous journey enrolments, the dashboard population list may receive a batch of new "Loyalty Insights origin" journeys at once. The UI must handle this without visual disruption to ongoing journeys. The following rules apply:

• New Loyalty Insights–origin journeys appear in the population list in the same row format as organic journeys; they are not grouped into a separate cohort view within this module.
• The "Journey origin" column (or equivalent indicator in the journey state row) displays a Loyalty Insights attribution label for each affected patient. Cohort-derived journeys also display the cohort reference identifier in the journey detail panel so staff can cross-reference with Loyalty Insights if needed.
• Staff cannot initiate or modify a Loyalty Insights handoff from within this module's UI; the originating Loyalty Insights view is where cohort-level decisions are made. If a staff member needs to review the cohort that generated the handoff, a read-only reference label (not a navigation link, unless the Communication Hub deep-link pattern is confirmed) is displayed. (needs UX writer input — cross-module reference label copy and confirm whether a deep-link into Loyalty Insights is feasible and desirable)
• A churn-risk–driven reconnect journey is functionally identical to an organic reconnect journey from this module's perspective. Staff must not need to apply different actions or interpret different states for it. The only visible difference is the journey origin label.

Flow 4 — Campaign Manager suppression event received mid-journey

Inferred from technical spec §5.3 and §13.2 rule 11, and Campaign Manager §2 ("Suppression is always visible"), which requires that consent exits and system-paused states are distinguishable from one another and cannot be silently continued.

1. Campaign Manager emits one of the following event types:
   a. Suppression event  — patient is suppressed from outreach
      (e.g. active campaign conflict, frequency cap reached)
   b. Consent-revocation event — patient has withdrawn consent

2. System evaluates active Recall/Reconnect journeys for affected patient

3a. Suppression event received:
    → Journey paused immediately
    → Automation status set to: Paused (System — Campaign Manager)
    → Reason recorded in immutable audit trail with attribution:
      "Paused by Campaign Manager suppression — [suppression type]"
    → Journey may be automatically resumed if suppression is lifted,
      subject to re-evaluation of eligibility at that point

3b. Consent-revocation event received:
    → Journey exited immediately; no further outreach
    → Automation status set to: Exited (Consent revoked — Campaign Manager)
    → Reason recorded in immutable audit trail with attribution:
      "Exited: consent revoked via Campaign Manager"
    → Re-enrolment requires consent to be re-established via
      User & Access / Preferences; no manual re-enrolment path is
      available in this module while consent is absent

4. Dashboard reflects updated automation status (Paused / Exited)
   with reason visible in journey detail panel

5. Staff viewing the journey detail panel see:
   — Automation status label: "Paused — system (Campaign Manager)"
     or "Exited — consent revoked (Campaign Manager)"
   — These labels are visually distinct from:
       • "Paused — staff [name]" (manually paused by a staff member)
       • "Paused — consent absent" (no consent at initial enrolment)
       • "Failed" (automation failure unrelated to suppression)
   — The distinction is achieved through a combination of the
     automation status label text and a secondary attribution tag;
     colour alone must not be the sole differentiator (accessibility)

Distinguishing suppression pause from manual pause — visual treatment:

The automation status indicator (see §5.2 and §6) MUST visually distinguish the following pause/exit causes so that staff do not misread a system-governed pause as a staff-initiated one or vice versa:

The attribution label text for Campaign Manager–sourced pauses and exits must be agreed with the UX writer. (needs UX writer input — attribution label copy per suppression type) The attribution must be unambiguous; staff must not need to consult Campaign Manager to understand why a journey paused or exited.

5.2 State machines (mirror of technical spec §3)

Visual treatments inferred from the deterministic state machine defined in technical spec §3.2 and the operational dashboard requirements in §6.1.

Primary recall states and their UI treatments:

Outreach sub-states and their UI treatments:

The Needs Personal Follow-up sub-state must receive the highest visual distinction of any sub-state, because the technical spec §13.2 rule 9 requires that automation has fully halted and a human must act. It must not be styled with the same treatment as a routine in-progress state.

Entry conditions visible before transitions:

• Before a staff-initiated action (pause, exit, re-enrolment), the UI must display the current state and the trigger reason so the staff member is acting with full context, inferred from technical spec §6.1 automation transparency requirement.
• The Care Plan entitlement status at trigger evaluation must be visible in the journey detail panel, inferred from technical spec §8 audit requirements and §13.1 data model field care_plan_entitlement_status.

Confirmation pattern for irreversible transitions:

• Exit journey and re-enrolment actions are irreversible or require material state change (technical spec §13.2 rules 9–10); these must be gated behind a confirmation modal that states the consequence explicitly before the action is committed. (needs UX writer input — modal copy for each irreversible action)
• Pause journey is recoverable but audit-significant; a single confirmation step is required with the reason for pausing. (needs UX writer input — pause confirmation copy)

Automation status indicator:

• Each journey in the dashboard must display an automation status label (Active / Paused / Completed / Failed), inferred from technical spec §13.4 filter definitions. This is separate from the outreach sub-state and must be visually distinct from it.
• The automation status label must also encode the pause/exit cause (staff-initiated, Campaign Manager suppression, consent absent/revoked) as described in §5.1 Flow 4. This is additional information within the same indicator component, not a separate component.

5.3 Empty / loading / error / offline states

Dashboard — population view:

• Empty state: Displayed when the practice has no patients yet in a Due, Overdue, or Inactive state — e.g. immediately after activation. Must indicate the system is operational and listening, not that something is wrong. (needs UX writer input — empty state copy)
• Loading state: Skeleton rows representing the population list while data loads. Inferred from the technical spec §14 requirement that the dashboard reflects current state without manual refresh, implying data is fetched on load.
• Error state: If the dashboard fails to load population data, display an error with a retry action. The error must not show raw system errors; it must indicate whether the issue is transient. (needs UX writer input — error message copy)
• Offline state: The management dashboard is a web portal surface; full offline operation is not expected. A banner should indicate connectivity loss and that data shown may not reflect the latest state. Read-only viewing of cached data may be supported if technically feasible; no state mutations are permitted offline.

Patient journey detail panel:

• Empty state: Not applicable; the detail panel is only opened from an existing journey record.
• Loading state: Skeleton representing the journey timeline while audit trail data loads.
• Error state: If audit trail data cannot be loaded, display the last-known state with an explicit notice that the full history is temporarily unavailable, plus a retry action. (needs UX writer input)
• Offline state: As per dashboard — mutations disabled; read-only view of cached record if available.

Patient mobile app — in-app recall message:

• Empty state: Not applicable; the in-app message is only shown when a journey has delivered an outreach event.
• Loading state: The in-app message is deep-linked from a push notification; if the app is loading, a brief loading indicator is appropriate before the message content renders. Inferred from technical spec §5.2 push notification deep-link requirement.
• Error state: If the booking flow cannot be initiated (Appointment Manager unavailable), the Book action must fail gracefully with a message directing the patient to contact the practice. (needs UX writer input — error copy for failed booking initiation)
• Offline state: If the patient is offline when opening the push notification, the in-app message may not load. The app should display a connectivity notice and retry automatically when connectivity is restored. The Ask a question path should also be disabled with an explanatory message when offline.

6. Component inventory

New components introduced by this module:

• Recall population summary panel — displays count of patients by recall state (Due / Overdue / Inactive) with drill-down into filtered list. Appears at the top of the web portal management dashboard. Inferred from technical spec §6.1.
• Journey state row — a single patient's recall record as it appears in the dashboard list: patient identifier, recall state badge, outreach sub-state, trigger reason, last action, automation status (including pause/exit cause attribution), and hand-off reason if applicable. Inferred from technical spec §6.1 and §13.4.
• Journey detail panel — slide-in or split-pane panel showing the full automated timeline for a selected patient journey: each state transition, actor (system/staff/role), channel used, timestamp, and available staff actions. Inferred from technical spec §6.1 and §3.1 audit trail requirements.
• Automation status indicator — a compact label/badge showing Active / Paused / Completed / Failed for a journey, including the cause and attribution of any pause or exit (staff-initiated, Campaign Manager suppression, consent absent/revoked). Visually distinct from the outreach sub-state badge. Inferred from technical spec §13.4 filter definitions and Campaign Manager §2 suppression visibility requirements.
• Needs Personal Follow-up work item card — appears in the "Needs Follow-up Today" saved view; surfaces the patient, hand-off reason, and the primary staff action. Inferred from technical spec §6.1 and §13.4.
• Recall in-app message — patient-facing full-screen or card-style message delivered via push notification deep-link; contains a contextual recall reason, primary Book action, and secondary Ask a question action. No promotional content. Inferred from technical spec §5.2 and §6.3.
• Journey action confirmation modal — used for irreversible or audit-significant staff actions (exit journey, pause journey, manual re-enrolment). Displays current state, consequence, and requires explicit confirmation. Inferred from technical spec §13.2 rules 9–10 and §9 MFA note.
• Journey origin label — a compact attribution tag displayed on the journey state row and within the journey detail panel, indicating whether a journey originated from an organic recall trigger, a Loyalty Insights patient-level handoff, or a Loyalty Insights cohort handoff. Includes the cohort reference identifier where applicable. Inferred from technical spec §13.4 filter definitions and Loyalty Insights §4.1 handoff contract.

Reused from the design system:

• Standard data table / list component (for population list)
• Filter bar (recall state, sub-state, trigger reason, automation status, date range)
• Saved views / tab strip (Needs Follow-up Today, Stalled Journeys)
• Confirmation modal / dialog
• Toast notification (for successful staff actions)
• In-app banner (for connectivity loss, suppression events surfaced to staff)
• Skeleton loader
• Badge / status chip
• Push notification (patient mobile — rendered by OS; content assembled by Patient Outreach Manager)

7. Visual design notes

• Typography: (needs UX writer input — heading scale, body scale; no specific values inferred from the technical spec)
• Colour: Semantic colour usage is required to distinguish recall states and sub-states. At minimum, the following semantic distinctions are required, inferred from the state machine in technical spec §3.2: Needs Personal Follow-up must be visually distinct from all progressing sub-states; Booked (terminal success) requires a success treatment; Overdue warrants higher visual weight than Due. Pause and exit cause attributions (staff-initiated vs. system/Campaign Manager vs. consent-related) must also be semantically distinguishable; colour alone must not be the sole differentiator (see §8 accessibility). Specific colour values are deferred to the design system. (needs UX writer input — specific colour tokens)
• Iconography: Icons must never appear without a text label on the management dashboard, because staff must be able to identify state at a glance in clinical settings. Inferred from the "governance always visible" principle and the density of state information in §6.1. (needs UX writer input — icon set selection)
• Motion: The management dashboard must not use decorative animation on state badges or row highlights; this is a care-continuity operational tool. Transitions that reflect a real-time state update (e.g. a journey moving from Notified to Viewed while the dashboard is open) should be subtle and non-disruptive, consistent with the "calm by default" principle. (needs UX writer input — specific transition values)

8. Accessibility & inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large)
• All interactive controls reachable via keyboard
• Focus states visible
• Form fields have programmatic labels
• ARIA used only where native semantics are insufficient
• Touch targets ≥44×44 px on mobile/tablet
• Motion can be reduced via prefers-reduced-motion
• Screen reader tested on NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android)

Module-specific accessibility notes:

• The journey state row contains multiple status values (recall state, outreach sub-state, automation status, trigger reason) in a single row. Screen reader reading order and ARIA labelling for this component requires careful authoring to avoid an incomprehensible string of values. Each status value must have a semantic label that gives it context, not just the value alone. Inferred from the information density required by technical spec §6.1 and §13.4.
• The automation status indicator now encodes pause/exit cause attribution in addition to the basic Active / Paused / Completed / Failed value. The ARIA label for this component must convey both the status and its cause (e.g. "Paused — Campaign Manager suppression") so that screen reader users receive the same governance information as sighted users.
• The patient-facing in-app recall message must present the Book and Ask a question actions as clearly labelled buttons, not icon-only tappable areas, and must meet the ≥44×44 px touch target requirement. Inferred from technical spec §6.3 and §5.2.
• The journey action confirmation modal, which may trigger an MFA challenge (technical spec §9), must manage focus correctly — focus must move into the modal on open and return to the triggering element on close or cancel.

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; to be confirmed by product owner (needs UX writer input — confirm RTL requirement)
• Recall interval and inactivity threshold values configured by the practice (technical spec §13.3) must be displayed with locale-appropriate unit labels (e.g. days, weeks, months). Inferred from the configuration surface definitions in technical spec §13.3.
• Dates shown in the journey timeline (enrolled at, last transition at — technical spec §13.1) must be formatted per the authenticated user's locale, not hardcoded to a single format.

10. Cross-module UX touchpoints

All touchpoints inferred from the integration contracts defined in technical spec §10.1 and §10.2.

• Patient Outreach Manager — Recall & Reconnect hands off outreach initiation requests to Patient Outreach Manager; the staff user never configures channel ordering, send times, or templates from within the Recall & Reconnect dashboard. A clear demarcation must exist in the UI: the dashboard shows what the system did (last message sent, channel used, delivery outcome) as read-only information sourced from Patient Outreach Manager delivery confirmations; it does not offer outreach configuration controls. If a staff member needs to modify the approved template library or channel configuration, the UI must signpost where to go. (needs UX writer input — signposting copy and link destination)

• Appointment Manager — When a patient taps Book in the mobile app recall message, the patient is handed off into Appointment Manager's booking flow. The return journey (after booking is confirmed) must close the recall message and reflect the Booked terminal state. The handoff must feel seamless; the patient should not need to navigate back manually. When a booking event is received by Recall & Reconnect from Appointment Manager, the dashboard must update the journey to terminal state Booked without requiring a manual refresh, per technical spec §14 and §13.2 rule 7.

• Care Plan Subscriptions — The journey detail panel must display the Care Plan entitlement status that was recorded at the time of trigger evaluation (technical spec §13.1 field care_plan_entitlement_status). This gives staff visibility of why a recall was suppressed or allowed without needing to consult Care Plan Subscriptions directly. No navigation to Care Plan Subscriptions is required from within this module's UI.

• Loyalty Insights — Journeys originating from a Loyalty Insights handoff are visually distinguished in the dashboard via a "Loyalty Insights origin" indicator (technical spec §13.4 filter: Journey origin). Loyalty Insights may initiate handoffs at both individual patient level and cohort level (Loyalty Insights §4.1); in either case, each resulting journey in this module is represented as a discrete patient journey. Cohort-derived journeys additionally display the cohort reference identifier in the journey detail panel. Staff do not interact directly with Loyalty Insights from within this module; the outcome event is emitted automatically at journey termination so that Loyalty Insights can close the handoff loop. No cross-navigation into Loyalty Insights is required from within this module's UI, though a read-only cohort reference label may be displayed. (needs UX writer input — confirm whether a deep-link back into Loyalty Insights is required for cohort reference labels)

• Campaign Manager — When a Campaign Manager suppression or consent-revocation event pauses or exits a journey, the reason must appear in the journey detail panel's audit timeline with an attribution label indicating the event came from Campaign Manager. The automation status indicator must distinguish a Campaign Manager–driven pause from a staff-initiated pause and from a consent-absent pause (see §5.1 Flow 4 and §6 automation status indicator). Staff must not need to consult Campaign Manager to understand why a journey stopped. No navigation link is required, but the attribution must be unambiguous. (needs UX writer input — attribution label copy per suppression type)

• Task Manager — When automation reaches the Needs Personal Follow-up terminal state, a work item is created in Task Manager (technical spec §10.2). The Recall & Reconnect dashboard surfaces these patients in the "Needs Follow-up Today" saved view. If the practice also uses Task Manager's own UI for work queues, there may be a duplicate view of the same work item; UX consistency rules for work item ownership and status sync between the two surfaces need to be agreed with the Task Manager module owner. (needs UX writer input — cross-module work item deduplication pattern)

• Communication Hub — Inbound patient reply signals are routed via Communication Hub and advance the journey to the Engaged sub-state (technical spec §10.1). The staff dashboard reflects this sub-state transition; staff do not receive or read the reply content within Recall & Reconnect. If a staff member needs to read the reply, they must navigate to Communication Hub. The dashboard should indicate that an inbound reply was received and signpost where to view it. (needs UX writer input — signposting copy)

• Admin Control Plane — Recall interval, inactivity threshold, escalation cap, app engagement window, and fallback channel toggles are configured in Admin Control Plane (technical spec §13.3). These controls do not appear within the Recall & Reconnect dashboard. The dashboard may surface the current configuration values as read-only context (e.g. "Escalation cap: 3 attempts — configured in Settings") with a link to Admin Control Plane for authorised administrators. (needs UX writer input — read-only configuration display pattern and link label)

• User & Access / Preferences — Consent state and channel preferences are enforced at outreach initiation by User & Access / Preferences (technical spec §10.1). If a journey is paused because all channels are opted out, the reason displayed in the dashboard must be intelligible to staff without exposing raw preference data fields. (needs UX writer input — suppression reason display copy)

UX consistency rules:

• Staff action buttons (Pause journey, Exit journey, Manual re-enrolment) must be consistently placed in the journey detail panel, not in the population list row, to prevent accidental activation when scanning the list. Inferred from the "governance always visible" and "no dead toggles" principles applied to the information density of technical spec §6.1.
• Automation attribution (system-initiated vs staff-initiated) must be visually consistent throughout the journey timeline. Every timeline entry must identify its actor (system / staff name / role) in the same visual position. Inferred from technical spec §3.1 field last_transition_by and §8 audit requirements.
• The read-only audit trail view must be visually distinct from editable or actionable sections of the detail panel.
• Pause and exit attributions sourced from Campaign Manager must use the same visual attribution pattern as other system-sourced events in the timeline; they must not be styled differently merely because they originate from an external module. Consistency of the attribution pattern across all system actors (this module, Campaign Manager, User & Access / Preferences) is essential so staff can scan the timeline without learning module-specific visual conventions.

11. Governance & auditability

All governance behaviours below are inferred from technical spec §8 audit requirements, §3.1 immutable audit trail, §7 AI boundaries, and §9 access control.

• No AI in this module: The system applies deterministic rules only. The UI must never imply AI judgement. There are no AI suggestion treatments (dotted borders, AI badges) in this module. If a future version introduces AI elements, this section must be revised.
• Automation attribution: Every action in the journey timeline is attributed to an actor: system, a named staff user, or a role. This attribution is rendered visibly in the timeline, not only in an export.
• Audit-significant actions require confirmation: Staff actions that mutate journey state (pause, exit, re-enrolment) are audit-significant and require a confirmation step. The confirmation modal must state what will be recorded in the audit trail. (needs UX writer input — confirmation modal copy per action type)
• Immutable audit trail accessible to authorised staff: The full audit trail for a patient journey must be viewable from the journey detail panel by staff with appropriate permissions. The trail must be presented in chronological order with timestamps, actor, action, and reason. It must be clearly read-only; no edit or delete controls appear.
• Audit log export: The technical spec §8 requires audit logs to be "immutable and exportable for inspection." The UI must provide an export action (format to be agreed with engineering) accessible to compliance-authorised users from within the journey detail panel or a dedicated audit section. (needs UX writer input — export CTA label and format options)
• Suppression and consent events in the timeline: When a journey is paused or exited because of a suppression or consent-revocation event from Campaign Manager or User & Access / Preferences, this event must appear in the journey timeline with the originating system identified and the reason legible to staff. The timeline entry must make clear whether the pause was system-driven (Campaign Manager suppression) or consent-driven (revocation via User & Access / Preferences), consistent with the visual distinction requirements in §5.1 Flow 4. Inferred from technical spec §8 and §5.3.
• Care Plan gating decisions in the timeline: Each trigger suppression decision (entitlement Not Yet Available) must appear in the journey timeline with the entitlement status at the time of evaluation. Inferred from technical spec §8 and §13.1.
• Role and permissions visible: The authenticated staff user's role and the permissions that govern which journey actions they can take must be surfaced in the UI — either in a persistent header element or contextually within the action controls. Inferred from technical spec §9 access control and the "governance always visible" principle.
• Read-only states visually distinct: The journey detail panel's audit trail section must be visually distinct from any editable or actionable controls in the same panel — for example, by section separation, background treatment, or an explicit read-only indicator.

12. Notification & communication patterns

All patterns below are inferred from the technical spec's integration contracts (§10), audit event requirements (§8), and channel strategy (§5.2).

In-app banner (web portal — staff-facing):

• Displayed when connectivity is lost, to indicate that dashboard data may not reflect the latest state. Inferred from NFR §14 and the "calm by default" principle — this is the appropriate treatment for a connectivity issue on a read-heavy operational surface.
• May be used to surface a system-level notice if the Patient Outreach Manager delivery pipeline is degraded and active journeys are affected. Inferred from technical spec §14 reliability requirements and the staffs' need for automation transparency.

Toast (web portal — staff-facing):

• Confirmation of successful staff actions: journey paused, journey exited, re-enrolment triggered. A brief, dismissible toast is appropriate for these low-risk confirmations because the action is already reflected in the journey detail panel. Inferred from the "calm by default" principle — a persistent banner would be disproportionate.

Push notification (patient mobile — via Patient Outreach Manager):

• Recall and reconnect outreach is delivered app-first via push notification. Push notifications are NOT sent directly by this module; they are requested via Patient Outreach Manager, which governs delivery, send-time optimisation, and channel escalation (technical spec §5.1 and §10.2). This module emits an outreach initiation request; Patient Outreach Manager sends the push.
• Deep-links into the in-app recall message within the Primoro patient app. Inferred from technical spec §5.2.
• No guilt or urgency language. Inferred from technical spec §5.2.

SMS and Email fallback (patient-facing — via Patient Outreach Manager and Communication Hub):

• SMS and Email are intelligent fallback channels, activated only if app engagement does not occur within the configured window (technical spec §5.2). These are NOT sent directly by this module; they are governed by Patient Outreach Manager's channel escalation rules. This module emits the journey progression signal; Patient Outreach Manager decides delivery.
• Fallback stops immediately on any engagement signal. Inferred from technical spec §5.2 and §5.4.

Email and SMS to staff — not used by this module:

• Staff notifications of Needs Personal Follow-up are surfaced as work items in Task Manager and flagged in the "Needs Follow-up Today" dashboard view. This module does not send email or SMS to staff directly. Inferred from technical spec §10.2 Task Manager integration and §6.1.

13. Open questions

The following questions must be resolved before this spec is promoted from draft to published. Items marked with (from technical spec) are also open in the technical spec and have direct UX implications.

1. (from technical spec §15.1) Escalation attempt cap default: What is the practice-level default for the escalation cap per journey? The UX must display this value in read-only configuration context on the dashboard, and the confirmation modal for a terminal failure must reference it. The default value must be defined before the component can be fully specified.

2. (from technical spec §15.2) App engagement window default: What is the default number of hours or days before SMS fallback is activated? This value is displayed in the read-only configuration section of the dashboard. The default must be defined.

3. (from technical spec §15.3) Inactivity threshold default: What is the default inactivity window that triggers a Reconnect journey? Required for configuration display and for the empty-state copy on the Reconnect segment of the dashboard.

4. "Needs Follow-up Today" definition: The saved view name implies a time-based filter, but the technical spec §13.4 does not define the exact staleness threshold that causes a journey to appear in this view. This must be defined so the view label is accurate and the filtering logic is unambiguous.

5. Work item deduplication with Task Manager: When a Needs Personal Follow-up work item is created via Task Manager and also surfaced in the Recall & Reconnect dashboard, what is the source of truth for ownership and completion status? If a staff member marks the task complete in Task Manager, does the Recall & Reconnect dashboard reflect this? The cross-module UX pattern needs to be agreed with the Task Manager module owner.

6. Communication Hub reply signposting: When a patient reply advances a journey to the Engaged sub-state, the staff dashboard must indicate that a reply was received. Should the dashboard include a direct link to the conversation in Communication Hub, or a passive indicator only? The answer depends on Communication Hub's deep-link API. (needs input from Communication Hub module owner)

7. Audit trail export format: The technical spec §8 requires audit logs to be exportable. The file format (CSV, JSON, PDF) and the triggering UI control need to be defined in collaboration with the compliance and engineering leads.

8. RTL support requirement: The technical spec does not address RTL. Product owner confirmation is needed before the i18n section can be finalised.

9. (from technical spec §15.5) Dashboard performance targets: Specific latency targets for the dashboard query have not been defined. Until they are, the loading state specification (skeleton duration, refresh interval) cannot be fully authored.

10. Patient-facing message content ownership: The technical spec §5.2 confirms no promotional content and no guilt/urgency language, but the exact copy, tone, and contextual variables (e.g. patient name, appointment type, practice name) in the in-app recall message are not defined. These require input from a UX writer and clinical tone review before the mobile surface can be built.

11. Loyalty Insights cohort reference deep-link: When a journey is cohort-derived (Loyalty Insights §4.1), the journey detail panel displays a cohort reference identifier. Whether this identifier should link back into the Loyalty Insights module (e.g. to the originating cohort view) or remain a read-only label requires confirmation from the Loyalty Insights module owner and a review of the available deep-link API. (needs input from Loyalty Insights module owner)

12. Campaign Manager suppression attribution label copy: The automation status indicator and journey timeline must display distinct attribution labels for each suppression/exit cause (Campaign Manager suppression, consent revocation, staff-initiated pause). The exact label text for each variant must be agreed with the UX writer and verified against Campaign Manager's event payload schema to ensure the displayed reason accurately reflects the suppression type. (needs UX writer input and input from Campaign Manager module owner)