Klinische Terminologie-Zuordnung und Interoperabilität von Gesundheitsdaten (SNOMED CT, LOINC, FHIR, OMOP)

Krankenhäuser halten Daten aus Jahrzehnten unter lokalen Codes („Na-Serum", „Kreatinin_neu"), die kein anderes System versteht. Auf Embeddings und LLMs gestützte Zuordnungswerkzeuge schlagen Standardkonzepte vor (SNOMED CT, LOINC, ATC, UCUM), Terminologen bestätigen sie, und Pipelines erzeugen daraus FHIR-Ressourcen oder OMOP-Tabellen. Der Nutzen ist ein deutlich kürzerer Rückstau bei der Zuordnung, von dem Forschungsdatenzentren und die Bereitschaft für den EHDS abhängen.

Problem & Nutzen

• Heute: Ein Krankenhaus-Laborkatalog hat Tausende lokaler Testcodes; ein Medikations- oder Diagnosewörterbuch hat Zehntausende Einträge. Die Zuordnung erfolgt manuell: Eine Terminologin bzw. ein Terminologe durchsucht einen Browser, vergleicht Einheiten, Probenmaterial und Methode und hält eine Entscheidung fest. Zuordnungstabellen veralten mit jeder Systemänderung, und jedes Forschungsprojekt ordnet dieselben Codes erneut zu.
• KI-Nutzen: Kandidaten in Sekunden abrufen und neu ordnen (Retrieve-and-Rerank), die vollständigen LOINC-Achsen (Komponente, Eigenschaft, System, Methode) aus einer lokalen Bezeichnung samt Einheit und Referenzbereich vorschlagen, die Zuordnungstabelle vorbefüllen und den Menschen die mehrdeutigen 10-30 % überlassen (es wird keine feste Zahl behauptet; messen Sie an Ihrem eigenen Katalog).
• Regulatorischer Sog: Die Verordnung über den Europäischen Gesundheitsdatenraum (EU) 2025/327 verlangt interoperable Patientenaktensysteme und ein europäisches Austauschformat für prioritäre Kategorien (Patientenkurzakte, E-Verordnung, Laborergebnisse, Bildgebungsbefunde, Entlassberichte) und ermöglicht die Sekundärnutzung von Gesundheitsdaten, mit stufenweiser Anwendung ab 2027 [1]. In Deutschland definiert der Kerndatensatz der Medizininformatik- Initiative (MII) FHIR-Profile, die die Datenintegrationszentren (DIZ) der Universitätskliniken befüllen müssen [2]. Netzwerke mit gemeinsamem Datenmodell (OHDSI/OMOP, EHDEN) benötigen dieselbe Harmonisierung für föderierte Studien [3].

Varianten

• Labor (LOINC + UCUM): lokaler Testcode + Einheit + Probenmaterial → LOINC; Einheitennormalisierung.
• Diagnosen und Befunde (SNOMED CT, ICD-10-GM): Freitext und postkoordinierte Ausdrücke.
• Medikation (ATC, RxNorm/OMOP-Arzneimittelvokabular, IDMP): Markennamen, Darreichungsformen, Stärken.
• FHIR-Transformation: HL7 v2 / CSV / SQL → FHIR R4 mit MII- oder IPS-Profilen.
• OMOP-ETL: Quelltabellen → OMOP-CDM mit Standard-Konzept-IDs.

So funktioniert es

1. source catalogue / data extract
2. profiling (frequency, units, value ranges, specimen, language)
3. candidate retrieval (lexical + embeddings over SNOMED CT / LOINC / ATC descriptions)
4. reranker or LLM judge (axes, units, specimen, laterality; "no match" is allowed)
5. confidence routing: high
6. auto-accept sample-audited | medium/low
7. terminologist review
8. versioned mapping table (source code, target concept, equivalence, author, date)
9. transformation (FHIR Mapping Language / OMOP ETL, e.g. HAPI FHIR, Whistle, Rabbit-in-a-Hat)
10. validation (FHIR profile validator, OHDSI DQD / Achilles)
11. loading into FHIR server / OMOP DB

