Benutzer-Werkzeuge

Webseiten-Werkzeuge


dighealth:ti:popp

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
dighealth:ti:popp [2026/02/02 08:56] fjhdighealth:ti:popp [2026/03/13 16:10] (aktuell) – [Umsetzungen] fjh
Zeile 1: Zeile 1:
 ====== Proof of Patient Presence (PoPP) ====== ====== 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**. Die Spezifikation und Umsetzung erfolgt in **zwei Stufen**.
Zeile 7: Zeile 7:
 **Stufe 1** umfasst folgende Anwendungsfälle: **Stufe 1** umfasst folgende Anwendungsfälle:
   * Nutzung der eGK in Versorgungseinrichtungen   * 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! => 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/#.))   * 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 ===== ===== 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> <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_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_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. 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>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 262: Zeile 270:
 **Problem** **Problem**
  
-((Zum Hintergrund: Nach Eingabe der CAN nutzt die eGK das PACE-Protokoll +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. 
-⇒ 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.+ 
 +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
  
-Beim CardLink-Verfahren konnten die aus der eGK ausgelesenen Informationen über die Informationssysteme der Krankenkassen (VSDM-Fachdienstewieder zusammengeführt und abgeglichen werden. Mit der Annahmedass 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**. +<note warning>Die Weiterentwicklung der Leistungserbringer-Identität (HBAspielt im Kontext PoPP keine Rolleda der PoPP-Token derzeit ausschließlich Informationen der Institution enthält und auch nur für entsprechende Nutzungsszenarien eingesetzt wirdEs sind keine Anforderungen an die PoPP-Lösung bekanntdie eine eindeutige Nutzerauthentifizierung mittels HBA (oder Nachfolgetechnologie) bedarf.</note>
-Mit der Abschaltung der VSDM1-Fachdienstesteht das CardLink-Verfahren aufgrund seiner Abhängigkeit zu den VSDM1-Fachdiensten nicht mehr zur Verfügung.+
  
  
  
  
-=== 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> 
  
  
dighealth/ti/popp.1770022608.txt.gz · Zuletzt geändert: von fjh

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki