gms | German Medical Science

Einleitung: FHIR (Fast Healthcare Interoperability Resources) ist ein neuer Entwurf eines Standards von HL7 [1] mit dem Ziel eine einfache Implementierbarkeit zu gewährleisten. Dazu setzt FHIR auf Eigenschaften von HL7 V2 und V3 und CDA auf und unterstützt moderne Web Services wie XML, JSON, HTTP, Atom und auch RESTful Architekturen. Die Kombination modularer Komponenten, so genannte Ressourcen, erlaubt die Abbildung der Inhalte komplexer medizinischer Datenobjekte. Ressourcen können über "extensions" erweitert bzw. durch "profiles" in der Nutzung eingeschränkt werden.

Ziel dieses Beitrags ist zu untersuchen, inwieweit diese Ressourcen bzw. erweiterte Ressourcen geeignet sind ein konkretes, komplexes Datenobjekt abzubilden und die Implementierung einer einfachen Anwendung zu unterstützen. In diesem studentischen Projekt solle als Datenobjekt ein Notfalldatensatz verwendet werden, so dass zudem eine Auswahl aus vorliegenden Vorgaben erfolgt.

Material und Methoden: Der Inhalt eines Notfalldatensatzes war und ist Ziel vieler Initiativen und Spezifikationen. So hat die Bundesärztekammer (BÄK) ein Arbeitskonzept für die Nutzung zusammen mit der eGK veröffentlicht [2] und arbeitet derzeit an einer konkreten Spezifikation. Für die Schweiz besteht bereits ein Implementierungsleitfaden für ein CDA Dokument [3]. Ebenso adressiert die EU Richtlinie mit dem "Minimum Dataset" den elektronischen Datenaustausch von u.a. Notfalldaten über Ländergrenzen [4]. Obwohl lediglich mit dem Implementierungsleitfaden der HL7 Benutzergruppe der Schweiz eine konkrete Spezifikation vorliegt, fiel die Entscheidung zugunsten des Arbeitskonzepts der BÄK, da dieses in Deutschland das beste Potential zur Umsetzung aufweist.

Die Anwendung selbst sollte die folgenden "use cases" für unterschiedliche Endgeräte umfassen: (i) Notfalldaten anlegen und auf dem Server abspeichern, (ii) eigene Notfalldaten anzeigen, (iii) eigene Notfalldaten editieren und speichern, (iv) Notfalldaten drucken und (v) nach Notfalldaten anderer Personen suchen.

Aus der Liste der FHIR Server bei HL7 wurde der Open Source Server von Ewout Kramer ausgewählt [5]. Er konnte in einer VisualStudio 2013 Umgebung ohne Probleme gestartet werden, nachdem die zugehörige Datenbank MongoDB installiert war. Als Entwicklungsumgebung wurde Aptana Studio 3 verwendet. Für die Browserbasierte Anwendung kamen Javascript, HTML, JQuery, JQuery UI und JQuery Mobile zum Einsatz und ermöglichen die Ausführung auf mehreren Plattformen.

Die Bewertung von FHIR orientierte sich an den folgenden Kriterien: (i) Einfachheit der Nutzung in einer web-basierten Anwendung, (ii) Umfang der Abbildung der Inhalte des Notfalldatensatz durch vorhandene Ressourcen in FHIR und (iii) IT Aspekte wie Versionierung von Ressourcen, referentielle Integrität und Autorenschaft.

Ergebnisse: Aufgrund des erwarteten Umsetzungspotentials wurde das Arbeitskonzept der BÄK als Vorgabe für die Inhalte eines Notfalldatensatzes gewählt. Die Abbildung der Inhalte erforderte die Nutzung von neun Ressourcen. Für die Person bzw. den Patient enthielt die Ressource "Patient" die benötigten Angaben. Bestehende Diagnosen wurden in zwei Ressourcen "DiagnosticReport" und "Observation" abgelegt, wobei beide durch Referenzen rekursiv der Ressource "Patient" zugeordnet wurden. Die Medikation wurde auf "Medication", zugehörige Wirkstoffe auf "Substance" und das Gabeschema auf "MedicationDispense" abgebildet. Durch die Forderung nach einem Freitext für Allergien musste die bestehende Ressource "AllergyTolerance" mit einer "Extension" zur Aufnahme des Freitexts erweitert erden. Die 'Besonderen Hinweise' in der Vorgabe der BÄK beziehen sich u. a. auf Implantate, die mit der Ressource "Devices" abbildbar sind, allerdings ohne das geforderte Datum der Implantation, das erneut eine "Extension" erfordert. Für die in dieser Rubrik ebenfalls mögliche Angabe einer Schwangerschaft steht die Ressource "Condition" bereit.

Die Umsetzung der Anwendung nutzt fünf Module und war bis auf ein Berechtigungsproblem im Zusammenspiel zwischen FHIR Server und Browser gut lösbar.

Im Sinne der Bewertung können FHIR Ressourcen auf die graphischen Elemente der Anwendung abgebildet werden; dies ist sowohl statisch als auch mit einer dynamischen Generierung von Elementen der Benutzeroberfläche möglich. Da die FHIR Ressourcen granularer als Konstrukte wie CMETs oder HL7 Templates sind, werden für die Abbildung der fünf Datensatzelemente der eGK für die Notfalldaten neun Ressourcen benötigt. Nachteilig ist allerdings, dass so in einzelnen Ressourcen nur ein Bruchteil der vorliegenden Elemente genutzt wird.

Diskussion: Obwohl der Notfalldatensatz erfolgreich und mit einem akzeptablen Aufwand umgesetzt werden konnte, gibt es einige Kritikpunkte, die sich auf die Eigenschaften und Konzepte von FHIR beziehen. In FHIR sind die Metadaten zu einer Ressource eingeschränkt, so dass z.B. Angaben zur Version des FHIR Standards fehlen, die die Grundlage bei der Erstellung der Ressource bildete. Zudem gibt es keine Angaben zur Autorenschaft einer Ressource oder einer Signatur. Berechtigungen, d.h. in diesem Fall zur Steuerung, wer auf die Notfalldaten zugreifen darf, werden in FHIR nicht explizit verwaltet. Sie sind durch die jeweiligen FHIR Server oder andere Systeme zusätzlich zu erbringen. Auch wenn für diese Anwendung ein definierter FHIR Server verwendet wurde und damit die Verfügbarkeit der erstellten Ressourcen gewährleistet ist, bleibt die Frage der referentiellen Integrität in einem verteilten System unbeantwortet. Am Rande sei noch erwähnt, dass in dem vorliegenden Standardentwurf noch unterschiedliche Bezeichnungen wie "subject" oder "patient" für den Patienten in Ressourcen verwendet werden, so dass eine Suche derzeit noch mit beiden Begriffen erfolgen sollte. Insgesamt erscheint der Ansatz von FHIR gut geeignet, um eine einfache Anwendung z.B. in Umfeld von Apps zu realisieren. Jedoch sollten für komplexe Anwendungen Lösungsansätze für die genannten Punkte vorliegen.