FHIR: In drei Schritten zum eigenen Profil

FHIR ist inzwischen der Standard für den Datenaustausch im Gesundheitswesen. Moderne klinische Informationssysteme, viele Medizinprodukte und selbst Health-Apps kommen an FHIR nicht vorbei.

FHIR steht für „Fast Healthcare Interoperability Resources“ und wird wie das englische „fire“ ausgesprochen.

Dieser von HL7 ins Leben gerufene Standard soll alle „Use Cases“ abdecken: vom Abfragen von Versicherungsstammdaten über den intersektoralen Datenaustausch bis zur Integration von Messgeräten.

Lesen Sie hier, wann und in welcher Tiefe FHIR für Sie relevant ist.

1. Was Sie über FHIR wissen sollten …

a) … als Führungskraft

… eines Herstellers

FHIR standardisiert die Kommunikation im Gesundheitswesen zwischen z. B. Medizinprodukten und IT-Systemen wie Apps und Krankenhausinformationssystemen.

Wenn Ihre Produkte FHIR nicht unterstützen, steigt die Gefahr, dass Ihre Kunden Ihre Produkte nicht mehr erwerben. Das kann darin liegen, dass

• die Interoperabilitätsverordnung in § 7 Gesundheitseinrichtungen dazu zwingt, Systeme einzusetzen, die die Anforderungen an die Interoperabilität erfüllen und
• die Aufwände für die Integration Ihrer Produkte in die Systemen der Gesundheitseinrichtungen unangemessen steigen.

… eines Krankenhauses

FHIR standardisiert nicht nur die Kommunikation zwischen z. B. den Medizinprodukten und IT-Systemen innerhalb Ihrer Organisation, sondern auch mit Dritten wie anderen Gesundheitsdienstleistern (z. B. niedergelassenen Ärzten), Behörden und Kassen.

Nach Möglichkeit und wo angemessen sollten Sie nur IT-Systeme und Medizinprodukte einkaufen, die die Interoperabilitätsstandards unterstützen, die das Expertengremium des Bundesgesundheitsministeriums empfiehlt. FHIR und die darauf basierenden Profile zählen dazu.

Die Interoperabilitätsverordnung (der offizielle Name lautet „IOP Governance-Verordnung“ oder kurz GIGV) verpflichtet sie dazu.

Außerdem wird es Ihnen ohne eine durchgängige Interoperabilität Ihrer Systeme nicht gelingen, Ihre Prozesse effizient und leistungsfähig zu gestalten.

b) … als Software-Entwickler:in

Mit FHIR gibt es endlich einen Interoperabilitätsstandard für das Gesundheitswesen, bei dem Sie Ihr Wissen aus dem Studium und anderen Branchen nutzen können; denn FHIR basiert auf Standards wie REST und damit auf http(s), XML, JSON, OAUTH und dem ressourcenorientierten Architekturparadigma.

Das heißt: Sie können Ihre üblichen Tools (IDEs, Testframeworks etc.) weiterhin nutzen. Zusätzlich müssen Sie sich in die Spezifika wie die semantischen Standards und die FHIR-Profile einarbeiten.

Lesen Sie dazu unten weiter mehr und nutzen Sie die dort verlinkten Ressourcen.

c) … als Qualitätsmanager:in und Regulatory Affairs Manager:in

FHIR ist ein Interoperabilitätsstandard, mit dessen Hilfe Medizinprodukte mit Nachbarsystemen kommunizieren können. Daher dient FHIR dazu, die externen Schnittstellen der Medizinprodukte zu spezifizieren.

Diese Spezifikation muss Teil der Product Requirements Specification (PRS) oder Software Requirements Specification (SRS) sein. Die Produkt- bzw. Software-Systemtests müssen überprüfen, ob diese Produkt- bzw. Software-Anforderungen erfüllt sind.

Die Schnittstellenspezifikation muss nicht zwingend in der PRS bzw. SRS enthalten sein. Es genügen Verweise. Aber die bloße Forderung, dass die Schnittstelle den FHIR-Standard unterstützen muss, reicht nicht aus. Vielmehr muss die PRS/SRS die Schnittstelle vollständig spezifizieren, z. B. durch Festlegung der verwendeten Profile bzw. der dabei verwendeten semantischen Interoperabilitätsstandards.

