Auslegeordnung IHE / HL7 / FHIR...eHealth Suisse – Auslegeordnung IHE / HL7 / FHIR Auslegeordnung IHE_HL7_FHIR v1.2.docx Seite 3 von 43 6.3 FHIR ermöglicht auch anderen Parteien

IHE / HL7 / FHIR Auslegeordnung

Jürgen Brandstätter Gemini Steering Committee

Co-chair, IHE Europe

Co-chair, PHARM, GDC, Education Committee

Member, IHE International Board

https://www.linkedin.com/in/jbrandstaetter

Bern, 11. Oktober 2019

Dokumentversion 1.2

https://www.linkedin.com/in/jbrandstaetter

eHealth Suisse – Auslegeordnung IHE / HL7 / FHIR

Seite 1 von 43

Impressum © eHealth Suisse, Kompetenz- und Koordinationsstelle von Bund und Kantonen

Lizenz: Dieses Ergebnis gehört eHealth Suisse (Kompetenz- und Koordinationsstelle von Bund und Kantonen). Das Schlussergebnis wird unter der Creative Commons Lizenz vom Typ „Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 Lizenz“ über geeignete Informationskanäle veröffentlicht. Lizenztext: http://creativecommons.org/licenses/by-sa/4.0

Weitere Informationen und Bezugsquelle: www.e-health-suisse.ch

Zweck und Positionierung dieses Dokuments Im Interesse einer besseren Lesbarkeit wird auf die konsequente gemeinsame Nennung der männlichen und weiblichen Form verzichtet. Wo nicht anders angegeben, sind immer beide Geschlechter gemeint.

http://creativecommons.org/licenses/by-sa/4.0

http://www.e-health-suisse.ch/


Auslegeordnung IHE_HL7_FHIR v1.2.docx Seite 2 von 43

1 Inhalt 1 Inhalt ....................................................................................... 2

2 Einleitung ................................................................................. 4

2.1 Der Standardisierungsprozess in der Gesundheitsinformatik

5

2.2 IHE, HL7 und FHIR ........................................................... 7

3 Grundlagen zu Interoperabilität ................................................ 9

3.1 Die 3 Stufen des Standardisierungsprozesses .................. 9

3.2 Was ist ein globaler Blueprint? .......................................... 9

3.3 Wie entsteht ein globaler Blueprint? ................................ 11

3.4 Warum ist ein globaler Blueprint so wichtig? ................... 13

3.5 Gibt es bereits globale Blueprints? .................................. 14

4 Die Organisationen IHE und HL7 ........................................... 17

4.1 Vision deckungsgleich, Mission unterschiedlich .............. 17

4.2 Klassische Aufgabenverteilung ....................................... 18

4.2.1 Was ist HL7? ............................................................ 18

4.2.2 Was ist IHE? ............................................................ 19

5 Zusammenarbeit zwischen IHE und HL7 ............................... 23

5.1 Die Dynamik von HL7 FHIR ............................................ 23

5.2 FHIR-basierte IHE Profile ................................................ 24

6 Problemstellungen und Herausforderungen ........................... 27

6.1 FHIR erleichtert Herstellern proprietäre Lösungen .......... 27

6.2 Durch FHIR induzierte Überschneidungen in den

Betätigungsfeldern von HL7 und IHE ......................................... 28

6.2.1 Profilierung des Standards für Anwendungsfälle ...... 29

6.2.2 Testing ..................................................................... 30



6.3 FHIR ermöglicht auch anderen Parteien das Profilieren .. 31

6.4 Missverständnis: „FHIR oder IHE“ (der Birnen/Äpfel -

Vergleich) .................................................................................. 32

6.4.1 Grundsätzliches Missverständnis IHE=Dokumente,

FHIR=Daten .......................................................................... 33

6.5 Fehlinformation und Verwirrung im Markt ........................ 34

7 Lösungsansätze und Neuorientierung ................................... 35

7.1 Profilierung ist auch mit FHIR weiterhin notwendig! ......... 35

7.2 Projekt „Gemini“ .............................................................. 36

7.3 FHIR Community Process (noch in Entwicklung) ............ 38

7.4 IHE und HL7 Testing Events für FHIR ............................. 38

7.5 Zukünftige Positionierung von IHE, HL7 und weiterführende

Kollaborationen ......................................................................... 39

8 Referenzen ............................................................................ 41



2 Einleitung Für Nicht-Insider in der Standardisierung der Gesundheitsinformatik

ist das Zusammenspiel der verschiedenen

Standardisierungsorganisationen und deren Aufgaben und Rollen

oftmals sehr verwirrend.

Eine ganze Reihe von Standardisierungsorganisationen arbeiten im

Bereich der Gesundheitsinformatik/Interoperabilität und teilen sich

das Wirkungsfeld mit möglichst geringen Überlappungen auf, wie

zum Beispiel HL71 für Gesundheitsdatenkommunikation, SNOMED

CT2 und LOINC3 für Terminologien oder DICOM4 im Bereich der

Radiologie und Bildverarbeitung in der Medizin.

Auch Standards von anderen, nicht gesundheitsinformatik-

spezifischen Standardisierungsorganisationen kommen in der

Gesundheitsinformatik zum Einsatz, wie zum Beispiel W3C5, OASIS6

und IETF7 für Internetstandards oder IEEE8 für

Gerätekommunikation.

Darauf aufbauend arbeiten vorgelagerte Profilierungs-

Organisationen wie IHE9 (Gesundheitsdatenaustausch im

Allgemeinen) oder PCHA/Continua10 (für gesundheitsrelevante

Endverbraucher-Geräte) daran, die bestehenden Standards für

Gesundheitsinformatik-Interoperabilitätsanwendungsfälle

1 Health Level 7 (HL7) International, www.hl7.org 2 SNOMED International, www.snomed.org 3 Logical Observation Identifiers Names and Codes (LOINC), www.loinc.org 4 Digital Imaging and Communications in Medicine (DICOM),

www.dicomstandard.org 5 World Wide Web Consortium (W3C), www.w3.org 6 Organization for the Advancement of Structured Information Standards (OASIS),

www.oasis-open.org 7 Internet Engineering Task Force (IETF), www.ietf.org 8 Institute of Electrical and Electronics Engineers (IEEE), www.ieee.org 9 Integrating the Healthcare Enterprise, www.ihe.net 10 Personal Connected Health Alliance (PCHA) www.pchalliance.org

http://www.hl7.org/

http://www.snomed.org/

http://www.loinc.org/

http://www.dicomstandard.org/

http://www.w3.org/

http://www.oasis-open.org/

http://www.ietf.org/

http://www.ieee.org/

http://www.ihe.net/

http://www.pchalliance.org/



zusammenzustellen und die kosteneffiziente Implementierung in der

Praxis zu ermöglichen.

Abgerundet wird das komplexe Bild durch internationale, regionale

oder nationale Normungsgremien (ISO11, CEN12, NIST13, etc.) die

ebenfalls Standards ausgeben, wobei grundsätzlich über bestehende

Liaisons versucht wird, diese in Zusammenarbeit mit obigen

Institutionen zu erstellen, um Doppelgleisigkeiten der sich

widersprechende Standards zu vermeiden.

Die vorliegende Auslegeordnung erläutert die Grundlagen der

Interoperabilität und des Standardisierungsprozesses, und

beleuchtet im speziellen die Aufgaben und Rollen zweier

maßgeblicher Standardisierungsorganisationen IHE und HL7 bzw.

die Position und die ausgelösten Implikationen des aufkommenden

Standards HL7 FHIR.

2.1 Der Standardisierungsprozess in der Gesundheitsinformatik

Kapitel 3 („Grundlagen zu Interoperabilität“) dieses Dokuments

beschreibt den Standardisierungsprozess von Anwendungsfällen in

der Gesundheitsinformatik, der 3 Stufen hat, welche aufeinander

aufbauen und idealerweise nacheinander erfolgen:

1. Entwicklung der Basis-Standards („Stufe 1: Developing the

base standards”)

2. Profilierung der Standards für spezielle Anwendungsfälle

(„Stufe 2: Profiling the standard for particular communities“)

