Ripple-effect queue

Surgery & Decon Day View is the primary owner of tablet day-view UX for surgery and decon workflows. Task Manager's removal of segment-based controls and introduction of flat time-ordered layout with header-based prev/next navigation represents a core UX pattern change that must be reflected in this module's specification.

Task Manager's tablet day view change directly impacts how Appointment Manager surfaces appointment data on tablet. The contract governing day-view ordering, real-time feed, and navigation must reflect the removal of time segments and introduction of prev/next day controls.

Lab Manager explicitly exposes day-view lab status visibility on Surgery Tablet and Decon Wall Tablet. The removal of time-segment controls and introduction of flat chronological ordering with prev/next navigation directly affects how lab cases are displayed on these shared tablet surfaces.

Task Manager's calendar now supports role-based multi-calendar overlay with manager-default to all teams. Smart Dashboards explicitly surfaces role-specific content (§13.3 Manager/Operator Dashboard), making this a direct integration point for workforce visibility and operational awareness.

The new flow explicitly creates 'scheduled instances' of work packages on the team calendar with start times and calculated end times. Appointment Manager owns the authoritative calendar and availability model. The scheduled work packages must be represented as first-class entities in Appointment Manager's data model or clearly delineated as a separate entity type to avoid conflicts with Appointment state machine.

Rota Manager explicitly references tablet day-view task display on shared tablets. The shift from segment-based to flat chronological navigation with prev/next controls affects how rota entries and shift awareness are presented alongside task displays.

The Day View surfaces work packages in task lists with visual distinction. The CalendarId field's colour-coding and visibility rules directly affect what appears on the tablet and how it is presented, making the integration necessary.

The change specifies that colour-coding and visibility rules in multi-calendar overlay mode are governed by CalendarId. Smart Dashboards consume and display work signals; they need to understand which Work Packages are visible to the current user based on their role and the package's CalendarId.

The flow assigns work packages to 'the team' and places them on a team calendar. Rota Manager controls staff availability and absence. The scheduling workflow must respect absence overrides, shift patterns, and availability windows; the contract between Task Manager's scheduling and Rota Manager's availability data needs explicit definition.

Rota Manager already owns shift patterns and staff schedules (§3.1–3.2). Task Manager's colour-coded role calendars represent a closely related scheduling surface; staff need visibility of both rota shifts and task calendars together to understand workload and availability overlap.

Work packages are assigned to individuals and roles; Rota Manager defines which staff members hold which roles at any given time. When a Work Package carries a CalendarId tied to a role, the rota determines which staff see it by default. This creates a visibility dependency.

Task Manager's calendar overlay is role and team-centric; Appointment Manager assigns appointments to practitioners and roles. Both surfaces need to show work (appointments and tasks) in a unified, colour-coded team view; alignment ensures no blind spots in capacity planning.

HR & People Manager controls leave requests (Flow 1) and absence changes, which directly affect workforce availability. Task Manager's role-based calendar overlay depends on accurate staff availability data; cascading absence updates ensures calendar accuracy and operational planning consistency.

Smart Dashboards specifies web portal primary surfaces and navigation patterns. Task Manager's new standardised left-hand navigation map must align with or reference the same navigational structure to avoid inconsistent information architecture across staff-facing dashboards.

The change specifies that default visibility is governed by role matching the CalendarId. Communication Hub's role-scoped channels already depend on role definitions; Work Package calendar association may require correlated message routing or channel membership rules.

The workflow is described as the primary scheduling mechanism and intended for managers. Smart Dashboards serves managers with at-a-glance operational visibility. The triage-list backlog (count of unscheduled packages) could be a valuable insight card on the Manager/Operator Dashboard to drive urgency around scheduling.

Communication Hub's web portal surface includes messaging and action routing. If Task Manager navigation is standardised as a top-level menu entry, Communication Hub's UX spec may need to clarify how task-related message-to-work flows navigate to the newly standardised Task Manager interface.

The change explicitly states that CalendarId is 'defined in Access Manager' and that the system maintains one calendar per configured role/team. Access Manager's role architecture is the source of truth for what role/team identities exist in the system, making it a direct dependency.

