FHIR: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(→‎Projekte von HL7-DE)
 
(9 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
'''FHIR''' steht für '''Fast Healthcare Interoperability Resources'''. Darunter ist eine REST-basierte Webservicespezifikation von HL7 zu verstehen.
+
=Einleitung=
 +
 
 +
Der neue Standard „FHIR“ (Fast Healthcare Interoperable Resources, ausgesprochen wie engl. “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.
 +
 
 +
=Warum FHIR?=
 +
 
 +
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, bspw. 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 UseCases – 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, ATOM, 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 ArchitekturenFHIR 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 „Resourcen“, „Referenzen“ und „Profilen“ zusammen.
 +
==Resourcen==
 +
 
 +
Resourcen sind kompakte, logisch diskrete Einheiten des Datenaustausches mit einem wohldefiniertem Verhalten und eindeutiger Semantik. Sie sind die kleinste Einheit der Übermittlung. Die 150 spezifizierten Resourcen decken das gesamte Spektrum des Gesundheitswesens ab.
 +
 
 +
Beispiele:
 +
* Patient
 +
* Procedure
 +
* Medication
 +
* Order
 +
 
 +
Jede Resource besteht aus drei Teilen:
 +
 
 +
1. 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.
 +
2. Narrative – textuelle, menschenlesbare Zusammenfassung des Inhaltes der Resource.
 +
3. Extensions – Erweiterungen um Einsatzszenarien außerhalb der üblichen UseCases zu unterstützen.
 +
==Referenzen==
 +
 
 +
Resourcen können mit Hilfe von Links auf andere Resourcen 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.
 +
 
 +
==Profile==
 +
 
 +
Die Kombination von Resourcen unterliegt keinen Beschränkungen. Wie einzelne Systeme Resourcen verwenden und kombinieren, wird in Profilen definiert. Profile sind das Regelwerk für die Definition eines Services. Sie erklären, welche Resourcen 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-Resourcen (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.
 +
 
 +
=FHIR in Relation zu anderen Standards=
 +
 
 +
Die Kommunikation mittels FHIR setzt sich immer wieder aus den selben Bausteinen zusammen, unabhängig davon, ob diese als einzelne Resourcen, 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 atomareren 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.“
 +
 
 +
Im Gegensatz zu HL7 Version 2 und CDA verfolgt FHIR diesen architektonischen Ansatz, der es erlaubt, Resourcen als Einzelnes zu suchen, abzurufen und zu editieren – wie es für Patienten- oder Medikamentenverzeichnisse erforderlich ist, gleichzeitig kann jedoch jedes System für sich entscheiden ob es weitere Informationen benötigt und bspw. verlinkte Resourcen abrufen möchte, oder nicht.
 +
In HL7 Version2 und CDA hat die abrufende Applikation keine Kontrolle über den Umfang der Daten, die übermittelt werden.
 +
 
 +
== FHIR in Relation zu HL7 V2 ==
 +
 
 +
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 Resourcen innerhalb einer solchen Nachricht analog zu den Segmenten in HL7 Version 2.
 +
 
 +
== FHIR in Relation zu CDA ==
 +
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 einzelnen Resourcen (vergleichbar mit CDA-Sections) enthalten sowohl menschenlesbaren Text als auch maschinenlesbare Daten. Ein FHIR-Dokument besteht aus einer in Sektionen untergliederte Zusammensetzung von Resourcen.
 +
 
 +
In einem Projekt (2014) arbeiten die FHIR-Entwickler darauf hin die Inhalte der einzelnen Sektionen mit der US-amerikanischen CCDA-Spezifikation zu harmonisieren.
 +
 
 +
Ü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.
 +
 
 +
== IHE-Profile basierend auf FHIR==
 +
* [http://wiki.ihe.net/index.php?title=Internet_User_Authorization Internet User Authorization]
 +
* [http://wiki.ihe.net/index.php?title=Mobile_access_to_Health_Documents_(MHD) Mobile Access to Health Documents]
 +
* [http://wiki.ihe.net/index.php?title=Patient_Demographics_Query_for_Mobile_(PDQm) Patient Demographics Query for Mobile]
 +
* [http://wiki.ihe.net/index.php?title=Category:FHIR Übersicht]
 +
 
 +
=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
  
 
==Bemerkenswerte Projekte und Anwendungen international==
 
==Bemerkenswerte Projekte und Anwendungen international==
Zeile 24: Zeile 142:
 
** Wird produktiv genutzt im Rahmen einer [http://c-tracker.chip.org/ großangelegten Hepatitis-Studie]
 
** Wird produktiv genutzt im Rahmen einer [http://c-tracker.chip.org/ großangelegten Hepatitis-Studie]
  
−
==Basis-Profilierung==
+
=FHIR in Deutschland=
−
Ziel des Projektes ist es, für die Verwendung des Standards in Deutschland erforderliche Extensions zu definieren und Basis-Profile zu erstellen, die als Grundlage der Interoperabilität von FHIR-Systemen in unterschiedlichen Einsatzszenarien dienen sollen.
 
  
−
[[FHIR-Basisprofilierung_(Projekt)| zur Projektseite]]
+
Die Aktivitäten zu FHIR sind im [[TC_FHIR | Technischen Kommittee FHIR]] gebündelt.
  
−
==Links==
+
=Links=
 
* [http://www.hl7.org/fhir FHIR (Originalspezifikation)]
 
* [http://www.hl7.org/fhir FHIR (Originalspezifikation)]
  

Aktuelle Version vom 2. Dezember 2016, 09:35 Uhr

Einleitung

Der neue Standard „FHIR“ (Fast Healthcare Interoperable Resources, ausgesprochen wie engl. “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.

Warum FHIR?

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, bspw. 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 UseCases – 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, ATOM, 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 ArchitekturenFHIR 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 „Resourcen“, „Referenzen“ und „Profilen“ zusammen.

Resourcen

Resourcen sind kompakte, logisch diskrete Einheiten des Datenaustausches mit einem wohldefiniertem Verhalten und eindeutiger Semantik. Sie sind die kleinste Einheit der Übermittlung. Die 150 spezifizierten Resourcen decken das gesamte Spektrum des Gesundheitswesens ab.

Beispiele:

  • Patient
  • Procedure
  • Medication
  • Order

Jede Resource besteht aus drei Teilen:

1. 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. 2. Narrative – textuelle, menschenlesbare Zusammenfassung des Inhaltes der Resource. 3. Extensions – Erweiterungen um Einsatzszenarien außerhalb der üblichen UseCases zu unterstützen.

Referenzen

Resourcen können mit Hilfe von Links auf andere Resourcen 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.

Profile

Die Kombination von Resourcen unterliegt keinen Beschränkungen. Wie einzelne Systeme Resourcen verwenden und kombinieren, wird in Profilen definiert. Profile sind das Regelwerk für die Definition eines Services. Sie erklären, welche Resourcen 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-Resourcen (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.

FHIR in Relation zu anderen Standards

Die Kommunikation mittels FHIR setzt sich immer wieder aus den selben Bausteinen zusammen, unabhängig davon, ob diese als einzelne Resourcen, 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 atomareren 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.“

Im Gegensatz zu HL7 Version 2 und CDA verfolgt FHIR diesen architektonischen Ansatz, der es erlaubt, Resourcen als Einzelnes zu suchen, abzurufen und zu editieren – wie es für Patienten- oder Medikamentenverzeichnisse erforderlich ist, gleichzeitig kann jedoch jedes System für sich entscheiden ob es weitere Informationen benötigt und bspw. verlinkte Resourcen abrufen möchte, oder nicht. In HL7 Version2 und CDA hat die abrufende Applikation keine Kontrolle über den Umfang der Daten, die übermittelt werden.

FHIR in Relation zu HL7 V2

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 Resourcen innerhalb einer solchen Nachricht analog zu den Segmenten in HL7 Version 2.

FHIR in Relation zu CDA

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 einzelnen Resourcen (vergleichbar mit CDA-Sections) enthalten sowohl menschenlesbaren Text als auch maschinenlesbare Daten. Ein FHIR-Dokument besteht aus einer in Sektionen untergliederte Zusammensetzung von Resourcen.

In einem Projekt (2014) arbeiten die FHIR-Entwickler darauf hin die Inhalte der einzelnen Sektionen mit der US-amerikanischen CCDA-Spezifikation zu harmonisieren.

Ü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.

IHE-Profile basierend auf FHIR

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

Bemerkenswerte Projekte und Anwendungen international

  • SMART-on-FHIR
    • Kooperation von Boston Children's Hospital, Harvard Medical, Argonaut Project
    • Integration von webbasierten Apps in KIS-Systeme
    • definiert ein Framework für Authentifikation (OAUTH 2) und die Übergabe von Kontext zwischen KIS und App
    • HTML5-basierte Apps können nahtlos in die KIS-UI integriert werden
    • Libraries für Python, Swift, JavaScript verfügbar
    • App-Gallery
  • CDS-Hooks
    • Framework für die Einbindung von Clinical Decision Support-Diensten in eine Anwendung
    • Anwendung und CDS-Service kommunizieren per FHIR über das SMART-on-FHIR Framework
    • CDS-Service kann dem Anwender in Echtzeit Hinweise, Warnungen, Links einblenden
    • Live-Demo für "Medication-Subscribe"-Dienst, der bei der Verordnung eines Medikamentes die entstehenden Kosten ermittelt und Alternativen vorschlägt
  • C3-PRO
    • Framework für klinische Studien
    • integriert FHIR mit dem Apple Research Kit
    • i2b2 DataMining als Backend
    • AWS-Komponente für hoch-verfügbare Kommunikation
    • Modulare Architektur
    • Wird produktiv genutzt im Rahmen einer großangelegten Hepatitis-Studie

FHIR in Deutschland

Die Aktivitäten zu FHIR sind im Technischen Kommittee FHIR gebündelt.

Links

Abgerufen von „https://wiki.hl7.de/index.php?title=FHIR&oldid=32694“