Extraktion aus Patientenakten und Laborbefunden

Praxen, Kliniken, Versicherer und Patienten erhalten weiterhin einen großen Teil klinischer Informationen als PDF, Fax oder Papier: Laborbefunde, Entlassbriefe, Befunde. Dokumenten-KI liest diese Seiten, extrahiert Werte und Diagnosen in eine strukturierte, kodierte Form (FHIR, LOINC, ICD-10) und zeigt jeden Wert neben seiner Quelle an, damit ein Mensch ihn schnell verifizieren kann. Der Nutzen sind weniger manuelle Übertragung und durchsuchbare Akten; der Preis ist der strikte Umgang mit Gesundheitsdaten (DSGVO Art. 9) und, je nach Zweck, Vorschriften für Medizinprodukte oder Hochrisiko-Regeln der KI-Verordnung (AI Act).

Problem & Nutzen

• Heute: Laborbefunde externer Labore, Entlassbriefe und Überweisungen kommen als PDF, Fax oder Papier an und werden vom Personal abgelegt oder neu abgetippt. Die Werte sind nicht maschinenlesbar, sodass Verläufe, Warnhinweise und Entscheidungsunterstützung sie nicht nutzen können.
• KI-Nutzen: Extraktion von Analyten, Einheiten, Referenzbereichen und Kennzeichen; Kodierung von Diagnosen und Medikamenten aus Freitext; Vorausfüllen der Akte zur Prüfung; Indexierung für die Suche.
• Regulatorischer Sog: Die Verordnung über den Europäischen Gesundheitsdatenraum (EHDS) ist am 26. März 2025 in Kraft getreten; Patientenkurzakten müssen ab März 2029 EU-weit austauschbar sein, Laborergebnisse, medizinische Bilder und Entlassberichte ab März 2031. Vorhandene PDFs müssen in die von diesen Regelungen verlangten strukturierten Formate überführt werden [1].
• Quantifizierter Nutzen: Diese Datei nennt bewusst keine pauschale Genauigkeits- oder Zeitersparnisangabe. Veröffentlichte Zahlen hängen von Dokumentmix und Sprache ab; messen Sie an Ihren eigenen Beispielen (siehe Kennzahlen).

Varianten

• Ambulante Praxis / MVZ / Laborverbund: Import externer Laborbefunde und Überweisungsschreiben in das Praxisverwaltungssystem.
• Klinik: Entlassbrief- und Altaktendigitalisierung für das Krankenhausinformationssystem und die klinische Forschung (mit Anonymisierung nach DOC-018).
• Versicherer und Leistungsabwicklung: Extraktion aus ärztlichen Bescheinigungen, Rechnungen und Berichten für die Leistungsbearbeitung (Grenze zu DOC-017 und DOC-001); Entscheidungen über Leistungen werden hochriskant, siehe unten.
• Pharma / klinische Studien: Extraktion aus Quelldokumenten und Vorausfüllen von Prüfbögen (Case Report Forms).
• Private Nutzung: Patienten fotografieren Laborergebnisse und erhalten eine strukturierte Zeitleiste und eine allgemeinverständliche Erklärung; Unterlagen können in der elektronischen Patientenakte (ePA) geführt werden.

So funktioniert es

1. Eingang (Fax/E-Mail/Scanner/KIM/Portal/Foto)
2. Klassifikation (Laborbericht | Entlassbrief | Überweisung | sonstiges; DOC-008)
3. OCR + Layout-Parsing (Tabellen, Spalten mit Referenzbereichen, handschriftliche Stempel)
4. Extraktion gegen ein Schema (VLM oder Dokumentmodell)
5. JSON
6. Normalisierung (Analyt
7. LOINC, Einheit
8. UCUM, Diagnose
9. ICD-10-GM, Arzneimittel
10. ATC)
11. Validierung (Plausibilitätsbereiche, Einheitenkonsistenz, Abgleich der Patientenidentität, Duplikatprüfung)
12. menschliche Prüfung von Feldern mit niedriger Konfidenz mit Quellenmarkierung (Human-in-the-Loop)
13. Export (FHIR DiagnosticReport + Observation, HL7 v2, API des Praxissystems) + Audit-Log

