Katalog / Gesundheitswesen & Life Sciences / HLTH-018

Zusammenfassung von Patientenakten und Längsschnittsuche in Krankenakten für Ärztinnen und Ärzte

Die gesamte Längsschnittakte eines Patienten zusammenfassen und Fragen von Ärztinnen und Ärzten dazu beantworten, wobei jede Aussage mit ihrem Quelleintrag verlinkt ist.

Bausteine für den EigenbetriebDokumente lesenSprachmodellSuche & RAG

Kranken- und Praxisakten wachsen über Jahre zu Hunderten von Notizen, Laborreihen und externen Briefen an, und Ärztinnen und Ärzte haben nur Minuten, um das Wesentliche zu finden. Eine KI-Schicht über der Akte eines einzelnen Patienten erstellt eine Zusammenfassung vor dem Besuch und beantwortet Fragen wie „Wann wurde die Antikoagulation zuletzt geändert und warum?“, wobei sie für jede Aussage den genauen Quelleintrag nennt. Nutzen: weniger Zeit für die Aktendurchsicht und weniger übersehene Fakten, vorausgesetzt, die Zusammenfassungen bleiben überprüfbar und das System ist für seinen Verwendungszweck validiert.

Problem & Nutzen

  • Heute: Ärztinnen und Ärzte blättern durch das KIS oder PVS, öffnen PDFs anderer Leistungserbringer und rekonstruieren die Vorgeschichte von Hand, oft bei Aufnahme, Übergabe oder vor einem Gespräch. Relevante Fakten verstecken sich im Freitext und in externen Briefen; kopierte Textbausteine erzeugen zusätzliches Rauschen.
  • KI-Nutzen: ein verifizierter Überblick in Sekunden, Suche nach Bedeutung statt nach Stichwort und ein einheitliches Übergabeformat. Anbieter berichten von Zeitersparnissen, doch die Zahlen stammen aus Pilotprojekten der Anbieter; messen Sie lokal, bevor Sie sich darauf verlassen [1][2].
  • Abgrenzung zu Nachbarn: HLTH-003 transkribiert Gespräche, HLTH-011 schreibt ausgehende Briefe, DOC-007 strukturiert einzelne Dokumente und KNOW-010 beantwortet allgemeine medizinische Fragen. Dieser Anwendungsfall liest die Akte eines einzelnen Patienten mit besonderen Kategorien von Daten und muss sie belegen.
  • EU-Kontext: Die deutsche ePA (elektronische Patientenakte) und der Europäische Gesundheitsdatenraum (EHDS, Verordnung (EU) 2025/327) machen Patientenkurzakten und Medikationsdaten übertragbar, sodass eine Zusammenfassungsschicht zunehmend Akten mehrerer Leistungserbringer sieht [3].

Varianten

  • Kurzübersicht vor dem Besuch (ambulant): einseitige Zusammenfassung vor einem Termin aus PVS und ePA.
  • Aufnahme und Übergabe (Krankenhaus): problemorientierte Zusammenfassung für Visite, Schichtwechsel, Ankunft in der Notaufnahme.
  • Fragen beantworten („mit der Akte chatten“): Freitextanfragen mit belegten Antworten.
  • Längsschnitt-Zeitleiste: Verläufe von Laborwerten, Medikation, Gewicht oder Symptomen über Jahre.
  • Patientenseitige Zusammenfassung: allgemeinverständliche Sicht auf die eigene Akte; anderes Risikoprofil, siehe HLTH-030.
  • Fachspezifische Sichten: Onkologie (Behandlungsverlauf), Psychiatrie (hohe Sensibilität), Langzeitpflege.

