Discharge letters & medical report generation

Physicians spend a large part of their day writing letters that mostly restate what is already in the record. An LLM that reads the whole stay, extracts diagnoses, course, findings and medication changes, and drafts the letter in the clinic's template can cut this effort sharply. The physician stays responsible: every draft is reviewed, corrected and signed, and each statement should be traceable to its source note.

Problem & value

• Today: at discharge the resident reads days or weeks of notes, copies lab values and findings, reconciles medication and dictates or types the letter, often hours or days after the patient has left. Late or incomplete letters delay follow-up by the GP and are a known patient-safety risk (missing pending results, unclear medication changes).
• AI value: a first draft available at discharge, consistent structure (diagnoses, anamnesis, course, findings, therapy, recommendations, medication), less copy-paste work, and reuse of the same pipeline for other reports (referral replies, insurer reports, rehabilitation applications, expert opinions).
• Evidence: studies of LLM-drafted discharge summaries report time savings and acceptable quality but also omissions and hallucinated details, which is why review is mandatory [1][2]. Vendor claims on minutes saved per letter vary and should be verified in your own pilot.
• Regulatory pull in the EU: the European Health Data Space (EHDS) regulation pushes structured patient summaries and interoperable records, which makes structured source data and clean output formats more important [3].

Variants

• Hospital inpatient discharge letter (main case): KIS integration, per-department templates.
• Outpatient and practice reports: Arztbrief from consultation notes, often combined with an AI scribe (HLTH-003).
• Specialist reports: operative reports, radiology or pathology follow-up letters, rehab and psychiatric reports with stricter content rules.
• Insurer and authority reports: medical reports for health insurers, pension insurers or courts (drafting support only; the expert opinion itself remains human).
• Patient-facing version: plain-language summary and translation into the patient's language, labelled as a derived text.
• Private use: patients can use consumer assistants to explain a letter they already hold; this is not a clinical use and is out of scope here (see HLTH-030 for patient communication).

How it works

1. trigger (discharge planned / order "letter")
2. collect record (KIS/EHR via FHIR/HL7, notes, labs, imaging reports, scans via OCR)
3. structure & select (timeline, problem list, medication changes, pending results)
4. draft generation (LLM, template-constrained, per-section prompts)
5. grounding check (each claim linked to a source note; numbers copied verbatim)
6. physician review in the editor (diff view, source highlights, missing-item hints)
7. signature
8. write-back to KIS, dispatch (KIM/e-letter, GP, patient)

• Extraction before writing: a two-stage design (first extract facts into a structured timeline, then write prose from that) reduces hallucinations versus feeding raw notes into one prompt.
• Medication: values and doses are taken from structured medication data, not generated; the LLM only explains changes.
• Guardrails: reject drafts with unsupported claims, check for missing mandatory sections, flag pending results.
• Human-in-the-loop: physician edits and signs; the system stores draft, edits and final version for audit and quality measurement.

Data preparation

The source is the patient record: physician notes, nursing documentation, lab and imaging reports, medication plans and earlier letters. They live in the hospital or practice information system, partly in PDFs, scanned external findings and dictations, and in templates on file shares. Typical gaps: free-text notes with local abbreviations, scans without OCR, contradictory entries, missing structure for diagnoses (ICD-10) and procedures (OPS), outdated letter templates and unclear access rights per ward.

Preparation steps: (1) inventory record sources and owners (PREP-001, PREP-004); (2) export through the vendor's interfaces (HL7/FHIR) (PREP-005); (3) digitise and OCR external findings (PREP-006); (4) collect good example letters per specialty as gold standards (PREP-016); (5) build an abbreviation and terminology list (PREP-015); (6) clean up templates and access rights (PREP-009, PREP-023); (7) pseudonymise any data used for testing (PREP-022). Tools: Whisper for dictation, Paperless-ngx or OCR for scans.

Plan about half of the effort for data access and quality; the model work is the smaller part. See GUIDE-003 and DOC-014.

Implementation paths

Which path for whom

• SMB (medical practices, small clinics): Path A, because the practice or hospital information system vendor usually offers an integrated, certified dictation and letter module at a manageable price.
• Enterprise (hospital groups): Path C, because patient records are highly sensitive and a self-hosted speech and LLM stack serves several documentation use cases (Baukasten effect).
• Developer: Path C, because open-weight models and Whisper allow building and testing letter drafting on local hardware without patient data leaving.
• Public (municipal and university hospitals): Path C on in-house or sovereign infrastructure, because health data and procurement rules favour control.

Path A — Buy (recommended)

• EHR-native: Epic (generative drafting in its AI features), Oracle Health clinical AI agent, Meditech; in the DACH area KIS vendors such as Dedalus (ORBIS), CGM, Meierhofer, and Nexus are adding LLM letter drafting. Check what your KIS vendor already offers first.
• Specialist vendors (EU marked): Microsoft Dragon Copilot (successor of Nuance DAX Copilot), Abridge, Suki (US); Tandem Health (SE, EU), Nabla (FR, EU), Doctolib AI assistant (FR, EU), Heidi Health. Check each tool's current MDR status.
• Choose A when: you have a mainstream KIS/PVS with a certified integration, want vendor liability and MDR status clarified, and do not have an ML team.

Path B — Build on cloud APIs

• Models: Claude, Gemini, GPT via EU-region endpoints (Azure OpenAI EU Data Zone, Google Vertex EU, AWS Bedrock Frankfurt); Mistral (EU provider) for EU-only processing.
• Stack: FHIR server or KIS export, OCR/document parsing (Azure Document Intelligence, Mistral OCR), structured outputs with JSON schema, orchestration with n8n or a custom service, letter editor embedded in the KIS.
• Requirements: data processing agreement, no training on inputs, EU data residency, pseudonymisation where possible, and a DPIA.