• Parsing: Tabellen mit Einheiten und Referenzbereichen sind die Hauptfehlerquelle; layoutbewusste Parser erhalten die Zeilen-/Spaltenstruktur [5].
• Extraktion: Ein Vision-Language-Modell liefert JSON, das durch ein Schema eingeschränkt ist; Freitextabschnitte verarbeitet ein LLM oder ein klinisches NER-Modell.
• Kodierung: Terminologie-Abfrage (Retrieval über Codesysteme), statt ein Modell Codes raten zu lassen.
• Mensch-in-der-Schleife (Human-in-the-Loop): zwingend bei Patientenidentität, kritischen Werten und jedem Wert, der eine klinische Handlung auslöst. Das FHIR-Modell DiagnosticReport/Observation ist das natürliche Ziel: Ein Bericht verweist auf atomare Observations, kodiert mit LOINC [4].

Datenaufbereitung

Daten: Laborbefunde (PDF, Fax, Scan), Entlass- und Überweisungsbriefe, Befunde und Freitextnotizen sowie Referenzexporte (HL7 v2, LDT, GDT) und Codesysteme (LOINC, ICD-10-GM, ATC). In Praxen und Kliniken liegen sie im Praxis- oder Krankenhausinformationssystem, im DMS, in E-Mail- oder KIM-Postfächern, auf Faxservern und in Papierakten.

Typische Lücken: Scans in Faxqualität, laborspezifische Tabellenlayouts, lokale Analytnamen und Einheiten, fehlende Patientenkennungen, Duplikate, Abkürzungen im Freitext und strenge Zugriffsrechte je Abteilung.

Aufbereitungsschritte: 1. Quellen und Datenflüsse erfassen und den Umfang des Piloten festlegen (PREP-002, PREP-005). 2. Eine Beispielmenge für Entwicklung und Tests pseudonymisieren (PREP-022); echte Daten nur in der freigegebenen Umgebung. 3. Beispielbefunde je Labor und Dokumenttyp sammeln und von Klinikern Gold-Standard-Annotationen erstellen lassen (PREP-018, PREP-016). 4. Zuordnungslisten für lokale Analytnamen, Einheiten und Abkürzungen aufbauen (PREP-015). 5. Terminologien der Codesysteme für die Retrieval-basierte Kodierung laden. 6. Regeln zum Identitätsabgleich festlegen und Dokumente zuerst klassifizieren (DOC-008). 7. Rechtsgrundlage und Berechtigungen prüfen (PREP-025, PREP-024).

Werkzeuge: Terminologieserver, FHIR-Toolkits, OCR-/Layout-Parser, Pseudonymisierungsskripte.

Aufwandsanteil: 40-50 Prozent; Expertenannotation und Terminologie-Zuordnung dominieren. Siehe DOC-014, DOC-018 und GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Praxen sollten zertifizierte, in der EU gehostete Module oder Erweiterungen für ihr Praxissystem nutzen, statt die Verarbeitung sensibler Gesundheitsdaten selbst zu betreiben.
• Großunternehmen: Weg C. Kliniken und Versicherer verarbeiten besondere Kategorien von Gesundheitsdaten in großem Umfang, haben oft eine gemeinsame KI-Plattform und wollen, dass die Daten im eigenen Rechenzentrum bleiben.
• Entwickler: Weg B. Hersteller medizinischer Software können mit EU-Region-APIs und einem unterzeichneten AVV beginnen und auf Selbstbetrieb wechseln, wenn Volumen oder Kunden es verlangen.
• Öffentlicher Sektor: Weg C. Öffentliche Kliniken und Behörden brauchen souveränen Betrieb und vergaberechtskonforme, prüfbare Stacks.
• Privat: Weg A. Patienten erhalten die beste Bedienbarkeit mit zertifizierten Apps, die ihre eigenen Befunde ordnen; lokale Werkzeuge sind eine Option für technisch versierte Nutzer.

