Proof of Patient Presence (PoPP)

Der Proof of Patient Presence (PoPP) ist ein Anwesenheitsbeleg mittels TI-Dienst als zukünftige Nachfolgeversion der derzeit beim Abruf von E-Rezepten mit der eGK eingeführten VSDM++-Lösung.

Zukünftig kann der PoP-P auch als Nachweis eines bestehenden Behandlungskontextes dienen, der dann durch Übergabe der eGK in der medizinischen Einrichtung erfolgen kann oder auch mittels GesundheitsID (auch ohne physische Präsenz in der med. Einrichtung).

Spezifikation

Für eine Lösung mit der Gesundheits-ID gibt es noch keine Spezifikation. Könnte ähnlich ablaufen wie beim Online Check-in (OCI)

Voraussichtliche PoPP-Lösung (Grobkonzeption)

Die PoPP-Lösung liefert den Nachweis, dass ein Versicherter sich zu einem bestimmten Zeitpunkt in einem Behandlungskontext mit einer LEI befindet mittels eines PoPP-Service. Aufgabe des PoPP-Service ist dabei die Authentifizierung der LEI und die Authentifizierung der GesundheitsID bzw. eGK des Versicherten als Bestätigung des Behandlungskontextes. Das Ergebnis ist ein PoPP-Token, der dem LEI zum autorisierten Zugriff auf Daten des Versicherten in einer TI-Anwendung bzw. einem TI-Fachdeinst dient.

Durch einen PoPP-Service, der ein sog. (authentisches) PoPP-Token zurück liefert, mit dem sich dann der anfordernde Leistungserbringer an einem TI-Fachdienst zwecks Datenzugriff autorisieren kann, wird der Vorgang der Authentifizierung von der Autorisierung entkoppelt.

Zur Erstellung eines validen, signierten PoPP-Token müssen im PoPP-Service vorliegen:

(authentizitätsgeprüfte) KVNR des Versicherten
(authentizitätsgeprüfte) Telematik-ID der LEI.

In der Übergangszeit von VSDM 1.0 auf VSDM 2.0 wird vom PoPP-Service auch ein VSDM++-Prüfnachweis erstellt. Dabei muss eine Verwendung dieses Prüfnachweises für die Abrechnung ausgeschlossen werden, da keine Online-Prüfung des Versicherungsstatus stattgefunden hat.

PoPP-Token

Das PoPP-Token wird in der Antwort des PoPP-Service auf einen Request des PoPP-Clients (im PS) geliefert und beinhaltet:

KVNR (als Identitätsattribut des Versicherten); inkl. der Info, ob die Quelle die eGK oder GesundheitsID des Versicherten ist
IK-Nummer (Kassenzugehörigkeit des Versicherten)
Telematik-ID (als Identitätsattribut der Institution)
Zeitstempel der Token-Erstellung
Signatur über alle Daten
X.509-Zertifikat (inkl. Public Key) zur Verifikation der Signatur

Das PoPP-Token ist kryptografisch abgesichert und über (die in Zero-Trust definierten) Token-Binding-Mechanismen an die konkrete Instanz des Primärsystems bzw. die Session zwischen PoPP-Client und PoPP-Service gebunden (DPoP¹⁾).

Es handelt sich um ein JSON Web Token (JWT), das mit JSON Web Signature (JWS) signiert wird.

PoPP mit eGK

Architektur in der LEI

C2S mit Standard-KT oder eHealth-KT und Konnektor/TI-Gateway.

Architektur mobil

Nach Eingabe der CAN nutzt die eGK das PACE-Protokoll
⇒ Die Zugriffsregeln der eGK verhindern dann den zusätzlichen Aufbau eines Trusted Channel zum PoPP (zusätzlich zum PACE-Kanal).
⇒ Nutzungsszenarien ohne PIN sind mit dem Versicherten-Smartphone zumindest initial nicht umsetzbar. Sicherstellung soll mit der Weiterentwicklung der eGK zur G3 erfolgen.

Damit entfallen faktisch auch alle telemedizinischen Szenarien

PoPP mit GesundheitsID

Architektur in der LEI

Lösung über QR-Code (Consent Code) und Authentifizierung des Versicherten ggü. dem PoPP-Service mittels GesundheitsID mit anschließender Bestätigung der an die LEI zu übermittelten Daten für das PoPP-Token.

Architektur mobil

Authentisierung des Versicherten mittels Smartphone (via GesundheitsID) über Link der LEI (QR-Code). Bei Öffnen des Links wird der Authentifizierungsworkflow über den sektoralen IdP gestartet. Der Link ist zudem eine einmalig nutzbare Einladung, die im Auslösen einer Autorisierungsanfrage resultiert. Das Verfahren ist analog zum OCI.

Telemedizinische Szenarien laufen entsprechend bspw. über die Zurverfügungstellung eines Link im Chat.

Datenschutz und Informationssicherheit

Um zu verhindern, dass der Betreiber des PoPP-Service sich selbst Token ausstellt und zwecks Profilbildung Zugriff auf die Daten hat wird eine VAU genutzt sowie ein sicherer Schlüsselspeicher (HSM).

Alte Lösung

Die gematik hat am 15.02.2023 eine Featurespezifikation mit zwei Lösungsalternativen für einen Anwesenheitsbeleg vor dem Abruf von E-Rezepten mit der eGK (vorab) veröffentlicht. Eine davon ist der PoPP (Kap. 3). Die gematik arbeitet jedoch an gerade einer vollständigen Spezifikation ohne Konnektor-Beteiligung (s.o.)

Im Rahmen der vorgeschlagenen Lösung kapselt ein sog. Miniservice-PoPP die Signaturerstellung und hält das zugehörige Zertifikat. Eine sog. Fachlogik-PoPP im (Basis-)Konnektor setzt die notwendigen Zugriffe auf SMC-B und eGK um.

Grob gesagt erstellt der Konnektor (Fachlogik-PoPP, Operation GetPoPP-Token) ein Token (bzw. dessen Hash), das folgende vom Konnektor geprüfte Testate enthält:

KVNR der (mittels C2C zwischen SMC-B und eGK) auf Echtheit und (mittels Statusprüfung von DF.HCA und OCSP-Abfrage auf) Sperrung geprüften eGK
Telematik-ID der SMC-B(, die zur Echtheitsprüfung der eGK verwendet wurde)
Systemzeit der Prüfung.

Das Token sendet der Konnektor (mittels beidseitig authentifiziertem TLS verschlüsselt) an den Miniservice-PoPP zur Signatur, welcher das signierte Token an den Konnektor zurücksendet. Der Konnektor sendet das signierte Token dann abschließend an das Primärsystem zurück. Die skizzierte Lösung ist TI2.0-kompatibel, da lediglich Identifier im Token genutzt werden, die auch mit TI2.0-Technologien nutzbar sind.

Folgende Abbildung zeigt den genauen Ablauf mittels eines Sequenzdiagramms.

Das AVS nutzt dieses PoPP-Token dann zum Abruf aller offenen Rezepte für die KVNR im Token vom E-Rezept-Fachdienst. Der Fachdienst prüft dann

die Gültigkeit der PoPP-Token-Signatur
die Übereinstimmung der Telematik-ID im AccessToken des AVS mit der des PoPP-Token
die zeitliche Nähe des Ausstellungszeitpunkts des PoPP-Token zum aktuellen Zeitpunkt

Ergänzend prüft der E-Rezept-Fachdienst periodisch die Gültigkeit der Signaturzertifikate des PoPP-Service.

¹⁾

RFC 9449