Elektronische Gesundheitskarte und Telematikinfrastruktur

Systemspezifisches Konzept
Versichertenstammdatenmanagement (VSDM)

    

     

      
Version
      
2.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
19.02.21
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSysL_VSDM
     
    

Dokumenteninformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument “Systemspezifisches Konzept VSDM“ beschreibt die Fachanwendung VSDM auf Systemebene im Kontext des Online-Produktivbetrieb (Stufe 1) und bildet den Rahmen für die weiterführenden Konzepte und Spezifikationen des Projektes VSDM.

Darüber hinaus erfolgt eine Zerlegung der Fachanwendung VSDM in die zugehörigen Produkttypen und die Schnittstellen zwischen den einzelnen Produkttypen werden spezifiziert.

Die Abbildung 1 zeigt schematisch die Dokumentenhierarchie im Projekt VSDM, in welcher das systemspezifische Konzept VSDM und die Konzepte sowie die 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

Kapitel 2 gibt einen Überblick über das System VSDM als Ganzes. Dabei werden die übergreifenden Anforderungen an die Fachanwendung VSDM dargestellt sowie eine Übersicht über die notwendigen Komponenten und deren Schnittstellen gegeben. Darüber hinaus wird ein Überblick über das Infomodell, das Berechtigungsmodell und die Anwendungsfälle des VSDM gegeben.

In Kapitel 3 erfolgt eine detaillierte Beschreibung der Anwendungsfälle, die zur Erfüllung der fachlich-funktionalen Anforderungen identifiziert wurden. Die Anwendungsfälle werden in Form von Aktivitäts- und Sequenzdiagrammen modelliert und es werden die zugehörigen funktionalen und nicht-funktionalen Anforderungen zu den Modellen beschrieben.

Die externen Schnittstellen der Fachanwendung VSDM werden in Kapitel 4 dargestellt. Dazu gehören die Schnittstellen zum Primärsystem, die Schnittstellen zu den Fachdiensten der Kostenträger (UFS, VSDD, CMS) und die benötigten Schnittstellen zur TI-Plattform.

Kapitel 5 beinhaltet die Systemzerlegung der Fachanwendung VSDM in die zugehörigen Produkttypen. Die Fachanwendung VSDM gliedert sich dabei in die Produkttypen Fachmodul VSDM, Intermediär und die Fachdienste UFS, VSDD und CMS. Daneben ist die Systemzerlegung für das mobile Einsatzszenario beschrieben.

Das Kapitel 6 enthält das technische Informationsmodell des VSDM mit den Infomodellen zum Prüfungsnachweis und zu den Versichertendaten.

Das Kapitel 7 listet informativ organisatorische Anforderungen auf, welche sich an Partner der Selbstverwaltung außerhalb des Projektes richten.

Die Ausgangsanforderungen des systemspezifischen Konzeptes und deren Zusammenhang zu den Anforderungen aus dem Lastenheft werden tabellarisch in Anhang B dargestellt. Anhang C enthält eine Darstellung der aus dem technischen Infomodell abgeleiteten XML-Schemas. Im Anhang D werden Varianten des Anwendungsfalls „VSD von eGK lesen“ erläuternd dargestellt, um die Verständlichkeit der verschiedenen Abläufe zu erhöhen.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von VSDM-Fachdiensten.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung im 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 Abgrenzung des Dokuments

Innerhalb dieses Dokuments wird auf die technische Umsetzung des Versichertenstammdatenmanagements eingegangen. Prozesse der Kostenträger und Leistungserbringer (z. B. Kartenherausgabe) sind nicht Bestandteil des systemspezifischen Konzeptes.

Für die Sichten „Datenschutz“ und „Datensicherheit“ werden jeweils eigene systemspezifische Konzepte für die Fachanwendung VSDM erstellt. Für die Sichten „Betrieb“ und „Test“ sowie für den Implementierungsleitfaden für die Primärsysteme wird jeweils ein gemeinsames Konzept mit dem Projekt Basis-TI (Stufe1) für den Online-Produktivbetrieb (Stufe 1) ausgearbeitet.

1.5 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 des systemspezifischen Konzepts 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 B1 dieses Dokuments werden in der Tabelle 48 die Lastenheftanforderungen aufgelistet, die in diesem Ergebnisdokument berücksichtigt sind. In der Spalte "umgesetzt durch" befinden sich die eindeutigen Referenzen auf die dazu erarbeiteten Umsetzungsanforderungen. In Anhang B2, Tabelle 49 stehen die Umsetzungsanforderungen mit ihrer Beschreibung 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.

Die Darstellung der Facharchitektur erfolgt prinzipiell auf der Grundlage einer durchgängigen UML-Modellierung.

2 Systemüberblick

2.1 Übergreifende Anforderungen

Nachfolgend werden die Anforderungen der Fachanwendung VSDM beschrieben, die übergreifend zu betrachten sind und sich nicht auf einzelne Prozesse, Anwendungsfälle oder Komponenten beziehen. Die spezifischen Anforderungen an die Anwendungsfälle werden in Kapitel 3 "Anwendungsfälle" und die spezifischen Anforderungen an die Produkttypen in Kapitel 5 "Systemzerlegung (Deployment)" ausgearbeitet.

Der Schutzbedarf der verarbeiteten Informationsobjekte der Anwendung VSDM wird durch die Sicherheitsanalysegegenstände (Komponenten, Dienste, Schnittstellen) sichergestellt, die diese Informationsobjekte verarbeiten. [VSDM-A_2177]

Alle Anwendungsfälle der Anwendung VSDM müssen im Ablauf mögliche Parallelisierungen vorsehen, um die Gesamtlaufzeiten der Anwendungsfälle zu optimieren. Grundlage für die Bewertung, welche Aktivitäten technisch parallelisiert werden können, ist das Dokument „Konzept Performanceuntersuchung VSDM“ [gemKPT_Perf_VSDM]. [VSDM-A_2141]

Kann eine Aktivität oder der ganze Anwendungsfall nicht durchgeführt werden bzw. wird eine Aktivität vorzeitig beendet, muss eine eindeutige, unverwechselbare Systemmeldung erzeugt werden. Diese Systemmeldung muss für alle nachnutzenden Systeme interpretierbar sein. Der Aufbau der Systemmeldung wird durch das übergeordnete Konzept zum einheitlichen Fehlermanagement bestimmt und die jeweiligen Inhalte durch die nachfolgenden Spezifikationen definiert. Der genaue Aufbau der Systemmeldungen kann erst festgelegt werden, wenn die Vorgaben des Projektes Basis-TI Stufe 1 bzgl. einheitlicher Struktur, Erzeugung und Verarbeitung von Fehlermeldungen [BasisTI-L_129] vorliegen. Inhaltlich werden die Systemmeldungen in der Konzeptionsphase an den Schnittstellen definiert. [VSDM-A_2142]

Erfolgt innerhalb einer Aktivität des Fachmoduls ein Operationsaufruf an einer Schnittstelle der TI-Plattform, darf die Ausführungszeit dieser Operation eine bestimmte zeitliche Dauer nicht überschreiten. Diese Zeitbegrenzung muss für das Fachmodul konfigurierbar sein. Dauert die Ausführung einer Operation länger als diese Zeit, muss die Aktivität kontrolliert beendet werden. [VSDM-A_2143]

2.2 Komponentenmodell Fachanwendung VSDM

In Abbildung 2 ist das Komponentendiagramm mit allen für die Anwendung VSDM relevanten Komponenten und Schnittstellen dargestellt. Das Clientsystem und die TI-Plattform sind für einen vollständigen Überblick aufgeführt, liegen aber nicht im Verantwortungsbereich des Projektes VSDM. Eine Beschreibung der Schnittstellen erfolgt in Kapitel 4 „Externe Schnittstellen“.

Die TI-Plattform ist entsprechend dem Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP] als „Black Box“ mit ihren Außenschnittstellen visualisiert. Dargestellt sind nur diejenigen Außenschnittstellen, die im Rahmen der Anwendung VSDM genutzt werden.

Die Architektur der Fachanwendung VSDM erlaubt die zukünftige Erweiterung um neue Funktionalitäten (z.B. Aufruf zusätzlicher Fachdienste der Kostenträger), indem die bestehenden Schnittstellen im Komponentenmodell erweitert oder neue Schnittstellen zu den Komponenten hinzugefügt werden.

Als Komponente der Fachdienste ist nur die Komponente „Fachdienst-Schnittstelle VSDM“ aufgeführt, da die weiteren Bestandteile der Fachdienste nicht im Verantwortungsbereich des Projektes VSDM liegen und deshalb auch nicht durch dieses definiert werden können.

Unter der Komponente Clientsystem sind die Clientsysteme der Leistungserbringer (PVS, AVS, KIS) und Kostenträger subsumiert.

Die Komponenten werden in Kapitel 5 den Produkttypen der Fachanwendung VSDM zugeordnet.

Abbildung 2 – Komponentendiagramm "Übersicht Komponenten VSDM" [VSDM-A_2001]

2.3 Überblick Informationsmodell

Die Informationsmodelle des systemspezifischen Konzepts VSDM leiten sich aus dem fachlichen Informationsmodell des Lastenheftes VSDM ab (Übersicht siehe Abbildung 3). Die Überführung dieses Informationsmodells in technische Informationsmodelle und deren Aufteilung in Teilmodelle wird in Kapitel 6 beschrieben.

Abbildung 3 – Übersicht Informationsmodelle VSD

2.4 Akteure und Berechtigungen

Ein Akteur beschreibt eine Rolle, die ein Anwender oder irgendein anderes System bei der Interaktion mit einem System einnimmt. Im herkömmlichen Sprachgebrauch sind Akteure handelnde Personen; sie wirken in verschiedenen Rollen an der Durchführung von Aktivitäten mit. In UML werden Akteure als Benutzer eines Systems definiert, die sich außerhalb des Systems befinden. Ein Akteur kann auch ein weiteres System sein. Ein Akteur ist an Interaktionen beteiligt, die in einem Anwendungsfall beschrieben sind [UML 2.0 projektorientiert].