Weg A — Kaufen (für die meisten Praxen und Kliniken empfohlen)

• Klinisches NLP / Health Text Mining: Averbis (Deutschland, Health Text Mining für deutsche klinische Texte), John Snow Labs Spark NLP for Healthcare, Amazon Comprehend Medical, Microsoft Azure AI Language „Text Analytics for health“.
• Dokumentenerfassung mit medizinischem Schwerpunkt: ECM-/DMS- und Input-Management-Anbieter im deutschen Gesundheitswesen (z. B. DMS-Module von Praxis- und Krankenhaussystemen); allgemeine IDP-Plattformen wie ABBYY Vantage oder Hyland. Prüfen: EU-Hosting oder On-Premises, Auftragsverarbeitungsvertrag (AVV) mit Klauseln zu Gesundheitsdaten, FHIR-/HL7-/GDT-Schnittstellen, Zertifizierung durch den PVS-/KIS-Hersteller.
• A wählen, wenn: der Hersteller des Praxis- oder Krankenhaussystems bereits ein Importmodul anbietet; die Integration in das Aktensystem ist dann der schwierigste Teil und bleibt am besten beim Hersteller.
• Herstellerangaben zur Genauigkeit sollten vor dem Kauf an Ihren eigenen Dokumenten überprüft werden.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Parsing: Azure AI Document Intelligence (Layout-/Read-Modelle, EU-Regionen) [3], Google Document AI (EU-Standort), Mistral OCR / Document AI (französischer Anbieter; API mit Annotationen für strukturierte Ausgabe) [2].
• Extraktion: multimodale Spitzen-LLMs mit JSON-Schema-Ausgaben in EU-Regionen (Anthropic Claude über AWS Bedrock oder Google Vertex EU, Gemini auf Vertex EU, Azure OpenAI EU-Datenzone, Mistral).
• Terminologie und Speicherung: FHIR-Speicher (Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake).
• Erforderlich: unterzeichneter AVV, kein Training mit Eingaben, ausschließlich Verarbeitung in der EU und für Deutschland eine Prüfung nach §203 StGB (Berufsgeheimnis) und den Cloud-Anforderungen des §393 SGB V (C5-Testat) für Daten der gesetzlichen Krankenversicherung.
• B wählen, wenn: Sie ein Produkt oder eine eigene Pipeline bauen und die Cloud-Verarbeitung von Gesundheitsdaten nach rechtlicher Prüfung akzeptieren.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling (MIT; lokal, air-gap-fähig; Granite-Docling-258M-VLM) [5], PaddleOCR / PaddleOCR-VL, MinerU, olmOCR.
• Modelle: offene VLMs und LLMs wie Qwen3-VL / Qwen3, Mistral Small, Llama-Familie sowie medizinische Modelle wie Google MedGemma 27B (Text und multimodal, auf Gemma 3 basierend, nutzbar unter den Bedingungen der Health AI Developer Foundations, nicht für direkte Diagnosen) [6]. Betrieb mit vLLM, Ausgabe per JSON-Schema einschränken.
• Anonymisierung vor jedem externen Schritt: Microsoft Presidio (MIT; Text, Bilder, DICOM; keine Garantie, alle personenbezogenen Daten zu finden) [7]. Terminologie: ICD-10-GM vom BfArM, LOINC, SNOMED CT.
• Hardware: HW3 (eine GPU mit 48–96 GB) für ein Modell mit ~27–32B; HW2 genügt für ein kleines VLM plus regelbasierte Validierung bei geringem Volumen. Betriebsaufwand: GPU-Server, Monitoring, Patches, Backup.
• C wählen, wenn: Daten das Netz der Klinik oder Praxis nicht verlassen dürfen (in Deutschland typisch).

Weg D — Eigenes Training

