C_12538_Anlage_V1.0.0
C_12538_Anlage
Inhaltsverzeichnis
1 Änderungsbeschreibung
Die festgelegte technische Lösung für PoPP (mobile) legt fest, dass PoPP-Modul, ZETA-SDK und Authenticator-Modul in einer App integriert sind. Bei Lösungen mit 1-App-Strategie ist dies die ePA-FdV-App. Bei Lösungen mit 2-App-Strategie ist das die Authenticator-App.
Abbildung 1: Unterscheidung PoPP-Modul Provider App und PoPP-Modul Consumer-App im Kontext der Online-Anwendungsfälle zur PoPP-Token-Erstellung
Die eigentliche Funktionalität des sektoralen IDP und seines Authenticator-Modul bleiben unberührt.
Bedingt durch die Rahmenbedingung für Apps der Krankenversicherungen, dass PoPP-Modul, ZETA Client und Authenticator-Modul der sektoralen IDPs in einer APP integriert sein müssen, ergeben sich Anforderungen an den sektoralen IDP und an die App mit integriertem Authenticator-Modul.
Zum einen werden für die technische Abbildung eines PoPP-Modul Aufrufs aus einer Anbieter-App die Plattformmechanismen von Android und iOS (deeplink / universal link) verwendet. Hier kann allerdings bereits nachgenutzt werden, dass für eine Authentifizierung des Versicherten mit GesundheitsID die entsprechende Konfiguration schon eingerichtet ist. Allerdings ist es notwendig, die Mechanismen der eigentlichen Authentifizierung vom Mechanismus des Aufrufs des PoPP-Moduls zu trennen. Zu diesem Zweck ist ein eigener Endpunkt in A_29041* [gemSpec_PoPP-Modul] definiert. Der Endpunkt besteht aus der Client-ID des sektoralen IDP in der TI-Föderation (iss) und einer PoPP spezifischen Pfaderweiterung.
Zum anderen muss es für die VER möglich sein, aus dem WebFrontend des sekt. IDP, welches im Browser auf dem Gerät des VER geöffnet wird, wenn die App mit Authenticator-Modul nicht installiert ist, zurück in die App zu gelangen, aus welcher der VER den Check-in Prozess gestartet hat.
2 Änderung in gemSpec_IDP_Sek
Es wird in Kapitel "4.1 Allgemeine Anforderungen an Teilnehmer der TI-Föderation" angepasst:
Für die technische Abbildung eines PoPP-Modul Aufrufs aus einer Anbieter-App werden die Plattformmechanismen von Android und iOS (deeplink / universal link) verwendet. Hier wird nachgenutzt, dass für eine Authentifizierung des Versicherten mit GesundheitsID die entsprechende Konfiguration schon eingerichtet ist. Allerdings ist es notwendig, die Mechanismen der eigentlichen Authentifizierung vom Mechanismus des Aufrufs des PoPP-Moduls zu trennen. Zu diesem Zweck ist ein eigener Endpunkt in <iss>/popp* ([gemSpec_PoPP-Modul] - A_29041*) definiert. Der Endpunkt besteht demnach aus der Client-ID des sektoralen IDP in der TI-Föderation (iss) und einer PoPP spezifischen Pfaderweiterung.
Die klare Trennung zwischen Authentifizierung mit GesundheitsID und PoPP-Funktionen erfordert die Bereitstellung eines Endpunkt <iss>/popp*. Ein WebFrontend unterstützt den Nutzer bei der Einrichtung der App mit PoPP-Modul (analog A_22306* bei fehlender Installation der App mit Authenticator-Modul).
Neu:
A_30017 - Information des Nutzers bei fehlender Installation der App mit integriertem Authenticator-Modul und PoPP-Modul
Der Hersteller eines sektoralen IDP MUSS ein technisches Verfahren für den Fall etablieren, dass ein Nutzer die App mit integriertem Authenticator-Modul und PoPP-Modul nicht installiert hat. In diesem Fall MUSS der sektorale IDP für den PoPP-Endpunkt <iss>/popp* ([gemSpec_PoPP_Modul] - A_29041*) ein WebFrontend anbieten und dort darstellen, aus welcher Quelle die App mit integriertem Authenticator-Modul und PoPP-Modul zu beziehen ist, auf welchen Geräten/Plattformen es installiert werden kann und welche Voraussetzungen für die Verwendung der App zu erfüllen sind. [<=]
Die VER werden über das WebFrontend informiert, wie die Einrichtung der App erfolgen muss. Dabei ist es u.a. auch notwendig, dass die VER sich identifizieren ([gemSpec_IDP_Sek]). Möchten die VER auf die Einrichtung der App verzichten, so sollen sie die Möglichkeit haben, über das WebFrontend zurück in die ursprüngliche App zu gelangen, von der aus der Check-in-Prozess gestartet wurde. Für den Rücksprung werden ebenfalls wieder die Plattformmechanismen von Android und iOS (deeplink / universal link) verwendet. Aus dem WebFrontend muss dafür die API [I_AnbieterApp_mobile_CheckIn.yaml] an der callBack-URL aufgerufen werden, die beim ursprünglichen Aufruf der ursprünglichen App als Parameter übergeben wurde. Die Parameter des API-Aufruf signalisieren der App, dass der VER den "Check-in" abgebrochen hat.
Neu:
A_30611 - Rücksprung in die aufrufende App bei Abbruch der Installation der App mit integriertem Authenticator-Modul und PoPP-Modul
Der Hersteller eines sektoralen IDP MUSS auf dem WebFrontend eine Funktion anbieten, die dem Nutzer einen Rücksprung in die aufrufende App ermöglicht, wenn dieser die App mit integriertem Authenticator-Modul und PoPP-Modul nicht installieren möchte. Die Anbieter implementiert dafür ein Interface nach A_30102* ([I_AnbieterApp_mobile_CheckIn.yaml]).
Der Hersteller eines sektoralen IDP MUSS beim Aufruf des Interface die Parameter mit folgenden Werten belegen:
- poppStatus="error
- errorDescription="HttpStatus.NOT_FOUND - PoPP-Modul is not installed"
3 Änderungen in Steckbriefen
3.1 Änderungen in gemProdT_IDP-Sek_KTR_PTV
Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_IDP-Sek_KTR_PTV]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.
Tabelle 1: Anforderungen zur funktionalen Eignung "Herstellererklärung"
| Afo-ID
|
Afo-Bezeichnung
|
Quelle (Referenz)
|
|---|---|---|
| A_30017 | Information des Nutzers bei fehlender Installation der App mit integriertem Authenticator-Modul und PoPP-Modul
|
gemSpec_IDP_Sek |
| A_30611 | Rücksprung in die aufrufende App bei Abbruch der Installation der App mit integriertem Authenticator-Modul und PoPP-Modul | gemSpec_IDP_Sek |