• Zuerst Retrieval: Das LLM darf nie Codes erfinden. Kandidaten stammen aus dem lizenzierten Terminologie-Release; das Modell ordnet nur, erklärt und lehnt ab. Jeder ausgegebene Code wird darauf geprüft, dass er im geladenen Release existiert und aktiv ist.
• Freitext: NER und Normalisierung von Diagnosen (LANG-015) speisen denselben Retrieval-Schritt; die Postkoordination (Lokalisation des Befunds, Seitenangabe, Schweregrad) nutzt ein LLM mit einer SNOMED-Ausdrucks- Constraint-Grammatik und eine Prüfung per $validate-code am Terminologieserver.
• Mensch-in-der-Schleife (Human-in-the-Loop): Terminologen genehmigen Zuordnungen; Klinikerinnen und Kliniker klären klinische Mehrdeutigkeit; akzeptierte Entscheidungen werden zu Trainingsdaten und Few-Shot-Beispielen.

Datenaufbereitung

Quelldaten sind lokale Codelisten, Freitext-Diagnosen und Labor- oder Medikamentenbezeichnungen sowie die Zielterminologien (SNOMED CT, LOINC, ICD-10-GM, ATC, OMOP-Vokabulare) und bestehende Zuordnungstabellen. Sie liegen im Krankenhausinformationssystem, im LIS, im Apothekensystem, in Excel-Dateien und auf Wiki-Seiten; Zuordnungen stehen oft in den Tabellen einzelner Fachleute.

Typische Lücken: doppelte und veraltete lokale Codes, Abkürzungen, fehlende Einheiten, uneinheitliche Sprachen (Deutsch und Englisch), keine dokumentierten früheren Zuordnungen sowie Lizenz- oder Zugriffsbeschränkungen bei Terminologie-Releases.

Schritte der Aufbereitung: die eindeutigen lokalen Begriffe mit Häufigkeit und Kontext exportieren (PREP-005); sie mit einfachen Skripten oder OpenRefine bereinigen und deduplizieren (PREP-011); die lizenzierten Zielterminologien laden; bestehende Expertenzuordnungen als Goldstandard und zurückgehaltenen Testsatz sammeln (PREP-016, PREP-018); eine Synonym- und Abkürzungsliste aufbauen (PREP-015); und ein Zuordnungsschema mit Konfidenzstufen vereinbaren (PREP-019). Verwandt: DATA-003 zur Qualität von Stammdaten.

Werkzeuge: OpenRefine, pandas, ein Embedding-Modell, eine Vektordatenbank und eine Tabellenkalkulation für die Expertenprüfung. Die Begriffe selbst sind meist keine personenbezogenen Daten, prüfen Sie aber Freitextfelder auf Patientennamen (PREP-022). Rechnen Sie mit etwa 30-40 Prozent des Aufwands in der Aufbereitung. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• enterprise: B - Klinikverbünde und Hersteller brauchen eine Zuordnung, die an ihre eigenen Datenmodelle gebunden ist; Cloud-LLM- und Embedding-APIs in EU-Regionen funktionieren gut, weil Begriffe und nicht Patientenakten gesendet werden.
• developer: C - offene Embedding-Modelle, Reranker und ein lokales LLM (HW2) mit einer offenen Vektordatenbank bieten volle Kontrolle und Reproduzierbarkeit.
• public: C - öffentliche Forschungs- und Gesundheitseinrichtungen profitieren von souveränem Hosting und offenen Komponenten und vermeiden Abhängigkeiten und Beschaffungsprobleme mit US-Clouds.

Weg A — Kaufen (Standardsoftware)