So ist beispielsweise ein „Clientsystem“ ein Akteur, der die Fachanwendung VSDM benutzt und aktiv am Anwendungsfall „VSD von eGK lesen“ beteiligt ist.

Für jeden Anwendungsfall der Anwendung VSDM werden in Tabelle 1 die Berechtigungen der Akteure für die Durchführung des jeweiligen Anwendungsfalls bzw. einzelner Schritte innerhalb des Anwendungsfalls dokumentiert.

Tabelle 1: Tab_VSDM_SysL_28 – fachliche Berechtigungsmatrix VSDM [VSDM-A_2146]

Erläuterung:

2.5 Zusammenhang der Anwendungsfälle

Der Zusammenhang zwischen den Anwendungsprozessen des Lastenheftes VSDM und den Anwendungsfällen in der vorliegenden Systemlösung wird in Abbildung 4 dargestellt.

Abbildung 4 – Zusammenhang Anwendungsprozesse und Anwendungsfälle

Die Abbildung 5 zeigt die Übersicht der Systemanwendungsfälle (primäre Anwendungsfälle). Sie werden in Kapitel 3 verfeinert. Zusätzlich sind zu den oben gezeigten Anwendungsfällen die Anwendungsfälle zum Lesen der Versichertendaten von der KVK, zum Administrieren des Fachmoduls und Anwendungsfälle des mobilen Einsatzszenarios aufgeführt.

Der spezielle Anwendungsfall der „Logischen Trennung“ im Konnektor wird nicht separat behandelt. Er schränkt die Online-Fähigkeiten des Konnektors außerhalb von VSDM ein und stellt aus Sicht VSDM ein vollwertiges Online-Szenario dar.

Abbildung 5 – Übersicht der Anwendungsfälle VSDM

Bei den dargestellten Akteuren Konnektor, Clientsystem und mobiles Kartenterminal handelt es sich um Systeme, die im Kapitel 5 Systemzerlegung (Deployment) beschrieben sind. Bei dem Akteur „Admin einer Organisation des Gesundheitswesens“ handelt es sich um die Person, die das jeweilige dezentrale System betreut. Organisation des Gesundheitswesens umfasst in diesem Zusammenhang nicht nur medizinische Einrichtungen, sondern bezieht sich auch auf die Einrichtungen der Kostenträger.

3 Anwendungsfälle

In diesem Kapitel werden die für das Projekt VSDM relevanten Anwendungsfälle beschrieben.

In den Aktivitätsdiagrammen und den dazugehörigen tabellarischen Darstellungen werden alle relevanten fachlichen Aktivitäten modelliert. Jede aufgeführte Aktivität wird in Form eines separaten Sequenzdiagramms verfeinert dargestellt. Ergänzend können zusätzliche funktionale und nichtfunktionale Anforderungen pro Aktivität angegeben werden.

Im Anwendungsfalldiagramm (Abbildung 6) werden die Systemanwendungsfälle aus Abbildung 5, deren untergeordneten technischen Anwendungsfälle mit Stereotyp „secondary“ sowie deren Beziehungen untereinander dargestellt.

Die Beschreibung der verwendeten externen Schnittstelle erfolgt separat in Kapitel 4.

Abbildung 6 – Übersicht Use Cases VSDM

[VSDM-A_2000] [VSDM-A_2017] [VSDM-A_2018] [VSDM-A_2019] [VSDM-A_2100] [VSDM-A_2502] [VSDM-A_2515]

Abbildung 7 – Übersicht Use Cases VSDM in AdV [VSDM-A_3054]

3.1 Anwendungsfall VSDM-UC_01: VSD von eGK lesen

Aktivitätsdiagramm

Fortführung nächste Seite 

Abbildung 8 – Aktivitätsdiagramm: VSDM-UC_01 - VSD von eGK lesen [VSDM-A_2002] [VSDM-A_2005] [VSDM-A_2022] [VSDM-A_2023] [VSDM-A_2024] [VSDM-A_2025] [VSDM-A_2030] [VSDM-A_2031] [VSDM-A_2032] [VSDM-A_2028] [VSDM-A_2027] [VSDM-A_2029] [VSDM-A_2026]

Funktionale Ergänzungen zum Anwendungsfall

Die nachfolgende Tabelle führt zum Anwendungsfall normativ funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 2: Tab_VSDM_SysL_01 – VSD von eGK lesen [VSDM-A_2055]

Nichtfunktionale Anforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ Leistungsanforderungen auf, welche durch die Anwendung VSDM mindestens zu erfüllen sind. Der Zielwert stellt dabei den Wert dar, der unter optimalen Bedingungen erreichbar erscheint. Der "95% Grenzwert" stellt den Wert dar, der von 95% der ablaufenden Prozesse unterschritten werden soll. Im systemspezifischen Konzept Performanceuntersuchung (VSDM) [gemKPT_Perf_VSDM] ist das Performancemodell beschrieben, aus dem die Werte hergeleitet werden. Dabei wurden die Werte beim Zielwert auf volle Sekunden abgerundet und beim 95% Grenzwert auf volle Sekunden aufgerundet.

Tabelle 3: Tab_VSDM_SysL_02 – Leistungsanforderungen Anwendungsfall “VSD von eGK lesen“ [VSDM-A_2056]

Datenschutz- und Sicherheitsanforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 4: Tab_VSDM_SysL_03 – Schutzbedarfe im Anwendungsfall “VSD von eGK lesen“ [VSDM-A_2057]

3.1.1 Aktivität VSDM-UC_12: Technische Nutzbarkeit und Gültigkeit der eGK prüfen

Abbildung 9 – SD: Technische Nutzbarkeit und Gültigkeit der eGK prüfen [VSDM-A_2006]

Funktionale Ergänzungen

Die Operation verify_eGK der TI-Plattform kapselt die Funktionalität der beiden Prozessschritte „Prüfung der eGK anhand der Kriterien der technischen Nutzbarkeit“ und „Onlineprüfung der Gültigkeit der eGK“ aus dem Lastenheft VSDM. Daraus ergibt sich die Anforderung, dass der Ergebniswert VerificationResult mindestens die in Tabelle Tab_VSDM_SysL_34 genannten Werte enthält.

Tabelle 5: Tab_VSDM_SysL_34 – Ergebniswerte von VSDM-UC_12 [VSDM-A_2145]

3.1.2 Aktivität VSDM-UC_11: Echtheit der beteiligten Karten prüfen

Abbildung 10 – SD: Echtheit der beteiligten Karten prüfen [VSDM-A_2042]

Funktionale Ergänzungen

Die Operation do_C2C der TI-Plattform unterstützt sowohl gegenseitige als auch einseitige Authentisierung. Dies muss je nach aktuellem Zustand im Ablauf des Anwendungsfalls durch das Fachmodul gesteuert werden. Eine gegenseitige Authentisierung ist nur notwendig, wenn das Fachmodul vorher noch nicht die Echtheit der eGK feststellen konnte. Die Echtheit der eGK kann im Ablauf des Anwendungsfalls durch eine vorherige erfolgreiche Aktualisierung der Karte verifiziert werden. Dies bedeutet, wenn eine vorherige erfolgreiche Aktualisierung der eGK stattgefunden hat, wird bei dem folgenden Aufruf der Operation do_C2C vom Fachmodul nur eine einseitige Authentisierung der SMC-B bzw. HBA gefordert. [VSDM-A_2147] [VSDM-A_2148]

3.1.3 Aktivität VSDM-UC_04: Aktualisierungsaufträge ermitteln

Abbildung 11 – SD: Aktualisierungsaufträge ermitteln [VSDM-A_2035]

Funktionale Ergänzungen

Der über die I_TLS_Client Schnittstelle gesendete Request und die empfangene Response entsprechen der in Kapitel 4.2 „Schnittstellen der Fachdienste zum Fachmodul“ beschriebenen Operation GetUpdateFlags.

3.1.4 Aktivität VSDM-UC_05: Aktualisierungen durchführen

Abbildung 12 – SD: Aktualisierungen durchführen [VSDM-A_2036]

Funktionale Ergänzungen

Die über die I_TLS_Client Schnittstelle gesendeten Requests und die empfangenen Responses entsprechen den in Kapitel 4.2 „Schnittstellen der Fachdienste zum Fachmodul“ beschriebenen Operationen PerformUpdates und GetNextCommandPackage. Entsprechend der Beschreibung der Schnittstelle wird für die Aktualisierung der Karte ein Trusted Channel zwischen der eGK und dem Fachdienst aufgebaut. Für den Aufbau ist der Austausch mehrerer Nachrichten notwendig (s. „loop while Update not closed and flag LastIfOK not set“). Erst nach erfolgreichem Aufbau des Trusted Channels werden die aktualisierten Daten auf die eGK geschrieben. [VSDM-A_2157] [VSDM-A_2184]

Die technische Nutzbarkeit der eGK muss erneut geprüft werden, wenn der ServiceType (s. Kapitel 4.2.2) des zuvor begonnenen Aktualisierungsauftrags den Wert “CMS“ besitzt, da die Gesundheitsanwendung der eGK durch eine CMS-Aktualisierung ge- oder entsperrt werden kann. Dieser Prüfungsschritt muss die Werte der in Tabelle 5 genannten Attribute für die folgenden Aktivitäten aktualisieren.

3.1.5 Aktivität VSDM-UC_06: Prüfungsnachweis erzeugen

Abbildung 13 – SD: Prüfungsnachweis erzeugen [VSDM-A_2037]

Funktionale Ergänzungen

Das Fachmodul muss erkennen, wenn die Anbindung des Leistungserbringers an die Telematikinfrastruktur über den im Fachmodul konfigurierten Parameter „Maximale Offline-Zeit“ hinaus offline war. In diesem Fall muss ein Prüfungsnachweis mit entsprechendem Ergebnis erstellt werden. Die spezifischen Regelungen bezüglich der "Maximalen Offline-Zeit" müssen zwischen den Vertragspartnern vereinbart werden. [VSDM-A_2151].

