# NHS exchange mechanisms and standards Specify an exchange from its clinical purpose outwards. “FHIR”, “MESH” and “shared care record” describe different things. None alone defines the full clinical and legal arrangement. This reference uses public sources checked on **16 October 2026**. ## Separate the layers | Layer | Defines | Examples and design question | |---|---|---| | Clinical content | What the communication must mean to its reader | [Correspondence standards](https://copper-tiger.pages.dev/clinical-correspondence/index.md): which findings, medicines, plans and requested actions belong here? | | Terminology | How concepts are coded | SNOMED CT, dm+d and units: which code system, edition and value set apply? | | Information structure | How content is represented | HL7 v2 segments, CDA documents, FHIR resources and profiles: which exact specification? | | Interaction | What the parties do | Query, publish/subscribe, document delivery, booking or request/result: which states and responses are supported? | | Transport and routing | How the data reaches a destination | MESH mailbox/workflow, API endpoint or secure email: how is the recipient selected and checked? | | Application workflow | What happens after receipt | Matching, filing, review, action and escalation: who owns failures and unfinished work? | | Authority and assurance | Whether this use is permitted and safe | [Legal basis and confidentiality](https://copper-tiger.pages.dev/legal-framework/index.md), service eligibility, access controls and clinical-risk management | This is an analytical framework. The specific standards can span several layers; the table does not redefine their formal scope. ITK3, for example, supplies FHIR messaging components over MESH without specifying every clinical payload. [SRC-091](https://copper-tiger.pages.dev/sources/index.md#src-091) ## Exchange routes and their boundaries A **shared care view** is an access role, not one exchange protocol or storage arrangement. It may present stored contributions, retrieved source information, or both. Viewing does not by itself file information into the GP record or transfer clinical work. The [Foundations definitions](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md#summaries-and-shared-views) distinguish this role from source accounts and the GP record's additional primary record of care (PRC) role. [SRC-003](https://copper-tiger.pages.dev/sources/index.md#src-003) [SRC-004](https://copper-tiger.pages.dev/sources/index.md#src-004) | Mechanism | What it supports | What must still be established | |---|---|---| | GP2GP | Transfer of the GP electronic record between participating practices | Exact sending/receiving capability and outstanding components; not a generic specialist-letter route. [SRC-007](https://copper-tiger.pages.dev/sources/index.md#src-007) [SRC-008](https://copper-tiger.pages.dev/sources/index.md#src-008) | | GP Connect | Distinct record-access and selected update/document products | Product, permitted purpose, supplier and onboarding status; see the [detailed assessment](https://copper-tiger.pages.dev/interoperability/index.md). [SRC-022](https://copper-tiger.pages.dev/sources/index.md#src-022) [SRC-023](https://copper-tiger.pages.dev/sources/index.md#src-023) | | NHS e-Referral Service (e-RS) | Referral management and associated clinical information | Referral workflow and participating services; a referral is not the full longitudinal record. Public documentation includes Defence users. [SRC-071](https://copper-tiger.pages.dev/sources/index.md#src-071) | | Booking and Referral Standard (BaRS) | Booking/referral exchanges through an API and use-case implementation guide | Supported use case, endpoint and version. The catalogue lists API 1.6.0 among production versions; this does not approve every possible referral. [SRC-101](https://copper-tiger.pages.dev/sources/index.md#src-101) | | MESH | Asynchronous delivery of files and messages, with mailboxes and workflow identifiers | Agreed payload and recipient processing. Download acknowledgement does not mean clinical review. [SRC-092](https://copper-tiger.pages.dev/sources/index.md#src-092) | | ITK3 Transfer of Care | Profiled clinical documents with messaging and business responses | Correct document profile, version and workflow identifier; see [correspondence](https://copper-tiger.pages.dev/clinical-correspondence/index.md). [SRC-091](https://copper-tiger.pages.dev/sources/index.md#src-091) | | National Events Management Service (NEMS) | Authorised publication and subscription to supported events | Product status, permitted events and subscriber approval; it is not a universal hospital ADT feed. [SRC-102](https://copper-tiger.pages.dev/sources/index.md#src-102) [SRC-103](https://copper-tiger.pages.dev/sources/index.md#src-103) | | Secure email | Human-readable correspondence and attachments through an approved service | Correct recipient, local workflow, filing and escalation. Secure transport does not establish disclosure authority. [SRC-085](https://copper-tiger.pages.dev/sources/index.md#src-085) [SRC-086](https://copper-tiger.pages.dev/sources/index.md#src-086) | | Pathology reporting | Established reporting routes and an evolving FHIR service | The October 2026 Pathology Laboratory Reporting API remains in development/private beta; its R4 design uses a Patient Data Manager and notifications. It is not general production availability. [SRC-069](https://copper-tiger.pages.dev/sources/index.md#src-069) | | A local HL7 interface | A specified source/receiver exchange, such as patient-administration events | Exact event/profile contract, transport and local deployment evidence. NHS or Defence estate-wide coverage cannot be inferred from HL7 compatibility. [SRC-090](https://copper-tiger.pages.dev/sources/index.md#src-090) [SRC-094](https://copper-tiger.pages.dev/sources/index.md#src-094) | ### Version and status are part of the design NHS England marks ITK2 messaging standards **deprecated**. Its ITK3 catalogue remains **active** and lists STU3-based versions 2.10.0 and 2.9.0. The relevant programme determines the response-code version. These statuses do not mean all HL7 v2 interfaces are retired, or that every NHS document uses FHIR R4. [SRC-090](https://copper-tiger.pages.dev/sources/index.md#src-090) [SRC-091](https://copper-tiger.pages.dev/sources/index.md#src-091) UK Core governance concerns FHIR R4 profiles, extensions and terminology assets. Its existence does not silently convert a STU3 service contract. Specify the FHIR base release, profile/package versions, supported interactions and receiving implementation together. [SRC-098](https://copper-tiger.pages.dev/sources/index.md#src-098) The NEMS Standards Directory, read directly, was updated **7 October 2026**: it marks NEMS deprecated and states retirement on **30 September 2029**. The older API page says production use with deprecation under review. Preserve that chronology; confirm the intended successor and migration route with current public service documentation before selecting a new integration. Deprecation is not an assertion that existing delivery has stopped. [SRC-103](https://copper-tiger.pages.dev/sources/index.md#src-103) [SRC-102](https://copper-tiger.pages.dev/sources/index.md#src-102) The official service-page extraction states that new publisher/subscriber onboarding has stopped and directs existing users towards Multicast Notification Service (MNS) and the relevant source API. Direct retrieval was blocked; the source record preserves that limitation. This direction does not establish that every replacement use case is available. [SRC-107](https://copper-tiger.pages.dev/sources/index.md#src-107) ### MESH delivery example MESH stores an uploaded message until the recipient retrieves it. The recipient acknowledges download; the sender can track delivery. The service describes a non-delivery report after five days without retrieval. Workflow IDs identify message flows; they are not interchangeable labels for arbitrary content. [SRC-092](https://copper-tiger.pages.dev/sources/index.md#src-092) For a proposed Defence exchange, record the authorised recipient, payload version, business identifier and action deadline independently of transport status. Urgent care must not depend on waiting for a transport timeout. Reconcile a retry with the earlier attempt so it does not create duplicate clinical work. These are proposed design controls, not a statement of current Defence configuration. ## Proposed Defence integration role The Integration Platform (IntP) is proposed as a message broker, closely coupled with publish–subscribe services. It would coordinate two-way information exchange between the Defence Shared Care Record (DShCR), independent source systems and other tools, including return flows to specialist source systems. Its role in wider processing remains to be confirmed. Workflow, caseload and patient-flow tools may provide that processing; their state can inform the primarily read-only DShCR. Logical capabilities do not require separate products. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) Core clinical exchanges would include conditions, medications, vaccinations and allergies to support clinical decision support systems (CDSS) within specialist source systems. Specify the receiving use, content, source authority, provenance, currency and reconciliation rules. Delivery alone must not trigger an unconditional overwrite or establish that all information needed for decision support is available. These remain proposed requirements. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) The broker's delivery evidence remains distinct from the recipient's clinical action. Source systems retain their authored accounts and correction responsibilities. Connecting or displaying those accounts does not make either the IntP or the DShCR their common authoring system. ## Identity, addressing and clinical meaning PDS holds demographic information, including NHS number and registered GP, for England, Wales and the Isle of Man. It supports patient matching and demographic maintenance; it is not a clinical record store. Its access requirements and restricted-record handling still apply. [SRC-096](https://copper-tiger.pages.dev/sources/index.md#src-096) ODS identifies organisations and sites. An ODS code is not, by itself, a routable clinical inbox. The design must also resolve the relevant service, mailbox or endpoint and its current acceptance rules. Keep organisation changes separate from patient-identity changes. [SRC-097](https://copper-tiger.pages.dev/sources/index.md#src-097) The proposed Defence **Enterprise Master Patient Index (EMPI)** would link source identifiers to a persistent internal patient identifier, including people without an NHS number. A shared demographic profile is a critical requirement. The service must resolve demographic disagreements, but the authority rules and method remain open. Registration, appointments and patient movements belong to other tools or system features. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) The proposed **Healthcare Provider Directory (HPD)** would represent user profiles and provider relationships, including temporary deployed facilities. Its context would inform access decisions and routing; it is not itself the whole access-control or message-routing service. Precise location and other sensitive directory information require controlled disclosure. Neither the EMPI nor HPD is a replacement name for a national service or evidence of access to it. External identity and directory interfaces need their own contracts. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) | Coding family | Role in the reference | Proposed implementation control | |---|---|---| | SNOMED CT | Detailed clinical concepts | Retain system, code, display and relevant edition; distinguish active from historical concepts | | dm+d | Medicines and devices terminology | Preserve product identity and structured dose/context; a drug code alone is not a complete prescription | | ICD-10 and OPCS-4 | Classifications for coded activity and reporting | Do not substitute a classification mapping for the original clinical description | | UCUM | Units of measure | Preserve numerical value, unit and interpretation together | These roles follow the NHS developer terminology guide. That page retains some older release statements; it is used here for distinctions, not as an up-to-date release catalogue. Select current releases from the relevant terminology publisher before implementation. [SRC-099](https://copper-tiger.pages.dev/sources/index.md#src-099) ## A proposed interface contract Every COPPER TIGER interface should have a reviewable contract with the following fields. This is a project design template, not an NHS-mandated document format. | Contract section | Required design decision | |---|---| | Purpose and scope | Care setting, patient cohort, nation, sender, receiver and permitted use | | Authority | Controller roles, legal and confidentiality assessment, agreements, access policy and retention | | Clinical content | Document/event type, required context, requested actions and outstanding work | | Technical version | Base standard, profile and terminology releases, required fields, extensions and validation rules | | Identity and provenance | Patient/encounter identifiers with issuing authorities; author, organisation, source and timestamps | | Routing and security | Service eligibility, endpoints, authentication, recipient checks and restricted information handling | | Responses | Transport and application responses, clinical acceptance where required, timeouts, retry and escalation | | Change and recovery | Duplicate detection, corrections, merges, out-of-order events, downtime and reconciliation | | Assurance | Clinical hazards, tests, operational ownership, monitoring and change approval | DCB0129 addresses clinical risk in manufacture; DCB0160 addresses deployment and use. Apply the relevant scope and current specification, including their review status, to the supplier and deploying organisation. Passing a schema validator does not address all clinical hazards. [SRC-100](https://copper-tiger.pages.dev/sources/index.md#src-100) [SRC-106](https://copper-tiger.pages.dev/sources/index.md#src-106) A useful assurance example is an incorrectly matched patient: a technically valid document could be filed to the wrong person. Test ambiguous identity, an unavailable receiver, duplicate delivery and amended content as distinct cases. The expected outcome must include both the technical response and the clinical work left open. Continue with [ADT and event messaging](https://copper-tiger.pages.dev/messaging-and-events/index.md) for event behaviour, acknowledgements and recovery. The later [Defence mechanism map](https://copper-tiger.pages.dev/defence-mechanisms/index.md) checks what public sources establish about actual use.