Telematikinfrastruktur 2.0

Spezifikation

PoPP (Proof of Patient Presence)

-Modul

Version
1.0.0_CC
Revision
1494668
Stand
26.01.2026
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemSpec_PoPP_Modul

Dokumenteninformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zur Herstellung, zum Test und zum Betrieb des Produkttyps Proof of Patient Presence (PoPP)-Modul. Diese bilden auf Versichertenseite den clientseitigen Gegenpart zu den serverseitigen Festlegungen in der Spezifikation [gemSpec_PoPP_Service]. In die Spezifikation sind die Ergebnisse intensiver Abstimmungen mit den Gesellschaftern der gematik als Konsumenten der gesamten PoPP-Lösung insbesondere zu Themen bei Nutzung der GesundheitsID eingeflossen.

Das PoPP-Modul bietet Versicherten mit GesundheitsID oder bei Nutzung der eGK-in-Fernversorgung den Zugang zur PoPP-Lösung. Der PoPP-Service erzeugt die Bestätigung eines Versorgungskontextes (VK) in Form eines kryptographisch gesicherten PoPP-Token. Dieses bestätigt, dass ein bestimmter Versicherter mit einer bestimmten Leistungserbringerinstitution (LEI) in einen Versorgungskontext getreten ist.

Neben dem PoPP-Modul, tragen weitere Komponenten zur PoPP-Lösung bei:

• Der PoPP-Service [gemSpec_PoPP_Service] ist der Server-Anteil der PoPP-Lösung.
• Die PoPP-Clients, die als Teil der Primärsysteme implementiert werden [gemILF_PoPP_Client].

Die Spezifikationen oder Beschreibungen dieser Komponenten erfolgt in den anderen Dokumenten.

1.2 Zielgruppe

Dieses Dokument richtet sich an Hersteller und Betreiber von Apps für Versicherte, die ein PoPP-Modul in ihre App integrieren wollen, insbesondere an die Kassen und ihre Auftragnehmer sowie Drittanbieter.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekanntgegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

In dem Dokument werden die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen spezifiziert. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch [Anhang ]).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps PoPP-Modul verzeichnet.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID,
Anforderungen zusätzlich durch die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Anforderungen werden im Dokument wie folgt dargestellt:
<AF-ID> - <Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

bzw.

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst der Anwendungsfall bzw. die Anforderung sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Hinweis auf offene Punkte (Beispiel)

2 Systemüberblick/Systemkontext

Das Konzept für den PoPP Online-Check-in ist in der Feature Spezifikation [gemF_PoPP_Online_Check-in] beschrieben.

Ein ausführlicher Systemüberblick und eine Darstellung der Anwendungsfälle sind in [gemSpec_PoPP_Service] dargestellt.

PoPP-Module müssen funktionale und sicherheitstechnische Anforderungen der gematik erfüllen. Welche Anforderungen ein PoPP-Modul erfüllen muss, wird von der gematik in einem Produkttypsteckbrief bekanntgegeben.
Die Erfüllung der Anforderungen muss der Hersteller eines PoPP-Moduls der gematik in einem Zulassungsverfahren nachweisen.

Ein Systemüberblick und die Erläuterung dazu sind der in "Systemkontext PoPP-Lösung" dargestellten Komponenten findet sich in [gemSpec_PoPP_Service].

2.1 Detailsicht "Online-Anwendungsfälle zur PoPP-Token-Erstellung"

An der über eine App (Krankenversicherung-App, Drittanbieter-App) auf dem mobilen Endgerät des Versicherten initiierten Erstellung eines PoPP-Token sind mehrere Architekturkomponenten der TI beteiligt.

Die ZETA-Komponenten (Zero Trust-Architektur) garantieren die Vertrauenswürdigkeit des Geräts des Versicherten und der für PoPP zum Einsatz kommenden Anwendung auf diesem Gerät.

Die Komponenten der TI-Föderation garantieren die Authentifizierung der Person, welche die Anwendung nutzt, für den Fall, dass eine Authentifizierung über die GesundheitsID erfolgt.

Die Komponenten des PoPP-Service garantieren die Ausstellung eines PoPP-Token an die LEI, welche der Versicherte ausgewählt hat und für die er in eine Datenweitergabe eingewilligt hat.

PoPP-Modul und ZETA Client müssen dabei immer gemeinsam in eine App integriert sein. Die "Detailsicht Komponenten für die Online-Anwendungsfälle zur PoPP-Token Erstellung mit PoPP-Modul in App der Krankenversicherung" zeigt die beteiligten Komponenten, wenn PoPP-Modul und ZETA Client in die Krankenversicherungs-App integriert sind, welche auch das Authenticator-Modul des sektoralen IDP der Krankenversicherung implementiert.

Abbildung 1: Verteilungssicht Komponenten für  die Online-Anwendungsfälle zur PoPP-Token-Erstellung mit PoPP-Modul in App der Krankenversicherung

Diese Konstellation unterstützt alle Online-Anwendungsfälle zur PoPP-Token-Erstellung der Krankenversicherungen optimal. Anwendungsfälle von Drittanbieter-Apps werden ebenfalls unterstützt. Im Ablauf findet ein App-Wechsel von der Drittanbieter-App in die Krankenversicherungs-App und zurück statt. Es erfordert keine durch die gematik zuzulassende Implementierung.

Tabelle 1: Beschreibung der wesentlichen Komponenten für die Online Anwendungsfälle zur PoPP-Token Erstellung

3 Übersicht Funktionsmerkmale und Schnittstellen

Apps mit unterschiedlichen fachlichen Ausrichtungen haben den Bedarf, einen Versorgungskontext zwischen einer versicherten Person und einer Leistungserbringerinstitution herzustellen.

Die Benutzerführung für die Erstellung eines Versorgungskontext zwischen einer versicherten Person und einer LEI wird dabei wesentlich davon geprägt, welchen Zweck die jeweilige Anbieter-App verfolgt. Dabei spielen folgende Faktoren eine Rolle:

• Welche Authentisierungsverfahren sollen durch das PoPP-Modul unterstützt werden (GesundheitsID und/oder "eGK-in-Fernversorgung")?
• Ist durch die Anbieter-App bereits festgelegt, welche Leistungserbringerinstitution (LEI) ein PoPP-Token benötigt oder muss die LEI über das PoPP-Modul ermittelt werden?
• Welche Verfahren zur Ermittlung der LEI werden unterstützt?

Die Benutzerführung in den jeweiligen Apps muss die unterschiedlichen Einflussfaktoren berücksichtigen.

Weitere Einflussfaktoren zur Ausgestaltung der Benutzerführung sind:

• Wenn das PoPP-Modul in ein ePA-Frontend des Versicherten (FdV) integriert ist, so kann für die Authentifizierung des Versicherten über seine GesundheitsID das Single-Sign-On (SSO) des ePA-FdV genutzt werden.
• Wenn die Anbieter-App, welche das PoPP-Modul benötigt, auf demselben Gerät installiert ist wie die App mit dem Authenticator-Modul für die Authentifizierung mit GesundheitsID (entweder standalone oder integriert in Krankenversicherungs-App), erfolgt die Erstellung des PoPP-Token bei einer Authentifizierung mit GesundheitsID über das PoPP-Modul mit App-App-Kommunikation (App-Sprung). Wenn die Anbieter-App, welche das PoPP-Modul benötigt, nicht auf dem Gerät installiert ist, auf dem auch die App mit dem Authenticator-Modul läuft, so erfolgt die Erstellung des PoPP-Token bei einer Authentifizierung mit GesundheitsID über das PoPP-Modul durch eine 2-Geräte-Kommunikation.
• Ist das PoPP-Modul in eine Drittanbieter-App integriert und das Gerät unterstützt NFC, so kann eine Authentifizierung der eGK ohne PIN-Eingabe ("eGK-in-Fernversorgung") genutzt werden. In diesem Fall gibt es keinen App-Sprung.
• Ist das Gerät des Versicherten nicht Near Field Communication (NFC) fähig oder kann kein Standardkartenleser verwendet werden, so ist die Authentifizierung einer elektronischer Gesundheitskarte ("eGK-in-Fernversorgung") nicht möglich.