3. Weiterführen der Lösungen in die Produktion für den Markt („Stufe 3: Driving Solutions into production in the

market“)

11 International Organization for Standardization (ISO), www.iso.org 12 European Committee for Standardization, www.cen.eu 13 National Institute of Standards and Technology US, www.nist.gov

http://www.iso.org/

http://www.cen.eu/

http://www.nist.gov/



Ist für einen Anwendungsfall das Ziel der „globale Markt“, ist es

notwendig den beschriebenen Standardisierungsprozess, um

Feedback- und Harmonisierungszyklen zu erweitern, um dadurch zu

einem globalen Blueprint für einen bestimmten Anwendungsfall zu gelangen.

Von einem globalen Blueprint spricht man dann, wenn eine bestimmte Standards-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.

Ein globaler Blueprint beinhaltet alles „gemeinsame“,

lässt aber gleichzeitig Raum für die jeweiligen

nationalen/regionalen Eigenheiten.

Pro Anwendungsfall kann es natürlich auch mehrere solcher

Lösungen geben, wobei die Konvergenz zu einer Lösung

anzustreben ist.

Ein Vergleich: Aus den zwei konkurrenzierenden Blueprints für den

Anschluss von Geräten an den Computer, USB und Firewire, hat sich



letztendlich der USB Standard als der finale globale Blueprint für

diesen Interoperabilitäts-Anwendungsfall herauskristallisiert.

Die Ausbildung solcher globaler Blueprints ist auch in der

Gesundheitsinformatik absolut anzustreben, denn

Anwendungsfälle in der Gesundheitsinformatik sind global sehr ähnlich und es wohnt in jedem Anwendungsfall ein großes Potential

an „globaler Harmonisierung“ inne. Natürlich sind die

Interoperabilitäts-Anwendungsfälle in der Gesundheitsinformatik

ungleich komplexer als bei USB, und durch die Vielzahl beteiligter

Stakeholder (Gesundheitsdiensteanbieter, Gesetzgeber, öffentliche

Hand, Hersteller, etc.) auch nicht einfach durch einen Industrie-

Standard zu lösen.

Es ist daher nicht einfach und durchaus langwierig zu einem globalen

Blueprint zu gelangen. Jedoch ist in Zeiten der Errichtung nationaler

oder gar cross-border Gesundheitsdatenaustausch-Infrastrukturen

das Potential von derartigen globalen Lösungen unbedingt

anzustreben und zu nutzen, da der dadurch gewonnene globale

Markt Herstellerunabhängigkeit, Wettbewerb und damit niedrigere Kosten und Nachhaltigkeit bedeutet.

2.2 IHE, HL7 und FHIR

In den weiteren Kapiteln beschreibt dieses Dokument die Rollen und

Aufgabenverteilung der beiden Organisationen IHE und HL7 in

obigem Standardisierungsprozess, sowie die Änderungen, die durch

den neuen aufkommenden Standard HL7 FHIR induziert werden.

Die klassische Aufgabenverteilung …

• HL7 in

o „Stufe 1: Entwicklung der Basis-Standards“ und

• IHE in

o „Stufe 2: Profilierung der Standards für spezielle

Anwendungsfälle“ und

o „Stufe 3: Weiterführen der Lösungen in die Produktion

für den Markt“)



… wird durch die Implikationen des FHIR Standards zunehmend

überlappend und weniger klar abgegrenzt.

HL7 und auch andere Organisationen bzw. sogar Projekte mit breiter,

internationaler Wirkung, beginnen sich nun auch in Stufe 2

„Profilierung“ zu betätigen. Dies schafft ein gewisses Maß an

Verwirrung im Markt, ob der Zuständigkeiten und Kernkompetenzen

der einzelnen Organisationen und wirkt einem koordinierten

Vorgehen hinsichtlich des Erlangens globaler Blueprints entgegen.

Außerdem trägt der Hype rund um FHIR dazu bei, dass vermehrt

wieder „einfache Lösungen“ versprochen werden, mit dem Verweis

auf die zu hohe Komplexität der Vorgänger-Standards von FHIR, wie

z.B. HL7v3 Messaging oder CDA. Diese können aber oftmals nicht

eingehalten werden, da die Komplexität den Prozessen innewohnt,

und nur zu einem geringen Teil von einem effizienteren Standard

abgeschwächt werden können („the complexity of the processes do

not disappear just because of a new standard“).

All dies stellt insofern ein Problem dar, da die oben gezeichnete

Botschaft der Notwendigkeit von globalen Blueprints (mit der

einhergehenden Nachhaltigkeit) und wie man zu jenen gelangt,

mancherorts wieder in den Hintergrund gerückt ist.

Diesen Entwicklungen wird nun von beiden Organisationen IHE und HL7, sowie von weiteren anderen, die dies als Problem

identifiziert haben, entgegengewirkt (siehe Kapitel 7,

„Lösungsansätze und Neuorientierung“). Es geht darum, den

Herausforderungen „gemeinsam“ zu begegnen und eine

gemeinsame Neuorientierung und -positionierung zu erreichen,

sodass die Kernkompetenzen beider Organisationen optimal

wirksam werden.



3 Grundlagen zu Interoperabilität

3.1 Die 3 Stufen des Standardisierungsprozesses

Der Standardisierungsprozesses der Gesundheitsinformatik besteht

im Wesentlichen aus drei, aufeinander aufbauenden Stufen (siehe

dazu Grahame Grieve’s Blog „The 3 Legs of the Health Informatics

Standards Process“):

1. Entwicklung der Basis-Standards („Stufe 1: Developing the

base standards”)

2. Profilierung der Standards für spezielle Anwendungsfälle

(„Stufe 2: Profiling the standard for particular communities“)

3. Weiterführen der Lösungen in die Produktion für den Markt („Stufe 3: Driving Solutions into production in the

market“)

Diese drei Stufen sind als eine Grundstruktur zur Erlangung von

Interoperabilität zu betrachten, also der theoretische Weg zu einem

Blueprint für einen Markt. In der Regel bedarf es bis zu einer

anerkannten Lösung in diesem Markt noch einige Feedback- und

Harmonisierungszyklen innerhalb dieser 3 Stufen, bis dieser sich als

„best practice“ in diesem Markt herauskristallisiert hat, sozusagen ein

Blueprint in diesem Markt oder Region.

Ist der im Standardisierungsprozess angestrebte Markt „global“ (was

er sein sollte!) wird die vom Prozess hervorgebrachte Lösung ein

globaler Blueprint.

3.2 Was ist ein globaler Blueprint?

„Plug-and-play“ ist in der Gesundheitsinformatik äußerst selten, aber

dennoch sind die Anwendungsfälle in der Gesundheitsinformatik in

der Regel global sehr ähnlich.

Abhängig vom Anwendungsfall schwankt die globale

Übereinstimmung von „nahezu überall identisch“ (z.B:

Patientenidentifikation und -abfrage, Audit-Prozesse, etc.) bis zu

http://www.healthintersections.com.au/?p=2921




„identisch in den Kernprinzipien, aber signifikante Unterschiede in

den Inhalten“ (z.B. Austausch von Dokumenttypen, etc.). Ein

Anwendungsfall kann also immer in zwei Teile aufgeteilt werden, jene

Bereiche, welche „global gleich“ sind, und jene, welche

„nationale/regionale Eigenheiten“ beinhalten. In der Regel wohnt

aber in jedem Anwendungsfall ein mehr oder weniger großes

Potential an „globaler Harmonisierung“ inne.

Wird eine bestimmte Standards-basierte Lösung eines Interoperabilitäts-Anwendungsfalls durch den vielerorts

angewandten Einsatz dieser Lösung letztendlich als „best practice“

anerkannt, und wenn dafür bereits eine Vielzahl von Produkten am

Markt vorhanden sind, welche einen kompetitiven Markt bilden,

spricht man von einem globalen Blueprint. Es natürlich auch

mehrere solcher Lösungen pro Anwendungsfall geben, aber

langfristig ist die Konvergenz zu einer Lösung anzustreben bzw.

findet naturgemäß von selbst statt.

Ein globaler Blueprint beinhaltet alles „gemeinsame“,

