Prototypische Realisierung

Inhalt

Einführung
Nutzung von docker / docker-compose
Quelltext / Build-Artefakte

Backend Komponenten
Überblick
Reverse Proxy (nginx)
Identity Provider (keycloak)
FHIR Service (hapi-fhir)
MQTT Service (mosquitto)
MQTT Authorization Service
STUN/TURN Server (coturn)

Client Apps
Health Card Authenticator
Videokonsultation
Elektronische Einwilligung

Hinweis: Die Lösungsbausteine der prototypischen Realisierung eignen sich NICHT für den Einsatz in Umgebungen, in denen “reale” Gesundheitsdaten von Versicherten/Patienten verarbeitet werden. Ein Einsatz in entsprechenden produktiven Umgebungen erfordert eine Weiterentwicklung und Härtung der entsprechenden Bausteine. Anregungen, welche Aspekte im Rahmen einer Weiterentwicklung berücksichtigt werden sollten, finden sich in den unten stehenden Abschnitten. Die Dokumentation zur Beschreibung der prototypischen Realisierung trifft ferner keine Festlegung bezüglich zusätzlich benötigter Infrastrukturkomponenten (z.B. Firewalls) und deren korrekter Konfiguration.

Einführung

Nutzung von docker / docker-compose

Alle Bausteine der prototypischen Realisierung werden in Form von docker Containern realisiert. Dieser Ansatz ermöglicht ein einfaches Deployment in verschiedenen Betriebsumgebungen, angefangen von Entwicklerarbeitsplätzen, über klassische Server im Rechenzentrum bis hin zu modernen Cloudinfrastrukturen. Weiterführende Informationen zu docker finden sich unter https://www.docker.com/. Für die Orchestrierung der verschiedenen Container wird docker-compose genutzt.

Quelltext / Build-Artefakte

Der Quelltext der entwickelten Komponenten sowie alle weiteren Artefakte, die für den Aufbau einer lauffähigen Umgebung benötigt werden (Beispielkonfiguration, build und deployment Skripte für docker etc.) sind nach Projektabschluss im git-Repository des Fraunhofer FOKUS zu finden. Eine Übersicht aller verfügbaren Artefakte findet sich hier.

Komponenten

Die nachfolgenden Abschnitte beschreiben die konkrete Realisierung der durch die technische Architektur vorgegebenen Lösungskomponenten. Die Abbildung der jeweiligen Komponenten bzw. deren funktionaler Bestandteile erfolgt dabei über separate Lösungsbausteine, die als individuelle docker-Container realisiert werden.

Überblick

Die folgende Abbildung bietet einen Überblick über die für die prototypische Realisierung genutzten Lösungsbausteine:

Prototypische Realisierung - Überblick

Jedes Rechteck repräsentiert einen docker Container und besteht aus Angaben zum Containernamen, zur genutzten Software (Angabe in eckigen Klammern), zum Port, über den Dienste für andere Container im selben logischen Netz bereitgestellt werden sowie zum Port über den der entsprechende Dienst über das Netzwerkinterface des Hosts erreicht werden kann (fett gedruckt). Die einzelnen Containern sind dabei verschiedenen logischen Schichten zugeordnet:

Reverse Proxy (nginx)

Für die Umsetzung der Reverse Proxy Funktionalität wird nginx verwendet. Die Quellen und Dokumentation werden unter einer BSD-ähnlichen Lizenz veröffentlicht. Eine kostenfreie Nutzung im kommerziellen Umfeld ist problemlos möglich.

Ausgestaltung

Prototypische Realisierung - Reverse Proxy

Der Reverse Proxy stellt zwei verschiedene Ports bereit, an denen jeweils TLS-Verbindungen terminiert werden können:

Während der TCP-basierte Datenverkehr auf Port 8883 nach der Entschlüsselung direkt weiter an den mqtt Container gestreamt wird, erfolgt für den Datenverkehr auf Port 443 eine Verarbeitung. Diese Verarbeitung beschränkt sich primär auf die Funktionalität des URL-basierten Routing des eingehenden Datenverkehrs. In diesem Zusammenhang stellt der Dienst sicher, dass ausschließlich Datenverkehr für bekannte Pfade (vgl. Abbildung) an den Identity Provider bzw. den FHIR Store weitergeleitet wird. Darüber hinaus erweitert der Reverse Proxy den http Header um benötigte Attribute (z.B. X-Real-IP, X-Forwarded-For).

Änderungen am Quelltext der nginx-Software wurden für das Projekt nicht vorgenommen. Die benötigte Funktionalität lässt sich allein über die Konfiguration der Software umsetzen.

Konfigurierbarkeit

Um die Lauffähigkeit der Lösung in verschiedenen Umgebungen sicherzustellen, ist es erforderlich Anpassungen an der nginx Konfiguration vorzunehmen. Die entsprechenden Änderungen können in der aktuellen Version der Umsetzung nicht ausschließlich über die Konfiguration des Containers (z.B. über Umgebungsvariablen) erfolgen. Somit bleibt es bis auf Weiteres erforderlich, bestimmte Änderungen direkt im Dateisystem des Images vorzunehmen oder über Volumes dem jeweiligen Container bereitzustellen. Für ein Deployment besonders wichtige Konfigurationsparameter sind:

Detaillierte Informationen zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/reverse-proxy.

Weiterentwicklungsmöglichkeiten
Identity Provider (Keycloak)

Für die Realisierung der Identity Provider Funktionalität kommt eine speziell angepasste Version von keycloak (Version 4.5) zum Einsatz, welche durch das Projekt um einen zusätzlichen Authentifizierungsmechanismus erweitert wurde und eine leicht veränderte OIDC-Token-Ausgestaltung umsetzt. Der keycloak Quelltext steht unter der Apache Licence 2.0 bereit und kann problemlos auch im kommerziellen Einsatz kostenfrei genutzt werden.