Um den Zeitraum bestimmen zu können, in der die Anbindung des Leistungserbringers an die Telematikinfrastruktur offline war, muss das Fachmodul eine entsprechende Funktion besitzen. Diese Funktion bestimmt anhand der Events „Verbindung zur TI aufgebaut“ und „Verbindung zur TI abgebrochen“ des Notifikationsmechanismus der TI-Plattform, seit welchem Zeitpunkt die TI ununterbrochen nicht mehr zu erreichen war. [VSDM-A_2152]

Der Prüfungsnachweis enthält in dem Element Ergebnis das Ergebnis der Onlineprüfung und –aktualisierung. Der Wert dieses Elements ergibt sich aus den Ergebnissen der vorher durchgeführten Aktivitäten. Die Zuordnung des Werts ist in Tabelle 6 dargestellt.

Tabelle 6: Tab_VSDM_SysL_35 – Zuordnung der Ergebnisse der Aktivitäten zu Werten des Elements Ergebnis des Prüfungsnachweises [VSDM-A_2153]

Hinweis zu "Authentifizierungszertifikat der eGK nach Onlineprüfung nicht gültig":
Der Anwendungsfall verhält sich in einem Sonderfall unterschiedlich zwischen Standalone- und Online-Szenario. Dieser Sonderfall tritt ein, wenn das Zertifikat online gesperrt ist und die Gesundheitsanwendung auf der Karte nicht gesperrt ist. Im Online-Szenario erhält man eine Fehlermeldung und weder VSD noch einen Prüfungsnachweis. Im Standalone-Szenario hingegen wird der Prüfungsnachweis mit Ergebnis 4 geschrieben. Beim Lesen der VSD erhält das Primärsystem den die VSD und den Prüfungsnachweis von der eGK mit entsprechendem Ergebnis, weil das Fachmodul ohne Verbindung zur TI die Gültigkeit des Zertifikats nicht online prüfen kann. Hintergrund: Der Kostenträger kann bei Meldung eines Verlustes der eGK das Zertifikat des Versicherten direkt für die Online-Nutzung sperren und gegebenenfalls die Sperrung der Gesundheitsanwendung (DF.HCA) erst später durch Aktualisierung der eGK vornehmen. Ist die Gesundheitsanwendung der eGK gesperrt, ist sie im Kontext des VSDM technisch nicht nutzbar.

Das Unterelement Fachdienstquittung im Prüfungsnachweis wird vom Fachmodul mit der vom Fachdienst übermittelten Prüfziffer erstellt. Entweder sendet der Fachdienst UFS eine Prüfziffer, wenn kein VSD-Aktualisierungsauftrag vorliegt, oder der Fachdienst VSD, wenn eine VSD-Aktualisierung durchgeführt wurde. Der Fachdienst CMS erstellt keine Prüfziffer, da eine CMS-Prüfziffer nicht als Nachweis zur Aktualität der Versichertendaten geeignet ist. Im Fehlerfall liegt dem Fachmodul unter Umständen keine Prüfziffer vor. Liegt dem Fachmodul keine Prüfziffer vor, erzeugt es einen Prüfungsnachweis ohne Prüfziffer. [VSDM-A_2340]

3.1.6 Aktivität VSD Status Container lesen

Abbildung 14 – SD: VSD Status Container lesen [VSDM-A_2043]

3.1.7 Aktivität PD und VD von eGK lesen

Abbildung 15 – SD: PD und VD von eGK lesen [VSDM-A_2044]

3.1.8 Aktivität GVD von eGK lesen

Abbildung 16 – SD: GVD von eGK lesen [VSDM-A_2045]

Funktionale Ergänzungen

Beim Lesen der geschützten Versichertendaten (GVD) über die Operation read_Card_Data werden durch die TI-Plattform Zugriffsrechte berücksichtigt.

3.1.9 Aktivität VSDM-UC_09: Daten zu Protokollierungsliste hinzufügen

Abbildung 17 – SD: Daten zu Protokollierungsliste hinzufügen [VSDM-A_2040]

Funktionale Ergänzungen

Ein Protokolleintrag besteht aus den Informationen „WER" „WANN" „WAS" ausgeführt hat. Um das „WER“ zu ermitteln, muss das Fachmodul über die extract_card_data Operation der TI-Plattform die Identifikation bzw. den Namen aus der beteiligten HBA bzw. SMC-B ermitteln. Für das „WANN“ wird beim Erzeugen des Protokolleintrags ein aktueller Zeitstempel erzeugt. Das „WAS“ ist entweder das Lesen der geschützten Versichertendaten oder die Aktualisierung der eGK. Bei einer Aktualisierung muss das „WAS“ zusätzlich um den Service-Type aus den Lokalisierungsinformationen des zugehörigen Update Flags ergänzt werden. Die Zuordnung der einzutragenden Informationen zum Protokollierungsgegenstand (WER, WAS, WANN) ist in Tabelle Tab_VSDM_SysL_36 dargestellt.

Tabelle 7: Tab_VSDM_SysL_36 – Durch das Fachmodul VSDM zu erzeugende Informationen im Protokolleintrag des VSD-UC_09 [VSDM-A_2160]

3.1.10 Aktivität VSDM-UC_08: Prüfungsnachweis lesen

Abbildung 18 – SD: Prüfungsnachweis lesen [VSDM-A_2039]

Funktionale Ergänzungen

Der Prüfungsnachweis muss zwingend auf die eGK geschrieben werden, da im SGB V, § 291, Absatz 2b, Satz 7 die Speicherung des Nachweises der Durchführung der Onlineaktualisierung auf der eGK gefordert wird. Um sicherzustellen, dass nur die Institution den Prüfungsnachweis lesen kann, welche die Prüfung veranlasst hat, wird als Mechanismus ein symmetrisches Kryptographieverfahren eingesetzt. Dabei muss der Prüfungsnachweis mit dem symmetrischen Schlüssel entschlüsselt werden, der im Fachmodul konfiguriert ist. Damit die Entschlüsselung erfolgreich ist, muss derselbe Schlüssel verwendet werden, der auch zum Verschlüsseln des Prüfungsnachweises verwendet wurde (siehe Kapitel 3.1.12).

Das Fachmodul VSDM muss bzgl. des symmetrischen Schlüssels mandantenfähig sein damit es in Umgebungen mit mehreren Mandanten, z.B. Praxisgemeinschaften, einsetzbar ist. Demnach muss das Fachmodul VSDM sicherstellen, dass ein Mandant nur den ihm zugeordneten Schlüssel nutzen darf. [VSDM-A_2745]

3.1.11 Aktivität VSDM-UC_10: Protokollierungsliste auf eGK schreiben

Abbildung 19 – SD: Protokollierungsliste auf eGK schreiben [VSDM-A_2041]

Funktionale Ergänzungen

Innerhalb der Operation write_eGK_Protocol wird durch die TI-Plattform sichergestellt, dass die Berechtigung zum Schreiben von Protokolleinträgen vorliegt. Ist die Berechtigung nicht vorhanden, wird eine entsprechende Fehlermeldung zurückgegeben. Die TI-Plattform stellt ebenfalls sicher, dass das Lesen der Protokolleinträge nur durch Berechtigte erfolgen kann.

3.1.12 Aktivität VSDM-UC_07: Prüfungsnachweis schreiben

Abbildung 20 – SD: Prüfungsnachweis schreiben [VSDM-A_2038]

Funktionale Ergänzungen

Der Prüfungsnachweis muss mit dem symmetrischen Schlüssel geschrieben werden, der im Fachmodul konfiguriert ist. Somit wird sichergestellt, dass nur die Institution den Prüfungsnachweis entschlüsseln kann, die im Besitz des symmetrischen Schlüssels ist (siehe 3.1.10).

Auf die eGK wird immer der aktuelle Prüfungsnachweis geschrieben, da das Speichern auf der eGK lediglich zum Transport im Standalone-Szenario dient. Ein evtl. bereits vorhandener Prüfungsnachweises wird überschrieben. [VSDM-A_2161]

3.2 Anwendungsfall VSDM-UC_02: Automatische Onlineprüfung VSD

Aktivitätsdiagramm

Abbildung 21 – Aktivitätsdiagramm: VSDM-UC_02 - Automatische Onlineprüfung VSD [VSDM-A_2004] [VSDM-A_2005] [VSDM-A_2022] [VSDM-A_2023] [VSDM-A_2024] [VSDM-A_2025] [VSDM-A_2026] [VSDM-A_2029] [VSDM-A_2034]

Funktionale Ergänzungen zum Aktivitätsdiagramm

Die folgende Tabelle führt zum Anwendungsfall normativ funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 8: Tab_VSDM_SysL_04 – Automatische Onlineprüfung VSD [VSDM-A_2058]

Nichtfunktionale Anforderungen

Die nachfolgende Tabelle führt zum Anwendungsfall normativ Leistungsanforderungen auf, welche durch die Anwendung VSDM mindestens zu erfüllen sind. Der Zielwert stellt dabei den Wert dar, der unter optimalen Bedingungen erreichbar erscheint. Der "95% Grenzwert" stellt den Wert dar, der von 95% der ablaufenden Prozesse unterschritten werden soll. Im systemspezifischen Konzept Performanceuntersuchung (VSDM) [gemKPT_Perf_VSDM] ist das Performancemodell beschrieben, aus dem die Werte hergeleitet werden. Dabei wurden die Werte beim Zielwert auf volle Sekunden abgerundet und beim 95% Grenzwert auf volle Sekunden aufgerundet.

Tabelle 9: Tab_VSDM_SysL_05 – Leistungsanforderungen Anwendungsfall „Automatische Onlineprüfung VSD“ [VSDM-A_2059]

Datenschutz- und Sicherheitsanforderungen

Die nachfolgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 10: Tab_VSDM_SysL_06 – Schutzbedarfe im Anwendungsfall “Automatische Onlineprüfung VSD“ [VSDM-A_2060]

3.2.1 Aktivität VSDM-UC_12: Technische Nutzbarkeit und Gültigkeit der eGK prüfen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.1 „Aktivität VSDM-UC_12: Technische Nutzbarkeit und Gültigkeit der eGK prüfen“.

3.2.2 Aktivität VSDM-UC_11: Echtheit der beteiligten Karten prüfen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.2 „Aktivität VSDM-UC_11: Echtheit der beteiligten Karten prüfen“.

3.2.3 Aktivität VSDM-UC_04: Aktualisierungsaufträge ermitteln

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.3 „Aktivität VSDM-UC_04: Aktualisierungsaufträge ermitteln“.

3.2.4 Aktivität VSDM-UC_05: Aktualisierungen durchführen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.4 „Aktivität VSDM-UC_05: Aktualisierungen durchführen“.

3.2.5 Aktivität VSDM-UC_06: Prüfungsnachweis erzeugen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.5 „Aktivität VSDM-UC_06: Prüfungsnachweis erzeugen“.

3.2.6 Aktivität VSDM-UC_10: Protokollierungsliste auf eGK schreiben

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.11 „Aktivität VSDM-UC_10: Protokollierungsliste auf eGK schreiben“.

3.2.7 Aktivität VSDM-UC_07: Prüfungsnachweis schreiben

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.12 „Aktivität VSDM-UC_07: Prüfungsnachweis schreiben“.

3.2.8 Aktivität Ergebnis am Kartenterminal anzeigen

Da im Standalone-Szenario das Ergebnis der automatischen Onlineprüfung nicht am Bildschirm des Clientsystems dargestellt werden kann, müssen diese Informationen am Kartenterminal angezeigt werden können.

Abbildung 22 – SD: Ergebnis am Kartenterminal anzeigen [VSDM-A_2046]

3.3 Anwendungsfall VSDM-UC_03: Versichertendaten von KVK lesen

Da neben der eGK auch die KVK für Nicht-GKV Versicherte parallel im Feld ist, besteht die Notwendigkeit, dass Clientsysteme beide Karten verarbeiten können. Aus diesem Grund muss die Anwendung VSDM dem Clientsystem eine entsprechende Funktion bereitstellen.

Aktivitätsdiagramm

Abbildung 23 – Aktivitätsdiagramm: Versichertendaten von KVK lesen [VSDM-A_2003] [VSDM-A_2033] [VSDM-A_2176]

Funktionale Ergänzungen zum Anwendungsfall

Die nachfolgende Tabelle führt zum Anwendungsfall normativ funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 11: Tab_VSDM_SysL_07 – Versichertendaten von KVK lesen [VSDM-A_2061]

Datenschutz- und Sicherheitsanforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 12: Tab_VSDM_SysL_08 – Schutzbedarfe im Anwendungsfall “ Versichertendaten von KVK lesen“ [VSDM-A_2062]

3.3.1 Aktivität Versichertendaten von KVK lesen

Abbildung 24 – SD: Versichertendaten von KVK lesen [VSDM-A_2047]

3.3.2 Aktivität Versichertendaten prüfen

Funktionale Ergänzungen

Die Datenintegrität des ASN.1 KVK-Satzes wird durch Verifizieren der Prüfsumme geprüft. [VSDM-A_2167]

3.4 Anwendungsfall VSDM-UC_13 Konfiguration des Fachmoduls administrieren

Über diesen Anwendungsfall kann ein Administrator die Konfigurationseinträge für das Fachmodul einrichten und anpassen. Die nach derzeitigem Stand zu konfigurierenden Parameter sind in der nachfolgenden Tabelle aufgeführt.

Tabelle 13: Tab_VSDM_SysL_37 – Konfigurationsparameter des Fachmoduls [VSDM-A_2164]

Darüber hinaus muss die Schnittstelle dem Administrator ermöglichen, Log-Einträge einzusehen, um eine Fehleranalyse oder andere Supportprozesse zu unterstützen. [VSDM-A_2165]

Eine Definition der Konfigurationsschnittstelle des Fachmoduls ist derzeit noch nicht möglich. Für die Definition der Konfigurationsschnittstelle müssen erst die entsprechenden Festlegungen der TI-Plattform für den sicheren Ausführungsbereich und zum Schreiben und Lesen von Log-Einträgen getroffen werden. Da diese Festlegungen durch das Projekt Basis-TI Stufe 1 erst in der Spezifikationsphase erfolgen, kann auch erst dann die weitergehende Definition des Anwendungsfalls erfolgen.

3.5 Anwendungsfall VSDM-UC_14: VSD von eGK im mobilen Einsatzszenario lesen

Aktivitätsdiagramm

Abbildung 25 – Aktivitätsdiagramm: VSD von eGK im mobilen Einsatzszenario lesen [VSDM-A_2501] [VSDM-A_2509] [VSDM-A_2508] [VSDM-A_2506] [VSDM-A_2504] [VSDM-A_2503] [VSDM-A_2507]

Funktionale Ergänzungen zum Anwendungsfall

Die nachfolgende Tabelle führt zum Anwendungsfall funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 14: Tab_VSDM_SysL_39 – VSD von eGK im mobilen Einsatzszenario lesen [VSDM-A_2510]

Datenschutz- und Sicherheitsanforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 15: Tab_VSDM_SysL_40 – Schutzbedarfe im Anwendungsfall “VSD von eGK im mobilen Einsatzszenario lesen“ [VSDM-A_2513]

3.5.1 Aktivität Technische Nutzbarkeit und offline Gültigkeit der eGK prüfen (mobil)

Die technische Nutzbarkeit der eGK wird durch die Prüfung, ob die Gesundheitsanwendung auf der eGK aktiv (HCA-Container nicht gesperrt) ist, festgestellt. Die offline-Gültigkeit der eGK wird durch Prüfung der zeitlichen Gültigkeit des AUT-Zertifikats des Versicherten festgestellt. Darüber hinaus gehende Prüfungen des AUT-Zertifikats sind im mobilen Einsatzszenario nicht möglich, da die dafür benötigte Liste der vertrauenswürdigen Herausgeber von Zertifikaten nicht zuverlässig aktualisiert werden kann. [VSDM-A_2518]

3.5.2 Aktivität Echtheit der beteiligten Karten prüfen (mobil)

Es erfolgt eine gegenseitige Authentisierung der eGK und der verwendeten SMC-B/HBA, um die Echtheit der beteiligten Karten zu prüfen. Durch die gegenseitige Authentisierung wird die eGK je nach Rolle der SMC-B/HBA gleichzeitig zum Lesen der GVD freigeschaltet. [VSDM-A_2519]

3.5.3 Aktivität VSD Status Container Lesen (mobil)

Innerhalb der Aktivität wird die VSD-Statusinformation der eGK ausgelesen. Weisen die Statusinformationen auf inkonsistente VSD hin, wird die Aktivität mit einer entsprechenden Fehlermeldung abgebrochen. [VSDM-A_2522]

3.5.4 Aktivität PD und VD von eGK lesen (mobil)

Die persönlichen Versichertendaten und die allgemeinen Versicherungsdaten werden von der eGK gelesen. [VSDM-A_2521]

3.5.5 Aktivität GVD von eGK lesen (mobil)

Die geschützten Versichertendaten werden von der eGK gelesen, sofern die Rolle der SMC-B/HBA zum Lesen der GVD berechtigt ist [VSDM-A_2520]

3.5.6 Aktivität Protokolleintrag auf eGK schreiben (mobil)

Das Lesen der geschützten Versichertendaten wird protokolliert, indem ein Protokolleintrag auf der eGK geschrieben wird. [VSDM-A_2523]

3.6 Anwendungsfall VSDM-UC_15: Versichertendaten von KVK im mobilen Einsatzszenario lesen

Da neben der eGK auch die KVK für Nicht-GKV Versicherte parallel im Feld ist, besteht die Notwendigkeit, dass mobile Kartenterminals beide Karten einlesen können. Der Ablauf ist identisch zum Anwendungsfall VSDM-UC_03 Versichertendaten von KVK lesen.

Aktivitätsdiagramm

Abbildung 26 – Aktivitätsdiagramm: Versichertendaten von KVK im mobilen Einsatzszenario lesen [VSDM-A_2514] [VSDM-A_2517] [VSDM-A_2516]

Funktionale Ergänzungen zum Anwendungsfall

Die nachfolgende Tabelle führt zum Anwendungsfall normativ funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 16: Tab_VSDM_SysL_41 – Versichertendaten von KVK im mobilen Einsatzszenario lesen [VSDM-A_2526]

Datenschutz- und Sicherheitsanforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 17: Tab_VSDM_SysL_42 – Schutzbedarfe im Anwendungsfall “ Versichertendaten von KVK im mobilen Einsatzszenario lesen“ [VSDM-A_2527]

Die Aktivität Versichertendaten prüfen“ entspricht der Aktivitäten, wie sie in Kapitel 3.3.2 beschrieben ist.

3.6.1 Aktivität Versichertendaten von KVK lesen (mobil)

Die Versichertendaten werden von der KVK gelesen. [VSDM-A_2524]

3.6.2 Aktivität Versichertendaten prüfen (mobil)

Die Datenintegrität des ASN.1 KVK-Satzes wird durch Verifizieren der Prüfsumme geprüft. [VSDM-A_2525]

3.7 Anwendungsfall VSDM-UC_16: VSD von eGK in der AdV lesen

Aktivitätsdiagramm

Fortführung nächste Seite 

Abbildung 27– Aktivitätsdiagramm: VSDM-UC_16 - VSD von eGK in der AdV lesen [VSDM-A_3058] [VSDM-A_3059]

Funktionale Ergänzungen zum Anwendungsfall

Die nachfolgende Tabelle führt zum Anwendungsfall normativ funktionale Ergänzungen auf, welche durch die Anwendung VSDM zu erfüllen sind.