lässt aber gleichzeitig Raum für die jeweiligen

nationalen/regionalen Eigenheiten.

Die Anwendungsfälle in eHealth sind mannigfaltig und erstrecken

sich von administrativen Prozessen (z.B. Patientenidentifikation, etc.)

bis hin zu klinischen Prozessen (Austausch klinischer Dokumente

oder Informationen, etc.).

Viele von diesen Anwendungsfällen bauen aufeinander auf, oder

bedingen einander. Letztendlich ist anzustreben, dass für alle diese

Anwendungsfälle jeweils globale Blueprints entstehen, welche

zueinander kompatibel sind und sich nahtlos ergänzen.



3.3 Wie entsteht ein globaler Blueprint?

Zu einem globalen Blueprint zu gelangen ist nicht einfach und

durchaus langwierig. Der Weg erstreckt sich über mehrere Phasen.

Die folgende Grafik zeigt den Weg von den ersten Versuchen einen

Anwendungsfall zu lösen (verschiedenste „Trial“ Entwicklungen),

über die Phasen, in denen sich aus den weltweiten Versuchen die

„best practice“ herausstellt („Usability“ und „Harmonization“), bis hin

zur globalen Akzeptanz dieser Lösung als globalen Blueprint wegen

Serienreife und Vorhandensein eines kompetitiven Markts („Cost-

efficiency“ und „Acceptance“).



Es liegt auf der Hand, dass die einzelnen Phasen des Weges die

jeweils erforderliche Zeit benötigen, um zu reifen und

ordnungsgemäß durchlaufen zu werden. Der Prozess kann zwar

durch geeignete Maßnahmen beschleunigt werden, braucht aber

jedenfalls eine substanzielle Zeitspanne, andernfalls wird die am

Ende notwendige Akzeptanz nicht erreicht, welche den globalen

Blueprint letztendlich als solchen bestätigt. In der Regel dauert es

mehrere Jahre, bis man dies auf globaler Ebene erreicht.

Selbstverständlich wird hier nicht der Anspruch erhoben, dass sich

die ganze Welt notwendigerweise auf eine Art der Lösung einigen

muss, aber je größer die Gruppe, desto höher der Nutzen. Und

natürlich kann es auch mehrere Lösungen parallel geben, wie auch

die ständig voranschreitende Weiterentwicklung und Innovation

immer wieder neue Blueprints produzieren wird:

• entweder als modernere Lösung für bereits bestehende

Anwendungsfälle

o Beispiel: USB 3.0 löst USB 2.0 ab, gleicher Zweck, ist

aber besser



• oder für neue Anwendungsfälle, für die erstmalig ein

Blueprint entwickelt wird

o Beispiel: NFC am Handy, erstmalig ist drahtlose

Nahfeld-Kommunikation möglich

3.4 Warum ist ein globaler Blueprint so wichtig?

Globale Blueprints sind deshalb wichtig, weil während der

Entstehung die globalen Gemeinsamkeiten des Anwendungsfalls

nicht nur erfasst, sondern über die geleistete globale

Harmonisierungsarbeit, auch noch vermehrt werden. Die Arbeit am

globalen Blueprint bewirkt also, dass auf globaler Ebene dieser

Anwendungsfall „einheitlicher“ gelöst wird. Somit eröffnet sich das

Potential, die gestellten Probleme „einmal für alle“ zu lösen (oder

sich dem möglichst weit anzunähern).

Dies wiederum zieht ein erhebliches Maß an positiven Folgen und

Möglichkeiten nach sich. Einerseits macht es das Vorhandensein

solcher Blueprints wesentlich leichter, Spezifikationen für ein Projekt

zu erstellen, da der grundsätzliche Lösungsansatz schon ausgearbeitet ist, und weite Teile der eigenen Spezifikation mittels

„copy & paste“14 von anderen Projekten übernommen werden können

