Wie tauschen medizinische Systeme Daten über HL7 und FHIR aus?

HL7 ist nicht gleich FHIR

Health Level Seven International entwickelt mehrere Standards. In vielen Einrichtungen ist HL7 Version 2 für Nachrichten wie Aufnahme, Verlegung, Laborauftrag oder Befund etabliert. Solche Nachrichten bestehen typischerweise aus Segmenten und werden durch Triggerereignisse ausgelöst. Lokale Varianten sind verbreitet; deshalb genügt die Aussage „wir sprechen HL7“ nicht als Schnittstellenbeschreibung.

FHIR – Fast Healthcare Interoperability Resources – verwendet klar definierte Ressourcen wie Patient, Observation, Condition, Medication oder DiagnosticReport. FHIR Release 4 in Version 4.0.1 ist eine weit verbreitete stabile Basis. Ressourcen können in JSON oder XML dargestellt und über standardisierte REST-Interaktionen wie read, create, update und search ausgetauscht werden. Dokumente, Nachrichten und Transaktionen sind ebenfalls möglich.

Profile machen den Anwendungsfall eindeutig

Die FHIR-Kernspezifikation ist bewusst international und flexibel. Ein Implementierungsleitfaden schränkt sie für einen konkreten Anwendungsfall ein: verpflichtende Elemente, Kardinalitäten, Suchparameter, Terminologien und Erweiterungen werden in Profilen festgelegt. Ein CapabilityStatement beschreibt, welche Ressourcen, Profile und Interaktionen ein Server tatsächlich unterstützt.

Für den deutschen Krankenhausbereich konkretisiert die gematik mit ISiK – Informationstechnische Systeme im Krankenhaus FHIR-basierte Schnittstellen. Die jeweilige verbindliche oder projektbezogene Version muss ausdrücklich vereinbart werden; ein Release Candidate ist nicht automatisch eine produktive Vorgabe. Ebenso sind Terminologien wie ICD, SNOMED CT oder LOINC nur dann interoperabel, wenn Version, ValueSet und Binding eindeutig feststehen.

Ein Austauschprojekt braucht mehr als ein Datenformat

Vor der Implementierung sollten beide Seiten mindestens klären:

• fachlicher Anwendungsfall und führendes System,
• FHIR- beziehungsweise HL7-Version und konkreter Implementierungsleitfaden,
• Patienten-, Fall-, Leistungserbringer- und Organisationsidentitäten,
• Codesysteme, ValueSets und Umgang mit unbekannten Codes,
• Erzeugung, Änderung, Stornierung und Dublettenbehandlung,
• Fehlerantworten, Wiederholung, Reihenfolge und Transaktionsgrenzen,
• Authentisierung, Autorisierung, Transportverschlüsselung und Auditierung,
• Testdaten, Konformitätsprüfung und Ende-zu-Ende-Abnahme.

FHIR ist selbst kein vollständiges Sicherheitsprotokoll. Die offizielle Spezifikation empfiehlt für Produktionsdaten TLS, authentisierte Clients und risikogerechte Zugriffskontrolle; für webbasierte Szenarien kommen beispielsweise OAuth und SMART on FHIR in Betracht. Medizinische Zweckbestimmung und Risikomanagement bleiben auch bei standardisiertem Datenaustausch bestehen: Ein syntaktisch gültiger Wert kann fachlich falsch, veraltet oder dem falschen Patienten zugeordnet sein.