Aufbau eines Application Containers

Der ELGA AC bildet auf Basis der existierenden ELGA Infrastruktur die Möglichkeit, einfach und flexibel neue e-Health bzw. ELGA Anwendungen umzusetzen. Der ELGA AC setzt sich aus unterstützenden Zentralkomponenten (Z-PI, GDA-I, etc.), BeS-Zentralkomponenten, dezentralen BeS-Komponenten (AGW/ZGF) und der Fachlogik, die wie ein ELGA Bereich durch eine vorgeschaltete ZGF gekapselt und geschützt ist, zusammen. Die Fachlogik kann nur passiv (responding) oder aktiv-passiv (initiating & responding) agieren. Die Fachlogik eines AC kann auf unterschiedliche Art realisiert werden.

Aktuell stehen gemäß der etablierten Verfahren in ELGA wie WS Trust, XDS, XCA und PDQ, SOAP basierende IHE Profile im Fokus. Perspektivisch könnte eine Fachlogik auch mittels FHIR REST umgesetzt werden und mittels On Demand Dokumenten oder REST Schnittstellen in die ELGA Infrastruktur integriert werden.

Abbildung: Aufbau eines AC

Der erste Schritt für einen Client, um mit einem AC zu kommunizieren ist, eine AC Kontext-Assertion für den jeweiligen AC zu beantragen. Damit wird eine Anmeldung im Kontext des AC durchgeführt. Mit der Kontext-Assertion können nachfolgend Transaktionen an eine initiierende ZGF durchgeführt werden. Die ZGF bzw. der Kontext-Switch beantragt für den AC eine Treatment-Assertion und leitet die Anfrage an den jeweiligen AC weiter.

Wie in ELGA bereits üblich, schreibt die initiierende ZGF ATNA Audits in ein "ELGA Bereichs ATNA Repository".

Abhängig vom AC werden A-ARR Audits in das zentrale A-ARR eingebracht.

Einwilligungen zu einem AC werden vom Client mittels BPPC Dokumenten an die initiierende AGW gesendet. Die AGW leitet BPPC Dokumente an den zentralen ELGA XDS-PAP weiter.

Der Client kann außerdem DSUB ITI-52 Subscribe-Nachrichten über die initiierende AGW an die zentrale DSUB Komponente senden.

Die antwortende ZGF ist entweder eine spezifische AC ZGF für den jeweiligen AC, wie sie z.B. bereits für den e-Impfpass eingesetzt wird oder eine existierende Bereichs-ZGF, wie es bei den VOs umgesetzt wurde. Eine antwortendende ZGF kann auch für mehrere AC verwendet werden.

Ist eine Fachlogik nur passiv, existieren auf der antwortenden ZGF nur die responding XCA Schnittstellen. Ist die Fachlogik aktiv-passiv, existieren auf der ZGF zusätzlich die initiierenden XCA Schnittstellen (siehe Kapitel ZGF Routing).

Für spezielle AC Implementierungen kann auch ein PDQ von der antwortenden ZGF an eine "Fachlogik" wie z.B.: dem Z-PI oder NCPeH-AT weitergeleitet werden.

AC Kontext-Switch

Ein Hauptbestandteil des AC ist der Kontext-Switch, der kontextsensitives Routing ermöglicht. Der Kontext-Switch basiert auf einem zur HCP-Assertion analogen Kontext-Assertion in Form einer SAML2-Assertion.

Ein Client meldet sich hierfür mittels WS Trust mit einer ELGA Login-Assertion oder einer vertrauenswürdigen Identity-Assertion für einen AC an, indem eine Kontext-Assertion beim ETS beantragt wird. Diese muss nachfolgend für alle Transaktionen im SOAP Security Header präsentiert werden.

Die ZGF entscheidet auf Basis der spezifischen AC Kontext-Assertion, welche dynamisch geladenen Konfigurationselemente des jeweiligen AC anzuwenden sind und damit auch welche Basisfunktionalitäten bzw. Routings eines AC zu aktivieren sind.

