Information movement and clinical work

The systems page identified functions for recording, sharing and following up care. This page connects those functions across services. Information reaching another system and a team accepting clinical work are different events.

Five connected concepts

This teaching model distinguishes GP2GP record transfer, GP Connect shared access and admission, discharge and transfer (ADT) messaging. GP2GP serves practices in England; GP Connect Access Record includes a read-only view. These examples do not establish Defence connectivity. ^{007, 022, 090}

Correspondence can inform without requesting action. For example, the NHS 111 standard distinguishes a post-event message from a referral. A letter can carry a task without demonstrating its acceptance. ⁰⁶⁷

Brokering information and processing work

Proposed direction. The Integration Platform (IntP) is fundamentally a message broker: it receives and routes information between connected systems. It should coordinate exchange in both directions among the DShCR, independent clinical source systems and supporting tools. A closely coupled publish–subscribe service lets a system publish an event for authorised, interested consumers to receive. Exact exchange contracts, routing and delivery guarantees remain open. ^{212, 220}

For example, a corrected allergy entry could update the DShCR and reach authorised receiving source systems under the agreed contract. Those systems could then use the information in their own clinical decision support systems (CDSS). Conditions, medications and vaccinations also fall within the proposed core sharing scope. Patient matching, source authority, provenance, currency and reconciliation rules must govern each flow; receipt alone must not trigger an unqualified overwrite. ²²⁰

The broker need not decide the next clinical action or own a caseload. Workflow processing manages work states and the rules for progressing work. Caseload tools help teams manage the people and work assigned to them; patient-flow tools support movement through services. These functions may sit in source systems or other tools. The proposed DShCR can show relevant progress and outstanding work from them without becoming their processing engine. ²¹²

This separates three questions: Was information delivered? What does the overview show? Who must act? A notification, a visible task and acceptance of responsibility are different events.

Follow the patient, information and responsibility

In the patient example, the GP requests specialist assessment. Relevant history supports the request; the specialist records the assessment and orders an imaging test.

A clinic letter returns findings and the plan to the GP. Filing it adds to the primary record of care (PRC) while the specialist's source account remains available in its own context. A community assessment report or hospital discharge summary can make a similar contribution. Shared access could make further detail visible without adding it to the GP record. Neither filing nor viewing establishes that the GP has accepted responsibility for the specialist's pending result. See how source records contribute.

In this example, the ordering specialist team remains responsible for tracking the result. When it becomes available, that team reviews it, acts and communicates with the patient. NHS imaging guidance assigns these duties to the initiating referrer. Any proposed handover needs an explicit decision under the applicable pathway. ⁰²⁰

If the patient changes primary-care provider while the result is pending, transferring the GP record supports continuity. The pending test still needs a visible owner and follow-up arrangement. Sending the record does not resolve that work.

Distinguish progress from completion

COPPER TIGER proposes these separate states for correspondence and work. They do not prescribe a universal NHS workflow.

These states need not occur in one fixed sequence. Information-only correspondence may have no action to accept. Requests may be declined or redirected; record the decision and escalation route. NHS messaging guidance supports tracking outstanding requests, covering absent staff and detecting failed flows. ⁰²¹

Connect clinical meaning to technical delivery

A content standard describes the information a communication needs. Fast Healthcare Interoperability Resources (FHIR) provides a standard way to represent and exchange healthcare data. A transport service carries the information between systems. The acute discharge standard combines clinical content, FHIR representation and Message Exchange for Social Care and Health (MESH) transport. Each serves a different purpose. ⁰⁶²

A transport acknowledgement confirms a defined delivery event. It does not prove clinical review or task completion. The flow reference, correspondence reference and exchange reference develop these distinctions. ⁰⁹²

Patient contributions and continuity options

Patient-facing flow to explore. Source systems could contribute through the IntP to the DShCR, with appropriate information passed through the IntP to patient-facing services. Patient contributions would return through the IntP to the DShCR, relevant source systems and supporting tools. This is a proposed relationship, not a mandatory route for every exchange. Content, permissions, clinical review and incorporation rules remain open. A patient's contribution would not automatically overwrite a professional entry or enter the PRC. ²¹²

Business continuity means sustaining the required service when normal operation is disrupted. The DShCR should support business continuity planning (BCP) alongside routine shared access. Three related capabilities are under exploration: ²²⁰

These are options to develop, not selected storage or offline designs. Their scope, capture responsibilities and recovery arrangements remain to be determined. Retaining a copy does not establish that it is current or that users can reach it during the relevant outage. ^{212, 220}

Public NHS continuity guidance supports investigating fallback access and recovery. Secondary-care EPR requirements also distinguish read-only downtime access and visible data gaps. These are reference points, not adopted Defence service targets. The architecture develops the controls and remaining design questions. ^{214, 215}

Previous: Systems and capabilities. Next: Governance, assurance and procurement: permitted purposes, safety and system selection.