Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dighealth:ti:popp [2026/01/28 16:14] – [Spezifikation] 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 124: / Zeile 129: @@
 <note important>**Nicht unterstützte Anwendungsfälle/Szenarien**
-Bei den nicht unterstützten Anwendungsfällen handelt es sich um Fälle, bei denen der Versicherte eine eGK über sein eigenes Gerät **per NFC** anbindet. Es kann bei der Kontaktloskommunikation mit den eGK G2.1 im Gegensatz zum kontaktbehafteten Ansprechen nicht sichergestellt werden, dass die Daten "authentisch" aus der eGK ausgelesen werden.((Zum Hintergrund: Nach Eingabe der CAN nutzt die eGK das PACE-Protokoll
+Bei den nicht unterstützten Anwendungsfällen handelt es sich um Fälle, bei denen der Versicherte eine eGK über sein eigenes Gerät **per NFC** anbindet. Es kann bei der Kontaktloskommunikation mit den eGK G2.1 im Gegensatz zum kontaktbehafteten Ansprechen nicht sichergestellt werden, dass die Daten "authentisch" aus der eGK ausgelesen werden.
-⇒ Die Zugriffsregeln der eGK verhindern dann den zusätzlichen Aufbau eines Trusted Channel zum PoPP (zusätzlich zum PACE-Kanal) bzw. das Einlesen des X.509-Zertifikat mit den benötigten Informationen zum Versicherten für den CheckIn aus dem bestehenden CV-Kanal.
+⇒ Nutzungsszenarien ohne PIN sind mit dem Versicherten-Smartphone zumindest initial nicht umsetzbar. Sicherstellung soll mit der Weiterentwicklung der eGK zur G3 erfolgen. Bei der voraussichtlichen Verfügbarkeit der PoPP-Lösung werden jedoch ausschließlich G2.1 Karten im Feld sein.
-⇒ Nutzungsszenarien ohne PIN sind mit dem Versicherten-Smartphone zumindest initial nicht umsetzbar. Sicherstellung soll mit der Weiterentwicklung der eGK zur G3 erfolgen.)) Eine Änderung dieser Zugriffsregeln lassen sich erst für eine neue Kartengeneration, z.B. eGK G3, ändern. Bei der voraussichtlichen Verfügbarkeit der PoPP-Lösung werden jedoch ausschließlich G2.1 Karten im Feld sein.
-Beim CardLink-Verfahren konnten die aus der eGK ausgelesenen Informationen über die Informationssysteme der Krankenkassen (VSDM-Fachdienste) wieder zusammengeführt und abgeglichen werden. Mit der Annahme, dass dies mit VSDM2 nicht mehr in der Form zur Verfügung steht, ist **eine sichere mobile Nutzung der eGK G2.1 ohne PIN** in einem Versorgungskontext **nicht möglich**.
-Mit der Abschaltung der VSDM1-Fachdienste, steht das CardLink-Verfahren aufgrund seiner Abhängigkeit zu den VSDM1-Fachdiensten nicht mehr zur Verfügung.
 //Die gematik arbeitet weiterhin an entsprechenden Lösungsvorschlägen, um die kontaktlose Nutzung der eGK G2.1 ohne PIN zukünftig im Kontext PoPP zu ermöglichen und somit die bisher nicht erfüllten Use Cases zu unterstützen.//
@@ Zeile 139: / Zeile 141: @@
 {{:dighealth:ti:popp:popp_arch.png?400|}}
 Zur Erstellung eines validen, signierten PoPP-Token müssen im PoPP-Service vorliegen:
@@ Zeile 166: / 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 259: / Zeile 262: @@
-=== Material ===
+=== Ausblick gesamt ===
+Folgende Punkte wurden diskutiert und werden fortlaufend über Spezifikationsdokumente adressiert und ebenfalls zur Kommentierung und Diskussion vorgelegt.
+== Nutzung der eGK-Kontaktlosschnittstelle (NFC) für mobile Szenarien ==
+**Problem**
+Die Zugriffsregeln der eGK erfordern PACE als sicheres Übertragungsprotokoll für die kontaktlose Kommunikation. Dabei wird die Kommunikation zwischen der eGK und dem PACE-Endpunkt (i.d.R das Kartenlesegerät) verschlüsselt. Diese Art der Verschlüsselung würde nur dann sicher im PoPP-Service enden, wenn die CAN (Card Access Number) sicher übermittelt werden könnte, was mit der bestehenden Peripherie ausgeschlossen ist.
+Das PoPP Konzept mit eGK basiert auf dem authentischen Auslesen des C.CH.AUT (KVNR und IK-Nummer) aus der eGK über ein C2C-initiiertes Secure Messaging zwischen eGK und PoPP-Service. Die Zugriffsregeln der eGK G2.1 lassen dies jedoch bei der Kontaktloskommunikation nicht zu. Demnach kann nicht sichergestellt werden, dass dem PoPP-Service nicht ein anderes C.CH.AUT Zertifikat zur Gültigkeitsprüfung vorgelegt wird.
+Um dennoch sicherzustellen, dass das CV-Zertifikat (ICCSN) und X.509.AUT-Zertifikat (C.CH.AUT) von derselben eGK stammen, muss ein Datenabgleich ermöglicht werden. Da es keine gemeinsamen Eigenschaften der beiden Zertifikate gibt, muss der Auftragsdatensatz bekannt sein oder die Daten bereits mindestens einmal authentisch (über die kontaktbehaftete Schnittstelle und PoPP) eingelesen werden. Beim CardLink-Verfahren konnten die aus der eGK ausgelesenen Informationen über die Informationssysteme der Krankenkassen (VSDM-Fachdienste) wieder zusammengeführt und abgeglichen werden. Mit der Annahme, dass dies mit VSDM2 nicht mehr in der Form zur Verfügung steht, ist **eine sichere mobile Nutzung der eGK G2.1 ohne PIN** in einem Versorgungskontext **nicht möglich**. Mit der Abschaltung der VSDM1-Fachdienste, steht das CardLink-Verfahren aufgrund seiner Abhängigkeit zu den VSDM1-Fachdiensten nicht mehr zur Verfügung.
+**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>
-<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>