Task Manager references 'configured role or team' as the unit of calendar grouping. Access Manager owns role architecture (§4.4); a spec sync is needed to ensure Task Manager's role/team definitions are consistent with Access Manager's canonical role catalogue.

Task Manager §2 (Audit is a feature, non-negotiable) requires all state transitions to be explicitly time-stamped and immutable. When Communication Hub converts a message into a task or work item, the resulting task must inherit Task Manager's governance and audit properties. The interaction model should clarify that task creation via message is an explicit, auditable action.

Admin Control Plane manages tenant configuration and entitlements. If Task Manager's navigation map defers certain items to later delivery phases, Admin Control Plane may need to add configuration surfaces to control which navigation items are visible per tenant or deployment stage.

The change explicitly references Staff App Mode § 6.3 'Staff App Mode — Quiet Hours Contract' as the source of rota data for quiet-hours enforcement. Staff App Mode's technical spec must verify that the contract it exposes matches the consumption model Communication Hub now defines, ensuring no divergence in shift interpretation or suppression timing.

Communication Hub spec § 3.2 explicitly states that downstream modules MUST read NotificationMute records and MUST NOT maintain local copies of mute state. Staff App Mode currently uses the session artefact as a potential storage point for user preferences; this clarification requires it to delegate mute state to Communication Hub entirely.

Communication Hub's quiet-hours feature is entirely dependent on Rota Manager shift data (explicitly cited as 'Rota Manager shift data already consumed by Staff App Mode'). The technical spec must confirm the data structure, timing precision, and lunch-break representation meet Communication Hub's requirements for accurate suppression.

Task Manager creates and surfaces tasks across multiple surfaces and flows, many of which involve patient-centric work (e.g. 'Flow 7 — Task created from a Communication Hub thread conversion'). Consistent terminology with Communication Hub's non-negotiable principle prevents terminology fragmentation in task creation, assignment, and display.

Recall & Reconnect manages patient-centric outreach journeys and surfaces patient-related insights in staff dashboards. All user-facing copy must reflect Communication Hub's non-negotiable healthcare domain terminology to maintain consistency in patient communication and staff-facing interfaces.

Digital Forms delivers forms to patients and assigns them through multiple channels. Copy within form context (headers, instructions, notifications) must align with Communication Hub's non-negotiable terminology to maintain consistent patient-centric language across touchpoints.

Smart Dashboards aggregate signals and insights from multiple modules and surface them across role-specific dashboards (FOH, TCO, Manager, Practitioner, Nurse). Patient-related insights, metrics, and action cards must use consistent terminology to align with Communication Hub's non-negotiable principle.

AI Guardian surfaces Findings and alerts that often reference patient data, compliance status, or patient-related risks. Terminology must align with Communication Hub's principle to ensure consistent healthcare domain language in governance and auditability contexts.

Smart Dashboards likely surface notification state or suppress certain alerts based on user mute status. The new first-class mute artefact with immutable audit trail changes how downstream modules query and display mute state; integration contracts must reflect this single source of truth.

The Communication Hub mute is a global, 1-hour, session-level suppression of all notifications, whereas Staff App Mode's quiet hours are a separate boundary mechanism. The specs should clarify whether these can coexist and how their interaction is handled (e.g., does mute override quiet hours or vice versa).

Staff App Mode surfaces Communication Hub threads on mobile. The UX spec should explicitly address whether typing indicators from other staff or patients are visible on the mobile app, and if they adapt to the smaller screen (e.g., abbreviated display).

AI Concierge's § 5.1 Flow B (Staff takeover) involves handing calls to human staff who may then compose replies. If staff reply from within AI Concierge's interface, the reply-method selector placement becomes relevant to ensure consistency with Communication Hub's design decision.

Smart Dashboards consumes real-time alert signals from multiple sources. If Communication Hub and Smart Dashboards both use WebSocket, the typing-indicator transport degradation model (§ Degradation and Fallback) must align with dashboard alert delivery guarantees to avoid conflicting fallback strategies.

