# Clinical correspondence: types, standards and routes Clinical correspondence communicates an assessment, decision, request, result or plan between people and services. COPPER TIGER treats its clinical meaning, technical delivery and required action as separate concerns. This page uses NHS England as the baseline. Public evidence was checked on 16 October 2026. Read [clinical information flows](https://copper-tiger.pages.dev/information-flows/index.md) for responsibility, [exchange mechanisms](https://copper-tiger.pages.dev/exchange-mechanisms/index.md) for service choices, and [messaging and events](https://copper-tiger.pages.dev/messaging-and-events/index.md) for ADT and acknowledgements. The [governance model](https://copper-tiger.pages.dev/governance/index.md) addresses permission to disclose and use information. Correspondence connects the [source records introduced in Foundations](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md#how-source-records-contribute-to-continuing-care). A community report or hospital letter contributes selected information to the GP record, supporting its primary record of care (PRC) role. The originating service retains its detailed account. Filing the communication, consulting a shared care view and accepting requested work remain distinct actions. ## Separate the layers An implementation description needs all five layers below. The acute discharge standard illustrates this separation through its clinical model, terminology, FHIR representation and MESH transport. Clinical responsibility remains a separate workflow question. [SRC-062](https://copper-tiger.pages.dev/sources/index.md#src-062) [SRC-018](https://copper-tiger.pages.dev/sources/index.md#src-018) | Layer | Question | Example | |---|---|---| | Clinical communication | What is being communicated, and why? | Discharge summary; referral question; diagnostic opinion | | Content standard | Which information and meaning must be preserved? | Discharge diagnoses, medicines, allergies, plan and requested actions | | Representation and profile | How is that information encoded? | A specified FHIR document profile and release; a human-readable attachment where permitted | | Exchange route | How does it reach the intended recipient? | MESH, an e-RS workflow, an approved API or an agreed secure fallback | | Clinical workflow | Who reviews, accepts and completes the work? | Named receiving team, deadline, escalation and closure evidence | This is an analytical framework. A content standard does not, by itself, make a recipient reachable or assign clinical responsibility. A transport service does not establish the legal basis for disclosure. ## Correspondence families The table is a working taxonomy, not an exhaustive national classification. Its purpose is to prevent different communications being treated as interchangeable letters. | Type | Purpose and action | Relevant standard or route boundary | |---|---|---| | **Referral request** | Ask another service to assess or treat a problem. Include the clinical question, urgency and relevant background. | Clinical Referral Information Standard; e-RS where the service and pathway support it. A sent referral still needs processing. [SRC-060](https://copper-tiger.pages.dev/sources/index.md#src-060) [SRC-066](https://copper-tiger.pages.dev/sources/index.md#src-066) | | **Advice and guidance request and response** | Obtain specialist advice to inform the referrer's next decision. | e-RS advice conversations differ from referral assessment. Advice may lead to a referral; it is not automatically an accepted referral. [SRC-066](https://copper-tiger.pages.dev/sources/index.md#src-066) | | **Referral assessment or triage response** | Accept, redirect, request more information or return advice under the applicable pathway. | e-RS worklists expose actions for referrers and providers. A booking state and a clinical decision are distinct. [SRC-066](https://copper-tiger.pages.dev/sources/index.md#src-066) | | **Outpatient clinic letter** | Communicate consultation findings, decisions and follow-up to the patient and relevant professionals. | Outpatient Letter Standard; the Transfer of Care outpatient specification is a particular technical implementation. [SRC-061](https://copper-tiger.pages.dev/sources/index.md#src-061) [SRC-065](https://copper-tiger.pages.dev/sources/index.md#src-065) | | **Acute inpatient or day-case discharge summary** | Summarise the episode and information needed after discharge. | DAPB4042 combines the eDischarge content model with terminology, FHIR and MESH requirements for its defined scope. [SRC-062](https://copper-tiger.pages.dev/sources/index.md#src-062) | | **Emergency care discharge summary** | Communicate emergency attendance, assessment and onward plan. | Emergency Care Discharge Standard covers type 1, 2 and 3 units. It excludes inpatient discharge and inter-hospital transfers. [SRC-063](https://copper-tiger.pages.dev/sources/index.md#src-063) | | **Mental health inpatient discharge summary** | Support continuity after adult inpatient mental health care, including relevant physical and mental health information. | The dedicated mental health standard excludes outpatient discharge and inter-hospital transfer. [SRC-064](https://copper-tiger.pages.dev/sources/index.md#src-064) | | **Community, rehabilitation or therapy communication** | Convey assessment, progress, care-plan changes or discharge from a service. | Identify the actual encounter and commissioned pathway. Outpatient content may be relevant; this research has not established one universal community correspondence profile. [SRC-061](https://copper-tiger.pages.dev/sources/index.md#src-061) | | **Diagnostic request and report** | Request an investigation and return its findings or interpretation. | A pathology report is a structured diagnostic artefact, distinct from the letter interpreting it. Imaging results also need review, action and patient communication. [SRC-069](https://copper-tiger.pages.dev/sources/index.md#src-069) [SRC-020](https://copper-tiger.pages.dev/sources/index.md#src-020) | | **NHS 111 referral and post-event message (PEM)** | A referral requests action; a PEM informs the GP about a contact. | The 111 Referral Standard explicitly distinguishes these purposes. Routing a PEM into the record is not acceptance of a referral. [SRC-067](https://copper-tiger.pages.dev/sources/index.md#src-067) | | **Community pharmacy notification** | Return the relevant outcome of a pharmacy service to general practice. | DAPB4008 defines information by service. GP Connect Update Record supports specified pharmacy flows, not arbitrary specialist write-back. [SRC-068](https://copper-tiger.pages.dev/sources/index.md#src-068) [SRC-024](https://copper-tiger.pages.dev/sources/index.md#src-024) | | **Shared-care request and response** | Propose and agree specified prescribing or monitoring responsibilities. | A letter alone does not establish patient-specific shared-care agreement. Use the relevant protocol and record the receiving clinician's decision. [SRC-029](https://copper-tiger.pages.dev/sources/index.md#src-029) | | **Occupational or fitness report** | Answer an authorised employment or fitness question for a defined recipient. | Distinguish the report from the underlying clinical record and a direct-care letter. GMC guidance explicitly addresses Armed Forces dual obligations. [SRC-033](https://copper-tiger.pages.dev/sources/index.md#src-033) | An **admission, discharge or transfer (ADT) message** represents a patient-administration event. It should not be treated as the clinical discharge summary. A referral response, result report and discharge letter can concern the same episode while carrying different meanings. See [messaging and events](https://copper-tiger.pages.dev/messaging-and-events/index.md). ## Versions and status matter The NHS Standards Directory says the listed PRSB-developed resources moved to NHS England management on 1 January 2026. Keep the content-model version separate from the technical profile release and the contract year. “Active” describes a published standard; it does not prove adoption by every provider. [SRC-060](https://copper-tiger.pages.dev/sources/index.md#src-060) [SRC-061](https://copper-tiger.pages.dev/sources/index.md#src-061) | Standard or specification | Published position checked on 16 October 2026 | Implementation implication | |---|---|---| | Clinical Referral Information Standard | Directory publication version **1.0.0**, active; PRSB model v1.0. [SRC-060](https://copper-tiger.pages.dev/sources/index.md#src-060) | Use the model's mandatory, required and optional rules. Do not replace them with a locally invented minimum. | | Outpatient Letter Standard | Active; linked release notes identify **v2.2**, April 2023. [SRC-061](https://copper-tiger.pages.dev/sources/index.md#src-061) | Record the model version separately from the chosen message specification. | | Acute inpatient discharge | **DAPB4042 Amd 75/2021**, directory version **1.0.0**, active; underlying eDischarge model **2.1**. [SRC-062](https://copper-tiger.pages.dev/sources/index.md#src-062) | Check the standard's provider scope and the applicable NHS contract. | | Emergency Care Discharge Standard | Directory version **2.2.0**, active. [SRC-063](https://copper-tiger.pages.dev/sources/index.md#src-063) | Preserve emergency-care scope and exclusions. | | Mental Health Inpatient Discharge Standard | Active; linked PRSB documentation identifies model **v2.1**. [SRC-064](https://copper-tiger.pages.dev/sources/index.md#src-064) | Adult inpatient scope does not establish a universal mental health interface. | | NHS Transfer of Care message specifications | Acute, emergency, mental health and outpatient specifications are listed as **2.9.0-live**, dated 30 July 2021, based on **FHIR STU3**. [SRC-065](https://copper-tiger.pages.dev/sources/index.md#src-065) | A newer FHIR release is not a drop-in replacement for these published profiles. | | 111 Referral Standard | Directory version **1.0.0**, active. [SRC-067](https://copper-tiger.pages.dev/sources/index.md#src-067) | Content scope and BaRS implementation availability must be checked separately. | | Community Pharmacy Information Standard | **DAPB4008 5/2023**, active, effective 1 July 2023. [SRC-068](https://copper-tiger.pages.dev/sources/index.md#src-068) | The directory still includes historic service names and routing text. Use current service-specific specifications for delivery. | For implementation, retain the exact content model, implementation guide, terminology release and technical profile used by each interface. Validate the combination. Do not infer one version from another. ## Routes are selected by communication and recipient **Referral and advice workflows:** e-RS offers booking, triage and advice functions. Its public service description lists Defence medical services among its users. That establishes a documented connection to the platform, not coverage of every Defence service or every correspondence type. [SRC-071](https://copper-tiger.pages.dev/sources/index.md#src-071) **Hospital discharge to general practice:** the DAPB4042 route uses a FHIR representation carried over MESH. An attached PDF sent by email is not equivalent evidence of conformance. Verify the receiving organisation, supported profile and failure response. [SRC-062](https://copper-tiger.pages.dev/sources/index.md#src-062) **Pharmacy updates:** distinguish the pharmacy content standard from GP Connect Update Record and each supported service. Current eligibility and onboarding restrictions remain relevant. [SRC-068](https://copper-tiger.pages.dev/sources/index.md#src-068) [SRC-024](https://copper-tiger.pages.dev/sources/index.md#src-024) [SRC-025](https://copper-tiger.pages.dev/sources/index.md#src-025) **Pathology:** the October 2026 API specification describes FHIR R4 reporting through Patient Data Manager and Multicast Notification Service. It labels the API in development, with private-beta, invitation-only onboarding. Do not infer that legacy EDIFACT flows have ended or that Defence can use this route. [SRC-069](https://copper-tiger.pages.dev/sources/index.md#src-069) The [exchange-mechanisms reference](https://copper-tiger.pages.dev/exchange-mechanisms/index.md) compares transport, APIs, record access and secure email. Urgent communication and agreed outage procedures need their own operational route. Routine electronic delivery alone cannot assure a timely clinical response. [SRC-021](https://copper-tiger.pages.dev/sources/index.md#src-021) ## A proposed correspondence lifecycle COPPER TIGER proposes the following states for interface and workflow design. They are not a description of current Defence operation or a universal NHS protocol. 1. **Author and approve.** Identify the encounter, author, responsible service, document type and intended recipients. Separate information from requested actions. 2. **Validate and send.** Validate patient identity, recipient, required content and the agreed technical profile. Record the document and transmission identifiers separately. 3. **Receive and match.** Record transport and application responses. Quarantine unmatched patients or invalid documents for resolution; do not silently discard them. 4. **Review and decide.** Route clinical work to the responsible team. Record whether each requested action was accepted, declined or redirected. 5. **Act and close.** Record completion, patient communication and any continuing responsibility. Escalate overdue work through the agreed pathway. This separates **transport receipt**, **application processing**, **clinical review** and **acceptance of an action**. An acknowledgement must be interpreted at the layer defined by its specification. The [ADT and acknowledgement reference](https://copper-tiger.pages.dev/messaging-and-events/index.md) explains the technical distinctions. ### Worked fictional example An NHS outpatient team sees a patient whose usual primary care is provided by Defence. The team orders an investigation and sends a clinic letter. The example illustrates information requirements only. It assumes no live interface or clinical treatment decision. | Proposed field | Fictional example | Reason | |---|---|---| | Patient identity | Test patient `CT-EXAMPLE-01`; NHS number omitted | A production exchange needs validated patient identification. | | Encounter | Outpatient attendance, 16 October 2026 | Separate clinical event time from authoring and delivery time. | | Document identity | `CT-LETTER-001`, issue 1 | Distinguish the clinical document from transport retries. | | Author and accountable service | Example NHS outpatient team | Preserve provenance and a contact for clarification. | | Recipient and copy role | Defence primary-care team: information copy | Do not imply an action merely by including a recipient. | | Pending investigation | `CT-ORDER-001`; result not yet available | Preserve the link between the order and later report. | | Result responsibility | Ordering outpatient team retains review and patient communication | Make responsibility explicit in this scenario. | | Requested primary-care action | None in this example | Distinguish information from a handover request. | | Later amendment | Issue 2 supersedes issue 1; reason and author recorded | Prevent obsolete information being mistaken for current advice. | These are proposed logical fields, not valid FHIR JSON or a complete conformance template. Map them to the selected profile, rather than inventing unsupported extension fields. The receiving system can acknowledge delivery and file the letter. The pending investigation remains on the ordering team's worklist. When the result arrives, that team reviews it and records communication with the patient. Any new request to primary care needs a separate, visible decision and action trail. This proposed design follows the distinction between result communication and responsibility. [SRC-020](https://copper-tiger.pages.dev/sources/index.md#src-020) ### Corrections, medicines and pending work COPPER TIGER proposes linked amendments that preserve the original document, corrected version, reason, author and recipients. Receiving systems should distinguish a retransmission from a new version. An urgent correction should trigger direct communication through the agreed pathway, alongside the corrected document. Medication information needs reconciliation, not automatic conversion of every letter into a prescription. Older outpatient implementation guidance, still linked by the current directory, specifies responsible GP prescriber authorisation for changes to the GP medication record. It also distinguishes dose-based and product-based prescribing. This supports the distinction between receiving information and authorising a medicine change; current local prescribing arrangements still require confirmation. [SRC-070](https://copper-tiger.pages.dev/sources/index.md#src-070) Pending results need an owner, expected follow-up and escalation route. A patient copy, information displayed in a shared care view or a discharge event does not show that the result has been reviewed. The [information-flows report](https://copper-tiger.pages.dev/information-flows/index.md) develops the responsibility model. [SRC-020](https://copper-tiger.pages.dev/sources/index.md#src-020) [SRC-021](https://copper-tiger.pages.dev/sources/index.md#src-021) ## National scope and Defence unknowns The clinical referral and 111 standards describe UK-wide content scope. The 111 standard excludes transfers between 111 services and between 111 and 999. Shared content definitions do not establish common infrastructure, contractual duties or operating arrangements across the four nations. [SRC-060](https://copper-tiger.pages.dev/sources/index.md#src-060) [SRC-067](https://copper-tiger.pages.dev/sources/index.md#src-067) For a cross-border or Defence exchange, COPPER TIGER therefore proposes recording the sending nation, receiving service, local standard, route and applicable agreement. Public evidence has not established every Defence mailbox, accepted document profile, local message transformation or escalation process. These remain unknown, rather than inferred from NHS capability. ## Questions that develop the concept The next design questions apply across correspondence families, rather than selecting one pathway as the whole model: - Which artefacts are an information copy, a request for work, a clinical decision, an event notification or a record transfer? - What minimum provenance and responsibility information must survive every route, including human-readable fallback? - Which standard and version apply to each setting, age group and nation? Where is a local profile necessary? - Which recipient maintains the PRC, which service maintains each source account, and who must act on each finding or request? - How will corrections, duplicate transmissions, late results and changes of usual GP be reconciled without losing clinical context? - What public evidence establishes the actual Defence route, and which details must remain explicitly unknown? These questions apply the proposed [architecture](https://copper-tiger.pages.dev/architecture/index.md) to correspondence. They remain design and evidence gaps, with parked work recorded in the [validation queue](https://copper-tiger.pages.dev/validation-queue/index.md). They do not establish permission to access records or evidence that an interface exists. Continue with [exchange mechanisms](https://copper-tiger.pages.dev/exchange-mechanisms/index.md) to specify how the selected content reaches its recipient and how delivery is checked.