Dieser Post ist Teil der Serie “Medizinische Datenformate”. Wie immer gilt: Kommentare, Korrekturen, Ergänzungen willkommen.
Es ist hilfreich vorher HL7 v2 und HL7 v3 gelesen zu haben.
Legen wir los.
Was ist FHIR?
HL7 FHIR schickt sich an einer der wichtigsten Standards im Gesundheitswesen zu werden. Er bricht mit so ziemlich allen bisher verwendeten Prinzipien und ist angetreten nach und nach alle bisherigen (HL7-)Standards abzulösen. Hier die Kernpunkte:
- HL7 FHIR - “Fast Healthcare Interoperability Resources”
- Aktuelle Version (Stand 2022-01-06): 4.0.1
- Entwicklung begann 2011, Erstveröffentlichung Februar 2014 als “Draft for trial use”
- Kann alle Bereiche von HL7 v2, HL7 v3 und CDA abdecken (Messaging & Dokumente)
- Definiert darüber hinaus auch erstmals APIs und IT Prozesse (REST, Authentifikation, Verschlüsselung, etc.)
- Basiert auf Web Technologien (XML und JSON, RESTful services)
- Basiert nicht auf dem HL7 RIM
- Vollständige Neuentwicklung
Ganz praktisch ist FHIR angetreten, sowohl HL7 v2 als auch das Paket HL7 v3 abzulösen, und stellt inhaltlich sowie “philosophisch” eine vollständige Neuentwicklung dar. Der Impuls zur Entwicklung von FHIR geht auf den Australier Grahame Grieve zurück, der die Herangehensweise an FHIR maßgeblich geprägt hat (zwei sehr interessante Interviews dazu auf YouTube).
Designprinzipien und Motivation von FHIR
HL7.de listet die wesentlichen Punkte sehr prägnant.
- Zu den “treibenden Faktoren” von FHIR schreibt es:
- Paradigmenwechsel im Gesundheitswesen
- Online statt offline
- Mehr Transparenz
- Mehr Analysen
- Und zu den Designprinzipien:
- Fokus auf Implementierer
- Fokus auf weitverbreitete Use Cases
- Fokus auf erprobte Web-Technologien
- Fokus auf menschenlesbare Information
- Fokus auf freie Verfügbarkeit
- Unterstützung multipler Paradigmen und Architekturen
Ein Ergebnis des “Fokus auf weitverbreitete Use Cases” möchte ich hervorheben: FHIR wurde auf Basis der 80/20 Regel entworfen (HL7.de und HL7.org):
Attribute wurden bei der Spezifikation nur dann in diesen Teil der Resource übernommen, wenn davon ausgegangen werden konnte, dass mindestens 80% aller Implementierungen, die diese Resource verwenden, es auch benutzen
FHIR möchte also nicht allumfassend sein, darauf gehe ich in einem weiteren Post noch einmal ein.
Designierte Einsatzgebiete von FHIR
In dieser Konsequenz werden die folgenden erweiterten Nutzungsmöglichkeiten für FHIR spezifiziert (Quellen: Youtube und Healthcare IT News):
- in Nachrichten (Scope von HL7 v2, HL7 v3)
- FHIR-codierte Dokumente (Scope von CDA)
- in REST URLs (das Arbeiten mit FHIR Ressourcen, neu)
- in Services (zB Clinical Decision Support, neu)
Das führt zB dazu, dass FHIR erstmals auch nicht-medizinische Elemente wie Authentifizierung, Schnittstellen und Übertragungsprotokolle definiert und sich dabei der heutzutage gängigen Web Standards bedient (OAuth, REST, JSON). FHIR geht dabei also noch einmal deutlich über den Scope der bisherigen HL7 Standards hinaus.
FHIR Dokumente & Objekte
Während HL7 v2 & die Standards aus v3 entweder Nachrichten oder Dokumente definieren, basiert FHIR auf “Objekten” bzw. “Ressourcen” als kleinstem Baustein (zB “Allergy”, “Patient”, “Medication”, div. Vitalparameter, etc.).
Diese Ressourcen bilden dadurch die Basis für sowohl Dokumente als auch Nachrichten.
Erwähnenswert:
Durch die Bereitstellung von (REST) APIs können diese Objekte (Patient, Vitalparameter, etc.) jetzt auch als einzelne Informationseinheit direkt verwaltet werden.
Die Basisobjekte werden von HL7.org entwickelt und veröffentlicht, und von den jeweiligen nationalen HL7 Ablegern in nationale Profile überführt. Die deutschen Profile werden auf der Seite “simplifier.net” beschrieben. (Mehr zu Profilen später).
Erfreulich ist dass ab jetzt zumindest theoretisch alle Informationen strukturiert vorliegen: In FHIR ist der strukturierte Teil verpflichtend und der narrative Teil optional, genau umgekehrt zu CDA.
Die Codierung der Informationen erfolgt entweder in XML oder in JSON. Die Konversion ist trivial (da regelbasiert), ein Beispiel-Konverter incl. Beispiel-Patient ist online verfügbar, mit Quellen auf GitHub.
Interoperabiliät mit FHIR: Profile & Extensions
Verglichen mit den bisherigen Standards sind wir in einem entscheidenden Punkt wesentlich weiter: Wir haben definierte APIs (REST-basierte Verwaltung von FHIR-Objekten), incl. notwendiger Ergänzungen für zB Autorisierungsverfahren, etc.
Leider haben wir ebenfalls immer noch das gleiche Problem das in HL7 v3 CDA durch Templates gelöst wird - sehr schön formuliert in einem sehr lesenswerten Beitrag über FHIR Profile des Johner-Instituts:
[…] Daher ist die Spezifikation nicht spezifisch für einzelne Länder. Sie ist auch weder ausreichend spezifisch für viele Anwendungsfälle noch ausreichend konkret für eine Implementierung. Beispielsweise existiert auf der globalen Ebene keine Pflegestufe, wie wir sie (nur) in Deutschland kennen.
HL7 selbst weiß das auch und löst dies in FHIR mit Hilfe von Profilen und Extensions. Profile können die in FHIR definierten Ressourcen einschränken und erweitern, und zwar durch (ebenfalls übernommen von Johner) …
- Einschränkung der Kardinalität (Attribute spezifizieren als: verboten, verpflichtend, Festlegung der Anzahl …)
- Erweiterung durch Extensions (kommt gleich)
- Festlegung von Werten (Kodiersysteme)
Extensions sind was man sich darunter vorstellen würde, eine kontrollierte und formalisierte Erweiterung eines FHIR-Objekts, entweder strukturell (neue Felder) oder inhaltlich (neue Feldwerte). Ein Beispiel ist das Coding-Profil der deutschen ICD-10 Erweiterungen.
Wie bereits erwähnt entwickelt HL7 Deutschland die deutschen Basisprofile und veröffentlicht diese auf simplifier.net, zusammen mit dem deutschen Implementierungsleitfaden, der noch einmal gezielt auf die nationalen Erweiterungen eingeht.
Eine weitere thematische Unterteilung der Basisprofile ist vermutlich notwendig, denn zB für eine Abrechnungs-Applikation wird die Unterstützung von Blutdruckwerten eher nicht notwendig sein. Daher werden sich vermutlich verschiedene in Deutschland genutzte Profile (ggf. sogar herstellerspezifisch) herausbilden, die dann Applikationen auf fachlicher Ebene miteinander verbinden können.
Unterschiede zu HL7 v2 & den Standards aus v3
Drastisch viele, HL7.org hat auch ordentlich viel dazu geschrieben. Ein persönliches “TL;DR” könnte folgendermaßen aussehen.
Den Hauptunterschied von “FHIR vs. HL7 v3” kann man nicht am Fokus der Standards festmachen, sondern an der dahinterstehenden Absicht bzw. Philosophie. Die unterschiedlichen Fokusmengen ergeben sich ausschließlich daraus. Formulieren würde ich das als “einen radikalen Schwenk von einem top-down-Design abstrakter Modelle (auf Basis abstrakter Informationsstrukturen) zu einer pragmatischen, auf Implementierung fokussierten Vorgehensweise”. Ich möchte hier noch einmal auf den Vortrag von Graham Grieve verweisen, in dem er (ab ca. 4:40) genau über das Herantasten an einen “Agilen Standard” spricht. (Was genau denn bitte ein “agiler Standard” sein soll ist nämlich aus der Perspektive einer Industrienorm eine sehr berechtigte Frage).
Inhaltlich kann man mit beiden (FHIR & allem aus HL7 v3) “sämtliche” (jaja, 80%, ich weiß) medizinischen Prozesse und Dokumente abbilden. Was FHIR allerdings erreichen will ist, dass man es endlich auch tut, und nicht nur ein ungenutztes Werkzeug dafür zur Verfügung hat. Den Implementierungsstand der HL7v3-Suite konnte man beim besten Willen nicht als “hoch” bezeichnen.
Die Leuchttürme dieser Haltung sind sicherlich die Loslösung vom RIM als Information Model (“It is possible to implement FHIR with absolutely no knowledge of the HL7 RIM”) und der damit verringerten Komplexität, zusammen mit der Aufnahme von Schnittstellen- und (IT-)Prozessdefinitionen.
Konkrete Beispiele
Beispiel 1 - wir möchten die Stammdaten eines Patienten ändern. Mit HL7 v2 würde man eine ADT-Nachricht schicken. Was passiert wenn die ignoriert wird ist erst einmal nicht intuitiv. Mit HL7 v3 kommt man gar nicht ans Ziel, denn ich könnte ganz platt keine aktive Implementierung in einem KIS nennen. Mit FHIR schickt man einen synchronen Request ans Zielsystem. Der liefert “Erfolg” oder “Fehler” direkt zurück.
Beispiel 2 - wir möchten in einem Prozess Informationen abfragen. Mit HL7 v2 geht das - in Deutschland - nicht. Jedenfalls nicht nach dem definierten Standard in Version 2.5. Die Lösung ist: Jedes System baut eigenen lokalen Spiegel der Informationen auf (indem es an einen HL7 v2 Datenstrom angeschlossen wird, der immer die aktuellsten Änderungen liefert), um dann bei Bedarf diese zu nutzen. Mit HL7 v3 mag das theoretisch gehen, nur eben praktisch nicht, hier gilt dasselbe wie bei Beispiel 1. Mit FHIR fragt man das führende System an und bekommt seine Daten.
Beispiel 3 - wir möchten ein Dokument digital abbilden. Mit HL7 v2 - Pech gehabt, Dokumente werden nicht definiert, nur Nachrichten. Mit HL7 v3 CDA ohne Weiteres möglich. Allerdings muss man sich über sämtliche Objekte Gedanken machen und diese spezifzieren (in Form besagter Templates). Keine zwei Templates die parallel (ohne Wissen voneinander) entwickelt werden dürften einen “Patienten” auf dieselbe (oder auch nur ähnliche) Art kodieren. Mit HL7 FHIR ohne Weiteres möglich. Hier sind die Objekte weitestgehend vordefiniert, man muss also “nur” Anpassungen machen an den Stellen, die der Standard in seiner “Reinform” nicht berücksichtigt hat, bzw. notwendige Beschränkungen einführen.
Akzeptanz von FHIR
FHIR wird allen Anzeichen nach der bestimmende Standard der nächsten Jahre. Einerseits findet FHIR mehr und mehr Einzug in die regulatorischen Anforderungen. In Deutschland zB hat die Gematik FHIR als Basis für ihren ISiK-Standard und zB das eRezept auserkoren (dass dies gerade wieder gescheitert ist kann man allerdings eher nicht FHIR anlasten). Neue(re) IHE Profile (mehr zu IHE in einem späteren Post) bauen ebenfalls auf FHIR.
Andererseits locken Web-Standards und ein Fokus auf Implementierbarkeit die Implementierer, so dass um FHIR herum bereits jetzt ein relativ großes Software-Ökosystem existiert, und auch Datenbankhersteller sowie Cloud Anbieter (Google, AWS, Azure) erweitern ihre Produkte um FHIR Funktionen.
Für mich persönlich ist ein passender Schluss der Verweis auf den HL7 Blog, in dem Graham Grieve selbst Anfang 2019 davon ausging, FHIR R5 in Q3 2020 zu publizieren. Man entschloss sich dann aufgrund des Feedbacks dazu, dies “auf unbestimmte Zeit zu verschieben”. Warum finde ich das gut? Weil FHIR dadurch in der Realität angekommen ist. Es gibt Feedback, man ist im Kontakt, und man entwickelt den Standard nicht an den Nutzern vorbei.