Tabelle 18: Tab_VSDM_SysL_45 – VSD von eGK in der AdV lesen [VSDM-A_3055]

Nichtfunktionale Anforderungen

Es gelten die in Tab_VSDM_SysL_02 beschriebenen Leistungsanforderungen in der Ab-laufvariante „Lesen VSD mit Onlineprüfung mit Aktualisierung der VSD“. Die Zeit für die PIN-Eingabe durch den Versicherten wird hierbei nicht betrachtet.

Datenschutz- und Sicherheitsanforderungen

Die folgende Tabelle führt zum Anwendungsfall normativ den Schutzbedarf der Schutzziele auf, welcher durch die Anwendung VSDM zu erfüllen ist.

Tabelle 19: Tab_VSDM_SysL_47 – Schutzbedarfe im Anwendungsfall “VSD von eGK in der AdV lesen“ [VSDM-A_3057]

3.7.1 Aktivität VSDM-UC_12: Technische Nutzbarkeit und Gültigkeit der eGK prüfen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.1 „Aktivität VSDM-UC_12: Technische Nutzbarkeit und Gültigkeit der eGK prüfen“.

3.7.2 Aktivität VSDM-UC_11: Echtheit der beteiligten Karten prüfen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.2 „Aktivität VSDM-UC_11: Echtheit der beteiligten Karten prüfen“.

3.7.3 Aktivität VSDM-UC_04: Aktualisierungsaufträge ermitteln

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.3 „Aktivität VSDM-UC_04: Aktualisierungsaufträge ermitteln“.

3.7.4 Aktivität VSDM-UC_05: Aktualisierungen durchführen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.4 „Aktivität VSDM-UC_05: Aktualisierungen durchführen“.

3.7.5 Aktivität: Authentifizierung des Versicherten

Die Berechtigung für den lesenden Zugriff auf die GVD und den schreibenden Zugriff auf das Protokoll (EF.LOGGING) wird neben dem Card-2-Card mit der Eingabe der PIN.CH durch den Versicherten erreicht.

Abbildung 28 – Sequenzdiagramm: Authentifizierung des Versicherten

3.7.6 Aktivität: VSD Status Container lesen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.6 „Aktivität VSD Status Container lesen“.

3.7.7 Aktivität: PD und VD von eGK lesen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.7 „Aktivität PD und VD von eGK lesen“.

3.7.8 Aktivität: GVD von eGK lesen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.8 „Aktivität GVD von eGK lesen“.

3.7.9 Aktivität VSDM-UC_09: Daten zu Protokollierungsliste hinzufügen

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.9 „Aktivität VSDM-UC_09: Daten zu Protokollierungsliste hinzufügen“.

3.7.10 Aktivität VSDM-UC_10: Protokollierungsliste auf eGK schreiben

Die Beschreibung der Aktivität erfolgt in Kapitel 3.1.11 „Aktivität VSDM-UC_10: Protokollierungsliste auf eGK schreiben“.

4 Externe Schnittstellen

In diesem Kapitel werden die Schnittstellen zwischen den Clientsystemen und dem Fachmodul sowie die Schnittstellen zwischen dem Fachmodul und den Fachdiensten dargestellt. Darüber hinaus werden die genutzten Schnittstellen der TI-Plattform aufgeführt. Es werden nur die Schnittstellen und Operationen definiert, die von den in Kapitel 3 beschriebenen Anwendungsfällen genutzt werden. Weitere Schnittstellen oder Operationen können in zukünftigen Ausbaustufen ergänzt werden.

Die Basis-TI hat produkttypübergreifende Anforderungen für eine einheitliche Struktur, Erzeugung und Verarbeitung von Fehlermeldungen spezifiziert. Zusätzlich werden fachanwendungsspezifische Fehlermeldungen in den VSDM Schnittstellen Spezifikationen definiert. [VSDM-A_2120]

4.1 Schnittstellen des Fachmoduls zum Clientsystem

4.1.1 Überblick

Für die Anwendungsfälle „VSD von eGK lesen“ und „Versichertendaten von KVK lesen“, die von dem Akteur Clientsystem initiiert werden, muss vom Fachmodul eine Schnittstelle Richtung Clientsystem bereitgestellt werden. [VSDM-A_2094] [VSDM-A_2170]

Für den Anwendungsfall „VSD von eGK in der AdV lesen“, der von dem Akteur Fachmodul AdV initiiert wird, muss vom Fachmodul VSDM eine Schnittstelle Richtung Fachmodul AdV bereitgestellt werden. [VSDM-A_3060]

Sollte durch die dezentrale TI-Plattform den Clientsystemen nicht bereits eine Möglichkeit zur Verfügung gestellt werden, die KVNR einer gesteckten eGK zu erhalten, muss von der Anwendung VSDM zusätzlich eine Schnittstelle zum Lesen der KVNR bereitgestellt werden. [VSDM-A_2118]

Abbildung 29 – Übersicht der Schnittstellen des Fachmoduls VSDM

4.1.2 Operation ReadVSD

Die Operation ReadVSD dient der Initiierung des Anwendungsfalls „VSD von eGK lesen“.

In dem Request muss ein Merkmal zur Identifizierung der eGK, von der die Daten gelesen werden sollen, enthalten sein. Um die notwendige Card-to-Card-Authentisierung durchführen und Protokolleinträge erstellen zu können, muss ebenfalls ein Merkmal zur Identifizierung der beteiligten SMC-B/HBA übergeben werden.

Damit das Clientsystem steuern kann, ob eine Update-Anfrage durchgeführt werden soll, muss die Operation einen entsprechenden Parameter besitzen. Ebenfalls soll das Clientsystem festlegen können, ob ein Prüfungsnachweis zurückgegeben werden soll.

Abhängig von der Parametrisierung des Requests enthält die Response den Inhalt des Status-Containers, die ungeschützten Versichertenstammdaten, die geschützten Versichertenstammdaten und den Prüfungsnachweis.

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 20: Tab_VSDM_SysL_29 – Parameter der Operation ReadVSD [VSDM-A_2097]    

4.1.3 Operation ReadKVK

Die Operation ReadKVK dient der Initiierung des Anwendungsfalls „Versichertendaten von KVK lesen“.

In dem Request muss ein Merkmal zur Identifizierung der KVK, deren Daten gelesen werden sollen, übergeben werden. In der Response werden die binären Daten der KVK an das Clientsystem zurückgegeben.

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 21: Tab_VSDM_SysL_30 – Parameter der Operation ReadKVK [VSDM-A_2099]

4.1.4 Operation ReadVSDAdV

Die Operation ReadVSDAdV dient der Initiierung des Anwendungsfalls „VSD von eGK in der AdV lesen“.

In dem Request muss ein Merkmal zur Identifizierung der eGK, von der die Daten gelesen werden sollen, enthalten sein. Um die notwendige Card-to-Card-Authentisierung durchzuführen und Protokolleinträge erstellen zu können, muss ebenfalls ein Merkmal zur Identifizierung der beteiligten SM-B übergeben werden.

Die Response enthält den Inhalt des Status-Containers, die ungeschützten Versicherten-stammdaten und die geschützten Versichertenstammdaten.

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 22: Tab_VSDM_SysL_46 – Parameter der Operation ReadVSDAdV [VSDM-A_3056]

4.2 Schnittstellen der Fachdienste zum Fachmodul

4.2.1 Überblick

Über die Schnittstelle zwischen Fachdienst und Fachmodul kann eine Aktualisierung der eGK initiiert werden und ein Fachdienst beliebige Chipkarten-Kommandos zur eGK senden. Zur Initiierung muss ein Fachmodul den Dienst anstoßen. Initial erhält der Dienst einen (oder mehrere) sogenannten Update-Identifier, anhand derer er den durchzuführenden Vorgang identifizieren kann. Den (oder die) Update-Identifier erhält das Fachmodul durch den vorherigen Aufruf der Schnittstelle des Update Flag Service (UFS).

Abbildung 30 – Übersicht der Schnittstellen der Fachdienste

Die technische Umsetzung der Schnittstelle erfolgt durch das Simple Object Access Protocol (SOAP) in der Version 1.1. [VSDM-A_2101] [VSDM-A_2103] [VSDM-A_2104]

Neben den fachlichen Informationen dieser Operationen werden für den Transport Metainformationen benötigt. Diese Metainformationen werden in diesem Kapitel ebenfalls beschrieben.

Eine zusätzliche Absicherung des Transportes auf Nachrichtenebene bei der Durchführung der Aktualisierung ist entsprechend den Anforderungen aus dem Lastenheft VSDM nicht erforderlich. Somit wird auf die Nachrichtensignatur bei der Operation PerformUpdates verzichtet. [VSDM-A_2121]

4.2.2 Operation GetUpdateFlags

Über die Operation GetUpdateFlags des UFS wird ermittelt, welche Fachdienste auf die eGK zugreifen möchten. Die Operation liefert Aktualisierungsaufträge (Update Flags) zu einer bestimmten ICCSN zurück. Liegen keine Aktualisierungsaufträge vor, wird eine Prüfziffer vom Fachdienst erzeugt und zurückgegeben. [VSDM-A_2102]

Die Reihenfolge, in der die zugehörigen Aktualisierungen angestoßen werden müssen, wird durch die Reihenfolge der in der Antwort enthaltenen Update Flags bestimmt. Die Reihenfolge wird somit vom Betreiber des Fachdienstes UFS vorgegeben. [VSDM-A_2110]

Neben den technischen Informationen zu den Aktualisierungsaufträgen wird auch eine textuelle Beschreibung des Auftrags mitgeliefert, die dem Nutzer über das Clientsystem angezeigt werden kann.

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 23: Tab_VSDM_SysL_31 – Parameter der Operation GetUpdateFlags [VSDM-A_2106]

4.2.3 Operation PerformUpdates

