Discharge Summary Extraction AI for NHS Teams

A discharge summary is the handover document of the NHS. When a patient leaves an acute ward, the summary is meant to tell the GP what happened, what changed in the medication list, and what the practice now has to do. Under the 2026/27 NHS Standard Contract, the provider has 24 hours to send it. The trouble starts on the other side of that deadline, in the GP inbox and the community team's queue, where the document has to be read, understood and acted on.

On 10 July 2025 the Health Services Safety Investigations Body reported that patients are coming to harm because critical information is lost, delayed or missed when they leave hospital. A month later the government announced an AI tool to help doctors write discharge summaries faster. Both stories are about the same document, but they sit at opposite ends of it, and a Head of Digital deciding where AI belongs needs to keep the two ends apart.

This guide is about extraction on the receiving end: turning an inbound discharge summary into structured fields a person can check and act on. It covers the contract duty, what HSSIB found, how the national standard is meant to work, and where a private extraction model fits. It cedes the generic measurement of clinical extraction models to our clinical document extraction guide, the NHS supplier assessment detail to our post on the NHS SBS AI framework, and ambient scribing to our write-up of the London AI scribing programme.

This guide is shipped by the team behind Dilr Mira, private clinical small language models that turn clinical documents into source-grounded, schema-valid JSON on your own hardware. Or see DATS, the five-stage consulting system we use to place AI, from diagnosis through to production.

What is discharge summary extraction AI?

Discharge summary extraction AI is software that reads a hospital discharge summary and drafts structured fields from it: the diagnoses, the procedures, the medication changes, the investigation results and the actions requested of the GP. The output is a draft for a clinician or a trained administrator to check, not a decision. It matters most where a summary arrives as free text or a scanned letter rather than as coded data.

Two jobs get called "discharge summary AI", and they are different. One writes the summary on the hospital side, drawing on the patient record before the patient leaves. The other reads the summary on the receiving side, after it has arrived. The government tool announced in August 2025 is the first kind. A private extraction model such as Dilr Mira is the second.

The distinction is not academic. The writer sits inside the hospital's electronic patient record and has the whole admission to draw on. The reader has only the document in front of it, which is exactly the position of a GP practice, a community nursing team, a care home or an insurer handling a claim. That is why the evidence for one cannot be borrowed for the other. Our post on the 782-document Mira-Q2 scorecard sets out what a published evaluation can and cannot tell a deployment decision.

What does the NHS Standard Contract require of a discharge summary?

The NHS Standard Contract requires the provider, meaning the hospital or other NHS-funded service discharging the patient, to issue a discharge summary to the patient's GP or other referrer within 24 hours of an inpatient, day case or A&E discharge. The 2026/27 Service Conditions also require the provider to be able to send and receive summaries through every applicable delivery method at all times.

The clause is SC11.5 of the full-length Service Conditions. In the contract's own words, "When transferring or discharging a Service User from an inpatient or day case or accident and emergency Service, the Provider must within 24 hours following that transfer or discharge issue a Discharge Summary", and the same sentence goes on to name the GP, the referrer and any relevant third-party provider of health or social care as recipients.

Three neighbouring clauses fill in the rest of the picture:

• SC11.6A sets a faster signal: by 8.00am on the next operational day the provider must send a Post Event Message to the GP, where appropriate.
• SC11.7 covers outpatient care: where a GP needs to take prompt action, the provider must send a clinic letter as soon as reasonably practicable and in any event within 7 days.
• SC11.8 puts a duty on commissioners: they must use all reasonable endeavours to help the provider reach the national systems for electronic submission, and to make sure GPs can receive what is sent.

Notice who each duty binds. The 24-hour clock binds the provider that discharges the patient. It does not bind the GP practice, and it does not bind a software vendor. None of the clauses quoted here sets a clock for the receiving practice to read a summary or act on it, and much of what HSSIB documented sits on that receiving end. An organisation designing its post-discharge process should map those duties first, the same way our AI operating model work fixes ownership, through a RACI and a review cadence, before a system goes live.

What did HSSIB find goes wrong after discharge?

HSSIB found that patients come to harm when critical information is lost between hospital and community care. Its July 2025 investigation of the electronic discharge summary documented cases where follow-up actions were never done, systems that could not talk to each other, summaries that never reached every provider responsible for the patient, and no clear accountability for safety in the early days after discharge.

The full HSSIB report is worth reading in full by anyone who owns this pathway. Four of its findings bear directly on extraction:

1. Summaries are sometimes sent too early. HSSIB found cases where a summary was generated and sent before care had concluded, so the document the GP received was out of date.
2. The action for the GP is hard to find. GPs told the investigation that templates did not make it clear "up front" what the GP needed to do for the patient after discharge.
3. Coding is inconsistent. SNOMED CT is mandated for NHS providers' electronic records, and every GP practice the investigation visited used it, but not every hospital it visited did. The report also found no standardised layout and inconsistent use of clinical terms.
4. The risk has been normalised. The report says risks tied to the quality and timeliness of discharge correspondence have been normalised, and that the current approach to inspecting care quality does not lend itself to effective scrutiny of pathways that cross providers.

