Written by Technical Team | Last updated 23.01.2026 | 14 minute read
Discharge is not a single moment; it is a chain of clinical decisions, communications, reconciliations, and confirmations that begins before the patient leaves and continues until the next care setting is genuinely equipped to take over. In the NHS, that handover has historically been fragile: discharge summaries arrive late, key medication changes are buried in narrative text, follow-up plans are unclear, and primary care has to chase information that should have travelled with the patient.
The NHS Transfer of Care approach tackles this by standardising what discharge information should look like and how it is shared, using HL7 FHIR resources packaged as structured messages and documents. For integration teams, this changes the practical problem from “How do we generate a discharge letter?” to “How do we reliably model, assemble, transmit, receive, and render clinically safe FHIR content in a way that fits real discharge workflows?”
This article gets into the hands-on reality of implementing Transfer of Care style discharge interoperability: which FHIR resources do the heavy lifting, how to map hospital EPR data into a coherent discharge document, how messaging and transport choices affect workflow, and what you need operationally to move from a successful test to a service that clinicians trust.
The Transfer of Care ecosystem is best understood as a set of nationally aligned discharge and correspondence use cases (such as inpatient/day case discharge, emergency care discharge, mental health discharge, and outpatient clinic attendance), paired with FHIR-based message and document specifications that are designed to be consistently handled by different vendors. The goal is not just to “send something electronically”, but to send a clinically meaningful, structured payload that receiving systems can process safely and consistently.
For most providers, the integration challenge sits between three worlds: the operational discharge process in the hospital (where information is created incrementally), the constraints of the hospital’s source systems (EPR, ePMA, pathology, radiology, discharge module), and the requirements of receiving systems (often GP systems) that need the content to be precise, timely, and unambiguous. Transfer of Care succeeds when all three worlds meet: clinicians can complete discharge without extra clicks, information governance is satisfied, and the receiving practice gets a discharge that is both readable and computable.
A key practical point is that Transfer of Care style integrations are document-led, but resource-rich. That means the payload behaves like a “document” (it has a narrative structure with sections and a clinical context) while also embedding discrete resources (medication statements, allergies, problems, procedures, observations) that receiving systems can safely parse and file into the patient record. Treating it as “just a document” loses the computable value; treating it as “just data” loses the clinical narrative and safety cues. Your design needs both.
In implementation terms, you are typically building a pipeline that: detects or is triggered by a discharge event, gathers and normalises data across clinical domains, assembles a FHIR document bundle that matches the discharge use case, validates it against the relevant constraints, and transmits it using the required messaging and transport arrangements. On the receiving side, the workflow is equally important: the GP system (or an intermediary) must accept, reconcile, render, and file the content in a way that does not create extra administrative burden.
Finally, it’s worth acknowledging that “discharge” is not uniform across the NHS. Emergency care discharge has different rhythms from elective day case discharge; mental health discharge may involve different audiences and risk information; and inpatient discharge often requires reconciliation between multiple teams. A robust integration design anticipates variation: content can be optional, late, or corrected; discharge timing can change; and responsibility can be distributed.
At the heart of a Transfer of Care discharge is a FHIR document bundle. Conceptually, this is a packet that answers: who is the patient, what encounter is this about, what happened, what changed, what should happen next, and who is responsible. FHIR provides the building blocks; your job is to assemble them into a clinically coherent whole.
A document bundle typically has a “spine” made up of a small set of resources that establish clinical context. The Patient resource is the anchor identity. Encounter captures the clinical episode and is particularly useful for separating multiple concurrent care episodes. Organisation and Practitioner/PractitionerRole establish provenance: which organisation is issuing the discharge and which clinicians were responsible. If you have location and service context (ward, specialty), include it in ways that the receiving system can display sensibly without guessing.
The next step is to represent the discharge summary itself as a Composition resource. Composition is where you define the document type, its author(s), its subject (the patient), the encounter, and—crucially—its sections. Sections are not merely cosmetic; they are how you guide safe reading. A well-structured Composition makes it clear where to find diagnoses, investigations, medication changes, follow-up plans, and safety-critical advice. Where possible, each section should point to the discrete FHIR resources that support it (for example, the medication section references MedicationStatement and/or MedicationRequest items).
Discharge content usually spans multiple clinical domains, and this is where careful modelling matters. Conditions can represent diagnoses and problems; Procedures capture operations and interventions; Observations carry measured results (such as vitals or key lab values); DiagnosticReport can summarise investigation panels; and ServiceRequest can represent follow-up tests. The objective is not to dump everything: it is to include the “transfer-critical” subset that supports continuity of care and reduces rework in primary care. A discharge that includes every observation from a two-week admission becomes unreadable and potentially unsafe.
Medication is often the most operationally valuable and the most clinically sensitive domain. You need to represent: what the patient is taking at discharge, what changed compared with pre-admission, and the reasons for change. Depending on your local systems and the constraints of the receiving environment, you may use MedicationStatement to communicate “the medication list at discharge”, and MedicationRequest to communicate intended ongoing therapy directions. If you have an ePMA, pay attention to dose syntax, timing, and route. Free-text dosage instructions are a safety risk; overly granular dose structures that receiving systems cannot render are also a risk. The best approach is to generate structured dosage directions where you can do so safely, and include human-readable instructions that match what the patient has been told.
Allergies and intolerances should be represented with AllergyIntolerance. Here, accuracy and status matter: distinguishing “confirmed allergy” from “unverified history” changes prescribing behaviour. If your source systems are inconsistent, invest in data quality rules before sending—because once primary care receives an allergy entry, it can be difficult to unwind.
Plans and follow-up responsibilities are where discharges often fail. CarePlan can represent the overall plan (including follow-up arrangements), while Task can be used where explicit actions are needed. However, avoid overengineering: if your local discharge process does not reliably capture tasks in a structured way, forcing a Task model may produce misleading data. In that case, focus on a clear plan narrative in Composition and include structured ServiceRequest resources for follow-up tests and referrals that your systems can support.
Provenance is not optional in practice; it is how you defend clinical safety and traceability. Use provenance-like information to ensure a receiver can see what system created the discharge, when it was authored, and by whom. In real workflows, discharge drafts may be written by a junior doctor and authorised by a consultant; your modelling should reflect that distinction where feasible. Auditability supports both clinical governance and operational troubleshooting.
Transfer of Care discharge integrations are as much about delivery as they are about content. Your FHIR bundle can be perfectly modelled and still fail in practice if the transport and workflow do not fit operational reality. Message-based patterns are particularly well suited to discharge because discharge is event-driven: something has happened (or will happen soon), and someone else must be notified with sufficient context.
In many NHS implementations, the transport mechanism is a secure messaging channel rather than an open query API. That has consequences. You typically do not “GET discharge summary for patient X”; instead, you “SEND discharge summary for patient X to recipient Y”. This shifts your system design towards reliable event detection, queueing, retry handling, and idempotency. It also changes how you handle corrections: a corrected discharge is a new message that references or supersedes the previous one, not a silent update that the receiver may never see.
A practical architecture often includes an integration layer that sits between the EPR and the messaging endpoint. This layer is responsible for transforming data, assembling the FHIR document bundle, applying business rules, and handling transport-level concerns. Treat this as a product, not a one-off script. If it is not observable, supportable, and change-controlled, it will become a bottleneck the first time a discharge fails on a Friday evening.
Because discharge touches sensitive personal data, security and assurance are not afterthoughts. You need to design for authentication and authorisation, least privilege access to source systems, secure storage (including transient storage in queues), and a clear audit trail of message creation and transmission. In practice, you will also need robust handling of recipient selection: sending to the wrong GP practice is not a “minor defect”; it is a reportable incident risk. Recipient resolution should be deterministic, explainable, and testable, using the best available identifiers and matching logic.
Operational resilience matters because discharge is time-critical. Build for partial failure: if the ePMA is down, can you still send a discharge with a clearly stated limitation? If your messaging channel is delayed, can you queue safely without duplicating? If your validation rejects a message, can clinical staff see what’s missing and correct it without calling IT? Discharge interoperability succeeds when it degrades gracefully rather than collapsing.
In designing your flow, it helps to make explicit choices about:
The most successful implementations treat transport, workflow, and clinical behaviour as a single system. If you only focus on the FHIR payload, you will get a technically correct discharge that does not arrive at the right time, does not reach the right recipient, or is not trusted by clinicians.
Implementation work goes faster when you treat it as a sequence of deliverable capabilities rather than a single “integration project”. The aim is to get to a clinically usable discharge flow early, then iterate by adding richer content and better workflow support.
Start by defining the minimum viable discharge payload that is still clinically safe and operationally valuable. In practice, that usually means: patient identity, encounter context, principal diagnosis/problem list, discharge date/time, responsible clinician/service, medications at discharge (with clear changes), allergies, follow-up instructions, and contact information for queries. Do not begin by attempting to include every possible data item; your first success criteria should be “GP can file and act on this without chasing”.
Mapping is where most time is lost, particularly when hospital systems store the “same concept” in different places. For example, diagnoses may exist as coded problems, discharge coding entries, and narrative text, all differing slightly. Medication may exist as inpatient charting, discharge prescriptions, and pharmacy dispenses. Decide which sources are authoritative for discharge communication and document that decision. Once you have chosen the source, enforce it consistently in your transformation logic; inconsistent sourcing will create clinically confusing outputs.
Validation must be treated as part of your build, not a final gate. Structural validity (FHIR schema correctness) is the easy part. The harder part is profile and business-rule validity: required fields present, consistent identifiers, safe code systems, and coherent references between resources. Invest in automated validation in your pipeline, and make validation errors human-readable. If the error says “element missing”, your operational users need to know whether that means “the consultant hasn’t signed” or “the EPR has no GP practice recorded”.
A practical build sequence looks like this:
Testing needs two audiences: integration assurance and clinical users. Integration assurance testing checks that messages are sent, received, and processed across environments, including edge cases such as long admissions, multiple consultant episodes, and missing GP details. Clinical testing checks that the resulting discharge is readable, trustworthy, and does not create additional work. It is common to “pass” technical testing and still fail clinical adoption because the discharge is too long, ambiguous, or inconsistent with what the patient was told.
When you begin to enrich content, prioritise additions that reduce workload in primary care. For example, clearly structured medication changes (stopped/started/changed with reasons) can reduce follow-up calls and re-prescribing errors. Explicit follow-up responsibilities (“GP to repeat U&Es in 7 days” vs “bloods in a week”) reduce ambiguity. If you include investigation results, include interpretation when it changes management; raw numbers without context are less useful.
Finally, plan your go-live as an operational change, not just a technical release. Discharge teams need to know what “good” looks like, what to do when recipient details are missing, and how to handle an amended discharge. Primary care needs to know how the discharge will arrive, how it will be filed, and what to expect when something is corrected.
Once your integration is live, the real work begins: keeping it safe, reliable, and aligned to changing clinical practice. Discharge content is safety-critical, so your operational model should treat the integration as part of the clinical system, not merely an interface.
Clinical safety assurance is not a box-ticking exercise. A small transformation bug—such as swapping dose units, truncating free-text, or mislabelling “stopped” as “active”—can create direct patient harm. Build explicit safety controls into your service: automated checks for clinically implausible values, warnings for missing critical fields, and clear handling of uncertain data. Where your source data is incomplete, design the output to be honest about uncertainty rather than silently filling gaps.
Information governance is equally practical. You need to be clear about lawful basis for sharing, role-based access in source systems, secure handling of payloads, and retention policies for transient message stores. Discharge messaging should minimise unnecessary exposure by sending to the correct recipient only, while still ensuring that the recipient has enough context to act safely. “Less data” is not always “safer”; omission of key risk information can also be unsafe. Your governance model should support a balanced, clinically informed approach.
Optimisation is where teams unlock the real value of Transfer of Care. Once the flow is stable, measure what matters: time from discharge to receipt in primary care, percentage of discharges with structured medication changes, rate of amended discharges, failure rates by cause, and the volume of manual chasing. Use those measures to prioritise improvements that reduce clinical friction.
Common operational improvement areas include:
There is also a long-term architectural opportunity: using the same FHIR resource mapping investment to support other transitions of care and correspondence types. Once you have robust Patient/Encounter identity handling, medication and allergy modelling, and a reliable document bundle assembler, you can extend into emergency care discharge, outpatient letters, and cross-organisation care planning with less incremental effort. The key is to build reusable mapping components rather than one discharge-specific transformation that cannot evolve.
In practice, the best indicator of success is behavioural rather than technical: do clinicians trust that the discharge will arrive, do they understand how it is structured, and does it reduce the need for follow-up clarification? When those answers are “yes”, you have moved beyond “integration complete” to a genuinely improved transfer of care.
Is your team looking for help with NHS Transfer of Care API integration? Click the button below.
Get in touch