Smart Dashboards consume real-time engagement signals from other modules. Typing indicators are transient presence signals that could inform TCO or FOH dashboards about active conversations. The integration contract should clarify whether typing-indicator presence is surfaced as an engagement metric.

Staff App Mode § 5.1 covers communication and message composition on mobile. If mobile staff are composing replies to patients via the Staff App, the reply-method selector placement decision should be consistent with web and tablet surfaces documented in Communication Hub.

Task Manager spec documents multiple event sources and notification contracts. If a user disables notifications for a channel, it's unclear whether tasks originating from or discussed in that channel should honour the channel-level setting or apply independent task notification rules. This needs explicit boundary clarification.

Smart Dashboards spec includes cross-module touchpoints and role-specific content (e.g. staff activity signals). Communication Hub's introduction of per-channel notification defaults and admin-configurable suppression may warrant dashboard visibility for staff awareness, particularly for low-priority channels or suppressed channels.

The change explicitly states: 'Whether a staff member's role permits the 1-hour self-service mute is governed by role configuration in Access Manager.' This is a direct dependency—Access Manager is the authoritative source for role-based permission policies, and must specify the mute permission flag and its enforcement contract.

The technical spec explicitly states that TypingIndicator remains active during AI suggestion prompts and user decision (§ Integration with Message-to-Work Conversion). The Aiden UX spec needs to ensure the suggestion UI does not clear or interfere with the typing indicator state, maintaining visual continuity for other thread participants.

The change explicitly prohibits mute state being modelled as a transient field on the user session. Access Manager owns the Session artefact definition; it must formally document that mute-related fields are out of scope and delegated to Communication Hub's immutable audit model.

Aiden surfaces suggestions across multiple modules and surfaces (web portal, tablet, mobile, website chat). If Communication Hub has established 'patients' as non-negotiable domain terminology, Aiden's copy must be consistent to avoid terminology fragmentation in shared user-facing surfaces and maintain coherent healthcare domain language.

The change states that for roles where 'the practice administrator has restricted mute capability, the snooze control is not rendered'. This implies a role-based access control rule that Access Manager must define or expose. Access Manager's RBAC spec should clarify how this permission is stored and consumed.

The change specifies that roles can be added/removed at the channel level, and all current members of that role are automatically included. This requires Access Manager to provide a queryable interface for role membership and role definitions. Current spec does not explicitly mention this contract with Communication Hub.

The typing-indicator spec defines asymmetric visibility (patients see staff typing; staff do not see patient typing). This is a role-based access control decision that should be explicitly linked to Access Manager's RBAC model to ensure consistency with other visibility rules.

AI Concierge's Call Thread captures live communication state. Typing indicators are real-time composition signals transmitted via the same transport layer (WebSocket). The technical spec should clarify whether typing indicator events appear in Call Thread transcripts and how they are filtered during persistence.

The change introduces role-based and individual membership management for channels. Aiden's existing spec § 5.3 covers suggestions within Communication Hub threads, but does not explicitly bind those suggestions to the channel's membership and notification defaults. This boundary needs clarification to ensure Aiden respects channel-level permissions.

The change indicates that admin users can configure channel-level notification behaviour (e.g. suppress all notifications). This suggests a need for admin-facing configuration UI, likely within Admin Control Plane's settings or setup wizard for channel governance policies.

Communication Hub's spec explicitly states typing indicators are transient and MUST NOT create durable records. Aftercare Manager consumes Communication Hub events; the technical boundary should confirm that typing events are excluded from Aftercare triggering logic.

The specification explicitly states DiaryNote is 'displayed in the Huddle Box at the top of the Day View diary'. Smart Dashboards owns Day View dashboard construction and must define the contract for consuming DiaryNote data, including read permissions and scope.

DiaryNote is explicitly shown 'at the top of the Day View diary for a specific practice date'. Surgery & Decon Day View is the primary tablet surface for day view; it must define how DiaryNote is rendered, accessed, and integrated into the tablet workflow for nurses and clinicians.

Recall & Reconnect drives patients to re-book appointments via outreach. The new zone constraint is now a hard gate for patient booking, so recall's re-booking offer matching must use the same zone filter to avoid offering out-of-zone slots.

