Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Fachmodul VSDM

    

     

      
Version
      
2.8.0
     
     

      
Revision
      
1230567
     
     

      
Stand
      
10.07.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_VSDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das vorliegende Dokument spezifiziert den Produkttyp Fachmodul VSDM und beschreibt, wie die fachlichen Abläufe umzusetzen sind, indem die Umsetzungsanforderungen aus der Systemlösung VSDM verfeinert und zu Blattanforderungen für das Fachmodul VSDM ausgearbeitet werden.

Die Systemlösung der Fachanwendung VSDM ist im systemspezifischen Konzept [gemSysL_VSDM] beschrieben. Es setzt die fachlichen Anforderungen des Lastenheftes auf Systemebene um, zerlegt die Fachanwendung VSDM in die zugehörigen Produkttypen, darunter das Fachmodul VSDM, und definiert die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation des Fachmoduls VSDM wird die Kenntnis von [gemSysL_VSDM] vorausgesetzt.

Die Anforderungen an den sicheren Transport der fachanwendungsspezifischen Daten zwischen Fachmodul VSDM und der Fachdienste VSDM werden separat in der Schnittstellenspezifikationen Transport VSDM [gemSpec_SST_VSDM] und Schnittstellenspezifikation Fachdienste (UFS/VSDD/CMS) [gemSpec_SST_FD_VSDM] behandelt.

Die Anforderungen an den Transport der fachanwendungsspezifischen Daten zwischen Fachmodul VSDM und dem Clientsystem werden separat in der Schnittstellenspezifikation Primärsysteme VSDM [gemSpec_SST_PS_VSDM] behandelt.

Die Abbildung 1 zeigt schematisch die Dokumentenhierarchie im Projekt VSDM, in welcher die Spezifikation Fachmodul und die Konzepte und Spezifikationen eingeordnet sind. Die Abbildung stellt nicht die vollständige Dokumentenhierarchie des Projekts Online-Produktivbetrieb (Stufe 1) oder den Trace der Anforderungen dar.

Abbildung 1: Dokumentenhierarchie im Projekt VSDM

In diesem Dokument wird einleitend in Kapitel 1 die Zielsetzung des Dokumentes, die notwendigen Grundlagen und die gewählten Methoden dargestellt.

Das Kapitel 2 enthält einen Systemüberblick zur besseren Einordnung des Fachmoduls.

Das Kapitel 3 spezifiziert das Verhalten der Schnittstellen.

Das Kapitel 4 spezifiziert die Funktionen und die funktionalen Eigenschaften des Fachmoduls VSDM.

Das Kapitel 5 spezifiziert die nicht-funktionalen Anforderungen.

Die Ausgangsanforderungen dieser Spezifikation und deren Zusammenhang zu den Anforderungen aus dem übergeordneten Konzepten und Spezifikationen werden tabellarisch in Anhang B dargestellt.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Hersteller und Anbieter von Produkten für die 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 Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

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 Arbeitsgrundlagen

Grundlagen für die Ausführungen dieses Dokumentes sind

• das systemspezifische Konzept VSDM [gemSysL_VSDM]
• das Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
• die Konnektorspezifikation [gemSpec_Kon]

1.5 Abgrenzung des Dokuments

Innerhalb dieses Dokuments wird auf die technische Umsetzung der Anforderungen an das Fachmodul VSDM eingegangen. Anforderungen an andere Produkttypen sind nicht Bestandteil des Dokuments. Für Informationen zur Systemlösung wird auf das systemspezifische Konzept VSDM [gemSysL_VSDM] verwiesen.

Die Schnittstellen der Fachdienste VSDM sind in den Schnittstellenspezifikationen [gemSpec_SST_VSDM] und [gemSpec_SST_FD_VSDM], die Schnittstellen des Fachmoduls VSDM für das Primärsystem in [gemSpec_SST_PS_VSDM] beschrieben und spezifiziert. Sie werden hier nicht wiederholt. Die Kenntnis der Schnittstellen der Fachdienste und die Operationen GetUpdateFlags, PerformUpdates und GetNextCommandPackage werden vorausgesetzt.

Die vom vorliegenden Dokument referenzierten Technical Use Cases (TUC) des Konnektors sind in der Konnektorspezifikation [gemSpec_Kon] beschrieben.

Das hier spezifizierte Fachmodul VSDM ist nicht für den Einsatz in mobilen Kartenterminals vorgesehen. Die Anforderungen, die sich aus den fachlichen Abläufen im mobilen Einsatzszenario ergeben, sind in dem Dokument [gemSpec_MobKT_St2] beschrieben.

1.6 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sofern im Text auf die Ausgangsanforderungen verwiesen wird, erfolgt dies in eckigen Klammern, z.B. [VSDM-A_2093]. Dies tritt häufig bei Modellen und Tabellen auf, da viele Umsetzungsanforderungen genau auf eine dieser methodischen Beschreibungen verweisen. Wird auf Eingangsanforderungen verwiesen, erfolgt dies in runden Klammern, z.B. (VSDM-A_303).

In Anhang B (Anforderungshaushalt) dieses Dokuments werden in der Tabelle 27 die Eingangsanforderungen aufgelistet, die in diesem Ergebnisdokument berücksichtigt sind. In der Spalte „umgesetzt durch“ finden sich die eindeutigen Referenzen auf die dazu erarbeiteten Umsetzungsanforderungen. Im Anhang B in der Tabelle 28 stehen die Umsetzungsanforderungen mit ihrem Text und dem entsprechenden Vorgänger.

Die zu einer Eingangsanforderung referenzierte Umsetzungsanforderung spiegelt die erste Ebene des Anforderungsbaumes wieder. Die Verfeinerung dieser Anforderungen zu einem vollständigen Anforderungsbaum erfolgt in einem Anforderungsmanagement-Tool und nicht im vorliegenden Dokument.

Auf der untersten Ebene des Anforderungsbaums stehen die Blattanforderungen an die jeweiligen Produkttypen, die für eine Zulassung erfüllt werden müssen. Dieses Dokument stellt Blattanforderungen an das Fachmodul VSDM.

2 Systemüberblick

2.1 Systemkontext

Das Fachmodul VSDM wird als integraler Bestandteil des Anwendungskonnektors als eine der dezentralen Komponenten der TI betrieben. Es unterstützt die Anwendungsfälle der Fachanwendung VSDM, indem es dem Clientsystem (i.d.R. PVS/KIS) anwendungsspezifischen Schnittstellen zum Auslesen der Versichertenstammdaten der eGK und der KVK anbietet. Dazu nutzt es Funktionalitäten, die der Anwendungskonnektor anbietet, wie z.B. Zugriff auf die Karten.

Für die Unterstützung des Anwendungsfalls „VSD von eGK in der AdV lesen“ wird das Fachmodul VSDM als integraler Bestandteil der AdV in einer Umgebung im Auftrag der Kostenträger (KTR-AdV) betrieben. Die KTR-AdV besteht aus den Teilsystemen AdV-Server (Server) und AdV-App (Client). Die Umsetzung des Fachmodules VSDM in der KTR-AdV hat clientseitige und serverseitige Anteile.

Um die Aktualität der VSD auf der eGK zu prüfen, kommuniziert das Fachmodul unter Nutzung des fachanwendungsspezifischen Intermediärs VSDM mit dem Fachdienst des Kostenträges des Versicherten und aktualisiert bei Bedarf die VSD.

Abbildung 2: Fachmodul im Systemkontext

2.2 Funktionen

Das Fachmodul ist verantwortlich für die fachlichen Abläufe der Fachanwendung VSDM im Konnektor. Wesentliche Teile des Funktionsumfangs sind: Lesen der Versichertendaten von der eGK bzw. von der KVK, Prüfen der Vorbedingungen, Kommunikation mit den Fachdiensten, um die eGK zu aktualisieren und Erstellung des Prüfungsnachweises.

In der KTR-AdV beschränkt sich der Funktionsumfang auf die eGK. Die KVK wird nicht unterstützt.

2.3 Unterstützte Versionen der eGK

Von der elektronischen Gesundheitskarte existieren die Versionen Generation 0 (G0), Generation 1 (G1), Generation 1 plus (G1+), Generation 2 (G2) und Generation 2.1 (G2.1). Die Versionen G1+, G2 und höher beherrschen das Speichern des Prüfungsnachweises auf der eGK, wie es für das Standalone-Szenario erforderlich ist. Da die älteren Versionen der eGK somit nicht für den Einsatz im Online-Produktivbetrieb geeignet sind, besteht für das Fachmodul VSDM keine Notwendigkeit, die Versionen G0 und G1 der eGK zu unterstützen. Sollen die Versichertenstammdaten von einer eGK mit einer älteren Version als Generation 1 plus gelesen werden, muss das Fachmodul mit einer Fehlermeldung abbrechen. [VSDM-A_2607] [VSDM-A_2687]

Die Operation ReadVSDAdV wird nur mit der der eGK-Version G2 oder höher genutzt, da die AdV als Ablaufumgebung nur die eGK-Version G2 oder höher unterstützt.

Die Version der eGK ist im Container EF.Version in [gemSpec_eGK_ObjSys] spezifiziert und die konkrete Versionsnummer der eGK Generation in der Dokumentenlandkarte dokumentiert.

Die für die Fachanwendung VSDM spezifischen Speicherstrukturen der eGK werden in [gemSpec_eGK_Fach_VSDM] beschrieben. Die Version der VSDM Speicherstrukturen wird in EF.StatusVD.Version_Speicherstruktur Container der eGK vorgegeben. Bei der Generation 1 plus Karten kann dieser Container leer sein. In diesem Fall entsprechen die Speicherstrukturen gemäß [gemeGK_Fach] des Releases 0.5.3. Falls die EF.StatusVD.Version_Speicherstruktur eine unbekannte Version der VSDM Speicherstrukturen referenziert, muss das Fachmodul mit einer Fehlermeldung abbrechen. [VSDM-A_2979]

Hinweis: Der Konnektor unterstützt eGK mit einer älteren Version als Generation 1 plus nicht. Sie werden mit dem Kartentyp CARD.TYPE = UNKNOWN geführt.

3 Schnittstellen

Dem Primärsystem werden vom Fachmodul VSDM die zwei Schnittstellen I_VSDService mit der Operation ReadVSD und I_KVKService mit der Operation ReadKVK zur Verfügung gestellt. Der Anwendungsfall „VSD von eGK lesen“ wird durch Aufruf der Operation ReadVSD gestartet, der Anwendungsfall „Versichertendaten von KVK lesen“ durch den Aufruf der Operation ReadKVK. Die Details dieser SOAP-Schnittstellen inklusive der Parameter sind in der Schnittstellenspezifikation Primärsysteme VSDM [gemSpec_SST_PS_VSDM] spezifiziert und werden hier nicht wiederholt.

Im Standalone-Szenario wird der Anwendungsfall „Automatische Onlineprüfung VSD“ beim Stecken einer eGK durch Aufruf der Operation AutoUpdateVSD initiiert.

Der KTR-AdV wird vom Fachmodul VSDM die Schnittstelle I_VSDAdVService mit der Operation ReadVSDAdV zur Verfügung gestellt. Der Anwendungsfall „VSD von eGK in der AdV lesen“ wird durch Aufruf der Operation ReadVSDAdV gestartet.

Abbildung 3: Schnittstellen des Fachmoduls

Die Ablauflogik der Anwendungsfälle ist in dem Systemspezifischen Konzept Versichertenstammdatenmanagement [gemSysL_VSDM] vorgegeben und wird hier weiter detailliert.

Für die vier relevanten Anwendungsfälle werden die Aktivitätsdiagramme aus [gemSysL_VSDM#AnhC] informativ wiederholt, um die Lesbarkeit dieses Dokuments zu erhöhen.

3.1 Übergreifende Festlegungen

Bei jedem Operationsaufruf an der Schnittstelle I_VSDServiceoder I_KVKService des Fachmoduls wird der Aufrufkontext bestehend aus Mandanten-ID, Clientsystem-ID, Arbeitsplatz-ID und ggf. User-ID übergeben. Das Fachmodul muss diese Parameter vor Beginn der Ausführung einer Operation mittels des TUC_KON_000 „Prüfe Zugriffsberechtigung“ prüfen, um sicherzustellen, dass für die Durchführung von Operationen erforderliche eGK, HBA, SM-B, KVK im gegebenen Kontext verwendet werden dürfen. Ist der Aufrufkontext nicht zulässig, muss die Verarbeitung mit einer Fehlermeldung abgebrochen werden. [VSDM-A_2775]

3.2 Schnittstellen zum Primärsystem Clientsystem

Die Aktivitätsdiagramme aus [gemSysL_VSDM] beschreiben den Ablauf des Anwendungsfalls und geben das Verhalten der Schnittstellen vor. Die Schnittstellenimplementierung muss die Einzelaktivitäten nicht exakt umsetzen, sondern kann davon abweichen, solange die Schnittstelle das geforderte Verhalten zeigt. Sichtbare und damit testbare Ergebnisse des Schnittstellenaufrufs umfassen die Ausgangsparameter, Fehlermeldungen, Änderungen der Daten der eGK (u.a. Aktualisierung der VSD) und das Zeitverhalten.

3.2.1 Operation ReadVSD

Das Fachmodul VSDM realisiert die Schnittstelle I_VSDService mit der Operation ReadVSD. Diese Operation dient der Initiierung des Anwendungsfalls „VSD von eGK lesen“.

3.2.1.1 Verhalten der Operation

Die Operation liefert immer mindestens die persönlichen Versichertendaten (PD), die allgemeinen Versicherungsdaten (VD) und den Status-Container der angegebenen eGK dem Aufrufer zurück, sofern die Gesundheitsanwendung der eGK nicht gesperrt ist, das AUT-Zertifikat der eGK weder offline noch online ungültig ist, die Versichertenstammdaten konsistent sind und beim Auslesen der Daten kein technischer Fehler aufgetreten ist. [VSDM-A_2567] [VSDM-A_2568] [VSDM-A_2569] [VSDM-A_2570] [VSDM-A_2571]

Um die GVD von der eGK zu lesen und den Prüfungsnachweis und die Protokolleinträge auf die eGK schreiben zu können, muss die eGK vorher mittels C2C (einseitige oder gegenseitige Authentisierung) freigeschaltet bzw. die Echtheit der beteiligen Karten geprüft werden. Die Authentisierung mittels C2C soll abgebrochen werden, wenn Aktualisierungsaufträge ermittelt wurden. Wenn bereits im Ablauf durch eine erfolgreiche Aktualisierung die Echtheit der eGK nachgewiesen ist, soll lediglich eine einseitige Authentisierung des SM-Bs bzw. der HBA durchgeführt werden. Da bei der Aktualisierung der eGK die Karte gegenüber dem Fachdienstserver mit geheimen, privaten Schlüsselmaterial einen Trusted Channel aufbaut, ist die Echtheit der eGK nachgewiesen. Können die GVD aufgrund fehlender Berechtigungen nicht gelesen werden, werden trotzdem die PD und VD zurückgegeben. [VSDM-A_2572] [VSDM-A_2573] [VSDM-A_2574] [VSDM-A_2662]

Die eGK enthält derzeit als Übergangsregelung für den Basis-Rollout noch eine Kopie der GVD im EF.VD Container. Das Fachmodul VSDM darf die GVD aus dem EF.VD Container nicht lesen. [VSDM-A_2784]

Wenn der Status-Container nach der Ausführung von vorliegenden Aktualisierungen im Feld Status den Wert '1' enthält und damit auf inkonsistente Versichertenstammdaten hinweist, muss mit einer Fehlermeldung abgebrochen werden. In diesem Fall soll das Primärsystem die Operation erneut mit dem Werttrue im Parameter PerformUpdate aufrufen, um eine evt. nicht vollständig ausgeführte Aktualisierung zu wiederholen. Die Inhalte des Containers StatusVD müssen in die Datenstruktur der Antwortnachricht der Operation umgewandelt werden. Die Details sind in 4.4 beschrieben. [VSDM-A_2660]

Der Prüfungsnachweis ist in der Antwort enthalten, wenn dieser im Aufruf angefordert ist. Erzeugt wird ein Prüfungsnachweis, wenn eine Ermittlung der Aktualisierungsaufträge stattfindet bzw. eine Aktualisierung durchgeführt wird oder wenn keine Verbindung zur TI besteht, aber eine Onlineprüfung über die Eingangsparameter gefordert ist. Der Aufbau und Inhalt des Prüfungsnachweises ist in Kapitel 4.1.1 näher erläutert. [VSDM-A_2575] [VSDM-A_2576] [VSDM-A_2578]

Wurde ein Prüfungsnachweis erzeugt und ist die Rückgabe des Prüfungsnachweises über die Eingangsparameter gefordert, muss dieser auch auf die eGK geschrieben werden. Der Prüfungsnachweis soll zur Performanceoptimierung parallel zur Rückgabe der Antwort auf die eGK geschrieben werden. Schlägt das Schreiben fehl, z.B. weil die eGK vorzeitig gezogen wurde, erhält das Clientsystem den Prüfungsnachweis trotzdem als Bestandteil der Antwort des Fachmoduls und kann damit für Abrechnungszwecke genutzt werden. [VSDM-A_2579] [VSDM-A_2772]

Wurde kein Prüfungsnachweis erzeugt und ist die Rückgabe des Prüfungsnachweises gefordert (z.B. im Standalone-Szenario), so muss, sofern die Gesundheitsanwendung der eGK nicht gesperrt ist, der Prüfungsnachweis von der eGK gelesen und entschlüsselt werden. [VSDM-A_2577]

Wenn eine Verbindung zur TI besteht, muss die Ermittlung von Aktualisierungsaufträgen für die eGK und anschließende Durchführung immer dann erfolgen, wenn dies über den Eingangsparameter vom Aufrufer gefordert ist, die Gesundheitsanwendung der eGK gesperrt ist oder das AUT-Zertifikat der eGK online oder offline ungültig ist. Wird durch eine Aktualisierung die Gesundheitsanwendung gesperrt, dürfen die Versichertenstammdaten nicht gelesen werden. [VSDM-A_2580] [VSDM-A_2581] [VSDM-A_2582] [VSDM-A_2583] [VSDM-A_2584] [VSDM-A_2585]

Für eine durchgeführte VSD Aktualisierung und für das Lesen der GVD muss je ein Protokolleintrag gemäß Kapitel 4.2 auf der eGK erstellt werden. [VSDM-A_2586] [VSDM-A_2587]

Die Versichertenstammdaten und der Prüfungsnachweis werden vom Fachmodul vor der Rückgabe mittels Base64 kodiert, um die Binärdaten mit dem textbasierten SOAP-Protokoll transportieren zu können. Wurde der Prüfungsnachweis im Ablauf erstellt und nicht von der eGK gelesen (vgl. VSDM-UC_01 im Online-Szenario mit ReadOnlineReceipt true), wird er vor der Kodierung mittels Base64 vom Fachmodul VSDM komprimiert. Somit erhält der Aufrufer der Operation ReadVSD die Versichertenstammdaten und den Prüfungsnachweis immer in Base64 kodierter und komprimierter Form. [VSDM-A_2652]

Zum besseren Verständnis sind im Folgenden exemplarisch drei Varianten des Anwendungsfalls mit dem jeweiligen Ergebnis dargestellt, vgl. auch [gemSysL_VSDM#AnhD1].

Tabelle 1: Tab_FM_VSDM_01 – VSD von eGK lesen im Normalfall

Tabelle 2: Tab_FM_VSDM_02 – VSD von eGK lesen, wenn die TI online nicht verfügbar ist

Tabelle 3: Tab_FM_VSDM_03 – VSD von eGK lesen, wenn Gesundheitsanwendung gesperrt wird

3.2.1.2 Ablauf (informativ)

Wie am Anfang dieses Kapitels beschrieben, ist die Ablauflogik der Operation in dem Systemspezifischen Konzept Versichertenstammdatenmanagement [gemSysL_VSDM] vorgegeben. Die Aktivitäten der Ablauflogik werden in Tabelle Tab_FM_VSDM_15 mit den Aufrufen von entsprechenden TUCs und im Aktivitätsdiagramm in Anhang C1 informativ dargestellt.

Tabelle 4: Tab_FM_VSDM_15 – ReadVSD: Für Aktivitäten verwendete TUCs

Aktivität	Kurzbeschreibung	Aufgerufene TUCs
Aufrufkontext prüfen	Der TUC_KON_000 „Prüfe Zugriffsberechtigung“ wird zwei Mal – ein Mal für den HBA bzw. das SM-B und ein Mal für die eGK aufgerufen, um sicherzustellen, dass sowohl der HBA bzw. das SM-B als auch die eGK im gegebenen Kontext verwendet werden dürfen. Der TUC muss mit den Eingangsparametern aufgerufen werden, die den Parametern der ReadVSD-Schnittstelle des Fachmoduls entsprechen: mandantId, clientSystemId, workplaceId, userId (falls ein HBA verwendet wird), HpcHandle, EhcHandle (siehe [gemSpec_SST_PS_VSDM]). ctId, needCardSession, allWorkplaces Parameter des TUCs bleiben nicht befüllt.
eGK reservieren	Der TUC_KON_026 „Liefere CardSession” wird verwendet, um die CardSession von der eGK zu erhalten. Der TUC_KON_023 “Karte reservieren” wird mit den Eingangsparametern CardSession eGK und DoLock = Ja verwendet, um die Karte zu reservieren.
Technische Nutzbarkeit und Gültigkeit der eGK prüfen	Der TUC_KON_018 „eGK-Sperrung prüfen” wird aufgerufen. Das Ergebnis der Operation ist Grundlage für die Steuerung des weiteren Ablaufs.
Echtheit der beteiligten Karten prüfen	Der TUC_KON_026 „Liefere CardSession” wird verwendet, um die CardSession von SM-B bzw. HBA zu erhalten. Der TUC_KON_022 „Liefere PIN-Status” für PIN.SMC bzw. PIN.CH prüft, ob SM-B bzw. HBA freigeschaltet sind. Falls nein, bricht das Fachmodul mit Fehlercode 3041 bzw. 3042 ab. In diesem Fall muss das Primärsystem die externe Schnittstelle des Konnektors VerifyPin für PIN.SMC bzw. PIN.CH aufrufen, um den Sicherheitszustand der entsprechenden Karte zu erhöhen (siehe [gemILF_PS] für weitere Details) und den ReadVSD Vorgang wiederholen. Der TUC_KON_005 „Card-to-Card authentisieren“ wird für eine gegenseitige Echtheitsprüfung von eGK und SM-B/HBA aufgerufen. Wird während der Echtheitsprüfung ein Aktualisierungsauftrag ermittelt, wird die Echtheitsprüfung mittels des TUC_KON_024 „Karte zurücksetzen” abgebrochen.
Aktualisierungsaufträge ermitteln	Die SOAP-Operation für die Abfrage der Aktualisierungsaufträge ist in der Schnittstellenspezifikation Fachdienste [gemSpec_SST_FD_VSDM] beschrieben. Die für die Operation GetUpdateFlags erforderliche ICCSN wird über den TUC_KON_202 „LeseDatei” aus EF.GDO Container (siehe [gemSpec_eGK_ObjSys]) der eGK ermittelt. Die für die Fachdienstlokalisierung erforderliche ProviderID wird aus dem AUT-Zertifikat der eGK ausgelesen. Das Zertifikat wird von eGK über den TUC_KON_034 „Zertifikatsinformationen extrahieren” ermittelt. Weitere Details zur Fachdienstlokalisierung sind im Kapitel 4.3.3 aufgeführt. Der Aufruf wird über die, mit Hilfe von TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen” aufgebaute, TLS-Verbindung verschickt. Die TLS-Verbindung wird mit beidseitiger Authentifizierung aufgebaut. Für die clientseitige Authentifizierung muss das durch den Konfigurationsparameter MANDANT_SMB definierte SM-B (siehe Kap. 4.8) verwendet werden. Der Aufbau der URL, die für die TLS-Verbindung erforderlich ist, wird im Kapitel 4.3.3 beschrieben. Bevor der TUC_KON_110 aufgerufen wird, prüft das Fachmodul mit Hilfe von TUC_KON_022 „Liefere PIN-Status”, ob SM-B freigeschaltet ist. Falls nein (das kann passieren, wenn Card-to-Card-Authentisierung mit HBA durchgeführt wurde), bricht das Fachmodul mit Fehlercode 3041 ab. In diesem Fall muss das Primärsystem die externe Schnittstelle des Konnektors VerifyPin aufrufen, um den Sicherheitszustand SM-B zu erhöhen (siehe [gemILF_PS] für weitere Details) und den ReadVSD Vorgang wiederholen. Weitere Details zum Ermitteln der Aktualisierungsaufträge und zur Durchführung der Aktualisierungen sind im Kapitel 4.3 aufgeführt.
Aktualisierungen durchführen	Für jeden ermittelten Aktualisierungsauftrag wird eine Aktualisierung durchgeführt. Bevor die Aktualisierung durchgeführt wird, wird das Clientsystem mittels des TUC_KON_256 „Systemereignis absetzen” durch VSDM/PROGRESS/UPDATE Ereignis (siehe Tabelle 19) über den Anfang der Aktualisierung informiert. Die Werte für den Aufruf der PerformUpdates SOAP-Operation werden den Aktualisierungsaufträgen entnommen. Anschließend wird die Aktualisierung mittels der SOAP-Operation GetNextCommandPackage fortgeführt. Zum Senden der empfangenen Kartenbefehle wird der TUC_KON_200 „Sende APDU” verwendet. Weitere Details zum Ermitteln der Aktualisierungsaufträge und zur Durchführung der Aktualisierungen sind im Kapitel 4.3 aufgeführt. Nachdem die CMS-Aktualisierungen durchgeführt wurden, muss geprüft werden, ob die eGK durch die Aktualisierung gesperrt bzw. die bestehende Sperrung aufgehoben ist. Dafür kann einer der Gesundheitsanwendung zugehörigen Container (z.B. EF.PD) mit Hilfe von TUC_KON_202 „LeseDatei” gelesen werden. Falls die eGK gesperrt bzw. die bestehende Sperrung nicht aufgehoben ist, wird der TUC mit einem Fehler abbrechen und somit wird der Vorgang mit Fehler 114 („Gesundheitsanwendung auf eGK gesperrt“) abgebrochen.
Echtheit der beteiligten Karten prüfen	Nach einer erfolgreichen Aktualisierung der eGK muss diese zum Lesen der VSD freigeschaltet werden und das Fachmodul eine Echtheitsprüfung SM-B bzw. HBA mittels des TUC_KON_005 „Card-to-Card authentisieren“ ausführen. Durch eine erfolgreiche Aktualisierung wird die Echtheit der eGK nachgewiesen und daher soll lediglich eine einseitige Authentisierung des SM-Bs bzw. der HBA durchgeführt werden.
Prüfungsnachweis erzeugen	Die Erzeugung des Prüfungsnachweises erfolgt nur im Fachmodul. Es müssen keine TUCs aufgerufen werden. Der Aufbau und Inhalt des Prüfungsnachweises ist in Kapitel 4.1 beschrieben.
VSD Status Container lesen	Der EF.StatusVD Container (siehe [gemSpec_eGK_ObjSys]) wird mittels des TUC_KON_202 „LeseDatei” ausgelesen. Falls der Inhalt des Status-Container auf inkonsistente VSD hinweist, muss der Ablauf durch das Fachmodul unterbrochen, evtl. ausstehende Protokollierungseinträge auf die eGK geschrieben und dem Clientsystem mit einer Fehlermeldung geantwortet werden. Die VSD sind inkonsistent, wenn das Feld Status im Container EF.StatusVD ‚1’ ist und konsistent, wenn das Feld Status im Container EF.StatusVD ‚0’ ist. Wenn der Lesevorgang mit dem Lesen des VSD Status Containers beginnt, wird das Clientsystem mittels des TUC_KON_256 „Systemereignis absetzen” durch VSDM/PROGRESS/READVSD (siehe Tabelle 19) Ereignis über den Anfang des Lesevorgangs informiert.
PD und VD von eGK lesen	Das Fachmodul liest über den TUC_KON_202 „LeseDatei” den PD-Datensatz aus EF.PD und den VD-Datensatz aus EF.VD Container (siehe [gemSpec_eGK_ObjSys]) der eGK aus. Die gezippten Daten von der Karte müssen unverändert übernommen werden. Beim Auslesen des VD-Datensatzes aus dem EF.VD Container müssen „Offset Start VD“- und „Offset Ende VD“-Elemente beachtet werden (siehe [gemSpec_eGK_Fach_VSDM], damit ausschließlich die VD (und nicht die GVD) gelesen werden.
GVD von eGK lesen	Das Fachmodul liest, wenn die Berechtigung zum Lesen der GVD vorliegt, über den TUC_KON_202 „LeseDatei” den GVD-Datensatz aus EF.GVD Container (siehe [gemSpec_eGK_ObjSys]) der eGK aus. Die gezippten Daten von der Karte müssen unverändert übernommen werden.
Daten zu Protokollierungsliste hinzufügen	Es wird vom Fachmodul ein Protokolleintrag erstellt. Die benötigten Daten (Identität der Leistungserbringerkarte) werden über den TUC_KON_034 „Zertifikatsinformationen extrahieren” aus dem subjectDN des AUT-Zertifikats der für die Card to Card verwendeten SM-B bzw. des HBAs ermittelt. Weiter Details zum Inhalt der Protokolleinträge ist im Kapitel 4.2 aufgeführt.
Prüfungsnachweis lesen	Muss der Prüfungsnachweis von der eGK (EF.Prüfungsnachweis Container - siehe [gemSpec_eGK_ObjSys]) gelesen werden, erfolgt dies über den TUC_KON_202 „LeseDatei”. Weitere Details bzgl. des Lesens und Entschlüsseln des Prüfungsnachweises sind im Kapitel 4.1 aufgeführt.
Protokollierungsliste auf eGK schreiben	Durch das Aufrufen des TUC_KON_006 „Datenzugriffsaudit eGK schreiben” werden die entsprechen Protokolleinträge auf die eGK geschrieben. Weitere Details zum Inhalt der Protokolleinträge ist im Kapitel 4.2 aufgeführt.
Prüfungsnachweis schreiben	Der Prüfungsnachweis wird symmetrisch verschlüsselt (Details über den Schlüssel und die verwendeten Algorithmen sind im Kapitel 4.1.3 beschrieben). Dafür wird der TUC_KON_072 „Daten symmetrisch verschlüsseln” verwendet. Der verschlüsselte Prüfungsnachweis wird über TUC_KON_203 „SchreibeDatei” in EF.Prüfungsnachweis Container der eGK geschrieben. Parallel dazu wird bereits die Antwort mit PD, VD, GVD und den Prüfungsnachweis an den Aufrufer zurückgegeben.
Reservierung der eGK aufheben	Nach Abschluss der letzten Aktivität ist die Reservierung der eGK aufzuheben. Dafür wird der TUC_KON_023 “Karte reservieren” mit den Eingangsparametern CardSession eGK und DoLock = Nein verwendet. Tritt im Verlauf der Abarbeitung der Operation ReadVSD ein Fehler auf, der zum Abbruch der Operation führt, dann muss die Reservierung der Karte ebenfalls aufgehoben werden.

3.2.2 Operation ReadKVK

Das Fachmodul VSDM realisiert die Schnittstelle I_KVKService mit der Operation ReadKVK. Diese Operation dient der Initiierung des Anwendungsfalls „Versichertendaten von KVK lesen“.

3.2.2.1 Verhalten der Operation

Die Versichertendaten werden vom Fachmodul von der KVK gelesen und geprüft. Bislang wurde die Prüfung der Kartendaten der KVK von multifunktionalen oder eHealth-BCS Kartenterminals vorgenommen. Das neu spezifizierte eHealth-Kartenterminal hingegen soll keine fachlich motivierten Prüfungen implementieren, so dass dieser Vorgang vom Fachmodul VSDM vorgenommen werden muss.

Das Fachmodul VSDM muss die Prüfungen gemäß den Vorgaben in [KVK-Spec] durchführen (siehe auch Anhang E). Wenn die Prüfsumme falsch ist oder die Daten nicht den Vorgaben in [KVK-Spec] entsprechen, muss der Anwendungsfall mit einer Fehlermeldung ohne weitere Verarbeitung der Daten abgebrochen werden. Nach der erfolgreichen Prüfung der Kartendaten der KVK werden die Daten im ASN.1 Format in die Antwortnachricht für den Aufrufer übernommen. [VSDM-A_2611] [VSDM-A_2609]

Zusätzlich muss geprüft werden, ob das Gültigkeitsdatum der Karte überschritten ist. Wenn das Gültigkeitsdatum der KVK abgelaufen ist, soll die Warnmeldung „Das Gültigkeitsdatum der Karte ist überschritten“ auf dem Display des Kartenterminals mittels TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ angezeigt werden. Die Daten der KVK werden in die Antwortnachricht übernommen. [VSDM-A_2626]

3.2.2.2 Ablauf (informativ)

Wie am Anfang dieses Kapitels beschrieben, ist die Ablauflogik der Operation in [gemSysL_VSDM] vorgegeben. Die Aktivitäten der Ablauflogik werden in Tabelle Tab_FM_VSDM_16 mit den Aufrufen von entsprechenden TUCs und im Aktivitätsdiagramm in Anhang C3 informativ dargestellt.

Tabelle 5: Tab_FM_VSDM_16 – ReadKVK: Für Aktivitäten verwendete TUCs

Aktivität	Kurzbeschreibung	Aufgerufene TUCs
Aufrufkontext prüfen	Der TUC_KON_000 „Prüfe Zugriffsberechtigung“ wird aufgerufen um sicherzustellen, dass die Karte im gegebenen Kontext verwendet werden dürfen. Der TUC muss mit den Eingangsparametern aufgerufen werden, die den Parametern der ReadKVK-Schnittstelle des Fachmoduls entsprechen: mandantId, clientSystemId, workplaceId, KVKHandle (siehe [gemSpec_SST_PS_VSDM]). ctId, needCardSession, allWorkplaces Parameter des TUCs bleiben nicht befüllt.
Versichertendaten von KVK lesen	Der TUC_KON_026 „Liefere CardSession” wird verwendet, um die CardSession von der KVK zu erhalten. Mittels TUC_KON_202 „LeseDatei” werden die Versichertendaten von der KVK gelesen. Zusätzlich wird geprüft, ob das Gültigkeitsdatum der Karte überschritten ist. Falls ja, soll die Warnmeldung „Das Gültigkeitsdatum der Karte ist überschritten“ auf dem Display des Kartenterminals, in das die KVK eingesteckt wird, mittels TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ angezeigt werden
Versichertendaten prüfen	Das Fachmodul prüft die Vorgaben gemäß [KVK-Spec].

3.3 Operation AutoUpdateVSD

Das Fachmodul VSDM realisiert die Schnittstelle I_Notification mit der Operation AutoUpdateVSD. Diese Operation dient zur Ausführung des Anwendungsfalls „Automatische Onlineprüfung VSD“. Der Konnektor stößt diese Operation mittels des Ereignisdiensts an, wenn eine eGK im Standalone-Szenario gesteckt wird, s. Kap. 4.5 für Details. [VSDM-A_2612]

3.3.1 Verhalten der Operation

Die Operation prüft, ob Aktualisierungsaufträge für die eGK vorliegen und führt diese gegebenenfalls durch. Die Information, ob eine VSD-Aktualisierung erfolgreich durchgeführt wurde, wird anhand des Prüfungsnachweises auf der eGK zur späteren Verwendung gespeichert. Der Aufbau und Inhalt des Prüfungsnachweises ist in Kapitel 4.1 näher erläutert. Ist die Gesundheitsanwendung der eGK gesperrt oder das AUT-Zertifikat der eGK offline ungültig, wird kein Prüfungsnachweis auf die eGK geschrieben. [VSDM-A_2614] [VSDM-A_2615] [VSDM-A_2619] [VSDM-A_2620]

Um den Prüfungsnachweis sowie die Protokolleinträge auf die eGK schreiben zu können und um die Echtheit der beteiligen Karten zu verifizieren, muss die eGK vorher mittels C2C (einseitige oder gegenseitige Authentisierung) freigeschaltet werden. Eine einseitige statt gegenseitige Authentisierung der HBA bzw. des SM-Bs muss durchgeführt werden, wenn vorher durch eine erfolgreiche Aktualisierung bereits die Echtheit der eGK nachgewiesen ist. [VSDM-A_2621] [VSDM-A_2622]

Für eine durchgeführte VSD Aktualisierung muss ein Protokolleintrag gemäß 4.2 auf der eGK erstellt werden. [VSDM-A_2623]

Wenn die Operation durchlaufen wurde, muss ein zum Resultat des Anwendungsfalls passender Ergebnistext gemäß Tabelle Tab_FM_VSDM_07 am Kartenterminal mittels des TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ angezeigt werden. Der Ergebnistext muss nach einem fest definierten Zeitraum (z.B. 30 Sekunden) von der Anzeige des Kartenterminals gelöscht werden. Zusätzlich, muss das Fachmodul den Ergebnistext mit dem Ziehen der eGK aus dem Kartenterminal von der Anzeige löschen (z.B. durch das Abfangen von CARD/REMOVED Ereignis und dem Aufruf von TUC_KON_051).

Tabelle 6: Tab_FM_VSDM_07 – Ergebnistexte für AutoUpdateVSD [VSDM-A_2616]

3.3.2 Ablauf (informativ)

Wie am Anfang dieses Kapitels beschrieben, ist die Ablauflogik der Operation in [gemSysL_VSDM] vorgegeben. Die Aktivitäten der Ablauflogik werden in Tabelle Tab_FM_VSDM_17 mit den Aufrufen von entsprechenden TUCs und im Aktivitätsdiagramm in Anhang C2 informativ dargestellt.

Tabelle 7: Tab_FM_VSDM_17 – AutoUpdateVSD: Für Aktivitäten verwendete TUCs

Aktivität	Kurzbeschreibung	Aufgerufene TUCs
Aufrufkontext prüfen	Der TUC_KON_000 „Prüfe Zugriffsberechtigung“ wird zwei mal – ein mal für HBA bzw. SM-B und ein mal für eGK aufgerufen, um sicherzustellen, dass sowohl HBA bzw. SM-B als auch eGK im gegebenen Kontext verwendet werden dürfen. Der TUC muss mit den Eingangsparametern cardHandle = CardHandle zur jeweiligen Karte mandantId (für AutoUpdateVSD konfiguriert) workplaceId (für AutoUpdateVSD konfiguriert) clientSystemId (für AutoUpdateVSD konfiguriert) userId = „vsdmAutoUpdateUser“ (falls ein HBA verwendet wird) aufgerufen werden. ctId, needCardSession, allWorkplaces Parameter des TUCs bleiben nicht befüllt.
eGK reservieren	Der TUC_KON_026 „Liefere CardSession” wird verwendet, um die CardSession von der eGK zu erhalten. Der TUC_KON_023 “Karte reservieren” wird mit den Eingangsparametern CardSession eGK und DoLock = Ja verwendet, um die Karte zu reservieren.
Technische Nutz- barkeit und Gül- tigkeit der eGK prüfen	Der TUC_KON_018 „eGK-Sperrung prüfen” wird aufgerufen. Das Ergebnis der Operation ist Grundlage für die Steuerung des weiteren Ablaufs.
Echtheit der beteiligten Karten prüfen	Der TUC_KON_026 „Liefere CardSession” wird verwendet, um die CardSession von SM-B bzw. HBA zu erhalten. Der TUC_KON_022 „Liefere PIN-Status” für PIN.SMC bzw. PIN.CH prüft, ob SM-B bzw. HBA freigeschaltet sind. Falls nein, bricht das Fachmodul mit Fehlercode 3041 bzw. 3042 ab. In diesem Fall muss das Primärsystem die externe Schnittstelle des Konnektors VerifyPin für PIN.SMC bzw. PIN.CH aufrufen, um den Sicherheitszustand der entsprechenden Karte zu erhöhen (siehe [gemILF_PS] für weitere Details) und den AutoUpdateVSD Vorgang wiederholen. Der TUC_KON_005 „Card-to-Card authentisieren“ wird für eine gegenseitige Echtheitsprüfung von eGK und SM-B/HBA aufgerufen. Wird während der Echtheitsprüfung ein Aktualisierungsauftrag ermittelt, wird die Echtheitsprüfung mittels des TUC_KON_024 „Karte zurücksetzen” abgebrochen.
Aktualisierungsaufträge ermitteln	Die SOAP-Operation für die Abfrage der Aktualisierungsaufträge ist in der Schnittstellenspezifikation Fachdienste [gemSpec_SST_FD_VSDM] beschrieben. Die für die Operation GetUpdateFlags erforderliche ICCSN wird über den TUC_KON_202 „LeseDatei” aus EF.GDO Container (siehe [gemSpec_eGK_ObjSys]) der eGK ermittelt. Die für die Fachdienstlokalisierung erforderliche ProviderID wird aus dem AUT-Zertifikat der eGK ausgelesen. Das Zertifikat wird von eGK über den TUC_KON_034 „Zertifikatsinformationen extrahieren” ermittelt. Weitere Details zur Fachdienstlokalisierung sind im Kap. 4.3.3 aufgeführt. Der Aufruf wird über die, mit Hilfe von TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen” aufgebaute, TLS-Verbindung verschickt. Die TLS-Verbindung wird mit beidseitiger Authentifizierung aufgebaut. Für die clientseitige Authentifizierung muss das durch den Konfigurationsparameter MANDANT_SMB definierte SM-B (siehe Kap. 4.8) verwendet werden. Der Aufbau der URL, die für die TLS-Verbindung erforderlich ist, wird im Kap. 4.3.3 beschrieben. Bevor der TUC_KON_110 aufgerufen wird, prüft das Fachmodul mit Hilfe von TUC_KON_022 „Liefere PIN-Status”, ob SM-B freigeschaltet ist. Falls nein (das kann passieren, wenn Card-to-Card-Authentisierung mit HBA durchgeführt wurde), bricht das Fachmodul mit Fehlercode 3041 ab. Weitere Details zum Ermitteln der Aktualisierungsaufträge und zur Durchführung der Aktualisierungen sind im Kapitel 4.3 aufgeführt.
Aktualisierungen durchführen	Für jeden ermittelten Aktualisierungsauftrag wird eine Aktualisierung durchgeführt. Die Werte für den Aufruf der PerformUpdates SOAP-Operation werden den Aktualisierungsaufträgen entnommen. Anschließend wird die Aktualisierung mittels der SOAP-Operation GetNextCommandPackage fortgeführt. Zum Senden der empfangenen Kartenbefehle wird der TUC_KON_200 „Sende APDU” verwendet. Weitere Details zum Ermitteln der Aktualisierungsaufträge und zur Durchführung der Aktualisierungen sind im Kapitel 4.3 aufgeführt. Nachdem die CMS-Aktualisierungen durchgeführt wurden, muss geprüft werden, ob die eGK durch die Aktualisierung gesperrt bzw. die bestehende Sperrung aufgehoben ist. Dafür kann einer der Gesundheitsanwendung zugehörigen Container (z.B. EF.PD) mit Hilfe von TUC_KON_202 „LeseDatei” gelesen werden. Falls die eGK gesperrt bzw. die bestehende Sperrung nicht aufgehoben ist, wird der TUC mit einer Fehler abbrechen und somit wird der Vorgang mit Fehler 114 („Gesundheitsanwendung auf eGK gesperrt“) abgebrochen.
Echtheit der beteiligten Karten prüfen	Nach einer erfolgreichen Aktualisierung der eGK muss diese für das Schreiben des Protokolleintrags freigeschaltet werden und das Fachmodul eine Echtheitsprüfung des SM-Bs bzw. der HBA mittels des TUC_KON_005 „Card-to-Card authentisieren“ ausführen. Durch eine erfolgreiche Aktualisierung wird die Echtheit der eGK nachgewiesen und daher soll lediglich eine einseitige Authentisierung des SM-Bs bzw. der HBA durchgeführt werden.
Protokollierungs- liste auf eGK schreiben	Es wird vom Fachmodul ein Protokolleintrag erstellt. Die benötigten Daten (Identität der Leistungserbringerkarte) werden über den TUC_KON_034 „Zertifikatsinformationen extrahieren” aus dem subjectDN des AUT-Zertifikats der für die Card to Card verwendeten SM-B bzw. des HBAs ermittelt. Durch das Aufrufen des TUC_KON_006 „Datenzugriffsaudit eGK schreiben” werden die entsprechen Protokolleinträge auf die eGK geschrieben. Weitere Details zum Inhalt der Protokolleinträge ist im Kap. 4.2 aufgeführt.
Prüfungsnachweis erzeugen	Die Erzeugung des Prüfungsnachweises erfolgt nur im Fachmodul. Es müssen keine TUCs aufgerufen werden. Der Aufbau und Inhalt des Prüfungsnachweises ist in Kap. 4.1 beschrieben.
Prüfungsnachweis schreiben	Der Prüfungsnachweis wird symmetrisch verschlüsselt (Details über den Schlüssel und die verwendeten Algorithmen sind im Kapitel 4.1.3 beschrieben). Der verschlüsselte Prüfungsnachweis wird über TUC_KON_203 „SchreibeDatei” in EF.Prüfungsnachweis Container (siehe [gemSpec_eGK_ObjSys]) der eGK geschrieben.
Ergebnis am Kar- tenterminal anzei- gen	Das Ergebnis des Ablaufs wird gemäß Tab_FM_VSDM_07 mittels TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ am Kartenterminal, in das die eGK eingesteckt wird, angezeigt.
Reservierung der eGK aufheben	Nach Abschluss der letzten Aktivität ist die Re-servierung der eGK aufzuheben. Dafür wird der TUC_KON_023 “Karte reservieren” mit den Eingangsparametern CardSession eGK und DoLock = Nein verwendet. Tritt im Verlauf der Abarbeitung der Operation AutoUpdateVSD ein Fehler auf, der zum Abbruch der Operation führt, dann muss die Reservierung der Karte ebenfalls aufgehoben werden.

3.4 Operation ReadVSDAdV

Das Fachmodul VSDM realisiert die logische Schnittstelle I_VSDAdVService mit der Operation ReadVSDAdV. Diese Operation dient der Initiierung des Anwendungsfalls „VSD von eGK in der AdV lesen“.

3.4.1 Verhalten der Operation

Die Operation ReadVSDAdV wird im Rahmen einer eGK-Sitzung in einer KTR-AdV aufgerufen. Als Teil der Initialisierung einer eGK-Sitzung in der AdV muss der Versicherte seine PIN eingeben. Somit kann für die Operation ReadVSDAdV als Vorbedingung angenommen werden, dass die Authentisierung des Versicherten mittels PIN.CH erfolgreich erfolgte.

Die Operation ReadVSDAdV liefert dem Aufrufer immer mindestens die persönlichen Versichertendaten (PD), die allgemeinen Versicherungsdaten (VD) und den Status-Container der angegebenen eGK zurück, sofern die Gesundheitsanwendung der eGK nicht gesperrt ist, das AUT-Zertifikat der eGK weder offline noch online ungültig ist, die Versichertenstammdaten konsistent sind und beim Auslesen der Daten kein technischer Fehler aufgetreten ist. [VSDM-A_3034] [VSDM-A_3035] [VSDM-A_3036] [VSDM-A_3037] [VSDM-A_3038]

Wenn als Ergebnis der Onlineprüfung ein Update vorliegt, dann muss vor der Ausführung der Aktualisierung das Sicherheitszustand der eGK zurückgesetzt werden. [A_15133]

Um die GVD von der eGK zu lesen und die Protokolleinträge auf die eGK schreiben zu können, muss die eGK vorher mittels C2C und PIN-Eingabe freigeschaltet sein. Wenn im Ablauf eine Aktualisierung durchgeführt wird, soll nach Abschluss der Aktualisierungen für die Freischaltung eine einseitige Authentisierung des SM-Bs durchgeführt werden und eine erneute Authentisierung des Versicherten mittels PIN.CH durchgeführt werden. Können die GVD aufgrund fehlender Berechtigungen nicht gelesen werden, werden trotzdem die PD und VD zurückgegeben. [VSDM-A_3039] [VSDM-A_3040] [VSDM-A_3041] [VSDM-A_3065]

Wenn der Status-Container nach der Ausführung von vorliegenden Aktualisierungen im Feld Status den Wert '1' enthält und damit auf inkonsistente Versichertenstammdaten hinweist, muss mit einer Fehlermeldung abgebrochen werden. Der Versicherte kann den Anwendungsfall erneut aufrufen, um eine evtl. nicht vollständig ausgeführte Aktualisierung zu wiederholen. Die Inhalte des Containers StatusVD müssen in die Datenstruktur der Antwortnachricht der Operation umgewandelt werden. Die Details sind in 4.4 beschrieben. [VSDM-A_3042]

Im Ablauf der Operation ReadVSDAdV wird kein Prüfungsnachweis erzeugt oder gelesen.

Wenn eine Verbindung zur TI besteht, muss die Ermittlung von Aktualisierungsaufträgen für die eGK und anschließende Durchführung immer erfolgen. Wird durch eine Aktualisierung die Gesundheitsanwendung gesperrt, dürfen die Versichertenstammdaten nicht gelesen werden. [VSDM-A_3043] [VSDM-A_3044] [VSDM-A_3045]

Für eine durchgeführte VSD-Aktualisierung und für das Lesen der GVD muss je ein Protokolleintrag gemäß Kapitel 4.2 auf der eGK erstellt werden. [VSDM-A_3046] [VSDM-A_3047]

Die Versichertenstammdaten sind auf der eGK gzip-komprimiert innerhalb der Dateien abgelegt. Da die Rückgabe der Versichertenstammdaten über eine interne Schnittstelle erfolgt, muss das Fachmodul VSDM die Daten vor der Rückgabe nicht mittels Base64 kodieren. Der Aufrufer der Operation ReadVSDAdV erhält die Versichertenstammdaten dann in komprimierter Form.

3.4.2 Ablauf (informativ) für Umsetzung in KTR-AdV

Das Fachmodul VSDM nutzt für den Zugriff auf die eGK und den Verbindungsaufbau zu den Fachdiensten Plattformleistungen, welche durch die KTR-AdV als Ablaufumgebung des Fachmoduls VSDM bereitgestellt werden.

Die KTR-AdV besteht aus den Teilsystemen AdV-Server (Server) und AdV-App (Client). Die Umsetzung der Operation ReadVSDAdV hat clientseitige und serverseitige Anteile. Da die Datenverarbeitung lokal erfolgen muss, werden die Kartenzugriffe und die Verarbeitung der gelesenen Daten in der AdV-App umgesetzt. Der TSL-Verbindungsaufbau zu den Fachdiensten wird im AdV-Server umgesetzt, da dieser die Schnittstellen zu den zentralen Diensten der TI kapselt. Der fachmodulseitige Anteil der UFS und CCS Schnitt-stelle kann in der AdV-App oder im AdV-Server umgesetzt werden. Werden die Requests zur Abfrage der UFS und CCS Schnittstelle in der AdV-App erstellt, dann muss der AdV-Server die Validität der Requests prüfen. Die vom AdV-Server empfangenen Responses der Fachdienste werden unverändert an die AdV-App weitergeleitet und dort ausgewertet.

Die Plattformleistung PL_TUC_CARD_INFORMATION ermittelt Statusinformationen zu einer angebundenen Smartcard und stellt diese Informationen anderen Systemprozessen für die Dauer der Verbindung zur Smartcard zur Verfügung. PL_TUC_CARD_INFORMATION wird beim Verbindungsaufbau zur eGK (Initialisierung des CardProxies mit Zugriff auf die eGK) ausgeführt. Damit stehen die Statusinformationen zur eGK der Operation ReadVSDAdV für die Steuerung des Ablaufs zur Verfügung.

Aktivitäten, welche zum Erlangen der Berechtigung zum Zugriff auf die Objekte der eGK dienen, z.B. Verifikation der PIN oder Card-2-Card mit einer SM-B, werden nicht durch das Fachmodul umgesetzt. Sie werden, falls notwendig, durch Plattformleistungen initiiert.

Die Ablauflogik der Operation ist im „Systemspezifischen Konzept Versichertenstammdatenmanagement“ [gemSysL_VSDM] vorgegeben. Die Aktivitäten der Ablauflogik werden in Tabelle Tab_FM_VSDM_28 mit den Aufrufen von entsprechenden Plattformleistungen der KTR-AdV informativ dargestellt.

Tabelle 8: Tab_FM_VSDM_28 – ReadVSDAdV: Für Aktivitäten verwendete Plattformleistungen

3.5 Verwendete Schnittstellen der Fachdienste

Die Schnittstellen zu den UFS-, VSDD- und CMS-Fachdiensten zum Ermitteln der Aktualisierungsaufträge und zum Durchführen der Aktualisierungen ist in [gemSpec_SST_FD_VSDM] definiert.

3.6 Verwendete Technical Use-Cases des Konnektor

Das Fachmodul verwendet die in der Tabelle Tab_FM_VSDM_24 dargestellten Technical Use Cases (TUCs) des Konnektors.

Tabelle 9: Tab_FM_VSDM_24 – Verwendete TUCs des Konnektors

(*) In Phase 1 der Umsetzung des Konnektors ist der Use Case im Fachmodul entsprechend der Beschreibung aus [gemSpec_Kon] zu implementieren.

3.7 Verwendete Plattformleistungen in der KTR-AdV

Das Fachmodul verwendet die in der Tabelle Tab_FM_VSDM_29 dargestellten Plattformleistungen der KTR-AdV.

Tabelle 10: Tab_FM_VSDM_29 – Verwendete Plattformleistungen in der KTR-AdV

4 Funktionale Ergänzungen

4.1 Prüfungsnachweis

Der Prüfungsnachweis dient als Nachweis über die Durchführung der Prüfung auf Gültigkeit, Prüfung der Aktualität der Daten und Aktualisieren der Daten auf der eGK für die Abrechnungsdaten nach § 295 SGB V.

Der gesetzlichen Forderung, die Onlineprüfung und -aktualisierung durch Fachdienste der Kostenträger auch dann durchführen zu können, wenn das Primärsystem nicht an das Netz der Telematikinfrastruktur angebunden ist, wird durch die Umsetzung des Standalone-Szenarios Rechnung getragen. Die eGK dient bei Nutzung des Standalone-Szenarios als Transportmedium zur Übergabe des Prüfungsnachweises vom Online-Fachmodul zum Offline-Fachmodul, welches Bestandteil des Konnektor im Praxisnetz ist.

Da das Schreiben des Prüfungsnachweises auf einer eGK bzw. das Lesen des Prüfungsnachweises von einer eGK nur seitens des Fachmoduls VSDM durchgeführt wird, wird die Speicherstruktur des entsprechenden eGK Containers in diesem Dokument beschrieben. Die Speicherstrukturen von anderen VSDM-spezifischen Containern der eGK (EF.PD, EF.VD, EF.GVD, ED.StatusVD) werden in [gemSpec_eGK_Fach_VSDM] beschrieben.

Im Rahmen einer eGK-Sitzung in der KTR-AdV wird kein Prüfungsnachweis erzeugt und auf die eGK geschrieben.

4.1.1 Speicherstruktur auf der eGK

Der Prüfungsnachweis wird auf der eGK in den MF/DF.HCA/EF.Prüfungsnachweis-Container gespeichert. Die Beschreibung der Speicherstruktur des Containers erfolgt in [gemSpec_eGK_Fach_VSDM], Tabelle Tab_eGK_Fach_VSDM_06. [VSDM-A_2989]

4.1.2 Prüfungsnachweis erzeugen

Das Fachmodul muss den Prüfungsnachweis entsprechend dem Infomodell aus [gemSysL_VSDM] erzeugen und mit den in Tabelle Tab_FM_VSDM_04 aufgezählten Feldern und dem zutreffenden Ergebnis aus Tab_FM_VSDM_05-01 befüllen.

Wurde eine VSD-Aktualisierung durchgeführt, kann nach erfolgreicher Verarbeitung der letzten Kartenbefehle vom Fachdienst (s. das Attribut „LastIfOK“ in [gemSpec_SST_FD_VSDM]) der Ablauf fortgesetzt werden. Dennoch muss eine abschließende Nachricht an den Fachdienst geschickt werden, damit dieser für die erfolgreiche Aktualisierung mit der Prüfziffer antworten kann. Da die Prüfziffer Teil des Prüfungsnachweises ist, muss für die Erzeugung des Prüfungsnachweises auf die letzte Antwortnachricht gewartet werden, sofern eine VSD-Aktualisierung vorlag.

Tabelle 11: Tab_FM_VSDM_04 – Werte für Prüfungsnachweis [VSDM-A_2588] [VSDM-A_2653]

Tabelle 12: Tab_FM_VSDM_05-01 – Zuordnung der Ergebnisse der Aktivitäten zu Werten des Elements „Ergebnis des Prüfungsnachweises“ [VSDM-A_2578] [VSDM-A_2589] [VSDM-A_2614] [VSDM-A_3033]

Damit der Prüfungsnachweis inkl. Integritätsschutz in den 300 Bytes langen Container EF.Prüfungsnachweis geschrieben werden kann, muss das Fachmodul sicherstellen, dass der Prüfungsnachweis nach der Komprimierung maximal 270 Byte lang ist. Das Fachmodul muss bei der Erzeugung der Prüfungsnachweises den Default-Namespace verwenden, den Namespace nur einmal hinzufügen, die schemaLocation nicht aufnehmen und Whitespaces zwischen einzelnen Elementen des Prüfungsnachweis entfernen. [VSDM-A_2770]

Nach dem Erzeugen des Prüfungsnachweises schreibt das Fachmodul einen Eintrag im Ablaufprotokoll. Dieser Eintrag dokumentiert das Ergebnis des Prüfungsnachweises und ggf. den ErrorCode. [VSDM-A_3067]

Wenn die Operation ReadVSD einen Prüfungsnachweis mit Code 1 oder 2 zurück liefert, wird damit angezeigt, dass die übermittelten VSD aktuell sind. Wenn die Operation ReadVSD mit Fehler 114, 106 oder 107 beendet wird, ist diese eGK ungültig und stellt keinen Versicherungsnachweis dar. Bei den Prüfungsnachweisen mit den Codes 3, 4, 5 und 6 wird keine Aussage über die Gültigkeit der zurückgemeldeten VSD gemacht, weil im Prozess Fehler passiert sind.  Wenn eine eGK ungültig ist, dürfen keine VSD und kein Prüfungsnachweis an das Primärsystem gemeldet werden. [A_23020], [A_23157], [A_23158].

4.1.3 Prüfungsnachweis schreiben

Der Prüfungsnachweis muss vor dem Schreiben auf die eGK komprimiert und verschlüsselt werden, auch im Online-Szenario. Ein evtl. bestehender Prüfungsnachweis muss immer ungeprüft überschrieben werden. [VSDM-A_2655] [VSDM-A_2590]

Für die Ver- und Entschlüsselung muss der in der Konfiguration für den Mandanten hinterlegte Schlüssel VSDM-PNW-Key genutzt werden (vgl. 4.1.4). Das Fachmodul verschlüsselt den komprimierten Prüfungsnachweis mit dem Schlüssel VSDM-PNW-Key. Als Algorithmus muss AES im Galois/Counter Mode gemäß [gemSpec_Krypt#GS_5016] genutzt werden. Dazu wird der TUC_KON_072 „Daten symmetrisch verschlüsseln” ^{(In Phase 1 der Umsetzung des Konnektors ist der Use Case im Fachmodul entsprechend der Beschreibung aus [gemSpec_Kon] zu implementieren.)} [gemSpec_Kon] genutzt. Der TUC erzeugt ein max. 270 Byte langes Chiffrat und einen 16 Byte (= 128-Bit) langen Authentication-Tag. Beide werden zusammen in EF.Prüfungsnachweis geschrieben. [VSDM-A_2591]