Jede App mit integriertem PoPP-Modul muss auch ein ZETA Client [gemSpec_ZETA] implementieren. Der ZETA Client als Frontend-Komponente der Zero Trust-Architektur stellt die sichere Kommunikation zwischen der App mit dem PoPP-Modul auf einem mobilen Endgerät und dem PoPP-Service sicher. Über den ZETA Client wird im Rahmen der Initialisierung sowohl das Gerät auf dem die App läuft als auch die App selbst in der ZETA Guard Client-Registry registriert. Unter anderem wird durch die Attestierung der App auf einem bestimmten Gerät das Vertrauensverhältnis zwischen PoPP-Modul und PoPP-Service hergestellt. 

Im Anhang des Dokuments sind die Abläufe der PoPP-Token Erstellung über eine Authentifizierung von Versicherten mit GesundheitsID und über die Authentifizierung einer eGK ohne PIN-Eingabe (eGK-in-Fernversorgung) detailliert beschrieben.

Die Abläufe berücksichtigten auch den Fall, dass ein PoPP-Token von einer Anwendung angefordert wird, welche kein PoPP-Modul integriert.

Dabei muss die Anwendung Voraussetzungen erfüllen, um die PoPP-Token-Erstellung zu initiieren:

• Auswahl der Krankenversicherung des Versicherten bzw. Ermittlung der ClientID des sektoralen IDP der Krankenversicherung in der TI-Föderation.
• Ermittlung der Telematik-ID der LEI, für die ein PoPP-Token erstellt werden soll.
• Ermittlung der WorkplaceID,  für die ein PoPP-Token erstellt werden soll.
• Festlegung, ob zwingend eine Anmeldung mit "eGK-in-Fernversorgung" durchgeführt werden soll.
• Aufruf eines Request mit Telematik-ID und einer Rücksprung-URL (callBackURL) an die ClientID des sektoralen IDP der Krankenversicherung in der TI-Föderation um den Ablauf in das PoPP-Modul zu verlagern.

Die WorkplaceID dient einer LEI, welche ein PoPP-Token erhält, dieses einem konkreten Arbeitsplatz zuzuweisen. Die WorkplaceID kann durch die LEI auch wie eine Session-ID verwendet werden, um das letztendlich erzeugte PoPP-Token dann dem richtigen Versicherten zuordnen zu können. Dies kann bspw. im Online-Apotheken-Anwendungsfall notwendig werden. Die LEI muss dabei beachten, dass die in A_28629* beschriebenen Einschränkungen für die WorkplaceID entsprechend genauso gelten.

Die Abläufe der Authentifizierung von Versicherten mit GesundheitsID und der Authentifizierung einer eGK ohne PIN-Eingabe (eGK-in-Fernversorgung) unterscheiden sich in den Schritten der konkret ablaufenden Authentifizierung und sind darüber hinaus z.B. im Hinblick auf die Initialisierung des ZETA Client , der Ermittlung der Daten einer LEI über den VZD, der Zustimmung zur Nutzung der Daten und der Ergebnisverarbeitung der PoPP-Token-Erstellung identisch. 

3.1 Authentifizierung mit GesundheitsID

Die Erstellung eines PoPP-Token wird bei Online Szenarien über ein in eine App integriertes PoPP-Modul gestartet. Für die Authentifizierung mit GesundheitsID gibt es hier drei unterschiedliche Umsetzungsvarianten:

1. PoPP-Modul und Authenticator-Modul des sektoralen IDP sind in die App der Krankenversicherung integriert, welche auch das ePA-FdV integriert.
2. PoPP-Modul und Authenticator-Modul des sektoralen IDP sind in einer eigenen Authenticator-App und der Online-Check-in mit GesundheitsID wird aus einer anderen App gestartet (App-Sprung).
3. PoPP-Modul ist in einer Drittanbieter-App und das Authenticator-Modul ist in einer App der Krankenversicherung integriert (App-Sprung).

Das Aktivitätsdiagramm "Allgemeiner Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung über die GesundheitsID" im Anhang stellt den Ablauf der PoPP-Token-Generierung für den Fall dar, dass das PoPP-Modul und Autheticator-Modul in einer App integriert sind. Der Start des Online-Check-in erfolgt in einer Drittanbieter-App oder in der App der Krankenversicherug. Ein Versicherter wird über seine GesundheitsID authentifiziert. Die für die PoPP-Token-Erstellung notwendigen Daten, KVNR des Versicherten und IK-Nummer der Krankenversicherung des Versicherten werden bei erfolgreicher Authentifizierung aus dem vom sektoralen IDP ausgestellten ID-Token entnommen.

Die Informationen zum eingesetzten Authentisierungsmittel und zum Vertrauensniveau, auf dem die Authentifizierung durchgeführt wurde, werden ebenfalls aus dem ID-Token entnommen und fließen als "proofMethod" in das PoPP-Token ein.

3.2 Authentifizierung einer eGK (in Fernversorgung)

Mit einer Authentifizierung eGK-in-Fernversorgung können Anwendungsfälle unterstützt werden, bei denen das Sicherheitsniveau einer eGK-Authentifizierung ausreichend ist. Für die Authentifizierung einer eGK-in-Fernversorgung muss der Nutzer eine eGK an sein Smartphone halten. Über die NFC-Schnittstelle wird die eGK durch den PoPP-Service ausgelesen. Der PoPP-Service prüft die ausgelesenen Daten.

Wählt der Versicherte als Authentisierungsmittel "eGK-in-Fernversorgung" oder wird dies durch den Anwendungsfall vorgegeben (z.B. Rezept einlösen durch Vertreter), so wird die eGK über die Komponenten des PoPP-Service authentifiziert.

Für das Auslesen der eGK kommuniziert der PoPP-Service über die ZETA-Komponenten mit dem PoPP-Modul und dieses direkt mit der eGK. Das PoPP-Modul sendet über die NFC-Schnittstelle des Versicherten-Gerätes die vom PoPP-Service erzeugten APDU-Kommandos an die eGK und empfängt von dieser die jeweiligen Antworten. Die Antworten der eGK werden vom PoPP-Modul unverändert über die ZETA-Komponenten an den PoPP-Service geschickt. Über diesen Weg werden CV-Zertifikat und X.509-Zertifikat ausgelesen. Außerdem wird eine vom PoPP-Service erzeugte Challenge durch die eGK mit dem CV-Zertifikat der eGK signiert.

Der PoPP-Service führt dann die notwendigen Prüfungen der Zertifikate sowie der signierten Challenge durch. Der PoPP-Service erstellt nach erfolgreicher Prüfung das PoPP-Token. Die Daten zur LEI (Telematik-ID und WorkplaceID) kommen in diesem Fall aus einem vorherigen Request vom PoPP-Modul. Die KVNR des Versicherten und die IK-Nummer des Kostenträgers werden aus dem X.509-Zertifikat ermittelt.

Durch das proofMethod Attribut im PoPP-Token wird einer verwendenden Fachanwendung vermittelt, dass zur Erstellung des PoPP-Token nur eine niederschwellige Authentifizierung durchgeführt wurde.

3.3 Schnittstellen des PoPP-Moduls

Die Abbildung "Schnittstellen vom und zum PoPP-Modul" zeigt die Schnittstellen von und zum PoPP-Modul. Die Schnittstellen zwischen Komponenten der Authenticator-App sind API-Schnittstellen. Zwischen den über das Internet erreichbaren Komponenten sind REST-Schnittstellen.

Abbildung 2: Schnittstellen vom und zum PoPP-Modul

3.3.1 initPoppTokenGeneration()

Beschreibung:

Wird die PoPP-Token-Erstellung über eine Drittanbieter-App initiiert, so ruft diese die URL des sektoralen IDP der Krankenkasse des Versicherten mit den Parametern für das PoPP-Modul auf, um die Erstellung eines PoPP-Token für eine Telematik-ID zu initiieren.