("geborgte Kompetenz der Community nutzen“). Andererseits bringt

der durch einen globalen Blueprint gewonnene „globale Markt“

Herstellerunabhängigkeit und Wettbewerb, was letztendlich

schnellere Implementierung, niedrigere Kosten und Nachhaltigkeit bedeutet.

Ein globaler Blueprint bringt Aufwands- und Kostenersparnisse in den

folgenden Bereichen:

• Akzeptanz für die Lösung bei allen Projektteilnehmern schaffen

14 Damit ist gemeint, dass weite Teile des Lösungsansatzes übernommen

werden können



o Dies ist z.B. in nationalen Projekten ein aufwändiger

Prozess, der wesentlich leichter fällt, wenn auf globale

Blueprints verwiesen werden kann

• Erstellung der Projektspezifikationen o Geschieht wesentlich schneller, da weite Teile der

Spezifikation bereits gegeben sind. Sie müssen nur

mehr um die projekt-spezifischen Eigenheiten ergänzt

werden

• Ausschreibung und Beschaffung o Ausschreibungen sind wesentlich weniger komplex

und die einlangenden Angebote viel schneller und

besser vergleichbar

o Produkte sind günstiger, weil der globale Blueprint

einen kompetitiven Markt mit vergleichbaren

Produkten geschaffen hat „Von der Stange“ statt

maßgeschneidert

• Rollout und Testing o Globale Blueprints erlauben es, weite Teil des

Interoperabilitäts-Testens bereits auf der Ebene des

Blueprints abzudecken („IHE Connectathon“), was

den projekt-eigenen Testbedarf minimiert (Projekt-

spezifischer „Projectathon“)

o Das ist ein großer Kostenfaktor -> Ersparnisse in

diesem Bereich, selbst wenn nur im Prozent-Bereich,

wirken sich finanziell in der Regel stark aus

3.5 Gibt es bereits globale Blueprints?

Globale Blueprints in der Gesundheitsinformatik sind bereits Realität,

zum Beispiel für den Austausch von klinischen Dokumenten, welcher

über die IHE Profil-Familie rund um Cross-Document Sharing (XDS),

inklusive der damit verbundenen Profile wie zum Beispiel zur

Patientenidentifikation (PIX/PDQ) oder Audit (ATNA) weit verbreitet

und anerkannt ist.



Um zu derartigen Lösungen zu gelangen, ist jedoch eine

ausreichende Menge an globalen Teilnehmern nötig, um die damit

einhergehende und notwendige „globale Harmonisierung“ zu

bewerkstelligen. Außerdem ist es ein gesamt-kollaborativer Prozess, da die Teilnehmer sowohl aus der Anwender- als auch

Hersteller Seite kommen müssen. Dies ist naturgemäß ein großer

Aufwand, jedoch ist dieser Prozess absolut anzustreben, denn in

Zeiten der Errichtung nationaler oder gar cross-border

Gesundheitsdatenaustausch-Infrastrukturen ist das Potential,

welches dadurch eröffnet wird, unbedingt zu nutzen.

Beispielsweise hat die Europäische Kommission sich bei ihren

Spezifikationen rund um die Europäische eHealth Digital Service Infrastructure (eHDSI)15 zum Austausch von Gesundheitsdaten

zwischen EU Mitgliedsstaaten (vormals epSOS Projekt) bereits

existierende globale Blueprints zunutze gemacht. In diesem Fall die

anerkannten und erprobten IHE Profile aus der IHE IT-Infrastructure

Domäne zum Dokumentenaustausch.

Die im Februar 2019 ausgesprochene EC Empfehlung zu einem „European Electronic Health Record exchange format“16 stützt

15 Europäische Kommission, eHealth Digital Service Infrastructure,

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+

Operations+Home

16 EC Recommendation on a European Electronic Health Record exchange

format: https://ec.europa.eu/digital-single-

market/en/news/recommendation-european-electronic-health-record-

exchange-format

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home

https://ec.europa.eu/digital-single-market/en/news/recommendation-european-electronic-health-record-exchange-format





sich im Bereich der Erweiterung der eHDSI ebenfalls auf bereits

erprobte „best-practices“ in den Bereichen:

• Entlassungsbrief-,

• Radiologie- und

• Labor-Informationsaustausch.

Weiters ermöglichen globale Blueprints die Aufnahme in

Investmentpläne und Beschaffungskataloge. Beispielsweise sind

die IHE Profile aus der EU Empfehlung

„COMMISSION DECISION (EU) 2015/1302 of 28 July

2015 on the identification of ‘Integrating the Healthcare

Enterprise’ profiles for referencing in public procurement“

17

in den

Europäischen Katalog für ICT Beschaffung18

aufgenommen worden.

17 European Commission recognizes 27 IHE profiles that should be

referenced in public procurement documents: http://eur-lex.europa.eu/legal-

content/EN/TXT/?uri=OJ:JOL_2015_199_R_0011 18https://joinup.ec.europa.eu/collection/ict-standards-

procurement/identified-ict-specifications-procurement

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2015_199_R_0011


https://joinup.ec.europa.eu/collection/ict-standards-procurement/identified-ict-specifications-procurement

https://joinup.ec.europa.eu/collection/ict-standards-procurement/identified-ict-specifications-procurement



4 Die Organisationen IHE und HL7 Dieses Kapitel beschreibt die Vision, Mission und klassische

Aufgabenverteilung der Standardisierungsorganisationen IHE und

HL7.

4.1 Vision deckungsgleich, Mission unterschiedlich

Die Visionen der beiden Organisationen HL719 und IHE20 sind nahezu

deckungsgleich:

HL7 A world in which everyone can securely access and use

the right health data when and where they need it.

IHE Enable seamless and secure access to health

information that is usable whenever and wherever

needed.

Die Mission, um die Vision zu erreichen ist allerdings unterschiedlich,

HL7 fokussiert auf „Standards“, IHE auf „Specifications, Tools and Services“:

HL7 To provide standards that empower global health data

interoperability.

IHE IHE improves healthcare by providing specifications, tools and services for interoperability. IHE engages

clinicians, health authorities, industry, and users to

develop, test, and implement standards-based solutions

to vital health information needs.

19 https://www.hl7.org/about 20 https://www.ihe.net/about_ihe

https://www.hl7.org/about

https://www.ihe.net/about_ihe



4.2 Klassische Aufgabenverteilung

Die klassische Aufgabenverteilung zwischen den beiden

Organisationen gemäß Kapitel 3.1, „Die 3 Stufen des

Standardisierungsprozesses“ ist wie folgt:

HL7 Stufe 1 „Basis Standards“

IHE Stufe 2 “Profilierung” (IHE Profile) und

Stufe 3 „Deployment“ (Testing am IHE Connectathon

und IHE Services21)

Allerdings wird mit dem Erscheinen von FHIR dieses klassische

Zusammenspiel zunehmend neu ausgerichtet. Mittlerweile betätigen

sich HL7 (und andere Organisationen) ebenfalls in Stufe 2 und haben

auch Stufe 3 als Ziel.

In diesem Zusammenhang gab es in den letzten Jahren auch immer

wieder Ereignisse, die die grundsätzlich freundliche Zusammenarbeit

überschattet haben. Siehe dazu Kapitel 6, „Problemstellungen und “

und Kapitel 7, „Lösungsansätze und Neuorientierung“.

4.2.1 Was ist HL7?

HL7 ist eine Non-Profit-Standardisierungsorganisation im

Gesundheits-IT-Wesen, welche seit 1987 Standards erstellt und

publiziert. Ursprünglich in den USA gegründet, arbeitet HL7

inzwischen als Normengremium auf internationaler Ebene. Früher

nicht kostenfrei, können HL7 Standards seit einigen Jahren kostenlos

genutzt werden.

Bekannte HL7 Standards sind …

21 IHE Services ist die operative Einheit von IHE Europe und offeriert

Services im Bereich Beratung und Testing im Zusammenhang mit IHE.

Siehe https://www.ihe-europe.net/deployment/IHE-Services

https://www.ihe-europe.net/deployment/IHE-Services



• HL7v2 Messaging Standard, welche text-basiert ist und vor

allem in der intramuralen Kommunikation zwischen Systemen

eine sehr weite Anwendung findet.

• HL7v3 RIM („Reference Information Model“), welches XML-

basiert als eine Weiterentwicklung von HL7v2 entwickelt

wurde, und gleichermaßen für Message-basierte als auch

persistierte Kommunikation dienen sollte. HL7v3 Messaging

hat sich, bis auf wenige Ausnahmen, nicht durchgesetzt und

konnte HL7v2 defacto nicht ablösen. Das HL7v3 RIM Modell

wurde zwar als sehr mächtig eingestuft, aber gleichzeitig als

sehr kompliziert und schwer zu verstehen und

implementieren.

• CDA („Clinical Document Architecture“), welche auf dem

HL7v3 RIM Modell basiert, und zur Abbildung von klinischen

Dokumenten entwickelt wurde. Kombiniert zum Beispiel mit

der IHE XDS („Cross-Enterprise Document Sharing“) Profil

Familie hat sich der Standard für den überregionale

Austausch von klinischen Dokumenten (auf regionaler oder

nationaler Ebene, bzw. cross-border) als geeignet erwiesen

und wird angewandt.

• FHIR („Fast Healthcare Interoperability Resources“), ist

ein völlige Neuentwicklung. FHIR beschreibt Datenformate

und Elemente als sogenannte „Ressourcen“ und bietet eine

Schnittstelle (API) an, um diese auszutauschen. Ein starker

Fokus liegt dabei auf einer einfachen Implementierbarkeit.

Moderne web-basierte API Technologien, wie das HTTP-

basierte RESTful Protokoll, HTML, TLS und OAUTH2

kommen bei FHIR zum Einsatz. Für die Repräsentation der

Daten kann sowohl JSON als auch XML verwendet werden.

4.2.2 Was ist IHE?

Integrating the Healthcare Enterprise (IHE) wurde 1998 in den USA

gegründet und ist eine weltweite Non-Profit-Initiative mit im Bereich

eHealth. Sie widmet sich der Interoperabilität in der

Gesundheitsinformationstechnologie.



IHE arbeitet mit Anwendern und Herstellern zu häufig benötigten eHealth Interoperabilitäts-Anwendungsfällen, um für sie weltweit akzeptable,

detaillierte und auf Standards basierende Spezifikationen zu erstellen.

Darüber hinaus unterstützt IHE den Einsatz dieser Profile

durch eine Open-Source-Testplattform und eine Produktkonformitätsprüfung.

Anwendungsfälle für die Interoperabilität von eHealth sind weltweit

sehr ähnlich. Der Beitrag von IHE besteht darin, sicherzustellen, dass

diese globalen Gemeinsamkeiten in der Standardgemeinschaft

herausgearbeitet werden, bevor sie für bestimmte Märkte oder

Implementierungen als Basis dienen und gegebenenfalls um lokale

Anforderungen weiter bereichert werden.

IHE profiliert die Anwendungsfälle bis zum größtmöglichen Grad globaler Gemeinsamkeit (in etwa 80-90%, je nach

Anwendungsfall), und achtet gleichzeitig darauf, die darüber hinaus

gehenden Bereiche offen zu lassen. Bis auf ganz wenige Ausnahmen

benötigt der Kontext des Anwenders der Profile nämlich in der Regel

noch spezielle Anpassungen im verbleibenden Prozentbereich, zum

Beispiel spezielle Terminologien oder Datenelemente, um zur

eigentlichen Interoperabilitäts-Spezifikation des Anwenders zu

kommen.

Diese Interoperabilitäts-Spezifikation deckt dann den

Anwendungsfall vollständig im jeweiligen Kontext ab, zum Beispiel in

einer nationalen Spezifikation. Derartige nationale Erweiterungen

können in der IHE dann als „National Extensions“ wiederum publiziert

werden (Technical Framework, Volume 4), zum Nutzen und Vorlage

für andere, nachfolgende Länder.



Nutzer von IHE Profilen müssen beim Verfassen Ihrer

Interoperabilitäts-Spezifikationen nur mehr die speziellen Abweichungen vom Profil definieren.

Die Leistung der internationalen Profilierung und Abstimmung des

„global gemeinsamen Teils“ wird von der IHE zum Gemeinwohl

beigesteuert und führt zu einem erheblich geringeren Aufwand für die

Nutzer der Profile, welche nur mehr die speziellen Abweichungen

vom Profil definieren müssen.

Die dadurch erzielte Kostenersparnis ist vor allem bei großen

Unternehmungen enorm. Sie erstreckt sich über …

• … die Erstellung der Interoperabilitäts-Spezifikationen,

• … den Aufwand des Ausschreibens und deren Prüfung,

• … der nötigen projekt-spezifischen Änderungen an gemäß

Profilen entwickelten, fertigen Produkten und

• … des Testens.

Insbesondere die Reduktion beim Test-Aufwand ist maßgeblich für

die Kosten-Effizienz, da diese nicht nur beim ersten Testen vor

Inbetriebnahme anfallen, sondern während der gesamten Laufzeit

des Projekts (Onboarding von neuen Teilnehmern).

IHE Profile sind frei zugänglich und kostenlos. Häufig werden in IHE

Profilen HL7 Standards verwendet, abhängig vom Interoperabilitäts-

Anwendungsfall aber andere Standards, wie z.B. DICOM, SNOMED,

LOINC, W3C, OASIS, etc.

Die folgende Grafik veranschaulicht das Lego-Baustein Prinzip,

welches durch die IHE Profilierung verfolgt wird. Die Folge sind

Standards-Bausteine passend zu den jeweiligen Anwendungsfällen.



IHE Profile sind aufeinander abgestimmt und können je nach Bedarf

oder Notwendigkeit miteinander kombiniert werden, um komplexere

Anwendungsfälle abzubilden. Zum Beispiel Patientenidentifikation

kombiniert mit Gesundheitsdienstanbieter-Authentifikation und dazu

passendem Audit/Logging um klinische Dokumente bereitzustellen

(„Document Sharing“), wobei auch alle anderen Anwendungsfälle,

die dieselben Basiskomponenten benötigen, dieselben Baustein

verwenden (z.B. ein „Audit/Logging“-Baustein für alle

Anwendungsfälle).

Zu vielen IHE Profilen sind bereits Produkte zur Marktreife gebracht

und global im operativen Einsatz (vor allem in den IHE Domänen IT-

Infrastructure und Radiology).



5 Zusammenarbeit zwischen IHE und HL7

Beide Organisationen arbeiten seit Jahren in denen Ihnen klassisch

zugesprochenen Bereichen gut zusammen.

Es existiert zwischen IHE und HL7 seit vielen Jahren ein „Statement

of Understanding“ zur gegenseitigen Förderung und

Zusammenarbeit, welches im Jahr 2018 erst wieder erneuert wurde,

und die starke freundschaftliche Verflechtung der beiden

Organisationen belegt.

Wenngleich die Organisationen grundsätzlich getrennt sind und die

Mitgliederschaft unterschiedlich ist, sind im Bereich der

ehrenamtlichen Standards-Entwicklung auch eine Menge der aktiven

Personen in beiden Organisationen tätig. Durch dieses persönliche

Engagement ergibt sich eine noch tiefere Zusammenarbeit in

manchen Bereichen.

HL7 Standards, zum Beispiel HL7v2, HL7v3 und CDA sind äußerst

oft verwendete Standards in IHE Profilen. Aber auch FHIR kommt

bereits in einer Vielzahl von IHE Profilen bereits zur Anwendung; eine

Tatsache, die noch relativ wenig bekannt ist. Man kann vielmehr

sagen, dass die Mehrzahl der neuen IHE Profile den FHIR Standard

verwenden. Außerdem werden auch laufend zu etablierten IHE

Profilen, welche klassische Standards verwenden, FHIR-basierte

Erweiterungs- und Ergänzungsprofile erstellt. Siehe dazu Kapitel 5.2,

„FHIR-basierte IHE Profile“.

5.1 Die Dynamik von HL7 FHIR

FHIR hat es geschafft eine Community von jungen Entwicklern über

die Technologie für die Standardisierung zu begeistern.

Die Weiterentwicklung des FHIR-Standards ist sehr modern, Tool-

getrieben und damit attraktiv für die Community. Dies führt zu einer

schnelleren und qualitativ-höheren Standards-Entwicklung und ist



unter anderem einer der Faktoren für den Erfolg von FHIR als

Standard.

Um dem Rechnung zu tragen, hat HL7 nahezu vollständig auf den

FHIR Standards eingeschwenkt und die Mehrzahl aller derzeitigen

Aktivitäten beziehen sich auf diesen neuen Standard.

Der FHIR Standard ist immer noch in Entwicklung, wobei mit jeder

verabschiedeten Fassung die Anzahl der bereits als „normativ“

eingestuften Bereiche größer wird, und auch die restlichen Bereiche

an Stabilität immer mehr zunehmen.

5.2 FHIR-basierte IHE Profile

Zum Zeitpunkt dieses Reports, sind 27 FHIR-basierte IHE Profile

publiziert. Die Publizierung erfolgte im Einklang mit den

Publizierungsrichtlinien von FHIR Implementation Guides auf der

Website fhir.org.

Übersicht über IHE Profile:

https://wiki.ihe.net/index.php/Profiles (FHIR-basierte IHE Profile sind mit einem FHIR Symbol

gekennzeichnet)

