Care Coordination and 360 Referrals (Proof of Concept) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Referral Outcome Reports

The report back - consultation note, clinic letter or discharge summary - is what closes the loop. This page describes the report content and the ways of delivering it, from the MESH and HL7 v2 messaging most trusts use today to document sharing through the EU Health Data API.

References

• HL7 Europe Hospital Discharge Report (HDR) - 1.0.0 STU 1 (2026-10-16)
• EU Health Data API - 1.0.0-ballot (2026-03-13)
• IHE ITI Mobile access to Health Documents (MHD)
• Transfer of Care, PRSB standards
• NW GMSA - Health Data API, Document Exchange (MHD), Message Exchange

Report Types

Each report SHALL be linked to the referral it answers, by the Referral ID (and the UBRN if eRS was used). The link is made by the workflow that carries the document, not inside the FHIR Document:

HL7 Europe Hospital Discharge Report

HDR is a FHIR Document (Bundle of type document) whose first entry is a Composition with sections for the hospital stay. It is built on HL7 Europe Base and the International Patient Summary, and is one of the European Electronic Health Record exchange Format (EEHRxF) priority categories. It is the most likely successor to the Transfer of Care eDischarge document.

The heading mapping is indicative only - To confirm against the PRSB eDischarge standard. This guide uses HDR as published. HDR offers a basedOn extension on the Composition (event-basedOn), but the FHIR R4 validator does not allow that extension on Composition, so this guide does not use it: the document is linked to the referral by the workflow (table above). See notes/research.md #48.

HDR is for inpatient stays. HDR's Encounter only allows inpatient classes (IMP, ACUTE, NONAC, OBSENC, SS) and its Composition.type is fixed to LOINC 34105-7 (Hospital Discharge Summary). It does not fit an outpatient clinic letter. For outpatient letters this guide uses a plain Composition (LOINC 11488-4 Consult Note) with the HDR section codes - whether HDR should be relaxed for outpatient encounters is Open. A virtual ward stay is treated as an inpatient stay so it can use HDR - see Virtual Wards.

Example: Virtual ward discharge report.

Delivering the Report

flowchart LR
    RR[Referral Recipient<br/>EPR] --> TIE[Trust Integration Engine]
    TIE -->|HL7 v2 MDM^T02 / ORU^R01| RI1[Referral Initiator<br/>EPR / GP system]
    TIE -->|MESH: Kettering XML,<br/>FHIR Document, ITK3| RI2[GP practice]
    TIE -->|ITI-105 / ITI-65 publish| DAP[(Document Access Provider<br/>shared care record)]
    DAP -->|ITI-67 / ITI-68 query and retrieve| DC[Document Consumer<br/>Referral Initiator, other carers]
    DAP -.->|notification - MNS / Subscription| DC

360X pushes the outcome to the Referral Initiator. Document sharing does not replace that: a published document only closes the loop if the referrer is notified or queries for it.

From Document Messaging to Document Sharing

See also EU Health Data API and Document Sharing [MHD].

The EU Health Data API defines the actors for sharing documents and resources, based on IHE MHD, PDQm and HL7 IPA:

The Health Data API DocumentReference derives from the IHE MHD Minimal DocumentReference. A Kettering XML envelope or an HL7 v2 MDM^T02 maps onto it directly (patient, type, date, author, attachment), so a trust already sending letters by MESH can publish the same letters with little extra mapping.

Open: the Health Data API discharge report document type value set uses LOINC 18842-5 (Discharge summary), while HDR fixes Composition.type to 34105-7 (Hospital Discharge Summary). Which code should DocumentReference.type carry?

HL7 v2 Report Messages

Most trust EPRs already produce HL7 v2 for letters:

A Trust Integration Engine (or regional orchestration engine) can turn either into a FHIR Document Message, a Kettering XML MESH message, or an ITI-105 publish. The referral identifier must be carried through each step.