• Terminologieserver und Zuordnungswerkzeuge: Snowstorm (SNOMED International, Open Source), Ontoserver (CSIRO), Termite/Snow Owl (B2i Healthcare), John Snow Labs Healthcare NLP mit Entity Resolvern (SNOMED, ICD-10, RxNorm, LOINC),.
• Interoperabilitätsplattformen: Smile CDR, InterSystems HealthShare / IRIS for Health, Firely (NL, EU), Medblocks, an die gematik angelehnte FHIR-Server, Rhapsody, Integrationsengines von Health Level Seven. Deutsche Anbieter: Medatixx, Dedalus (EU), Philips, Siemens Healthineers (EU) für KIS-eingebettetes FHIR.
• Wählen Sie A, wenn: Sie eine zertifizierte Integrations-Engine brauchen und manuelle Zuordnung mit KI-Vorschlägen als Zusatz akzeptieren.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende LLMs mit strukturierter Ausgabe (Claude, Gemini, GPT, Mistral) in EU-Regionen; Embeddings wie OpenAI text-embedding-3, Cohere Embed v4, Mistral Embed oder Voyage.
• Cloud-Gesundheitsdienste: Azure Health Data Services (FHIR-Dienst, DICOM, MedTech; EU-Regionen), Google Cloud Healthcare API (FHIR, HL7v2-Aufnahme, EU-Standorte), AWS HealthLake und Amazon Comprehend Medical (ICD-10-CM / RxNorm / SNOMED-CT-Inferenz, begrenzte Abdeckung der EU-Regionen).
• Vorgehen: zuerst de-identifizieren oder pseudonymisieren, das LLM nur mit der lokalen Bezeichnung, der Einheit und den Metadaten aufrufen (keine Patientenkennungen), den Terminologieserver innerhalb Ihrer Vertrauensgrenze halten.
• Wählen Sie B, wenn: Sie ein Data-Engineering-Team und einen unterzeichneten Auftragsverarbeitungsvertrag mit Schutzvorkehrungen für Gesundheitsdaten haben (Art. 9 DSGVO, nationales Krankenhausrecht).

Weg C — Selbst betreiben (Open Source)

• Terminologie und FHIR: Snowstorm / Hermes (SNOMED), HAPI FHIR, Firely .NET SDK, Blaze (FHIR- Server, der in der MII verwendet wird), Aidbox, Pathling (FHIR-Analytik), OHDSI-Werkzeuge (Usagi, Athena, Atlas, WhiteRabbit, Achilles, DQD).
• Modelle: biomedizinische Encoder wie SapBERT (UMLS-Entity-Linking), LLMs mit offenen Gewichten (Llama, Qwen, Gemma, Mistral-Familien, MedGemma), bereitgestellt mit vLLM; bge-m3- oder e5-Embeddings mit einem Reranker; pgvector oder OpenSearch für die hybride Suche.
• Hardware: HW2 reicht für ein 7-14B-Modell plus Embeddings bei einem Katalog in Krankenhausgröße; HW3 für größere Modelle oder mehrsprachige Freitext-Normalisierung.
• Betriebsaufwand: ein Dateningenieur plus eine Terminologin bzw. ein Terminologe in Teilzeit; Aktualisierungen der Terminologie-Releases zweimal jährlich.

Weg D — Eigenes Training

Ein Embedding- oder Cross-Encoder-Modell auf Ihren eigenen akzeptierten Zuordnungen feintunen (typischerweise einige tausend Quelle-Ziel-Paare), um das Ranking für deutschsprachige und krankenhausspezifische Abkürzungen zu verbessern. Lohnt sich bei großen Katalogen oder wiederkehrenden Projekten mit mehreren Standorten (z. B. MII, Netzwerke im Stil von EHDEN).

Stand der Technik (2026)