Der Aufruf bewirkt das Öffnen der Authenticator-App mit implementierten PoPP-Modul. Aufgrund der übergebenen Parameter wird das PoPP-Modul aufgerufen.

Protokoll: HTTP

Parameter:

Rückgabewerte:

3.3.2 startPoppTokenErzeugung()

Beschreibung:

Wird die PoPP-Token Erstellung über eine Drittanbieter-App initiiert, welche das PoPP-Modul und ZETA Client selbst implementieren, so ruft diese dazu eine API-Schnittstelle am PoPP-Modul auf.

Protokoll: API

Parameter:

Rückgabewerte:

3.3.3 hasGesundheitsID()

Beschreibung:

Die Schnittstelle dient der Abfrage an das Authenticator-Modul, ob eine GesundheitsID mit einer Identifikation des Versicherten auf dem Vertrauensniveau "gematik-ehealth-loa-high" eingerichtet wurde. Ist das nicht der Fall (Abfrage liefert "false"), so kann im weiteren Verlauf nur eine eGK-Authentifizierung über den PoPP-Service und nicht eine Versicherten-Authentifizierung über die sektoralen IDP erfolgen.

Protokoll: API

Parameter: keine

Rückgabewerte:

3.3.4 init()

Beschreibung:

Der Aufruf initialisiert den ZETA Client.

Protokoll: API

Parameter:

Rückgabewerte: keine 

3.3.5 execute(httpLoadPractitionerInformationRequest)

Beschreibung:

Der execute-Aufruf des PoPP-Modul am ZETA Client ist die Anweisung zur Durchführung eines HTTP-Request am PoPP-Service für die Suche der Daten zu einer LEI. Dafür wird als Parameter ein am FHIR-VZD ausführbarer Search-Request mit übergeben. Der Search-Request wurde entweder an der Schnittstelle zum PoPP-Modul (initPoppTokenGeneration oder startPoppTokenErzeugung) übergeben. Nach der ZETA-Initialisierung stellen die ZETA-Komponenten ein Client Access-Token aus und führen den HTTP-Request mit dem Access-Token am PoPP-Service aus. Nach Ermittlung der LEI-Daten über den FHIR-VZD wird das Suchergebnis als Response an ZETA zurückgegeben. Der ZETA Client ruft die callBack-Methode mit dem Response-Objekt beim PoPP-Modul auf.

Protokoll: API

Parameter:

Rückgabewerte: keine

3.3.6 callBackLoadPractitionerInformation

Beschreibung:

Das PoPP-Modul stellt die API-Methode bereit, die vom ZETA Client als Abschluss des ausgeführten execute-Auftrags zur Ermittlung der Daten einer LEI aufgerufen werden soll. Der ZETA Client übergibt die Antwort auf den HTTP-Request an das PoPP-Modul.

Protokoll: API

Parameter:

Rückgabewerte: keiner

3.3.7 execute(httpReadEgkRequest)

Beschreibung:

Der Aufruf der execute-Methode mit dem Parameter httpReadEgkRequest wird nur bei der Authentifizierung einer eGK aufgerufen.

Der execute-Aufruf des PoPP-Modul am ZETA Client ist die Anweisung zur Durchführung eines HTTP-Request am PoPP-Service für die Prüfung einer eGK. Die ZETA-Komponenten führen mit dem Client-Access-Token aus den HTTP-Request am PoPP-Service aus.  Der PoPP-Service erstellt einen APDU-Command, welches an die eGK verschickt werden soll. Der PoPP-Service gibt das APDU-Command in der Response an die ZETA-Komponenten zurück. Der ZETA Client ruft die callBack-Methode mit dem Response-Objekt beim PoPP-Modul auf.

Der Ablauf, Aufruf der execute(httpReadEgkRequest)-Methode und Antwort in der callBackReadEgk()-Methode wird so lange durchlaufen, bis alle vom PoPP-Service zu erstellenden APDU-Commands abgearbeitet sind. Die Antworten auf ein APDU-Command werden in den app_authorization_details des nächsten execute() Aufrufs an den PoPP-Service übertragen. Demzufolge sind keine Daten in den app_authorization_details im ersten Aufruf enthalten.

Protokoll: API

Parameter:

Rückgabewerte: keine

3.3.8 callBackReadEgk - bei Authentifizierung einer eGK

Beschreibung:

Der callBackReadEgk-Methode wird vom ZETA Client nur bei der Authentifizierung einer eGK aufgerufen.

Das PoPP-Modul stellt die API-Methode bereit, die vom ZETA Client als Antwort auf ausgeführte execute-Aufträge zum Auslesen der Daten aus einer eGK aufgerufen werden soll. Der ZETA Client übergibt die Antwort auf den HTTP-Request an das PoPP-Modul. Das Response-Objekt enthält entweder den nächsten durchzuführenden APDU-Aufruf für die eGK oder einen Datensatz zum Status der PoPP-Token-Generierung, wenn die APDU-Command vollständig abgearbeitet ist und ein Status der PoPP-Token-Generierung vom PoPP-Service erstellt wurde. 

Protokoll: API

Parameter:

Rückgabewerte: keiner

3.3.9 sendAPDUCommands()

Beschreibung:

Die sendAPDUCommand-Methode wird vom PoPP-Modul nur bei der Authentifizierung einer eGK aufgerufen.

Das PoPP-Modul sendet der eGK über die NFC-Schnittstelle die APDU-Command aus dem Response-Objekt, welche beim Aufruf der callReadEgk()-Methode übergeben wurde.

Die Antwort der eGK wird apdu_command_respose in den app_authorization_details des nächsten execute(httpReadEgkRequest, callBackReadEgk, app_authorization_details) an den PoPP-Service übertragen.

Protokoll: API

Parameter:

Rückgabewerte:

3.3.10 execute(httpCheckInGIDRequest)

Beschreibung:

Der Aufruf der execute-Methode mit dem Parameter httpCheckInGIDRequest wird nur bei der Authentifizierung mit GesundheitsID aufgerufen.

Der execute-Aufruf des PoPP-Modul am ZETA Client ist die Anweisung zur Durchführung eines HTTP-Request am PoPP-Service zur Erstellung eines PoPP-Token nach Authentifizierung des Versicherten über seine GesundheitsID. Die ZETA-Komponenten prüfen, ob bereits eine Authentifizierung durchgeführt wurde. Ist das nicht der Fall wird die Authentifizierung des Versicherten über den sektoralen IDP angestoßen. Die URL des sektoralen IDP wird in den app_authorization_details vom PoPP-Modul übergeben. Nach erfolgreicher Authentifizierung werden den ZETA-Komponenten die Daten des Versicherten als ID-Token übergeben. Die ZETA-Komponenten führen nun den httpCheckInGIDRequest am PoPP-Service aus. Der PoPP-Service erstellt ein PoPP-Token. Den Status der PoPP-Token-Generierung liefert der PoPP-Service als Response den ZETA-Komponenten zurück. Der ZETA Client ruft die callBack-Methode mit dem Response-Objekt beim PoPP-Modul auf.

Protokoll: API

Parameter:

Rückgabewerte: keine

3.3.11 callBackCheckInGID

Beschreibung:

Die callBackCheckInGID-Methode wird vom ZETA Client nur bei der Authentifizierung mit GesundheitsID aufgerufen.

Das PoPP-Modul stellt die API-Methode bereit, die vom ZETA Client als Abschluss des ausgeführten execute-Auftrags aufgerufen werden soll. Der ZETA Client übergibt die Antwort auf den HTTP-Request an das PoPP-Modul.

Protokoll: API

Parameter:

Rückgabewerte: keiner

3.3.12 execute(httpReadStatusPoPPRequest)

Beschreibung:

Der Aufruf der execute-Methode mit dem Parameter httpReadStatusPoPPRequest kann vom PoPP-Modul aufgerufen werden um bei PoPP-Service den aktuelle Status zum Check-in abzurufen. Dieser Aufruf ist dann sinnvoll, wenn der ursprüngliche Check-in noch nicht vollständig abgeschlossen werden konnte, da die LEI nicht online war. In diesem Fall hat der Check-in-Prozess dem PoPP-Modul den Status "pending" zurückgeliefert (siehe A_28503*).

Der execute-Aufruf des PoPP-Modul am ZETA Client ist die Anweisung zur Durchführung eines HTTP-Request am PoPP-Service für den Abruf des aktuellen Status zur PoPP-Token Erstellung. Die ZETA-Komponenten führen mit dem Client Access-Token den HTTP-Request am PoPP-Service aus.  Den Status der PoPP-Token-Generierung liefert der PoPP-Service als Response den ZETA-Komponenten zurück. Der ZETA Client ruft die callBack-Methode mit dem Response-Objekt beim PoPP-Modul auf.

Protokoll: API

Parameter:

Rückgabewerte: keine

3.3.13 callBackReadStatusPoPP

Beschreibung:

Der callReadStatus-Methode wird vom ZETA Client als Ergebnis der Status-Abfrage zur PoPP-Token-Generierung aufgerufen.

Das PoPP-Modul stellt die API-Methode bereit, die vom ZETA Client  als Antwort auf ausgeführte execute-Aufträge zum Auslesen der Daten aus einer eGK aufgerufen werden soll. Der ZETA Client übergibt die Antwort auf den HTTP-Request an das PoPP-Modul. Das Response-Objekt enthält einen Datensatz zum Status der PoPP-Token-Generierung. 

Protokoll: API

Parameter:

Rückgabewerte: keiner

3.3.14 callBackApp

Beschreibung:

Ist die PoPP-Token-Erstellung über eine Drittanbieter-App über App-App-Kommunikation initiiert, ruft das PoPP-Modul die im initPoppTokenGeneration()-Request übergebene callBackAppURL mit der HTTP-Response aus dem callBackReadEgk()-Request bzw. callBackCheckInGID()-Request auf. Das Gerät muss so konfiguriert sein, dass der Aufruf zum Öffnen der Drittanbieter-App führt (deeplink / universal link).

Protokoll: HTTP

Parameter:

Rückgabewerte:

3.4 PoPP-Modul in Drittanbieter-APP

Das spezielle Verfahren der Authentifizierung einer eGK wird über das Zusammenwirken von PoPP-Modul, ZETA-Komponenten und PoPP-Service ohne Beteiligung weiterer Komponenten abgebildet. PoPP-Token, die auf diesem niedrigen Vertrauensniveau ausgestellt werden, sind nicht für alle Fachverfahren zulässig. Bei der Authentifizierung Versicherter mit ihrer GesundheitsID werden noch die Komponenten des sektoralen IDP der Krankenversicherung benötigt. Die Authentifizierung der Versicherten über die sektoralen IDPs erfolgt hier auf hohem Vertrauensniveau (siehe [gemSpec_IDP_Sek] - "gematik-ehealth-loa-high" und "gematik-ehealth-loa-substantial"). Die im PoPP-Token enthaltenen Versichertendaten gehören eindeutig zum Versicherten, welcher sich authetifiziert hat.

Alternativ kann PoPP-Modul und ZETA Client auch in der Drittanbieter-App implementiert werden ("Detailsicht Komponenten für  die Online-Anwendungsfälle zur PoPP-Token-Erstellung mit PoPP-Modul in Drittanbieter App").

Abbildung 3: Verteilungssicht Komponenten für  die Online-Anwendungsfälle zur PoPP-Token-Erstellung mit PoPP-Modul in Drittanbieter App

Da für die Authentifizierung einer eGK nur PoPP-Modul, ZETA-Komponenten und PoPP-Service benötigt werden, ist in diesem Fall kein App-Sprung notwendig. Der detaillierte Ablauf ist in [Kapitel "Detailierter Ablauf der PoPP-Token Generierung durch Authentifizierung der eGK über den PoPP-Service mit PoPP-Modul in einer Drittanbieter-App"] dargestellt. 

Die PoPP-Token Erstellung auf einem hohen Vertrauensniveau über Authentifizierung des Versicherten mit GesundheitsID muss allerdings immer über das Authenticator-Modul in der App der Krankenversicherung erfolgen.

4 Übergreifende Festlegungen

4.1 Datenschutz und Informationssicherheit

Hinweis: Das in gemSpec_ZETA#A_25340* geforderte Einbinden des TI-Vertrauensraums ist nicht erforderlich.

Hinweis: Die Einwilligungsabfrage kann mit der Anzeige der LEI-Informationen (vgl. A_28488*) in einem Schritt passieren.

Hinweis: Über die Anzeige der LEI-Daten soll der Versicherte in die Lage versetzt werden, eine ggf. falsche Telematik-ID (gescannte oder übergebene Daten sind fehlerhaft oder manipuliert) zu erkennen, indem er die angezeigten Klartext-LEI-Informationen mit den erwarteten Informationen (LEI bei der er den Check-in durchführen möchte) abgleichen kann, so dass nur für die korrekte LEI die Einwilligung erteilt wird (vgl. A_27621*).   

5 Funktionsmerkmale

5.1 Allgemeine funktionale Anforderungen PoPP-Modul

Hinweis: Die Anzahl der angezeigten Einträge in der Historie sollte konfigurierbar sein. Empfohlen wird die Darstellung der letzten zehn Ereignisse.

5.2 Auswahl der LEI/ Bestimmen der Telematik-ID

5.2.1 Favoriten

5.2.2 Verzeichnisdienstsuche

5.2.3 QR-Code

Wenn die Auswahl einer LEI mittels des Auslesens eines QR-Codes der LEI geschieht, gelten folgende Festlegungen zum Lesen und Prüfen des QR-Codes.

Der Inhalt des statischen QR-Codes wird als JSON-Struktur gemäß RFC 8259 repräsentiert. Der verwendete Zeichensatz ist UTF-8 nach RFC 3629. Die Erstellung des QR-Codes erfolgt gemäß ISO/IEC 18004. Die Erstellung erfolgt im Primärsystem (siehe [gemILF_PoPP_Client] und verwendet die Formatvorgaben in Tabelle [Tab_PoPP_Modul_Payload_stat_QRCode].

Tabelle 2: Tab_PoPP_Modul_Payload_stat_QRCode]: Payload QR-Code

Hinweis zu wpid: Die Festlegung ob eine WorkplaceID verwendet wird, und wie diese gebildet ist, erfolgt in der Verantwortung der LEI.

5.3 Auslösen der Erstellung eines PoPP-Token

5.3.1 Anforderungen PoPP-Modul bei Authentisierung eines Versicherten mit GesundheitsID

Die Abläufe der Erzeugung eines PoPP-Token über die Authentifizierung des Nutzers mit GesundheitsID sind in Kapitel [Detailierter Ablauf der PoPP-Token Generierung durch Authentifizierung Versicherter über ihre GesundheitsID] dargestellt. 

Das PoPP-Modul einer Anwendung löst durch Aufrufen der ZETA Client Schnittstelle die Erzeugung eines PoPP-Token für eine bestimmte LEI aus. Dabei prüft der ZETA Client, ob in der laufenden Session bereits eine Nutzer-Authentifizierung über die GesundheitsID durchgeführt wurde. Ist das nicht der Fall, so stößt der ZETA Client die Authentifizierung des Versicherten an. Der Ablauf der Authentifizierung wird durch die ZETA-Komponenten und dem sektoralen IDP mit seinem Authenticator-Modul abgebildet.

Nach erfolgreicher Authentifizierung des Versicherten wird vom ZETA Client der eigentliche HTTP-Request (siehe A_28501*) an den PoPP-Service erstellt. Dabei wird der vom PoPP-Modul erstellte HTTP-Request vom ZETA Guard HTTP-Proxy um

• Informationen zum Client aus der Client-Registrierung und
• KVNR und IK-Nummer der Krankenversicherung aus dem ID-Token der Versicherten Authentifizierung