Lohnt sich bei wiederkehrenden lokalen Formaten (die eigenen Befundlayouts eines Laborverbunds, deutsche Konventionen für Entlassbriefe, Abkürzungen) oder zur Kostensenkung bei hohem Volumen. Erfordert einige hundert bis einige tausend manuell verifizierte, anonymisierte Dokumente mit Labels auf Feldebene, das Feintuning eines kleinen VLM oder eines Encoder-NER-Modells (text-classifier), eine zurückgehaltene Testmenge je Dokumenttyp und eine Ethik-/Datenschutz- Freigabe für die Trainingsdaten. Für strukturierte Labortabellen Regeln bevorzugen; für Fließtext trainieren.

Stand der Technik (2026)

• Parsing: layoutbewusste VLM-Parser (Docling mit Granite-Docling, Mistral OCR, PaddleOCR-VL, Azure-Layoutmodelle) lesen komplexe Tabellen deutlich besser als klassische OCR; verbleibende Probleme sind mehrseitige Tabellen, Handschrift, Stempel, Faxscans schlechter Qualität und gedrehte Seiten [3][5].
• Medizinische LLMs: offene medizinische Modelle wie MedGemma (27B Text, 27B multimodal; EHRQA 86,3 / 90,5 laut Modellkarte) zeigen starke Ergebnisse bei medizinischer Fragebeantwortung und Aktenaufgaben, doch die Karte selbst warnt, dass die Ergebnisse vom Prompt abhängen und die Ausgaben unabhängig überprüft werden müssen [6].
• Standards: FHIR R4/R5 DiagnosticReport und Observation mit LOINC-Kodierung sind die Zielformate [4]; in Deutschland legen die MIO-Spezifikationen der KBV und die ePA-Infrastruktur der gematik nationale strukturierte Formate fest (aktuelle Versionen für Ihren Fall prüfen).
• Grenzen und Fehlerbilder: falsche Einheit oder falsches Dezimaltrennzeichen (ein Dezimalkomma, das als Tausendertrenner gelesen wird), vertauschte Zeilen in Tabellen, falsche Patientin bzw. falscher Patient (vermischte Seiten in einem Faxstapel), halluzinierte Werte bei unleserlichem Text, falsch kodierte Diagnosen, Verneinung und Unsicherheit im Freitext („kein Hinweis auf ...“) sowie stille Fehler, die plausibel aussehen. Gegenmaßnahmen: Schemavalidierung, Einheiten-/Plausibilitätsprüfungen, doppelte Extraktion mit zwei Verfahren und Prüfung bei Abweichung, Quellenhervorhebung.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Bausteine: Stack für Dokumenten-Parsing und VLM-Extraktion (DOC-001, DOC-014), Klassifikation und Input-Management (DOC-008), Anonymisierung (DOC-018), Validierungsschicht, Prüfoberfläche, Audit-Log, Terminologieserver, FHIR-Speicher, ein GPU-Server (HW3), der von der Dokumentenfamilie gemeinsam genutzt wird.
• Naheliegende Kombinationen: DOC-008 (eingehende Post leiten), DOC-018 (für Forschung oder Modelltraining anonymisieren), DOC-014 (allgemeine Tabellenextraktion), DOC-017 (Analyse von Kontoauszügen/Gehaltsabrechnungen nutzt dasselbe Muster für ein anderes Gebiet), AGENT-004 (agentische Folgeaktion wie die Buchung einer Kontrolluntersuchung oder die Benachrichtigung der Ärztin bzw. des Arztes; Mensch in der Schleife behalten). Akten-Chatbots über die strukturierten Daten benötigen RAG-Komponenten (vector-db, embedding-text), die diese Datei nicht voraussetzt.

Aufwand, Kosten & Kennzahlen

