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