Quelltext und Dokumentation

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.

Quelltext-Repositories

Im Rahmen der prototypischen Realisierung wurde eine Vielzahl von Komponenten entwickelt und/oder angepasst. Entsprechend den Förderbedingungen des Projektes wird der Quelltext dieser Komponenten der Allgemeinheit zur Verfügung gestellt. Als Veröffentlichungs-Plattform dient dabei der Git-Repository Manager des Fraunhofer FOKUS. Folgende Git-Repositories werden bereitgestellt:

reverse-proxy - Projekt zur Umsetzung eines Reverse Proxy für die Terminierung von TLS-Verbindung sowie die Vermittlung von Traffic zum Identity Provider, FHIR Server und MQTT-Server
keycloak-server - Das Projekt beinhaltet den Keycloak Quelltext sowie alle Änderungen, die vorgenommen wurden, um eine acr/amr-Unterstützung zu realisieren. Entsprechende Änderungen vinden sich im ask_amr_support branch.
keycloak-authenticator - Das Projekt beinhaltet den Quelltext, der für die Umsetzung der serverseitigen Authentisierungsfunktionalität (keycloak Authentication SPI) benötigt wird.
keycloak - Projekt mit Binaries und Konfigurationsdateien, die für das Bauen eines lauffähigen keycloak docker image benötigt werden
fhir-server - Projekt mit Quelltext zur Umsetzung des benötigten FHIR-Servers inkl. aller Dateien zur Erstellung eines lauffähigen docker images
mosquitto-acs - Projekt mit Quelltext für einen java-basierten Access Control Service für mosquitto inkl. aller Dateien zur Erstellung eines lauffähigen docker images
mosquitto-build - Projekt mit Quelltext für mosquitto und ein mosquitto auth plugin inkl. aller Dateien zur Erstellung eines lauffähigen docker images
coturn - Projekt mit Konfigurationsdateien und Skripten zur Erstellung eines lauffähigen coturn docker images
deployment - Projekt zur Umsetzung eines kompletten Deployments des AsK Service Stack unter Nutzung von docker-compose
keycloak-authenticator-android - Projekt mit Quelltext zur Umsetzung der Authenticator App (clientseitiges Gegenstück zum keycloak-authenticator)
vc-patient - Projekt mit Quelltext zur Umsetzung der Video-Konferenz-App (Anwendung der Patienten)
vc-hcp - Projekt mit Quelltext zur Umsetzung der Video-Konferenz-App (Anwendung der Leistungserbringer)
einwilligung-patient - Projekt mit Quelltext zur Umsetzung der Einwilligungs-App (Anwendung der Patienten)
einwilligung-hcp - Projekt mit Quelltext zur Umsetzung der Einwilligungs-App (Anwendung der Leistungserbringer)

Anhand der folgenden Grafik kann eine Zuordnung der Repositories zu den im Abschnitt Prototypische Realisierung eingeführten Modell hergestellt werden:

Zuorgnung Komponenten-Repositories

Hinweis: Der Quelltext der für die Ansteuerung der NFC-eGKs benötigten Libraries ist derzeit noch nicht in den Git-Repositories enthalten. Die Verteilung erfolgt durch die gematik.

Deployment-Leitfaden

Die folgenden Abschnitte geben einen Überblick über die Schritte, die erforderlich sind, um ein lauffähiges Minimaldeployment aller benötigten Dienste und Apps zu realisieren. Detailliertere Beschreibungen der einzelenen Schritte finden sich jeweils in den referenzierten git-Projekten.

Hinweis: Es wird davon ausgegangen, dass eine angepasste Version des im deployment-Projekt bereitgestellten docker-compose files für das Aufsetzen der Lösung genutzt wird. Ist dies nicht der Fall, ergeben sich weitere Anpassungsbedarfe, die im Zusammenhang mit dieser Dokumentation jedoch nicht dargestellt werden.

A. Vorüberlegung/-bedingungen

Folgenden Vorbedingungen müssen für ein erfolgreiches Deployment erfüllt sein:

A.1 Bereitstellen von Hard- und Software

Für ein einfaches Demo-Deployment werden nur sehr geringe Anforderungen an die benötigte Hardware gestellt. In der durch das Fraunhofer FOKUS bereitgestellten Demo-Umgebung kommt ein Arbeitsplatzrechner mit Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz und 8GB Hauptspeicher zum Einsatz, wovon allerdings nur 2 GB genutzt werden. Ein Deployment auf einem üblichen Entwicklerarbeitsplatz stellt somit kein Problem dar.

Für das Deployment der Komponenten kommt docker und docker-compose zum Einsatz. Entsprechende Software muss vorab installiert werden.

A.2 Festlegen eines Hostnames

Die Deploymentkonfiguration basiert zu großen Teilen auf der Angabe eines eindeutigen Hostnames, über welchen der Server bzw. seine Dienste erreichbar sind. Der offizielle hostname für den Demo-Server des Fraunhofer FOKUS lautet ehealth-ask.fokus.fraunhofer.de. Für die zu erstellende Testumgebung muss ein entsprechender hostname neu angelegt und über DNS bekannt gemacht bzw. ein bestehender ermittelt werden.

A.3 Netztechnische Erreichbarkeit des bereitgestellten Servers

Die verschiedenen, im Deployment enthaltenen Dienste müssen über verschiedene Ports/Protokolle erreicht werden können. Eine Übersicht relevanter Ports/Protokolle bietet die Realisierungsbeschreibung. Die zum Einsatz kommenden Firewall-Systeme sollten die sich aus dieser Realisierung ableitenden Anforderungen berücksichtigen.

A.4 Beschaffen von X.509-Zertifikaten

