Erste Schritte für den Zugriff auf das eEKP-Zentralsystem¶
Dokumentation im Aufbau
Die vorliegende technische Dokumentation befindet sich derzeit im Aufbau. Demzufolge können sich die Inhalte zum Thema eEKP-FHIR-Anbindung noch ändern, respektive weitere Inhalte hinzukommen.
Allgemeines¶
Die technische Grundlage für eEKP-FHIR – also die Anbindung von Krankenanstalten eEKP-Zentralsystem (elektronischer Eltern-Kind-Pass) – baut auf der bestehenden ELGA-Infrastruktur auf. Dabei werden vorhandene Komponenten wie Anbindungsgateways, das ELGA-Berechtigungssystem sowie damit verbundene und etablierte technische Prozesse berücksichtigt. Dazu zählen insbesondere die bestehenden Verfahren für das Beziehen einer ELGA HCP-Assertion (SAML) sowie zur Einmeldung eines Kontaktes über das Kontaktbestätigungsservice (KBS). Die vorliegende technische Dokumentation konzentriert sich daher auf die technischen Rahmenbedingungen, die ab jenem Zeitpunkt relevant sind, ab dem ein zugreifendes Client-System diese Vorbedingungen erfüllt.
Vorbedingungen¶
Die eEKP-FHIR-Anbindung hat unter Berücksichtigung der bestehenden Infrastrukturkomponenten, i.e. Anbindungsgateways (AGW), den bestehenden zentralen Komponenten des ELGA-Berechtigungssystems und den damit verbundenen und etablierten technischen Prozessen zu erfolgen. Dies umfasst insbesondere:
- Bisherige Mechanismen für das Beziehen einer ELGA HCP-Assertion (SAML) sowie der Einmeldung eines Kontaktes über das Kontaktbestätigungsservice (KBS). Dementsprechend fokussieren sich die Ausführungen in der vorliegenden technischen Dokumentation auf die notwendigen technischen Voraussetzungen ab dem Zeitpunkt, ab dem ein etwaiger Consumer/Source Akteur diese Vorbedingungen erfüllt hat.
- Die fachlichen Transaktionen in Richtung eines eEKP-Zentralsystems erfolgen auf Basis von REST/FHIR.
- Zugriff auf das eEKP-Zentralsystem über eEKP-FHIR erfolgt ausschließlich innerhalb der gesicherten Gesundheitsnetze.
Autorisierung von Zugriffen¶
Zugangspunkt für die Kommunikation mit dem eEKP-Zentralsystem stellt die ELGA Service Fassade (ESF) dar. Sie kann als dezentraler Teil des ELGA/e-Health-Berechtigungssystems angesehen werden und fungiert damit in ihrer Rolle analog zur bestehenden Zugriffssteuerungsfassade, allerdings mit dem wesentlichen Unterschied, dass die ESF vorwiegend REST-basierte Technologien unterstützt. Die ESF kommuniziert einerseits mit dem ELGA/e-Health Berechtigungssystem, anderseits ist sie dafür verantwortlich die fachlichen Transaktionen hin zum eEKP-Zentralsystem zu autorisieren.
Auf Seiten des ELGA/e-Health-Berechtigungssystems agiert der ELGA OAuth2 Authorization Server (EOAS) als Kommunikationspartner für die ESF und bildet die Brücke zwischen den bestehenden Autorisierungsmechanismen auf Basis der WS*-Spezifikation und der OAuth2 und OIDC-Welt. Der EOAS stellt dabei Mechanismen zur Verfügung, um ausgehend von einer erfolgten Autorisierung mittels SAML-Assertions einen Übergang in Richtung OAuth2 zu schaffen.
Vereinfacht dargestellt, lässt sich ein Access Token für den Zugriff auf das eEKP-Zentralsystem über eEKP-FHIR anhand des RFC-7522, dem SAML-Bearer Profile wie folgt anfordern. Dabei gilt es zu berücksichtigen, dass für das Anfordern dieses Tokens, eine HCP-Assertion im Attribut assertion zu übermitteln ist. Das folgende Listing zeigt
exemplarisch die Anforderung eines eEKP-Access-Token mittels RFC-7522.
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: b64(client_id:client_secret)
assertion=b64Url(HCP)
grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer
&scope=launch/patient context/<eEKP-App-Id>
&patient=lpid-domain|lpid-wert
Content-Type: application/json
{
"token_type": "Bearer",
"access_token": "eyJraWQiOm51...LjaGg",
"expires_in": 600,
"refresh_token": "eyJraWQiOmed...xxSS",
}
Authorization-Header der jeweiligen Anfrage zu übermitteln.
Information
Ein vom EOAS angeforderter und ausgestellter eEKP-Access-Token ist ausschlißlich für die Kommunikation mit dem eEKP-Zentralsystem vorgesehen.
Damit besteht die Rolle des EOAS darin, einen Übergang von einer in Form von SAML repräsentierten HCP-Assertion in einen Access Token, wahlweise als Json Web Token (JWT), zu ermöglichen. Technisch bedient sich das EOAS anhand der Festlegungen des RFC 7522 - SAML Bearer Token Exchange. Dabei wird über eine definierte Schnittstelle eine bestehende und gültige SAML-Assertion gegen einen JSON Web Token (JWT) getauscht. Dieser JWT kann in Folge im Authorization-Header einer HTTP-Nachricht den Zugriff auf REST- oder wie im vorliegenden Fall auf FHIR-REST-Schnittstellen verwendet werden. Eine erfolgreiche Ausstellung eines Access Tokens auf der Grundlage einer HCP-Assertion ist an die nachfolgenden Bedingungen geknüpft:
- Es handelt sich um eine gültige HCP-Assertion. Die übermittelte Assertion wird unter Nutzung der Funktionen und Services des ETS validiert. Eine Auflistung der vom ETS durchgeführten Prüfungen findet sich unter Referenz BES SS. -[x] Die Rolle des zugreifenden GDA entspricht einer für den Zugriff auf das eEKP-Zentralsystem berechtigten Rolle (siehe Punkt 4.3 für eine Auflistung der in eEKP-FHIR zugelassenen Rollen).
- Im KBS existiert ein aktiver Kontakt zwischen GDA und Patient.
- Über eine PIX-Query wird sichergestellt, dass der Patient eindeutig identifiziert wurde.