FHIR IG Übersicht auf fhir.org:

http://www.fhir.org/guides/registry

FHIR-basierte IHE Profile wurden bis dato in den IHE Domänen ITI,

PCC, RAD, QRPH und PHARM erstellt. Anfänglich wurden FHIR-

basierte IHE Profile als Ergänzung zu bestehenden IHE Profilen

erstellt (z.B. der FHIR-basierte Zugriff auf Patientendaten mittels

PIXm und PDQm, oder der FHIR-basierte Zugriff auf XDS basierten

Dokumentenaustausch mittels MHD).

https://wiki.ihe.net/index.php/Profiles




Grundsätzlich kann man sagen, dass neue IHE Profile

Anwendungsfälle derzeit sehr oft den FHIR Standard verwenden, da

dieser als moderner und effizienter Standard angesehen wird,

welcher das Potential hat, langfristig die bestehenden Standards

abzulösen.

Eine grundsätzliche Schwierigkeit bei der Profilierung von FHIR war

der über lange Zeit gegebene, nicht-stabile Status des Standards.

Erst vor kurzem wurde mit FHIR Release 4 der die erste normative

Version des Standards verabschiedet22, wobei allein von R3 zu R4

zirka 3000 Änderungen23 (davon > 1000 substanziell) eingearbeitet

wurden. Die Situation hat sich also bereits stark verbessert, es ist

aber davon auszugehen, dass der Standard noch für einige Zeit in

Bewegung bleibt.

Dies steht der grundsätzlichen Maxime von IHE, nur „existierende“,

etablierte und erprobte Standards für seine IHE Profile zu

verwenden, um entsprechende Stabilität in den Produkten zu

gewährleisten, eigentlich im Wege. Aufgrund der großen Nachfrage

nach FHIR am Markt hat die IHE aber dennoch recht früh begonnen

22 Das bedeutet, diese Version des Standards hat zum ersten Mal einen „normativen

Ballot“ passiert 23 Quelle: http://hl7.org/fhir/history.html

http://hl7.org/fhir/history.html



FHIR-basierte IHE Profile zu erstellen, und schärft diese mit den

Releases von FHIR laufend nach.



6 Problemstellungen und Herausforderungen

Dieses Kapitel beschreibt diverse bestehende oder neue

Problemstellungen und Kontroversen, welche durch FHIR

aufgetreten sind oder verstärkt wurden.

Allen genannten Punkten wird bereits von beiden Organisationen IHE

und HL7 gemeinsam entgegengewirkt.

6.1 FHIR erleichtert Herstellern proprietäre Lösungen

Immer schon war für Hersteller die Möglichkeit gegeben, gegebene

Standards unabgestimmt und ohne Governance heranzuziehen, um

eigene Kommunikationslösungen in ihren Produkten zu

implementieren. Dies geschah bereits in den 1990iger Jahren bei

HL7v2 und beim DICOM Standard, was damals die Situation schaffte,

dass trotz „Basierens auf demselben, internationalen Standard“

Produkte verschiedener Hersteller dennoch nicht interoperabel