Der Umstieg von einer nicht-FHIR-basierten auf eine FHIR-basierte Schnittstelle stellt eine wesentliche Änderung dar.

2. Wo FHIR zur Anwendung kommt

a) Zum Austausch von Nachrichten und Dokumenten …

FHIR dient dem Informationsaustausch von Systemen im Gesundheitswesen (Medizinprodukte, Apps, IT-Systeme). FHIR unterstützt sowohl den Austausch von Nachrichten als auch den von Dokumenten.

• Nachrichten sind i. d. R. kurz, werden nicht gespeichert und liefern keinen vollständigen Kontext. Ein Beispiel ist die Nachricht eines Laborinformationssystems an den klinischen Arbeitsplatz, dass ein neuer Laborwert vorhanden ist.
• Dokumente liefen einen umfassenderen Kontext: z. B. welche Institution das Dokument erstellt hat, welchen Patienten es betrifft sowie Daten aus verschiedenen „Töpfen“ wie Diagnosen, Laborwerte und Medikationspläne. Beispiele für Dokumente sind Arzt- und Entlassbriefe.
• Informationseinheiten sind z.B. Vitalparameter und Medikationsdaten. Sie entsprechen „Ressourcen“ auch im Sinne einer REST-Architektur.

Diese Informationen betreffen u. a.

• die Patient:innen inklusive Stammdaten und Anamnesen,
• deren Befunde (z. B. Laborwerte, Vitalparameter) und Diagnosen,
• deren Behandlung (z. B. Medikationen und Operationen),
• den Workflow für diese Befundungen und Behandlungen (z. B. die Leistungsanforderungen, Terminvereinbarungen und Überweisungen) sowie
• die Abrechnung all dieser Leistungen.

b) … innerhalb von Organisationen

Noch dominiert HL7 Version 2 den Informationsaustausch innerhalb der Klinken. Doch HL7 FHIR ist angetreten, die nachrichtenorientierte Version 2 abzulösen bzw. zu ergänzen.

Endpunkte dieser Kommunikation sind bzw. werden sein:

• Klinische Informationssysteme, z. B.:
  • KIS (Krankenhausinformationssystem)
  • KAS (Klinische Arbeitsplatzsysteme)
  • RIS (Radiologische Informationssysteme)
  • LIMS (Laborinformations-Managementsysteme)
  • PDMS (Patientendaten-Managementsysteme)
  • PVS (Praxisverwaltungssyteme)
  • AIS (Arztinformationssyteme)
• Medizinprodukte, z. B.:
  • einige der o. g. klinischen Informationssysteme
  • Systeme für die radiologische Bildgebung
• Administrative Systeme, z. B.
  • Systeme für die Leistungserfassung und Leistungsabrechnung
  • Systeme für die Statistik und das (medizinische) Controlling
• Sonstige Systeme

Die Kommunikation innerhalb einer Organisation beschränkt sich nicht auf die physischen Mauern einer Organisation. FHIR standardisiert auch den Informationsaustausch über verschiedene Standorte einer Organisation hinweg sowie für Ärztinnen und Ärzte, die remote arbeiten.

c) … zwischen Organisationen und mit Patient:innen

FHIR soll und wird den sektorenübergreifenden Austausch von Informationen fördern und dabei auch die Patientinnen und Patienten als direkt Betroffene mit einbinden.

• Krankenhäuser müssen besser mit Arztpraxen und medizinischen Versorgungszentren kommunizieren.
• Rezepte werden digital an die Apotheken übermittelt und können von den Patienten eingesehen werden.
• Patienten greifen über Ihre Apps auf ihre elektronische Gesundheitsakte zu und ergänzen diese um Vitaldaten von z. B. SmartWatches.
• Auch die Patientenportale dienen der Kommunikation über die Sektorengrenzen hinweg.
• Alle Beteiligten können auf die Telematikinfrastruktur und deren Dienste zugreifen.
• Die Forschung kann institutionsübergreifend auch Versorgungsdaten sammeln.
• Die Leistungsträger (Kassen) und Leistungserbringer (z. B. Krankenhäuser, Praxen, Physiotherapeuten) tauschen die notwendigen Daten aus.

