Das deutschsprachige HL7 Magazin

Magazin

Zurück zur Übersicht

von Oliver Egger, Martin Smock

IHE on FHIR

IHE und FHIR? IHE ist doch für Dokumente aber nicht für Daten? Und wieso sprechen HL7 und IHE von Profilen und Connectathons, verstehen darunter aber nicht das Gleiche? Dieser Artikel versucht aufzuzeigen, wie IHE und HL7 mit ihren jeweiligen Länderorganisationen den Standardisierungsprozess unterstützen und wie IHE mit neuen FHIR-Implementierungsleitfäden globale Blueprints zur Interoperabilität im Gesundheitswesen erstellt.

Im Gesundheitswesen haben sich mehrere Standards etabliert, welche die digitale Transformation unterstützen. Neben der HL7-Standardfamilie sind das insbesondere der DICOM-Standard im Bereich der Bildverarbeitung und LOINC sowie SNOMED CT für Terminologien. Daneben haben mit dem Erfolg des Internets leichtgewichtige, offene Standards des W3C zunehmend an Bedeutung gewonnen. IHE hingegen entwickelt keine eigenen Standards, sondern arbeitet mit Anwenderinnen, Anwen­dern und Herstellern zusammen, definiert Anwendungsfälle und erstellt Spezifikationen, die aufzeigen, wie die Standards für die Anwendungsfälle genutzt werden können. Wie können nun die verschiedenen Organisationen zusammenspielen, damit interoperable und universell einsetzbare Lösungen entstehen?

Facebook
Twitter
LinkedIn

Vom globalen Standard zur nationalen Implementierung

Grahame Grieve, der Initiator von FHIR sieht in seinem Blog1 drei Pfeiler des globalen Standardisierungsprozesses. Der erste Pfeiler ist die Entwicklung des Basis-Standards. Der Basis-Standard soll ein international einsetzbarer Plattform-Standard sein, damit er für möglichst viele Anwendungsfälle eingesetzt werden kann. FHIR von HL7 zum Beispiel ist ein solcher Plattformstandard. Basis-Standards können und werden für Anwendungsfälle profiliert. Schliesslich müssen die Profile als Lösungen im Markt etabliert werden.

Bis zum Aufkommen von FHIR hatte sich eine gewisse Aufgabenteilung etabliert. HL7 hat den Basis-Standard entwickelt und IHE hat darauf aufbauend die Profilierung in Blueprints für die Anwendungsfälle entwickelt und auf den IHE Connectathons getestet. Diese Blueprints wurden wiederum für länder- oder projektspezifische Gegebenheiten weiter angepasst und auf Projektathons getestet. Oft wurden dabei die länder- und projektspezifischen Anpassungen in enger Zusammenarbeit der HL7- und IHE-Länderorganisationen definiert.     

Die Abgrenzung zwischen Basis-Standard und Profilierung ist nicht immer ganz einfach. Einerseits gibt es nicht für alle Anwendungsfälle entsprechende Blueprints der IHE, andererseits haben nicht alle Länder auch die jeweiligen Länderorganisationen etabliert. Eine neue Herausforderung stellt sich auch damit, dass mit der Einführung von FHIR auch HL7 mit den FHIR Accelerators den Basis-Standard profiliert. Zudem benötigt es eine gewisse Zeit, bis sich die Basis-Standards im Markt etabliert haben.

In der Schweiz zum Beispiel folgte die Entwicklung des nationalen elektronischen Patientendossiers (EPD) diesem Prozess. Das Bundesamt für Gesundheit (BAG) erarbeitete in Zusammenarbeit mit dem Koordinationsgremium eHealth Suisse die Schweizer Implementierungsleitfäden basierend auf den IHE-Profilen und IHE-Austauschformaten. Gewonnene Erfahrungen wurden auch wieder zurück in die jeweiligen Gremien geleitet. Die nationalen Leitfäden werden mindestens jährlich an einem Schweizer Projectathon analog zu einem IHE Connectathon getestet. Die Testumgebung Gazelle von IHE Services wurde entsprechend für die nationalen Anforderungen erweitert. Eine Gemeinschaft, die das EPD anbietet, muss die Konformität mit den Leitfäden nachweisen und eine technische Zertifizierung durchlaufen. Neue nationale Leitfäden werden praktisch nur noch auf dem FHIR-Standard entwickelt und neu auch in einem Vernehmlassungsprozess der HL7 Schweiz ballotiert.

Globale Blueprints

