Wozu brauchen wir IHE, wir haben doch FHIR!“ So oder ähnlich lautet neuerdings eine Reihe von Aussagen, die man häufiger hört. Vor gut 20 Jahren lautete die Frage, „Wozu braucht man HL7 (d.h. v2.x), es gibt doch XML“. Kann es sein, dass hier Äpfel mit Birnen verglichen werden? Aber der Reihe nach:

Einleitung

IHE ist eine Organisation, die als PEO - Profiling Enforcement Organisation bezeichnet wird. Dahinter verbirgt sich eine Initiative, die Anwender mit Herstellern zusammenführt, indem die Anwender ihre Probleme in Form von Use Case einbringen und diese unter Verwendung sog. Integrationsprofile mit Akteuren und deren Interaktionen auf einer abstrakten Ebene beschreiben. Die Hersteller suchen dafür dann Standards heraus, mit denen diese Use Cases anschließend umgesetzt und gelöst werden können. IHE entwickelt also keine eigenen Standards.

FHIR hingegen ist ein Standard, der von HL7 International erarbeitet und veröffentlicht worden ist. FHIR ist ein Akronym, das für „Fast Healthcare Interoperability Resources“ steht. Genau genommen stellt FHIR ein Framework dar, mit dessen Hilfe schnell - engl. „fast“ - Schnittstellen und Datenaustauschformate festgelegt werden können. Die Basis dafür ist eine Sammlung sog. Ressourcen (z. B. Patient, Observation, Appointment), die als Container für Inhalte angesehen und äußerst flexibel eingesetzt und miteinander kombiniert werden können. Dazu kommen noch standardisierte RESTful CRUD-Services, evtl. ergänzt um individuelle Services, um diese Ressourcen zu kommunizieren bzw. konkrete Funktionen auszulösen. Darüber lassen sich diverse Interaktionen zwischen Client und Server festlegen, um einen individuellen nachrichten- oder dokumentenbasierten Austausch zu realisieren. Eine solche Spezifikation wird dann als Implementierungsleitfaden veröffentlicht.

Problemstellung

Um ein Maximum an Flexibilität und einen möglichst großen Einsatzbereich abzudecken, enthalten die Ressourcen keinerlei Umsetzungsanforderungen, so dass alle Elemente - d.h. bis auf wenige Ausnahmen für strukturelle Attribute - optional sind. Damit sind diese Elemente zwar grundsätzlich für alle Szenarien geeignet, aber ohne weitere Präzision nicht direkt einsetzbar. Deshalb müssen die Ressourcen für den jeweiligen Einsatzzweck profiliert und die notwendigen Details in sog. Implementierungsleitfäden zusammengestellt werden. Weltweit dürften - wenn man die Zahlen der beiden Primärtools zusammenzählt - aktuell ca. 1500 derartige Implementierungsleitfäden existieren. Auf der einen Seite kann die hohe Anzahl an Leitfäden als klarer Erfolg von FHIR gewertet werden, da andere Standards wie v2.x und CDA, aus denen die Profilierungslogik abgeleitet wurde, nicht zu einem derartigen Umfang geführt haben - was vielleicht auch auf die mangelnde Propagation sowie zu wenige Werkzeuge und Libraries zurückzuführen ist. Auf der anderen Seite war FHIR von Anfang an als Rahmenstandard gedacht und entsprechend entwickelt worden.

Lösungsansatz

Um diese Profileration an Leitfäden zu reduzieren und damit handhabbar zu machen, bedarf es bestimmter Mechanismen. Die beiden bekanntesten Maßnahmen dürften die Festlegung und Umsetzung von Use Cases und der Aufbau von Profilhierarchien sein, was einer horizontalen (Use Case) und vertikalen (Profilhierarchien) Ausrichtung entspricht. FHIR propagiert zwar eine Profilierung, ohne hierbei eine ausgeprägte mehrstufige Hierarchiebildung zu bewerben, so dass es zu vielen „Schwesterspezifikationen“ kommt, was allein in Deutschland an den vielen inkompatiblen Leitfäden zu erkennen ist.

IHE hingegen unterstützt beides direkt, weil eine wirkliche Effizienz nur bei gleichzeitiger Berücksichtigung entsteht. Die Integrationsprofile von IHE sind im Prinzip vereinfachte Use Cases, wobei mitunter mehrere Integrationsprofile miteinander kombiniert eingesetzt werden müssen, um ein bestimmtes Ziel zu erreichen. Bei konformer Umsetzung haben die Hersteller aber genau das bereits berücksichtigt und über die Connect-a-thons praktisch demonstriert.

Die Integrationsprofile sind gleichzeitig auf globaler Ebene so festgelegt worden, dass über „national Extensions“ (im Vol. 4 der Technical Frameworks) Anpassungen an die landesspezifischen Erfordernisse vorgenommen werden können. Das entspricht dann Profilhierarchien, ohne dass dies ebenfalls explizit so bezeichnet wird. Die oberste Ebene wird auch mit „universal realm“ tituliert, was treffend als „allgemeines Königreich“ übersetzt werden kann, womit die so definierten Profile universell eingesetzt werden können.

Die bei HL7 International zur Kommentierung angebotenen Leitfäden tragen ungefähr jeweils zur Hälfte die Bezeichnungen „universal“ und „US“. Die Leitfäden anderer Länder kommen dort nicht vor, was eine Fokussierung jedes einzelnen Landes ausschließlich auf seine eigenen Interessen dokumentiert. Damit sind die wenigsten Leitfäden universell einsetzbar, sondern fast ausschließlich nur für den Einsatz in einzelnen Ländern oder einen noch weiter eingeschränkten Use Case gedacht, ohne einen übergreifenden Abgleich durchzuführen oder Kompatibilität herzustellen.

