Telematikinfrastruktur 2.0

Spezifikation

Versichertenstammdaten-
management 2.0 (VSDM 2.0)

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
1153084
     
     

      
Stand
      
04.03.2025
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_VSDM_2
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen. 

Dies ist die erste Version des Dokuments.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Beim vorliegenden Dokument handelt es sich um die Festlegungen der zweiten Ausbaustufe von VSDM (VSDM 2.0). Diese ist definiert durch den Abruf der Versichertenstammdaten (VSD) durch das Primärsystem des Leistungserbringers direkt vom Fachdienst der Krankenkasse. Die VSD werden im Gegensatz zu VSDM 1.0 nicht mehr auf der eGK aktualisiert und von dort gelesen. 

Die vorliegende Spezifikation definiert Anforderungen zu Herstellung, Test und Betrieb der Produkttypen und beschreibt, wie die fachlichen Abläufe umzusetzen sind.

Zu den Produkttypen gehören

1. Fachdienst VSDM 
2. Primärsystem des Leistungserbringers.

1.2 Zielgruppe

Das Dokument richtet sich an

1. den Hersteller des Fachdienstes VSDM
2. den Hersteller und Anbieter von weiteren Produkttypen der Fachanwendung VSDM 

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt und bekannt gegeben.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Fachdienst VSDM (VSDM 2.0) verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes sind die informativen und normativen Ergänzungen zur Nutzung der Schnittstellen des Fachdienstes VSDM in der separaten API-Dokumentation, sowie zur Profilierung der verwendeten FHIR Ressourcen.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID,
Anforderungen zusätzlich durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselwörter MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Anforderungen werden im Dokument wie folgt dargestellt:
<AF-ID> - <Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

bzw.

<AFO-ID> - <Titel der Anforderung>
Text / Beschreibung
[<=]

Dabei umfasst der Anwendungsfall bzw. die Anforderung sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

1.5.1 Hinweis auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung, sind wie folgt im Dokument gekennzeichnet:

2 Systemkontext

Die Fachdienste VSDM (Synonyme: Versichertenstammdatendienste, VSDD) stellen eine Schnittstelle für den Abruf der VSD und der Prüfziffer für die Primärsysteme einer Leistungserbringerinstitution (LEI) bereit. Ein Abruf erfolgt jedoch nur bei einem vorliegenden Versorgungskontext, der durch den Proof-of-Patient-Presence Dienst (PoPP-Service) in Form eines PoPP-Token nachgewiesen werden muss.

Der VSDD ist für Primärsysteme direkt über das Internet erreichbar und ist aufgrund dessen durch Mechanismen und Komponenten gemäß den Zero-Trust Prinzipien abgesichert.

Der Zugriff auf einen Fachdienst VSDM ist nur mit einer erfolgreichen Authentifizierung auf Basis einer SMC-B oder SMB möglich. Hieraus ergeben sich folgende Infrastrukturoptionen für die Authentisierung einer Leistungserbringerinstitution:

• mittels SMC-B, eHealth-Kartenterminal und Konnektor oder
• mittels SMC-B, eHealth-Kartenterminal und TI-Gateway oder
• mittels SM-B und TI-Gateway.

Im Rahmen der Nachweiserstellung über einen bestehenden Versorgungskontext ergeben sich folgende Infrastrukturoptionen für die Authentisierung eines Versicherten:

• mittels eGK, eHealth-Kartenterminal und Konnektor oder
• mittels eGK, eHealth-Kartenterminal und TI-Gateway oder
• mittels einer zukünftig angestrebten Nutzung der eGK mit einem handelsüblichen Smartcard-Reader oder
• mittels GesundheitsID-Versicherte

Abbildung 1 : Kontextdiagramm VSDM

2.1 Akteure und Rollen

Im Kontext der Anwendung VSDM werden verschiedene Akteure und Rollen definiert:

2.1.1 Hersteller ZETA Guard

Der Hersteller des ZETA Guard implementiert und entwickelt den ZETA Guard und dessen Komponenten gemäß den Vorgaben der gematik [gemSpec_ZETA].

2.1.2 Hersteller Resource Server VSDM

Der Hersteller eines Ressource Server VSDM implementiert und entwickelt den Resource Server gemäß den Vorgaben der gematik und den Krankenversicherungen. Der Hersteller eines Resource Servers kann zusätzlich eine Monitoring-Komponente für den Resource Server einbinden.

2.1.3 Anbieter Fachdienst VSDM

Der Anbieter eines Fachdienstes VSDM integriert den ZETA Guard und Resource Server VSDM zu einem Fachdienst VSDM und betreibt den zugelassenen Fachdienst im Internet gemäß den Vorgaben der gematik. Zudem verantwortet der Anbieter das Monitoring und Security Information and Event Management (SIEM) des Fachdienstes.

2.1.4 Kostenträger

Kostenträger bzw. Krankenversicherer stellen über einen Fachdienst VSDM die Versichertenstammdaten ihrer Versicherten zur Verfügung.

Kostenträger bzw. Krankenversicherer ermöglichen ihren Versicherten den Zugriff auf die versichertenindividuellen Zugriffsprotokolle eines Fachdienst VSDM.

2.1.5 gematik

Die gematik spezifiziert den Fachdienst VSDM und legt die Zulassungsbedingungen sowie -verfahren fest. Die gematik lässt den jeweiligen Fachdienst VSDM und den Anbieter eines Fachdienstes, inklusive den anbieterrelevanten Vorgaben zum Betrieb des ZETA Guard, zu.

Die gematik stellt den qualitätsgesicherten ZETA Guard zur Integration und den Betrieb zur Verfügung.

Die gematik stellt dem Anbieter eines Fachdienstes VSDM Möglichkeiten zur Konfiguration des ZETA Guard mittels Konfigurationsdateien (Manifest-Dateien) in Form von Templates zur Verfügung und stellt dem Anbieter diese Konfigurationsdateien qualitätsgesichert zur Verfügung.

Die gematik stellt dem Anbieter eines Fachdienstes VSDM Richtlinien in Form von TI-weit sowie anwendungsspezifisch geltende Policies qualitätsgesichert zur Verfügung.

Die gematik führt ihre Governance-Rolle für die Fachdienste VSDM und deren Anbieter aus.

2.1.6 Primärsystemhersteller

Primärsystem-Hersteller nutzen den vom Anbieter eines Fachdienstes VSDM bereitgestellten Fachdienst in der Referenzumgebung, um ihre jeweiligen Primärsysteme mit den VSDM und ZETA Client Funktionen zu entwickeln und zu testen.

2.1.7 Leistungserbringer, LE-Institution oder Medizinische Fachangestellte

Die Leistungserbringerinstitutionen bzw. deren Leistungserbringer oder medizinische Fachangestellte benutzen mittels eines Primärsystems mit VSDM und ZETA Client Funktionen den Fachdienst VSDM, um aktuelle Versichertenstammdaten sowie eine Prüfziffer für Abrechnungszwecke zu erhalten.