Digital Forms are assigned appointment-driven. Since Appointment Manager now gates patient-facing booking by zone, form assignment logic that depends on appointment availability must align with the same zone constraint to avoid offering forms for out-of-zone appointments.

Treatment Pipeline drives lead-to-opportunity conversion and booking. The new zone constraint is authoritative on patient booking; the module must ensure lead qualification and initial appointment offers respect zone assignment.

Smart Dashboards consume appointment signals from Appointment Manager. The new zone constraint is a hard gate on patient booking; dashboard signals and alerts must account for zone filtering to ensure staff see accurate availability context.

Huddle Box is explicitly designed to replace sticky-note annotation and support the morning huddle workflow. Communication Hub already handles Structured Internal Requests and team announcements. The two surfaces serve different purposes (daily transient vs persistent team communication), but the spec should explicitly state this boundary to avoid duplication.

Smart Dashboards has a governed read-only interface to Appointment Manager. If patient zone eligibility is derived dynamically (e.g. from registered practitioner), the dashboard may need to filter or scope cards by zone. This affects the integration contract between the two modules.

DiaryNote is scoped to staff and explicitly NOT a patient artefact ('MUST NOT appear in patient audit trails'). Communication Hub owns audit and notification patterns; confirm whether DiaryNote creates/deletes should emit events to Communication Hub or remain isolated to Appointment Manager.

Recall & Reconnect initiates patient outreach journeys. If patient zone assignment becomes a hard constraint on appointment eligibility, outreach messaging and appointment suggestions must align with zone eligibility rules, potentially requiring updates to channel and candidate filtering logic.

Huddle Box acts as the practice's daily checklist and focus list. Smart Dashboards (particularly Manager/Operator Dashboard § 4.6) already expose role-specific alerts and action items. A ripple to show unreviewed or linked-appointment Huddle notes would align with the dashboard's 'Insight → Action' philosophy.

Huddle Box is positioned as a practice daily checklist and focus list. Task Manager's § 5.1 flows document how tasks are created and claimed. If Huddle Box notes can be converted to formal tasks (similar to Communication Hub's message-to-work pattern), this contract should be documented.

DiaryNote defines strict RBAC: 'minimum role required to create or delete a DiaryNote is Reception; read access is granted to all authenticated staff roles with diary access'. Access Manager owns RBAC and role architecture; it must ensure Reception and diary-access roles are authoritative and document the DiaryNote permission set.

AI Concierge handles inbound call booking and lead recovery outbound. If patients call to book, the new zone constraint is a hard gate; the module must apply the same zone filter when matching slots to ensure consistency with patient-facing booking elsewhere.

Appointment Manager UX §4.1 describes 'Find Next operates as a persistent modal overlay' with constraint confirmation. Communication Hub's Flow 5 (message-to-work hand-off to Appointment Manager) must document this UI hand-off and ensure constraints are visible at the point of conversion.

Aftercare instructions are appointment-triggered. If an appointment can only exist within a patient's zone due to the new constraint, aftercare delivery logic remains consistent, but the spec should clarify that zone-based filtering at the appointment boundary implicitly constrains aftercare scope.

The change explicitly states that aftercare templates may contain inline images and embedded video blocks, and that these assets are stored and versioned within Document Hub under the same governed lifecycle as other form assets. Document Hub's core objects and ingestion model need to confirm support for media assets as first-class document types, not just text/PDF.

The change resolves that aftercare templates support rich media as optional components. The Aftercare Manager technical spec (§ 3.3 Aftercare Template) needs to codify the block types and structure to ensure template authors and consuming surfaces (patient mobile app, document rendering) understand which content types are permissible and how they are rendered.

Aftercare Manager's technical spec references Aftercare Template objects but does not yet formally specify the editing/builder pattern. The pending decision in Digital Forms UX on whether to build dedicated drag-and-drop or reuse component libraries directly affects the template schema design and builder implementation contract.

