Terminologien in FHIR: Ohne SNOMED/LOINC wird’s teuer – wie man Codesysteme beherrschbar macht

Wer von Dokumenten (CDA/PDF) Richtung FHIR-Ressourcen geht, merkt schnell: Die eigentliche Komplexität steckt nicht im JSON, sondern in der Semantik. Eine Observation ist erst dann interoperabel, wenn klar ist, was gemessen wurde, in welcher Einheit, mit welchem Code und wie dieser Code zu interpretieren ist.

Warum „ohne Terminologien“ in FHIR teuer wird

1) Kostenfalle „lokale Codes überall“

Ohne gemeinsame Codesysteme entstehen pro Schnittstelle individuelle Übersetzungen: Labor A ↔ KIS B ↔ Klinik C ↔ Forschung D. Jedes System baut eigene Mappings, die gepflegt, getestet und versioniert werden müssen. Der Aufwand skaliert nicht linear – er explodiert.

2) Interoperabilität wird zur Illusion

FHIR sorgt für Transport- und Strukturstandardisierung. Bedeutung kommt über Terminologien. Wenn jeder „HbA1c“ anders kodiert, ist das Ergebnis: technisch austauschbar, fachlich nicht vergleichbar.

3) Analytics, CDS und Sekundärnutzung scheitern zuerst

• Qualitätsindikatoren, Register, Forschung, KI/ML, Clinical Decision Support: alles hängt an stabilen Codes.
• Ohne saubere Terminologie-Governance werden Projekte zu „Datenbereinigung als Dauerzustand“.

SNOMED CT und LOINC: Warum gerade diese beiden?

LOINC: Labor & klinische Beobachtungen (und mehr)

LOINC ist der de-facto Standard für Labor- und Beobachtungskennungen und wird von Regenstrief gepflegt. LOINC ist grundsätzlich kostenfrei nutzbar, aber unterliegt Nutzungsbedingungen. (Regenstrief Institute)

SNOMED CT: klinische Konzepte (Diagnosen, Befunde, Verfahren, Body Sites …)

SNOMED CT ist die umfassende klinische Terminologie. Für Deutschland wichtig: Deutschland ist seit 01.01.2021 Mitglied bei SNOMED International; das BfArM baut das nationale Release Center auf. Für Nutzende in Deutschland ist eine Affiliate-Lizenz/Sublicense über den MLDS zu beantragen und nach BfArM-Angaben kostenfrei. Es gibt eine deutsche National Edition/Extension (Übersetzungen, Deutschland-spezifische Inhalte, Subsets, Mappings). (BfArM)

FHIR-Terminologie-Bausteine: CodeSystem, ValueSet, ConceptMap – und warum das nicht optional ist

CodeSystem

„Woher kommt der Code?“ – z. B. LOINC, SNOMED CT, UCUM, ICD, lokale Systeme.

ValueSet

„Welche Codes sind für diesen Zweck erlaubt/erwünscht?“ ValueSets sind die entscheidende Steuerungsinstanz für Interoperabilität: sie definieren den erlaubten Ausschnitt eines Codesystems.

ConceptMap

„Wie übersetze ich von System A nach System B?“ Wenn lokale Codes bleiben müssen, wird die ConceptMap zur Lebensversicherung – aber nur, wenn sie versioniert und gepflegt wird.

Der „teure“ Teil: Governance statt Technik

Beherrschbares Zielbild: 3 Ebenen, die zusammen funktionieren

Ebene 1: Kanonische Standards (wo immer möglich)

• Observation.code → LOINC (für Labor/Beobachtungen)
• Condition / Procedure / BodySite / ClinicalFinding → SNOMED CT (je nach Use Case)
• Einheiten → UCUM (in FHIR praktisch Standard)

Ebene 2: ValueSet-Governance (der Interop-Hebel)

• Für jede relevante FHIR-Elementbindung (Binding) ein klares ValueSet: „muss“ / „soll“ / „kann“ (Binding Strength)
• Regel: Nichts geht in Produktion ohne validate-code gegen das ValueSet, mindestens in Tests/CI.

Ebene 3: Übersetzungen & lokale Realität (ConceptMap)