• A: Wochen bis wenige Monate, überwiegend Integration, Validierung und Datenschutz-Folgenabschätzung (DSFA); Lizenz je Dokument oder je Arbeitsplatz.
• B: 2–4 Monate für ein MVP einschließlich Terminologie-Zuordnung und Prüfoberfläche; Kosten bestimmt durch Seiten- volumen, Modellwahl und rechtliche Prüfung.
• C: 3–6 Monate mit GPU-Hardware und Betrieb; geringere Grenzkosten, höhere Fixkosten.
• D: zusätzlicher Annotationsaufwand (die Zeit von Klinikern ist der teure Teil) und eine Validierungsstudie.
• Kennzahlen: Präzision/Recall auf Feldebene je Feldtyp (Patienten-ID, Analyt, Wert, Einheit, Kennzeichen), Rate übersehener kritischer Werte (Ziel null, gemessen an einer Testmenge), Anteil der ohne Korrektur verarbeiteten Dokumente, Prüfzeit pro Dokument, Kodiergenauigkeit im Vergleich zur Kodierung durch Kliniker, Anzahl von Identitätsverwechslungen sowie Zeit vom Eingang bis zur Verfügbarkeit in der Akte.

Menschen & Veränderung

Von Anfang an einbinden: Geschäftsleitung und ärztliche Leitung (Haftung, Umfang), das Praxis- oder Stationspersonal, das prüfen wird, IT und IT-Sicherheit (Hosting, KIM, Zugriffe), die/den Datenschutzbeauftragte(n), Recht und Compliance (Fragen zu Medizinprodukten und Berufsgeheimnis), die Datenverantwortlichen der klinischen Systeme und den Betriebs- oder Personalrat.

Betriebsrat: abhängig vom Einzelfall, in Kliniken eher ja. Prüfwarteschlangen, Audit-Logs und Fehlerstatistiken je Nutzer sind zur Verhaltensüberwachung geeignet, sodass §87 Abs. 1 Nr. 6 BetrVG in der Regel greift (BAG: objektive Eignung genügt); §90 Abs. 1 Nr. 3 verlangt frühzeitige Information, und der Betriebsrat kann nach §80 Abs. 3 einen KI-Sachverständigen hinzuziehen. Öffentliche Kliniken fallen unter den Personalrat. Siehe GUIDE-004.

Datenschutz: Gesundheitsdaten sind besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO; eine DSFA ist sehr wahrscheinlich, ein AVV ist zwingend, und die/der Datenschutzbeauftragte sollte vor jedem Test mit echten Daten einbezogen werden (GUIDE-005). Sicherheitsmaßnahmen aus GUIDE-013 ergänzen.

KI-Kompetenz: Das Personal darin unterstützen, Extraktionsfehler, Einheitenverwechslungen und Automatisierungsbias zu verstehen (KI-Verordnung Art. 4; GUIDE-006).

Pilot und Kommunikation: mit einem Befundtyp und einem kleinen, motivierten Team beginnen, im Schattenbetrieb laufen lassen und Feldgenauigkeit sowie Korrekturzeit messen (GUIDE-009, GUIDE-008).

Bedenken: Patientensicherheit (Kliniker bestätigen Identität und kritische Werte immer), Sorge um den Arbeitsplatz (Entlastung von Abschreibarbeit) und Vertrauen (Quellenhervorhebung zeigen).

Risiken, Regulierung & Compliance