waren. Diese Situation war seinerzeit der Auslöser der Gründung von

IHE, mit dem Zweck genau diesem Phänomen am Markt

entgegenzuwirken. Nach jahrelanger Profilierungs- und

Überzeugungsarbeit durch IHE wurde diese unbefriedigende

Situation für etliche wichtige Interoperabilitäts-Anwendungsfälle am

Markt entschärft.

Durch die Einfachheit von FHIR, ist jetzt dieses Vorgehen für

Hersteller wiederum attraktiv geworden. Getrieben von Innovation

und dem kommerziellen Zwang damit schnell am Markt sein zu

müssen, greifen Startups sowie etablierte Firmen wiederum zu der

Abkürzung, ihre eigenen Kommunikationslösungen mit FHIR

(unabgestimmt mit anderen) zu implementieren. Dies führt wieder

vermehrt zu Doppelgleisigkeiten, proprietären Lösungen und damit

zu Silo-Anwendungen, die wiederum nur mit Mehraufwand und

Schnittstellen mit anderen Systemen kombiniert werden können.



Aus Standardisierungs-Sicht ist dieser Ansatz, der die Abstimmung

und das Profilierens des Anwendungsfalls innerhalb der Standards-

Community nicht beinhaltet, als problematisch anzusehen. Obwohl

hier vorderhändig versucht wird Interoperabilität (sogar auf Basis von

internationalen Standards) herzustellen, wird der nachhaltigen

Standardisierung eigentlich entgegengewirkt.

Von den wenigen problematischen Effekten, die FHIR unbeabsichtigt

verursacht, ist dieser Punkt wahrscheinlich der negativste, da diese

Entwicklungen dem Anstreben von globalen Blueprints (siehe Kapitel

3, „Grundlagen zu Interoperabilität“) am meisten entgegenwirkt.

6.2 Durch FHIR induzierte Überschneidungen in den Betätigungsfeldern von HL7 und IHE

Der große Erfolg (und Hype) von FHIR, sowie dessen technische

Einfachheit und Tool-basierte Entwicklung, hat HL7 hinsichtlich

seines Betätigungsfeldes und Einflussbereiches

Handlungsmöglichkeiten eröffnet, welche vorher nicht vorhanden

waren, nämlich in den Bereichen „Profilierung“ und „Testing“. Beides

waren ursprünglich alleinige Domänen von IHE.

Diese Erweiterung des Betätigungsfeldes rüttelt an der klassischen

Aufgabenverteilung und führte anfangs zu einer gewissen

Kontroverse zwischen den beiden Organisationen IHE und HL7,

letztendlich aber zu Neuorientierung und mehr Kollaboration (siehe

Kapitel 7, „Lösungsansätze und Neuorientierung“).



6.2.1 Profilierung des Standards für Anwendungsfälle

Im Zuge der Entwicklung des FHIR Standards hat HL7 auch das

Konzept des „FHIR Implementation Guides“ (FHIR-IG)24 eingeführt,

welcher sich auf einen Interoperabilitäts-Anwendungsfall bezieht und

damit einem IHE Profil im Zweck sehr nahekommt. Damit betritt HL7

das Gebiet der „Profilierung“, wobei die Governance rund um die

FHIR-IGs nicht so weit geht, wie diejenige rund um ein IHE Profil und

auch andere Einschränkungen vorherrschen, wie zum Beispiel, dass

ein FHIR-IG sich nur auf den FHIR-Standard bezieht, während ein

IHE Profil nicht zwingend auf FHIR festgelegt ist, und beliebig viele

Standards kombinieren kann.

FHIR-Implementation Guides können im Unterschied zu IHE Profilen

von jedermann erstellt werden und befinden sich daher nicht

zwangsweise unter der Governance und den Qualitäts-Richtlinien

von HL7. Es gibt auch mehrere unterschiedliche Plattformen, mittels

welchen ein FHIR Implementation Guide publiziert werden kann,

einerseits unter HL7 selbst (HL7 FHIR-IG Registry25), aber auch von

kommerziellen Anbietern (z.B.: Firely Simplifier26, etc.).

Um den negativen Auswirkungen dieser Freiheitsgrade

entgegenzuwirken, wurde kürzlich von HL7 der „FHIR Community

Process“ ins Leben gerufen (siehe Kapitel 7.3).

Die folgende Grafik zeigt den theoretischen Weg vom „Standard

zum getesteten, interoperablen Produkt“:

24 http://wiki.hl7.org/index.php?title=FHIR_Implementation_Guides 25 http://www.fhir.org/guides/registry 26 https://simplifier.net/guides

http://wiki.hl7.org/index.php?title=FHIR_Implementation_Guides


https://simplifier.net/guides



In diesem „Pfad vom Standard bis zum getesteten, marktreifen,

interoperablen Produkt“ ist ein FHIR-IG also der Endpunkt auf Seiten

HL7, wobei ein IHE Profil der Ausgangspunkt für die weiteren

Aufgaben in der Kette darstellt, nämlich das Software-Testen am IHE

Connectathon und weiterführend das Conformity Assessment von

Produkten, um letztendlich die Reife für den Markt zu bereiten.

Damit dieser zu beschreitende Weg nicht beim FHIR-IG aufhört,

sondern der Prozess bis zu marktreifen, getesteten Produkten (bei

Akzeptanz am Markt dann insgesamt einen globalen Blueprint

darstellend) weitergeführt wird, wurde 2018 das gemeinsamen

IHE/HL7 Gemini-Projekt ins Leben gerufen (siehe Kapitel 7.2).

6.2.2 Testing

Die Tool-orientierte Entwicklung von FHIR erlaubte HL7 gleichzeitig

auch den Einstieg in das Gebiet des Software-Testens, einer

Domäne, die vorher ebenfalls nur von IHE abgedeckt wurde.



HL7 und FHIR affine Organisationen etablierten Testing-Events, wie

z.B. die FHIR DevDays27 von einem kommerziellen Anbieter und den

FHIR Connectathon28 welcher von HL7 ausgerichtet wird. Beide

Events sind im Bereich der Entwicklung und Prototyp-Testing

angesiedelt, und dienen mehr dem gegenseitigen „teach, learn and

share“.

Die Einführung von Letzterem („FHIR Connectathon“) führte aufgrund

der Namensähnlichkeit zu einem IHE Connectathon, aber der völlig

unterschiedlichen Ausrichtung des Events, zu einiger Verwirrung im

Markt.

Für eine genaue Aufstellung der verschiedenen Testing-Events von

IHE und HL7, und deren jeweiligen Zweck und Zielgruppen, siehe

Kapitel 7.4, „IHE und HL7 Testing Events für FHIR“.

6.3 FHIR ermöglicht auch anderen Parteien das Profilieren

Durch die Einfachheit von FHIR und die barrierefreie Möglichkeit

FHIR Implementation Guides von jedermann zu erstellen, haben

auch andere Organisationen als HL7 begonnen FHIR IGs zu

publizieren.

Beispiele dafür sind in den USA die Projekte Argonaut29 und

DaVinci30, welche mit entsprechenden Mitteln ausgestattete

Industrie-Initiativen sind und eine dementsprechend große

Verbreitung erzielen. Sie decken verschiedenste Anwendungsfälle

ab, erheben aber nicht den Anspruch „global“ zu sein, sondern sind

auf den US Markt ausgerichtet. Dennoch sind diese Initiativen global

sichtbar, und dienen vielerorts als Vorlage für nationale

Spezifikationen. Die Folgen sind potenzielle „Nachbauten“ dieser

27 https://www.devdays.com 28 http://www.hl7.org/events/fhir-connectathon/index.cfm 29 http://argonautwiki.hl7.org/index.php?title=Main_Page 30 http://www.hl7.org/about/davinci

https://www.devdays.com/

http://www.hl7.org/events/fhir-connectathon/index.cfm

http://argonautwiki.hl7.org/index.php?title=Main_Page

http://www.hl7.org/about/davinci



Spezifikationen in anderen Ländern, ohne der entsprechenden

globalen Abstimmung.

Dass auch außerhalb der Standardisierungsorganisationen an

Interoperabilität gearbeitet wird, ist per se natürlich als positiv zu