So funktioniert es

  1. KIS / PVS / ePA (FHIR R4, HL7 v2, CDA, PDFs)
  2. Zugriffsprüfung (Behandlungsbeziehung, Rolle, Zweck)
  3. Umfang = EIN Patient
  4. Normalisierung (FHIR-Ressourcen; OCR für gescannte Briefe; Deduplizierung kopierter Texte)
  5. Index (hybrid: BM25 + Embeddings, Chunks behalten Ressourcen-ID, Datum, Autor)
  6. Retrieval + Reranking für Frage/Besuchskontext (z. B. kardiologische Verlaufskontrolle)
  7. LLM-Entwurf mit verpflichtenden Belegen auf Chunk-IDs
  8. Verifikation (Beleg vorhanden, Zitat stimmt, Daten/Einheiten/Dosierungen gegengeprüft)
  9. Ansicht für Ärztin/Arzt: Zusammenfassung mit Klick zur Quelle, „nicht gefunden“ ausdrücklich
  10. Audit-Log (wer hat was gefragt, welche Akten wurden gelesen)
  • Langer Kontext vs. Retrieval: Ganze Akten übersteigen oft, was ein Modell zuverlässig nutzt, selbst bei großen Kontextfenstern; produktive Systeme kombinieren strukturierte Voraggregation (Problemliste, aktive Medikation, letzte Werte) mit Retrieval und Map-Reduce-Zusammenfassung der Notizen.
  • Belegbarkeit (Grounding): Generierung mit Beleg zuerst; Sätze ohne überprüfbare Quelle werden entfernt oder markiert.
  • Terminologie: Die Abbildung auf SNOMED CT, LOINC, ICD-10-GM und ATC (siehe HLTH-028) lässt Anfragen wie „irgendein Antikoagulans“ über Handelsnamen hinweg funktionieren.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Die Ärztin bzw. der Arzt liest und bleibt verantwortlich; Zusammenfassungen werden nie ohne Prüfung als Fakten in die Akte zurückgeschrieben.

Datenaufbereitung

Die Daten liegen im Krankenhausinformationssystem oder KIS (Notizen, Laborwerte, Medikation, Problemlisten), in einem PACS/RIS für Befundberichte, in Dokumentenarchiven mit gescannten externen Briefen und zunehmend in der ePA und der EHDS-Patientenkurzakte. Typische Lücken: Freitextnotizen mit Abkürzungen und lokalem Jargon, gescannte Briefe und Faxe, doppelte oder zersplitterte Patientenidentitäten, fehlende Kodierung, widersprüchliche Medikationseinträge und feingranulare Zugriffsrechte, die der Behandlungsbeziehung folgen müssen.

Schritte der Aufbereitung: strukturierte und unstrukturierte Daten über FHIR- oder HL7-Schnittstellen herausholen (PREP-005); externe Briefe digitalisieren und per OCR erfassen (PREP-006, DOC-014); je Fachgebiet eine Abkürzungs- und Synonymliste aufbauen (PREP-015); die Regeln für Patientenidentität und Aktenverknüpfung festlegen; Rollen so abbilden, dass das Retrieval die Behandlungsbeziehung beachtet (PREP-023); alle für Entwicklung und Tests genutzten Daten pseudonymisieren (PREP-022); mit Ärztinnen und Ärzten einen Evaluationsdatensatz erstellen (PREP-018). Werkzeuge: HAPI FHIR, Docling oder Tesseract für Scans, ein Vektorindex je Patientenkontext. Die Prüfung in GUIDE-003 hilft bei der Abgrenzung. Grober Aufwand: 50 bis 60 Prozent des Projekts, da Schnittstellen, Identität und Zugriffsrechte überwiegen.

Umsetzungswege

Welcher Weg für wen

  • Enterprise (C): Vollständige Patientenakten enthalten besondere Kategorien personenbezogener Daten, und eine Plattform kann Zusammenfassung, Kodierung und Suche bedienen. Deshalb ist ein selbst betriebener Open-Weight-Stack im Krankenhausnetz (gemeinsame interne KI-Plattform) die bessere Basis als Produkte pro Arbeitsplatz.
  • Developer (C): Open-Weight-Modelle und FHIR-Werkzeuge erlauben es, in einer geschlossenen Umgebung zu bauen und zu validieren, ohne echte Patientendaten an Dritte zu senden.
  • Public (C): Öffentliche Krankenhäuser und Behörden brauchen typischerweise souveränen, On-Premises- oder deutschen/europäischen Government-Cloud-Betrieb; Kaufen ist nur eine Option, wenn der KIS-Anbieter ein zertifiziertes, in der EU gehostetes Modul anbietet.

