FHIR (Fast Healthcare Interoperability Resources)

FHIR (Fast Healthcare Interoperability Resources) ist ein internationaler HL7-Standard für den Austausch von Gesundheitsinformationen unter Verwendung modularer Dateneinheiten, sogenannter Ressourcen, und webbasierter Anwendungsprogrammierschnittstellen (APIs). Er kombiniert die strukturierte Informationsmodellierung früherer HL7-Standards mit weit verbreiteten Webtechnologien – RESTful APIs, JSON- und XML-Serialisierung sowie Standard-HTTP –, um den Zugriff auf Gesundheitsdaten und die Entwicklung von Anwendungen zu erleichtern.

Definition

FHIR ist ein Standard, der klinische und administrative Daten als diskrete, eigenständige Ressourcen darstellt – jede mit einer definierten Struktur und einer stabilen Identität – und diese über eine RESTful-Anwendungsprogrammierschnittstelle (API) mittels Standard-Webprotokollen austauscht, sodass Systeme und Anwendungen Gesundheitsdaten interoperabel lesen, schreiben und durchsuchen können.

Scope

Dieser Eintrag behandelt das FHIR-Ressourcenmodell, sein RESTful-Austauschparadigma, die Profilierung für lokale Anforderungen und seine Beziehung zu früheren HL7-Standards sowie zu austauschbaren Anwendungen wie SMART on FHIR. Er behandelt FHIR als Datenaustauschstandard und methodisches Thema; er gibt keine Anleitungen zur Implementierung, Sicherheitskonfiguration oder Beschaffung.

Core questions

• Was ist eine FHIR-Ressource, und wie kombinieren sich Ressourcen, um eine Patientenakte darzustellen?
• Wie unterscheidet sich der RESTful-API-Ansatz von der HL7 v2-Nachrichtenübermittlung?
• Was sind Profile und Erweiterungen, und warum werden sie benötigt?
• Wie ermöglicht FHIR austauschbare Anwendungen wie SMART on FHIR?

Key concepts

• Ressourcen (Patient, Observation, Encounter, MedicationRequest, etc.)
• RESTful API (erstellen, lesen, aktualisieren, löschen, suchen)
• JSON- und XML-Serialisierung
• Referenzen und Bundles
• Profile und Erweiterungen
• Implementierungsleitfäden
• SMART on FHIR austauschbare Anwendungen

Mechanisms

FHIR modelliert Gesundheitsinformationen als Ressourcen – modulare Einheiten wie Patient, Observation oder MedicationRequest – jede mit einem definierten Satz von Elementen und einer stabilen, adressierbaren Identität. Ressourcen verweisen aufeinander, und Gruppen von Ressourcen können zu Bundles zusammengefasst werden. Systeme tauschen sie über eine RESTful-Schnittstelle aus, bei der Standard-HTTP-Operationen Ressourcen erstellen, lesen, aktualisieren, löschen und suchen, wobei Daten als JSON oder XML serialisiert werden. Da individuelle Implementierungen lokale Einschränkungen benötigen, unterstützt FHIR die Profilierung: Profile und Erweiterungen passen Basisressourcen an eine Jurisdiktion oder einen Anwendungsfall an, und Implementierungsleitfäden bündeln diese für eine Gemeinschaft. Dieses Ressourcen- und API-Design untermauert auch austauschbare Anwendungen, bei denen eine App, die an einem FHIR-Endpunkt (das SMART on FHIR-Muster) autorisiert ist, über konforme Systeme hinweg ausgeführt werden kann.

Clinical relevance

FHIR bildet zunehmend die Grundlage für patientenorientierte Apps, den Zugriff auf klinische Daten und den organisationsübergreifenden Austausch und ist Bestandteil nationaler Interoperabilitätsrichtlinien. Dieser Eintrag beschreibt, wie FHIR Daten strukturiert und zugänglich macht; er ist Referenzmaterial über den Standard und keine Anleitung zum Aufbau, zur Sicherung oder zur Bereitstellung klinischer Systeme.

Evidence & guidelines

FHIR ist ein normativer HL7 International Standard, der von HL7 entwickelt und abgestimmt wurde, mit nationalen und regionalen Implementierungsleitfäden, die ihn für den lokalen Gebrauch einschränken. Bender und Sartipi (2013) ist eine frühe technische Beschreibung des RESTful-Designs des Standards; das Lehrbuch von Benson und Grieve bietet eine konsolidierte Darstellung von FHIR neben HL7 und SNOMED CT, und Mandl und Kohane (2012) liefern die politische Begründung für die offene, App-basierte Architektur, die FHIR unterstützt.

History

FHIR wurde um 2011-2012 von HL7 unter der Leitung von Grahame Grieve als bewusst schlankere Alternative zu HL7 Version 3 initiiert, die gängige Webtechnologien wiederverwendete. Frühe Beschreibungen wie die von Bender und Sartipi (2013) fassten es als agilen, RESTful-Ansatz auf, und der Standard entwickelte sich in den 2010er Jahren durch aufeinanderfolgende Veröffentlichungen zu einem normativen Status, wobei er mit politischen Argumenten für offene, austauschbare Gesundheits-IT konvergierte.

Debates

Wie gut erreicht FHIR eine echte semantische Interoperabilität?

FHIR standardisiert Struktur und Austausch gut, aber eine konsistente Bedeutung hängt immer noch von der disziplinierten Verwendung von Profilen und Terminologiebindungen ab; Variationen in der Profilierung über Implementierungen hinweg können die sofortige semantische Interoperabilität einschränken.

Key figures

• Grahame Grieve
• Duane Bender
• Kamran Sartipi
• Kenneth Mandl
• Isaac Kohane

Seminal works

• bender-sartipi-2013
• benson-grieve-2021

Frequently asked questions

Wie unterscheidet sich FHIR von der HL7 v2-Nachrichtenübermittlung?

HL7 v2 sendet ereignisgesteuerte Nachrichten mit segmentierten Abschnitten, während FHIR diskrete Ressourcen über eine RESTful Web-API bereitstellt, die Systeme direkt lesen, schreiben und durchsuchen können, unter Verwendung gängiger Formate wie JSON über HTTP.

Was bedeutet SMART on FHIR?

SMART on FHIR ist ein Muster, bei dem eine Anwendung sich über offene Standards an einem FHIR-Endpunkt autorisiert, sodass dieselbe App über verschiedene Systeme hinweg ausgeführt werden kann, die konforme FHIR-APIs bereitstellen; es ist eine Motivation für das Ressourcen- und API-Design von FHIR.