Frohe Oster-FHIR-Tage!

Funktioniert das neue Apple Health auch in Deutschland?

Quelle: Wellness Corporate Solutions

Unlängst kündigte Apple für die neue Version seines mobilen Betriebssystems iOS 11.3 eine Neuerung für Apple Health an, die für einige Verwunderung sorgte:

Basierend auf dem HL7 Standard FHIR soll der Datentransfer zwischen Krankenhaus-/ Praxisverwaltungssystemen und Patienten-Smartphones ermöglicht werden.

Wie ist das möglich? Braucht es wirklich nur einen pfiffigen neuen Kommunikationsstandard um alle Barrieren, die uns im Gesundheitswesen seit Jahrzehnten Kopfzerbrechen bereiten, mit einem einzigen iPhone-Update niederzureißen?

Ist das, was in den USA anscheinend so mühelos funktioniert auch in Deutschland möglich?

Technisch betrachtet würde das Verfahren auch bei uns funktionieren. Allerdings besteht in den USA die einzigartige Situation, dass mit Hilfe des Subventionsprogrammes ("Meaningful Use") im Rahmen des HITECH Acts (Health Information Technology for Economic and Clinical Health Act) durch den ONC (Office of the National Coordinator for Health Information Technology) konkrete und verpflichtende Vorgaben auf nationaler Ebene gemacht wurden, welche Daten KIS und PVS-Systeme über eine offene API verfügbar machen müssen.

Konkret wurden die gesetzlichen Anforderungen von den US-Herstellern durch die Implementierung der FHIR-API in Kombination mit dem SMART-Framework für die Authentifizierung und Autorisierung von Apps implementiert.

Das Mapping des Datenkatalogs auf FHIR fand im Argonaut-Project statt, einem Zusammenschluss der Hersteller zur Förderung von FHIR.
Diese Regelung trat zum 1.1.2018 in Kraft, so dass Apple sich darauf verlassen kann, in den meisten amerikanischen Kliniken diese standardisierten Schnittstellen anzutreffen, die einen genau definierte Menge an Daten zur Verfügung stellen.

Die USA werden nun die Früchte geerntet, die vor fast 10 Jahren mit einer Gesetzesinitiative von Präsident Obama gesät wurden!

Eine entsprechende Initiative deutscher Gesetzgeber gibt es hingegen nicht. Es gibt weder einen definierten Datenkatalog, noch nationale Vorgaben zu den zu verwendenden Terminologien, noch eine verbindliche Vorgabe, die Hersteller dazu zwingt oder zumindest ermutigt, solche Schnittstellen umzusetzen.