3. Was FHIR standardisiert

Als Interoperabilitätsstandard kann FHIR mehrere Interoperabilitätsebenen standardisieren:

1. Strukturelle Interoperabilität (z. B. Übertragungsprotokolle)
2. Syntaktische Interoperabilität (z. B. Formate wie XML und JSON)
3. Semantische Interoperabilität (z. B. Kodiersysteme und Taxonomien wie ICD-10)
4. Organisatorische Interoperabilität (z. B. Workflows und Benutzerberechtigungen)

In der Praxis zeigt sich, dass FHIR bei der Standardisierung der ersten drei Ebenen hilfreich ist. Auf der organisatorischen Ebene fehlen noch Konzepte wie systemübergreifende Definitionen von Rollen und Workflows.

a) Ressourcen (Semantische Ebene)

FHIR standardisiert die sogenannten Ressourcen. Beispiele für Ressourcen sind:

• Patient:innen
• Medikationsverschreibungen
• Beobachtungen („Observations“) wie Laborwerte und Vitalparameter (z. B. Blutdruck)
• Organisationen (z. B. niedergelassene Ärzt:innen) 

Für jede Ressource legt FHIR fest, über welche Attribute sie verfügen kann oder gar muss. FHIR spricht hier von „elements“. Beispielsweise verfügt ein Patient (s. Abb. 3) über

• keinen, einen oder mehrere Namen,
• keine, eine oder mehrere Telefonnummern,
• kein oder genau ein Geschlecht,
• kein oder genau ein Geburtsdatum,
• keinen, einen oder viele Kontakte, wobei jeder Kontakt über die Art der Beziehung, einen optionalen oder mehrere Namen sowie Kontaktinformationen verfügt.

b) Datenelemente, Datentypen (Semantische Ebene)

Zudem bestimmt FHIR teilweise die möglichen Werte für die Attribute dieser Ressourcen. So darf das Geschlecht eines Patienten nur einen der folgenden Werte annehmen: male, female, other, unknown.

Um diese kodierten Werte zu bestimmen, verwendet FHIR eigene Kodiersysteme (z. B. das eben erwähnte AdministrativeGender) oder es schafft die Möglichkeit, eigene Kodiersysteme wie ICD-10 einzubinden.

FHIR-Profile (dazu unten mehr) schränken die Freiheiten ein, z. B. bei der Wahl des Kodiersystems, bzw. legen konkrete Kodiersysteme fest.

c) Zugriff auf Ressourcen (Strukturelle und syntaktische Ebene)

FHIR basiert auf REST-Architekturen. Das sind Software-Architekturen für verteilte Systeme, die einen i. d. R. http(s)-basierten Zugriff auf Ressourcen erlauben.

Die http-Methoden legen dabei fest, was mit der Ressource geschehen soll. Diese führt zu folgender Form der Programmierschnittstellen (API):

Ziel: Ressource …	http-Methode	Beispiel (die Links dienen nur der Illustration und funktionieren nicht)
anlegen	POST	https://meinepraxis.de/pfad/patient
anzeigen	GET	https://meinepraxis.de/pfad/patient/172
suchen	GET	https://meinepraxis.de/pfad/patient?name=Otto
ändern	PUT	https://meinepraxis.de/pfad/patient/172
löschen	DELETE	https://meinepraxis.de/pfad/patient/172

FHIR definiert darüber hinausgehende Aktionen:

• Historie anzeigen lassen: GET https://meinepraxis.de/pfad/patient/172/_history
• Ressource durch Operation bearbeiten: GET https://meinepraxis.de/pfad/patient/172$merge

Die Ressourcen bzw. deren Inhalte werden zwischen Client und Server im XML- oder JSON-Format ausgetauscht.