• DSGVO: Gesundheitsdaten sind besondere Kategorien personenbezogener Daten (Art. 9 Abs. 1). Die Verarbeitung für die Versorgung stützt sich auf Art. 9 Abs. 2 Buchst. h mit Schutzvorkehrungen zum Berufsgeheimnis (Art. 9 Abs. 3); Forschung nutzt Art. 9 Abs. 2 Buchst. j oder eine Einwilligung (Art. 9 Abs. 2 Buchst. a) [8]. Eine DSFA (Art. 35), ein AVV und ein Eintrag im Verzeichnis von Verarbeitungstätigkeiten sind erforderlich. Deutsche Praxen unterliegen zudem §203 StGB sowie landes- und kirchenspezifischen Krankenhausdatenschutzgesetzen.
• KI-Verordnung (AI Act): Die Einstufung hängt vom Zweck ab. Reine Transkription und Strukturierung von Dokumenten zur Prüfung durch das Personal hat typischerweise minimales Risiko oder fällt unter die Ausnahme nach Art. 6 Abs. 3 für enge verfahrenstechnische oder vorbereitende Aufgaben, die dokumentiert und registriert werden muss [9]. Hochrisiko liegt vor, wenn es ein Medizinprodukt oder eine Sicherheitskomponente nach Anhang I ist (Art. 6 Abs. 1) oder für Anwendungen nach Anhang III genutzt wird, etwa Anspruch auf öffentliche Gesundheitsleistungen, Triage bei Notfallpatienten oder Risikobepreisung in der Krankenversicherung [10]. Profiling von Personen ist immer hochriskant.
• MDR (Verordnung (EU) 2017/745): Software, die Daten nur speichert, umwandelt oder anzeigt, ist kein Medizinprodukt, doch eine Extraktion mit der Zweckbestimmung Diagnose, Prognose oder Therapieentscheidung (zum Beispiel automatische Markierung auffälliger Werte für die Behandlung) kann nach MDCG 2019-11 und Regel 11 als Medizinprodukte-Software gelten. Die Zweckbestimmung eng fassen und dokumentieren.
• Sonstiges: EHDS (Zweitnutzung nur über Zugangsstellen für Gesundheitsdaten, keine Re-Identifizierung) [1]; Aufbewahrung von Patientenakten und Dokumentationspflichten nach §630f BGB in Deutschland; das Originaldokument muss die rechtlich maßgebliche Aufzeichnung bleiben.
• Gegenmaßnahmen: menschliche Verifikation, EU-/On-Premises-Hosting, Verschlüsselung, rollenbasierter Zugriff, Audit-Logs, keine Nutzung von Patientendaten zum Training von Modellen Dritter, Anonymisierung vor der Cloud-Nutzung.

Erste Schritte

1. 200–500 repräsentative Dokumente sammeln, anonymisiert und rechtlich freigegeben, die die schlimmsten Fälle abdecken (Fax, seitenübergreifende Tabellen, Handschrift); von einer Klinikerin oder einem Kliniker ein Gold-Set annotieren lassen.
2. Den Verwendungszweck schriftlich festlegen (Transkriptionshilfe vs. Entscheidungsunterstützung) und die Einstufung nach KI-Verordnung/MDR sowie die DSFA mit der/dem Datenschutzbeauftragten prüfen, bevor echte Daten verarbeitet werden.
3. Zwei oder drei Parser am Gold-Set vergleichen (Docling, Azure Document Intelligence, Mistral OCR) und einen VLM-Extraktions-Prompt mit JSON-Schema testen; Fehler auf Feldebene messen, nicht nur die Textgenauigkeit.
4. Den Prüfbildschirm mit Quellenhervorhebung und harten Validierungsregeln (Einheiten, Bereiche, Patientenabgleich) bauen und im Schattenbetrieb neben der manuellen Erfassung laufen lassen.
5. Über FHIR oder die Schnittstelle des Aktensystems integrieren und dann Dokumenttyp für Dokumenttyp ausrollen.

Quellen

1. European Commission – European Health Data Space Regulation (EHDS): https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
2. Mistral AI documentation – Document AI / OCR: https://docs.mistral.ai/capabilities/document_ai/
3. Microsoft Learn – Azure Document Intelligence overview: https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/overview
4. HL7 FHIR – DiagnosticReport: https://www.hl7.org/fhir/diagnosticreport.html
5. Docling project (IBM/LF AI & Data, MIT): https://github.com/docling-project/docling
6. Google MedGemma 27B model card: https://huggingface.co/google/medgemma-27b-it
7. Microsoft Presidio: https://github.com/microsoft/presidio
8. GDPR Art. 9: https://gdpr-info.eu/art-9-gdpr/
9. EU AI Act Art. 6: https://artificialintelligenceact.eu/article/6/
10. EU AI Act Annex III: https://artificialintelligenceact.eu/annex/3/