Episode #4 – FHIR

Kurze Frage. Jetzt hast du HL7 und DICOM gesagt. Aber der wichtigste Kommunikationsstandard ist doch IHE, oder?

Ja, kann man so sagen. Nein. IHE ist kein Kommunikationsstandard. Vielleicht hören ja einige von deinen Studies zu, die das Beispiel gebracht haben mit dem IHE-Salat. Also wenn man IHE als Salat bezeichnen würde, dann wären HL7 und DICOM das Gemüse in dem Salat. Also IHE verwendet DICOM und HL7.

Gut. Was ist das Ziel von FHIR?

Also das Ziel, erst mal der Name: Der kommt von Fast Healthcare Interoperability Resources und ist von HL7 International entworfen worden. Die Ziele sind eben eine bessere Vernetzung in einem sich wandelnden Gesundheitssystem. Auch der Patient soll Möglichkeiten haben, auf seine Daten zuzugreifen und unter den aktuellen Schnittstellen ist es etwas schwierig.

Um FHIR zu verstehen, muss man zumindest so ein paar Basics wissen über Web Services. Also wenn man früher über Web Services geredet hat, dann hat man immer gleich SOAP in Erinnerung und SOAP ist ja etwas schlechter in Erinnerung, weil es relativ kompliziert und mit großem Overhead ist. In den letzten Jahren steht in direkter Konkurrenz zu dem SOAP-Ansatz der REST-Ansatz.

Hier haben wir im Gegensatz zu dem prozedurbasierten Ansatz den objektzentrierten Ansatz. Also hier stehen die Substantive mehr im Vordergrund als die Verben. Das macht das Ganze wesentlich einfacher. Das ist auch ein Vorteil gegenüber dem SOAP-System. Also es wird alles sehr viel einfacher und das befördert natürlich auch die Entwickler, die jetzt mit weniger Aufwand, weniger Gedanken machen und schneller programmieren können.

Ja, wenn wir jetzt die Web Services hinter uns lassen und mal schauen, was es bei FHIR noch gibt, dann fällt eben dieses Datenmodell auf. Das Datenmodell, das sonst immer eher auf einer Metaebene beschrieben wurde, wird jetzt konkretisiert.

Wir haben richtige Bausteine, die definiert sind. Einer der Bausteine heißt Ressource. Das könnte jetzt zum Beispiel ein Patient, eine Untersuchung, eine OP oder ein Medikament sein und so weiter.

Diese sind ähnlich beschrieben wie in einem CDA-Dokument. Also auch hier gibt es strukturierte Daten, es gibt narrative Daten und falls diese strukturierten Daten, die von FHIR definiert sind, nicht reichen, dann gibt es auch noch die Möglichkeit, dass sich Kooperationspartner eigene Extensions definieren.

Hier ist auch noch so ein Konzept, das sich die Leute von FHIR ausgedacht haben. Sie wollen jetzt nicht diese Welt, die sie beschreiben, bis ins kleinste Detail beschreiben, sondern sie wollen das Pareto-Prinzip anwenden. Sie haben sich gesagt: 80 Prozent der Sachen wollen wir abdecken, 80 Prozent der Workflows und der Implementierungen wollen wir abdecken und die anderen 20 Prozent sollen, wenn sie von den Leuten implementiert werden, eher in Extensions definiert werden.

Das hat den Vorteil, dass man nicht diesen großen Overhead in dieses überbordende Konzept und diese überbordenden Modelle bekommt.

Was ich noch spannend finde bei FHIR ist, dass es meiner Meinung nach die besten Ansätze von HL7 v2 und v3 herausgepickt hat.

Also HL7 v2 ist ja ein bisschen hemdsärmelig. Nach dem Motto: Wir brauchen hier noch in irgendeinem Feld die Schuhgröße, dann schreiben wir das in das siebte Segment mit rein. Dadurch wirkt es eben auch so, dass quasi jede Schnittstelle zwischen zwei Systemen relativ individuell ist und man gar nicht so richtige Standards hat.

HL7 v3 wiederum ist in Deutschland eigentlich kaum verbreitet und hat sehr viel Overhead, ist sehr wissenschaftlich aufbereitet, aber nichts, was man mal eben schnell machen kann.

Und genau in diese Lücke stößt eigentlich FHIR rein. Also was du gerade sehr schön gesagt hast: Dass man eben den Großteil der Daten, die tatsächlich nachher im Krankenhaus kommuniziert werden, schön standardisiert, aber auch nicht verkopft kommunizieren kann über FHIR. Und wenn man dann in dem Beispiel gerade eben doch noch mal die Schuhgröße braucht und die eben nicht in diesen 80 Prozent drin ist, dann definiert man sie wieder in einer eigenen Extension.

Gut. Viele denken sich jetzt: Nach HL7, DICOM und CDA, warum jetzt noch ein neuer Standard?

Das ist auch, sagen wir mal, ein berechtigter Einwand. Aber das Ziel ist es, diese Standards auch zusammenzuführen. Also insbesondere da die relativ in die ähnliche Richtung gehen, dass langfristig CDA und FHIR zusammengeführt werden und ein einheitlicher Standard wird.

Gut, jetzt hast du ja im letzten Podcast etwas zur Sicherheit erzählt. Wie schaut es mit Sicherheit bei FHIR aus? Kann da einfach jeder die Web Services ansprechen?

Nein. Also FHIR setzt da auf einen allgemeinen Standard: OAuth. OAuth gibt es mittlerweile in der zweiten Version und da wird so eine Art Token für die Fremdsysteme generiert, der dann von den Hauptsystemen ausgewertet wird.

Ist also auch wieder ein Standard, der dann im FHIR-Standard benutzt wird.

Genau. Der ist zwar nicht ganz REST-konform, da werden einige REST-Liebhaber intervenieren, aber es ist ein sehr brauchbarer und weit verbreiteter Standard.

Dann vielleicht noch eine Anmerkung: Es gibt ein spannendes Video von der HIMSS, ich glaube auch von Cerner. Und zwar zeigen die dort im Millennium, wie sie eben mit FHIR Drittanbietern, also kleinen App-Entwicklern, ermöglichen, Apps für ihr KIS Millennium zu entwickeln.

Die treten dort ein bisschen wie der Google Play Store oder der Apple App Store auf. Die bieten Services an und da können dann andere Drittanbieter Apps dafür bauen. Cerner verdient ein bisschen mit und die Kunden sind zufrieden, weil sie für ihre ganz speziellen Lösungen einzelne kleine Apps bekommen.

Ich glaube, in die Richtung geht es. Dass man vielleicht nachher als KIS-Anbieter gar nicht mehr alles selbst machen muss, sondern einfach Sachen bereitstellt und dann vielleicht mitpartizipiert, wenn andere Hersteller oder Entwickler die eigenen Services nutzen.

HL7, IHE, FHIR(Fast Healthcare Interoperability Resources), REST, Datenmodell, Datensicherheit