Ausgestaltung

Prototypische Realisierung - Identity Provider

Der Identity Provider stellt einen Port für die Kommunikation über das HTTP-Protokoll bereit:

Nutzung der Authentication SPI

Die Architektur des keycloak Servers ermöglicht eine einfache Erweiterbarkeit der bereitgestellten Funktionalität über spezielle Service Provider Interfaces (SPI). Zur Umsetzung der beschriebenen Authentifizierungsfunktionalität wurde das von keycloak bereitgestellte Authentication SPI genutzt, um ein Plugin (keycloak-authenticator) zu entwickeln, welches insbesondere die initiale Nutzerregistrierung (inkl. Smartcard-basierter Authentisierung) sowie die Keystore-basierte Authentisierung serverseitig umsetzt. Die entsprechende Funktionalität wird weitestgehend innerhalb der Klasse de.fraunhofer.fokus.ehealth.ask.keycloak.authenticator.AskAuthenticator realisiert.

Detaillierte Informationen zum Kompilieren der Software sowie zum Einbinden in den keycloak Identity Provider finden sich im Software Repository des Projektes: /egav/keycloak-authenticator.

Anpassung am keycloak Quelltext

In Version 4.5.0 des keycloak Servers werden bestimmte - für die Umsetzung der beschriebenen Szenarien jedoch benötigte - Funktionen nicht unterstützt. Insbesondere das von den OpenID Connect Spezifikationen als optional deklarierte amr-Attribut (Authentication Method Reference) wird derzeit nicht in die ausgestellten OIDC Token eingebettet. Um dieses Problem zu lösen, wurden Anpassungen am keycloak Quelltext vorgenommen. Folgende Module bzw. Klassen sind von den Änderungen betroffen:

Der Quelltext zum Kompilieren der benötigten Softwarekomponenten findet sich im Software Repository des Projektes: /egav/keycloak-server.

Konfigurierbarkeit

Das Projekt bietet die Möglichkeit, den keycloak-Server während des Starts des docker container umfassend zu konfigurieren. Dazu wird eine zuvor erzeugte und im container-Image enthaltene Konfigurationsdatei geladen, die alle relevanten Informationen zur Erstellung des benötigten Realms und der entsprechenden Realm-Konfiguration (clients etc.) enthält. Darüber hinaus bietet das Projekt die Möglichkeit wesentliche Parameter des keycloak Identity Providers über die Umgebungsvariablen des Docker Conatainers zu steuern. Zu den genutzten Variablen gehören:

Detaillierte Informationen zum Kompilieren der benötigten Softwarekomponenten sowie zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/keycloak.

Hinweis: Leider können aufgrund eines Fehlers nicht alle Parameter der keycloak-Konfiguration automatisch gesetzt werden. Nach dem ersten Starten des Containers ist das Setzen des neu hinzugefügten Authentication Flows zu den einzelnen Clients zwingend erforderlich.

Weiterentwicklungsmöglichkeiten
FHIR Service (hapi-fhir)

Für die Realisierung des Dienstes wird eine angepasste Version des HAPI FHIR JPA Server genutzt. Die Lösung steht unter der Apache Licence 2.0, welche eine kommerzielle Nutzung grundsätzlich ermöglicht. Zur Realisierung der benötigten Authentifizierungs- und Autorisierungsfunktionalität sowie zur Integration in die Gesamtinfrastruktur wurde zusätzlicher Quellcode entwickelt.

Ausgestaltung

Prototypische Realisierung - FHIR Server

Der FHIR Service stellt einen Port für die Kommunikation über das MQTT-Protokoll bereit:

Die gewählte Lösung bietet Erweiterungsmechanismen an, über welche zusätzliche Funktionalität implementiert werden kann. Der für die Anpassung am häufigsten gewählte Mechanismus ist die Erweiterung des InterceptorAdapter welcher es erlaubt, in die Verarbeitung von ein- und ausgehenden Nachrichten einzugreifen. Folgende Interceptor werden durch die prototypische Lösung implementiert:

Konfigurierbarkeit

Das Projekt bietet die Möglichkeit wesentliche Parameter des FHIR Servers über die Umgebungsvariablen des Docker Conatainers zu steuern. Dazu gehören:

Detaillierte Informationen zum Kompilieren des Quelltextes sowie zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/fhir-server.

Weiterentwicklungsmöglichkeiten
MQTT Service (mosquitto)

Für die Realisierung der benötigten MQTT-Funktionalität wird mosquitto verwendet. Die Lösung steht unter einer EPL/EDL-Lizenz. Eine kostenfreie Nutzung im kommerziellen Umfeld ist somit problemlos möglich. Zur Realisierung der benötigten Authentifizierungs- und Autorisierungsfunktionalität wurde der mosquitto-Quelltext zusammen mit einem speziellen Authentication-Plugin (3-Clause BSD License) direkt aus dem Quelltext gebaut.

Ausgestaltung

Prototypische Realisierung - mosquitto

Der MQTT Service stellt einen Port für die Kommunikation über das MQTT-Protokoll bereit:

mosquitto erlaubt es durch die Bereitstellung des Quelltexts eigene, weiterführende Funktionalität in die Software zu implementieren. Für die Realisierung der Authentifizierungs- und Autorisierungsfunktionalität greift das Projekt auf das mosquitto-auth-plugin zurück, welches in der Lage ist, sich mit verschiedenen Backend-Systemen zu verbinden. Dazu gehören u.a. LDAP, MongoDB aber auch spezielle Web Service, die eine ganz bestimmte API implementieren. Das AsK-Projekt greift nutzt den letztgenannten Ansatz und implementiert einen Java-basierten Dienst, der die entsprechende API umsetzt (Details finden sich hier). Auf diesen externalisierten Sicherheitsdienst wird durch das Plugin per http zugegriffen.