• Retrieve-and-Rerank schlägt reine Generierung. Berichte aus Community und Forschung zur LLM-Zuordnung zu SNOMED CT, LOINC und OMOP bevorzugen durchgängig Embedding-Retrieval plus Reranking gegenüber dem Auffordern eines LLM, Codes direkt auszugeben, was Kennungen halluziniert; prüfen Sie dies an Ihrem eigenen Goldsatz.
• Sprache zählt: Deutsche und abgekürzte lokale Bezeichnungen senken die Genauigkeit; mehrsprachige Embeddings plus eine Prüfung von Einheit und Probenmaterial helfen. SNOMED CT ist lizenzpflichtig; die deutsche nationale Release- Stelle verteilt es mit Lizenzbedingungen, und LOINC hat eine deutsche Sprachvariante.
• OHDSI-Werkzeuge (Usagi, Athena-Vokabular) bleiben die Basis für die OMOP-Zuordnung, wobei LLM-gestützte Zuordnung inzwischen in Forschungs- und Community-Werkzeuge einzieht [3].
• FHIR-Erzeugung aus tabellarischen Quellen funktioniert mit Vorlagen gut; von LLMs geschriebene Zuordnungs- skripte brauchen vor dem Einsatz eine Profilvalidierung und Testdaten.
• Grenzen: Die Äquivalenz ist abgestuft (exakt, enger, weiter); Postkoordination und Methoden- unterschiede sind fehleranfällig; Einheitenumrechnungen müssen deterministisch sein, nie LLM-Ausgabe; Zuordnungen driften mit Terminologie-Releases und brauchen eine erneute Validierung.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (embedding-text, reranker, vector-db, llm-general): HLTH-018 Aktensuche, HLTH-005 Kodierung, HLTH-017 regulatorisches Schreiben, DATA-003 Deduplizierung von Stammdaten.
• Vorgelagert: LANG-015 Informationsextraktion, HLTH-011 Entlassbriefe (strukturierte Abschnitte), HLTH-025 Pflegedokumentation (sobald FHIR-kodiert).
• Nachgelagert: HLTH-009 Patientenabgleich für Studien und HLTH-020 Risikostratifizierung nutzen OMOP-/FHIR-Daten; HLTH-010 Pharmakovigilanz braucht eine MedDRA-Zuordnung.
• Ein Terminologiedienst und ein Zuordnungs-Repository bedienen all diese Fälle.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für Lizenzierung und Einrichtung; die Zuordnung bleibt manuell.
• Weg B/C: 3-6 Monate für eine erste Domäne (Labor) einschließlich Terminologieserver, Evaluierungs- satz und Prüfoberfläche; weitere Domänen nutzen die Pipeline wieder.
• Kostentreiber: Prüfzeit der Terminologen (größter Posten), Lizenzierung von SNOMED/LOINC, Betrieb des FHIR-Servers, LLM-Aufrufe (klein: ein Aufruf pro eindeutigem Code, nicht pro Patientenakte).
• Kennzahlen: Zuordnungsabdeckung (% des Aktenvolumens zugeordnet, nicht % der Codes), Top-1-/Top-5-Genauigkeit gegen einen Goldsatz, Prüfminuten pro Code, Anteil mit Eskalation an Experten, ETL-Datenqualitäts- Scores (OHDSI DQD), FHIR-Validierungsfehlerrate, Zeit zur Anbindung eines neuen Standorts.

Menschen & Veränderung

Beziehen Sie die Leitung für den Umfang ein, die Datenverantwortlichen oder Terminologie-Eigner (data-owner) jedes Quellsystems, die Leitung der klinischen Informatik (department-lead) sowie die Ärztinnen, Ärzte oder Kodierfachkräfte, die Zuordnungen validieren. IT und IT-Sicherheit werden für den Vektorspeicher und den API-Zugriff gebraucht; die Datenschutzbeauftragten sollten bestätigen, dass nur Begriffe, nicht Patientenakten, an externe Dienste gesendet werden, andernfalls gelten eine DSFA und ein Auftragsverarbeitungsvertrag (GUIDE-005).

Betriebsrat: in der Regel nein, weil das Werkzeug mit Codelisten arbeitet und nicht mit dem Verhalten von Beschäftigten. Relevant wird es (§ 87 Abs. 1 Nr. 6 BetrVG), wenn Prüfprotokolle pro Person ausgewertet werden; § 90 Abs. 1 Nr. 3 verlangt dennoch eine rechtzeitige Information bei Änderung von Arbeitsabläufen, und öffentliche Stellen informieren den Personalrat (GUIDE-004).

