Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dighealth:ti:popp [2026/02/02 08:59] – [Ausblick gesamt] fjh
+++ dighealth:ti:popp [2026/03/13 16:10] (aktuell) – [Umsetzungen] fjh
@@ Zeile 1: / Zeile 1: @@
 ====== Proof of Patient Presence (PoPP) ======
-Der Proof of Patient Presence (PoPP) ist ein Anwesenheitsbeleg mittels TI-Dienst als zukünftige Nachfolgeversion der derzeit beim [[dighealth:ti:erp:f_abrufegk|Abruf von E-Rezepten mit der eGK]] eingeführten [[dighealth:ti:vsdm#vsdm|VSDM++-Lösung]], der auch als Nachweis eines bestehenden Behandlungskontextes dient.
+Der Proof of Patient Presence (PoPP) ist ein Anwesenheitsbeleg mittels TI-Dienst als zukünftige Nachfolgeversion der derzeit beim [[dighealth:ti:erp:f_abrufegk|Abruf von E-Rezepten mit der eGK]] eingeführten [[dighealth:ti:vsdm#vsdm|VSDM++-Lösung]], der auch als Nachweis eines bestehenden Behandlungskontextes dient. Mit der geplanten Abschaltung von VSDM 1.0 entfällt der von Leistungserbringende genutzte Prüfnachweis als Nachweis des Behandlungskontextes zudem gänzlich. Die Nachfolgetechnologie PoPP setzt auf einem Basisdienst der TI 2.0 (PoPP-Service) auf und basiert auf den Prinzipien der TI 2.0. PoPP wird neben der eGK auch die GesundheitsID unterstützen, die gem. § 291 Abs. 8 SGB V in Verbindung mit VSDM 2.0 ab dem 01.01.2027 als Versicherungsnachweis gefordert ist.
 Die Spezifikation und Umsetzung erfolgt in **zwei Stufen**.
@@ Zeile 7: / Zeile 7: @@
 **Stufe 1** umfasst folgende Anwendungsfälle:
   * Nutzung der eGK in Versorgungseinrichtungen
-  * Nutzung der eGK in mobilen Szenarien
+  * Nutzung der eGK in mobilen Szenarien (bspw. Haus- und Heimbesuche)
 => Keine Nutzung der GesundheitsID!
@@ Zeile 45: / Zeile 45: @@
   * gesund.de plant PoPP-Entwicklung als Nachfolger von CardLink ein.((https://www.apotheke-adhoc.de/nachrichten/detail/e-rezept/gesundde-naechste-loesung-fuer-e-rezepte/#.))
+  * Die Umsetzung einer PoPP-Lösung bietet beispielsweise die Firma Service.health mit ihrer Open-Source-Implementierung von PoPP ohne Lizenzgebühren.((https://www.apotheke-adhoc.de/nachrichten/detail/e-health/popp-cardlink-nachfolger-auf-der-zielgeraden/#.))
 ===== Spezifikation =====
+<note important>03.03.2026: Gesellschafterversammlung gibt PoPP-Spec frei: https://e-health-com.de/details-news/gruenes-licht-fuer-spezifikation-des-popp-dienstes/</note>
 <note>Spezifikation der Stufe 2 als [[https://gemspec.gematik.de/prereleases/Draft_PoPP_26_1/|Prerelease PoPP_26_1]] (26.01.2026) veröffentlicht</note>
@@ Zeile 56: / Zeile 62: @@
   * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_Smartcards_24_3/|Draft_Smartcards_24_3]] (20.01.2025)
   * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_PoPP_25_1/|Draft_PoPP_25_1]] (16.06.2025)
-  * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_PoPP_25_2/|Draft_PoPP_25_2]] (21.11.2025)
+  * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_PoPP_25_2/|Draft_PoPP_25_2]] (21.11.2025) => Stufe 1
-  * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_PoPP_26_1|Draft_PoPP_26_1]] (26.01.2026)
+  * Prerelease [[https://gemspec.gematik.de/prereleases/Draft_PoPP_26_1|Draft_PoPP_26_1]] (26.01.2026) => Stufe 2
 Ursprünglich war eine Lösung für den CheckIn mit FdV vorgesehen, bei der der Versicherte den CheckIn anstößt, indem er sich am PoPP-Service authentisiert und anschließend eine TAN als One-Time-Passwort (OTP) erhält, mit der er im Folgenden in der Leistungserbringerinstitution (LEI) den Versorgungskontext herstellen kann. In der LEI wird das OTP entweder als Barcode eingescannt (Scanner notwendig!) oder in einer kurzen Version manuell eingegeben (wenn die LEI vorab bekannt war). Mittels dieses OTP holt sich die LEI, dann den Versorgungskontext als PoPP-Token vom PoPP-Service.
@@ Zeile 161: / Zeile 167: @@
 <note>Das PoPP-Token wird als ein self-contained JWT OAuth2 Access-Token abgebildet. Die Signatur erfolgt dann mit JSON Web Signature (JWS).</note>
+<note important>Bei PoPP mit eGK handelt es sich - anders als bei PoPP mit GesundheitsID - nicht um eine Authentifizierung, sondern um eine "passive" Verifikation.</note>
@@ Zeile 270: / Zeile 278: @@
 **Mögliche Lösung**
+Über eine eGK-Hash-Datenbank wäre diese Szenario auch für eGK der Generation 2.1 möglich. Darüber kann man dann die Frage beantworten: Stammt ein vorgelegtes CV-Zertifikat und ein vorgelegtes X.509 Zertifikat aus ein und derselben eGK. (s.o.)
+== Statischer QR-Code ==
+  * Weiterverwendung etablierter Verfahren wie eEB und OCI
+  * Einheitlichkeit: statischer QR-Code sollte KIM-Adresse und TelematikID beinhalten
+  * URL oder keine URL (Nur über App scanbar)
+  * man benötigt keine Geräte in der LEI zur Anzeige von dynamisch generierten QR-Codes
+  * Gängigster Anwendungsfall wird der "Vor-Ort-Check-in" sein, aber relevant und zu betrachten sind auch Pre-Check-In mit oder ohne Terminvereinbarung und das Nachreichen von Quittungen (zeitliche ENtkopplung der Aktivitäten von LE und Versichertem)
+== Grenzfälle der Nutzung ==
+  * Notfallszenarien mit GesundheitsID und eGK
+  * Vertreterszenarien mit GesundheitsID und eGK
+== Weiterenwicklung ==
+  * EUDI-Wallet für LEI
+  * EUDI-Wallet für Versicherte
+<note warning>Die Weiterentwicklung der Leistungserbringer-Identität (HBA) spielt im Kontext PoPP keine Rolle, da der PoPP-Token derzeit ausschließlich Informationen der Institution enthält und auch nur für entsprechende Nutzungsszenarien eingesetzt wird. Es sind keine Anforderungen an die PoPP-Lösung bekannt, die eine eindeutige Nutzerauthentifizierung mittels HBA (oder Nachfolgetechnologie) bedarf.</note>
-=== Material ===
-<note important>Über eine eGK-Hash-Datenbank (s. eGK-Hash-Datenbank, Kap. [[https://gemspec.gematik.de/prereleases/Draft_PoPP_25_1/gemSpec_PoPP_Service_V1.0.0_CC2/#6.2.1.9|6.2.1.9]]) wäre diese Szenario auch für eGK der Generation 2.1 möglich. Darüber kann man dann die Frage beantworten: Stammt ein vorgelegtes CV-Zertifikat und ein vorgelegtes X.509 Zertifikat aus ein und derselben eGK.</note>