FHIR als Rahmenwerk

Bemühen wir einen anderen Vergleich: FHIR als Rahmenwerk stellt sozusagen eine universelle Sprache dar. Darüber wird primär die Syntax und Grammatik (Grundstruktur der Elemente/Bausteine) festgelegt, ohne gleichzeitig eine formale Definition (Semantik) bereitzustellen. Letzteres geschieht erst durch implizite gemeinsame Annahmen der Anwender, welche erst durch die Leitfäden - meistens in Form von natürlichsprachlichen Sätzen - genauer präzisiert werden. Im Prinzip stellen diese Leitfäden dann Themenbereiche mit jeweils eigenen Dialekten dar. So gibt es diverse Ausarbeitungen zu „Vital Signs“, die dann ähnlich, aber nicht gleich sind. Das Gleiche gilt für unterschiedliche Leitfäden, die unterschiedliche Interpretationen derselben Komponenten (Profile von Ressourcen) enthalten.

Ein anderes Beispiel könnte der Infektionsschutz sein, der auf Landesebene mit Meldetatbeständen als allgemeine Vorgabe unterschiedlich geregelt ist, so dass gleichlautende Vorgaben - möglichst auf Basis von FHIR - ideal wären. Die landesspezifische Diversifikation lässt sich dann leicht über angepasste Vokabularien regeln. Hierfür gibt es den Value Set Mechanismus, der dies stark vereinfacht. Auf diese Weise braucht es nicht einmal spezialisierte Entwicklungen, der Download des entsprechenden Vokabulars genügt. Bei richtiger Implementierung geschieht der Rest gewissermaßen von allein.

Diese Beispiele zeigen aber auch, dass eine Synchronisation von Use Cases mit technischen Umsetzungen nur über domänenspezifische, auf die Use Cases zugeschnittene Informationsmodellen erfolgt, da nur diese den Zusammenhang zwischen den Daten vorgeben und regeln. (Die Abbildung 1 zeigt die Einordnung in das Referenzmodell für Open Distributed Processing - RM-DOP.) Zu einem solchen Modell gehört eine formale Beschreibung, um ein gleiches Verständnis zu ermöglichen und Informationsverlust sowie Missinterpretationen zu verhindern. Bei genauerer Betrachtung erkennt man, dass alle Anwendungen letztendlich die Daten auch in ihre eigene Geschäftslogik und das dazugehörige Datenmodell integrieren müssen und somit ein Mapping zwangsweise entsteht. Eine echte Interoperabilität ist nur möglich, wenn das anwendungsinterne und das für den Austausch vorgesehene Modell kongruent bzw. kompatibel sind - ansonsten gehen Informationen verloren oder werden missinterpretiert. Nur leider kommen derartige Modelle aber in fast keinem Leitfaden vor.

Fazit

Für einen erfolgreichen Einsatz von Interoperabilitätsszenarien braucht es demnach beides: universelle Einsatzbarkeit mit einer Spezialisierung auf ganz konkrete Bedarfe, die aus der Ableitung von Use Cases heraus resultieren inklusive der dazugehörigen Informationsmodelle. Die Einordnung in ein Referenzmodell wie ODP, vgl. Abbildung 1, zeigt einerseits auf, dass sich IHE und FHIR wunderbar ergänzen - vielmehr einander sogar eher bedingen, andererseits aber auch, dass dann immer noch (formal beschriebene) Informationsmodelle fehlen. Damit bietet die Kombination von FHIR mit IHE genau die richtigen Voraussetzungen für Interoperabilität.

Literatur

IHE Integrating the Healtcare Enterprise: www.ihe.net, wiki.ihe.net, www.ihe-d.de, letzte Einsicht am 27. März 2023.

IG-Publisher: Dokumentation bei HL7 International, https://confluence.hl7.org/display/FHIR/IG+Publisher+Documentation, letzte Einsicht am 27. März 2023.

Simplifier: Fire.ly, www.simplifier.net, letzte Einsicht am 27. März 2023.

RM-ODP: International Organization for Standardization (1996) ISO/IEC 10746 - 2. Information technology - "Reference Model for Open Distributed Processing": Foundations. Geneva. ISO/IEC IS 10746 / ITU-T x.901, ISO/IEC IS 10746 / ITU-T x.901, http://www.rm-odp.net, letzte Einsicht am 27. März 2023.

Oemig, Blobel: "Modelling Digital Health Systems to foster Interoperability", Front. Med., 07 March 2022, Sec. Translational Medicine, https://www.frontiersin.org/research-t ... ation-towards-p5-medicine, letzte Einsicht am 27. März 2023.

Blobel, Oemig, Routsalainen, Lopez: "Transformation of health and social care systems - An interdisciplinary approach towards a foundational architecture", Front. Med., 07 March 2022
Sec. Translational Medicine, https://doi.org/10.3389/fmed.2022.802487, https://www.frontiersin.org/articles/10.3389/fmed.2022.802487/full, letzte Einsicht am 27. März 2023.

Oemig, Snelick: "Healthcare Interoperability Standards Compliance Handbook - Conformance and Testing of Healthcare Data Exchange Standards", Springer, 2016, ISBN 978-3-39-44837-4.


Autor: Frank Oemig, Mülheim