Weg A — Kaufen (Standardsoftware)

  • KIS-nativ: Epics generative KI-Aktenzusammenfassungen (Epic hat seinen Sitz in den USA, ist auch in Europa im Einsatz), Oracle Health Clinical AI, Microsoft Dragon Copilot (ergänzt ambiente Notizen um Aktenkontext), Meditech Expanse AI [1]. Das hausinterne „Chart Hero“ von Penn Medicine zeigt die Richtung für im Krankenhaus entwickelte Werkzeuge [2].
  • EU-/DACH-Anbieter: CompuGroup Medical (CGM), Doctolib (FR; Assistenzprodukte) und Dedalus (IT, Krankenhausinformationssysteme) mit KI-Erweiterungen; die Verfügbarkeit schwankt, prüfen Sie daher die aktuellen Produktseiten.
  • A wählen, wenn: Ihr KIS-Anbieter ein validiertes Modul mit EU-Hosting anbietet und ein Auftragsverarbeitungsvertrag sowie die Einordnung nach MDR dokumentiert sind.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Modelle: Claude-, Gemini-, GPT- und Mistral-Modelle über Endpunkte in EU-Regionen (Azure OpenAI EU-Datenzone, Google Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme); Modelle mit langem Kontext und Funktionen für strukturierte Ausgabe und Belege.
  • Datenschicht: FHIR-Server (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake); hybride Suche in OpenSearch oder pgvector; Azure AI Search.
  • B wählen, wenn: Sie ein Entwicklungsteam, eine vorhandene FHIR-Fassade und einen AVV mit EU-Verarbeitung ohne Standardvertragsklauseln haben. Beachten Sie, dass Patientendaten bei einem Anbieter mit Hauptsitz in den USA weiterhin Fragen nach Kapitel V aufwerfen.

Weg C — Selbst betreiben (Open Source)

  • Modelle: Open-Weight-LLMs wie Llama 3.x/4, Qwen3, Mistral Small/Large, gpt-oss, Gemma 3 und medizinische Feintunings (MedGemma, OpenBioLLM); Betrieb mit vLLM oder llama.cpp.
  • Retrieval: BGE-M3- oder multilingual-e5-Embeddings, bge-reranker, OpenSearch oder pgvector; Docling für gescannte Briefe; deutsche klinische NER (z. B. Pipelines im Stil von medspaCy, GBERT-basierte Modelle).
  • Hardware: HW3 (eine GPU mit 48–96 GB) für ein quantisiertes Modell von ~30–70B, das eine Krankenhausabteilung bedient; HW4 für gleichzeitige Nutzung im ganzen Haus. Die Daten verlassen das Krankenhausnetz nie.
  • Passt zu Universitätskliniken und von den Ländern betriebenen Kliniken mit strengen Vorgaben zum Datenstandort.

Weg D — Eigenes Training

Selten der erste Schritt. Feintunen Sie Embedding- oder Reranker-Modelle auf hauseigenen Anfrage-/Dokumentpaaren oder trainieren Sie ein kleines Modell zur Klassifikation von Notiztypen sowie zur Erkennung von Negation und Zeitbezug. Erfordert von Ärztinnen und Ärzten gelabelte Beispiele und ethische bzw. datenschutzrechtliche Freigabe für die Zweitnutzung von Akten.