HSSIB made two safety recommendations. R/2025/065 asks NHS England and the Department of Health and Social Care, working with national bodies including the Professional Record Standards Body, to use user-centred design to develop and validate new discharge correspondence templates for primary and community care. R/2025/066 asks the Department to set expectations that NHS providers make safety-critical information accessible after discharge, with processes to complete safety-critical actions. Neither recommendation is addressed to suppliers, and neither is framed around AI.

That restraint is a useful guide. Extraction can make a buried action visible. It cannot make a summary arrive that was never sent, and it cannot correct a summary written before the procedure it should describe. Our healthcare sector analysis takes the same order of work: it starts from the sourced NHS problem, then maps where each DILR.AI line pays, rather than starting from the tool.

Writing the summary or reading it: which side does AI belong on?

AI can sit on either side of a discharge summary, and each side has a different owner, data set and risk. On the sending side, a tool drafts the summary from the hospital record before a clinician signs it off. On the receiving side, an extraction model reads what arrives and drafts structured fields for the practice. The NHS government pilot works on the sending side.

According to the GOV.UK announcement of 16 August 2025, the tool being developed at Chelsea and Westminster NHS Trust uses a large language model to extract key details such as diagnoses and test results from medical records, so doctors can draft discharge documents faster. A medical expert responsible for the patient reviews the draft before it is used. It is one of the Prime Minister's AI Exemplars. The announcement also notes that the current process can inaccurately record basic details such as treatment received or changes to medication.

The government's AI Knowledge Hub entry, created on 15 September 2025, lists the tool as in the Alpha phase and in pilot at Chelsea and Westminster, with its models hosted on the NHS Federated Data Platform. That is the status we could confirm on the date of writing; a reader should check the entry for anything newer before relying on it.

The two approaches are complements, not rivals. A hospital that writes better summaries helps every practice that receives them. A practice that reads summaries better is protected against the hospitals that do not. The sending-side tool has the richer data; the receiving-side model has the wider reach, because it works on whatever arrives, from any sender, in any format the model can read. The practical question for a Head of Digital is which side your organisation actually controls. A GP practice, a GP federation or an insurer controls only the receiving side.

If the PRSB standard already structures discharge summaries, why extract anything?

The PRSB eDischarge Summary Standard defines the content and structure of an electronic discharge summary, so that coded data can flow straight into the GP record. Where a hospital sends a fully coded summary to that standard, extraction adds little. Extraction earns its place on everything else: free-text sections, uncoded terms, scanned letters and summaries from senders outside the standard.

The Professional Record Standards Body describes the standard, now at version 2.1, as designed for sending coded and structured electronic discharges that can be used to populate primary care record systems. Its stated benefits include avoiding transcription errors when medication information moves into the GP record, and saving the time spent re-typing. From 1 January 2026 the standard is owned and managed by NHS England, which has said it will review the ongoing requirement for it.

HSSIB's findings show why the standard alone has not closed the gap. A summary can follow the PRSB headings and still carry its most important instruction as a sentence of free text. HSSIB also heard that even where SNOMED CT was used, a summary sent as a PDF removed the potential for interoperability. And the investigation heard mixed views on PRSB-informed templates: some found them too flexible and unstructured, while others thought they required too much information.

So the honest scope for extraction is narrow and specific:

• Free-text fields inside a structured summary, especially the actions requested of the GP and the reasons for medication changes.
• Uncoded or inconsistently coded terms, where a person still has to decide what the hospital meant.
• Documents that arrive as attachments or scans, for example letters from independent providers.
• Backlogs, where a practice needs to find the summaries with outstanding actions before it can work through them.

If your inbound summaries are fully coded and arrive on time, spend the money elsewhere. That is the kind of conclusion a placement diagnostic is designed to reach before anyone buys a model.

Which discharge summary fields can a model draft, and which must a person act on?

A clinical extraction model can draft the factual fields in a discharge summary: document type, encounter date and department, diagnoses, procedures, investigation results and the medication list as written. The decisions those facts trigger must stay with people: reconciling medication changes, booking follow-up tests, making referrals and judging whether the patient needs to be seen sooner.

A useful way to set the boundary is to ask what happens if the field is wrong. If a model misreads a haemoglobin result, a person checking the draft against the source should catch it, because every value in a well-built system points back to the sentence it came from. If a model misses a request to stop an anticoagulant, the cost of the miss lands on the patient. That second kind of field is why HSSIB's finding about buried actions matters, and why an extraction workflow should treat requested actions as a flag for review, never as a task closed by software.

The last row is a deliberate limit, not a gap to apologise for. Mira-Q2's published schema records a de-identified patient object of age and sex, never a name or medical record number. That keeps identifiers out of the model's output, but it means matching a summary to the right patient record stays inside the practice system and its existing workflow. Any vendor that claims to do both should show you exactly how.