erachten.

Allerdings ist dies, aus der Sicht des Anspruchs, durch

Harmonisierung auf globalem Level (wenn möglich) „einen“ allgemein

akzeptierten global Blueprint (IHE Profil / FHIR Implementation

Guide) pro Interoperabilitäts-Anwendungsfall zu haben, als

problematisch zu betrachten, sofern diese Initiativen völlig losgelöst

von der Standards-Community agieren.

HL7 wirkt dem entgegen in dem sie mit diesen Initiativen

zusammenarbeiten bzw. sie in die HL7 Community einbetten, um

damit die Voraussetzung für eine globale Harmonisierung zu

schaffen. Dennoch sind derartige Projekte (durch die Einfachheit von

FHIR) vielerorts im Vormarsch, und verändern (sofern nicht in die

Community eingebettet) die klassische Aufgabenverteilung, wie in

Kapitel 4.2 aufgezeigt, noch mehr.

Auch derartige Initiativen sollen mit dem „FHIR Community Process“

adressiert und kanalisiert werden (siehe Kapitel 7.3). Darauf

aufbauend sollten zukünftige, weitergehende Maßnahmen diese

Problematik noch umfassender einfangen (siehe Kapitel 7.5).

6.4 Missverständnis: „FHIR oder IHE“ (der Birnen/Äpfel - Vergleich)

Die Vielzahl der Änderungen durch FHIR, die große Akzeptanz am

Markt und der dadurch neu erschlossenen Gebiete der „Profilierung“

und des „Testings“ hat kurzzeitig dazu geführt, dass vielerorts bereits

von „FHIR oder IHE“ gesprochen wurde, welches hartnäckig ein

(nicht gegebenes) Konkurrenzverhältnis heraufbeschwört. Dabei ist

dieser Vergleich grundsätzlich gar nicht zulässig, da FHIR ein

Standard ist, IHE Profile hingegen eine Spezifikation zur „Anwendung

von Standards“ (auch von FHIR) für bestimmte Anwendungsfälle.



Die Problematik wird noch verschärft, da bei derartigen Aussagen alle

anderen existierenden Standards (DICOM, SNOMED, etc.)

unzulässigerweise gar nicht berücksichtigt werden.

Jedoch gibt es eine einfache Erklärung für dieses Missverständnis:

IHE wird oftmals mit „Dokumente-Austausch“ und FHIR mit „Daten-Austausch“ assoziiert. Das folgende Kapitel erklärt warum

dies so ist.

6.4.1 Grundsätzliches Missverständnis IHE=Dokumente, FHIR=Daten

Die mit Abstand erfolgreichste Gruppe der IHE Profile sind diejenigen

der XDS („Cross-Enterprise Document Sharing“) Familie aus der ITI

Domäne. Zahlreiche large-scale Implementierungen sind bereits

operativ und es gibt bereits einen großen kompetitiven Markt an

Produkte zu diesen Profilen. Selbst die cross-border Spezifikationen

rund um die Europäische eHealth Digital Service Infrastructure

(eHDSI) zum Austausch von Gesundheitsdaten zwischen EU

Mitgliedsstaaten (vormals epSOS) basieren auf dieser Profil-Familie.

Dieser an sich positive Umstand führte zu dem ungewollten

Nebeneffekt, dass von manchen die Organisation IHE und ihre

Arbeitsweise ausschließlich mit dessen erfolgreichster Profil-Familie

zu „Document Sharing“ assoziiert wird.

Obwohl das klassische „Document Sharing“ zwar als etabliert und

passend zu den gegebenen Prozessen in der Medizin gesehen wird,

entwickelt sich die Zukunft von eHealth in Richtung „Data Sharing“

weiter, mit welchem wiederum der Standard FHIR assoziiert wird.

Der dadurch aufkommende Eindruck IHE steht für „Document

Sharing“ (= old school) und FHIR für „Data Sharing“ (= modern) ist

wie vorhin schon dargelegt, kein zulässiger Vergleich, sondern

vielmehr ein Stimmungsbild, basierend größtenteils auf einem

Unverständnis darüber, was IHE und FHIR eigentlich sind.

IHE profiliert Anwendungsfälle, welche den Prinzipien des „Data

Sharings“ folgen schon seit der Zeit vor FHIR (Bsp: QED Profil -



Query Existing Data, etc.), und verfolgt dies nun mit dem FHIR

Standard selbstverständlich weiter (siehe Kapitel 5.2, „FHIR-basierte

IHE Profile“).

6.5 Fehlinformation und Verwirrung im Markt

All die in den Vorkapiteln genannten Entwicklungen führten zu einer

maßgeblichen Fehlinformation und Verwirrung im Markt, hinsichtlich

der Rollenverteilung der beiden Organisationen IHE und HL7 und wie

die zukünftige Standards-Entwicklung weitergehen wird.

Eine gewisse Polarisierung fand statt, zwischen den konträren

Standpunkten „IHE ist Vergangenheit, die Gegenwart gehört FHIR“

und „Die gegebenen, durch IHE Profilierten Standards wie CDA, etc.

sind bewährt und die Profilierung durch IHE muss weiterhin erfolgen.

FHIR muss seine Fähigkeit zu Interoperabilität zu führen erst

beweisen“.

Die Folge ist eine Unsicherheit im Markt, mit welchen Standards nun

ein Projekt umgesetzt werden soll bzw. ob die bestehenden und

bewährten Standards für gewisse Interoperabilitäts-Anwendungsfälle

noch verwendet werden können, oder man hier schon auf „veraltete

Technologie“ setzen würde.

Diese Fehlentwicklungen im Verständnis erreichte 2018 einen

Höhepunkt und wurden von beiden Organisationen IHE und HL7

gleichermaßen als Problem erkannt. Gemeinsam wurden

entsprechende Gegenmaßnahmen eingeleitet.



7 Lösungsansätze und Neuorientierung

Mit Beginn 2018 wurde die im vorigen Kapitel angesprochene

Problemstellungen und Kontroversen derart offenbar, dass sich beide

Organisationen zum Handeln aufgerufen fühlten.

7.1 Profilierung ist auch mit FHIR weiterhin notwendig!

Als erste Maxime wird von beiden Organisationen nun gemeinsam

ausgerufen, dass die Abstimmung und „Profilierung“ von Standards

für erfolgreiche, globale Interoperabilität auch im Falle von FHIR

erforderlich ist. IHE und HL7 werden diesbezüglich zukünftig

zusammenarbeiten, um den nun teilweise überlappenden Bereich

„FHIR Implementation Guide / FHIR-basiertes IHE Profil“ gemeinsam

abzustimmen, und den Weg vom „Standard zum getesteten,

interoperablen Produkt“ (siehe Kapitel 6.2.1, „Profilierung des

Standards für Anwendungsfälle“) wieder zu nahtlos zu schließen.

Als erste Maßnahme dazu wurde das Projekt „Gemini“ ins Leben

gerufen.



7.2 Projekt „Gemini“

Das Projekt „Gemini - A Joint Initiative of IHE and HL7 to Advance Use of FHIR for Interoperability“ ist eine gemeinsame

Initiative von HL7 und IHE zum Thema FHIR, um den in Kapitel 6,

„Problemstellungen und Herausforderungen“ angesprochenen

Herausforderungen entgegenzuwirken.

Die Initiative wird in gleicher Parität von beiden Organisationen, auf

Augenhöhe vorangetrieben, mittels eines „Joint Steering Committee“

bestehend aus jeweils 3 Personen aus IHE und HL7, welches die

verschiedenen bereits bestehenden Arbeitsgruppen zu FHIR in

beiden Organisationen in der Zusammenarbeit unterstützt.

Ziel ist es, in folgenden Bereichen Zusammenarbeit und Synergien

zu schaffen:

• Area 1: Development and Tooling of „FHIR-based IHE Profiles“

o FHIR-based IHE profiles remain under IHE

governance, but participation and contribution of HL7

shall be encouraged (as well as participation of IHE in

HL7)

o This includes collaborative work, alignment of tooling,

mutual notification of new work-items, etc.

