VSDM 2.0 – Der neue Versichertenstammdaten-Flow von der eGK bis zum FHIR-Bundle

Die eGK wird eingesteckt, die Patientendaten erscheinen auf dem Bildschirm – was für das Praxispersonal am Empfang wie ein simpler Vorgang aussieht, hat sich unter der Haube grundlegend verändert. Mit VSDM 2.0 modernisiert die Telematikinfrastruktur den Abruf der Versichertenstammdaten und setzt auf eine tokenbasierte Architektur mit OAuth2, FHIR und dem neuen PoPP-Verfahren.

In diesem Beitrag gehe ich den gesamten Flow einmal Schritt für Schritt durch – vom Answer to Reset (ATR) der eGK bis zum FHIR-Bundle im PVS.

Warum VSDM 2.0?

Das bisherige VSDM-Verfahren war eng an den Hardware-Konnektor gekoppelt – der gesamte Datenabruf lief über diese zentrale, oft wartungsintensive Komponente. VSDM 2.0 verlagert den eigentlichen VSD-Abruf auf einen FHIR-basierten Fachdienst und ergänzt das Modell um PoPP für den Anwesenheitsnachweis. Der ZETA-Client ist der Zero-Trust-Sicherheitslayer, über den sämtliche Kommunikation mit TI-2.0-Diensten läuft – sowohl zum PoPP-Service als auch zum VSDM-Fachdienst. Er stellt sicher, dass nur autorisierte Requests die Fachdienste erreichen. Der Hardware-Konnektor kann optional durch das softwarebasierte TI-Gateway abgelöst werden. Die Authentisierung der Leistungserbringerinstitution über die SMC-B / SM-B bleibt weiterhin erforderlich – der ZETA-Client stößt dazu ExternalAuthenticate am Konnektor bzw. TI-Gateway an.

Der VSDM 2.0 Flow Schritt-für-Schritt

Schritt 1: eGK → Kartenleser

Der Ablauf beginnt, sobald die eGK in den Kartenleser eingesteckt wird. Der Leser erkennt die Karte anhand des Answer to Reset (ATR) – einer standardisierten Bytefolge, die Kartentyp und unterstützte Protokolle signalisiert.

1 ATR: 3B D3 96 FF …
2 Reader: REINER SCT cyberJack RFID standard

Schritt 2: Kartenleser → PVS

Der Kartenleser meldet dem Praxisverwaltungssystem (PVS), dass eine eGK erkannt wurde. Das PVS weiß jetzt: Eine Versichertenkarte ist physisch vorhanden – der eigentliche Verifikationsprozess kann starten.

Schritt 3: PVS → PoPP-Client

Das PVS fordert beim lokalen PoPP-Client ein sogenanntes PoPP-Token an. PoPP steht für Proof of Patient Presenceund ist das zentrale neue Element in VSDM 2.0. Es belegt kryptografisch, dass sich der Versicherte im Versorgungskontext bei einem Leistungserbringer befindet. In unserem Fall geschieht dies durch das Einlesen der eGK vor Ort in der Praxis — in weiteren Ausbaustufen von PoPP auch über die GesundheitsID. 

Doch wie kommt das Token zustande?
Der PoPP-Client baut über den ZETA-Client einen authentifizierten Kanal zum PoPP-Service auf, indem sich der ZETA-Client gegenüber dem ZETA Guard des PoPP-Service authentifiziert und ein OAuth2-Access-Token mit DPoP (Demonstrating Proof-of-Possession) erhält.

DPoP ist eine Erweiterung des OAuth2-Frameworks, die sicherstellt, dass ein Access-Token nur von dem Client verwendet werden kann, der es angefordert hat. Selbst wenn ein Token abgefangen würde – ohne den zugehörigen privaten Schlüssel ist es wertlos. Das ist Zero Trust in der Praxis.

Über das Access-Token öffnet der PoPP-Client eine WebSocket-Verbindung zum PoPP-Service und signalisiert die Bereitschaft zur Token-Ausstellung — der PoPP-Service antwortet mit einem APDU (Application Protocol Data Unit)-Szenario zur Verifikation der eGK.

Schritt 4: PoPP-Service ↔ eGK via PoPP-Client

Der PoPP-Service sendet über die gesicherte WebSocket-Verbindung ein oder mehrere Szenarien — jedes Szenario enthält eine Sequenz von APDU-Kommandos, die der PoPP-Client transparent an die eGK im Kartenleser weiterleitet. Der PoPP-Client fungiert dabei als reiner Proxy: Er interpretiert oder verändert die Kommandos nicht.

Über diese APDU-Kommandos liest der PoPP-Service kryptografische Daten der eGK aus und verifiziert deren Authentizität. Nur eine echte, physisch anwesende Karte kann die erwarteten Antworten liefern — so wird sichergestellt, dass kein Token ohne Karte erzeugt werden kann.

1 → APDU-Kommando senden (Szenario-Start)
2 ← APDU-Response (Szenario abgeschlossen)

Schritt 5: PoPP-Service → PoPP-Client