Konfigurierbarkeit

Die prototypische Umsetzung bietet derzeit keine Möglichkeit über die Umgebungsvariablen des docker Containers die Konfiguration des Dienstes zu verändern. Alle Parameter sind in verschiedenen Konfigurationsdateien enthalten und werden während der Erstellung des docker Images fest hinterlegt. Anpassungsmöglichkeiten ergeben sich in kleinem Umfang über die Nutzung von contaner volumes. Detaillierte Informationen zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/mosquitto-build.

Weiterentwicklungsmöglichkeiten
MQTT Authentication/Authorization Service

Für die Realisierung des Authentication-/Authorization Backends wird eine durch Fraunhofer FOKUS entwickelte Java-Anwendung genutzt, die unter einer CC BY 4.0 Lizenz steht.

Ausgestaltung

Prototypische Realisierung - mosquitto-acs Der Dienst stellt einen Port für die Kommunikation über das HTTP-Protokoll bereit:

Folgende Endpunktadressen stehen für den Aufruf durch den MQTT Service bereit:

Eine vollständige Beschreibung des Interface findet sich in Form einer OpenAPI-Beschreibung im Software Repository des Projektes: /egav/mosquitto-acs.

Konfigurierbarkeit

Das Projekt bietet die Möglichkeit wesentliche Parameter des MQTT Authentication/Authorization Service über die Umgebungsvariablen des Docker Conatainers zu steuern. Dazu gehören:

Detaillierte Informationen zum Kompilieren des Quelltexts sowie zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/mosquitto-acs.

Weiterentwicklungsmöglichkeiten
STUN/TURN Server (coturn)

Für die Realisierung des STUN/TURN Servers wird coturn genutzt. Die Software steht unter einer 3-Clause BSD Lizenz und kann im komerziellen Umfeld problemlos genutzt werden. Im Rahmen der Umsetzung wurde die Software lediglich konfiguriert und in einem docker image verpackt. Anpassungen am Quellcode wurden hingegen nicht vorgenommen.

Ausgestaltung

Prototypische Realisierung - coturn

Der Dienst stellt die NAT-Traversal Funktionalität über verschiedene Ports bereit:

Konfigurierbarkeit

Das Projekt bietet die Möglichkeit wesentliche Parameter des STUN/TURN Servers über die Umgebungsvariablen des Docker Conatainers zu steuern. Dazu gehören:

Detaillierte Informationen zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /egav/coturn.

Client Apps

Die beschriebenen Backend Komponenten bilden die Basis für die Umsetzung der erarbeiteten Anwendungsfälle. Ohne die Implementierung von speziell auf diese Komponenten abgestimmter Clientfunktionalität ist dennoch keiner der beschriebenen Use Cases umsetzbar. Die folgenden Abschnitte geben einen Überblick über die clientseitig - in Form von Apps - implementierte Funktionalität sowie deren konkrete Umsetzung auf der Android-Plattform.

Entsprechend der Unterteilung der Anwendungsfälle in die Bereiche “übergreifend”, “Elektronische Einwilligung” und “Videokonsultation” wird die benötigte Funktionalität in Form von verschiedenen Apps umgesetzt:

Die für die Versicherten erstellten Versionen der Videokonsultations- und der Einwilligungs-App setzten das Vorhandensein der Health Card Authenticator App auf dem selben Mobilgerät voraus. Für Leistungserbringer gilt diese Anforderung für die prototypische Realisierung nicht, da hier auf Grund des begrenzten Projektscopes auf die Implementierung entsprechender Funktionalität verzichtet wurde.

Health Card Authenticator App (HCA App)

Für die Realisierung der benötigten Authentifizierungsfunktionalität wurde im Rahmen des Projektes eine App für die Android-Plattform entwickelt. Die App baut dabei auf einer Vielzahl von Biblitheken und Referenzimplementierungen auf. Dazu gehören neben vielen von google für Android bereitgestellten Basisbibliotheken u.a.:

Hinweis: Eine vollständige Übersicht der verwendeten Bibliotheken ergibt sich aus den im git Repository enthaltenen gradle files.

Grundlegende Designentscheidungen

Die Grundidee hinter der Entwicklung der Health Card Authenticator App (HCA App) ist die angestrebte Externalisierung von Authentifizierungsfunktionalität aus beliebigen Gesundheits-Apps. Die HCA App kapselt dabei alle für die Ansteuerung der Gesundheitskarte sowie für die Ansteuerung des Authentfizierungsbackends (Identity Provider) notwendigen Funktionen und stellt standardisierte Authentifizierungsnachweise über dokumentierte Schnittstellen bereit. Das hinter dieser Zielsetzung stehende Szenario ist nicht spezifisch für die eHealth-Domäne. Auch in anderen Domänen gibt es die Notwendigkeit, Nutzer über standardisierte (ggf. Domänen-spezifische) Mechanismen zu authentfizieren und diese Funktionalität mehreren Apps zur Verfügung zu stellen. Aus diesem Grund überrascht es auch nicht, dass Android eine spezielle API anbietet, um entsprechende Szenarien umzusetzen: android.account API - Die HCA App greift auf diese API zurück und implementiert einen sogenannten AccountAuthenticator, über den andere Apps die eGK-basierte Authentisierungsfunktionalität über einen einheitlichen Weg nutzen können.

