Entlassbriefe und Erstellung ärztlicher Berichte

Ärztinnen und Ärzte verbringen einen großen Teil ihres Tages mit Briefen, die meist nur wiedergeben, was bereits in der Akte steht. Ein LLM, das den gesamten Aufenthalt liest, Diagnosen, Verlauf, Befunde und Medikationsänderungen extrahiert und den Brief in der Vorlage der Klinik entwirft, kann diesen Aufwand deutlich senken. Die Verantwortung bleibt beim Arzt: Jeder Entwurf wird geprüft, korrigiert und unterschrieben, und jede Aussage sollte sich auf ihre Quellnotiz zurückführen lassen.

Problem & Nutzen

• Heute: Bei der Entlassung liest die Assistenzärztin bzw. der Assistenzarzt die Notizen von Tagen oder Wochen, kopiert Laborwerte und Befunde, gleicht die Medikation ab und diktiert oder tippt den Brief, oft Stunden oder Tage nach der Entlassung. Späte oder unvollständige Briefe verzögern die Weiterbehandlung durch den Hausarzt und sind ein bekanntes Risiko für die Patientensicherheit (fehlende ausstehende Befunde, unklare Medikationsänderungen).
• KI-Nutzen: ein erster Entwurf bereits bei der Entlassung, einheitliche Struktur (Diagnosen, Anamnese, Verlauf, Befunde, Therapie, Empfehlungen, Medikation), weniger Copy-and-paste-Arbeit und Wiederverwendung derselben Pipeline für weitere Berichte (Antworten auf Zuweisungen, Berichte an Versicherer, Reha-Anträge, Gutachten).
• Evidenz: Studien zu LLM-erstellten Entlassberichten berichten von Zeitersparnis und akzeptabler Qualität, aber auch von Auslassungen und erfundenen Details; deshalb ist die Prüfung zwingend [1][2]. Herstellerangaben zu eingesparten Minuten je Brief schwanken und sollten im eigenen Pilot überprüft werden.
• Regulatorischer Rückenwind in der EU: Die Verordnung zum Europäischen Gesundheitsdatenraum (EHDS) fördert strukturierte Patientenkurzakten und interoperable Akten, wodurch strukturierte Quelldaten und saubere Ausgabeformate wichtiger werden [3].

Varianten

• Stationärer Entlassbrief im Krankenhaus (Hauptfall): KIS-Integration, Vorlagen je Fachabteilung.
• Ambulante Berichte und Praxisberichte: Arztbrief aus Konsultationsnotizen, oft kombiniert mit einem KI-Scribe (HLTH-003).
• Fachberichte: OP-Berichte, Nachsorgebriefe der Radiologie oder Pathologie, Reha- und psychiatrische Berichte mit strengeren inhaltlichen Vorgaben.
• Berichte an Versicherer und Behörden: ärztliche Berichte für Krankenkassen, Rentenversicherer oder Gerichte (nur Entwurfsunterstützung; das Gutachten selbst bleibt menschlich).
• Patientenversion: Zusammenfassung in einfacher Sprache und Übersetzung in die Sprache der Patientin bzw. des Patienten, gekennzeichnet als abgeleiteter Text.
• Private Nutzung: Patienten können Verbraucher-Assistenten nutzen, um einen Brief zu erklären, den sie bereits besitzen; das ist keine klinische Nutzung und hier nicht Gegenstand (zur Patientenkommunikation siehe HLTH-030).

So funktioniert es

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)

• Extraktion vor dem Schreiben: Ein zweistufiges Vorgehen (zuerst Fakten in eine strukturierte Zeitleiste extrahieren, dann daraus den Text schreiben) verringert Halluzinationen gegenüber dem Einspeisen roher Notizen in einen einzigen Prompt.
• Medikation: Werte und Dosierungen werden aus strukturierten Medikationsdaten übernommen, nicht generiert; das LLM erläutert nur die Änderungen.
• Leitplanken: Entwürfe mit nicht belegten Aussagen ablehnen, auf fehlende Pflichtabschnitte prüfen, ausstehende Befunde markieren.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Ärztin bzw. der Arzt bearbeitet und unterschreibt; das System speichert Entwurf, Änderungen und Endfassung für Audit und Qualitätsmessung.

Datenaufbereitung