Both modules build editable, reusable templates with block/component libraries. If aftercare chooses full drag-and-drop, Smart Treatment Proposals' §4.5 'Content Library & Click‑to‑Add Blocks' may need alignment or explicit divergence rationale to avoid UX inconsistency across template builders.

Smart Treatment Proposals already supports 'Multimedia Explanations' (§ 4.2) and a 'Content Library & Click‑to‑Add Blocks' (§ 4.5). If aftercare templates now formally support rich media blocks, the two modules should clarify whether they share a unified content-block vocabulary or maintain separate schemas. This is a design consistency concern rather than a hard dependency.

Aftercare Manager's technical spec references Document Hub integration for instruction delivery. If aftercare template builder uses bespoke drag-and-drop, Document Hub's rendering contract (§5) may need to support custom template markup or fallback to component-based rendering.

Campaign Manager explicitly features a drag-and-drop builder engine. If Aftercare implements its own bespoke drag-and-drop design, the two surfaces should maintain consistent interaction models and visual language.

Aftercare Manager issues instructions to patients; Communication Hub handles patient notifications and acknowledgements. If aftercare templates become more interactive or component-driven, the delivery and acknowledgement UX in Communication Hub may need updating to match.

Aftercare instructions may be surfaced or discussed in Communication Hub threads. The change allows rich media in templates, but Communication Hub's message-rendering contract should confirm it can safely display or link to media-rich aftercare content without breaking the thread UI or security model.

The digital-forms spec describes form assignment, expiry, and mandatory-form blocking (§5.2, §13.2 rules). Communication Hub is the platform's notification and messaging hub; if form assignments or reminders go through Communication Hub, the integration should be explicitly documented to avoid race conditions or duplicate notifications.

Surgery Decon Day View explicitly states that tooth-number display depends on PMS API availability of charted treatment data per appointment. Appointment Manager owns the PMS integration contract and must clarify whether this data field is available before Surgery Decon Day View finalises its data model.

The open question raises an engineering dependency on PMS API capability. If Surgery Decon Day View issues frequent or bulk queries for tooth data, the External Provider API Gateway's traffic classification and rate limits must accommodate this new access pattern.

Lab Manager specifies decon wall tablet day-view signal contracts and references surgery tablet display. If Surgery Decon Day View resolves tooth-number sourcing via PMS API, Lab Manager should align its own data model to use the same authoritative source for consistency.

Smart Treatment Proposals now defines a pre-populated form template library with clone-and-edit capability. Digital Forms is the module responsible for form creation, assignment, and lifecycle management. The template library is a foundational asset that Digital Forms will consume and build upon, requiring an explicit acknowledgement of this dependency and clarification of boundaries around template ownership vs. form instance ownership.

The change specifies that 'seed templates are provided by the platform operator at deployment time.' This is a deployment-time configuration responsibility that sits squarely within Admin Control Plane's provisioning and Setup Wizard remit. The module needs to document how seed templates are seeded into each tenant's form template library during onboarding.

The change states that templates 'automatically inherit the practice's top-level branding configuration' and branding is 'applied at render/export time.' If rendered forms are exported as documents and stored in Document Hub, Document Hub should clarify whether it receives pre-rendered (branded) documents or stores form metadata separately. This affects the Document Hub's ingestion and storage model.

STP technical spec §8.1 and §8.2 govern Q&A capture and staff response. STP UX §4.1 lists 'Review and respond to patient Q&A, including reviewing Aiden-suggested replies before sending' as a core task. Communication Hub must support contextual Q&A threads and message-to-action conversion for proposal-related queries.

Treatment Pipeline Manager UX establishes strict governance around stage transitions, especially irreversible ones (§2, Principle 7; §3). If Communication Hub converts a patient message into a pipeline action (e.g., marking a record as Lost / Closed), the conversion flow should respect the same confirmation and irreversibility warnings.

Staff App Mode §4.3 explicitly lists 'Reading and sending secure messages, participating in group chats and channels, viewing announcements and praise' as key tasks. Communication Hub owns these artefacts and their state machines; the mobile staff surface must be integrated into Communication Hub's interaction model and state machine documentation.

