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: TODO.

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: TODO.

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:

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: TODO.

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 Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: TODO.

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: TODO.

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 OpanAPI-Beschreibung im Software Repository des Projektes: TODO.

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 Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: TODO.

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: TODO.

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: TODO.

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: TODO.

Weiterentwicklungsmöglichkeiten
Einwilligungs-App
Ausgestaltung

TODO

Konfigurierbarkeit
Weiterentwicklungsmöglichkeiten