Die Quelle ist die Patientenakte: ärztliche Notizen, Pflegedokumentation, Labor- und Bildgebungsbefunde, Medikationspläne und frühere Briefe. Sie liegen im Krankenhaus- oder Praxisinformationssystem, teils in PDFs, eingescannten externen Befunden und Diktaten sowie in Vorlagen auf Dateiservern. Typische Lücken: Freitextnotizen mit lokalen Abkürzungen, Scans ohne OCR, widersprüchliche Einträge, fehlende Struktur bei Diagnosen (ICD-10) und Prozeduren (OPS), veraltete Briefvorlagen und unklare Zugriffsrechte je Station.

Schritte der Aufbereitung: (1) Aktenquellen und Verantwortliche erfassen (PREP-001, PREP-004); (2) Export über die Schnittstellen des Herstellers (HL7/FHIR) (PREP-005); (3) externe Befunde digitalisieren und per OCR erfassen (PREP-006); (4) gute Beispielbriefe je Fachgebiet als Referenzstandard sammeln (PREP-016); (5) eine Liste von Abkürzungen und Fachbegriffen aufbauen (PREP-015); (6) Vorlagen und Zugriffsrechte bereinigen (PREP-009, PREP-023); (7) alle für Tests verwendeten Daten pseudonymisieren (PREP-022). Werkzeuge: Whisper für Diktate, Paperless-ngx oder OCR für Scans.

Planen Sie etwa die Hälfte des Aufwands für Datenzugang und Datenqualität ein; die Modellarbeit ist der kleinere Teil. Siehe GUIDE-003 und DOC-014.

Umsetzungswege

Welcher Weg für wen

• KMU (Arztpraxen, kleine Kliniken): Weg A, weil der Hersteller des Praxis- oder Krankenhausinformationssystems meist ein integriertes, zertifiziertes Diktat- und Briefmodul zu einem überschaubaren Preis anbietet.
• Enterprise (Klinikverbünde): Weg C, weil Patientenakten hochsensibel sind und ein selbst betriebener Sprach- und LLM-Stack mehrere Dokumentations-Anwendungsfälle bedient (Baukasten-Effekt).
• Entwickler: Weg C, weil Open-Weight-Modelle und Whisper den Aufbau und Test der Briefentwürfe auf lokaler Hardware erlauben, ohne dass Patientendaten das Haus verlassen.
• Öffentlicher Sektor (kommunale Krankenhäuser und Universitätskliniken): Weg C auf eigener oder souveräner Infrastruktur, weil Gesundheitsdaten und Vergaberegeln Kontrolle begünstigen.

Weg A — Kaufen (empfohlen)

• EHR-nativ: Epic (generative Entwürfe in den KI-Funktionen), Oracle Health Clinical AI Agent, Meditech; im DACH-Raum ergänzen KIS-Hersteller wie Dedalus (ORBIS), CGM, Meierhofer und Nexus LLM-Briefentwürfe. Prüfen Sie zuerst, was Ihr KIS-Hersteller bereits anbietet.
• Spezialanbieter (EU-Markt): Microsoft Dragon Copilot (Nachfolger von Nuance DAX Copilot), Abridge, Suki (USA); Tandem Health (SE, EU), Nabla (FR, EU), Doctolib AI Assistant (FR, EU), Heidi Health. Prüfen Sie den aktuellen MDR-Status jedes Werkzeugs.
• A wählen, wenn: Sie ein gängiges KIS/PVS mit zertifizierter Integration haben, Herstellerhaftung und MDR-Status geklärt haben möchten und kein ML-Team besitzen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Claude, Gemini, GPT über Endpunkte in EU-Regionen (Azure OpenAI EU Data Zone, Google Vertex EU, AWS Bedrock Frankfurt); Mistral (EU-Anbieter) für rein europäische Verarbeitung.
• Stack: FHIR-Server oder KIS-Export, OCR/Dokumentenanalyse (Azure Document Intelligence, Mistral OCR), strukturierte Ausgaben mit JSON-Schema, Orchestrierung mit n8n oder einem eigenen Dienst, im KIS eingebetteter Briefeditor.
• Voraussetzungen: Auftragsverarbeitungsvertrag, kein Training mit Eingaben, Datenhaltung in der EU, Pseudonymisierung wo möglich und eine Datenschutz-Folgenabschätzung (DSFA).

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-LLMs wie die Familien Llama, Qwen, Mistral und Gemma; medizinische Varianten wie MedGemma; deutsche klinische Texte profitieren von Modellen, die auf deutschen Daten evaluiert wurden. Betrieb mit vLLM oder Ollama.
• Analyse und Anonymisierung: Docling oder PaddleOCR für Scans; Microsoft Presidio oder klinisches NER für den Umgang mit personenbezogenen Daten; HAPI FHIR als FHIR-Server.
• Hardware: HW3 (eine GPU mit 48-141 GB) für quantisierte Modelle mit ca. 30-70 Mrd. Parametern; HW2 genügt für Modelle mit ca. 8-30 Mrd. Parametern bei einfacheren Vorlagen.
• Aufwand: braucht ein ML-/Plattform-Team und klinische Validierung; verbreitet in Universitätskliniken mit Datenschutzauflagen.