Was ist unter einem globalen Blueprint zu verstehen? Jürgen Brandstätter hat dies in einer Auslegeordnung IHE / HL7 / FHIR folgendermassen definiert:2 «Von einem globalen Blueprint spricht man dann, wenn eine bestimmte Standard-basierte Lösung eines Interoperabilitäts-Anwendungsfalls durch den vielerorts angewandten Einsatz dieser Lösung letztendlich als ‹best practice› anerkannt ist, und wenn dafür bereits eine Vielzahl von Produkten am Markt vorhanden sind, welche einen kompetitiven Markt bilden».

IHE hat bekanntlich verschiedene globale Blueprints entwickelt. Ein bekanntes Beispiel sind die anerkannten und weit verbreiteten Blueprints zum Cross-Document Sharing (XDS) für den Austausch von klinischen Dokumenten und die damit verbundenen Profile zur Patientenidentifikation (PIX/PDQ) oder zur Protokollierung (ATNA). Diese Blueprints basieren aber noch auf alten Generationen der Standards (HL7 V2 und V3, ebXML usw.).

Mit FHIR verfolgt HL7 grundsätzlich neue Ansätze. Der Standard wird iterativ entwickelt und die finale Version sowie die Zwischenstände werden als Implementierungsleitfäden auf entsprechenden Webseiten publiziert. IHE hat diese Entwicklungen aufgenommen und die Anwendungsfälle in neuen Blueprints mit dem FHIR-Standard profiliert. Dabei wurde darauf geachtet, dass die neuen Blueprints fachlich abwärtskompatibel zu den bestehenden Blueprints sind. Mittlerweile wurden so FHIR-basierte IHE-Blueprints in den IHE-Domänen ITI, PCC, RAD, QRPH und PHARM erstellt.

Auch die Art und Weise wie diese Blueprints erarbeitet werden, hat sich geändert. Das technische Framework IHE ITI früher unterteilt in verschiedene PDF-Dokumente, wurde neu als Webseite3 publiziert. Zudem nutzt das technische Komitee IHE ITI zur Erarbeitung neuer Blueprints auch FHIR-Implementierungsleitfäden. Diese FHIR-basierten Blueprints der IHE-Domäne ITI werden dadurch neu nicht mehr als PDF-Dokumente, sondern als FHIR Implementation Guide auf Webseiten zusammen mit den dazugehörigen Conformance-Ressourcen veröffentlicht. Insbesondere die Conformance-Ressourcen helfen den Anbietern im Gesundheitswesen, Implementation-konforme Produkte zu entwickeln und zu testen.

Für das Document Sharing und die Patientenidentifikation hat das IHE ITI Technische Komitee mittlerweile die folgenden FHIR-Implementierungsleifäden publiziert:

Mobile access to Health Documents (MHD)

Abbildung: Mobile access to Health Documents (MHD)4

Der Implementierungsleitfaden Mobile Access to Health Documents (MHD) spezifiziert ein standardisiertes API für den Austausch von Gesundheitsdokumenten mit dem FHIR RESTful API. Mit dem Implementierungsleitfaden soll die Entwicklung von leichtgewichtigen Apps und Anwendungen unterstützt werden.

Der Implementierungsleitfaden behandelt die wichtigsten Use Cases des interoperablen Dokumentenaustauschs: die Speicherung von Dokumenten und Dokument-Metadaten, die Abfrage bzw. Suche nach Dokumenten anhand von Dokument-Metadaten und den Abruf der Dokumente. Aus Gründen der Abwärtskompatibilität wurde das Metadatenkonzept aus der IHE-Cross-Document-Sharing-Architektur (XDS.b) übernommen.

Der Implementierungsleitfaden zeigt damit auf, wie eine Infrastruktur zum Austausch von medizinischen Dokumenten basierend auf FHIR-Servern aufgebaut werden kann, die zudem mit einer bestehenden XDS.b-Infrastruktur interoperabel kombiniert werden kann (XDS on FHIR Option). Hersteller können ihre Apps und Anwendungen bereits beim IHE Connectathon testen. Dazu wurde das NIST FHIR Toolkit5 (aka «Asbestos») in die Testplattform Gazelle integriert und die entsprechenden Testfälle für die Implementierung von MHD definiert.

Abbildung: Patient Identifier Cross-referencing for mobile (PIXm)6

IHE und HL7 on FHIR …