Communication Hub stores messages and structured requests, which are sensitive artefacts. Their creation, modification, and deletion must be auditable under security-privacy's framework, and any AI-assisted message generation must be logged with actor_type attribution.

Rewards-manager/ux §4.1 explicitly states 'Initiating staff-led outreach via Communication Hub for referrals that have stalled or for rewards that have not been redeemed' (Technical spec §5.3, §11.2). Communication-hub/ux must add or clarify a flow that allows staff to initiate outreach for rewards-related use cases (referral follow-up, redemption nudges).

The recall spec defines a secondary patient action ('Ask a question') that halts escalation and changes journey state. Communication Hub must support inbound messages from recall-originated conversations and integrate with the recall journey state lifecycle.

Loyalty Insights §4.1 references 'Communication Hub' indirectly as part of outreach execution (via Recall & Reconnect and Campaigns). Communication Hub's UX (§5.1 Primary Flows) should document how it receives structured handoff requests from Loyalty Insights and converts them into actionable outreach without duplication.

Knowledge UX §2 forbids the module from reminding or enforcing, but Communication Hub may receive questions about learning content. Clarify the boundary so learners can ask for help within Chat without the Knowledge module being responsible for response.

Hygiene-subscriptions explicitly references Communication Hub for payment exception notifications (Technical Spec §6.3). Chat surface should support message-to-work conversion for subscription exceptions (e.g. pending enrolment reminders, payment failure escalations) and route to hygiene-subscriptions management surfaces.

HR & People Manager emits governance-critical notifications (acknowledgements, escalations, workflow step assignments). Communication Hub is the authoritative message broker. The UX should document how HR notifications appear in the unified inbox and trigger structured requests.

Family Profiles technical spec (inferred from UX §2 governance principles) requires clear audit of consent actions. Communication Hub must specify whether invite codes, consent confirmations, and permission-change notifications are sent to guardian contact channels and how delegated identity is rendered in those messages.

Document Hub's design philosophy explicitly states 'Nothing is emailed as an attachment, nothing is copied to an external system'. Communication Hub currently allows messaging and document sharing; this cascade requires alignment with Document Hub's secure-by-reference-only pattern.

Campaign Manager is now a primary staff workspace. If Communication Hub detects campaign-related intents, it should be able to route or surface handoffs to the Campaign Manager, similar to how it routes to Appointment Manager.

Aftercare Manager's §4.1 (Web Portal) and §3 (Design Philosophy) specify that escalated conversations must be read-only to all except authorised clinical roles, with full AI interaction history and prior patient responses visible. Communication Hub's delivery surfaces section should clarify support for this read-only escalation conversation pattern and how AI contributions are marked within threaded conversations.

The ACP spec describes Support Mode (§4.10, partial) and references just-in-time support access sessions. Communication Hub's technical spec (§4.3) mentions 'Structured Internal Requests' and § 5.2 references 'Staff App Mode'. The UX spec should clarify how ACP staff (Support Engineers, CSM, Sales) interact with internal communication primitives and escalation paths within the ACP context.

Communication Hub is the unified chat and internal-request surface. If meetings are organisation-scoped internal events, participants may need to discuss or acknowledge meeting outcomes via Communication Hub (e.g. action handoff, decision clarification). This is speculative but worth exploring in UX design.

AI Guardian's technical spec §7 states AI MAY suggest alert content for human approval before those outputs are committed to Communication Hub. Communication Hub's UX spec should document the review-first workflow for AI-suggested alerts.

AI Concierge defines CallThread as a Conversation Thread sub-type in Communication Hub's technical spec (§3.1.1). The new AI Concierge UX spec establishes immutable transcripts and append-only audit trails (§13.2–13.1 of its technical spec). Communication Hub's UX must specify whether staff can access or reference these call records from the unified chat view and how they are distinguished from other conversation threads.

Aiden's spec states it answers 'internal Q&A questions answered from the practice-approved knowledge base' (§5.1, §6.1) and requires 'AI involvement always declared' with visual marking. Communication Hub's UX should clarify how Aiden's knowledge-base answers are presented and marked in the unified chat interface.