Zwar gibt es in Deutschland agierende Hersteller, die die Meaningful-Use-Schnittstellen aufgrund einer internationalen Produktpalette implementiert haben, jedoch basieren diese auf dem amerikanischen Datenkatalog, der hierzulande nur eingeschränkt nutzbar ist. (Bspw. kommen dort SNOMED-Terminologien zum Einsatz, für die in Deutschland der Kauf einer Lizenz erforderlich wäre, ebenso enthält der dort verwendete Medikamenten-Katalog "RxNorm" nicht die in Deutschland zugelassenen Medikamente; die Erfassung von Datenelementen wie "Rasse" und "Ethnizität" sind in den USA verpflichtend, in Deutschland jedoch verboten.

In so fern würde Apple's Health-App in Deutschland auf keine kompatiblen KIS- oder PVS-Systeme stoßen.

...vorher muss Deutschland seine Hausaufgaben machen.

Insgesamt liegt Deutschland bei der Entwicklung national einheitlicher Standardisierungs-Konzepte für das Gesundheitswesen und der Adaption neuer Technologien wie FHIR im internationalen Vergleich weit hinten.
Selbst Vietnam und Chile sind da deutlich weiter.

Während die Politik noch zaudert, arbeitet die Deutsche FHIR-Community an Lösungen!

Auch ohne politisches Mandat interessieren sich mehr und mehr Organisationen, Hersteller und Implementierer für die Nutzung von FHIR in Deutschland. In einer offenen Community wird seit Monaten fleißig am Deutschen FHIR Implementierungsleitfaden gearbeitet.

Mitmachen ist erwünscht!

Informationen mit FHIR verfügbar machen: VONK bietet die Komplett-Lösung incl. Zugriffskontrolle

Gemeinsam mit unseren Partnern von fire.ly bieten wir mit Vonk einen vollständigen FHIR-Server an, der als FHIR-Fassade in Verbindung mit einer proprietären Datenbank implementiert werden kann aber auch FHIR-Ressourcen jeglicher Form entgegennehmen, validieren und nativ in einer eigenen Datenbank speichern kann.

Danach stellt Vonk die so gespeicherten Informationen über die FHIR-API für Dritt-Applikationen zur Verfügung.

Datenzugriff auf KIS/PVS? Nur per Export-Schnittstelle!

Stellen Sie sich also vor, Sie möchten Patientendaten, die in Ihrem Krankenhaus- oder Praxis-Informationssystem (KIS) erfasst wurden, einer App zur Verfügung stellen.
Ein direkter Zugriff der App auf das KIS ist kaum möglich, da die wenigsten Systeme über Query-Schnittstellen verfügen. Die meisten beherrschen jedoch irgendeine Form einer Export-Schnittstelle (z.B. HL7 V2, xDT oder - worst case - CSV).

Über einen Kommunkationsserver (z.B. "Cloverleaf" der Fa. Health-Comm) können diese Informationen in FHIR-Ressourcen übersetzt und an VONK übermittelt werden.
Dort stehen Sie nun für sämtliche Web-Applikationen, mobile Apps, Clinical-Decision-Support-Systeme oder mobile Geräte, die den FHIR-Standard unterstützen, zur Verfügung.

Wichtig ist dabei natürlich die Zugriffskontrolle

Daher unterstützt VONK nun eine auf den Standards OAUTH2 und OpenIDConnect basierte Zugriffskontrolle.
VONK folgt dabei dem Authorisierungs-Modell des SMART-on-FHIR-Frameworks, das als Best-Practice in diesem Bereich gilt.

Die erforderlichen Schritte sind

1. Identifikation des Benutzers (Wer ist der Benutzer?)
2. Authentifikation (Kann er es beweisen?)
3. Autorisation (Welche Berechtigungen hat der Benutzer?)
4. Zugriffskontrolle (Welche Daten darf Vonk an einen Benutzer mit diesen Berechtigungen ausliefern?)

Die ersten beiden Schritte finden außerhalb von Vonk statt, ausgehend davon, dass der Benutzer bereits in einem Portal, einem KIS oder dem ActiveDirectory bekannt ist. Wichtig ist, dass das jeweilige System die Ausgabe von JWT Tokens unterstützt.

Welche Berechtigungen einer App gewährt werden können, ist in SMART in Form von "Scopes" definiert:
patient/*.read verleiht lesenden Zugriff auf alle Ressourcen im Zusammenhang mit dem aktuellen Patienten,
user/Observation.write erlaubt Schreibzugriff auf alle Observation-Ressourcen im Zugriff des aktuellen Benutzers.

Die Verbindung zum konkreten Patienten- oder Benutzer-Objekt, stellt die App beim Start über den sog. Launch-Context her.

Bei der Vergabe des Tokens muss das Autorisierungssystem (bspw. ActiveDirectory) diese Informationen zusammen mit dem Token übergeben.

Vonk führt die Zugriffskontrolle dann basierend auf Scope, Launch-Kontext und den in FHIR definierten Compartments aus.

Vonk kann jedoch noch mehr!

Über die in SMART definierten Launch Contexts hinaus, die stets nur den Zugriff auf einen bestimmten Patienten oder Fall zulassen, kann in Vonk der Kontext auch über ein beliebiges Patienten-Attribut hergestellt werden, z.B. der Versicherung oder dem Zuweiser, wie es für die Implementierung von Portal-Systemen erforderlich sein kann.

Ausprobieren kann man Vonk online oder offline, sogar mit eigenem Identity-Server

Mehr Informationen:
http://www.gefyra.de/p/vonk.html
https://blog.fire.ly/2018/02/26/access-control-in-vonk/
https://fire.ly/vonk

FHIR Release 4 (normativ) geht in die Abstimmung

Aktuell durchläuft FHIR das erste HL7-Abstimmungsverfahren (Ballot) in seiner Geschichte, bei dem Inhalte als "normativ" abgestimmt werden. Noch besteht die Möglichkeit, auf diese Inhalte einzuwirken.

Ballot Status

Für das Ballot haben sämtliche Inhalte der Spezifikation einen "Ballot Status" erhalten:

• Normative: Inhalte, die als normativ in die Abstimmung gehen. Werden Sie angenommen, können keine inkompatiblen Änderungen mehr vorgenommen werden.
• Trial Use: Inhalte, die aktuell das FHIR maturity Model durchlaufen. Sobald sie ausreichend getestet sind, werden Sie in einer späteren Version als normativ ballotiert.
• Informative: Inhalte, die generelle Informationen enthalten und keinen Bezug zur Konformität eines Systems zum Standard haben.
• Draft: Inhalte, die erst kürzlich hinzugefügt wurden und nur zur allgemeinen Kenntnisnahme publiziert wurden, aber nicht formal zur Abstimmung stehen.
• External: Inhalte, die von anderen Quellen (HL7 V2/3, DICOM...) stammen und nicht zur Abstimmung stehen

Einige normative Ressourcen können einzelne Elemente enthalten, die als "Trial Use" gekennzeichnet wurden, da diese im Gegensatz zum Rest der Ressource noch nicht ausreichend getestet wurden. Dazu würde Patient.animal zählen, wenn es nicht kurz vor Redaktionsschluss komplett aus der Patient-Ressource in eine veterinärmedizinische Extension verbannt worden wäre.

Bundle.signature ist ein weiteres Beispiel.

Ballot Ablauf

Das Ballot-Verfahren verläuft in drei Zyklen:

1. Draft Ballot  (Dec 2017 - Jan 2018)
   Dient hauptsächlich der Qualitätskontrolle innerhalb der HL7-Arbeitsgruppen und der FHIR-Community 
2. Full FHIR Ballot (Apr 2018 - May 2018)
   Vollständiger Ballot der Normative- und Trial-Use-Pakete für R4 
3. Follow up Ballot (Aug 2018 - Sep 2018)
   Re-Ballot der Substantiellen Änderungen des normativen Paketes, die aus dem vorherigen Ballot hervorgehen.
   Re-Ballot der Ergänzungen, die dem Trial-Use-Paket hinzugefügt wurden.

Alle normativen Inhalte, die nach dem dritten Ballot nicht die erforderliche Zustimmung erhalten, werden automatisch auf "Trial Use" heruntergestuft und so in R4 veröffentlicht.

Ballot Inhalt

Folgende normativen Pakete gehen ins Ballot:

• Infrastructure
  Datentypen, Repäsentations-Formate, die RESTFul API und allgemeine Regeln zur Verwendung des Standards 
• Terminology and Conformance Terminologie- und Conformance-Infrastruktur und alle damit verbundenen Ressourcen 
• Patient
  Die Patienten-Ressource und damit zusammenhängende Inhalte 
• Observation
  Die Observation-Ressource und damit zusammenhängende Inhalte

Beteiligung am Ballot

Wer sich an der Abstimmung zu R4 beteiligen möchte, kann dies über zwei Wege tun:

über HL7 Deutschland

HL7 Deutschland e.V. verfügt als Affiliate Organisation (gemessen an der Zahl der Mitglieder) über 25 Stimmen. In der Regel werden die Kommentare der Mitglieder in Deutschland zentral gesammelt und alle Voter verweisen dann bei ihrere Stimmabgabe auf diese Kommentare.
Weitere Informationen zum Abstimmungsverfahren gibt es hier.

Speziell für das FHIR-Ballot-Verfahren werden wir die Kommentare im FHIR-Chat diskutieren und einsammeln. Wer sich also beteiligen möchte, kann dies jederzeit unter http://chat.fhir.org im Deutschen Stream tun.

über Change Requests

Wie auch außerhalb des Ballots, können Change Requests für FHIR jederzeit über das Issue-Tracking-System "GForge" eingereicht werden. Die dort eingereichten Kommentare haben zwar während des Ballots eine niedrigere Priorität als die offiziellen "Votes", werden aber dennoch von den jeweils zuständigen Arbeitsguppen abgearbeitet. Auch hier empfiehlt es sich jedoch, das Thema zuvor im Chat zu diskutieren.

Letzte Chance!

FHIR wird Ende des Jahres normativ! Das Ballot-Verfahren im April/Mai bietet die letzte Gelegenheit, Änderungswünsche an die Community heranzutragen!
Wer sich nicht beteiligt, ist automatisch verpflichtet, die betreffenden Ressourcen für immer kommentarlos hinzunehmen ;-)

#MakingCENS in Santiago de Chile

Auf Einladung des Centro Nacional en Sistemas de Información en Salud (CENS) durften wir am 8.3.2018 bei den TechTalks in Anwesenheit des neuen Gesundheitsministers Emilio Santelices über unsere Erfahrungen bei der Integration von FHIR mit anderen Standards berichten. FHIR spielt bei den Plänen für den Aufbau einer Nationalen Health IT Infrastruktur in Chile eine zentrale Rolle. Dem CENS kommt dabei die Aufgabe zu, zwischen den verschiedenen Akteuren im Chilenischen Gesundheitswesen zu koordinieren und zentrale Vorgaben im Bereich der Standardisierung zu erarbeiten.
Im ersten Schritt wird an der Implementierung eines Healthcare-Provider-Directories gearbeitet.

Wir freuen uns besonders über die vielen positiven Rückmeldungen und die große Begeisterung für FHIR in Chile!
...und darauf, die Initiative beim geplanten Connectathon im Herbst weiter unterstützen zu dürfen!

#makecens-Tweets

KBV goes FHIR

Nur wenige Tage nach der Bekanntgabe des QMS, folgt der nächste Paukenschlag:

KBV setzt auf internationalen Standard: #FHIR als Grundlage für Archiv- und Wechselschnittstellen in Praxissoftware gewählt.

— KBV (@kbv4u) 7. März 2018

Dennoch: Die Einigung auf eine technologische Basis ist nur der erste Schritt.
Nur wir es nun schaffen, alle zusammenzuarbeiten und gemeinsam kompatible, abgestimmte Profile für Deutschland zu erstellen, kann Großartiges entstehen.

Google publiziert FHIR-Tools

Vor wenigen Tagen gab Google die Veröffentlichung der FHIR Protocol Buffer Implementierung bekannt.


Protocol Buffers (protobuf) ist ein Datenformat zur Serialisierung strukturierter Daten. Für eine Vielzahl an Programmiersprachen wird eine offizielle Implementierung von Google als freie Software bereitgestellt, unter anderem C#, C++, Objective-C, Java, Python und Ruby.

Mit Protobuf erhält FHIR eine alternative Möglichkeit, Ressourcen zu serialisieren, die deutlich performanter ist als XML.

Der folgende XML-Code benötigt mindestens 69 Bytes und ca. 5.000-10.000 Nanosekunden zum parsen:

  <person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
  </person>

Im Protobuf-Binär-Format benötigt die gleiche Information nur noch 28 Bytes und ca. 100-200 Nanosekunden zum parsen.

Dies bietet der FHIR-Community spannende Möglichkeiten, FHIR in high-volume und bandbreiten-begrenzten Szenarien zu nutzen.

Google verspricht in der gleichen Ankündigung die Veröffentlichung weiterer Tools, um die Entwicklung von FHIR-basierten Applikationen für die Forschung und das Management von Gesundheitsdaten zu unterstützen.

Wir warten gespannt...