Internal Defence architecture
How should Defence maintain patients’ lifelong primary (GP) records of care in line with applicable NHS conventions and standards, preserving continuity and supporting record transfer from and to NHS general practice when Defence care arrangements begin and end?
In parallel, how should Defence develop a complementary internal Defence Shared Care Record (DShCR) that brings information from multiple source systems into a contiguous, longitudinal view, supports business continuity, and enables appropriately governed information access and sharing across Defence healthcare and occupational health-led military medicine?
Proposed logical architecture — clarified 22–23 October 2026. This defines capabilities and relationships for COPPER TIGER/Care Hub. It does not describe deployed systems or an approved design. Care Hub is a potential rebranding of Programme Cortisone. The leading principle is a continuing primary record of care (PRC) alongside a governed Defence Shared Care Record (DShCR), ready to integrate with national and regional services. 211, 212, 220
The proposed DShCR provides a comprehensive, primarily read-only overview across multiple source systems and relevant supporting tools, with authorised access to complete contributing clinical source records through that view. Contiguous means connected presentation across sources; longitudinal means continuity over time. Completeness remains an objective, subject to source coverage, freshness and access conditions. 220
A closely coupled Integration Platform (IntP) brokers information exchange in both directions, including back to independent specialist source systems. Source systems retain the originating clinical accounts and correction responsibilities. Separate tools or system features can manage work, patient administration and information capture. These are capability boundaries; they do not prescribe products or procurement lots.
Internal ecosystem and external boundary
flowchart TB
accTitle: Proposed source records, integration and Defence shared record
accDescr: The GP source record has the additional continuing PRC role. It and other clinical source records contribute through the Integration Platform to the Defence Shared Care Record and other tools or interfaces. These selected outward relationships do not exclude return flows. Identity, directories and access controls support all components. Storage and routing remain open.
A["GP source and PRC"] --> C["IntP broker"]
B["Other sources"] --> C
C --> D["DShCR overview"]
C --> E["Tools and interfaces"]The arrows show selected outward information flows. “Other sources” means the clinical source records of contributing services. The proposed exchange is two-way: core clinical information, corrections and patient contributions also flow to appropriate independent source systems and tools through the IntP. Each direction needs a defined contract. The diagram does not make the DShCR an obligatory processing stage for every exchange. “Tools and interfaces” includes workflow and patient-administration tools, possible forms and patient-facing services, and governed external connections. 220
The Enterprise Master Patient Index (EMPI) links patient identities and supplies shared demographics. The Healthcare Provider Directory (HPD) represents people, organisations, services and their relationships. They support the ecosystem rather than form successive steps in the diagram. Access controls, provenance, safety and continuity apply throughout. National interfaces defines the external boundary separately.
Capability and responsibility model
| Capability | Proposed responsibility | Boundary to preserve |
|---|---|---|
| Source clinical records | Preserve the authored account of primary, specialist, dental, mental-health, rehabilitation, hospital and deployed care, including corrections. | A specialty does not require a separate application. Each account retains provenance. |
| Continuing PRC | Maintain lifelong primary-care history in line with applicable NHS conventions and standards, including relevant contributions from other services, to support continuity and record transfer from and to NHS general practice when Defence care arrangements begin and end. | Applies to Armed Forces and civilian patients within scope. The GP record carries source and PRC roles. Fuller specialist source detail need not all be copied into the PRC. 220 |
| DShCR | Bring information from multiple source systems into a contiguous, longitudinal, primarily read-only overview, with authorised access to complete contributing clinical source records and relevant work state. | Complete coverage is an objective, subject to availability, freshness and access conditions. Source records retain their originating accounts; storage and retrieval are undecided. |
| IntP and publish–subscribe | Coordinate two-way information exchange and notifications between the DShCR, independent source systems and supporting tools, including return flows of core clinical information. | Message brokering does not assign ownership of clinical content, workflow, caseload or patient-flow processing. |
| Core clinical sharing and decision support | Exchange conditions, medications, vaccinations and allergies for consistent information use and CDSS within specialist source systems. | Define source authority, provenance, currency, corrections and reconciliation. No automatic overwrite or single authoritative clinical store is selected. |
| Coordination and work tools | Process and track referrals, results, handovers, caseloads, patient flow, exceptions and closure. Make relevant state available to the DShCR. | The responsible tool and clinical role remain explicit. Delivery or shared visibility does not discharge work. |
| EMPI | Match identities, link source identifiers to a persistent internal patient identifier, and provide a shared demographic profile to connected systems. | Include people without an NHS number. Demographic authority and conflict resolution are required functions; their rules remain to be determined. |
| HPD | Support configurable user profiles and represent organisations, teams, services, facilities and their relationships. | Include permanent and temporary deployed facilities. Directory data informs access; the complete authentication and enforcement design remains open. |
| Patient administration | Manage registration, appointments and patient movements through dedicated tools or features in other systems. | These functions are distinct from the EMPI's identity and demographics scope. |
| Occupational health and readiness | Conduct authorised assessments; retain assessment evidence and produce appropriately limited fitness/readiness outputs. | Treatment access does not grant blanket occupational use or command access. |
| Patient-facing services, potentially PHRs | Explore one or more tools for access, communication and patients' contribution and management of their own information. | Features are options to explore. Patient contributions retain attribution and do not automatically overwrite professional records. |
| Consultation forms | Explore capture during outages, outside existing source systems and across specialties. | Forms could be in the DShCR suite or another tool. Their source-record responsibilities and reconciliation remain open. |
| Population and service uses | Support planning, surveillance, research and operational analysis through approved data products and controlled environments. | Direct-care access is not authority for reuse; aggregation alone does not guarantee anonymity. |
| Terminology and exchange controls | Preserve coding, semantic mappings and versioned content contracts; validate and observe exchanges. | An adapter cannot decide clinical truth or assume a transport acknowledgement is acceptance. |
| Assurance and service operation | Maintain safety cases, security, access policies, auditing, continuity, incident response and change control. | Capability, assurance, procurement and actual deployment require separate evidence. |
These are proposed requirements and options from the owner clarification, not claims about a selected software service. CDSS means clinical decision support systems; their role in this model is developed below. 212, 220 The Foundations capability map introduces the terms. The operating model identifies accountability questions.
What the shared record adds
An appropriately authorised Defence GP could consult a full mental-health consultation through the DShCR to support occupational primary care and risk management. The PRC receives the appropriate correspondence or summary under applicable NHS standards. This gives access to fuller detail while preserving the continuing record's purpose. It does not create an existing access entitlement or exclude clinically relevant mental-health information from the PRC. 212
The overview should show origin, coverage, freshness and correction state. It can include relevant care plans and outstanding work from their responsible tools. Displaying those items does not transfer authorship or work ownership to the DShCR. The record-purpose explanation distinguishes the source account, PRC contribution and shared use.
Patient identity, provider context and access
The EMPI's shared demographic profile is a critical requirement. Its service must resolve disagreement between demographic sources. Field authority, update rules, matching methods and merge/unmerge behaviour remain design questions; no source hierarchy or latest-update rule is selected. Preserve each linked identifier and its issuing context. 212
The HPD supports continuously configurable profiles, including role, function, seniority, clinical need and population scope. It also represents changing relationships with teams, services and permanent or temporary facilities. Location and geospatial information need controlled disclosure in the Defence context. Service discovery without precise location is a future feature to explore. 212
Clinical access normally requires an established care relationship, interpreted broadly for Defence. Any patient may be available to clinical or administrative users under the appropriate conditions. Role-based access control (RBAC), break-glass, audit, automated audit and alerts are required capabilities. Exact administrative visibility and permission rules remain open. An HPD profile informs the access decision; it does not replace authentication or policy enforcement. 212
Break-glass needs a defined exceptional purpose, recorded justification and review. The governance reference keeps treatment, occupational assessment, command disclosure and secondary uses distinct.
Apply the five patterns inside Defence
| Pattern | Internal design rule | Example |
|---|---|---|
| PRC versus source account | Preserve source detail and continuing primary history; apply the relevant NHS content standards. | A specialist assessment remains attributable; appropriate findings and follow-up enter the PRC while permitted detail is available through the DShCR. |
| Transfer, correspondence, access and responsibility | Model each interaction independently. | Moving between primary-care providers includes reconciliation and an explicit handover; opening a shared record does not complete either. |
| Delivery versus clinical work | Record receipt, filing, review, acceptance, action and closure as distinct events. | A delivered result can still be unreviewed or have no accepted action owner. |
| Treatment, occupational assessment and command disclosure | Authorise each purpose and limit each output. | A fitness recommendation follows its approved route without releasing the full treatment record. |
| Capability, assurance, procurement and deployment | Hold evidence against the exact configuration, setting, use and date. | Procurement eligibility alone proves neither safe use nor live integration. |
Public guidance supports the underlying record and governance distinctions. Their combination into this Defence architecture is proposed. 004, 018, 032
Identity, versions and information integrity
Patient identity, clinical-item identity, a revision and a delivery event answer different questions. The EMPI identifies the person. A clinical-item identifier links copies to their originating account; a version distinguishes a correction; a delivery identifier supports retry handling. Preserve source identifiers and their issuing contexts. FHIR's resource model distinguishes logical identity, version metadata and business identifiers; it is a reference, not a selected Defence exchange standard. 216
A globally unique identifier (GUID) and a hexadecimal content fingerprint are options for integrity and duplicate handling. A cryptographic hash detects changes to a defined representation. It does not establish clinical equivalence, authorship or freshness. An unchanged retry of the same item and version must not create another clinical item; a correction remains a new version. Similar separate entries must not be merged solely because their text matches. Identifier formats, hash algorithm and representation rules remain open. 218, 212
Preserve origin, author, care time, entry time and revision relationships. Provenance describes how information came to exist; access audit records its use. They are complementary controls. A correction should reference the superseded version and reach relevant recipients under the agreed contract. It must not silently rewrite the evidence available for an earlier decision. 217
Information exchange and clinical work
The associated IntP should coordinate exchange of core clinical information, including conditions, medications, vaccinations and allergies, in both directions. Independent specialist source systems can contribute this information and receive relevant information from other sources. The aim is consistent information use and support for clinical decision support systems (CDSS) within those systems. Viewing a record in the DShCR and supplying usable information to a source system's CDSS are distinct capabilities. 220
The EMPI supplies patient matching and shared demographics; the HPD supplies provider identities, profiles and relationships that inform access and routing. These supporting services are distinct from the contributing clinical source records. Source authority, provenance, currency, correction propagation and reconciliation need explicit rules for each clinical information category. No automatic overwrite, global source hierarchy or single authoritative clinical store is selected. 220
For every interface, specify producer, consumer, purpose, population, permitted operations, content/profile versions, identifiers, acknowledgements, correction handling, retention, security and recovery. Read permission does not imply permission to write, export, retain or reuse. Use the exchange contract and legal decision record as references.
The IntP brokers exchange and publish–subscribe notifications. Consumers and processing tools need their own rules for acceptance, retries, missed events and reconciliation. Relevant work state can be presented in the DShCR while remaining owned by the responsible workflow tool and clinical service.
Receipt, filing, review, acceptance, action and closure remain distinct. Clinical pathways determine their order and exception handling. Record the responsible role, owning team, due time, cover and escalation where needed. A message acknowledgement cannot establish clinical acceptance. Duplicate delivery must not duplicate an order or close work twice.
Continuity and information capture options
The DShCR should support routine use and business continuity. Explore retained information for reading, consultation capture and subsequent reconciliation with source systems. Scope and implementation remain to be determined. Retained copies, live retrieval and a hybrid remain options by content and setting. A retained copy alone does not prove that the service survives a source, network, identity-service or hosting outage. 212, 220
Public evidence. NHS continuity guidance includes offline record repositories and recovery of temporary records as examples. Published secondary-care EPR requirements address read-only downtime access and visible data gaps. These support evaluating the options; they do not prescribe Defence topology or recovery targets. 214, 215
Proposed direction. Show last successful update, coverage and unavailable sources. Distinguish stale copies, denied access, unmatched identity and confirmed absence of information. Where capture can continue, preserve author, care time, entry time and item/version identity. Reconcile corrections, duplicates, conflicting changes and outstanding work before declaring recovery complete.
Open design questions. Define the failure scenarios covered, minimum information, permitted retention, expiry, access during outages and recovery objectives. Forms may support continuity or other cross-specialty capture, within the DShCR suite or another tool. Their uses, source-record authority, destination and reconciliation remain to be determined. No numerical service target or universal offline capability is assumed.
Patient-facing services and return flows
Explore patient-facing record services, potentially personal health records (PHRs). NHS England's published capability model associates a PHR with a person managing and adding to their information. Viewing alone does not establish that full capability. 213
The proposed outward relationship is source systems → IntP → DShCR → IntP → patient-facing services. Patient contributions should return through the IntP to the DShCR, relevant source systems and other supporting tools as appropriate. This is an information-flow requirement, not a mandatory chain for every item. Patient attribution, clinical review and incorporation into professional records remain distinct. 212
Features, presentation, proxy access, sensitive-content rules and tool boundaries remain open. Keep these options separate from the continuing PRC and from the professional DShCR overview.
Next design questions
The discovery register separates the remaining content, continuity, directory, identity and patient-facing questions. Evaluate options against provenance, correction handling, permitted access, availability, portability, operating cost and exit. No particular product or database follows from the capability model.
Continue with national and regional integration for external contracts. Allied, overseas and contracted provision remain in scope; their precise interfaces require further evidence.