Für die Ressource Patient (s. Abb. 3) könnte das wie folgt aussehen:

Die in Abbildung 4 dargestellte JSON-Datei zeigt exemplarisch die Daten, mit denen ein Server auf einen GET-Request https://meinepraxis.de/pfad/patient/1234567 antwortet. Oder sie entspräche der Nutzlast, die im http-Body eines POST-Requests enthalten wäre. Hier würde allerdings der Identifier noch fehlen, den erst der Server vergeben würde.

Abbildung 4 zeigt auch, wie FHIR die Datentypen festlegt und dabei allgemeine Datentypen wie „boolean“ oder „date“ ebenso verwendet wie spezifische Datentypen wie HumanName, Address und CodableConcept.

Da FHIR auf http basiert, können bereits auf der http-Ebene (Webserver) und nicht erst auf Applikationsebene Zugriffsberechtigungen eingeschränkt werden.

Als Protokoll zur Sicherung der REST-API kommt meist OAuth 2.0 zum Einsatz.

d) Sonstiges

Extensions

Extensions erlauben es, Attribute zu ergänzen. Das ist notwendig, um beispielsweise landesspezifische Werte erfassen zu können. So hat man in den Niederlanden festgelegt, dass Patienten über ein Attribut „preferredPharmacy“ verfügen müssen. Dieses ist als Extension realisiert.

Extensions finden als Teil von Profilen Anwendung (siehe Abschnitt 4).

Menschenlesbare Zusammenfassungen

Optional können Ressourcen über Texte auch für Menschen lesbar beschrieben werden. Dazu steht eine eingeschränkte Menge an HTML-Tags zur Verfügung, mit der sich z. B. Absätze, Listen und Tabellen gestalten lassen.

4. Was FHIR Profile sind

Dieser Abschnitt stellt die Profile vor und zeigt, wie man in drei Schritten ein eigenes Profil erstellen kann.

a) Konzept

Die Spezifikation von FHIR stammt von HL7, einer weltweit agierenden Organisation. 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.

Die Profile nutzen verschiedene Ansätze, um eine präzise Schnittstellenspezifikation auf Basis von FHIR zu erreichen. Die folgende Tabelle zeigt exemplarisch mehrere Ansätze.

Ansatz	Erläuterung	Beispiel
Einschränkung der Kardinalität	Der FHIR-Standard erlaubt es oft, Attribute wegzulassen oder mehrfach zu verwenden. Ein Profil kann hingegen die Kardinalität genau bestimmen und damit Pflichtfelder festlegen.	Während die Ressource ChargeItem als Anzahl der „quantity“ 0 oder 1 erlaubt (sprich das Attribut optional macht), ist dieses Attribut beim deutschen Basisprofil, dem ChargeItemEBM, ein Pflichtfeld (hat die Kardinalität 1).
Erweiterung durch Extensions	Der FHIR-Standard erlaubt Erweiterungen (s. Abschnitt 2.d).	Das Coding-Profil für ICD-10-GM erweitert die Ressource „Observation“ um das Attribut „Diagnosesicherheit“.
Festlegung von Werten	Ein Profil kann konkrete Kodiersysteme vorgeben. Man spricht auch von ValueSetBindings.	Das Coding-Profil für ICD-10-GM legt zum Kodieren von Diagnosen den ICD-10-Katalog mit der URN http://fhir.de/CodeSystem/bfarm/icd-10-gm fest.Der Identifier von Vertragsarztpraxen muss aus dem System http://fhir.de/sid/kbv/vknr stammen, welches die Vertragskassennummer (VKNR) umfasst.

b) Beispiele für Profile in Deutschland

HL7 hat eine Vielzahl von FHIR-Profilen entwickelt, darunter die Profile im Basisprofil DE. Dazu zählen:

• Deutsche Adressen
• ChargeItem für EBM-Ziffer als Abrechnungsposition
• Coding-Profil für OPS (die Operationen und Prozedurenschlüssel)
• Coverages für das deutsche „GKV-Profil“
• Identifier-Profil für die Telematik-ID

c) Eigenerstellte Profile