Mit Nutzung der entsprechenden API einher geht die Möglichkeit mehrere sogenannte “Accounts” bzw. “Konten” zu pflegen, die jeweils dazu genutzt werden können, Authentisierungsfunktionalität für einen bestimmten Versicherten umzusetzen. In der Folge besteht die Möglichkeit auf einem Endgerät die Gesundheitskarten von mehreren Versicherten ansteuern zu können. Der Zugriff auf diese Accounts kann theoretisch direkt über den Start der HCA App erfolgen oder aber auch direkt über die durch Android in den Einstellungen angebotenen Menüpunkt “Konten”.

Prototypische Realisierung - Health Card Authenticator - Nutzung mehrerer Konten

Ausgestaltung

Die vorliegenden Konzepte unterscheiden für den anwendungsübergreifenden Bereich zwischen vier verschiedenen Anwendungsfällen:

Die folgenden Abschnitte beschreiben, wie diese Anwendungsfälle über das User Interface der HCA App umgesetzt werden und welche Abläufe im Hintergrund stattfinden.

Account anlegen

Wie bereits im Abschnitt zu den grundlegenden Designentscheidungen beschrieben, wird die Android Account API als Blaupause für die Umsetzung der benötigten Funktionalität verwendet. Die erarbeitete Lösung sieht vor, dass das von der API vorgesehenen Konstrukt des Accounts/Kontos für die Repräsentation der Versichertenidentität genutzt wird. Ein Konto repräsentiert somit die digitale Identität eines Versicherten. In der Folge ist jedem Konto genau eine eGK zugeordnet.

Die Anlage eines Kontos erfolgt entweder direkt über die Android Einstellungen oder im Zuge des erstmaligen Aufrufs der HCA App aus einer beliebigen Gesundheits App heraus. Die folgenden Screenshots zeigen die Anlage eines Kontos über die Android Konto-Einstellungen:

Prototypische Realisierung - Health Card Authenticator - Account anlegen

Nach Drücken des “Konto hinzufügen” Button (obere Reihe - 1ter Screenshot) wird eine Liste aller unterstützen Authentisierungslösungen, die die Account API nutzen, angezeigt. Durch die Installation der HCA App findet sich hier auch der Eintrag “AsK Authenticator” (obere Reihe - 2ter Screenshot). Sobald dieser Eintrag ausgewählt wird, startet der eigentliche Anlageprozess:

Die für den Nutzer aus wenigen Dialogen und Arbeitsschritten bestehende Registrierung ist bezüglich der Abläufe im Hintergrund dennoch recht komplex. Die folgenden Absätze beleuchten die entsprechenden Vorgänge im Details.

Prototypische Realisierung - Health Card Authenticator - Account anlegen

Beschreibung:

Hinweis: Details zu den zwischen HCA-App und Identity Provider ausgetauschten Nachrichten finden sich in der technischen Architektur.

Gesundheits-App autorisieren

Grundsätzlich könnten beliebige Apps den Account Mechanismus benutzen und eine eGK-basierte Authentifizierung anstoßen. Um einen Missbrauch zu unterbinden, sieht die HCA App die explizite Autorisierung (AF-UE-02) einer jeden erstmalig zugreifenden App durch den Nutzer des mobilen Endgerätes vor:

Prototypische Realisierung - Health Card Authenticator - Gesundheits App autorisieren

Im Rahmen der erstmaligen App-Nutzung (hier am Beispiel der Videokonsultations-App dargestellt) wird der Nutzer aufgefordert (2ter und 3ter Screenshot), zu entscheiden, mit welchem der AsK-Konten die App verbunden werden soll. Ist die Auswahl getroffen, muss er für das gewählte Konto einmalig den Zugriff autorisieren (4ter Screenshot). Erst nach erfolgter Autorisierung ist die Gesundheits-App in der Lage, standardisierte Authentifizierungsnachweise über die HCA-App anzufordern.

Die Prozesse im Hintergrund stellen sich wie folgt dar:

Hinweis: Die App-Autorisierung ist sehr eng mit dem Durchführen eines Authentifizierungsvorganges verknüpft. Die Abläufe werden daher an dieser Stelle ineinander eingebettet dargestellt

Prototypische Realisierung - Health Card Authenticator - Gesundheits-App autorisieren

Beschreibung:

Account löschen

Mit dem Löschen des Accounts/Kontos schließt sich der Lebenszyklus:

Prototypische Realisierung - Health Card Authenticator - Account löschen

Über die Android Konteneinstellung (1ter Screenshot) wählt der Nutzer das zu löschende Konto aus. Durch Betätigen des “Konto entfernen” Button wird das Entfernen initiiert (2ter Screenshot). Bestätigt der Nutzer das Entfernen nochmals (3ter Screenshot), verschwindet der Account vom Endgerät und wird nicht mehr in der Kontenliste (4ter Screenshot) angezeigt.

Die Prozesse im Hintergrund erfordern in der aktuellen Umsetzung keine Funktionalität, die durch die HCA-App implementiert werden müsste.

Steuerung des Authensierungsablaufes Die Spezifikationen des Projektes machen es erforderlich, dass der Authentisierungsablauf hinsichtlich verschiedener Aspekte gesteuert werden können muss. Zu diesen Aspekten gehören beispielsweise der Typ des zu erstellenden Token, die Art des zu verwendenden Authentisierungsmechanismus oder auch die Auswahl der Anwendung für welche ein Token ausgestellt werden soll. Die Steuerung übernimmt in diesem Zusammenhang jeweils die Gesundheits-App aus deren Anwendungsfällen sich die konkreten Anforderungen an den Authentifizierungsablauf ableiten.

Wie in den weiter oben beschrieben Abläufen zu sehen ist, kann die getAuthToken() Methode des AccountManager genutzt werden, um aus einer Gesundheits-App heraus benötigte Sicherheitstoken über die HCA-App zu beschaffen. Folgende Parameter sind in diesem Zusammenhang von besonderem Interesse:

Folgende Typen von authToken werden unterschieden:

Folgende Optionen, die als Werteschlüssel (key) des option Bundle kodiert werden, werden unterstützt:

Konfigurierbarkeit

Die App bietet - über die Veränderung von Konfigurationsdateien - die Möglichkeit, wesentliche Parameter anzupassen. Dazu gehören:

Detaillierte Informationen zur Konfiguration finden sich im Software Repository des Projektes: /egav/keycloak-authenticator-android.

Weiterentwicklungsmöglichkeiten
Videokonsultations-App

Für die Realisierung der benötigten Videokonsultations-Funktionalität wurde im Rahmen des Projektes eine App für die Android-Plattform entwickelt. Die App baut dabei auf einer Vielzahl von Biblitheken und Referenzimplementierungen auf. Dazu gehören neben vielen von google für Android bereitgestelltenn Basisbibliotheken u.a.:

Hinweis: Eine vollständige Übersicht ergibt sich aus den im git Repository enthaltenen gradle files.

Ausgestaltung

Dem im Abschnitt Health Card Authenticator App beschriebenen Muster folgend, implementiert die Videokonsultations-App primär die Fachlichkeit der Anwendungsfälle. Funktionalität, die mit der Authentisierung des Nutzers im Zusammenhang steht, wird über die beschriebene Schnittstelle lediglich in die App eingebunden und dort nutzbar gemacht.

Die nachfolgenden Abschnitte stellen die durch die App umgesetzte Funktionalität dar. In diesem Zusammenhang wird sowohl gezeigt, wie die Abbildung der beschriebenen Anwendungsfälle im User Interface erfolgt, als auch welche Kommunikation mit den entsprechenden Backend-Diensten stattfindet.

Verwaltung von Videokonsultationsangeboten

Einen wesentlichen funktionalen Block stellt die Verwaltung der einzelnen Videokonsultationsangebote dar. Innerhalb dieses Blocks werden die folgenden Anwendungsfälle umgesetzt:

Die folgende Abbildung zeigt die Umsetzung der ersten drei Anwendungsfälle (AF-VK-01 bis AF-VK-03). Ausgehend von einer leeren Favouritenliste (2ter Screenshot - AF-VK-03) hat der Nutzer die Möglichkeit nach verfügbaren Angeboten zu suchen (3ter Screenshot - AF-VK-01) und diese zur Favouritenliste hinzuzufügen (4ter Screenshot - AF-VK-02). Ist dies geschehen erfolgt die Anzeige des Favouriten in der Übersicht (5ter Screenshot - AF-VK-03).

Prototypische Realisierung - Videokonsultation - Verwaltung von Videokonsultationsangeboten

Darüber hinaus bietet sich dem Nutzer die Möglichkeit favourisierte Angebote von der Liste zu entfernen (2ter + 3ter Screenshot - AF-VK-04)

Prototypische Realisierung - Videokonsultation - Verwaltung von Videokonsultationsangeboten

Die Funktionalität wird im Hintergrund primär über die Kommunikation mit dem FHIR-Server abgehandelt, der die entsprechenden FHIR-Ressourcen (HealthcareService und Organization) verwaltet:

Prototypische Realisierung - Videokonsultation - Videokonsultationsangebote suchen

Die Speicherung der Favouritenliste erfolgt nicht im Backend. Die App speichert die ensprechenden Angebotsreferenzen innerhalb der App und nutzt diese, um die Angebotsdetails bei Bedarf vom Server zu laden. Das Löschen eines Favouriten macht es somit nicht erforderlich ein Aufruf gegen den FHIR-Server zu starten. Beispiel-Request/Response-Nachrichten können hier heruntergeladen werden.

Termine verwalten

Den zweiten funktionalen Block stellt die Terminverwaltung dar. Hierbei werden folgende Anwendungsfälle adressiert:

Die Suche nach verfügbaren Terminen wird über die Auswahl eines konkreten Videokonsultationsangebotes aus der Favouritenliste initiiert (2ter Screenshot). In der Übersicht werden nun alle für dieses Angebot noch verfügbaren, d.h. bisher noch nicht gebuchten Terminmöglickeiten zur Anzeige gebracht (3ter Screenshot - AF-VK-05). Durch das Selektieren einer Terminmöglichkeit (3ter Screenshot) kann der Termin nun verbindlich gebucht werden (4ter Screenshot - AF-VK-06. Sobald die Registrierung im Backend erfolgreich war, wird der gebuchte Termin in der Terminübersicht dargestellt (5ter Screenshot - AF-VK-07).

Prototypische Realisierung - Videokonsultation - Termine verwalten

Das Stornieren eines Termins wird über die Terminübersicht initiiert. Durch Auswahl eines gebuchten Termins (1ter Screenshot) ergibt sich in dessen Detaildarstellung (2ter Screeshot) die Möglichkeit der Stornierung (AF-VK-08). Wird der entsprechende Button durch den Nutzer gedrückt, erfolgt durch Aufrufe im Backend die Stornierung des Termins bzw. die Freigabe der Terminmöglichkeit für andere Nutzer. Der Termin wird nun auch nicht mehr in der Terminübersicht angezeigt (3ter Screenshot - AF-VK-05).

Prototypische Realisierung - Videokonsultation - Termine verwalten

Die Umsetzung der dargestellten Funktionalität erfolgt auch für diesen funktionalen Block im Zusammenspiel mit dem FHIR-Server. Dabei fällt den folgenden FHIR-Ressourcen eine besodnere Rolle zu:

Die folgenden Sequenzdiagramme dienen der Darstellung der Anfragen, die durch die Videokonsultations-App gegen den FHIR-Server gestellt werden müssen, um die einzelnen Anwendungsfälle umzusetzen:

Verfügbare Termine eines Videokonsultationsangebotes anzeigen:

Prototypische Realisierung - Videokonsultation - Verfügbare Termine eines Videokonsultationsangebotes anzeigen Beispiel-Request/Response-Nachrichten können hier heruntergeladen werden.

Verfügbaren Termin eines Videokonsultationsangebotes buchen:

Prototypische Realisierung - Videokonsultation - Verfügbaren Termin eines Videokonsultationsangebotes buchen Beispiel-Request/Response-Nachrichten können hier heruntergeladen werden.

Gebuchte Termine anzeigen:

Prototypische Realisierung - Videokonsultation - Gebuchte Termine anzeigen Beispiel-Request/Response-Nachrichten können hier heruntergeladen werden.

Gebuchten Termin stornieren:

Prototypische Realisierung - Videokonsultation - Gebuchten Termin stornieren Beispiel-Request/Response-Nachrichten können hier heruntergeladen werden.

Videokonsultation durchführen

Den dritten und letzen funktionalen Bock stellt die eigentliche Durchführung der Videokonsultation dar. Folgende Anwendungsfälle werden in diesem Zusammenhang adressiert:

Der Start des Verbindungsaufbaus (AF-VK-09) wird über die Selektion eines gebuchten Termins (1ter Screenshot) und anschließendem Drücken des Buttons “Videoverbindung starten” (2te Screenshot) initiiert. Sobald auch die Gegenseite (Leistungserbringer) den Start der Verbindung bestätigt, wird die Versicherte aufgefordert, ihre PIN einzugeben (3ter Screenshot) und anschließend die eGK an die Rückseite des mobilen Endgerätes zu halten (4ter Screenshot). War die Authentifizierung durch den Identity Provider sowie die Gegenseite erfolgreich wird die Verbindung gestartet (5ter Screenshot). Eine detaillierte Beschreibung der hinter dieser Funktionalität stehenden Abläufe (Signallisierung, Schlüsselaushandlung, Authentifizierung etc.) kann der technischen Spezifikation entnommen werden.

Prototypische Realisierung - Videokonsultation - Videokonsultation durchführen

Die App bietet die Möglichkeit nach erfolgreichem Verbindungsaufbau einzelne Verbindungsparameter zu konfigurieren. Ein Druck auf das Kamerasymbol (1ter Screenshot) ermöglicht das Umschalten zwischen der Kamera auf der Vorder- und Rückseite des mobilen Gerätes (AF-VK-12). Die Gegenseite empfängt nun ein entsprechend perspektivisch verändertes Bild (vgl. 2ter Screenshot unten rechts). Ein Druck auf das Mikrofonsymbol (2ter Screenshot) unterbindet die Übertragung des Audiosignals an die Gegenseite (AF-VK-11). Das Berühren des roten Telefonhöhres (3ter Screenshot) beendet die Audio-/Videokonferenz (AF-VK-10)

Prototypische Realisierung - Videokonsultation - Videokonsultation durchführen

Konfigurierbarkeit

Die App bietet - über die Veränderung von Konfigurationsdateien - die Möglichkeit, wesentliche Parameter anzupassen. Dazu gehören:

Die Festlegung der Endpunktadressen anderer benötigter Dienste (z.B. MQTT Service oder STUN/TURN Server) erfolgt nicht über die Konfigurationsdateien der App selbst, sondern wird als Erweiterungen der für das Projekt profilierten Appointment Ressource an die Anwendung übergeben. Entsprechende Änderungen dieser Parameter sind somit in der Konfiguration des FHIR Servers zu pflegen.

Detaillierte Informationen zur Konfiguration finden sich im Software Repository des Projektes: /egav/vc-patient.

Weiterentwicklungsmöglichkeiten
Einwilligungs-App

Für die Realisierung der Funktionalität für die Elektronische Einwilligung wurde im Rahmen des Projektes eine App für die Android-Plattform entwickelt. Die App baut dabei auf einer Vielzahl von Bibliotheken und Referenzimplementierungen auf. Dazu gehören neben vielen von google für Android bereitgestelltenn Basisbibliotheken u.a.:

Hinweis: Eine vollständige Übersicht ergibt sich aus den im git Repository enthaltenen gradle files.

Ausgestaltung

Dem im Abschnitt Health Card Authenticator App beschriebenen Muster folgend, implementiert die Einwilligungs-App primär die Fachlichkeit der Anwendungsfälle. Funktionalität, die mit der Authentisierung des Nutzers im Zusammenhang steht, wird über die beschriebene Schnittstelle lediglich in die App eingebunden und dort nutzbar gemacht.

Die nachfolgenden Abschnitte stellen die durch die App umgesetzte Funktionalität dar. In diesem Zusammenhang wird sowohl gezeigt, wie die Abbildung der beschriebenen Anwendungsfälle im User Interface erfolgt, als auch welche Kommunikation mit den entsprechenden Backend-Diensten stattfindet.

Verwaltung von Einwilligungspaketen

Einen wesentlichen funktionalen Block stellt die Verwaltung der einzelnen Einwilligungspakete dar. Innerhalb dieses Blocks werden die folgenden Anwendungsfälle umgesetzt:

Die folgende Abbildung zeigt die Umsetzung der beiden Anwendungsfälle (AF-EW-01 und AF-EW-02). Ausgehend von einer leeren Liste von Einwilligungspaketen hat der Nutzer die Möglichkeit ein neues Einwilligungspaket herunterzuladen (AF-EW-01). Hierzu muss der Nutzer einen (validen) QR-Code (in dem eine URN:UUID kodiert ist) abscannen (2ter Screenshot). Daraufhin wird das Einwilligungspaket heruntergeladen und erscheint in der Liste (3ter Screenshot).

Prototypische Realisierung - Elektronische Einwilligung - Verwaltung von Einwilligungen

Darüber hinaus bietet sich dem Nutzer die Möglichkeit Einwilligungspakete von der Liste zu entfernen, indem er auf ein Einwilligungspaket in der Liste lange drückt (AF-EW-02).

Die Funktionalität wird im Hintergrund primär über die Kommunikation mit dem FHIR-Server abgehandelt, der die entsprechenden FHIR-Ressource (ConsentPackageList) verwaltet:

Prototypische Realisierung - Elektronische Einwilligung - Einwilligungspaket herunterladen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Bei der FHIR-Ressource ConsentPackageList handelt es sich um eine für das Projekt profilierte List Ressource. Diese Ressource muss beim Starten des FHIR-Servers initialisiert werden. Sie beinhaltet als Einträge weitere profilierte Ressourcen, die zur Abbildung des Einwilligungverlaufes dienen:

Eine detaillierte Auflistung und Beschreibung aller profilierten Ressourcen kann im Implementierungsleitfaden eingesehen werden.

Die Informationen zum FHIR Endpunkt, die Inhalte der Aufklärungsmaterialien und eine Referenz zu dem Terminkalender für Aufklärungsgespräche werden lokal in der App gespeichert. Beim Löschen eines Einwilligungspaketes aus der Liste, werden diese lokal gehaltenen Daten gelöscht. Noch nicht abgehaltene Termine für Aufklärungsgespräche werden storniert und die entsprechenden Terminslots freigegeben (siehe hierzu Termin buchen / stornieren).

Aufklärungsmaterial einsehen / Fragen notieren

Den zweiten funktionalen Block stellt das Einsehen des Aufklärungsmaterials und das Notieren von Fragen bezüglich des Aufklärungsmaterials dar. Hierbei werden folgende Anwendungsfälle adressiert:

Die folgende Abbildung zeigt exemplarisch den Ablauf der Anwendungsfälle (AF-EW-03) und (AF-EW-06). Der Nutzer hat die Möglichkeit durch selektieren des entsprechenden Aufklärungsmaterials (2ter Screenshot) sich dessen Inhalt anzeigen (und vorlesen) zu lassen (3ter Screenshot), sowie sich dort Abschnitte, die ihm unklar sind, zu markieren (AF-EW-06). Die Speicherung der markierten Abschnitte läuft lokal auf der App ab und erfordert keinen Aufruf gegen den FHIR-Server. Erst bei erfolgter Terminbuchung für ein Aufklärungsgespräch wird aus den als unklar markierten Fragen eine QuestionnaireResponse Ressource erzeugt (siehe hierzu Termin buchen / stornieren).

Prototypische Realisierung - Elektronische Einwilligung - Aufklärungsmaterial einsehen / Fragen notieren

Die Anwendungsfälle (AF-EW-04) und (AF-EW-05) laufen entsprechend analog ab.

Aufklärungsgespräch

Den dritten funktionalen Block bildet das Aufklärungsgespräch per Videokonsultation. Hier werden die Anwendungsfälle AF-EW-07 (Fragenliste ansehen) und AF-EW-08 (Aufklärungsgespräch durchführen) realisiert. Dieser Block wird unterteilt in die folgenden Abschnitte:

Termin buchen / stornieren

Die folgende Abbildung zeigt den Vorgang der Terminbuchung für ein Aufklärungsgespräch. Hierbei wählt der Nutzer den Punkt Aufklärungsgespräch (1ter Screenshot). Im Folgende werden alle verfügbaren Termine angezeigt (2ter Screenshot). Durch das Selektieren einer Terminmöglichkeit (3ter Screenshot) kann der Termin nun verbindlich gebucht werden. Abschließend kann der Termin (optional) in den persönlichen Kalender übernommen werden (4ter Screenshot).

Prototypische Realisierung - Elektronische Einwilligung - Termin buchen

Solange das Aufklärungsgespräch noch nicht stattgefunden hat, kann der Nutzer den Termin stornieren, indem er den Punkt Aufklärungsgespräch wählt (1ter Screenshot) und in der Detaildarstellung des Termins den entsprechenden Button drückt (2ter Screenshot).

Prototypische Realisierung - Elektronische Einwilligung - Termin stornieren

Die Umsetzung der dargestellten Funktionalität erfolgt für diesen funktionalen Block im Zusammenspiel mit dem FHIR-Server. Dabei fällt den folgenden FHIR-Ressourcen eine besondere Rolle zu:

Die folgenden Sequenzdiagramme dienen der Darstellung der Anfragen, die durch die Einwilligungs-App gegen den FHIR-Server gestellt werden müssen, um die Terminbuchung bzw. Terminstornierung umzusetzen:

Verfügbare Termine anzeigen:

Prototypische Realisierung - Elektronische Einwilligung - Verfügbare Termine anzeigen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Verfügbaren Termin buchen:

Prototypische Realisierung - Elektronische Einwilligung - Verfügbaren Termin buchen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Gebuchten Termin stornieren:

Prototypische Realisierung - Elektronische Einwilligung - Gebuchten Termin stornieren

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Fragenliste ansehen

Zusätzlich zu der Einwilligungs-App für die Versicherte wurde im Zuge des Projektes eine (rudimentäre) App für den Leistungserbringer entwickelt, um insbesondere die Anwendungsfälle (AF-EW-07) und (AF-EW-09) abzudecken. Die folgende Abbildung zeigt den Ablauf des Anwendungsfalls (AF-EW-07). Zunächst bekommt der Nutzer (Leistungserbringer) eine Auflistung aller Aufklärungsgesprächstermine zu allen Einwilligungsvorgängen dargestellt (1ter Screenshot), die er nach diversen Kriterien filtern kann (2ter Screenshot). Selektiert er einen dieser Termine, gelangt er zu einer Übersicht zu diesem Termin (4ter Screenshot). Hier kann er den Punkt “Patientenfragen” wählen, um alle Abschnitte der Aufklärungsmaterialien, die der Patient als unklar makiert hat, aufgelistet zu bekommen (5ter Screenshot).

Prototypische Realisierung - Elektronische Einwilligung - Fragenliste ansehen

Das folgende Sequenzdiagramm zeigt die Anfragen, die durch die Einwilligungs-App des Leistungserbringers gegen den FHIR-Server gestellt werden müssen, um die Fragenliste einzusehen:

Prototypische Realisierung - Elektronische Einwilligung - Fragenliste ansehen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Aufklärungsgespräch durchführen

Der Start des Verbindungsaufbaus wird über die Selektion des Punktes “Aufklärungsgespräch” und anschließendem Drücken des Buttons “Videoverbindung starten” auf Seite der Versicherten aufgerufen (2ter Screenshot). Sobald die Gegenseite (Leistungserbringer) die Videoverbindung ebenfalls gestartet hat (5ter Screenshot), wird nach erfolgreicher Authentifizierung durch den Identity Provider die Videoverbindung initiiert. Eine detaillierte Beschreibung der hinter dieser Funktionalität stehenden Abläufe (Signallisierung, Schlüsselaushandlung, Authentifizierung etc.) kann der technischen Spezifikation entnommen werden.

Prototypische Realisierung - Elektronische Einwilligung - Aufklärungsgespräch durchführen

Einwilligung

Den letzten funktionalen Block bildet der Vorgang der Einwilligung selbst. In diesem Block werden folgende Anwendungsfälle umgesetzt:

Zunächst muss in der App des Leistungserbringers eine Einwilligungsvorlage erstellt werden (AF-EW-09). Hierzu wählt der Nutzer den Punkt “Einwilligung erstellen / einsehen” in der Übersicht (2ter Screenshot). Im Folgenden bekommt er eine Übersicht der Patientendaten (Name + KVNR) der Versicherten, für die die Einwilligung erstellt werden soll, dargestellt und kann einen behandelnden Arzt, sowie ein Datum für die Operation festlegen (3ter Screenshot). Durch Drücken des Buttons “Einwilligung erstellen” wird die entsprechende FHIR-Ressource (Consent) angelegt.

Prototypische Realisierung - Elektronische Einwilligung - Einwilligungsvorlage erstellen

Nach der Erstellung der Einwilligungsvorlage wird diese von der Einwilligungs-App für die Versicherten automatisch heruntergeladen (Polling) und dargestellt (1er Screenshot). Durch Betätigen des entsprechenden Buttons, kann sich die Versicherte diese Einwilligungsvorlage ansehen (AF-EW-10) (2ter Screenshot). Mit dem “Fortfahren”-Button gelangt er weiter zur Einwilligungserklärung. Hier kann der Nutzer den Einwilligungsvorgang mit dem Button “mit EGK und PIN bestätigen” initiieren (3ter Screenshot). Daraufhin wird der Versicherte aufgefordert, seinen PIN einzugeben (4ter Screenshot) und anschließend die eGK an die Rückseite des mobilen Endgerätes zu halten (5ter Screenshot). War die Authentifizierung durch den Identity Provider erfolgreich, wird der Status der Consent-Ressource entsprechend geändert und somit die Einwilligung erteilt (AF-EW-11).

Prototypische Realisierung - Elektronische Einwilligung - Einwilligungsvorlage ansehen

Die Versicherte kann sich jederzeit gemäß der Anwendungsfälle AF-EW-12 und AF-EW-13 eine bereits erteilte Einwilligung ansehen (2ter Screenshot) und hat die Möglichkeit diese wieder zurückzuziehen (3ter Screenshot).

Prototypische Realisierung - Elektronische Einwilligung - Einwilligung zurückziehen

Die folgenden Sequenzdiagramme dienen der Darstellung der Anfragen, die durch die Einwilligungs-App des Leistungserbringers und der Versicherten gegen den FHIR-Server gestellt werden müssen, um die Anwendungsfälle AF-EW-09 bis AF-EW-13 zu realisieren:

Einwilligungsvorlage erstellen

Prototypische Realisierung - Elektronische Einwilligung - Einwilligungsvorlage erstellen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Einwilligung(svorlage) ansehen

Prototypische Realisierung - Elektronische Einwilligung - Einwilligung(svorlage) ansehen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Einwilligung erteilen

Prototypische Realisierung - Elektronische Einwilligung - Einwilligung erteilen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Einwilligung zurückziehen

Prototypische Realisierung - Elektronische Einwilligung - Einwilligung zurückziehen

Eine Beispiel-Request/Response-Nachricht kann hier heruntergeladen werden.

Konfigurierbarkeit

Die App bietet - über die Veränderung von Konfigurationsdateien - die Möglichkeit, wesentliche Parameter anzupassen. Dazu gehören:

Die Festlegung der Endpunktadressen anderer benötigter Dienste (z.B. MQTT Service oder STUN/TURN Server) erfolgt nicht über die Konfigurationsdateien der App selbst, sondern wird als Erweiterungen der für das Projekt profilierten Appointment Ressource an die Anwendung übergeben. Entsprechende Änderungen dieser Parameter sind somit in der Konfiguration des FHIR Servers zu pflegen.

Detaillierte Informationen zur Konfiguration finden sich im Software Repository des Projektes: /egav/einwilligung-patient.

Weiterentwicklungsmöglichkeiten