Telematikinfrastruktur 2.0

Spezifikation

PoPP (Proof of Patient Presence)

-Modul

    

     

      
Version
      
0.5.0
     
     

      
Revision
      
1105684
     
     

      
Stand
      
20.01.2025
     
     

      
Status
      
in Bearbeitung
     
     

      
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 zu Herstellung, Test und Betrieb des Produkttyps Proof of Patient Presence Frontend des Versicherten (PoPP-Modul).

Diese basieren auf dem Technischen Konzept [gemKPT_PoPP] und weitergeführten Abstimmungen mit den Gesellschaftern der gematik als Konsumenten der gesamten PoPP-Lösung, insbesondere zu Themen bei Nutzung der GesundheitsID. 

Das PoPP-Modul bietet Nutzern mit GesundheitsID den Zugang zur PoPP-Lösung. Der PoPP-Service erzeugt die Bestätigung eines Versorgungskontextes in Form des kryptographisch gesicherten PoPP-Token. Dieses bestätigt, dass ein bestimmter Versicherter mit einer bestimmten Leistungserbringerinstitution (LEI) zusammengekommen ist.

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

• Der PoPP-Service ist der Server Anteil der PoPP-Lösung.
• Die PoPP-Clients, die als Teil der Primärsysteme implementiert werden.
• Apps, die bei der mobilen Nutzung der eGK in die Kommunikation zur Erstellung der PoPP-Token eingebunden sind. 

Die Spezifikationen oder Beschreibungen dieser Komponenten erfolgt in anderen Dokumenten.

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller und Betreiber von Frontends der Versicherten für PoPP, insbesondere die Kassen und ihre Auftragnehmer.

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

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. 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 <<optional; Kasten mit "Offener Punkt" in das entsprechende Kapitel einfügen>>

2 Systemüberblick/Systemkontext

Ein ausführlicher Systemüberblick und eine Darstellung der Use-Cases und Anwendungsfälle ist in [gemSpec_PoPP_Service] dargestellt.

3 Übergreifende Festlegungen

Hinweis: Eine OCSP-Response wird im Handshake vom PoPP-Service mitgeliefert (Unterstützung von OCSP-Stapling [RFC 6066]).

4 Funktionsmerkmale

4.1 Anforderungen PoPP-Modul als OAuth-Client

4.2 Anforderungen PoPP-Modul an TAN und QR-Code

Hinweis: Mit technischen Möglichkeiten ist neben der Darstellung als QR-Code z.B. das Anbieten eines Eingabefeldes für 6-stellige TAN im PoPP-Modul einer App und die Übertragung zum PoPP-Client durch dessen backend gemeint. Da es je nach Anwendungsfall und Anwendungen unterschiedliche Möglichkeiten einer technischen Realisierung gibt, ist die Anforderung allgemein gehalten.

Hinweis: Die Anforderung A_26558* erweitert A_27029* hinsichtlich auf jeden Fall zu unterstützenden Möglichkeiten zur TAN Übertragung.

4.3 Anforderungen PoPP-Modul für GesundheitsID

Die Abläufe des Check-in über die Authentifizierung des Nutzers mit GesundheitsID sind in [gemSpec_PoPP_Service] Kapitel "Mobiler Check-in mit GesundheitsID" dargestellt. 

Aus dem PoPP-Modul einer Anwendung wird ein Authorization Request an den PoPP-Service Authorization Server  gesendet. Dieser löst durch einen Pushed Authorization Request (PAR) die Durchführung der Nutzerauthentifizierung über den sektoralen IDP aus.

Nach erfolgreicher Nutzerauthentifizierung wird vom PoPP-Service Authorization Server ein "ehealth-check" Access Token für das PoPP-Modul ausgestellt, der dieses zum Aufruf des PoPP-Services Resource Server autorisiert.

Der PoPP-Services Resource Server stellt dem anfragenden PoPP-Modul je nach Anwendungsfall eine "kurze" TAN oder ein TAN-Set mit "langen" TANs zum Einlösen in einer LEI aus.

Tabelle 1: Claims des Authorization Request zur Erlangung eines "ehealth-check" Access Token (informativ)

{ "authorization_details": [
    { "actorId": "<Telematik-ID Leistungserbringer>" }
]}

4.4 Anforderungen PoPP-Modul für eGK (mobil)

Die Abläufe des Check-in über durch die Authentisierung einer eGK sind in [gemSpec_PoPP_Service] Kapitel "Mobiler Check-in mit eGK" dargestellt.

Die Funktion eGK (mobil) ist nur für PoPP-Module zulässig, die in Drittanbieter-Apps integriert sind. Für PoPP-Module, die in Kassen-Apps integriert sind, soll diese Funktion nicht verfügbar sein.

Aus dem PoPP-Modul einer Anwendung wird ein Authorization Request an den PoPP-Service Authorization Server gesendet. Dieser stellt dem PoPP-Modul ein "card-check" Access Token aus, mit dem das PoPP-Modul seine Requests an den PoPP-Service Resource Server autorisiert.

Der PoPP-Service Resource Server führt über das PoPP-Modul die Prüfung der eGK durch.  Der PoPP-Services Resource Server stellt dem anfragenden PoPP-Modul je nach Anwendungsfall eine "kurze" TAN oder ein TAN-Set mit "langen" TANs zum Einlösen in einer LEI aus.

Tabelle 2: Claims des Authorization Request zur Erlangung eines "card-check" Access Token (informativ)

{ "authorization_details": [
    { "actorId": "<Telematik-ID Leistungserbringer>" }
]}

5 Informationsmodell

Eine gesondertes Informationsmodell der durch den Produkttypen verarbeiteten Daten wird nicht benötigt.

6 Verteilungssicht

Die Apps mit integriertem PoPP-Modul werden über die bekannten App-Stores den Nutzern zur Verfügung gestellt.

7 Implementierungsleitfaden für PoPP-Modul

In diesem Kapitel finden sich Hinweise und Empfehlungen der gematik an PoPP-Modul Hersteller... 

7.1 QR-Code

Für die Übertragung der TAN vom PoPP-Modul zum PS werden QR-Codes verwendet.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

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

8.5.2 Weitere Dokumente