Die Selektion wird anhand der e-Health Anwendung-ID durchgeführt.

Anbindung einer Fachlogik

Steht eine IHE/ELGA konforme XDS Registry, ein Repository und ein ATNA L-ARR zur Verfügung, sind bezüglich der Schnittstellen keine weiteren Anforderungen zu erfüllen. Wie bereits erwähnt kann für manche AC Implementierungen auch eine PDQ Transkation notwendig sein.

Wird eine Fachlogik nicht auf erprobten IHE Komponenten aufgebaut, muss diese alle IHE Transaktionen, die im jeweiligen Fachkonzept ausgewählt wurden, vollumfänglich unterstützen. Details dazu siehe Kapitel Patientensuche (PDQ).

Für die Patientensuche mittels AC kann die HL7 V3 Transaktion ITI-47 verwendet werden. Im SOAP Security Header muss eine AC Kontext-Assertion mitgeführt werden. Bis auf die Signatur der Assertion und der Existenz der Permission werden von BeS keine weiteren Prüfungen durchgeführt.

Die PDQ kann per AC Konfiguration aktiviert oder deaktiviert werden (Pdq Element im acImport.xml). Die Konfiguration wird wie üblich mittels Treatment-Assertion transportiert. Ein PDQ ist nur möglich, wenn "CHECK_PATIENT" false ist oder eine PID, die dem Z-PI bekannt ist, in der Anfrage existiert. Abhängig von der Konfiguration (CHECK_PATIENT) wird beim Ausstellen einer Treatment-Assertion keine Patientenidentifikation gegen den Z-PI durchgeführt.

Die AC-Permission für PDQ-Abfragen, die den jeweiligen Rollen zugeordnet werden muss, wird im AC Import definiert. Es kann z.B. eine eigene Permission für PDQ-Abfragen definiert werden (z.B. urn:elga:bes:2019:permission:{{AppId}}:pdq), es kann aber auch wie bei allen anderen Transaktionen jede in der XACML Policy vorhandene Permission (read, write, etc.) verwendet werden. Wichtig ist, dass die verwendete Permission auch in der XACML Policy vorhanden ist. Ist in der AC Kontext-Assertion oder in der XACML Policy keine PDQ Permission enthalten wird eine AccessDenied SOAP Fault zurückgegeben.

Die folgende Abbildung zeigt wie im Kontext eines AC eine Patientensuche durchgeführt wird.

Schnittstellen zur Fachlogik eines AC.

Es ist grundsätzlich möglich, beliebig viele Fachlogikimplementierungen über eine antwortende ZGF anzubinden. Dabei werden mehrere AC auf der antwortendenden ZGF bekannt gemacht und mittels Kontext-Switch äquivalent zur initiierenden ZGF die richtige Anwendung ausgewählt.

AC im Kontext von ZGF-Typen

Prinzipiel ist jeder der verschiedenen ZGF-Typen, ausgenommen Typ "EMED", in der Lage AC Konfigurationen zu importieren und die jeweiligen Funktionalitäten bereitzustellen. In der folgenden Tabelle findet sich ein Überblick über die einzelnen Spezialisierungen der jeweiligen Typen, im Hinblick auf die derzeitigen Anwendungsbereiche "ELGA" und "Applikation Container".

ZGF-Typ	ELGA	Applikation Container
EBEF	X	X
EMED	X	-
EBP	X	X
IMPF	-	X
ROZ	X	X

Tabelle: Spezialisierung von ZGF-Typen

Daraus ist zu Erkennen, daß einerseits nur der Typ "EMED" nicht als ZGF-Typ im Rahmen von AC-Konfigurationen verwendet werden kann, aufgrund seiner weitreichenden Spezialisierung und andererseits der ZGF-Typ "IMPF" keinerlei Funktionalitäten im Bereich ELGA aufweist und somit ausschließlich für AC Anwendungen zur Verfügung steht.