Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dighealth:ti:vsdm [2026/06/04 12:39] – [Technische Voraussetzungen für VSDM 2.0] fjh
+++ dighealth:ti:vsdm [2026/06/04 19:20] (aktuell) – [Was leistet VSDM?] fjh
@@ Zeile 4: / Zeile 4: @@
 ===== Was leistet VSDM? ======
-  * **Bereitstellung** der gesetzlich definierten **Versichertenstammdaten** (VSD).((§ 291a Abs. 2 bis 4 SGB V.))
+  * **Bereitstellung** der gesetzlich definierten **Versichertenstammdaten** (VSD) zur Übernahme in Abrechnungsunterlagen und Vordrucke durch den Leistungserbringenden.((§ 291a Abs. 2 bis 4 SGB V.))
   * **Versicherungsnachweis** durch Versicherte.((§ 291a Abs. 1 SGB V.))
   * **Prüfung der Leistungspflicht** der Krankenkasse des Versicherten
@@ Zeile 18: / Zeile 18: @@
   * **Bereitstellung VSD**
-    * VSD sind **auf** der **eGK** gespeichert.((§ 291a Abs. 2 und 3 SGB V.))
+    * VSD sind **auf** der **eGK** in einem proprietären XML-Datenformat gespeichert((§ 291a Abs. 2 und 3 SGB V.))
   * **Versicherungsnachweis**
     * **eGK** gilt als Versicherungsnachweis.((§ 291a Abs. 1 S. 1 SGB V.))
   * **Prüfung der Leistungspflicht**
     * Erfolgt im Rahmen des Einlesens der VSD von der eGK beim Arztbesuch.
-    * Beim Stecken der eGK gleicht der Konnektor die VSD auf der eGK über die TI mit dem VSDD der Krankenkasse ab.
+    * Beim Stecken der eGK werden die VSD auf der eGK über die TI mit dem VSDD der Krankenkasse abgeglichen.
     * Nach erfolgreicher Prüfung erfolgt ggf. eine Aktualisierung der Daten auf der eGK.
     * Der Vorgang wird protokolliert und ein **Prüfnachweis** wird auf eGK abgelegt.
     * VSD und Prüfnachweis werden abschließend in das Primärsystem übernommen.
-  * **Sonstiges**
+  * **Etablierung des Behandlungskontexts**
-    * Kommunikation zwischen Konnektor und Fachdiensten der Krankenkassen erfolgt über einen **Intermediär**, der die Daten der Arztpraxis anonymisiert bis hin zur IP-Adresse. Dadurch werden Profilbildungen vermieden.
+    * Übergabe und Stecken der eGK
+  * **Technische Architektur**
+    * eGK wird in ein mit dem Konnektor gepairtes eHealth-Kartenterminal gesteckt.
+    * Primärsystem ruft Operation //ReadVSD// des Fachmoduls VSDM am Konnektor auf.
+    * Verbindung zum VSDD der Krankenkasse über den Konnektor.
+    * Kommunikation zwischen Konnektor und VSDD erfolgt über einen **Intermediär**, der die Daten der Arztpraxis anonymisiert bis hin zur IP-Adresse. Dadurch werden Profilbildungen vermieden.
 ===== VSDM 2.0 =====
   * **Bereitstellung VSD**
-    * Die VSD stehen (aktuell und gültig) auf den VSDD der Krankenkassen zum Abruf zur Verfügung.
+    * Die VSD stehen (aktuell und gültig) auf den VSDD der Krankenkassen [[https://simplifier.net/packages/de.gematik.vsdm2/1.0.1|im FHIR-Format]] zum Abruf zur Verfügung.
     * "Abgespeckte" **VSD**((§ 291 Abs. 2 Nr. 3 SGB V.)) sind **auch weiterhin auf** der **eGK** gespeichert (als eine Art Offline-Backup), werden aber nach initialer Ausgabe nicht mehr aktualisiert.
   * **Versicherungsnachweis**
@@ Zeile 41: / Zeile 46: @@
     * Die VSD inkl. des Prüfnachweises werden direkt in das Primärsystem übernommen und nicht mehr auf der eGK aktualisiert.((§ 291b Abs. 2 S. 3 SGB V))
     * VSDM 2.0 ist die erste TI-2.0-Anwendung und benötigt keinen Konnektor mehr (ZETA).((https://fachportal.gematik.de/anwendungen/versichertenstammdaten-management.))
-  * **Sonstiges**
+  * **Etablierung des Behandlungskontexts**
-    * Der **Intermediär** entfällt.((In VSDM 2.0 ist kein Intermediär zu Entfernung des LE-Bezugs vorgesehen, um Profilbildung zu verhindern. Es werden ausschließlich organisatorische Maßnahmen vorgesehen. Da für den Versicherten Zugriffe protokolliert werden müssen (wie auch bei VSDM 1 auf eGK), müsste es dann auch eine Komponente zur Depseudonymisierung geben. Im Übrigen liegen die Daten (Abrechnung!), die eine Profilbildung ermöglichten ohnehin bereits bei den Kassen vor. Durch den Intermediär erhalten die Kassen diese Verknüpfung lediglich früher.))
+    * erfolgt über ein (kryptographisches) Token, das das Primärsystem vom PoPP-Dienst erhält.
+    * Authentizität ("Anwesenheit") des Versicherten kann dem PoPP-Service mittels eGK oder GesundheitsID (Smartphone) nachgewiesen werden.
+  * **Technische Architektur**
+    * Autorisiert durch das PoPP-Token ruft das Primärsystem (ohne Konnektor und Intermediär((In VSDM 2.0 ist kein Intermediär zu Entfernung des LE-Bezugs vorgesehen, um Profilbildung zu verhindern. Es werden ausschließlich organisatorische Maßnahmen vorgesehen. Da für den Versicherten Zugriffe protokolliert werden müssen (wie auch bei VSDM 1 auf eGK), müsste es dann auch eine Komponente zur Depseudonymisierung geben. Im Übrigen liegen die Daten (Abrechnung!), die eine Profilbildung ermöglichten ohnehin bereits bei den Kassen vor. Durch den Intermediär erhalten die Kassen diese Verknüpfung lediglich früher.))) die VSD direkt vom VSDD ab.
+    * Absicherung der Verbindung zum PoPP-Dienst und VSDD über ZETA.
+    * Im Vor-Ort-Szenario kann zum Stecken der eGK auch ein Standardkartenlesegerät genutzt werden.
+    * Zur Authentifizierung der Leistungserbringerinstitution am PoPP-Dienst und VSDD wird weiter entweder ein Konnektor/TI-Gateway plus SMC-B oder ein TI-Gateway mit einer SM-B (kartenungebundene Leistungserbringer-Identität) benötigt.
 Bei VSDM 2.0 erfolgt eine (weitgehende) Entkopplung von der eGK. Abruf der VSD (sowie auch die Etablierung des Behandlungskontextes) kann entweder mit eGK oder (kartenungebundener) digitaler Identität erfolgen - zukünftig auch ohne physische Präsenz in der Leistungserbringerinstitution.