Nach erfolgreicher Verifikation stellt der PoPP-Service ein signiertes PoPP-Token aus — ein JWT (JSON Web Token), das die KVNR der verifizierten eGK enthält. Das Token belegt kryptografisch, dass sich genau diese Versichertenkarte zum Zeitpunkt der Ausstellung im Versorgungskontext befand. Mit diesem Token kann das PVS nun im nächsten Schritt die Versichertenstammdaten abrufen.

1 Verbindung: WebSocket
2 Timestamp: 22:35:39.659
3 Quartal: Q2/2026
4 Token: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRpZW50S...

Schritt 6: PVS → VSDM-Fachdienst

Für den Zugriff auf den VSDM-Fachdienst authentifiziert sich das PVS — analog zu Schritt 3 — über einen eigenen ZETA-Client und erhält ein Access-Token. Mit diesem Token und dem PoPP-Token aus Schritt 5 ruft das PVS die Versichertenstammdaten über eine REST-API ab:

1 GET /vsdservice/v1/vsdmbundle
2 Authorization: Bearer <access_token>
3 DPoP: <proof>
4 X-PoPP-Token: <popp_token>

Die Antwort kommt als FHIR-Bundle – ein standardisiertes Datenformat aus dem HL7-FHIR-Ökosystem.

Der ETag ermöglicht effizientes Caching: Hat sich an den Stammdaten nichts geändert, kann der Fachdienst beim nächsten Abruf mit einem 304 Not Modified antworten – das spart Bandbreite und reduziert die Last auf den Fachdiensten. Zusätzlich stellt der VSDM-Fachdienst im Rahmen des Abrufs eine Prüfziffer aus, die den bisherigen Prüfungsnachweis ablöst.

Schritt 7: VSD im PVS

Die Versichertenstammdaten (VSD) liegen vor und werden im PVS angezeigt. Die Patientin ist erkannt, der Praxisalltag kann weitergehen.

Was sich architektonisch verändert hat

VSDM 2.0 ist mehr als ein Update – es ist ein Paradigmenwechsel in der Telematikinfrastruktur. Die wichtigsten Veränderungen auf einen Blick:

Prüfziffer statt Prüfungsnachweis. Den bisherigen Prüfungsnachweis löst die Prüfziffer ab, die der VSDM-Fachdienst im Rahmen des VSD-Abrufs ausstellt. Der Anwesenheitsnachweis der eGK erfolgt über das PoPP-Token.

OAuth2 + DPoP ergänzt die Konnektor-Kryptografie. Die Autorisierung gegenüber den Fachdiensten läuft über Industriestandards. DPoP verhindert Token-Replay-Angriffe und macht die Architektur resilient gegen Man-in-the-Middle-Szenarien. Die Einrichtungsauthentisierung selbst erfolgt weiterhin mit der SMC-B / SM-B am Konnektor bzw. TI-Gateway.

FHIR statt proprietäre Formate. Die Versichertenstammdaten werden als FHIR-Bundle ausgeliefert – interoperabel, standardisiert und international anschlussfähig.

WebSocket statt synchronem Polling. Die Kommunikation mit dem PoPP-Service nutzt persistente Verbindungen. Das reduziert Latenz und ermöglicht effizientere Ressourcennutzung.

Kein Hardware-Konnektor zwingend nötig. Der hardwarebasierte Konnektor kann durch das softwarebasierte TI-Gateway ersetzt werden. Das vereinfacht Bereitstellung und Wartung, senkt die Betriebskosten und reduziert die Fehleranfälligkeit in den Praxen.

Fazit

VSDM 2.0 zeigt, wohin die Reise in der Telematikinfrastruktur geht: weg von monolithischer Hardware, hin zu modularen, standardbasierten Services. Der Flow von der eGK bis zum FHIR-Bundle mag auf den ersten Blick komplex wirken – aber jeder einzelne Schritt folgt einer klaren Logik und nutzt bewährte Industriestandards.

Dieser Beitrag wurde am 14.4.2026 und 16.4.2026 nach fachlichem Feedback aktualisiert. Die Korrekturen betreffen im Wesentlichen folgende Punkte:
1. Der Konnektor bzw. das TI-Gateway bleibt für die Einrichtungsauthentisierung weiterhin erforderlich – er fällt nicht weg. Der hardwarebasierte Konnektor kann jedoch durch das softwarebasierte TI-Gateway ersetzt werden.
2. Das PoPP-Token dient ausschließlich dem Anwesenheitsnachweis der eGK. Den bisherigen Prüfungsnachweis löst die Prüfziffer ab, die der VSDM-Fachdienst ausstellt.
3. Der ZETA-Client wird durchgängig im Flow benötigt – sowohl für die Kommunikation mit dem PoPP-Service als auch mit dem VSDM-Fachdienst.
4. PoPP-Token-Erstellung (Schritt 3–5): Detaillierung der Kommunikation zwischen PoPP-Service, PoPP-Client und eGK.

Hinweis: Alle im Artikel enthaltenen Bilder wurden mit der Hilfe von KI erstellt.