Wenn lokale Codes bleiben (und das kommt vor!), dann:

1. Lokale Codes sind in einem eigenen CodeSystem sauber definiert
2. Belastbare ConceptMap zu Standardterminologien
3. Jede Übersetzung ist versioniert und testbar (Regression!)

Terminology Service: Ohne zentrale Instanz wird’s Wildwuchs

In größeren Umgebungen ist ein Terminology Service praktisch Pflicht:

• ValueSet-Expansion ($expand)
• Code-Validierung ($validate-code)
• Lookup/Display ($lookup)
• Mapping/Translation ($translate)
• Subsumption/Hierarchiefragen (v. a. für SNOMED CT)

Konkrete Praxis: So sieht „beherrschbar“ als Vorgehen aus

Schritt 1: Code-Strategie pro Ressource definieren

Beispiel „Labor“:

• Observation.code: LOINC
• Observation.value[x]: mit UCUM
• Interpretation: aus definiertem ValueSet
• Method/BodySite: wenn gebraucht, SNOMED CT

// Beispielbox: Labor-Observation (Ausschnitt)
Observation.code.coding.system = "http://loinc.org"
Observation.code.coding.code   = "4548-4"         // HbA1c (Beispiel)
Observation.valueQuantity.value = 6.8
Observation.valueQuantity.system= "http://unitsofmeasure.org"
Observation.valueQuantity.code  = "%"

Schritt 2: ValueSet-Minimum etablieren

Startet klein, aber verbindlich:

• „Top 50“ Laborparameter
• „Top 20“ Vitalparameter
• „Top 30“ Dokumenttypen / Fragebogenitems (je nach Scope)

Schritt 3: Lizenz & Distribution sauber regeln (SNOMED CT)

• Affiliate-Lizenz über MLDS (BfArM weist den Prozess aus)
• National Edition/Extension berücksichtigen (Übersetzungen, Subsets, Mappings)

Schritt 4: Mappings als Produkt behandeln

• Owner pro Mappingbereich (Labor, Diagnosen, Dokumente …)
• Reviewprozess (fachlich + technisch)
• Versionierung (Release-Notes!)
• Automatisierte Tests: „Mapping vorhanden?“, „Zielcode im ValueSet gültig?“, „Keine toten Referenzen?“

Schritt 5: Toolchain in CI/CD

• FHIR Validator gegen Profile
• Terminologie-Validierung gegen ValueSets (mindestens pre-deploy)
• Regression bei ValueSet-/CodeSystem-Updates

Typische Stolpersteine (und wie man sie elegant umgeht)

Eine kurze Checkliste für Hersteller und Kliniken

Wenn ihr nur 10 Punkte mitnehmt, dann diese:

• ✓Definiert pro Datendomäne das Ziel-Codesystem (LOINC/SNOMED/…)
• ✓Baut ValueSets als verbindliche Verträge (nicht als Doku)
• ✓Erzwingt $validate-code in Tests/CI
• ✓Nutzt lokale Codes nur mit klarer Übersetzung (ConceptMap)
• ✓Behandelt Mappings als versioniertes Produkt, nicht als Excel
• ✓Klärt SNOMED-Lizenzierung/MLDS frühzeitig
• ✓Plant Terminologie-Updates als Release-Prozess (nicht als „Nebenbei“)
• ✓Zentralisiert Terminologie-Funktionen (Terminology Service), wo möglich
• ✓Dokumentiert TerminologyCapabilities (was kann euer Server?)
• ✓Macht Metadatenqualität messbar (Coverage, Validierungsquote, Mapping-Abdeckung)

Fazit: Terminologien sind der Preis der Interoperabilität – aber auch ihr größter Hebel

FHIR macht Austausch modern und skalierbar. Aber ohne Terminologien bleibt es syntaktische Interoperabilität: Daten sehen gleich aus, bedeuten aber nicht das Gleiche.

LOINC und SNOMED CT sind dabei keine „nice to have“-Standards, sondern Kostenbremsen: weniger individuelle Übersetzungen, bessere Vergleichbarkeit, bessere Sekundärnutzung, bessere Skalierung.