Weg D — Eigenes Training

Feintuning (LoRA) auf einigen Tausend hauseigenen Briefen kann Stil, Abkürzungen und Abteilungsvorlagen anpassen und kleinere Modelle ermöglichen. Erfordert anonymisierte oder per Einwilligung freigegebene Daten, Freigabe durch Ethikkommission bzw. Datenschutzbeauftragte(n) und ein zurückgehaltenes Evaluationsset, das von Klinikern bewertet wird. Korrekturen aus der ärztlichen Prüfung sind das beste Trainingssignal.

Stand der Technik (2026)

• Führende und starke offene Modelle schreiben flüssige Briefe; das Hauptproblem ist die Treue zur Quelle, nicht die Flüssigkeit. Typische Fehlerarten: ausgelassene Diagnosen oder ausstehende Befunde, falsche zeitliche Reihenfolge, erfundene Befunde, übernommene veraltete Medikation und übernommene verneinte Befunde („keine Pneumonie“).
• Es werden Benchmarks und gemeinsame Aufgaben (z. B. BioNLP-/ACL-Aufgaben zu Entlassberichten auf Basis von MIMIC-IV) sowie von Klinikern bewertete Evaluationen genutzt; automatische Metriken wie ROUGE korrelieren schlecht mit klinischer Sicherheit, daher sind LLM-als-Richter plus klinische Prüfung üblich [2].
• Reasoning-Modelle helfen beim Medikationsabgleich und bei Widersprüchen, bei höheren Kosten und längerer Latenz.
• Die Evaluation sollte je Abteilung erfolgen; die Leistung bei deutschsprachigen, abkürzungsreichen Akten ist geringer als bei englischen Benchmarks.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie HLTH-003 (Ambient Notes speisen die Akte), HLTH-018 (Aktenzusammenfassung und Aktensuche), HLTH-025 (Pflegedokumentation), HLTH-030 (Patientennachrichten).
• Nachgelagert: HLTH-005 (Kodierung und Abrechnung aus dem Brief), HLTH-028 (Terminologie-Mapping und FHIR), HLTH-004 (Entscheidungsunterstützung auf derselben Akte).
• Bausteine: DOC-014 (Dokumentenanalyse), LANG-009 (Übersetzung), gemeinsamer selbst betriebener LLM-Server auf HW3 und eine FHIR-Integrationsschicht.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis wenige Monate (Integration, Vorlagen einrichten, Pilotstation); Lizenzen je Nutzer oder je Brief.
• Weg B: 3-6 Monate mit Sicherheitsprüfung, KIS-Integration und klinischer Validierung.
• Weg C: 6-12 Monate inkl. Infrastruktur, Validierung und Betrieb; GPU-Server plus Personal.
• Kennzahlen: Zeit bis zum fertigen Brief, Anteil der bei Entlassung versandten Briefe, Änderungsabstand zwischen Entwurf und Endfassung, Auslassungs- und Fehlerrate aus klinischen Audits, Zufriedenheit der Ärzte, Rückmeldungen der Hausärzte, gefundene Medikationsabweichungen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsführung und die Ärztliche Direktion ein, dann die Chefärzte (Prozessverantwortliche), IT und IT-Sicherheit, die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten und ab der Planung den Betriebsrat. Ärzte und Medizinische Schreibkräfte sind die täglichen Nutzer und müssen Vorlagen und Prüfablauf mitgestalten.

Betriebsrat: ja. Ein Entwurfssystem, das protokolliert, wer wann bearbeitet und unterschreibt und wie schnell, ist objektiv geeignet, Verhalten oder Leistung zu überwachen, daher gilt § 87 Abs. 1 Nr. 6 BetrVG; § 90 Abs. 1 Nr. 3 verlangt die rechtzeitige Unterrichtung, § 80 Abs. 3 erlaubt einen KI-Sachverständigen. Öffentliche Krankenhäuser beteiligen den Personalrat. Schließen Sie eine Betriebsvereinbarung, die individuelle Leistungsbewertung ausschließt (GUIDE-004).

Datenschutz: Gesundheitsdaten erfordern eine DSFA, einen AVV mit jedem Auftragsverarbeiter und die Einbindung der bzw. des Datenschutzbeauftragten (GUIDE-005).

KI-Kompetenz: Unterstützen Sie Ärzte mit kurzen Schulungen zur Prüfung von Entwürfen auf erfundene Befunde oder falsche Medikation (GUIDE-006). Starten Sie mit einer Station oder einem Fachgebiet als Pilot, benennen Sie je Station einen KI-Champion und kommunizieren Sie offen, dass die Ärztin bzw. der Arzt verantwortlich bleibt und jeden Brief unterschreibt. Begegnen Sie Sorgen vor zusätzlichem Prüfaufwand mit gemessener Zeitersparnis (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): abhängig von der Funktion. Reine Entwurfs- und Verwaltungstextunterstützung ist für sich genommen meist nicht hochriskant, doch wenn die Software für medizinische Zwecke bestimmt ist (z. B. Diagnosen oder Therapie vorschlägt), kann sie ein Medizinprodukt nach MDR sein (Regel 11, Klasse IIa oder höher), was sie nach Art. 6 Abs. 1 und Anhang I zu einem Hochrisiko-KI-System macht. Prüfen Sie Zweckbestimmung und CE-Status des Herstellers. KI-Kompetenz (Art. 4) gilt; Transparenzpflichten gelten für generierte Texte, die sich an Patienten richten [4].
• DSGVO: Gesundheitsdaten sind besondere Kategorien personenbezogener Daten (Art. 9); erforderlich sind eine Rechtsgrundlage (Gesundheitsversorgung, Art. 9 Abs. 2 Buchst. h plus nationales Recht wie Landeskrankenhausgesetze), DSFA, Auftragsverarbeitungsvertrag, EU-Hosting und strenge Zugriffskontrolle. Die ärztliche Schweigepflicht (§ 203 StGB) schränkt den Einsatz externer Dienstleister ein; nutzen Sie vertragliche Verschwiegenheitspflichten.
• Ärztliche Haftung: Die unterzeichnende Ärztin bzw. der unterzeichnende Arzt bleibt verantwortlich; dokumentieren Sie den Prüfprozess.
• Risiken und Gegenmaßnahmen: Halluzination (Quellenangaben, strukturierte Medikationsdaten), Automatisierungsverzerrung (Auslassungen anzeigen, Bestätigung je Abschnitt verlangen, nicht vorab signieren), Prompt Injection aus gescannten oder externen Dokumenten (externen Text als Daten behandeln), Datenabfluss (keine Verbraucher-Chat-Werkzeuge, EU-Endpunkte), Vorlagen-Drift (regelmäßige Audits).

Erste Schritte

1. Wählen Sie eine Station und 100 zurückliegende Aufenthalte; legen Sie die Briefvorlage fest und definieren Sie, was als Fehler zählt.
2. Prüfen Sie, was Ihr KIS-Hersteller und ein vorhandener KI-Scribe bereits bieten, bevor Sie etwas aufbauen.
3. Führen Sie einen retrospektiven Test durch: Entwürfe erzeugen und von zwei Ärzten auf Auslassungen, Halluzinationen und Nutzen bewerten lassen.
4. Führen Sie die DSFA durch und prüfen Sie MDR-Status bzw. Zweckbestimmung; beziehen Sie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten und den Betriebsrat ein.
5. Pilotieren Sie mit Bearbeiten und Unterschreiben im KIS, messen Sie die Kennzahlen 8 Wochen lang und weiten Sie dann Station für Station aus.

Quellen

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