KI-Kompetenz: Unterstützen Sie die prüfenden Fachleute mit einer kurzen Einführung in Konfidenzwerte, typische Fehler wie knapp danebenliegende Konzepte und den Prüfablauf (Art. 4 KI-Verordnung; GUIDE-006). Pilotieren Sie mit einer Domäne, zum Beispiel Laborcodes, messen Sie die Genauigkeit gegen den Goldstandard und weiten Sie erst nach Freigabe aus (GUIDE-009). Eine verbreitete Sorge ist, dass falsche Zuordnungen unbemerkt in Analysen und Abrechnung gelangen; begegnen Sie ihr, indem jeder Vorschlag ein Vorschlag mit menschlicher Freigabe bleibt, Zuordnungstabellen versioniert werden und Stichproben geprüft werden (GUIDE-011).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko; dies ist Data Engineering, kein medizinischer Zweck. Wenn Ausgaben unmittelbar Diagnose- oder Therapieentscheidungen steuern oder mit einer medizinischen Zweck- bestimmung vermarktet werden, können die MDR-Softwareregeln (Regel 11) und Hochrisiko nach Art. 6 Abs. 1 AI Act greifen [5].
• DSGVO / Gesundheitsdaten: Patientenakten sind Daten besonderer Kategorien nach Art. 9. Zuordnungskataloge enthalten keine Patientendaten und können externe APIs nutzen; ETL auf Patientenakten erfordert eine Rechts- grundlage (Versorgung, Forschung nach nationalem Recht, EHDS), Pseudonymisierung und eine Datenschutz-Folgen- abschätzung. Bevorzugen Sie für Freitext Inferenz im Haus oder in der EU.
• EHDS: Hersteller von Patientenaktensystemen müssen Anforderungen an Interoperabilität und Protokollierung erfüllen, und Dateninhaber für die Sekundärnutzung werden Daten über die Zugangsstellen für Gesundheitsdaten bereitstellen müssen [1].
• Lizenzierung: SNOMED-CT-Affiliate-Lizenzen, LOINC-Bedingungen, Urheberrecht von ATC/WHO und ICD.
• Risiken: Falsche Zuordnungen verfälschen unbemerkt Forschungskohorten oder klinische Warnungen; halluzinierte oder zurückgezogene Codes; Einheitenfehler. Gegenmaßnahmen: Generierung nur über Retrieval, deterministische Einheiten- umrechnung, Regressionstests mit dem Goldsatz je Terminologie-Release, Audit-Trail jeder Zuordnungs- entscheidung, Stichproben automatisch akzeptierter Zeilen.

Erste Schritte

1. Wählen Sie eine Domäne (z. B. die 500 häufigsten Laborcodes nach Volumen) und bauen Sie einen Goldsatz mit 200-300 Expertenzuordnungen auf.
2. Laden Sie SNOMED CT/LOINC in Snowstorm oder einen Vektorindex und messen Sie den Retrieval-Recall@10.
3. Ergänzen Sie einen Reranker oder LLM-Beurteiler mit der Option „keine Übereinstimmung"; vergleichen Sie mit dem Goldsatz.
4. Bauen Sie eine Prüfoberfläche (oder nutzen Sie Usagi) und leiten Sie nach Konfidenz weiter; protokollieren Sie jede Entscheidung.
5. Erzeugen Sie FHIR- oder OMOP-Ausgaben für einen Pilotdatensatz und lassen Sie die Validatoren laufen, bevor Sie skalieren.

Quellen

1. Regulation (EU) 2025/327, European Health Data Space — https://eur-lex.europa.eu/eli/reg/2025/327/oj
2. Medical Informatics Initiative Germany, core data set — https://www.medizininformatik-initiative.de/en/core-data-set
3. OHDSI, Book of OHDSI (vocabularies, Usagi, ETL) — https://ohdsi.github.io/TheBookOfOhdsi/
4. HL7 FHIR R4 specification and terminology module — https://hl7.org/fhir/R4/terminology-module.html
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. SNOMED International, Snowstorm terminology server — https://github.com/IHTSDO/snowstorm
7. Regenstrief Institute, LOINC — https://loinc.org/
8. HAPI FHIR — https://hapifhir.io/