erweitert, bevor der eigentliche Request gegen den PoPP-Service erfolgt.

Bevor der Ablauf zur Authentifizierung über die GesundheitsID erfolgen kann, muss das PoPP-Modul prüfen, ob überhaupt eine GesundheitsID an das Authenticator-Modul gebunden ist.

Hinweis: Da PoPP-Modul, ZETA Client und Authenticator-Modul Funktionen ein und derselben App sind, handelt es sich immer um die 1-App-Strategie, wenn diese Komponenten des ePA-FdV sind.

Hinweis: Die Schnittstelle ist in [I_PoPP_CheckIn_HID.yaml] definiert.

[<=]

Hinweis: Das Objekt zum Status der PoPP-Generierung enthält die Information, ob die Erstellung des PoPP-Token erfolgreich war.

• success - PoPP-Token wurde erzeugt und der LEI zugestellt
• pending - PoPP-Token wurde erzeugt und noch nicht zugestellt, da die LEI nicht online ist. Die Zustellung wird weiter versucht.
• cancelled - Prozess wurde aufgrund eines Fehlers oder wegen Überschreitung der maximalen Wartezeit (z.B. 72h) abgebrochen

Neben den Statusinformationen enthält das HTTP-Response-Objekt Detailinformationen zum Status oder zum aufgetretenen Fehler als "message". Die aufrufende Anwendung kann die Informationen verwenden, um z.B. den Nutzer zu informieren oder andere Anwendungsfälle anzubieten. Zur Identifikation des im PoPP-Service angelegten Datensatzes ist die ID des PoPP-Datensatz ebenfalls im vom PoPP-Service erstellten JSON-Objekt enthalten. 

5.3.2 Anforderungen PoPP-Modul für eGK-in-Fernversorgung

Die Abläufe für die Erstellung eines PoPP-Token mit dem Authentisierungsmittel "eGK" sind in Kapitel "Authentifizierung mit "eGK-in-Fernversorgung" dargestellt.

Die Authentifizierung einer "eGK-in-Fernversorgung" erfolgt durch den PoPP-Service. Dieser erstellt eine Challenge, welche mit dem privaten Schlüssel des CV-Zertifikats der eGK zu signieren ist. 

Der PoPP-Service erstellt APDU-Commands zur Signatur der Challenge sowie zum Auslesen der eGK und sendet diese sequentiell an das PoPP-Modul. Das PoPP-Modul sendet die APDU-Commands ungeändert an die eGK und deren Antwort zurück an den PoPP-Service.