Die Leistungserbringerinstitutionen bzw. deren Leistungserbringer oder medizinische Fachangestellte lesen mittels eines Primärsystems und der Nutzung eines handelsüblichen Smartcard-Readers oder eines eH-KT über den Konnektor oder TI-Gateway die Versichertenstammdaten aus dem Bereich der allgemeinen Versicherungsdaten (EF.VD) der elektronischen Gesundheitskarte (eGK). Das Auslesen des Bereiches der geschützten Versichertendaten (EF.GVD) entfällt.

2.1.8 Anbieter PoPP-Service

Der Anbieter des PoPP-Service stellt Leistungserbringerinstitutionen einen über das Internet erreichbaren Dienst zur Verfügung, um einen Nachweis für einen zustande gekommenen Versorgungskontext zwischen einer dedizierten Leistungserbringerinstitution und einem dedizierten Versicherten bzw. Patienten in Form eines PoPP-Tokens zu erhalten. Dieser Nachweis ist Voraussetzung zur Durchführung eines Online-Abrufes der Versichertenstammdaten und dem Erhalt einer Prüfziffer.

2.1.9 Versicherter

Versicherte bestätigen durch das Stecken der eGK oder unter Nutzung der GesundheitsID das Zustandekommen eines Versorgungskontextes mit einer dedizierten Leistungserbringerinstitution als Voraussetzung für den Abruf der VSD.

Ist der Abruf der VSD vom Fachdienst VSDM nicht möglich oder der PoPP-Service nicht erreichbar (offline-Fall) stellen Versicherte durch das Stecken ihrer eGK der Leistungserbringerinstitution die Versichertenstammdaten, welche sich auf der eGK befinden, bereit. 

2.2 Nachbarsysteme

2.2.1 Systeme in der Leistungserbringerinstitution

Die Schnittstellen der Fachdienste VSDM werden durch die Primärsysteme (Praxisverwaltungs-, Krankenhausinformations- und Apothekenverwaltungssysteme) der Leistungserbringer im Versorgungsprozess genutzt.

Ein Primärsystem kann die Versichertenstammdaten und die Prüfziffer zu einem Versicherten von einem Fachdienst VSDM nur dann abrufen, wenn dieses ein Testat über einen aktuell bestehenden Versorgungskontext zwischen einer Leistungserbringerinstitution und einem Versicherten übermittelt. Der aktuelle Versorgungskontext wird für die Leistungserbringerinstitution auf Basis der SMC-B und für den Versicherten auf Basis der eGK oder der GesundheitsID-Versicherte gegenüber dem PoPP-Service nachgewiesen. Der PoPP-Service attestiert diesen Versorgungskontext zwischen einer dedizierten LEI und einem dedizierten Versicherten zu einem dedizierten Zeitpunkt in Form eines PoPP-Tokens (Testat).

Können die Versichertenstammdaten nicht online von dem jeweiligen Fachdienst VSDM abgerufen werden, liest das Primärsystem die (zukünftig reduzierten) Versichertenstammdaten unter Nutzung von Konnektor oder TI-Gateway und eH-KT von der eGK. Darüber hinaus eröffnet die Umsetzung dieses Konzeptes die Nutzung eines handelsüblichen Smartcard-Readers zum Auslesen der (zukünftig reduzierten) Versichertenstammdaten von der eGK ohne Notwendigkeit eines Konnektors oder TI-Gateways.

2.2.2 TI-Gateway

Für Leistungserbringerinstitutionen, die anstatt des Konnektors ein TI-Gateway nutzen, erfolgt die Authentisierung einer Leistungserbringerinstitution gegenüber dem PoPP-Service und einem Fachdienst VSDM auf Basis der über ein eHealth-Kartenterminal an das TI-Gateway angebundenen SMC-B oder der vom Betreiber des TI-Gateway gehosteten SM-B.

2.2.3 PoPP-Service

Der PoPP-Service attestiert einen aktuellen Versorgungskontext zwischen einer auf Basis der SMC-B oder SM-B am PoPP-Service authentifizierten Leistungserbringerinstitution und einem Versicherten durch die Bereitstellung eines technischen Nachweises in Form eines sogenannten PoPP-Tokens, der unter anderem die Telematik-ID, das Institutionskennzeichen, die Krankenversichertennummer sowie einen Zeitstempel enthält. Die Authentizität des Versicherten kann dem PoPP-Service mittels eGK und unter Nutzung vom eHealth-Kartenterminal und Konnektor oder TI-Gateway nachgewiesen werden. Zudem eröffnet die Umsetzung des Konzeptes zum Nachweis des Versorgungskontextes die Möglichkeit zur Nutzung "handelsüblicher Smartcard-Readers". Zudem besteht für den Versicherten die Möglichkeit, sich durch Nutzung eines Frontend für Versicherte mit enthaltenen PoPP-Funktionalitäten mittels seiner GesundheitsID respektive des jeweiligen sektoralen IDP gegenüber dem PoPP-Service zu authentisieren.

Zur Prüfung der Authentizität des PoPP-Tokens stellt der PoPP-Service einem Fachdienst VSDM einen Endpunkt zum Abruf des JSON Web Key Set Dokumentes (JWKS-Document) mit dem dort enthaltenen und aktuell gültigen öffentlichen Schlüssel zur Prüfung der PoPP-Token Signatur zur Verfügung.

2.2.4 Federation Master

Der Federation Master stellt dem Fachdienst VSDM den authentischen FQDN zur Bildung der Adresse des ./well-known Endpunktes des PoPP-Service zur Verfügung. Über diesen ./well-known Endpunkt erhält der Fachdienst VSDM alle aktuellen Endpunkte des PoPP-Service und insbesondere den Endpunkt zum Abruf des JWKS-Documents, welches den aktuell gültigen Schlüssel zur Verifizierung der PoPP-Token Signatur enthält.. 

2.2.5 DNS

Das Domain Name System ermöglicht einem Primärsystem die Dienstlokalisierung anhand der Institutionskennung des Kostenträgers sowie der Auflösung des Fachdienst VSDM spezifischen Hostname in die entsprechende IP-Adresse und stellt somit die grundsätzliche Kommunikation zwischen Primärsystem und Fachdienst VSDM über das Internet sicher.

2.2.6 OCSP TSP X.509nQ SMC-B

Dieser im Internet verfügbare OCSP-Responder ermöglicht die Abfrage des Sperrstatus zum jeweiligen C.HCI.AUT-Zertifikat der Leistungserbringerinstitution im Rahmen der LEI-Authentifizierung am Fachdienst VSDM. Hiermit wird sichergestellt, dass ausschließlich Leistungserbringerinstitutionen mit einer gültigen Leistungserbringeridentität Versichertenstammdaten von einem Fachdienst VSDM abrufen können.

2.2.7 OCSP Internet-CA

Dieser OCSP-Responder eines TSP gemäß [CAB-Forum] ermöglicht den Primärsystemen die Überprüfung des Sperrstatus des jeweiligen Server-Zertifikates im Rahmen der Etablierung eines TLS-Kanals zum Fachdienst VSDM. Die OCSP-Response wird dem Primärsystem im Rahmen des Verbindungsaufbaus übermittelt (OCSP Stapling). Hiermit wird sichergestellt, dass ausschließlich VSDM Fachdienste mit einer gültigen Identität von den Primärsystemen genutzt werden können.

2.2.8 OCSP Komponenten-CA TI

