Telematikinfrastruktur 2.0

Spezifikation

Versichertenstammdaten-
management 2.0 (VSDM 2.0)

    

     

      
Version
      
1.0.0_CC
     
     

      
Revision
      
1045110
     
     

      
Stand
      
15.11.2024
     
     

      
Status
      
Freigegeben für interne QS
     
     

      
Klassifizierung
      
Wert nicht konfiguriert
     
     

      
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

<<Genereller Hinweis:

Hidden Text wird blau dargestellt

In doppelten spitzen Klammen gefasste Mustertexte der Vorlage sind Hidden Text und sind für die Druckaufbereitung normalerweise ausgeblendet.

In einfachen spitzen Klammern gesetzte Begriffe sind Platzhalter und sinngemäß auszutauschen bzw. zu entfernen.>>

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üsselworte 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 des Prüfungsnachweises 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.

Abbildung 1 : Kontextdiagramm VSDM

2.1 Akteure und Rollen

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

2.1.1 Hersteller Zero-Trust Cluster

Der Hersteller des Zero-Trust Cluster implementiert und entwickelt die Komponenten des Cluster gemäß den Vorgaben der gematik [gemSpec_Zero_Trust].

2.1.2 Hersteller Fachdienst VSDM

Der Hersteller eines Fachdienstes VSDM implementiert und entwickelt den Fachdienst gemäß den Vorgaben der gematik.
Der Hersteller muss eine Produktzulassung für den Fachdienst erreichen. Dazu muss er den Fachdienst nach den Vorgaben der gematik testen und der gematik für Zulassungstests zur Verfügung stellen.

2.1.3 Anbieter Fachdienst VSDM

Der Anbieter eines Fachdienstes VSDM betreibt den zugelassenen Fachdienst im Internet gemäß den Vorgaben der gematik. Dabei muss er den von der gematik beigestellten Zero-Trust Cluster verwenden.
Neben dem Betrieb einer Instanz für den Produktivbetrieb müssen weitere Instanzen für die Test-, Entwicklungs- und Referenzumgebungen betrieben werden.

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 Zero-Trust Cluster, zu.

Die gematik stellt dem Anbieter eines Fachdienstes VSDM das qualitätsgesicherte Zero-Trust Cluster zur Integration und den Betrieb zur Verfügung.

Die gematik stellt dem Anbieter eines Fachdienstes VSDM Möglichkeiten zur Konfiguration des Zero-Trust Clusters 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 Trust-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 Trust-Client Funktionen den Fachdienst VSDM, um aktuelle Versichertenstammdaten sowie einen Prüfungsnachweis für Abrechnungszwecke zu erhalten.

Die Leistungserbringerinstitutionen bzw. deren Leistungserbringer oder medizinische Fachangestellte lesen mittels eines Primärsystems und der Nutzung eines Konnektors sowie eH-KT oder eines handelsüblichen Smartcard-Readers die Versichertenstammdaten von der elektronischen Gesundheitskarte (eGK).

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 des Prüfungsnachweises.

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.

Versicherte stellen durch das Stecken ihrer eGK der Leistungserbringerinstitution die Versichertenstammdaten bereit (Offline-Fall).

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 den Prüfungsnachweis 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).
Eine Authentisierung der Leistungserbringerinstitution mittels Konnektor, eH-KT und SMC-B oder mittels TI-Gateway und SM-B gegenüber den Fachdiensten VSDM ist einmal am Tag erforderlich.

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. Zukünftig wird die Nutzung handelsüblicher Smartcard-Reader für die eGK ohne Notwendigkeit eines Konnektors oder TI-Gateways angestrebt.

2.2.2 TI-Gateway

Für Leistungserbringerinstitutionen, die anstatt des Konnektors ein TI-Gateway nutzen, erfolgt die LEI-Authentisierung gegenüber dem PoPP-Service und einem Fachdienst VSDM auf Basis der vom Betreiber des TI-Gateway (zukünftig) 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 von Konnektor oder TI-Gateway oder zukünftig unter Nutzung eines handelsüblichen Smartcard-Readers nachgewiesen werden. 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 die 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 des Endpunktes für das JWKS-Document. 

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 VAU-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 VAU-Identität von den Primärsystemen genutzt werden können.

2.2.9 ZT-Authorization Repository

Das Zero-Trust Authorization Repository 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) über den Policy Administration Point (PAP) zur Verfügung. Darüber hinaus werden über den 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 ZT-Cluster Repository

Das Zero-Trust Cluster 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 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 Zero-Trust Cluster. 

Das Softwareprodukt "Zero-Trust Cluster" 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)

Wie jeder Fachdienst der TI (ePA, E-Rezept, KIM etc.) müssen im Fachdienst VSDM sicherheitskritische Ergebnisse erkannt werden. 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 VSD vom Fachdienst abrufen

• 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 den Prüfungsnachweis ü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 den Prüfungsnachweis über die abgefragten VSD im Primärsystem speichern.
• Als Leistungserbringer möchte ich die VSD bei jedem Besuch des Patienten innerhalb eines Quartals abrufen, um immer die jeweils aktuellen VSD im Primärsystem speichern zu können.

2.3.2 VSD von eGK lesen

• Als Leistungserbringer muss ich in der Lage sein, meine Leistungen am Patienten auch dann abrechnen zu können, wenn die Herstellung des Versorgungskontextes fehlschlägt und die VSD des Versicherten nicht von der zuständigen Krankenkasse abgerufen werden können. In diesem Fall nutze ich die auf der eGK gespeicherten Daten, um ein zur Abrechnung geeignetes Ersatzverfahren anwenden zu können.

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 ein Jahr 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üfungsnachweis

Hinweis: Es gelten die Vorgaben aus [gemSpec_Krypt] für TLS.

Hinweis: Der erste Teil ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers ist.

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 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 und das Clientsystem kann die VSD vollautomatisch (bspw. auf Basis des Öffnens des Patientenstammes durch einen Mitarbeiter der Leistungserbringerinstitution) durchgeführt werden.

Beispiel für den HTTP-Request des Clientsystems

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

{

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 die HTTP-Response für den Status HTTP 304 Not Modified:

HTTP/1.1 304 Not Modified
...
{

HTTP/1.1 304 Not Modified
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pn: <Base64URL kodierter Prüfungsnachweis>
VSDM-Pn-Type: application/xml
VSDM-Pn-Encoding: gzip
VSDM-Pn-Lenght: 256
VSDM-Pn-Disposition: attachment; filename="pruefungsnachweis.xml"

{

}

}

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

HTTP/1.1 200 OK
...
{

HTTP/1.1 200 OK
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
Content-Type: {application/fhir+json, application/fhir+xml};charset=utf-8
Content-Encoding: gzip
...
VSDM-Pn: <Base64URL kodierter Prüfungsnachweis>
VSDM-Pn-Type: application/xml
VSDM-Pn-Encoding: gzip
VSDM-Pn-Length: 256
VSDM-Pn-Disposition: attachment; filename="pruefungsnachweis.xml"

{

"resourceType": "VSDMBundle",

...

}

}

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

HTTP/1.1 404 Not Found
...

{

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

{

"resourceType": "VSDMOperationOutcome",

...

}

}

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 Trust-Client Funktionen

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

Hinweis: VAU-Protokoll und VAU-Kanal sind im Kontext VSDM Synonyme.

4.1.4 Fehlerbehandlung

4.2 Zero-Trust Cluster

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

Die folgenden Anforderungen an die Komponenten des Zero-Trust Cluster (als Teil eines Fachdienstes VSDM) werden durch Einträge in die VSDM-spezifische Konfigurationsdaten (Manifest-Dateien) gemäß [gemSpec_Zero_Trust] umgesetzt (siehe auch 7.6 VSDM-spezifische Konfigurationsdaten Zero-Trust Cluster ). Da zum Veröffentlichungszeitpunkt dieser Spezifikation die konkrete Ausgestaltung der Manifest-Dateien noch nicht feststeht, werden die Konfigurationsvorgaben in Form von Anforderungen und als Teil dieser Spezifikation festgelegt, und dem Produkttypsteckbrief zugeordnet. Steht die konkrete Ausgestaltung der Manifest-Dateien fest, werden zukünftige Spezifikationen nur noch auf die Manifest-Dateien in Form einer Anforderung verweisen.

Tabelle 2 : TAB_VSDM_KONFIGURATIONSÜBERSICHT_ZERO-TRUST_CLUSTER

4.2.1 HTTP-Proxy Konfiguration

Der HTTP-Proxy nimmt die Anfragen eines Clientsystems entgegen und prüft die Anfrage vor dem Aufbau eines VAU-Kanals mittels VAU-Protokoll 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 VAU-Kanals geprüft und - wenn vorhanden - der PoPP-Token sicherheitstechnisch verifiziert.
Anschließend stellt der HTTP-Proxy eine HTTP-basierte Anfrage (ohne VAU-Protokoll, aber mit allen Informationen der Anfrage des Clientsystems) an den Ressource-Server und fügt dieser die Zero-Trust Cluster spezifischen Header ZTA-User-Info, ZTA-PoPP-Token-Content und bei entsprechender HTTP-Proxy Konfiguration ZTA-Client-Data hinzu.

Antworten des Ressource-Servers nimmt der HTTP-Proxy entgegen und setzt diese Richtung Clientsystem auf das VAU-Protokoll um.

4.2.1.1 Schnittstelle zum Clientsystem

Hinweis: Diese Anforderung dient zur Überprüfung der Eignung des Fachdienstes VSDM in seiner Endkonfiguration. Der Anbieter eines Fachdienst VSDM muss diese korrekte Funktionalität nur überprüfen.

4.2.1.2 Schnittstelle zum VSDM Resource Server

Hinweis: Diese Anforderung dient zur Überprüfung der Eignung des Fachdienstes VSDM in seiner Endkonfiguration. Der Anbieter eines Fachdienst VSDM muss diese korrekte Funktionalität nur überprüfen.

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.

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. 

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

Hinweis: Bei hoher Auslastung des VSDM Resource Servers größer 80% darf auf eine Komprimierung verzichtet werden.

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 das Zero-Trust Cluster. 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üfungsnachweis

Hinweis: Gemeint ist, dass der Prüfungsnachweis 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üfungsnachweis übermittelt.

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

Beispiel für die Übertragung des Prüfungsnachweises für den Fall HTTP 304 Not Modified:

HTTP-Header

HTTP/1.1 304 Not Modified
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pn: <Base64URL kodierter Prüfungsnachweis>
VSDM-Pn-Type: application/xml
VSDM-Pn-Encoding: gzip
VSDM-Pn-Lenght: 256
VSDM-Pn-Disposition: attachment; filename="pruefungsnachweis.xml"

Beispiel für die Übertragung des Prüfungsnachweises für den Fall HTTP 200 OK:

HTTP/1.1 200 OK
Content-Type: {application/fhir+json, application/fhir+xml};charset=utf-8
...
ETag: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
VSDM-Pn: <Base64URL kodierter Prüfungsnachweis>
VSDM-Pn-Type: application/xml
VSDM-Pn-Encoding: gzip
VSDM-Pn-Length: 256
VSDM-Pn-Disposition: attachment; filename="pruefungsnachweis.xml"

{

"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, application/fhir+xml};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 prüfen, ob überhaupt eine Aktualisierung notwendig ist bzw. ob die lokal im Clientsystem gespeicherten VSD noch aktuell sind.

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 den Prüfungsnachweis erhält.

4.3.3 FHIR-Fassade

4.3.4 Erstellung Prüfungsnachweis

Der Prüfungsnachweis dient als Nachweis über die Durchführung der Prüfung des Versicherungsstatus und der Prüfung der Aktualität der Versichertenstammdaten. Er dient als Nachweis für die Abrechnungsdaten nach § 295 SGB V.

Beispiel: Prüfungsnachweis mit Base64 kodierter Prüfziffer (PZ).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PN xmlns="http://ws.gematik.de/fa/vsdm/pnw/v1.0" CDM_VERSION="1.0.0">
    <TS>20240919092007</TS>
    <E>1</E>
    <PZ>VDAyMzU5MDA1MDE3MjY3Mzc2MDFVVDLYyBOm+EDF0oe1aW/ndQe2p36MGAzvyBk=</PZ>
</PN>

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.4 Zugriffsprotokoll für Versicherte formuliert. 

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 BDE-Lieferung

4.5 SIEM

Ein VSDM2-FD muss sicherheitskritische Ereignisse im Fachdienst erfassen und je nach Schweregrad an das SIEM der TI übermitteln. Die Anforderungen dafür werden wie bei allen anderen Fachdiensten über die Zuweisung von Anforderungen aus [gemSpec_DS_Anbieter] dem Anbieter-Produkttypsteckbrief für VSDM-Anbieter zugeordnet.

5 Systemablauf

5.1 Online-Abruf Versichertenstammdaten und Prüfungsnachweis

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 verschiedenen Umgebungen der TI werden third-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 Übereinstimmungen 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 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

Hinweis: Die Regeln im Kontext UC_1 für Zugriffe auf die Fachdienst VSDM API /vsdservice werden technisch durch das Zero-Trust Cluster durchgesetzt.

6.5 Authentifizierung und Autorisierung von Nutzern

Die Authentifizierung von Nutzern bzw. Leistungserbringerinstitutionen (LEI) erfolgt durch die Zero-Trust Komponente "Authorization Server" 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 "Trust-Client" realisiert und durch den VSDM Authorization-Server (SW-Komponente des Zero-Trust Clusters) 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_Zero_Trust] 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 Zero-Trust Cluster

Hinweis: Die PoPP-Service Policy wird in GIT erstellt (CID-Prozess).

Hinweis: Die Erstellung und das Deployment werden durch einen CID-Prozess gesteuert.

6.8 Sicherheit und Datenschutz

Ein VSDM2-FD bewahrt Zugriffsprotokolle für Versicherte ein Jahr 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.

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. Dabei wird es notwendig sein, dass die angestrebte Transition mittels qualifizierter Unterstützungsleistungen von gematik und den Anbietern intensiv betreut wird.

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 Behandlungskontextes 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.

Sobald die Teststrategie der gematik abgestimmt ist, wird dieses Kapitel entsprechend angepasst.

6.11 Zulassung Fachdienste

Die Zulassung/Bestätigung für die VSDM 2 Fachdienste, bezüglich deren funktionalen, betrieblichen und weiteren Anforderungen an das Produkt selbst und an den Betrieb der Lösung gliedert sich in die nachfolgenden Zulassungen/Bestätigungen auf.

Produktzulassung:
Der Fachdienst VSDM erhält eine Produktzulassung.
 
Anbieterzulassung:
Die Anbieterzulassung muss durch die Organisation bzw. das Unternehmen beantragt werden, die bzw. das die Einhaltung der im Anbietertypsteckbrief adressierten Anforderungen vollumfänglich selbst oder im Rahmen seiner bestehenden Vertrags- und Rechtsverhältnisse um- bzw. durchsetzen kann. Aus der Anbieterrolle kann sich eine datenschutzrechtliche Verantwortlichkeit aus § 307 SGB V ergeben. - Hier ist somit der Antragsteller die Krankenkasse.
 
Betreiberbestätigung:
Wenn der Anbieter des Fachdienstes VSDM einen Betreiber des Fachdienstes VSDM beauftragt hat, kann der Nachweis der betrieblichen Eignung durch den Betreiber in einem gesonderten Bestätigungsverfahren erbracht werden, welches ein Vorverfahren zur Zulassung Anbieter Fachdienstes VSDM ist. 

Ausblick:

Die gematik strebt an, das Konstrukt der Anbieterzulassungen der einzelnen konkreten Kasse für die verschiedenen Produkte (VSDM und weitere) zu optimieren.

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.

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.

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 Prüfungsnachweis

Der Prüfungsnachweis dient als Nachweis über die Durchführung eines Versichertenstammdatenabrufes für das laufende Quartal und wird bei jedem Abruf an das Clientsystem übermittelt. Für die Erstellung der Abrechnungsunterlagen kann nur der vom Fachdienst VSDM übermittelte Prüfungsnachweis verwendet werden. Der durch den PoPP-Service im Rahmen der Herstellung des Behandlungskontextes übermittelte Prüfungsnachweis darf nicht verwendet werden.

A_26965 - Fachdienst VSDM - Resource Server - Erzeugung Prüfungsnachweis

Der Resource Server VSDM MUSS den Prüfungsnachweis entsprechend dem nachfolgend aufgeführten Informationsmodell Prüfungsnachweis erzeugen

Abbildung 4 : Informationsmodell Prüfungsnachweis

und mit folgenden Feldern befüllen:

Tabelle 10 : TAB_FACHDIENST_VSDM_STRUKTUR_PRÜFUNGSNACHWEIS

CDM:Version	Enthält die logische Version 1.0.0 für fachliche Datenstrukturen („Corresponding Data Modell“, Versionskennung mit Bezug zum jeweiligen Architektur-Modell).
Timestamp	Aktueller Zeitstempel UTC
Ergebnis	Ergebnis der Abrufs VSD 1= Abruf VSD durchgeführt
ErrorCode	./.
Prüfziffer	Vom Fachdienst VSDM gesendete Prüfziffer

[<=]

7.3.1 Aufbau der Prüfziffer

Hinweise:

Die Liste der Kennungen der Betreiber wird von der gematik bereitgestellt.

Die Ausgabelänge der HMAC(SHA-256)-Hashfunktion ist 32 Byte lang. Für die Prüfziffer werden die ersten 24 Byte verwendet. Die restlichen 8 Bytes werden verworfen.

Die gemäß A_26766 kodierte Datenstruktur ist die Prüfziffer.

7.4 Zugriffsprotokoll für Versicherte

Hilfestellung zu ISO-8601:

Code-Beispiel in python

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

7.5 VSDM-Policy

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

7.6 VSDM-spezifische Konfigurationsdaten Zero-Trust Cluster

Die VSDM-spezifische Konfigurationen für die Komponenten des Zero-Trust Cluster müssen von dem Anbieter eines VSDM Fachdienstes nach dem Verfahren gemäß [gemSpec_Zero_Trust] erstellt werden. Die zugehörigen Konfigurationsdateien (Manifest-Dateien) werden dem Anbieter eines Fachdienstes VSDM über das Zero-Trust Cluster 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

8.6 Klärungsbedarf <<optional>>

8.7 Allgemeine Erläuterungen <<optional>>

<<hier können die Interfaces und Operationen mit Verweis auf die jeweilige Seite gelistet werden. Lesehilfe zur Auflösung von Querbezügen>>