Der PoPP-Service prüft die signierten Challenge und die von der eGK gelesenen Zertifikate (CV-Zertifikat, X.509-Zertifikat). Anschließend wird überprüft, ob CV-Zertifikat und X.509-Zertifikat zu ein und derselben eGK gehören. Zu diesem Zweck ruft der PoPP-Service die check-Schnittstelle der Hash-DB auf (siehe [gemSpec_PoPP_Service].

Wird durch die eGK-Hash-DB die Zusammengehörigkeit der Zertifikate bestätigt, können die Versichertendaten durch den PoPP-Service aus dem X.509-Zertifikat extrahiert und für die Generierung des PoPP-Token verwendet werden.

Die Kommunikation zwischen PoPP-Modul und PoPP-Service läuft über die ZETA-Komponenten.

Hinweis: Die Schnittstelle ist in [I_PoPP_CheckIn_eGK_Verification.yaml] definiert.

Hinweis: Das Objekt zum Status der PoPP-Generierung enthält die Information, ob die Erstellung des PoPP-Token erfolgreich war.

• success - PoPP-Token wurde erzeugt und der LEI zugestellt
• pending - PoPP-Token wurde erzeugt und noch nicht zugestellt, da die LEI nicht online ist. Die Zustellung wird weiter versucht.
• cancelled - Prozess wurde aufgrund eines Fehlers oder wegen Überschreitung der maximalen Wartezeit (z.B. 72h) abgebrochen

Neben den Statusinformationen enthält das HTTP-Response Objekt Detailinformationen zum Status oder zum aufgetretenen Fehler als "message". Die aufrufende Anwendung kann die Informationen verwenden, um z.B. den Nutzer zu informieren oder andere Anwendungsfälle anzubieten.

5.3.3 Kommunikation PoPP-Modul mit ZETA Client

ZETA Client ist die Zero Trust Komponente für ein FdV, welches in die Krankenversicherungs-App bzw. Authenticator-App integriert ist. Der ZETA Client überträgt bei der Initialisierung der Anwendung die Geräte- und App-Informationen an den ZETA Guard. 
Im laufenden Prozess kapselt der ZETA Client die gesamte Kommunikation zwischen der Anwendung auf dem Gerät des Versicherten und den Komponenten im Backend, u.a. auch zwischen PoPP-Modul und PoPP-Service. Der ZETA Client  steuert die Client-Authentisierung am ZETA Guard Authorization-Server und unterstützt die Nutzerauthentifizierung mit GesundheitsID.

In  [API ZETA Client] ist die API des ZETA Client und an dessen Verwendung spezifiziert. Das PoPP-Modul muss die bereitgestellten API-Schnittstellen des ZETA Client nutzen.

5.3.4 Kommunikation PoPP-Modul mit Drittanbieter-Apps

Drittanbieter-Apps, welche kein PoPP-Modul implementieren, können die Erstellung eines PoPP-Token über das PoPP-Modul in der App der Krankenversicherung anfordern. Dafür stellt das PoPP-Modul eine HTTP-Schnittstelle bereit, welche von der Drittanbieter-App aufgerufen werden kann.

Das Ergebnis der PoPP-Token-Erzeugung übermittelt das PoPP-Modul, indem es eine HTTP-Schnittstelle aufruft, welche die Drittanbieter-App zur Verfügung stellen muss (Ablaufbeschreibung siehe Anhang:  Ablaufdiagramme  und Flowdiagramme) .

Für Drittanbieter-Apps, welche ein PoPP-Modul und der ZETA Client implementieren, stellt das PoPP-Modul eine API-Schnittstelle bereit. Drittanbieter-Apps können die Erstellung eines PoPP-Token über die API-Schnittstelle des PoPP-Modul anfordern und erhalten als Ergebnis den Status zur PoPP-Token-Erstellung.

5.4 Verarbeitung des Ergebnisses der PoPP-Token-Erzeugung

Hinweis: Bei erfolgreicher PoPP-Token-Erstellung kann z.B. folgende Nachricht angezeigt werden "Berechtigung von <LEI-Name> erfolgreich.". Im Fehlerfall könnte die Information lauten: "Die Berechtigung von <LEI-Name> wurde aufgrund eines Fehlers <Fehlerinformation> abgebrochen".

Hinweis: Die ID des PoPP-Datensatzes ist Teil der Ergebnisinformationen der vom PoPP-Modul ausgelösten PoPP-Token-Erstellung. Konnte das PoPP-Datensatz erstellt aber ein PoPP-Token der LEI noch nicht zugestellt werden, ist der PoPP-Status "pending". In diesem Fall kann das PoPP-Modul über den HTTP-GET-Request zu einem späteren Zeitpunkt den Status beim PoPP-Service anfragen und den Benutzer entsprechend informieren.

6 Informationsmodell

Das abgebildete Informationsmodell bezieht sich ausschließlich auf die Anteile des Gesamtmodells für das Gerät des Versicherten und des PoPP-Service für das Ausstellen einen PoPP-Token nach Authentifizierung des Versicherten mit GesundheitsID oder Authentifizierung einer eGK über das PoPP-Modul in einer Krankenversicherungs-App auf dem Gerät des Versicherten. 

Abbildung 4: Bausteinsicht - Informationsmodell Gerät des Versicherten und PoPP-Service für Online-Anwendungsfälle zur PoPP-Token-Erstellung

7 Implementierungsleitfaden

Dieses Kapitel bietet Unterstützung für Hersteller, die den Online-Check-in mit PoPP in Apps umsetzen möchten. Ziel ist es, eine an den spezifischen Use Case angepasste Umsetzung zu ermöglichen. Der Inhalt gliedert sich wie folgt:

1. Einführung mit dem End-to-End Flow (Happy Path)
Zunächst wird der Happy Path beschrieben, der die Umsetzung des Online-Check-ins mit PoPP in einer Krankenversicherungs-App mit GesundheitsID und Scannen eines QR-Codes vor Ort darstellt. Die Vorgaben werden anhand der umzusetzenden Flow-Schritte aufgeführt.

2. Integration in Drittanbieter-Anwendungen
Neben Krankenversicherungen können auch Drittanbieter den Online-Check-in in Apps umsetzten. Hier werden zwei Umsetzungsvarianten mit unterschiedlichen Implementierungsaufwand für den Hersteller unterschieden:

• Integriertes PoPP-Modul: Das PoPP-Modul ist in der Drittanbieter-App integriert und ermöglicht die Durchführung des Online-Check-ins in der eigenen Drittanbieter-App (Bei Verwendung der GesundheitsID ist für den Vorgang der Autorisierung auch weiterhin ein App-Wechsel erforderlich).
  
• Nachnutzung eines anderen PoPP-Moduls (App2App): Die Drittanbieter-App nutzt das PoPP-Modul einer Krankenversicherungs-App nach und der eigentliche Online-Check-in wird in der Krankenversicherungs-App durchgeführt. Der Wechsel in den Krankenversicherungs-App und wieder zurück erfolgt hierbei automatisch.

3. Optionen und Alternativen
Neben der Darstellung des Happy Path werden Alternativen zu den einzelnen Flow-Schritten aus dem Happy Path aufgeführt, um die unterschiedliche Rahmenbedingungen von Use Cases zu berücksichtigen:

• Autorisierung: Variante zur Nutzung der eGK ohne PIN statt GesundheitsID
  
• Auswahl der LEI: Varianten, um Einrichtung auszuwählen statt QR-Code zu scannen
  
• Statusinformation: Varianten um über den Check-in-Status zu informieren
• Ersteinrichtung: Zusätzliche/Abweichende Flow-Schritt bei der erstmaligen Nutzung

4. Sprachliche Konsistenz und Terminologie
Abschließend werden Vorgaben zur Terminologie genannt.

7.1 End‑to‑End Flow (Happy Path)

Der Happy Path zeigt die Umsetzung des Online-Check-ins mit PoPP in einer Krankenversicherungs-App mit GesundheitsID und Scannen eines QR-Codes vor Ort. (Verweis auf PoPP-Service Spec. UC_PoPP_1a/UC_PoPP_1b).

Clickdummy / Screenshot

Visuelle Umsetzung des Online-Check-ins in einer Krankenversicherungs-App für einen Praxisbesuch mit GesundheitsID.

[Clickdummy] 

Ausgangssituation

Der Happy Path umfasst nicht die Ersteinrichtung. Folgende Punkte werden entsprechend vorausgesetzt.

• Krankenversicherungs-App mit PoPP-Modul ist auf dem Smartphone einer VER installiert.
• [Auth-Modul]: GesundheitsID ist auf dem Smartphone der VER eingerichtet, GesundheitsID ist gültig, VER hat SSO zugestimmt, hat Komfortfeatures zugestimmt und benutzt Biometrie. 
• [Auth-Modul]: VER hat Übermittlung von KVNR und IK-Nummer an den “Online-Check-in Service” einmalig zugestimmt. 
• VER hat der App Zugriff auf die Kamera erteilt.
• VER ist mit dem Smartphone in einer Gesundheitseinrichtung vor Ort und hat Internetzugriff.
• LEI stellt für den Check‑in einen QR‑Code‑Aufsteller am Empfang bereit. 
• VER wird am Empfang aufgefordert, den QR-Code aus der App mit integriertem PoPP-Modul zu scannen. 

Flow-Schritte und Vorgaben

Tabelle 3: Flow-Schritte und Vorgaben an den Online-Check-in im Happy Path.

7.2 Drittanbieter-Apps

Für Hersteller von Drittanbieter-Apps gibt es zwei Varianten einer versicherten Person den Online-Check-in zu ermöglichen. Die Umsetzungsvarianten sind dabei mit unterschiedlichen Implementierungsaufwand verbunden:

• Integriertes PoPP-Modul: Das PoPP-Modul ist in der Drittanbieter-App integriert und ermöglicht die Durchführung des Online-Check-ins in der eigenen Drittanbieter-App (Bei Verwendung der GesundheitsID ist für den Vorgang der Autorisierung auch weiterhin ein App-Wechsel erforderlich).
  
• Nachnutzung des PoPP-Moduls (App2App): Die Drittanbieter-App nutzt das PoPP-Modul einer Krankenversicherungs-App nach und der eigentliche Online-Check-in wird in der Krankenversicherungs-App durchgeführt. Der Wechsel in den Krankenversicherungs-App und wieder zurück erfolgt hierbei automatisch.

Neben der Umsetzung in Apps, ist auch die Umsetzung in (Web-) Anwendungen möglich.

7.2.1 Integriertes PoPP-Modul

Bei einem Online-Check-in aus einer Drittanbieter-App mit integrierten Popp-Modul heraus sind nicht alle im Happy Path aufgeführten Schritte erforderlich. Ausnahmen, wie bspw. Entfall des Flow-Schritts Auswahl der LEI, da eine Telematik-ID direkt in der Drittanbieter-App hinterlegt werden kann, sind in den jeweiligen Kapiteln benannt. 

Clickdummy/Screenshot

Visuelle Umsetzung des Online-Check-ins in einer Drittanbieter-App mit integriertem PoPP-Modul für Online-Dienste einer Apotheke mit eGK.

[Clickdummy]

Flowschritte und Vorgaben

• Abweichend vom Happy Path entfallen die Schritte Check-in und Auswahl der LEI.  
• Der Einstieg sowie der Ausstieg können individuell durch die Drittanbieter-App festgelegt werden. Eine Ausnahme bildet der Sonderfall (nur eGK): Wenn für eine andere Person eingecheckt werden soll, ist ein zusätzlicher Button "Für andere Person einchecken" in der Drittanbieter-App erforderlich. 

7.2.2 Nachnutzung des PoPP-Moduls (App2App)

Bei einem Online-Check-in aus einer Drittanbieter-App, die das PoPP-Modul einer anderen App nachnutzen (App2App) sind nicht alle im Happy Path aufgeführten Schritte erforderlich. Ausnahmen, wie bspw. Entfall des Flowschritts Auswahl der LEI, da eine Telematik-ID direkt in der Drittanbieter-App hinterlegt werden kann, sind in den jeweiligen Kapiteln benannt. 

Clickdummy / Screenshot

Visuelle Umsetzung des Online-Check-ins in einer Drittanbieter-App für Online-Dienste einer Apotheke mit eGK.

[Clickdummy] 

Visuelle Umsetzung des Online-Check-ins in einer Drittanbieter-App für Videosprechstunden mit GesundheitsID.

[Clickdummy] 

Ausgangssituation

• VER hat vorab ausgewählt, für wen der Online-Check-in durchgeführt werden soll, für sich oder als Vertreterin oder Vertreter.

Flow-Schritte und Vorgaben

• Abweichend vom Happy Path entfallen die Schritte Check-in und Auswahl der LEI.  
• Der Einstieg sowie der Ausstieg können individuell durch die Drittanbieter-App festgelegt werden. Eine Ausnahme bildet der Sonderfall (nur eGK): Wenn für eine andere Person eingecheckt werden soll, ist ein zusätzlicher Button "Für andere Person einchecken" in der Drittanbieter App erforderlich. 
• Die App der Krankenversicherung darf weder Drittanbieter-Apps noch gültige Telematik-IDs von dem Online-Check-in ausschließen. 

7.3 Alternative Flow-Schritte

Um die unterschiedliche Rahmenbedingungen von Use Cases an den Prozess zu berücksichtigen, werden im Folgenden Alternativen zu den Flow-Schritten abweichend des Happy Paths beschrieben.

7.3.1 Autorisierung

Neben der Autorisierung mittels GesundheitsID ist auch eine Autorisierung mit der eGK ohne PIN möglich. Hierbei ändert sich nur der Flow-Schritt Autorisierung.

Clickdummy/Screenshot

Visuelle Umsetzung des Flow-Schritts Autorisierung mit eGK ohne PIN als Screenshot.

Abbildung 5: Screenshot des Flow-Schritt Autorisierung mit eGK ohne PIN.

Ausgangsituation  

• VER hat keine GesundheitsID eingerichtet und verwendet stattdessen die eGK oder VER möchte als Vertreterin oder Vertreter agieren und die eGK der zu vertretenden Person verwenden (s. Sonderfall).

Flow-Schritte und Vorgaben

Tabelle 4: Flow-Schritte und Vorgaben an den Online-Check-in mit der Variante Autorisierung mittels eGK.

• Um der VER das kontaktlose Einlesen der eGK zu erleichtern, soll der VER die korrekte Positionierung der eGK in Abhängigkeit vom verwendeten Smartphone-Modell angezeigt werden. Für Smartphone-Modelle sollen allgemeine Hinweise zur optimalen Positionierung bereitgestellt werden, die auf den typischen Positionen der NFC-Antennen basieren.
• Sofern eine GesundheitsID eingerichtet und gültig ist, soll immer diese verwendet werden. 
• Sonderfall (Vertretung): Wenn die eincheckende Person als Vertreterin oder Vertreter handelt, muss diese Rolle bereits vorab in der App ausgewählt werden. In diesem Fall erfolgt die Autorisierung mit der eGK – auch dann, wenn eine GesundheitsID eingerichtet ist. 
• Nur für Drittanbieter-Apps, die das PoPP-Modul einer anderen App nachnutzen (App2App): Weicht die Krankenversicherung der zu vertretenden Person ab, soll die Krankenversicherungs-App der Vertreterin oder des Vertreters verwendet werden, da diese in der Regel bereits auf dem Smartphone der VER installiert ist. 

7.3.2 Auswahl der LEI

Die Auswahl der LEI für den Online-Check-in erfolgt in der Regel durch das Scannen eines QR-Codes. Alternativ kann auch eine Drittanbieter-App die Telematik-ID bereits in der Drittanbieter-App hinterlegen, sodass die Auswahl der LEI durch die VER entfällt. Wird keine Drittanbieter-App verwendet oder ist das Scannen einen QR-Codes nicht möglich, sollen der VER alternative Varianten zu Auswahl der LEI zur Verfügung stehen.

Clickdummy/Screenshot

Visuelle Umsetzung des Flow-Schritts Auswahl der LEI mit Verzeichnisdienst (VZD) Suche, Anzeige einer Historie der letzten Online-Check-ins, Favoriten und Detailscreens einer Einrichtung

Abbildung 6: Screenshot des Flow-Schritts Auswahl der LEI mit VZD-Suche, Anzeige einer Historie der letzten Online-Check-ins, Favoriten und Detailscreens einer Einrichtung.

Flow-Schritte und Vorgaben

• Anzeige einer Historie der letzten zehn Online-Check-ins inkl. Adresse
• Möglichkeit, Favoriten anzulegen und anzuzeigen (keine Adresse erforderlich)
• Volltextsuche im VZD inkl. Filtermöglichkeiten (nur Einrichtungen, DiGA und Krankenversicherungen/Kostenträger dürfen angezeigt werden). Suchergebnisse inkl. Adresse anzeigen. 

Tabelle 5: Filterkriterien für Suche im VZD - Einträgen auswählen/suchen

Tabelle 6: Filterkriterien für Suche im VZD - Einträge eingrenzen

Tabelle 7: Filterkriterien für Suche im VZD - Einträge darstellen

Erhält die versicherte Person die Check-in-Informationen außerhalb einer App (z.B. per E-Mail oder über eine Website), ist das Scannen eines QR-Codes auf demselben Gerät, auf dem auch die App der Krankenversicherung installiert ist, nicht ohne weiteres möglich. 

Daher sollen folgende Alternativen unterstützt werden: 

• QR-Code als Bild speichern und das gespeicherte Bild zur Erkennung hochladen
• Telematik-ID direkt kopieren
• Telematik-ID oder QR-Code über das systemweite Share-Sheet teilen

7.3.3 Statusinformation

Die VER wird nach Abschluss des Online-Check-ins darüber informiert, wie der Status des Online-Check-ins ist.

Flow-Schritte  und Vorgaben

Die Benachrichtigung über den Check-in-Status müssen kann von der App am PoPP-Service abgefragt und dem Nutzer dargestellt werden. 

7.3.4 Ersteinrichtung

Bei der erstmaligen Verwendung des Online-Check-ins sind zusätzliche Flow-Schritte erforderlich, die sich je nach Rahmenbedingungen des Use Cases unterscheiden.

Clickdummy/Screenshot

Visuelle Umsetzung des Online-Check-ins in einer Krankenversicherungs-App für einen Praxisbesuch mit GesundheitsID inkl. zusätzlicher Flow-Schritte für die Ersteinrichtung: Einrichtung der GesundheitsID und Zustimmung der VER zur Nutzung des Online-Check-ins.

[Clickdummy] 

Visuelle Umsetzung des Online-Check-ins in einer Drittanbieter-App (App2App) für einen Online-Dienst einer Apotheke mit eGK inkl. zusätzlicher Flow-Schritte für die Ersteinrichtung: Auswahl der Krankenversicherungs-App, CAN-Eingabe und Zustimmung der VER zur Nutzung des Online-Check-ins.

[Clickdummy] 

Visuelle Umsetzung des Online-Check-ins in einer Drittanbieter-App (App2App) für Videosprechstunden mit GesundheitsID inkl. zusätzlicher Flow-Schritte für die Ersteinrichtung: Auswahl der Krankenversicherungs-App, Einrichtung GesundheitsID und Zustimmung der VER zur Nutzung des Online-Check-ins.

[Clickdummy] 

Visuelle Umsetzung eines zusätzlichen Flow-Schritts nach erstmaliger Bereitstellung des Online-Check-in in einer App, der auf die neue Online-Check-in-Funktion hinweist.

Abbildung 7: Screenshot der auf die neue Online-Check-in-Funktion hinweist.

Flow-Schritte  und Vorgaben

• Bei der erstmaligen Bereitstellung des Online-Check-ins in der App soll der VER ein Tooltip eingeblendet werden, der auf die neue Online-Check-in-Funktion hinweist und sie kurz erklärt. 
• Bei Nutzung des Online-Check-ins aus einer Drittanbieter-App, die das PoPP-Modul einer anderen App nachnutzt (App2App), muss in dieser zunächst die Krankenversicherung ausgewählt, damit die passende App der Krankenversicherung geöffnet wird. Ab der zweiten Nutzung soll die Krankenversicherung nicht mehr ausgewählt werden müssen.
• Bei der Erstverwendung muss die VER einwilligen, dass für den Online-Check-in erforderliche Daten an den Online-Check-in-Service übermittelt werden.
• Bei der Erstverwendung mit eGK muss die VER einmalig die CAN eingeben. Diese soll gespeichert werden, damit sie ab der zweiten Nutzung bereits vorausgefüllt ist. 
• Wird die eigene eGK verwendet, soll der VER, die Möglichkeit angeboten werden, stattdessen auch eine GesundheitsID einzurichten. Nach der Authentisierung mit eGK soll eine Abfrage zur Einrichtung einer GesundheitsID erscheinen. Die Abfrage soll nur bei den ersten drei Online-Check-ins angezeigt werden.
• Der Online-Check-in muss in der Krankenversicherungs-APP ohne zusätzlichen Account und ohne nicht erforderliche Einrichtungsschritte möglich sein. Davon ausgenommen sind gesetzlich notwendige Schritte, beispielsweise die Zustimmung zu Nutzungsbedingungen. 

7.4 Terminologie

Die Texte dürfen geringfügig angepasst werden, etwa wenn in der App das „Du“ genutzt wird. 

8 Test

Um automatisierte Zulassungstests zu ermöglichen, muss das PoPP-Modul eine Testtreiber-Schnittstelle implementieren.

8.1 Schnittstelle für Testtreiber

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

9.5.2 Weitere Dokumente

10 Anhang B - Ablaufbeschreibungen

10.1 Ablaufdiagramme

10.1.1 Allgemeiner Ablauf der PoPP-Token-Generierung durch Authentifizierung Versicherter über ihre GesundheitsID

Abbildung 8: Laufzeitsicht - Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung über die GesundheitsID

10.1.2 Allgemeiner Ablauf der PoPP-Token-Generierung durch Authentifizierung der eGK über den PoPP-Service

Das nachfolgende Aktivitätsdiagramm stellt den allgemeinen Ablauf mit den beteiligten Komponenten dar.

Abbildung 9: Laufzeitsicht - Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung der eGK über den PoPP-Service

10.1.3 Detailablauf "ZETA Client Initialisierung"

Bei der Initialisierung des ZETA Client wird, wenn noch nicht bekannt, eine Client-Registrierung und App-Attestierung im ZETA Guard vorgenommen. Wenn der Ablauf zum PoPP-Modul zurückgekehrt ist, ist sowohl das Geräte als auch die App mit dem integrierten PoPP-Modul im ZETA Guard registriert.

Abbildung 10: Laufzeitsicht - Initialisierung ZETA Client 

10.1.4 Detailablauf "FHIR-VZD-Anfrage"

Die Abfrage des FHIR-VZD nach Daten zu LEIs muss die Anwendungsfälle unterstützen:

• Die Telematik-ID ist bekannt und es müssen für die Einwilligung des Nutzers weitere Daten zur LEI ermittelt werden.
• Die Telematik-ID ist nicht bekannt und es muss mit eines Suche auf Basis von bekannten Suchparametern (Name der LEI, Adresse/PLZ der LEI, u.ä.) durchgeführt werden. Als Ergebnis werden alle Daten der LEI für die Einwilligung des Nutzers und die Telematik-ID der LEI erwartet.

Die Unterscheidung beider genannter Fälle erfolgt lediglich aufgrund des formulierten Requests an den FHIR-VZD.

Die FHIR-VZD-Abfrage erfolgt durch das PoPP-Modul über die ZETA-Komponenten durch den PoPP-Service. Das PoPP-Modul erstellt den eigentlichen FHIR-VZD Search Request auf Basis der im PoPP-Modul vorhanden Daten zur LEI. Der FHIR-VZD Search Request wird über die ZETA-Komponeten an den PoPP-Service propagiert. Dabei stellen die ZETA-Komponenten auf Basis der Client-Registrierung ein Client Access-Token aus, mit dem der Suchauftrag beim PoPP-Service angereichert wird.

Der PoPP-Service ist ein registrierter FHIR-VZD-Client und führt die Suche mit dem übergebenen FHIR-VZD Search Request aus. Die ZETA-Komponenten übertragen das Suchergebnis an das PoPP-Modul zur weiteren Verarbeitung.

Das PoPP-Modul filtert das Suchergebnis und zeigt dem Nutzer den Datensatz zur Erteilung der Einwilligung in die Datennutzung an. 

Abbildung 11: Laufzeitsicht - Ermittlung Suchkriterien, VZD-Datenabruf mit Suchkriterien und Einwilligung in die Datenweitergabe

10.1.5 Detailablauf "Information zum Status der PoPP-Token-Generierung an das PoPP-Modul"

Nach Abschluss wird der Status der PoPP-Token-Generierung an das PoPP-Modul übermittelt. Der Status wird in der Response zum ausgeführten Request über den ZETA Guard HTTP-Proxy an den ZETA Client zurückgegeben. Der ZETA Client ruft daraufhin die vorgesehene callBack-Methode am PoPP-Modul mit dem Response-Objekt als Parameter auf.

Abbildung 12:  Laufzeitsicht - Information zum Status der PoPP-Token-Generierung an das PoPP-Modul

10.2 Flowdiagramme

10.2.1 Detaillierter Ablauf der PoPP-Token-Generierung durch Authentifizierung Versicherter über ihre GesundheitsID

Das Sequenzdiagramm "Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung über die GesundheitsID" stellt den vollständigen Ablauf der PoPP-Token-Generierung für den Fall dar, dass ein Versicherter über seine GesundheitsID authentifiziert wird.

Abbildung 13: Laufzeitsicht - Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung über die GesundheitsID

10.2.2 Beschreibung der Schritte zur PoPP-Token-Erstellung bei Authentifizierung Versicherter mit ihrer GesundheitsID

Die Tabelle [Beschreibung der Schritte zur PoPP-Token-Erstellung bei Authentifizierung des Versicherten über seine GesundheitsID] beschreibt die einzelnen Schritte vom Start der PoPP-Token-Erstellung durch den Nutzer einer Fachanwendung bis zur Darstellung des Ergebnis der PoPP-Token-Erstellung.

Tabelle 8: Beschreibung der Schritte zur PoPP-Token-Erstellung bei Authentifizierung des Versicherten über seine GesundheitsID

10.2.3 Detaillierter Ablauf der PoPP-Token-Generierung durch Authentifizierung der eGK über den PoPP-Service

Das Sequenzdiagramm "Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung der eGK über den PoPP-Service" stellt den vollständigen Ablauf der PoPP-Token-Generierung für den Fall dar, dass ein Versicherter die Authentifizierung einer eGK durchführt.

Abbildung 14: Laufzeitsicht - Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App und Authentifizierung der eGK über den PoPP-Service

10.2.4 Beschreibung der Schritte zur PoPP-Token-Erstellung bei Authentifizierung einer eGK

Die Tabelle [Beschreibung der Schritte zur PoPP-Token-Erstellung aus einer Anbieter-App und Authentifizierung der eGK über den PoPP-Service] beschreibt die einzelnen Schritte vom Start der PoPP-Token-Erstellung durch den Nutzer einer Fachanwendung bis zur Darstellung des Ergebnis der PoPP-Token-Erstellung.

Tabelle 9: Beschreibung der Schritte zur PoPP-Token-Erstellung aus einer Anbieter-App und Authentifizierung der eGK über den PoPP-Service

10.2.5 Detaillierter Ablauf der PoPP-Token-Generierung durch Authentifizierung der eGK über den PoPP-Service mit PoPP-Modul in einer Drittanbieter-App

Das Sequenzdiagramm "Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App mit PoPP-Modul und Authentifizierung der eGK über den PoPP-Service" stellt den vollständigen Ablauf der PoPP-Token-Generierung für den Fall dar, dass ein Versicherter die Authentifizierung einer eGK durchführt und PoPP-Modul und ZETA Client in der Drittanbieter-App implementiert sind.

In diesem Ablauf findet kein APP-Sprung statt.

Abbildung 15: Detaillierter Ablauf der PoPP-Token-Generierung aus einer Anbieter-App mit PoPP-Modul und Authentifizierung der eGK über den PoPP-Service

10.2.6 Beschreibung der Schritte zur PoPP-Token-Erstellung bei Authentifizierung einer eGK mit PoPP-Modul in einer Drittanbieter-App

Die Tabelle [Beschreibung der Schritte zur PoPP-Token-Erstellung aus einer Anbieter-App mit PoPP-Modul und Authentifizierung der eGK über den PoPP-Service] beschreibt die einzelnen Schritte vom Start der PoPP-Token-Erstellung durch den Nutzer einer Fachanwendung bis zur Darstellung des Ergebnisses der PoPP-Token-Erstellung.

Tabelle 10: Beschreibung der Schritte zur PoPP-Token-Erstellung aus einer Anbieter-App mit PoPP-Modul und Authentifizierung der eGK über den PoPP-Service

11 Anhang C – Offene Punkte, Fragen

11.1 Offene Punkte