Bei der Zusammenarbeit stellen sich den Organisationen bezüglich der Profilierung von FHIR einige Herausforderungen. So stellt sich die Frage, in wessen Kompetenz die Profilierung fällt und wie diese angegangen werden soll, um zu verhindern, dass sich inkompatible Varianten von FHIR Implementierungsleitfäden entstehen. Für Aussenstehende kann es mitunter schwierig sein, die Aufgabenteilung zu erkennen, insbesondere, wenn die gleichen Begriffe in verschiedenen Zusammenhängen verwendet werden.

IHE Profil vs. HL7 Profil

IHE International verwendet den Begriff Profil für die Blueprints des technischen Frameworks, welches Akteure und Transaktionen für die jeweiligen Anwendungsfälle definiert, wie zum Beispiel im oben erwähnten IHE-MHD-Profil. Bei HL7 hingegen wird der gleiche Begriff für die strukturierte Beschreibung der fachspezifischen Einschränkungen von FHIR-Ressourcen (FHIR Ressource Structure Definition) verwendet. Diese begriffliche Trennung kann leicht zu Missverständnissen führen, insbesondere, weil IHE-Profile als Implementierungsleitfäden veröffentlicht werden, die auch FHIR-Profile spezifizieren.

IHE Connectathon vs. HL7 Connectathon

Eine klare Abgrenzung ist auch beim Begriff Connectathon nötig. Die IHE Connectathons sind ein zentraler Bestandteil des IHE-Prozesses, bei denen die Hersteller ihre Produkte auf Konformität mit den Blueprints der IHE testen und verifizieren können. Auf diesen jährlich in den USA, in Europa und in Asien stattfindenden Testwochen haben die Hersteller die Möglichkeit, die Interoperabilität ihrer Produkte zu testen. Zudem können sich die Hersteller die Konformität mit den Blueprints der IHE in einem Integration Statement bestätigen lassen. Zu diesem Zweck ist die Testwoche durch festgelegte Testabläufe strukturiert und Tests werden von Monitoren mit Hilfe der Testumgebung verifiziert. Dabei werden sowohl Tests gegen die Testumgebung ausgeführt (No-Peer) als auch in Interoperbabilitätstests (Peer-to-Peer) überprüft, ob Systeme verschiedener Hersteller interoperabel sind.

FHIR Connectathons werden aber auch von der HL7 organisiert, um zu testen, ob der FHIR-Standard eine genügende Reife zur Implementierung erreicht hat. Ursprünglich als FHIR Hackathon vor den dreimal jährlich stattfindenden Workgroup Meetings begonnen, hat sich inzwischen ein eigenes virtuelles Event etabliert, an dem die FHIR-Spezifikationen und Anwendungen der Hersteller getestet werden. Die Tests auf dem FHIR Connectathon werden aber absichtlich eher adhoc durchgeführt und sind nur wenig organisiert – und erfreuen sich vielleicht gerade aus diesen Gründen einer gewissen Beliebtheit und einer starken Beteiligung. So hatte zum Beispiel der letzte virtuelle FHIR Connectaton im September 2021 mehr als 500 Teilnehmerinnen und Teilnehmer aus der ganzen Welt.

Projekt Gemini, Global Consortium for eHealth Interoperability

HL7 und IHE gehen die Herausforderungen mit der Interoperabilität gemeinsam an und haben mit dem Projekt Gemini gestartet, um die Zusammenarbeit mit dem FHIR-Standard gemeinsam zu stärken. Mit dem Global Consortium for eHealth Interoperability wurde ein Gremium geschaffen, um auch als Partner auf hoher strategischer Ebene zusammenarbeiten zu können.

Fazit

Ein Fazit zu ziehen, ist derzeit noch schwierig. Zusammenfassend zeigt sich aber ein deutlicher Trend zu einer engeren und besseren Zusammenarbeit. Die beteiligten Organisationen konzentrieren sich jetzt stärker auf ihre jeweiligen Stärken und arbeiten Hand in Hand, um die Interoperabilität und Standardisierung im Gesundheitswesen voranzubringen. Die neuen Blueprints des technischen Komitees IHE ITI zeigen, wie eine fruchtbare Zusammenarbeit möglich ist. Auch das Deutsche Interoperabilitätsforum sowie die koordinierten Anhörungen der Schweizer Länderorganisationen von HL7 und der IHE sind positive Beispiele für eine konstruktive Zusammenarbeit.

Autoren

Oliver Egger
ahdis ag, Technical Manager der HL7-Benutzergruppe Schweiz, IHE ITI TC Co-Chair

Martin Smock
eHealth Suisse, Mitglied des Vorstands der IHE Suisse

Bildnachweis: © helen_f/stock.adobe.com

Facebook
Twitter
LinkedIn