Fast alle Verbindungen zu den Diensten des AsK-Service-Stacks werden über TLS abgesichert. Dies macht das Einspielen eines TLS-Server-Zertifikats erforderlich, das von einer CA ausgestellt wurde, die sich auf einen der Vertrauensanker in den Android-Truststores zurückführen lässt. Ein Zertifikat, das den hostname des Servers im CN oder der Subject Alternative Name Extension enthält muss beschafft werden.

A.5 Clonen aller git-Repositories

Die oben aufgelisteten Quelltext-Repositories beinhalten alle benötigten Dateien. Sie sollten vor Ausführung der einzelnen Schritte dieses Deployment-Leitfadens geclont werden, da u.U. Anpassungen an einzelnen Konfigurationsdateien erforderlich sind.

B. Anpassungsbedarfe Backend

Basierend auf den Vorüberlegungen/-bedingungen müssen folgende Anpassungen an den geclonten Projekten vorgenommen werden, um ein lauffähiges Gesamtsystem zu erhalten:

B.1 Reverse Proxy

Für den Reverse Proxy müssen (entsprechend den Anweisungen der README-Datei) die X.509-Zertifikatskette sowie das zugehörige private Schlüsselmaterial (s.o.) konfiguriert werden. Es schließt sich das beschriebene Builden des docker image an. Sofern Erstellung und Nutzung des docker image auf verschiedenen Systemen erfolgen, muss der Transfer des Images über geeignete Werkzeuge/Dienste sichergestellt werden. Die in der README-Datei beschriebene Konfiguration des Containers über Umgebungsvariablen erfolgt über das docker-compose file (siehe Abschnitt Deployment).

B.2 Identity Provider

Für das Deployment des Identity Providers kann das in der docker Registry hinterlegte docker Image (dockerhub.fokus.fraunhofer.de:5000/egav/keycloak) direkt genutzt und über den Befehl docker pull heruntergeladen werden (vgl. README.md. Alternativ übernimmt dies später der docker-compose Prozess. Die in der README-Datei beschriebene Konfiguration des Containers über Umgebungsvariablen erfolgt über das docker-compose file (siehe Abschnitt Deployment).

B.3 FHIR Server

Das docker image für den FHIR Server muss angepasst werden, um auch den Einwilligungs-Use-Case durchspielen zu können. Die README-Datei des entsprechenden git-Reositories beschreibt in den Abschnitten “Image Configuration”, “Build FHIR server (java code)” und “Build docker image” alle notwendigen Schritte. Sofern der Einwilligungs-Use-Case nicht genutzt werden soll, kann auch das pre-built image genutzt werden. Die in der README-Datei beschriebene Konfiguration des Containers über Umgebungsvariablen erfolgt über das docker-compose file (siehe Abschnitt Deployment).

B.4 MQTT Server

Für das Deployment des MQTT Servers kann das in der docker Registry hinterlegte docker image (dockerhub.fokus.fraunhofer.de:5000/egav/mosquitto-build) direkt genutzt und über den Befehl docker pull heruntergeladen werden (vgl. README.md. Alternativ übernimmt dies später der docker-compose Prozess.

B.5 MQTT Access Control Service

Auch der zum MQTT Server zugehörige Access Control Service kann direkt auf Grundlage des in der docker registry enthaltenen image (dockerhub.fokus.fraunhofer.de:5000/egav/mosquitto-acs) deployt werden (vgl. README.md. Die in der README-Datei beschriebene Konfiguration des Containers über Umgebungsvariablen erfolgt über das docker-compose file (siehe Abschnitt Deployment).

B.6 STUN/TURN Server

Eine Anpassung des docker image ist auch für diese Komponente nicht erforderlich. Der STUN/TURN Server kann direkt auf Grundlage des in der docker registry enthaltenen image (dockerhub.fokus.fraunhofer.de:5000/egav/coturn) deployt werden (vgl. README.md. Die in der README-Datei beschriebene Konfiguration des Containers über Umgebungsvariablen erfolgt über das docker-compose file (siehe Abschnitt Deployment).

B.7 Deployment

Große Teile der Konfiguration des AsK Service Stack erfolgen über die Anpassung der im deployment Repository enthaltenen docker-compose Konfigurationsdatei (fullstack.yaml). Welche Parameter anzupassen sind und mit welchem Kommando der Service Stack gestartet wird, kann der README-Datei des Projektes entnommen werden.

C. Anpassungsbedarfe Client-Apps

Die im Backend vorgenommen Änderungen, insbesondere bezüglich des konfigurierten hostnames, müssen nun auch in den Client-Apps nachgezogen werden:

C.1 Videokonferenz-App (Patient)

Entsprechend der Hinweise der offiziellen Dokumentation (Abschnitt Voraussetzungen) muss die Endpunktadresse des FHIR-Servers korrekt konfiguriert werden. Dies erfolgt über eine Konfigurationsdatei. Detaillierte Hinweise finden sich in der README-Datei des Projektes.

C.2 Videokonferenz-App (Leistungserbringer)

C.3 Einwilligungs-App (Patient)

Entsprechend der Hinweise der offiziellen Dokumentation (Abschnitt Voraussetzungen) muss die Endpunktadresse des FHIR-Servers korrekt konfiguriert werden. Dies erfolgt direkt in der App. Detaillierte Hinweise finden sich in der README-Datei des Projektes.

C.4 Einwilligungs-App (Leistungserbringer)

Entsprechend der Hinweise der offiziellen Dokumentation (Abschnitt Voraussetzungen) muss die Endpunktadresse des FHIR-Servers korrekt konfiguriert werden. Dies erfolgt direkt in der App. Detaillierte Hinweise finden sich in der README-Datei des Projektes.