Dieser im Internet verfügbare OCSP-Responder einer Komponenten-CA der TI ermöglicht den Primärsystemen die Überprüfung des Sperrstatus des jeweiligen Server-Zertifikates im Rahmen der Etablierung eines ZETA/ASL-Kanals zum Fachdienst VSDM. Die OCSP-Response wird dem Primärsystem im Rahmen des Verbindungsaufbaus übermittelt (OCSP Stapling). Hiermit wird sichergestellt, dass ausschließlich VSDM Fachdienste mit einer gültigen ZETA/ASL-Identität von den Primärsystemen genutzt werden können.

2.2.9 ZETA PIP und PAP Service

Der ZETA Service Policy Administration Point (PAP) stellt dem Fachdienst VSDM die für einen Autorisierungsvorgang aktuell gültigen und anzuwendenden Sicherheitsrichtlinien im Kontext der Anwendung VSDM (VSDM-Policy) sowie der TI (TI-Policy) zur Verfügung. Darüber hinaus werden über den ZETA Service Policy Information Point (PIP) zusätzliche und von der Sicherheitsrichtlinie geforderte Informationen wie bspw. erlaubte (Positivliste) oder verbotene (Negativliste) Endsystemkonfigurationen zur Verfügung gestellt, die ein Fachdienst VSDM im Rahmen der Evaluierung der Autorisierungsanfrage durch das Primärsystem gegen die Sicherheitsrichtlinie einbezieht.

2.2.10 ZETA Git-Repository

Das ZETA Git-Repository stellt dem Anbieter/Betreiber eines Fachdienstes VSDM die für den Zugriffsschutz gemäß der TI 2.0 Zero-Trust Architektur zu verwendenden bzw. betreibenden Software-Komponenten in Form eines Kubernetes-Cluster (ZETA Guard) bereit. Die aus dem Cluster zwingend zu verwendenden Komponenten und deren Konfigurationen werden durch die jeweiligen Fachdienstspezifikationen der gematik vorgegeben. Festlegungen für einen Fachdienst VSDM erfolgen im Kapitel 4.2 ZETA Guard. 

Das Softwareprodukt "ZETA Guard" wird durch einen von der gematik beauftragten Hersteller entwickelt und von der gematik freigegeben sowie authentizitäts- und integritätsgeschützt bereitgestellt.

2.2.11 Betriebsdatenerfassung (BDE)

Ziel der Betriebsdatenerfassung ist es, die betriebliche Steuerung und das differenzierte Aufrufverhalten für einen Fachdienst auf Basis der übermittelten Betriebsdaten qualitativ einzuordnen. Hierbei stehen das zeitnahe Monitoring und die monatliche Service Level Bewertung durch die gematik im Vordergrund.

2.2.12 Security Information and Event Management (SIEM)

Zur Erkennung von sicherheitskritischen Ergebnissen ist für einen Fachdienst VSDM ein SIEM erforderlich. Erkannte Alarme, Betriebsdaten und Reports werden an das TI-SIEM übermittelt und dienen dazu, dass die gematik anbieterübergreifend Anomalien und Angriffsversuche umgehend erkennen, Schwell- und Messwerte kontinuierlich verbessern, potenzielle Sicherheitsvorfälle auch auf Seiten der gematik analysieren und sicherheitsrelevante Trends (z. B. Anzahl abgelehnter Zugriffe über einen bestimmten Zeitraum) erkennen und bewerten kann.

2.2.13 Systeme der Kostenträger

Die Systeme der Kostenträger können der Bereitstellung der originären Versichertenstammdaten für den Fachdienst VSDM in einem nicht näher festgelegtem Datenformat und über eine nicht näher festgelegte Schnittstelle dienen. Zudem können über diese Systeme den Versicherten die Zugriffsprotokolle des jeweiligen Fachdienstes VSDM verfügbar gemacht werden.

2.3 User Stories

Die folgenden User Stories sollen die Bedarfe von Leistungserbringern beispielhaft verdeutlichen.

2.3.1 Versichertenstammdaten vom Fachdienst abrufen

• Als Leistungserbringer möchte ich mindestens einmal im Quartal die aktuellen Versichertenstammdaten erhalten und in mein Primärsystem übernehmen können.
• Als Leistungserbringer möchte ich auswählen können, dass die Versichertenstammdaten auch bei Folgebesuchen des Patienten innerhalb eines Quartals automatisch und ohne erneutem Stecken der eGK oder erneuten Nutzung der GesundheitsID durch den Versicherten abgerufen werden, um immer die jeweils aktuellen Versichertenstammdaten im Primärsystem speichern zu können.
• Als Leistungserbringer muss ich vor der eigentlichen Behandlung des anwesenden Patienten dessen Versicherungsverhältnis prüfen, um meine erbrachten Leistungen gegenüber der zuständigen Krankenkasse abrechnen zu können. Dafür muss ich die Versichertenstammdaten des Versicherten von seiner Krankenkasse abrufen und zusätzlich die Prüfziffer über die getätigte Abfrage in meinem Primärsystem speichern. Um diesen Prozess zu starten, muss vorher der Versorgungskontext mittels eGK oder GesundheitsID des Versicherten nachgewiesen werden.
• Als Leistungserbringer muss ich zur Abrechnung meiner Leistungen die Prüfziffer über die abgefragten VSD im Primärsystem speichern.

2.3.2 Versichertenstammdaten von eGK lesen

• Als Leistungserbringer möchte ich mindestens einmal im Quartal auch dann die Versichertenstammdaten erhalten und in mein Primärsystem übernehmen können, wenn die Herstellung des Versorgungskontextes fehlschlägt und/oder die Versichertenstammdaten des Versicherten nicht von der zuständigen Krankenkasse abgerufen werden können. In diesem Fall nutze ich die auf der eGK gespeicherten Daten.
• Als Leistungserbringer muss ich in der Lage sein, das Versicherungsverhältnis des anwesenden Patienten prüfen sowie meine Leistungen am Patienten abrechnen zu können, wenn die Herstellung des Versorgungskontextes fehlschlägt und/oder die Versichertenstammdaten des Versicherten nicht von der zuständigen Krankenkasse abgerufen werden können. In diesem Fall nutze ich die auf der eGK gespeicherten Daten.

2.3.3 Zugriffsprotokoll einsehen

• Als Versicherter möchte ich mich informieren, wer wann auf die mich betreffenden Versichertenstammdaten zugegriffen hat und somit meine Datenschutzrechte wahrnehmen können. Protokolleinträge werden im Fachdienst 3 Jahre aufbewahrt und anschließend sicher gelöscht.

3 Systemüberblick

Ein Fachdienst VSDM stellt die Versichertenstammdaten (VSD) der Versicherten einer Krankenkasse des jeweiligen Fachdienstes als ein zentraler Resource Server auf Basis des FHIR-Standards über eine im Internet erreichbare REST-API zum Abruf durch das Primärsystem des Leistungserbringers bereit. Zusätzlich protokolliert der Fachdienst alle Zugriffe auf die VSD durch den Leistungserbringer für den Versicherten.

In der folgenden Abbildung sind alle beteiligten Komponenten (das Primärsystem verallgemeinernd als Clientsystem) der VSDM-Architektur dargestellt:

Abbildung 2 : Systemdiagramm VSDM

4 Zerlegung des Produkttyps

4.1 Clientsystem

Die folgenden Anforderungen an ein Clientsystem haben rein informativen Charakter und beschränken sich auf die zwingend zu schaffende Voraussetzungen zur Nutzung eines Fachdienstes VSDM. Darüber hinaus dienen diese für ein besseres Verständnis über die Funktionsweise der Anwendung VSDM. Weiterführende und detaillierte Informationen sind im Implementierungsleitfaden [gemILF_PS] dokumentiert.

4.1.1 Datenbank

Die logische Komponente "Datenbank" dient lediglich als Strukturierungselement für diese Spezifikation und soll verdeutlichen, dass im Rahmen von VSDM bestimmte Informationen für einen dedizierten Zeitraum persistiert werden müssen. Diese Persistierung könnte bspw. als Teil des jeweiligen Patientenstammes realisiert werden.

4.1.2 VSDM-Client Funktionen

Die logische Komponente "VSDM-Client" dient lediglich als Strukturierungselement für diese Spezifikation und soll die VSDM-spezifischen Funktionen eines Clientsystems verdeutlichen.

4.1.2.1 Online-Abruf Versichertenstammdaten und Prüfziffer

Hinweis: Ein für das Quartal gültiger Nachweis über einen Versorgungskontext zwischen einer LEI und einem Patienten in Form eines PoPP-Tokens muss beim ersten Besuche des Patienten innerhalb des aktuellen Quartals vom PoPP-Service unter Verwendung der eGK oder GEsundheitsID bezogen werden. Für alle weiteren Besuche dieses Patienten in dieser LEI innerhalb des gleichen Quartals wird der vom Clientsystem gespeicherte PoPP-Token verwendet - somit muss für Folgebesuche keine eGK oder GesundheitsID verwendet werden. Das Clientsystem kann diesen VSD-Abruf bspw. als Hintergrunddienst bei einer dedizierten Nutzerinteraktion wie dem Aufruf des Patientenstamm oder dem Anklicken eines Aktualisierungsschalters zum Patientenstamm durchgeführt werden.

Das Feature der Versichertenstammdatenaktualisierung bei Folgebesuchen eines Patienten hat keinerlei rechtliche Verpflichtungen für die Leistungserbringerinstitution.

Hinweis: Im Gegensatz zu vorherigen VSDM-Versionen erstellt ein Fachdienst VSDM keinen Prüfungsnachweis mehr, sondern nur noch eine Prüfziffer.

Beispiel für den HTTP-Request des Clientsystems VSDM an den ZETA Client

GET /vsdservice/v1/vsdmbundle HTTP/1.1 
HOST: 101575519.vsdm2.ti-dienste.de
If-None-Match: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
Accept: application/fhir+json, application/fhir+xml
PoPP: Bearer <popp_token>

{

}

Beispiel für den HTTP-Request des ZETA Client mit ZETA/ASL-Kanal 

GET /vsdservice/v1/vsdmbundle HTTP/1.1 
HOST: 101575519.vsdm2.ti-dienste.de
Authorization: DPoP <access_token>
DPoP: <dpop_proof_jwt>

{

<HTTP-Request des Clientsystems VSDM>

}

Beispiel für die HTTP-Response für den Status HTTP 304 Not Modified:

HTTP/1.1 304 Not Modified
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pz: <Base64URL kodierte Prüfziffer>

{

}

Hinweis: Diese Response wurde schon vom ZETA Client aus dem ZETA/ASL-Kanal extrahiert.

Beispiel für die HTTP-Response für den Status HTTP 200 OK:

HTTP/1.1 200 OK
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
Content-Type: application/fhir+json; charset=utf-8
...
VSDM-Pz: <Base64URL kodierte Prüfziffer>

{

"resourceType": "VSDMBundle",

...

}

Hinweis: Dieser Response wurde schon vom ZETA Client aus dem ZETA/ASL-Kanal extrahiert.

Beispiel für eine HTTP-Response mit Fehlermeldung mittels FHIR-Resource

HTTP/1.1 404 Not Found
Content-Type: application/fhir+json; charset=utf-8
...

{

"resourceType": "VSDMOperationOutcome",

...

}

Hinweis: Dieser Request wurde schon vom ZETA Client aus dem ZETA/ASL-Kanal extrahiert.

4.1.2.2 Offline-Fall: Versichertenstammdaten von eGK lesen

Hinweis: Der Verweis auf den Implementierungsleitfaden für Primärsysteme bezieht sich ausschließlich auf die Verarbeitung der Versichertenstammdaten der eGK (Dekomprimierung, Dekodierung, VSD-Container von der eGK lesen, Interpretation der Stammdaten etc.

Ausblick:

Ab einem noch festzulegenden Datum wird nur noch der verkürzte Versichertenstammdatensatz auf elektronische Gesundheitskarten hinterlegt. Ein Clientsystem muss somit zukünftig für vor diesem Datum herausgegebene eGKs die kompletten als auch für ab diesem Zeitpunkt herausgegebene eGKs den reduzierten Versichertenstammdatensatz aus dem ungeschützten Bereich der eGK (Container PD und VD) lesen, verarbeiten und anzeigen können.

4.1.3 ZETA Client Funktionen

Die logische Komponente "ZETA Client" dient lediglich als Strukturierungselement für diese Spezifikation und soll die VSDM-spezifischen Clientsystem-Anforderungen an die ZETA Client Funktionen gemäß [gemSpec_ZETA] verdeutlichen.

Hinweis: Der Zeta-Client beinhaltet zwingend zu nutzende Kommunikationsfunktionen wie TLS, ZETA/ASL-Kanal und weitere (siehe [gemSpec_ZETA])

4.1.4 Fehlerbehandlung

4.2 ZETA Guard

Dieses Kapitel beschränkt sich folgend nur auf die ZETA Guard Komponenten mit VSDM-spezifischen Konfigurationsanforderungen. Vorgaben zur operativen Umsetzung der folgenden Konfigurationsanforderungen sind [gemSpec_ZETA] zu entnehmen.

Die folgenden Anforderungen an die Komponenten des ZETA Guard (als Teil eines Fachdienstes VSDM) werden durch Einträge in die VSDM-spezifische Konfigurationsdaten (Manifest-Dateien) gemäß [gemSpec_ZETA] umgesetzt (siehe auch 7.5 VSDM-spezifische Konfigurationsdaten ZETA Guard ). Da zum Veröffentlichungszeitpunkt dieser Spezifikation die konkrete Ausgestaltung der Manifest-Dateien noch nicht feststeht, werden die Manifest-Dateien zu einem späteren Zeitpunkt normativ referenziert und in den Anforderungshaushalt von VSDM 2.0 eingebunden.

Tabelle 2 : TAB_VSDM_KONFIGURATIONSÜBERSICHT_ZETA_GUARD

Hinweis:

Für Zugriffe auf den Resource-Server obliegt es dem Anbieter zu wählen, ob die Ingress & Egress Komponente oder die HTTP-Proxy Komponente des ZETA-Guard diese Anforderung durchsetzt.

4.2.1 HTTP-Proxy Konfiguration

Der HTTP-Proxy nimmt die Anfragen eines Clientsystems entgegen und prüft die Anfrage vor dem Aufbau eines ZETA/ASL-Kanals auf erlaubte Endpunkte sowie auf eine vorhandene sowie gültige Berechtigung auf Basis von DPoP- und Access-Token. Anschließend wird auf das Vorhandensein des Headers PoPP innerhalb des ZETA/ASL-Kanals geprüft und - wenn vorhanden - der PoPP-Token sicherheitstechnisch verifiziert.
Anschließend stellt der HTTP-Proxy eine HTTP-basierte Anfrage (ohne ZETA/ASL-Kanal, aber mit allen Informationen der Anfrage des Clientsystems) an den Resource-Server und fügt dieser die ZETA Guard spezifischen Header ZETA-User-Info, ZETA-PoPP-Token-Content und bei entsprechender HTTP-Proxy Konfiguration ZETA-Client-Data hinzu.

Antworten des Resource-Servers nimmt der HTTP-Proxy entgegen und setzt diese Richtung Clientsystem auf den ZETA/ASL-Kanal um.

4.2.1.1 Schnittstelle zum Clientsystem

4.2.1.2 Schnittstelle zum VSDM Resource Server

4.2.2 Authorization-Server Konfiguration

Hinweis: Die tägliche Authentifizierung ist ein Standardwert, der bspw. aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden kann. Zukünftig und bei Verfügbarkeit der VSDM-Policy wird dieser Standardwert über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

Hinweis: Zukünftig und bei Verfügbarkeit der VSDM-Policy werden die erlaubten OIDs über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

Die Angabe der konkreten ProfessionOIDs (OIDs der Berufsgruppe)  befindet sich im Dokument "gemSpec_OID).

Hinweis: Der Authorization-Server autorisiert auf Ebene eines API-Zugriffes bzw. für den Zugriff auf die VSDService-API des Resource Server eines Fachdienstes VSDM. Zukünftig und bei Verfügbarkeit der VSDM-Policy wird dieser Wert über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

Hinweis: Zukünftig und bei Verfügbarkeit der VSDM-Policy wird dieser Wert über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

Hinweis: Die Gültigkeitsdauer von 24 Stunden ist ein Standardwert, der bspw. aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden kann. Zukünftig und bei Verfügbarkeit der VSDM-Policy wird dieser Standardwert über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

Hinweis: Die Gültigkeitsdauer von 5 Minuten ist ein Standardwert, der bspw. aufgrund von Sicherheitsereignissen oder auf Basis der Sicherheitsbewertung des Clientsystems (Client-Attestation) im Betrieb mittels ZT-Policy geändert werden kann. Zukünftig und bei Verfügbarkeit der VSDM-Policy wird dieser Standardwert über die VSDM-Policy festgelegt und nicht mehr innerhalb dieser Spezifikation.

4.3 VSDM Resource Server

4.3.1 VSDService-API

Die VSDService-API stellt Clientsystemen unter dem Endpunkt /vsdservice/v1/vsdmbundle folgende Ressourcen bereit:

Tabelle 4 : TAB_FACHDIENST_VSDM_RESSOURCEN

4.3.1.1 Versichertenstammdaten

Auf eine Zugriffsprüfung auf Ressourcen-Ebene wird verzichtet, da die VSDService-API aktuell nur eine einzige und für alle zugriffsberechtigten Leistungserbringerinstitutionen gleiche Ressource (VSDMBundle) bereitstellt. Die Zugriffsprüfung entspricht damit exakt der Zugriffsautorisierung und Zugriffsprüfung durch den ZETA Guard. Sollte zukünftig die Notwendigkeit einer rollenspezifischen Versichertenstammdatenbereitstellung (VSDMBundle) entstehen, wird eine Zugriffsprüfung auf Ressourcen-Ebene und auf Basis von ProfessionOID eingeführt.

Hinweis: Die FHIR-Resource VSDMBundle beinhaltet die beiden FHIR Ressourcen VSDMPatient und VSDMCoverage.

4.3.1.2 Prüfziffer

Hinweis: Gemeint ist, dass die Prüfziffer immer an das Clientsystem und unabhängig davon, ob die Versichertenstammdaten in Form der FHIR-Resource VSDMBundle übermittelt werden oder nicht, übermittelt werden. Bedingung ist die korrekt durchgeführte Aktualitätsprüfung. In einem anderweitig auftretenden Fehlerfall, wird die Fehlermeldung ohne Prüfziffer übermittelt.

4.3.1.3 Beispiele für die HTTP-Response des Resource-Servers

Beispiel für die Übertragung der Prüfziffer für den Fall HTTP 304 Not Modified:

HTTP-Header

HTTP/1.1 304 Not Modified
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pz: <Base64URL kodierte Prüfziffer>

Beispiel für die Übertragung der Prüfziffer für den Fall HTTP 200 OK:

HTTP/1.1 200 OK
Content-Type: application/fhir+json; charset=utf-8
...
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pz: <Base64URL kodierte Prüfziffer>

{

"resourceType": "VSDMBundle",

...

}

4.3.1.4 Fehlermeldungen

Werte des Feldes BDE-Code dienen zur Kennzeichnung eines dedizierten Fehlers im Rahmen der Betriebsdatenlieferung und -erfassung. Der Wertebereich dieser Codes ist mit 79xxx festgelegt, um nicht mit anderen Nomenklaturen zu kollidieren. 

Beispiel für die Übertragung einer Fehlernachricht mit FHIR-Resource:

HTTP/1.1 404 Not Found
Content-Type: application/fhir+json; charset=utf-8
...

{

"resourceType": "VSDMOperationOutcome",

...

}

4.3.2 VSD-Aktualitätsprüfung

Da VSD-Abfragen häufig stattfinden, aber VSD-Änderungen im Vergleich dazu relativ selten sind, soll der VSDM Resource Server in Zusammenarbeit mit dem KTR-Bestandssystem einen eindeutigen Identifier als HTTP-ETag zur Verfügung stellen (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag ). Damit kann ein Clientsystem diesen ETag (256-Bit-Wert) lokal speichern und bei einer VSD-Abfrage dem Fachdienst VSDM übermitteln. Nun kann ein Fachdienst VSDM prüfen, ob überhaupt eine Aktualisierung bzw. eine Übertragung der Versichertenstammdaten notwendig ist oder ob die lokal im Clientsystem gespeicherten VSD noch aktuell sind (für diesen Fall wird nur die Prüfziffer übertragen).

Hinweis: Als Ausgangswert für der ETag kann die Gesamtheit eines dedizierten Versichertenstammdatensatzes, eine Versions-ID, ein Zeitstempel oder eine Zufallszahl dienen. Der finale ETag ist dann wie folgt zu bilden:

• SHA-256 Hash-Wert über die Gesamtheit des dedizierten Versichertenstammdatensatzes
• HMAC(SHA256)-Wert über die Versions-ID oder den Zeitstempel
• Zufallszahl mit hoher Güte (mit hoher Wahrscheinlichkeit nicht erratbar oder nachvollziehbar/nachrechenbar)

EIn SHA-256 Hash-Wert kann nicht ohne weitere Maßnahmen für die Erzeugung des ETags auf Basis einer reinen Versions-ID oder eines Zeistempels dienen, da man so als Abfragender erfährt (im Sinne von "nachrechnen") wie oft oder zu welcher Zeit sich diese VSD eines Versicherten sich geändert haben. Aufgrund dessen ist in diesen Fällen die Funktion HMAC-SHA-256(geheimer-Schlüssel, KVNR + VSD-Version oder Zeitstempel) als Pseudorandom-Funktion zu verwenden.

Hinweis: Die korrekte Umsetzung des Vergleiches von ETag und Änderungsindikator ist notwendig, um das Ziel der Übertragung von VSD nur bei einer Änderung dieser zu erreichen. Damit die Funktion der Änderungserkennung sich nicht negativ auf die Nutzer auswirkt, ist bei einem System-internen Fehlerfall dieser Funktion immer so zu verfahren, dass im Endeffekt das Clientsystem die Versichertenstammdaten und die Prüfziffer erhält.

4.3.3 FHIR-Fassade

4.3.4 Erstellung Prüfziffer

Die Prüfziffer dient als Nachweis über die durchgeführte Prüfung des Versicherungsstatus sowie der Aktualität der Versichertenstammdaten. Er dient als Nachweis für die Abrechnungsdaten nach § 295 SGB V.

Hinweis: Der Inhalt der Prüfziffer ist nicht weiter festgelegt und obliegt den Krankenversicherern.

4.3.5 Zugriffsprotokollierung

Der Fachdienst VSDM führt Zugriffsprotokolle für die Versicherten, in denen alle Zugriffe auf die personenbezogenen und medizinischen Daten eines Versicherten für den Versicherten einsehbar sind. Die Protokolleinträge werden gemäß der Löschfrist im VSDM Resource Server gespeichert und nach Ablauf dieser Frist automatisch gelöscht. Diese Zugriffsprotokolle sind unabhängig von technischen Protokollen und stehen ausschließlich dem Versicherten zur Wahrnehmung seiner Betroffenenrechte zur Einsicht zur Verfügung. Den Zugriff auf die Protokolle durch den Versicherten verantwortet der jeweilige Kostenträger und stellt seinen Versicherten geeignete Mittel und Wege zur Verfügung.

Anforderungen zum Inhalt des Nutzerprotokolls sind im Abschnitt 7.3 Zugriffsprotokoll für Versicherte formuliert. 

Hinweis: Der Zugriff durch Kostenträger oder Ombudsstellen darf ausschließlich auf Verlangen des Versicherten und zum Zweck der Beauskunftung gegenüber diesem erfolgen.

Hinweis: Es darf, wenn es die Implementierung vereinfacht, angenommen werden, dass ein Jahr 60*60*24*365 Sekunden hat.

4.3.6 VSD-DB

4.4 Fehlercodes

4.5 Monitoring und SIEM

Ein Fachdienst VSDM muss betriebliche und sicherheitskritische Ereignisse erfassen und je nach Schweregrad und Vorgaben der gematik an die Betriebsdatenerfassung und das SIEM der TI übermitteln. Die entsprechenden Anforderungen werden wie bei allen anderen Fachdiensten über den Anbietertypsteckbrief dem Anbieter VSDM zugeordnet.

Weitere Details zur Einbindung des ZETA Guard und Resource Server in das Monitorings und SIEM des Fachdienstes werden in [gemSpec_ZETA] erläutert.

5 Systemablauf

5.1 Online-Abruf Versichertenstammdaten und Prüfziffer

Abbildung 3: Sequenzdiagramm VSDM

6 Übergreifende Festlegungen

Der folgende Abschnitt beschreibt übergreifende Anforderungen an den Fachdienst VSDM zur Unterstützung der Fachlogik.

6.1 Systemzeit

Hinweis: Üblicherweise wird ein VSDM-Betreiber auf den relevanten Serversystemen das NTP-Protokoll zur Zeitsynchronisation gegenüber einer vertrauenswürdigen RZ-lokalen Zeitquelle verwenden. Für die Authentisierung von Abfragenden (LEI und Versicherten) und die Korrektheit der erzeugten Zugriffsprotokolle ist eine korrekte Systemzeit in den Komponenten notwendig, Dabei ist hierbei keine Genauigkeit im Nanosekundenbereich notwendig -- in A_26799 wurde +/-15 Sekunden als fachlich vertretbare Abweichung innerhalb der Komponenten bewertet.

6.2 Fachdienstlokalisierung

Unter Verwendung von DNS-Abfragen im Internet durch den VSDM-Client erfolgt die Lokalisierung der VSDM Schnittstellen. Dafür muss der Anbieter Fachdienst VSDM pro Institutionskennung einen Alias in der übergreifenden Domäne vsdm2.ti-dienste.de bereitstellen. Für die Umgebungen Referenzumgebung 1, Referenzumgebung 2 und Testumgebung der TI werden fourth-level Domänen eingerichtet: .ref (RU1), .dev (RU2) und .test (TU).

Jeder VSDM-Client kann unter Verwendung der ermittelten Institutionskennung aus dem PoPP-Token und der Lokalisierung die benötigte Schnittstelle des Fachdienstes VSDM ermitteln.

Die Idee, die mit dieser Festlegung verfolgt wird, ist folgende:

Die CNAME Resource Records in den Subdomänen unterhalb von vsdm2.ti-dienste.de werden zentral verwaltet und auf Basis der zugelieferten Informationen bereitgestellt. Der Canonical Name im Resource Record zeigt auf einen FQDN der Betreiber. Dadurch werden die Betreiber ertüchtigt, alle weiteren DNS-Einträge in ihren Nameservern eigenständig zu administrieren.

Beispiel zur Lokalisierung der dev - Umgebung für die Institutionskennung 123456789 und Betreiber betreiber-1:

123456789.dev.vsdm2.ti-dienste.de 86400 IN CNAME host.dev.vsdm2.betreiber-1.de

host.dev.vsdm2.betreiber-1.de IN A 198.51.100.1

Hinweis: Die TTL-Werte können im Rahmen des Change-Managements verändert werden.

Ist ein Dienstleister für das Management der Domäne und Resource Records beauftragt worden, muss dieser die Eintragungen in Übereinstimmung mit den Festlegungen vornehmen.

6.3 Systemprotokolle

Der Fachdienst VSDM muss Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren und die Performance zu analysieren. Für diese Zwecke führt der Fachdienst VSDM ein Systemprotokoll, mit dem der Anbieter des Dienstes jederzeit den Betriebszustand des Systems kontrollieren kann.

Hinweis: Die Systemprotokolle können nach Ablauf der Aufbewahrungsfrist gelöscht werden.

6.4 Berechtigungen

Grundsätzlich ist jede Leistungserbringerinstitution mit einer ProfessionOID gemäß A_26743 und einer gültigen SM(C)-B für das Lesen der Versichertenstammdaten von der eGK und zusätzlich mit einem vorhandenen sowie gültigen Versorgungskontext (PoPP-Token) für den Online-Abruf der Versichertenstammdaten berechtigt.

Erläuterung:
X: der fachliche Akteur ist berechtigt
nicht anwendbar: Kein Regelungsbestandteil durch die gematik und im Rahmen dieser Spezifikation.
nicht vorgesehen: Rechtlich nicht verboten, aber nicht als Use Case vorgesehen.
eingeschränkt erlaubt: Die Verarbeitung der Daten ist ausschließlich auf Verlangen des Versicherten und nur zum Zwecke der Auskunft gegenüber dem Versicherten innerhalb des gesetzlichen Rahmens zulässig. 
nicht erlaubt: Ist zu unterbinden.

Hinweis:
Die Regeln im Kontext UC_1 für Zugriffe auf die Fachdienst VSDM API /vsdservice werden technisch durch den ZETA Guard durchgesetzt. 

6.5 Authentifizierung und Autorisierung von Nutzern

Die Authentifizierung von Nutzern bzw. Leistungserbringerinstitutionen (LEI) erfolgt durch die Komponente "Authorization Server" des ZETA Guard und auf Basis der SMC-B (zukünftig auch SM-B). Eine erfolgreiche LEI-Authentifizierung ist Voraussetzung für die Durchführung der Autorisierung, die im Erfolgsfall mit der Ausgabe eines Refresh- und Access-Token für die LEI endet. Die Autorisierung erfolgt auf Basis der in der VSDM-Policy hinterlegten Regeln. Die Authentisierungsabläufe mit SMC-B in der LEI-Umgebung werden durch die logische Zero-Trust Komponente "ZETA Client" realisiert und durch den VSDM Authorization-Server (SW-Komponente des ZETA Guard) durchgesetzt.

VSDM-spezifische Anforderungen sind im Kapitel 4.2.2 Authorization-Server Konfiguration beschrieben. Das konkrete Regelwerk in Form einer VSDM-Policy ist unter [VSDM-Policy] hinterlegt.

Allgemeingültige Anforderungen im Rahmen der Authentifizierung und Autorisierung einer Leistungserbringerinstitution sind der Spezifikation [gemSpec_ZETA] und dem Produkttypsteckbrief [gemProdT_VSDM_2_FD]  zu entnehmen.

6.6 HTTP Status Codes

Der Fachdienst VSDM stellt eine http-Schnittstelle für den Aufruf durch Clientsysteme bereit. Das Ergebnis der Operation wird in der Verwendung von Http-Status-Codes gemäß [RFC2616] mitgeteilt. Die folgende Tabelle listet die vom Fachdienst VSDM genutzten Http-Status-Codes auf.

Tabelle 8 : TAB_FACHDIENST_VSDM_HTTP_STATUS_CODES

6.7 ZETA Guard

Hinweis: Die Erstellung und das Deployment der VSDM-Policy werden durch einen CID-Prozess gesteuert. Näheres zu diesem Prozess wird in [gemSpec_ZETA] definiert werden.

Hinweis: Die Erstellung und das Deployment der Manifest-Dateien werden durch einen CID-Prozess gesteuert. Näheres zu diesem Prozess wird in [gemSpec_ZETA] definiert werden.

6.8 Sicherheit und Datenschutz

Ein VSDM2-FD bewahrt Zugriffsprotokolle für Versicherte drei Jahre auf (vgl. Abschnitt 4.3.5 Zugriffsprotokollierung) und macht diese den Versicherten nach sicherer Authentisierung lesbar.

Anforderungen an den Anbieter bzw. Betreiber ergeben sich, wie für alle andere Fachdienste der TI, aus [gemSpec_DS_Anbieter] und sind dem Anbietertypsteckbrief zugewiesen.

Hinweis zur Profilbildung: Dies betrifft in besonderem Maße Daten, aus denen Rückschlüsse über ein dediziertes Arzt-Patienten-Verhältnis gezogen werden können.

Erläuterung zu A_27404:

Verschiedene Umsetzungsvarianten erfordern unterschiedlich starke Sicherheitsmechanismen.

6.9 Betrieb

In diesem Kapitel werden übergreifende, betriebliche Anforderungen getroffen oder auf Kapitel mit speziellen Ausprägungen für den Fachdienst VSDM in normativen Querschnittsdokumenten verwiesen.

Folgende, produktspezifische Vorgaben werden getroffen:

6.9.1 Schnittstellen und Anwendungsfälle

Die vom Fachdienst VSDM zur Verfügung gestellten Schnittstellen und Anwendungsfälle werden im entsprechenden Kapitel von [gemKPT_Betr] dargestellt.

6.9.2 Leistungsanforderungen und Performance

Die vom Fachdienst VSDM zu leistenden Performancevorgaben werden im entsprechenden Kapitel von [gemSpec_Perf] dargestellt. Dazu gehören insbesondere Vorgaben zur Verfügbarkeit, eingesetzten Redundanz und der Leistungsfähigkeit der Schnittstellenabrufe. Darüber hinaus werden Vorgaben zur Verarbeitung der eingesetzten Datenliefermodelle gemacht, die sich sowohl auf den Fachdienst, als auch organisatorisch auf den entsprechenden Anbieter beziehen, welcher diese Datenlieferungen gewährleisten muss.

6.9.3 Migration

Es ist vereinbart, dass ein definierter Zeitraum für die Migration von VSDM 1 zu VSDM 2 vorgesehen wird. Dabei kommt es zum Parallelbetrieb von VSDM 1 und VSDM 2. In dieser Zeit wird es notwendig sein, dass die angestrebte Transition mittels qualifizierter Unterstützungsleistungen von gematik und den Anbietern intensiv betreut wird.

Die Terminplanung sieht derzeit folgende Meilensteine ab einem Zeitpunkt T=0 vor (T wird zu einem späteren Zeitpunkt definiert):

• T=0: Beginn der kontrollierten Inbetriebnahme (KIB) von VSDM 2.
• T+1 Monat: Ende der KIB und Start 'Fokus auf die Modellregion'.
• T+3 Monate: Ende des Fokus auf die Modellregion.
• T+7 Monate: Offboarding der Fachdienste UFS, VSDD und CMS (VSDM 1).

Der Start (T=0) und das Erreichen der Meilensteine (T+) haben unterschiedliche Abhängigkeiten, die bis zu demjenigen Zeitpunkt vollständig aufgelöst werden müssen. Diese Abhängigkeiten und ein beispielhafter Ablauf werden nachfolgend kurz skizziert.

Die KIB wird intensiv von mindestens einem Transition-Manager der gematik begleitet, der u.a. bei der Anbieterzulassung VSDM 2 und abhängigen Nachweisführung ein Ansprechpartner ist. In der KIB MÜSSEN alle Instrumente des betrieblichen und sicherheitstechnischen Monitorings nachgewiesen werden. Dies gilt sowohl für PoPP, als auch für VSDM 2. Der Anbieter VSDM ist angehalten, das KIB-Verfahren binnen eines Monats mit Unterstützung der gematik vollständig abzuschließen.

Beginn der kontrollierten Inbetriebnahme (T=0):

Ab diesem Zeitpunkt findet dann ein Parallelbetrieb von VSDM 1 und VSDM 2 statt.

• Der PoPP-Service muss für den produktiven Betrieb bereit sein.
• Der Anbieter VSDM muss im Rahmen der KIB mindestens eine LEI suchen, in der die KIB durchgeführt werden kann.
• Der Anbieter VSDM muss im Rahmen der KIB mindestens zwei Versicherte suchen, die mit ihm diese KIB in der Praxis durchführen.
  

• Die Primärsysteme der KIB-Praxen müssen die VSDM2-, Zero-Trust und PoPP-Funktionen implementiert haben.
• Die Konnektorversion PTV 6 läuft erfolgreich in den KIB-Praxen.
• Bei der KIB müssen auch alle PoPP-Anwendungsfälle ausprobiert und validiert werden (eGK stecken, eGK kontaktlos, GesundheitsID-Versicherter, etc.), um den PoPP-Token zu erhalten und damit den Versichertenstammdatensatz abzurufen.

Ende der KIB und Start 'Fokus auf die Modellregion' (T+1 Monat):

Wenn eine Praxis bereits Software-seitig auf VSDM 2 umgestellt ist, kann die eGK dennoch mit der Konnektorfunktion "ReadVSD" ausgelesen werden. Dabei ist jedoch die Einschränkung vom PS-Hersteller "per default" vorzunehmen, sodass KEINE Onlineprüfung für VSDM 1 durchgeführt wird. Der Parameter "PerformOnlineCheck" muss gemäß [VSDM-A_2693] auf 'false' gesetzt werden.

Ende des Fokus auf die Modellregion (T+3 Monate):

Der Fokus auf die Modellregion wird in Rücksprache mit den Gesellschaftern beendet. Alternativ kann der Zeitraum erweitert werden. Die Empfehlung nach einem erfolgreichen Ende des Fokus auf die Modellregion kann z.B. ein bundesweiter Rollout sein.

Offboarding der Fachdienste UFS, VSDD und CMS - VSDM 1 (T+7 Monate):

Dieser Zeitpunkt ist der früheste Beginn der Ausgabe von eGKs mit verkürzten VSD. Das Offboarding der Fachdienste VSDM 1 kann beginnen.

6.9.3.1 Verfahren zum Umgang mit der strukturierten Prüfziffer

Das Verfahren der strukturierten Prüfziffer als Zugriffselement auf andere TI-Dienste aus dem Vorgängersystem VSDM 1 wird nicht weitergeführt. Stattdessen wird der originäre Sinn der Prüfziffer genutzt, um die Prüfung auf einen kryptografisch sichergestellten Abruf der Versichertenstammdaten - und damit die Abrechnungsgrundlage - zu ermöglichen. Um die Migration von TI 1.0 auf die TI 2.0 im Übergang flexibel zu gestalten, wird zukünftig übergangsweise der PoPP-Service eine strukturierte Prüfziffer ausschließlich zur Benutzung als Zugriffselement auf andere TI-Dienste anbieten. Perspektivisch soll durch die Akzeptanz von PoPP-Token anderer TI-Dienste (TI 2.0 Readiness) diese Notwendigkeit ersatzlos entfallen. In Zukunft ist es vorgesehen, dass der PoPP-Token (ohne die strukturierte Prüfziffer) als Nachweismerkmal des Versorgungskontextes den Zugriff auf andere TI 2.0 Dienste mit ermöglicht.

6.10 Test

Die Teststrategie der gematik für die TI 2.0 Anwendungen befindet sich aktuell in der Abstimmung mit den Gesellschaftern. Das daraus abzuleitende konkrete Testkonzept für VSDM und die daraus resultierenden Anforderungen an die VSDM Umsetzung sind dadurch noch nicht für eine Vorveröffentlichung verbindlich festgelegt.

Die Festlegungen hierzu werden in einem späteren Release nachgeführt.

6.11 Zulassung Fachdienste

Der konkrete Zulassungsschnitt und Zulassungsprozess für die VSDM Fachdienste inkl. der genutzten ZETA Guards befindet sich aktuell noch in Abstimmung.

Die Festlegungen hierzu werden in einem späteren Release nachgeführt.

6.12 Verfahren für Primärsysteme

Es ist vorgesehen für Primärsysteme ein Bestätigungsverfahren zum Nachweis der spezifikationskonformen Umsetzung der Anforderungen, die die Interoperabilität zwischen den Primärsystemen und der TI bzw. den für VSDM 2 benötigten Diensten sicherstellen, durchzuführen.

Die Festlegungen hierzu werden in einem späteren Release nachgeführt.

7 Informationsmodell

Die Informationsmodelle des systemspezifischen Konzepts VSDM leiten sich aus dem fachlichen Informationsmodell des Konzeptes VSDM ab.

7.1 Informationsmodell VSDM online

Die Spezifikation des fachlichen Informationsmodells erfolgt in Form von FHIR-Profilen im simplifier-Projekt https://simplifier.net/vsdm2, die als FHIR-Package in einer semantischen Versionierung veröffentlicht und gemanaged werden.

Die konkrete Ausgestaltung des Datensatzes befindet sich noch in Absprache zwischen den Gesellschaftern. Die in Abstimmung befindlichen Felder sind im logical model auf Simplifier mit "WIP" gekennzeichnet.

Die Festlegungen hierzu werden in einem späteren Release nachgeführt.

7.2 Informationsmodell verkürzte VSD auf eGK

Entsprechend den Vorgaben des SGB V werden die VSD auf der eGK nur noch in einem reduzierten Umfang abgelegt, der auch nicht mehr online aktualisiert wird. Diese Daten sind ab dieser VSDM Version nicht mehr relevant. Der Leistungserbringer kann jedoch zur Anwendung von Ersatzverfahren weiterhin auf diese Daten zugreifen. Diese Ersatzverfahren sind nicht Gegenstand der Anwendung VSDM.

Zukünftig werden nur noch folgende Daten auf neu ausgegebene elektronische Gesundheitskarten abgelegt:

Tabelle 9 : Übersicht der auf der eGK bereitgestellten Daten

7.3 Zugriffsprotokoll für Versicherte

Hinweis: Die Informationen <commonName> und <organizationName> werden über das Feld additionalProperties des ZETA-User-Info übertragen.

Hilfestellung zu ISO-8601:

Code-Beispiel in python

import datetime
datetime.datetime.now().isoformat()
>>> '2024-10-16T14:38:32.489558'

7.4 VSDM-Policy

Die VSDM-Policy wird von der gematik erstellt und gemäß [gemSpec_ZETA] über den Policy Administration Point (PAP) dem Anbieter eines Fachdienstes VSDM bereitgestellt.

7.5 VSDM-spezifische Konfigurationsdaten ZETA Guard

Die VSDM-spezifische Konfigurationen für die Komponenten des ZETA Guard müssen von dem Anbieter eines VSDM Fachdienstes nach dem Verfahren gemäß [gemSpec_ZETA] erstellt werden. Die zugehörigen Konfigurationsdateien (Manifest-Dateien) werden dem Anbieter eines Fachdienstes VSDM über das ZETA Git-Repository bereitgestellt. Wesentliche Konfigurationsdaten sind bspw. zu setzende Routen, Firewall-Regeln, Entity-Statements etc.

Die Manifest-Dateien werden dem Anbieter eines Fachdienstes VSDM als Templates zur Verfügung gestellt. Diese Templates beinhalten auch von der gematik festgelegte Konfigurationsdaten.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

8.5.2 Weitere Dokumente