Stand der Technik (2026)

  • Evidenz: Studien zur klinischen Zusammenfassung mit LLMs berichten von Zusammenfassungen, die bei der Vollständigkeit als gleichwertig oder besser bewertet wurden als ärztlich verfasste, aber auch von Auslassungen, falschen Zuordnungen und Erfindungen [4].
  • Grenzen langer Kontexte: Die Leistung sinkt bei Fakten, die mitten in sehr langen Eingaben vergraben sind; Retrieval in Chunks plus strukturierte Voraggregation ist das robuste Muster.
  • Techniken: Dekodierung mit Belegzwang, Überprüfung auf Aussageebene durch einen zweiten Modelldurchlauf, FHIR-bewusste Werkzeugnutzung (der Agent fragt die FHIR-API nach dem „letzten HbA1c“, statt Text zu lesen), Behandlung von Zeitbezug und Negation („keine Vorgeschichte von X“).
  • Interoperabilität: FHIR R4 und die Prioritätskategorien des EHDS für Patientenkurzakte und Medikation [3].
  • Fehlerarten: ausgelassene seltene, aber kritische Fakten (Allergie, Antikoagulation), vertauschte Patienten oder Zeitverläufe, veralteter kopierter Text, der als aktuell dargestellt wird, übermäßiges Vertrauen (Automation Bias), Prompt Injection durch Text in externen Dokumenten.

Gemeinsame Bausteine & Kombinationen

  • Gleicher Stack (embedding-text, reranker, vector-db, llm-general): DOC-014 Dokumenten-Parsing für RAG, HLTH-004 klinische Entscheidungsunterstützung, HLTH-030 Entwurf von Nachrichtenantworten, HLTH-011 Entlassbriefe.
  • Vor- und nachgelagert: HLTH-003 liefert neue Gesprächsnotizen; die Terminologieabbildung aus HLTH-028 verbessert das Retrieval; HLTH-011 nutzt die Zusammenfassung als Entwurfsbasis weiter.
  • Infrastruktur: Ein selbst betriebener HW3-Modellserver plus eine FHIR-/Suchschicht kann alle klinischen Assistenten eines Krankenhauses bedienen.

Aufwand, Kosten & Kennzahlen

  • Weg A: Wochen bis Quartale, abhängig von der Roadmap des KIS-Anbieters, Verträgen und klinischer Governance.
  • Weg B: 3–6 Monate für einen validierten Pilot in einer Abteilung; die Kosten werden von Integration, Evaluation und Governance bestimmt, nicht von Tokens.
  • Weg C: 6–12 Monate plus GPU-Betriebsteam.
  • Kennzahlen: Zeit für die Aktendurchsicht je Patient, Anteil gültiger Belege, Auslassungsquote im Vergleich zu einer ärztlichen Referenz- zusammenfassung (Stichprobe), Akzeptanz- und Änderungsrate durch Ärztinnen und Ärzte, Sicherheitsvorfälle, Auffälligkeiten in Zugriffsprotokollen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsleitung und die Ärztliche Direktion für die Entscheidung und die klinische Verantwortung ein, dann die Stations- oder Abteilungsleitungen als Prozessverantwortliche. IT und IT-Sicherheit werden für Schnittstellen, Hosting und Zugriffskontrolle gebraucht; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte muss von Anfang an dabei sein, denn es handelt sich in großem Umfang um besondere Kategorien personenbezogener Daten (Art. 9 DSGVO), sodass eine Datenschutz-Folgenabschätzung (DSFA) erforderlich ist und ein Auftragsverarbeitungsvertrag (AVV) mit jedem Auftragsverarbeiter. Ärztinnen, Ärzte und Pflegekräfte sind die täglichen Nutzer und sollten mitgestalten, was eine Zusammenfassung enthalten muss und wie Quellen gezeigt werden.

Betriebsrat: in der Praxis ja. Zusammenfassungen und Suchprotokolle halten fest, wer welche Akte wann aufgerufen hat, wodurch das System objektiv zur Verhaltenskontrolle geeignet ist (§ 87 Abs. 1 Nr. 6 BetrVG, BAG); § 90 Abs. 1 Nr. 3 verlangt zudem rechtzeitige Information, und die Hinzuziehung eines KI-Sachverständigen gilt nach § 80 Abs. 3 als erforderlich. In öffentlichen Krankenhäusern gilt der Personalrat nach BPersVG oder Landesrecht. Vereinbaren Sie Umfang und Aufbewahrungsdauer der Protokolle sowie ein Verbot der Leistungsbewertung.