• Area 2: Publication of „FHIR-based IHE Profiles“ o Align publication of FHIR Implementation Guides and

FHIR-based IHE profiles by referencing FHIR-based

IHE profiles on fhir.org

• Area 3: Testing o Positioning of the current testing initiatives, such as

HL7 FHIR Connectathons, IHE Connectathons, IHE

Conformity Assessment and coordination of the test

tooling ecosystem across both organizations

• Area 4: Pilot projects o Identify, agree and execute joint IHE/HL7 pilot projects

and demonstrations



• Area 5: Joint Messaging and Marketing o Maintain joint messaging/marketing/education on HL7

FHIR and FHIR-based IHE profiles on fhir.org

Die Gemini Initiative ist eine wesentliche neue

Kommunikationsschiene zwischen beiden Organisationen und es

existiert ein reger und regelmäßiger Austausch auf dieser Ebene.

Speziell in „Area 4“ wurden bereits folgende beiden Projekte als

„Gemini-Projekte“ akzeptiert:

• Medical Imaging for Cancer Care

o Seek to make incremental progress over the course of

IHE and HL7 Connectathons to develop an

interoperability solution built on FHIR and profiles

o HL7 work groups Health Care Devices, Image

Integration and CIMI, IHE Patient Care Coordination

• Computable care guidelines (CCG) o Develop CCG profile for workflow, content, actions

o WHO, CDC, HHSC, IHE, FHIR collaboration

o IHE Quality, Research and Public Health, HL7 working

groups

o See the following explanation videos:

CCG in 200 seconds:

https://vimeo.com/347427025

CCG QRPH profile in 300 seconds:


o Projekt wiki:

https://wiki.ihe.net/index.php/Computable_Care_Guid

elines



https://wiki.ihe.net/index.php/Computable_Care_Guidelines

https://wiki.ihe.net/index.php/Computable_Care_Guidelines



7.3 FHIR Community Process (noch in Entwicklung)

Um der in Kapitel 6.1, „FHIR erleichtert Herstellern proprietäre

Lösungen“ angesprochenen Problematik entgegenzuwirken, ist HL7

derzeit dabei den „FHIR Community Process“31 ins Leben zu rufen.

Die Rahmenbedingungen und Governance dieser Community

werden gerade ausgearbeitet und beinhaltet nach derzeitigem Stand

ein flaches Mitgliederkonzept, dem auch IHE plant beizutreten.

Der FHIR Community Process soll alle Entwicklungen mit FHIR in

eine gewisse Governance-Schiene leiten, damit die Nachteile des

völlig freien Entwickelns minimiert werden können

(Doppelgleisigkeiten, etc.).

7.4 IHE und HL7 Testing Events für FHIR

IHE und HL7 bieten gleichermaßen Testing Events für FHIR an,

welche sich jedoch in angesprochener Zielgruppe und Zweck stark

unterscheiden.

Während die Testing Events von HL7 eher auf den Bereich „Teach,

Learn, Share, Development“ abzielen, um die einerseits die

Community zusammenzubringen und andererseits Feedback zum

FHIR Standard zu erhalten, zielen die Testing Events von IHE auf

den Aspekt der „Marktreife von Produkten“ ab.

Die Reife der zu testenden Anwendung bzw. Prototyps und der

angepeilte Nutzen hinsichtlich der Qualifikation der entsandten

Personen des Programmierteams bestimmt also welcher der

angebotenen Testing Events der passende ist.

Die Matrix für die von IHE und HL7 angebotenen wichtigsten Testing-

Events, hinsichtlich ihres Zwecks und der angepeilten

Besuchergruppe ist wie folgt:

31 http://wiki.hl7.org/index.php?title=FHIR_Community_Process

http://wiki.hl7.org/index.php?title=FHIR_Community_Process



Teach, Learn, Share, Development

Prototype / Product

Final Product for Market

FHIR

DevDays

HL7 FHIR

Connectathon

IHE

Connectathon

IHE Conformity

Assessment

Product Maturity

7.5 Zukünftige Positionierung von IHE, HL7 und weiterführende Kollaborationen

Aufbauend auf Gemini wird derzeit bereits über weiterführende

Kollaborationen gesprochen.

Die derzeit im Gespräch befindliche Zusammenarbeit wäre auf einer

noch höheren strategischen Ebene, zusammen mit zusätzlichen

Partnern, um weitere Synergien zu schaffen.

Der Bedarf an globalen, vendor-neutralen, offenen und freien

Interoperabilitäts-Standards ist äußerst groß. Nationale eHealth

Projekte, bis hin zu cross-border Initiativen (siehe die eHealth Digital

Service Infrastructure (eHDSI) der Europäischen Union oder Trillium

Bridge) starten allerorts und globale Government-Initiativen (wie zB

die GDHP, „Global Digital Health Partnership“32) versuchen die

eHealth Herausforderungen zunehmend gemeinsam zu lösen.

Die Standardisierungsorganisationen müssen durch mehr

Kollaboration dieser Entwicklung Rechnung tragen. Die Idee dabei

wäre, die 3 Stufen des Standardisierungsprozesses (siehe Kapitel

3.1), in Kooperation mit diesen Stakeholdern, also den „Anforderern“

und späteren „Abnehmern“ der Standards auszurichten.

32 Global Digital Health Partnership (GDHP): www.gdhp.org

http://www.gdhp.org/



Siehe dazu den Artikel des Autors: „The 4 aspects that change the

game in eHealth Interoperability“33:

Die dazu laufenden Gespräche sind noch nicht öffentlich. Es ist aber

anzunehmen, dass Maßnahmen noch in diesem Jahr erwartet

werden können.

33 Artikel “The 4 aspects that change the game in eHealth Interoperability”:

https://www.linkedin.com/pulse/4-aspects-change-game-ehealth-interoperability-

j%C3%BCrgen-brandst%C3%A4tter

https://www.linkedin.com/pulse/4-aspects-change-game-ehealth-interoperability-j%C3%BCrgen-brandst%C3%A4tter






8 Referenzen IHE

• IHE International: https://www.ihe.net

• IHE Europe: https://www.ihe-europe.net

• Technical Frameworks und IHE Profile:

https://www.ihe.net/Technical_Framework

• IHE Profile: https://wiki.ihe.net/index.php/Profiles

• FHIR-Basierte IHE Profile, publiziert als FHIR

Implementation Guides auf fhir.org:

http://www.fhir.org/guides/registry/

• Wikipedia IHE:

https://de.wikipedia.org/wiki/Integrating_the_Healthcare_Ent

erprise

• IHE Services: https://www.ihe-europe.net/deployment/IHE-

Services

HL7

• HL7 International: https://www.hl7.org

• Wikipedia HL7: https://de.wikipedia.org/wiki/HL7

• Wikipedia FHIR:

https://de.wikipedia.org/wiki/Fast_Healthcare_Interoperability

_Resources

• Siehe FHIR IG Übersicht auf fhir.org:


• FHIR Community:


Andere

• The 3 Legs of the Health Informatics Standards Process:


https://www.ihe.net/

https://www.ihe-europe.net/

https://www.ihe.net/Technical_Framework

https://wiki.ihe.net/index.php/Profiles

http://www.fhir.org/guides/registry/

https://de.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise

https://de.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise



https://www.hl7.org/

https://de.wikipedia.org/wiki/HL7

https://de.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources

https://de.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources






• The 4 aspects that change the game in eHealth

Interoperability: https://www.linkedin.com/pulse/4-aspects-

change-game-ehealth-interoperability-j%C3%BCrgen-

brandst%C3%A4tter

• European Commission recognizes 27 IHE profiles that

should be referenced in public procurement documents:

http://eur-lex.europa.eu/legal-

content/EN/TXT/?uri=OJ:JOL_2015_199_R_0011

• GDHP, Global Digital Health Partnership:

https://www.gdhp.org






https://www.gdhp.org/

Auslegeordnung IHE / HL7 / FHIR...eHealth Suisse – Auslegeordnung IHE / HL7 / FHIR Auslegeordnung IHE_HL7_FHIR v1.2.docx Seite 3 von 43 6.3 FHIR ermöglicht auch anderen Parteien

Documents