The same split between drafting and deciding runs through our health insurance claims extraction guide, where the claims handler owns the decision, and our legal intake extraction guide, where the lawyer does. The principle carries across sectors because the failure mode is the same.

What can Mira-Q2 read in a discharge summary today?

Mira-Q2, the current release of Dilr Mira, is strongest on the document types it was trained on, and discharge summaries are one of them, alongside lab reports, medication lists, pathology reports, intake forms and progress notes, in English. It runs on the receiving organisation's own hardware, on-premises or air-gapped, and its outputs are drafts for human review.

DILR.AI's own published evaluation measures Mira-Q2 on 782 documents across four test sets, with zero identifier leaks recorded across all 782. On the held-out test set drawn from the same distribution as its training data, JSON validity is 100 percent and field-F1 is 1.000, with a 95 percent confidence interval of 0.999 to 1.0. On real physician documents across 39 specialties, JSON validity is 85.8 percent. Both figures come from the Mira-Q2 model card on Hugging Face, where the scorecard files are published for inspection. Mira-Q2 was trained on synthetic data, and the held-out set shares that distribution, so the 1.000 describes documents shaped like its training data, not real clinical letters. The gap between the two numbers is the honest summary: very strong on the shapes it learned, weaker on the long tail of real-world prose.

Three things follow for an NHS buyer:

• Test on your own summaries. The published figures tell you how the model behaved on its test sets, not on the letters your practices receive. A sample of real inbound summaries, checked by a clinician, is the only evidence that counts.
• Keep the verifier and the reviewer. The live Dilr Mira product page describes a deterministic verifier that checks schema validity, source grounding and identifier leaks before any output reaches a person, and a human review step after it. Neither replaces the other.
• Do not assume coding. Mira-Q2 drafts fields as text, such as a diagnosis written out in words. Turning a drafted diagnosis into a SNOMED CT code for the GP record is a separate step, and the published model card does not claim it.

Running on your own hardware is the property that changes the information governance conversation. Mira-Q2 runs on CPU and takes about 2 GB on disk, so a document never has to leave the organisation to be read. It does not remove the receiving organisation's own data protection and clinical safety duties. For the clinical safety and DTAC gates a supplier faces in NHS procurement, see our NHS SBS framework post. The newer Mira-3 generation, including multilingual support and zero-shot schemas, is in development and is not available today.

Where a pilot needs to move into production, our AI execution office, an embedded delivery team that builds a placement into your systems, stands up the evaluation harness and stays past go-live.

What is the best way to handle inbound discharge summaries in 2026?

The best approach in 2026 depends on what arrives. For coded summaries that follow the PRSB standard, the GP system's own filing workflow is usually the right tool, and AI adds little. For free-text, scanned or inconsistently coded summaries, a private extraction model that drafts fields for review can surface buried actions, provided every field traces to its source and a person acts.

Set against the alternatives, the trade-offs are clear. A cloud service such as Amazon Comprehend Medical, which AWS describes as a HIPAA-eligible service that extracts health data such as prescriptions, procedures and diagnoses from medical text, offers managed infrastructure at scale. For an organisation already comfortable sending clinical documents to that platform it may be the faster route, and that is a real case where the cloud service wins. A general-purpose large language model can read almost anything, but it does not usually come with an evaluation on documents like yours, so the testing burden falls on you. A sending-side tool such as the NHS pilot improves the summaries at source but only for the hospitals that adopt it. A private model such as Mira-Q2 keeps the document on your hardware and publishes its evaluation, but covers a narrower set of document types and is strongest in English.

Whichever route you take, the McKinsey State of AI survey is a reminder of the odds: in November 2025 it found 88 percent of organisations using AI in at least one function, while only about 6 percent are AI high performers seeing material EBIT impact. In our experience the difference is rarely the model. It is whether the work around the model, the review step, the ownership of actions and the measurement, was designed first. Our approach treats that as the starting point, and the same thinking shapes our KYC document extraction guide, where extracting a field is kept separate from verifying it.

For a broader map of how Dilr Mira compares with biomedical models and cloud APIs, see the comparison section of our clinical extraction pillar, and for more sector guides browse the industries category.

Can an extraction model file a discharge summary into the GP record?

An extraction model such as Dilr Mira drafts structured fields from a discharge summary; it does not file anything by itself. Mira-Q2 keeps identifiers out of its output, recording age and sex only, so matching the summary to the right patient and filing it remain steps in the practice system, completed or checked by a person.

Is the NHS AI discharge summary tool available to every trust?

The AI-assisted discharge summary tool announced by the government in August 2025 was, on its September 2025 Knowledge Hub entry, in the Alpha phase and in pilot at Chelsea and Westminster NHS Trust. That entry does not describe national availability, so a trust should check the current status with NHS England before planning around it.

Want to see this on your own documents? Look at Dilr Mira and its published scorecard, read about our AI operating model design, see our DATS methodology, or read about Dilr.ai and the team behind it.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.