Warum FHIR?
Der neue Standard „FHIR“® (Fast Healthcare Interoperability Resources, ausgesprochen wie englisch fire) wurde von Health Level Seven International (HL7) ins Leben gerufen. Der Standard unterstützt den Datenaustausch zwischen Softwaresystemen im Gesundheitswesen. Er vereinigt die Vorteile der etablierten HL7-Standard-Produktlinien Version 2, Version 3 und CDA mit jenen aktueller Web-Standards und legt einen starken Fokus auf eine einfache Implementierbarkeit.
Der Bedarf, medizinische Informationen elektronisch zu übermitteln, besteht seit den ersten mainframe-basierten elektronischen Patientenakten der 1960er Jahre. HL7 Version 2 entstand in den 1970ern und zielte auf den einrichtungs-internen Datenverkehr eines Krankenhauses. Der Druck, Daten auch einrichtungs- und sektorübergreifend kommunizieren zu können, sowie mobile und cloud-basierte Anwendungen zu unterstützen, wächst ebenso wie jener, Interoperabilität innerhalb von Tagen und Wochen statt Monaten und Jahren herstellen zu können.
Die treibenden Faktoren von FHIR sind:
- Paradigmenwechsel im Gesundheitswesen
Der Patient fordert zunehmend die Kontrolle über seine medizinischen Daten. Die Nachfrage, Patientendaten über Einrichtungs- Fachrichtungs- und Landesgrenzen hinweg zu kommunizieren, steigt. - Online statt offline
Der Trend von Desktop zu Tablet, Software zu App, Patienten- zu Gesundheitsakte und Server zu Cloud hält seit Jahren an. FHIR ist agil, unterstützt mobile Architekturen und verbindet Patienten ortsunabhängig mit ihren Daten. - Mehr Transparenz
Elektronische Patientenakten verhalten sich wie Datengräber. Die Informationen, einmal archiviert, lassen sich von anderen Systemen kaum wieder abrufen, insbesondere nicht in kompatiblen Formaten. FHIR verhält sich wie eine offene Schnittstelle um die Daten aus diesen Gräbern zu heben. Unterschiedliche Facetten einer Patientenakte werden in unterschiedlichen Systemen gespeichert. Moderne Werkzeuge erlauben es, diese verteilten Daten für den Anwender transparent zu aggregieren und weiterzuverarbeiten. - Mehr Analysen
Analysen benötigen transparenten Zugriff auf die Daten, doch müssen diese auch in analysierbaren Formaten vorliegen. FHIR verwendet Strukturen, die Auswertungen in die Breite sowie in die Tiefe optimal unterstützen. Beim Einsatz von FHIR erübrigt sich die Notwendigkeit, beispielsweise CDA-Dokumente in atomare Konzepte zu zerlegen, um diese analysieren zu können.
Ein neuer Anfang
Der Entwurf von FHIR begann mit der Frage: wie müsste der Datenaustausch im Gesundheitswesen aussehen, wenn man ganz von vorne anfangen würde?
Eine Suche nach den Erfolgsfaktoren moderner Implementierungen führte zu REST-Architekturen. FHIR basiert auf diesem Ansatz, der einen einfachen und etablierten Mechanismus für den Zugriff auf Daten auf verteilten Systemen verwendet.
HL7, weitere Standardisierungsorganisationen sowie der Beraterstab für Wissenschaft und Technik des US-Präsidenten (PCAST) kamen 2011 zu der Überzeugung, dass die Größe der übermittelten Datenpakete weder zu groß (schwer zu handhabende hochkomplexe Datenstrukturen) noch zu klein (die Daten benötigen Metainformationen und Kontext, um ihre Bedeutung zu erhalten) gewählt werden darf.
FHIR verwendet kompakte, in sich geschlossene Datenpakete, mit einheitlichem, wohldefiniertem Verhalten, Semantik, Kontext- und Metadaten.
Die FHIR-Philosophie
FHIR ist nicht die Lösung aller Probleme im Bereich der Interoperabilität. Unterschiede bei Workflows, abweichende Methoden der Datenerfassung, einrichtungsübergreifende Patientenidentifikation und heterogene Einsatzszenarien zu überbrücken, bleibt weiterhin eine große Herausforderung.
FHIR zielt darauf ab, die Implementierung des Datenaustausches so einfach wie möglich zu gestalten, um der Lösung der wichtigen Fragen nicht im Wege zu stehen.
Das Design von FHIR basiert darum auf den folgenden Prinzipien:
- Fokus auf Implementierer: FHIR ist für Software-Entwickler leicht zu erlernen. Es gibt zahlreiche Tools, APIs und Beispiele, die die Implementierung vereinfachen und beschleunigen.
- Fokus auf weitverbreitete Use Cases – jedoch mit Option zur Erweiterung
- Fokus auf erprobte Web-Technologien: FHIR verwendet Technologien, die aus Applikationen wie Google, Twitter und Facebook bekannt sind (z.B. XML, JSON, HTTPS, OAuth)
- Fokus auf menschenlesbare Information als Basis der Interoperabilität, Daten können immer in menschenlesbarer Form ausgetauscht und dargestellt werden, selbst wenn jegliche maschinenlesbare Interoperabilität fehlschlägt.
- Fokus auf freie Verfügbarkeit: FHIR basiert auf einer ‘Open Source’ Lizenz
- Unterstützung multipler Paradigmen und Architekturen: FHIR unterstützt die gleichen Datenmodelle und Profile (siehe weiter unten) unabhängig vom darunterliegenden Integrations-Ansatz (REST, Dokumente, Nachrichten, Services). Dies ist eine Konsequenz aus den Erfahrungen mit HL7 Version 3, wo sich die Datenmodelle abhängig vom Integrationsansatz unterscheiden und damit die Implementierung erschweren.
FHIR-Bausteine
Der FHIR-Standard setzt sich aus den Bausteinen „Resources“, „Referenzen“ und „Profilen“ zusammen.
Resources
Resources sind kompakte, logisch diskrete Einheiten des Datenaustausches mit einem wohldefiniertem Verhalten und eindeutiger Semantik. Sie sind die kleinste Einheit der Übermittlung. Die 150 spezifizierten Resources decken das gesamte Spektrum des Gesundheitswesens ab.
Beispiele:
- Patient
- Procedure
- Medication
- Order
Abbildung: Mindmap der aktuell definierten FHIR Resources (2014)
Jede Resource besteht aus drei Teilen:
- Strukturierte Daten – diese Attribute decken 80% der üblichen Einsatzszenarien ab. 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. Darüber hinaus gehende Inhalte müssen über Extensions abgebildet werden.
- Narrative – textuelle, menschenlesbare Zusammenfassung des Inhaltes der Resource.
- Extensions – Erweiterungen um Einsatzszenarien außerhalb der üblichen UseCases zu unterstützen.
Referenzen
Resources können mit Hilfe von Links auf andere Resources verweisen. Dadurch verknüpfen sich die Informationseinheiten zu einem Netzwerk, das beispielsweise eine Medikamenten-Verordnung, einen Labor-Befund oder gar vollständige Patientenakte abbilden kann.
Abbildung: Beispiel für verlinkte Resources
Die Kombination von Resources unterliegt keinen Beschränkungen. Wie einzelne Systeme Resources verwenden und kombinieren, wird in Profilen definiert. Profile sind das Regelwerk für die Definition eines Services. Sie erklären, welche Resources und Extensions ein System kommunizieren und speichern kann.
Profile werden von HL7 spezifiziert. Regionale HL7 Benutzergruppen (z.B. HL7 Deutschland e.V.) können diese Profile an nationale Besonderheiten, Regularien und Gesetzgebungen anpassen.
Auch Organisationen oder Projektgruppen können eigene Profile erstellen.
Zum Beispiel:
Die Regularien in einem Krankenhaus erfordern, dass bei der Überweisung von Patienten in die Kinderchirurgie stets der Name der Eltern, das Alter des Kindes sowie dessen Geschlecht angegeben werden müssen. Fehlt eine diese Informationen, so wird die Überweisung als ungültig zurückgewiesen. Ein Profil definiert die Regeln, die auf die Standard-Resources (hier: Patient) anzuwenden sind. Diese Regeln können beispielsweise beinhalten, welche Attribute verpflichtend angegeben werden müssen, welche Terminologien verwendet werden dürfen und welche Extensions zum Einsatz kommen.
Wir benutzen bereits HL7 Version 2 und CDA – brauchen wir FHIR?
Die Kommunikation mittels FHIR setzt sich immer wieder aus den selben Bausteinen zusammen, unabhängig davon, ob diese als einzelne Resources, komplexe Dokumente, Services oder Nachrichten übermittelt werden.
Der PCAST-Report von 2011 stellt fest:
Wir sind der Auffassung, dass eine universelle Sprache für den Datenaustausch im Gesundheitswesen den Austausch von mit Metadaten versehenen Elementen auf einem mehr atomaren und eigenständigeren Niveau [im Vergleich zu Dokumenten] unterstützen muss, so dass die Aggregation und Präsentation der Datenelemente in Dokumenten oder Berichten selbst zu einem robusten Marktsegment für Applikationen werden kann.
In HL7 Version2 und CDA hat die abrufende Applikation keine Kontrolle über den Umfang der Daten, die übermittelt werden.
Abbildung: Beispiel für eine Resource, die Basis-Informationseinheit in einer RESTful Umgebung
HL7 Version 2, welches auf den EDI-Standard aus den 1970er Jahren zurückgeht, funktioniert gut innerhalb einer Institution. Es lässt sich jedoch schlecht für die intersektorale Kommunikation skalieren. FHIR-Nachrichten decken den gleichen Funktionsumfang wie HL7 Version 2 ab. Dabei verhalten sich die Resources innerhalb einer solchen Nachricht analog zu den Segmenten in HL7 Version 2.
CDA verfügt über ein sehr breites Spektrum. Die Implementierung erfordert jedoch einen hohen Zeit- und Schulungsaufwand. CDA verfolgt den Zweck, sowohl die Mensch-zu-Mensch-Interoperabilität durch die mandatorische Übermittlung menschenlesbarer Texte als auch die Software-zu-Software-Interoperabilität durch die optionale Übermittlung von strukturieren Daten abzubilden. Letzteres durchzusetzen zählt nach wie vor zu den großen Herausforderungen, mit denen CDA ringt.
FHIR-Dokumente decken die gleiche Funktionalität wie CDA ab: Die einelnen Resources (vergleichbar mit CDA-Sections) enthalten sowohl menschenlesbaren Text als auch maschinenlesbare Daten. Ein FHIR-Dokument besteht aus einer in Sektionen untergliederte Zusammensetzung von Resources.
In einem Projekt (2014) arbeiten die FHIR-Entwickler darauf hin die Inhalte der einzelnen Sektionen mit der US-amerikanischen CCDA-Spezifikation zu harmonisieren.
Abbildung: Beispiel für ein FHIR-Dokument mit Resources und Referenzen
Über die zuvor genannten Funktionalitäten aus dem Spektrum von HL7 Version 2 und CDA hinaus, füllt FHIR eine Lücke, die weder HL7 Version2 noch CDA derzeit zufriedenstellend abdecken können: Durch den Einsatz moderner Web-Technologien (REST, XML, JSON, http, OAUTH…) unterstützt FHIR die Integration von Social und Mobile Apps sowie mobilen Endgeräten.
Von Version 2 und CDA zu FHIR
Organisationen im Gesundheitswesen müssen bereits heute mit einer Vielzahl unterschiedlicher Standards zurechtkommen (HL7 Version2, CDA, DICOM, xDT, HCM…) und zwischen diesen Standards vermitteln. Die Herausforderung zwischen FHIR und den bereits vorhandenen Standards zu übersetzen, unterscheidet sich davon kaum.
Da FHIR strukturell auf HL7 Version 2 und CDA basiert und die Harmonisierung von FHIR und CDA angestrebt wird, stellt sich das Mapping unkompliziert dar.
Kommunikationsserver können diese Aufgabe übernehmen, so dass an vorhandenen Schnittstellen keine Anpassungen erforderlich werden.
Zusammenfassung
- FHIR ist einfacher und kostengünstiger als vergleichbare Standards
- FHIR ist leichter zu erlernen, leichter zu implementieren und leichter zu debuggen. Man kann sich innerhalb eines Wochenendes einarbeiten. Viele Tools und Codebeispiele werden mitgeliefert.
◦ FHIR verfügt über eine sehr aktive und offene Community, die sich regelmäßig auf Connectathons zusammenfindet und einen regen Austausch in Foren, Chats und Online-Plattformen pflegt.
◦ FHIR verwendet modern Web-Technologien, wie sie z.B. auch von Facebook, Twitter und Google eingesetzt werden.
◦ FHIR erleichtert die Suche nach qualifizierten Entwicklern, da es auf weitverbreitete Technologien setzt. - FHIR wird derzeit bereits von zahlreichen Organisationen angewendet, unter anderem von
◦ (USA) ONC, SMART, Intermountain, CommonWell
◦ (UK) NHS
◦ (NZ) Orion Health,
◦ (NO) Helse Vest
◦ mehreren IHE-Profilen (z.B. PDQm)
◦ 70 Implementierungen in über 20 Ländern (Stand 2014) - FHIR wird die Kommunikation im Gesundheitswesen in Zukunft prägend beeinflussen, denn
◦ es ist skalierbar von sehr einfach zu hochkomplex
◦ es ist äußerst flexibel
◦ es ist lizenzfrei und quelloffen
Anwendungen für FHIR
FHIR eignet sich für den Einsatz in vielen Szenarien:
- den Datenaustausch zwischen Systemen innerhalb einer Organisation
- den Datenaustausch in einem intersektoralen, regionalen Netzwerk
- den Datenaustausch auf nationaler Ebene, z.B. für Register und elektronische Gesundheitsakten
- den Datenaustausch mit sozialen Median und mobile Applikationen
Da die sozialen Medien und mobilen Applikationen noch „grüne Wiese“ für die Kommunikation von medizinischen Informationen ist, wird erwartet, das FHIR hier am schnellsten Fuß fasst, bevor es sich auf die traditionellen Einsatzgebiete ausweitet
Weitere Informationen
- Über unsere Mailingliste fhir(at)hl7.de versorgen wir alle Interessenten regelmäßig mit relevanten Informationen über Meilensteine in der Standard-Entwicklung, Veranstaltungen und Informationsquellen
- Der FHIR Standard (in Englisch) – www.fhir.org
- FHIR-Aktivitäten in Deutschland (Blog) – www.fhirabend.de
- Der FHIR Kanal bei hl7.tv – hl7.tv/FHIR
Die Autoren
Herausgeber: René Spronk (Ringholm), Simone Heckmann (Health-Comm GmbH), basierend auf Quellen von Lloyd McKenzie (LM&A Consulting), Ewout Kramer (Furore) und Grahame Grieve (Health Intersections)
Deutsche Übersetzung: Simone Heckmann (Health-Comm GmbH)