Mit dem Tool Forge kann man eigene Profile erstellen. Man kann das Erstellen von Profilen üben, indem man andere Profile nachbaut. Das folgende Beispiel illustriert dies anhand des Coding-Profil für ATC.

Schritt 1: Mit Forge den Datatype „Coding“ klonen

Mit Forge lässt sich der Datatype „Coding“ klonen (s. Abb. 5a).

Als nächstes benennt man diesen Klone als „CodingATC“ (s. Abb. 5b).

Schritt 2: Das Code-System festlegen

Nun gilt es, die Defaults von „Coding“ anzupassen. Das betrifft konkret die folgenden Attribute:

• „system“: Das Attribut wird zum Pflichtattribut und die URL des Kodiersystems wird bestimmt als http://fhir.de/CodeSystem/bfarm/atc (s. Abb. 5c).
• „version“. Auch dieses Attribut wird zum Pflichtattribut. Außerdem werden die Kurz- und Langbeschreibung geändert.
• „code“: Dieses Attribut wird ebenfalls als Pflichtattribut festgelegt.

Das Ergebnis ist eine StructureDefinition im XML-Format, die dem „offiziellen Beispiel“, dem „Coding-Profil für ATC“, bis auf administrative Informationen entspricht (s. Abb. 5d).

Schritt 3: Das Profil veröffentlichen

Bei Simplifier.net könnte nun das Profil hochgeladen und veröffentlicht werden (s. Abb. 5e). Dort stünde es für andere Kommunikationspartner als Spezifikation bereit.

5. Fazit

Endlich ein praxisnaher Interoperabilitätsstandard, der (künftig) auch genutzt wird. Spätestens mit Inkrafttreten von ISiK (V2) sollten auch die Hersteller und Betreiber von Informationssystemen in Krankenhäusern auf diesen Zug aufspringen (müssen). Somit kann es bis zu einer durchgreifenden Interoperabilität in den Krankenhäuser noch bis in Jahr 2025 dauern.

Mit FHIR kommt Fahrt in die Standardisierung des Informationsaustauschs im Gesundheitswesen. Die Hersteller, die gematik, die Verbände, die Versicherungen und Krankenhäuser haben sich auf FHIR eingelassen. Davon zeugen die vielen Profile und Anwendungsfälle. Dazu zählt auch die Spezifikation des „ISiK Basismoduls“ (ISiK = Informationstechnische Systeme in Krankenhäusern).

Dass FHIR diesen Erfolg feiert, hat viele Gründe:

• Das Protokoll ist konsistent und erscheint nicht so aus der Hüfte geschossen wie HL7 V2.
• Gleichzeitig ist es nicht so „überakademisiert“ und unverständlich wie HL7 V3.
• Es hat auch die Entwickler im Blick und verwendet deren Architekturstile (REST), Standards (http, XML, JSON) und Entwicklungswerkzeuge.
• Es gibt eine FHIR-spezifische Toolunterstützung, z. B. Forge und die Plattform Simplifier.net.
• Die Dokumentation ist umfassend.

Gleichzeitig leidet FHIR etwas am eigenen Erfolg. Eine Vielzahl an Profilen ist entstanden, die die Übersicht erschweren. Daher ist es verständlich, dass das Bundesgesundheitsministerium mit der Interoperabilitätsverordnung versucht, Ordnung in den Zoo an Standards zu bringen.

Die dynamische Entwicklung zeigt sich auch daran, dass HL7 in Deutschland starke Änderungen bei den FHIR-Profilen vorgenommen hat. So enthält das deutsche Basisprofil kein zentrales Patienten-Profil mehr. Die Dokumentation ist noch nicht überall nachgezogen, unzählige Links führen ins Leere. Beides erschwert Anfängern die Einarbeitung.

Doch das ist keine Kritik. Im Gegenteil: Den Beteiligten gilt ein großer Dank. Sie haben mit FHIR und den Profilen für das Gesundheitswesen die Voraussetzungen geschaffen, um zumindest bei der Interoperabilität im 21. Jahrhundert anzukommen.