Path C — Self-host (open source)

• Models: open-weight LLMs such as Llama, Qwen, Mistral and Gemma families; medical variants such as MedGemma; German clinical text benefits from models evaluated on German data. Serve with vLLM or Ollama.
• Parsing and de-identification: Docling or PaddleOCR for scans; Microsoft Presidio or clinical NER for PII handling; HAPI FHIR as FHIR server.
• Hardware: HW3 (one 48-141 GB GPU) for ~30-70B quantised models; HW2 works for ~8-30B models with simpler templates.
• Effort: needs an ML/platform team and clinical validation; common in university hospitals with data protection constraints.

Path D — Custom training

Fine-tuning (LoRA) on a few thousand in-house letters can adapt style, abbreviations and department templates, and enable smaller models. Requires de-identified or consented data, ethics/DPO sign-off and a held-out evaluation set rated by clinicians. Corrections from physician review are the best training signal.

State of the art (2026)

• Frontier and strong open models write fluent letters; the main issue is faithfulness, not fluency. Typical failure modes: omitted diagnoses or pending results, wrong temporal ordering, invented findings, copied outdated medication, and carrying over negated findings ("no pneumonia").
• Benchmarks and shared tasks (e.g. BioNLP/ACL discharge summary tasks on MIMIC-IV-based data) and clinician-rated evaluations are used; automatic metrics such as ROUGE correlate poorly with clinical safety, so LLM-as-judge plus clinician review is common [2].
• Reasoning models help with medication reconciliation and contradictions, at higher cost and latency.
• Evaluation should be done per department; performance in German-language, abbreviation-heavy records is lower than in English benchmarks.

Shared resources & combinations

• Same stack as HLTH-003 (ambient notes feed the record), HLTH-018 (chart summarisation and record search), HLTH-025 (nursing documentation), HLTH-030 (patient messages).
• Downstream: HLTH-005 (coding and billing from the letter), HLTH-028 (terminology mapping and FHIR), HLTH-004 (decision support on the same record).
• Building blocks: DOC-014 (document parsing), LANG-009 (translation), shared self-hosted LLM server on HW3 and a FHIR integration layer.

Effort, cost & KPIs

• Path A: weeks to a few months (integration, template setup, pilot ward); per-user or per-letter licences.
• Path B: 3-6 months with security review, KIS integration and clinical validation.
• Path C: 6-12 months incl. infrastructure, validation and operations; GPU server plus staff.
• KPIs: time to finished letter, share of letters sent at discharge, edit distance between draft and final, omission and error rate from clinician audits, physician satisfaction, GP feedback, medication discrepancies found.

People & change

Involve management and the medical director first, then the chief physicians (process owners), IT and IT security, the data protection officer and the works council from the planning stage. Physicians and medical secretaries are the daily users and must co-design the templates and review flow.

Works council: yes. A drafting system that logs who edits, signs and how fast is objectively suited to monitor behaviour or performance, so §87(1) no. 6 BetrVG applies; §90(1) no. 3 requires timely information, §80(3) allows an AI expert. Public hospitals involve the Personalrat. Conclude a works agreement that bans individual performance evaluation (GUIDE-004).

Data protection: health data require a DPIA, AVV with every processor and DPO involvement (GUIDE-005).

AI literacy: support physicians with short trainings on checking drafts for hallucinated findings or wrong medication (GUIDE-006). Start with one ward or specialty as pilot, name an AI champion per ward, and communicate openly that the physician remains responsible and signs every letter. Address worries about extra checking effort with measured time savings (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: depends on function. Pure drafting and administrative text support is usually not high-risk by itself, but if the software is intended for medical purposes (e.g. suggests diagnoses or therapy) it can be a medical device under MDR (Rule 11, class IIa or higher), which makes it a high-risk AI system under Art. 6(1) and Annex I. Check the vendor's intended purpose and CE status. AI literacy (Art. 4) applies; transparency duties apply to patient-facing generated text [4].
• GDPR: health data is special-category data (Art. 9); needs legal basis (care provision, Art. 9(2)(h) plus national law such as state hospital laws), DPIA, processor agreement, EU hosting, strict access control. Medical confidentiality (§203 StGB) restricts use of external service providers; use contractual confidentiality duties.
• Medical liability: the signing physician remains responsible; document the review process.
• Risks and mitigations: hallucination (source citations, structured medication data), automation bias (show omissions, require section confirmation, do not pre-sign), prompt injection from scanned or external documents (treat external text as data), data leakage (no consumer chat tools, EU endpoints), template drift (regular audits).

Getting started

1. Pick one ward and 100 past stays; define the letter template and what counts as an error.
2. Check what your KIS vendor and an existing AI scribe already provide before building anything.
3. Run a retrospective test: generate drafts, have two physicians rate omissions, hallucinations and usefulness.
4. Run the DPIA and check MDR status or intended purpose; involve the data protection officer and the works council.
5. Pilot with editing-and-signing in the KIS, measure the KPIs for 8 weeks, then extend ward by ward.

Sources

1. Williams CYK et al., "Evaluating the use of large language models to provide clinical recommendations / draft discharge summaries" (JAMA Network Open and related studies) — https://jamanetwork.com/journals/jamanetworkopen
2. Van Veen D et al., "Adapted large language models can outperform medical experts in clinical text summarization", Nature Medicine 2024 — https://www.nature.com/articles/s41591-024-02855-5
3. European Commission — European Health Data Space — https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
6. MIMIC-IV-Note / PhysioNet — https://physionet.org/content/mimic-iv-note/
7. Google Health AI, MedGemma — https://developers.google.com/health-ai-developer-foundations/medgemma