Die Operation PerformUpdates initiiert die Kommunikation zwischen Fachdienst und eGK. Durch die Übermittlung eines oder mehrerer Update-Identifier an den Fachdienst wird bei diesem der durchzuführende Vorgang angestoßen. Nach der Initiierung können Aktualisierungen auf der eGK durchgeführt werden. Im Response zu dieser Operation wird vom Fachdienst bereits das erste Kommandopaket für die eGK angegeben. [VSDM-A_2105]

Bevor die Kartenkommandos zum Aktualisieren der eGK geschickt werden können, muss ein Trusted Channel zwischen der eGK und dem Fachdienst aufgebaut werden. Für den Aufbau des Trusted Channel ist der Austausch mehrerer Kartenkommandos notwendig. Die weiteren Kartenkommandos werden über die Operation GetNextCommandPackage verschickt.

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 24: Tab_VSDM_SysL_32 – Parameter der Operation PerformUpdates [VSDM-A_2107]

4.2.4 Operation GetNextCommandPackage

Mit der Operation GetNextCommandPackage wird ein weiteres Kommandopaket für die eGK angefordert. Vor der ersten Ausführung dieser Operation MUSS die Operation PerformUpdates ausgeführt worden sein. [VSDM-A_2105]

Im Request dieser Operation werden dem Dienst die letzten Antworten der eGK mitgeliefert. Diese Operation muss solange wiederholt abgesetzt werden bis vom Dienst mitgeteilt wird, dass alle Aktualisierungen beendet sind. Für jede erfolgreich durchgeführte Aktualisierung wird dem Fachmodul eine Prüfziffer für den Prüfungsnachweis übergegeben.

Die Response beinhaltet entweder eine Liste der erfolgreich durchgeführten Aktualisierungen, weitere Kommandopakete für die eGK oder die Bestätigung, dass keine weiteren Aktualisierungen durchzuführen sind.

Werden die Versichertenstammdaten mit einem der übertragenen Kartenkommandos geändert, muss der Fachdienst mit einem vorhergehenden Kommando den Transaktionsstatus auf der eGK setzen. Nach den Kommandos zum Ändern der Daten muss ein Kommando zum Zurücksetzen des Transaktionsstatus folgen. [VSDM-A_2175]

Die folgende Tabelle führt zur Operation normativ die Eingangs- und Ausgangsparameter auf, welche durch die Anwendung VSDM zu benutzen sind.

Tabelle 25: Tab_VSDM_SysL_33 – Parameter der Operation GetNextCommandPackage [VSDM-A_2108]

4.2.5 Metainformationen für den Transport

Metainformationen für den Transport sind Informationen, die nicht fachlich motiviert aber für die Verarbeitung einer Nachricht relevant sind. Die Übertragung dieser Informationen kann z.B. in einem SOAP-Header-Element erfolgen.

Damit der Intermediär auch eine Lokalisierung auf HTTP-Ebene durchführen kann, ist es notwendig, dass dem Intermediär bereits auf dieser Ebene die Lokalisierungsinformationen zugänglich gemacht werden. Um dies zu erreichen, muss das Fachmodul die relevanten Lokalisierungsinformationen in die Endpunkt-Adresse kodieren. Zu den relevanten Informationen zählen der ServiceType (UFS, VSDD oder CMS), die Provider-Kennung (Kostenträgerkennung) und die verwendete Version der Schnittstelle. Das genaue Format, in dem die Informationen kodiert werden, wird in der Spezifikationsphase festgelegt. [VSDM-A_2122]

Für eine mögliche Lokalisierung des Fachdienstes auf Nachrichtenebene (z.B. bei einem Intermediär), müssen die für die Lokalisierung notwendigen Informationen in jedem Request als SOAP-Header übertragen werden. Diese Lokalisierungsinformationen müssen die gleichen Werte besitzen, mit denen der Fachdienst registriert ist. [VSDM-A_2109] [VSDM-A_2111] [VSDM-A_2112] [VSDM-A_2113]

Damit die Fachdienste eine Folge von zusammengehörigen Nachrichten korrelieren können, muss eine entsprechende Sessioninformation übertragen werden. Diese Sessioninformation wird vom Fachdienst beim initiierenden Aufruf (Operation PerformUpdates) erstellt und in der Response dem Fachmodul übergeben. Bei allen weiteren Aufrufen des Fachmoduls (Operation GetNextCommandPackage) muss die Sessioninformation im Request enthalten sein. [VSDM-A_2114] [VSDM-A_2115] [VSDM-A_2116] [VSDM-A_2117] [VSDM-A_2181] [VSDM-A_2182]

4.3 Genutzte Schnittstellen der TI-Plattform

In diesem Kapitel werden die innerhalb der Anwendungsfälle genutzten logischen Schnittstellen der TI-Plattform aufgeführt. Eine Beschreibung der Schnittstellen erfolgt durch das Projekt Basis-TI (Stufe 1) im Dokument „Konzept Architektur der TI-Plattform“ [gemKPT_Arch_TIP].

Tabelle 26: Übersicht der von der TI-Plattform genutzten Schnittstellen/Operationen

Für jede von der Fachanwendung VSDM genutzte Operation wird angegeben, welche Schutzbedarfe die TI-Plattform entsprechend den Ergebnissen der Schutzbedarfsfeststellung gewährleisten muss.

Die folgenden Tabellen führen zu den Schnittstellen normativ den Schutzbedarf der Schutzziele auf, welcher durch die Schnittstellen zu erfüllen ist.

Tabelle 27: Tab_VSDM_SysL_43 – Schutzbedarfe an der Schnittstelle I_Notification_From_FM [VSDM-A_2627]

Tabelle 28: Tab_VSDM_SysL_10 – Schutzbedarfe an der Schnittstelle I_Reg_Notification [VSDM-A_2078]

Tabelle 29: Tab_VSDM_SysL_11 – Schutzbedarfe an der Schnittstelle I_KT_Operations [VSDM-A_2079]

Tabelle 30: Tab_VSDM_SysL_44 – Schutzbedarfe an der Schnittstelle I_KV_Card_Reservation [VSDM-A_2628]

Tabelle 31: Tab_VSDM_SysL_12 – Schutzbedarfe an der Schnittstelle I_KV_Card_Operations [VSDM-A_2080]

Tabelle 32: Tab_VSDM_SysL_13 – Schutzbedarfe an der Schnittstelle I_KV_Card_Unlocking [VSDM-A_2081]

Tabelle 33: Tab_VSDM_SysL_14 – Schutzbedarfe an der Schnittstelle I_TLS_Client [VSDM-A_2082]

Tabelle 34: Tab_VSDM_SysL_15 – Schutzbedarfe an der Schnittstelle I_Symm_Crypt_Operations [VSDM-A_2083]

Tabelle 35: Tab_VSDM_SysL_16 – Schutzbedarfe an der Schnittstelle I_DNS_Name_Resolution [VSDM-A_2084]

Tabelle 36: Tab_VSDM_SysL_17 – Schutzbedarfe an der Schnittstelle I_NTP_Time_Information [VSDM-A_2085]

Tabelle 37: Tab_VSDM_SysL_18 – Schutzbedarfe an der Schnittstelle I_DNS_Service_Localization [VSDM-A_2086]

Tabelle 38: Tab_VSDM_SysL_19 – Schutzbedarfe an der Schnittstelle I_TLS [VSDM-A_2087]

Tabelle 39: Tab_VSDM_SysL_20 – Schutzbedarfe an der Schnittstelle I_OCSP_Status_Information [VSDM-A_2088]

Tabelle 40: Tab_VSDM_SysL_21 – Schutzbedarfe an der Schnittstelle I_TSL_Download [VSDM-A_2089]

5 Systemzerlegung (Deployment)

5.1 Übersicht

Der Überblick über die physische Architektur in Abbildung 31 stellt dar, wie die in Kapitel 2.2 beschriebenen Komponenten auf Produkttypen verteilt werden. Dabei werden nur die primär für die Anwendung VSDM relevanten Knoten dargestellt. Alle nicht vollständig durch das Projekt VSDM verantworteten Knoten sind als extern gekennzeichnet.

Das Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP] sieht für den Konnektor zwei Produkttypen (Anwendungs- und Netzkonnektor) vor. Im VSDM-Deployment-Diagramm werden diese beiden Produkttypen vereinfacht zusammen als Produkttyp „Konnektor“ aufgeführt.

Das Fachmodul VSDM und das Fachmodul VSDM (mobKT) sind im Rahmen des Online-Produktivbetriebes (Stufe 1) keine eigenständigen Produkttypen. Sie sind lediglich Produktbausteine des Anwendungskonnektor bzw. des Mobilen Kartenterminals. Dieser Sachverhalt wird in der Abbildung nicht gesondert dargestellt.

Der Knoten „zentrale TI-Plattform“ ist nicht weiter untergliedert, da aus der Sicht der Anwendung VSDM die TI-Plattform eine „Black Box“ ist und die Aufteilung der TI-Plattform daher für die Anwendung VSDM nicht relevant ist.

Die Produkttypen UFS, VSDD und CMS unterliegen nicht vollständig der Verantwortung des Projektes VSDM. Damit der „Fachdienst-Schnittstelle VSDM“ dennoch eine für diese Produkttypen wesentliche Komponente in der Verantwortung des Projektes VSDM liegt, werden auch diesen Produkttypen Anforderungen zugeordnet.

Die Fachanwendung AdV gliedert sich in der Leistungserbringer-Umgebung in die Produkttypen LE-AdV-Terminal und Fachmodul AdV.

In der Kostenträgerumgebung (inkl. der Geräte des Versicherten) gliedert sich die Fachanwendung AdV in die Produkttypen KTR-AdV-Terminal und KTR-AdV. Der Produkttyp KTR-AdV wird dabei aus dem AdV-Server und der zugehörigen AdV-App gebildet.

Abbildung 31 – Deployment Diagramm „Deployment VSDM“ [VSDM-A_2052] [VSDM-A_2073] [VSDM-A_2074] [VSDM-A_2075] [VSDM-A_2076] [VSDM-A_2077] [VSDM-A_2512]

5.2 Produkttyp Fachmodul VSDM

Das Fachmodul VSDM ist Bestandteil der dezentralen TI und

• stellt dem Clientsystem die in Kapitel 4 genannten technischen Schnittstellen zur Verfügung,
• initiiert die Kommunikation Richtung Fachdienste,
• unterstützt die in Kapitel 3 genannten Anwendungsfälle und
• kapselt gegenüber der Außenwelt die Ausführungslogik.

Zum Zweck der Fehler- und Performanceanalyse muss das Fachmodul VSDM Log-Einträge schreiben, die es erlauben, Abläufe und Fehlerzustände zu analysieren. Die Log-Einträge sind über eine Schnittstelle auslesbar. [VSDM-A_2123] [VSDM-A_2165]

Das Fachmodul authentifiziert sich beim Verbindungsaufbau gegenüber dem Intermediär, um sicherzustellen, dass nur Anfragen aus Umgebungen von berechtigten Akteuren stammen. Um zu gewährleisten, dass nur ein berechtigter Intermediär mit dem Fachmodul kommuniziert, prüft das Fachmodul unter Verwendung der Schnittstelle I_TLS das Verbindungszertifikat des Intermediärs. [VSDM-A_2338] [VSDM-A_2709]

Die folgende Tabelle führt zum Produkttyp normativ den Schutzbedarf der Schutzziele auf, welcher durch den Produkttyp zu erfüllen ist.

Tabelle 41: Tab_VSDM_SysL_23 – Schutzbedarfe im Produkttyp Fachmodul VSDM [VSDM-A_2072]

5.3 Produkttyp systemspezifischer Intermediär VSDM

Der Intermediär VSDM

• steht logisch und physisch zwischen dem Fachmodul VSDM und den Fachdienstschnittstellen UFS, VSDD und CMS,
• lokalisiert den anzusprechenden Fachdienst,
• reicht fachliche Datenstrukturen transparent weiter,
• anonymisiert den anfragenden Leistungserbringer auf Netzwerkebene und
• bündelt Netzwerkverbindungen, um die Anzahl der Netzwerkverbindungen Richtung Fachdienste zu reduzieren. [VSDM-A_2336]

Der Intermediär verwendet zur Lokalisierung die in Kapitel 4.2.5 beschriebenen Informationen, um die korrekte URL des Fachdiensts zu ermitteln. [VSDM-A_2144]

Wie im Komponentendiagramm (s. Abbildung 2) dargestellt, stellt der Intermediär den Endpunkt für Verbindungen aus der dezentralen TI-Plattform dar und baut Richtung Fachdienste separate Verbindungen auf. Dies ermöglicht, die Verbindungen der Fachdienste zu reduzieren. Außerdem müssen für den Wiederaufbau einer Verbindung von einem Fachmodul bzw. zu einem Fachdienst durch den Intermediär VSDM Mechanismen realisiert werden, die den Verbindungsaufbau beschleunigen. Bereits aufgebaute offene Verbindungen zu den Fachdiensten werden für einen konfigurierbaren Zeitraum für weitere Anfragen wiederverwendet. [VSDM-A_2162] [VSDM-A_2163] [VSDM-A_2171]

Zusätzlich wird durch diese Architektur sichergestellt, dass den Fachdiensten nur die Netzwerkidentität des Intermediärs VSDM bekannt ist. Daten mit Bezug zum Leistungserbringer sind für die Fachdienste nicht ersichtlich und eine Profilbildung ist ausgeschlossen.

Der Intermediär VSDM stellt beim Verbindungsaufbau sicher, dass Anfragen nur aus Umgebungen von berechtigten Akteuren stammen. Dazu prüft er das Verbindungszertifikat des anfragenden Fachmoduls, als auch des aufzurufenden Fachdiensts auf Gültigkeit. Bestandteil dieser Prüfung ist die Ermittlung des Zertifikatsstatus am Zertifikatsvalidierungsdienst. Der Intermediär VSDM muss den Verbindungsaufbau abbrechen, wenn der Zertifikatsvalidierungsdienst nicht antwortet, das Zertifikat gesperrt oder nicht gültig ist. [VSDM-A_2137] [VSDM-A_2171] [VSDM-A_2337]

Zum Zweck der Fehler- und Performanceanalyse muss der Intermediär VSDM Log-Einträge schreiben, die es erlauben, Abläufe und Fehlerzustände zu analysieren. Die Log-Einträge müssen für berechtigte Nutzer auslesbar sein [VSDM-A_2126] [VSDM-A_2128].

Die folgende Tabelle führt zum Produkttyp normativ den Schutzbedarf der Schutzziele auf, welcher durch den Produkttyp zu erfüllen ist.

Tabelle 42: Tab_VSDM_SysL_24 – Schutzbedarfe im Produkttyp systemspezifischer Intermediär VSDM [VSDM-A_2090]

5.4 Produkttyp Fachdienst UFS

Der Fachdienst Update Flag Service (UFS) realisiert die Fachdienstschnittstelle VSDM und gibt Auskunft über vorhandene Aktualisierungsaufträge für die eGK. [VSDM-A_2180]

Zum Zweck der Fehler- und Performanceanalyse muss der Fachdienst UFS Log-Einträge schreiben, die es erlauben, Abläufe und Fehlerzustände zu analysieren. Die Log-Einträge müssen für berechtigte Nutzer auslesbar sein. [VSDM-A_2129] [VSDM-A_2133]

Um sicherzustellen, dass Anfragen nur aus Umgebungen berechtigter Akteure stammen, akzeptiert der Fachdienst UFS Verbindungsanfragen aus der TI nur vom Intermediär VSDM. Da der Intermediär VSDM wiederum nur Anfragen aus Umgebungen berechtigter Akteure weiterreicht, können somit keine Anfragen von unberechtigten Akteuren an den Fachdienst UFS gestellt werden.

Der Fachdienst UFS muss das Verbindungszertifikat des Intermediärs VSDM auf Gültigkeit prüfen. Bestandteil dieser Prüfung ist die Ermittlung des Zertifikatsstatus am Zertifikatsvalidierungsdienst. Der Fachdienst UFS muss den Verbindungsaufbau abbrechen, wenn der Zertifikatsvalidierungsdienst nicht erfolgreich antwortet, das Zertifikat gesperrt oder nicht gültig ist. [VSDM-A_2138] [VSDM-A_2172]

Die folgende Tabelle führt zum Produkttyp normativ den Schutzbedarf der Schutzziele auf, welcher durch den Produkttyp zu erfüllen ist.

Tabelle 43: Tab_VSDM_SysL_25 – Schutzbedarfe im Produkttyp Fachdienst UFS [VSDM-A_2091]

5.5 Produkttyp Fachdienst VSDD

Der Fachdienst Versichertenstammdatendienst (VSDD) realisiert die Fachdienstschnittstelle VSDM und kommuniziert mit der eGK, um vorhandene VSD-Aktualisierungen durchzuführen. [VSDM-A_2178]

Zum Zweck der Fehler- und Performanceanalyse muss der Fachdienst VSDD Log-Einträge schreiben, die es erlauben, Abläufe und Fehlerzustände zu analysieren. Die Log-Einträge müssen für berechtigte Nutzer auslesbar sein. [VSDM-A_2130] [VSDM-A_2134]

Um sicherzustellen, dass Anfragen nur aus Umgebungen berechtigter Akteure stammen, akzeptiert der Fachdienst VSDD nur Verbindungsanfragen des Intermediärs VSDM. Da der Intermediär VSDM wiederum nur Anfragen aus Umgebungen berechtigter Akteure weiterreicht, können somit keine Anfragen von unberechtigten Akteuren an den Fachdienst VSDD gestellt werden.

Der Fachdienst VSDD muss das Verbindungszertifikat des Intermediärs VSDM prüfen. Bestandteil dieser Prüfung ist die Ermittlung des Zertifikatsstatus am Zertifikatsvalidierungsdienst. Der Fachdienst VSDD muss den Verbindungsaufbau abbrechen, wenn der Zertifikatsvalidierungsdienst nicht erfolgreich antwortet, das Zertifikat gesperrt oder nicht gültig ist. [VSDM-A_2139] [VSDM-A_2173]

Die folgende Tabelle führt zum Produkttyp normativ den Schutzbedarf der Schutzziele auf, welcher durch den Produkttyp zu erfüllen ist.

Tabelle 44: Tab_VSDM_SysL_26 – Schutzbedarfe im Produkttyp Fachdienst VSDD [VSDM-A_2092]

5.6 Produkttyp Fachdienst CMS

Der Fachdienst Card Management System (CMS) realisiert die Fachdienstschnittstelle VSDM und kommuniziert mit der eGK, um vorhandene CMS-Aktualisierungen, z.B. die Sperrung der Gesundheitsanwendung, durchzuführen. [VSDM-A_2179]

Zum Zweck der Fehler- und Performanceanalyse muss der Fachdienst CMS Log-Einträge schreiben, die es erlauben, Abläufe und Fehlerzustände zu analysieren. Die Log-Einträge müssen für berechtigte Nutzer auslesbar sein. [VSDM-A_2131] [VSDM-A_2135]

Um sicherzustellen, dass Anfragen nur aus Umgebungen berechtigter Akteure stammen, akzeptiert der Fachdienst CMS nur Verbindungsanfragen des Intermediärs VSDM. Da der Intermediär VSDM wiederum nur Anfragen aus Umgebungen berechtigter Akteure weiterreicht, können somit keine Anfragen von unberechtigten Akteuren an den Fachdienst CMS gestellt werden.

Der Fachdienst CMS muss das Verbindungszertifikat des Intermediärs VSDM auf Gültigkeit prüfen. Bestandteil dieser Prüfung ist die Ermittlung des Zertifikatsstatus am Zertifikatsvalidierungsdienst. Der Fachdienst CMS muss den Verbindungsaufbau abbrechen, wenn der Zertifikatsvalidierungsdienst nicht erfolgreich antwortet, das Zertifikat gesperrt oder nicht gültig ist. [VSDM-A_2140] [VSDM-A_2174]

Die folgende Tabelle führt zum Produkttyp normativ den Schutzbedarf der Schutzziele auf, welcher durch den Produkttyp zu erfüllen ist.

Tabelle 45: Tab_VSDM_SysL_27 – Schutzbedarfe im Produkttyp Fachdienst CMS [VSDM-A_2093]

5.7 Produkttyp Fachmodul VSDM (mobKT)

Mit dem mobilen Kartenterminal kann ein Leistungserbringer die Versichertendaten der eGK ohne Verbindung zur Online-TI auslesen. Es vereint die Funktionen eines eHealth-Kartenterminals (Karten-Slots, Display, PinPad) mit den Funktionen eines portablen Computers (grafische Benutzerführung, Daten speichern/laden/bearbeiten).

Ein mobiles Kartenterminal hat prinzipiell keinen Zugang zur zentralen Telematikinfrastruktur. Es wird zur Übertragung von Daten lokal an einen Arbeitsplatzrechner angeschlossen und kommuniziert ausschließlich mit diesem.

Das Fachmodul VSDM (mobKT) ist ein integraler Bestandteil des mobilen Kartenterminals. Fachliche Anforderungen an das Fachmodul VSDM (mobKT) werden durch den Produkttyp mobiles Kartenterminal realisiert.

Die im Online-Produktivbetrieb (Stufe 1) eingesetzten Kartenterminals der Ausbaustufe 2 unterstützen das Lesen der GVD aus dem geschützten Bereich. Zwingende Voraussetzung hierfür ist ein C2C.

Tabelle 46: Tab_VSDM_SysL_22 – Schutzbedarfe im Produkttyp Fachmodul VSDM (mobKT) [VSDM-A_2511]

6 Informationsmodell

Hinweis: Dieses Dokument enthält eine weiterentwickelte Version des VSD-Schemas (Schemaversion 5.2). Die Abstimmungen zu den durch die Schemaänderung notwendigen Anpassungen an den Komponenten im Basis-Rollout werden zeitnah durch die Vertragspartner getroffen.

Hinweis: Dieses Dokument enthält eine zusätzliche Version des VSD-Schemas (Schemaversion 1.0) für die Nutzung durch Fachdienste der privaten Kostenträger.

6.1 Fachliches Informationsmodell VSDM

Das fachliche Informationsmodell der GKV und eine detaillierte Beschreibung der fachlichen Inhalte sind Gegenstand des Lastenhefts VSDM und werden im vorliegenden Dokument nicht aufgeführt.

6.2 Technisches Informationsmodell VSDM

Das technische Informationsmodell der GKV wird auf Basis des fachlichen Informationsmodells entworfen. Aus dem technischen Informationsmodell werden die notwendigen Teilmodelle der GKV abgeleitet.

Das technische Informationsmodell der PKV wird im vorliegenden Dokument dargestellt. Aus dem technischen Modell der PKV werden die notwendigen Teilmodelle der PKV abgeleitet.

Die Aufteilung der Informationsmodelle in die Teilmodelle für die VSD Container auf der eGK erfolgt für GKV und PKV separat, so dass auf einer eGK entweder das Informationsmodell der GKV oder das der PKV abgebildet ist.

Die Teilmodelle für die VSD Container resultieren in XML-Schemas für deren Befüllung. Aufgrund der getrennten Abbildung ergibt sich daraus jeweils ein Schema für die Befüllung der VSD Container einer eGK für gesetzlich Versicherte und für die Befüllung einer eGK für privat Versicherte.

Im Dokument selbst werden die Schemas grafisch dargestellt und beschrieben.

Für die XML-Repräsentation der Versichertenstammdaten und des Prüfungsnachweises ist die Verwendung einer Untermenge des Zeichensatzes [ISO 8859-15] vorgeschrieben. Diese Untermenge stellen alle in der Tabelle 47 nicht mit „res“ markierten Zeichen dar. [VSDM-A_2185]

Tabelle 47: Tab_VSDM_SysL_38 – Zeichencode ISO/IEC 8859-15 [VSDM-A_2185]

Legende:

6.2.1 Technisches Informationsmodell VSD

Die Versichertenstammdaten werden auf der eGK in drei Containern abgelegt

• Persönliche Versichertendaten (PD)
• Geschützte Versichertendaten (GVD)
• Allgemeine Versicherungsdaten (VD)

Zusätzlich wird ein vierter Container genutzt, der das Datum der letzten Aktualisierung, die Version und einen Status beinhaltet. Der Status zeigt an, ob der letzte Aktualisierungsprozess vollständig durchgelaufen ist und die Daten über die drei VSD-Container hinweg technisch konsistent sind. Schreibabbrüche während der Aktualisierung lassen sich somit eindeutig erkennen. [VSDM-A_2969]

Die Inhalte der drei VSD-Container werden als komprimierte XML-Dokumente abgelegt. Zur Komprimierung wird ein definierter Algorithmus verwendet. Der Status-Container wird als String abgelegt. Somit wird sichergestellt, dass der Status-Container auch ohne Kenntnis des Kompressionsalgorithmus gelesen werden kann.

Durch die Speicherung der VSD in drei Containern auf der eGK ist es erforderlich, aus den Informationsmodellen der Versichertenstammdaten jeweils drei Teilmodelle zu bilden, die Anteile des jeweiligen Informationsmodells VSDM enthalten. In die Teilmodelle werden nur die Assoziationen, Attribute und Klassen aufgenommen, die bezogen auf den sie aufnehmenden eGK-Container benötigt werden. [VSDM-A_2155]

Informationsmodell VSD der GKV

Abbildung 32 – Informationsmodell Versichertenstammdaten [VSDM-A_2051]

Informationsmodell VSD der PKV

Abbildung 33 Informationsmodell Versichertenstammdaten der PKV (A_21180)

6.2.2 Teilmodelle persönliche Versichertendaten

Teilmodell persönliche Versichertendaten der GKV

Abbildung 34 Teilmodell persönliche Versichertendaten [VSDM-A_2158]

Teilmodell persönliche Versichertendaten der PKV

Abbildung 35 Teilimodell persönliche Versichertendaten PKV (A_21172)

6.2.3 Teilmodelle geschützte Versichertendaten

Teilmodell geschützte Versichertendaten der GKV

Abbildung 36 – Teilmodell geschützte Versichertendaten [VSDM-A_2156]

Teilmodell geschützte Versichertendaten der PKV

Abbildung 37 – Teilmodell geschützte Versichertendaten der PKV (A_21174)

6.2.4 Teilmodelle allgemeine Versicherungsdaten

Teilmodell allgemeine Versichertendaten der GKV

Abbildung 38 – Teilmodell allgemeine Versicherungsdaten [VSDM-A_2159]

Teilmodell allgemeine Versichertendaten der PKV

Abbildung 39 - Teilmodell allgemeine Versicherungsdaten der PKV (A_21173)

6.2.5 Technisches Informationsmodell Prüfungsnachweis

Zur Ablage des Prüfungsnachweises wird ein weiterer Container EF.Prüfungsnachweis genutzt. Der Prüfungsnachweis dient dem Leistungserbringer zum Nachweis der durchgeführten Onlineprüfung und -aktualisierung beim ersten Quartalsbesuch eines Versicherten.

Der Inhalt des Containers EF.Prüfungsnachweis wird als komprimiertes XML-Dokument abgelegt. Zur Komprimierung wird ein definierter Algorithmus verwendet.

Das technische Informationsmodell zu dieser XML-Struktur ist in der nachfolgenden Abbildung dargestellt, das XML-Schema in Anhang C2

Informationsmodell Prüfungsnachweis der GKV

Abbildung 40 – Informationsmodell Prüfungsnachweis [VSDM-A_2154]

Informationsmodell Prüfungsnachweis der PKV

Abbildung 41 Informationsmodell Prüfungsnachweis der PKV

6.2.6 Abbildung der Teilmodelle in XML-Schemadateien

Die Teilmodelle für die VSD Container der eGK (PD, VD, GVD) werden auf technischer Ebene durch ein XML-Schema abgebildet.

Das resultierende Schema ist aufgrund der unterschiedlichen Teilmodelle spezifisch für eGK der GKV und eGK der PKV und liegt in einer Version der GKV und einer Version der PKV vor.

7 Externe Partner (informativ)

Die folgenden Anforderungen resultieren aus dem Lastenheft VSDM und richten sich an Kostenträger und Leistungserbringer in ihren Funktionen außerhalb des Projektes. Zur Vollständigkeit werden diese Anforderungen im systemspezifischen Konzept noch mal unverändert aufgeführt. Es werden in den Anforderungen Inhalte formuliert, die organisatorische Aufgaben des jeweiligen Adressaten außerhalb der Projektstruktur betreffen, die jedoch Bezug zum Projekt besitzen. Die Anforderungen sind daher nur informativ, da ihre Umsetzung durch das Projekt nicht gefordert und kontrolliert werden kann. Die Anforderungslevel wurden trotzdem in RFC-Notation formuliert, um die jeweilige Priorität der Anforderung aus Projektsicht hervorzuheben. [VSDM-A_2053], [VSDM-A_2054]

7.1 Anforderungen an die Gesellschafter

7.2 Anforderungen an die Kostenträger

7.3 Anforderungen an die Leistungserbringer

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

Die folgende Tabelle enthält eine Beschreibung von spezifischen Begriffen, die im systemspezifischen Konzept VSDM verwendet werden. Die Inhalte des spezifischen Glossars fließen zukünftig auch in das übergeordnete Glossar ein.

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. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellen, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

8.5.2 Weitere Dokumente

9 Anhang B – Anforderungshaushalt

9.1 Eingangsanforderungen

Tabelle 48: Eingangsanforderungen mit Nachweis der Abdeckung