Blog · Interoperabilität

Interoperabilität ist kein Export-Button

Warum „wir exportieren FHIR“ und „wir liefern ein PDF“ zwei sehr verschiedene Versprechen sind — und warum das eine davon im Betrieb teuer wird.

Es gibt einen Moment in fast jedem Krankenhausprojekt, in dem das Wort „interoperabel“ fällt und alle nicken. Meist deutet jemand auf einen Knopf: „Das System kann FHIR exportieren.“ Oder: „Wir geben den Befund als PDF raus.“ Damit gilt die Frage als beantwortet.

Sie ist es nicht.

Ein PDF ist Transport. Nicht Interoperabilität.

Ein FHIR-Export ist Transport. Nicht Interoperabilität. Beides bewegt Daten von A nach B. Ob B danach dasselbe versteht, was A gemeint hat, ist eine völlig andere Frage — und genau diese Frage entscheidet über Betrieb, Patientensicherheit und Skalierung.

Übertragung ist nicht Bedeutung

Interoperabilität bedeutet nicht, dass Daten ankommen. Sie bedeutet, dass die Bedeutung der Daten unbeschädigt ankommt.

Struktur transportieren HL7 v2 und FHIR zuverlässig. Die Bedeutung aber liegt woanders: in den Terminologien (SNOMED CT, LOINC, ICD, OPS), in den Einheiten (UCUM), in den IHE-Profilen, die festlegen, welches Element in welchem Kontext steht — und nicht zuletzt im gemeinsamen Prozessverständnis von Sender und Empfänger. Fällt einer dieser Layer weg, läuft die Übertragung technisch sauber durch und liefert trotzdem etwas Falsches.

Ein konkretes Beispiel aus der Praxis: Ein Laborwert wird mit korrektem LOINC-Code übermittelt. Strukturell konform, der FHIR-Validator ist zufrieden. Nur ist die Einheit (UCUM) auf dem Weg stillschweigend verloren gegangen, oder der Referenzbereich-Kontext wurde nicht mitgeführt. Das empfangende System zeigt eine Zahl an — die etwas anderes bedeutet als die Zahl, die das sendende System gemeint hat. Kein Fehlerprotokoll meldet das. Der Transport war ein Erfolg. Die Information ist es nicht.

Wo Bedeutung leise verloren geht

Diese stillen Verluste folgen Mustern. In unserer Arbeit an SILD — einem formalen Verfahren zur Erkennung semantischen Informationsverlusts an klinischen Systemgrenzen — lassen sie sich auf wenige kanonische Typen zurückführen:

  • Type Narrowing — ein präziser Begriff wird auf einen gröberen abgebildet (der spezifische SNOMED-Code landet als unspezifischer ICD-Eintrag).
  • Temporal Collapse — ein Zeitintervall oder eine Verlaufsinformation wird auf einen Zeitpunkt reduziert.
  • Attribute Dropping — ein Attribut, das die Aussage qualifiziert (Einheit, Status, Negation), fehlt nach der Übertragung.
  • Reference Severing — ein Verweis zwischen Ressourcen reißt, und der Kontext, der die Aussage trägt, geht verloren.

Das Entscheidende: Jeder dieser Verluste passiert innerhalb einer technisch erfolgreichen Übertragung. Wer Interoperabilität am Export-Button misst, sieht keinen davon.

Was das für Häuser bedeutet

Die Konsequenz ist unbequem, aber sie spart Geld. Interoperabilität ist keine Funktion, die man einkauft. Sie ist eine organisatorische und semantische Disziplin: Wer besitzt welches Profil? Wie sind Codes und Einheiten gebunden? Wer prüft, ob ein Empfänger die Bedeutung rekonstruieren kann — und nicht nur die Struktur? Was passiert an der Grenze zwischen zwei Systemen, wenn keiner sie verantwortet?

Jede Entscheidung der Form „das machen wir später über eine Schnittstelle“ unterstellt, dass Transport gleich Interoperabilität sei. Die Kosten dieser Annahme tauchen nicht im Projektplan auf. Sie tauchen im empfangenden System auf — oft unsichtbar, bis ein klinischer Prozess auf einer Zahl aufsetzt, die etwas anderes bedeutet, als alle glauben.

Über ISCaD

Wir begleiten Krankenhäuser und ihre IT bei genau dieser Disziplin — Profil-Governance, Terminologie-Bindung und die systematische Prüfung von Systemgrenzen auf semantischen Verlust. Wenn Sie wissen wollen, wo in Ihren Datenflüssen Bedeutung leise verloren geht: Kontakt aufnehmen.

Die formale Grundlage des hier skizzierten Verfahrens ist unter aion-clinical.eu dokumentiert.

← Zurück zum Blog