KI-Kompetenz (Art. 4 KI-Verordnung, Unterstützungsmaßnahmen): Schulen Sie zu Automation Bias, Auslassungen und zur Prüfung des zitierten Quelleintrags. Führen Sie einen Pilot auf einer Station und für einen Einsatzzweck durch (Übergabe oder Zusammenfassung vor dem Besuch), lassen Sie die Ärztin bzw. den Arzt Entscheidungsträger bleiben und machen Sie jede Aussage bis zu ihrer Quelle anklickbar. Begegnen Sie Sorgen wegen Zeitdrucks, indem Sie die eingesparte Dokumentationszeit messen, nicht die Ausgabemenge. Siehe GUIDE-004, GUIDE-005 und GUIDE-008.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): hängt vom Verwendungszweck ab. Ein Werkzeug, das nur zusammenfasst oder abruft, kann außerhalb der Definition eines Medizinprodukts liegen, doch eines, das Diagnose- oder Behandlungsentscheidungen unterstützt, ist wahrscheinlich Software als Medizinprodukt (MDR Regel 11, Klasse IIa oder höher) und damit Hochrisiko nach Art. 6 Abs. 1 mit Anhang I [5]. Anbieter sollten den Verwendungszweck ausdrücklich benennen; die Pflicht zur KI-Kompetenz (Art. 4) gilt für alle Betreiber. Keine verbotene Praxis nach Art. 5.
  • DSGVO: Gesundheitsdaten gehören zu den besonderen Kategorien (Art. 9); erforderlich sind eine Rechtsgrundlage für die Behandlung (Art. 9 Abs. 2 lit. h), eine DSFA (Art. 35), strikte rollenbasierte Zugriffe, beschränkt auf das behandelnde Team, Auftragsverarbeitungsverträge sowie nationale Regeln (z. B. § 630f BGB, Landeskrankenhausgesetze, Schweigepflicht nach § 203 StGB) [6].
  • EHDS: Regeln zur Primärnutzung (Patientenzugang, Kurzakten, Interoperabilität) treten in den kommenden Jahren stufenweise in Kraft; planen Sie mit EEHRxF-kompatiblen Daten [3].
  • Risiken und Gegenmaßnahmen: Halluzination und Auslassung (Belege, Verifikation, Stichprobenprüfungen); schleichende Ausweitung des Zugriffs (Umfang je Patient, Protokollierung); Verzerrung über Sprachen und Dialekte; Automation Bias (Quellen zeigen, nicht nur Schlussfolgerungen); Prompt Injection (Text der Akte als nicht vertrauenswürdige Daten behandeln, keine Werkzeugaktionen daraus ableiten).

Erste Schritte

  1. Wählen Sie einen Arbeitsablauf (z. B. Aufnahmezusammenfassung für die Innere Medizin) und erfassen Sie die aktuelle Zeit für die Aktendurchsicht.
  2. Prüfen Sie den Datenzugang: FHIR-API oder Export, ePA-Anbindung und eine DSFA, bevor ein Modell echte Daten sieht.
  3. Bauen Sie einen Referenzdatensatz aus 50–100 Akten mit von Ärztinnen und Ärzten verfassten Kernfakten, einschließlich Fallen (Allergien, Antikoagulantien, Negationen).
  4. Erstellen Sie einen Prototyp mit Retrieval mit Belegpflicht; messen Sie Auslassungen und Beleggültigkeit, nicht Sprachfluss.
  5. Klären Sie Verwendungszweck und MDR-Status mit dem Hersteller oder Ihrem Regulatory-Team und starten Sie dann einen Pilot mit Mensch-in-der-Schleife und einem Meldeweg für Vorfälle.

Quellen

  1. Epic Systems — AI and generative-AI features overview — https://www.epic.com/
  2. Penn Medicine / Penn Medicine News — AI tools for clinicians (Chart Hero) — https://www.pennmedicine.org/news
  3. Regulation (EU) 2025/327 — European Health Data Space — https://eur-lex.europa.eu/eli/reg/2025/327/oj
  4. Van Veen 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
  5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  6. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
  7. HL7 FHIR R4 specification — https://hl7.org/fhir/R4/
  8. MDCG 2019-11 — Guidance on qualification and classification of software under MDR — https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf