Elektronische Gesundheitskarte und Telematikinfrastruktur

Schnittstellenspezifikation

Fachdienste (UFS/VSDD/CMS)

    

     

      
Version
      
1.7.0
     
     

      
Revision
      
1141309
     
     

      
Stand
      
14.02.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_SST_FD_VSDM
     
    

Dokumentinformationen

Änderung zur Vorversion

Überarbeitung der Dokumente für den Online-Produktivbetrieb (Stufe 1), als Grundlage für Produktivzulassungen und den bundesweiten Rollout.

Die Änderungen zur letzten freigegebenen Version zum Online-Rollout (Stufe 1) sind gelb markiert.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument spezifiziert die Schnittstelle zwischen den Fachdiensten VSDM und dem Fachmodul VSDM auf Anwendungsebene. Die Fachdienste VSDM sind in der jetzigen Version der Update Flag Service (UFS), das Kartenmanagementsystem (CMS) und der Versichertenstammdatendienst (VSDD). Die Dienste CMS und VSDD werden in Bezug auf ihre Schnittstelle als "Card Communication Service" (CCS) zusammengefasst.

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 und definiert die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemSysL_VSDM] vorausgesetzt.

Die Anforderungen an die Transportschnittstelle auf Nachrichtenebene werden separat in dem Dokument Schnittstellenspezifikation Transport VSDM [gemSpec_SST_VSDM] behandelt.

Die Abbildung 1 zeigt schematisch die Dokumentenhierarchie im Projekt VSDM, in welcher die Schnittstellenspezifikation Fachdienste innerhalb der Konzepte und Spezifikationen der Design-Phase eingeordnet ist. 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 der Schnittstellenspezifikation Fachdienste werden einleitend in Kapitel 1 die Zielsetzung des Dokumentes, die notwendigen Grundlagen und die gewählten Methoden dargestellt.

Kapitel 2 enthält eine Zusammenfassung der allgemeinen Festlegungen zu den in diesem Dokument spezifizierten Schnittstellen.

Die Spezifikation der Operation der UFS-Schnittstelle erfolgt in Kapitel 3 und in Kapitel 4 erfolgt die Spezifikation für die Operationen der CCS-Schnittstelle.

Zur Verdeutlichung der Kommunikation im Rahmen der Aktualisierung einer eGK wird in Kapitel 5 der prinzipielle Ablauf einmal dargestellt und die Kartenkommandos, die für eine Aktualisierung notwendig sind werden beschrieben.

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 richtet sich an Hersteller und Anbieter der VSDM-Fachdienste und Fachmodule sowie an Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

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

Die Transportschnittstelle zwischen den Fachdiensten VSDM (UFS, VSDD, CMS) und dem Fachmodul VSDM befindet sich nach dem OSI-Schichtenmodell in der Anwendungsschicht. Die Transportschnittstelle selbst wird dabei in die zwei Ebenen Nachrichtenebene und Anwendungsebene unterteilt. Zur Anwendungsebene, die in diesem Dokument behandelt wird, zählen die fachdienstespezifischen Daten (SOAP-Body).

Das Dokument [gemSpec_SST_VSDM] spezifiziert die Schnittstelle zwischen den Fachdiensten VSDM und dem Fachmodul VSDM auf Nachrichtenebene und bezieht sich auf die Header-Information in der SOAP-Nachricht.

Festlegungen zu tiefer liegenden Schichten im OSI-Modell und übergreifenden Themen, wie Prüfung von Zertifikaten, zulässige Algorithmen und Details der sicheren Kommunikation, werden durch Spezifikationen der Basis-TI getroffen.

Festlegungen zur Ausführung von Anwendungsfällen und Vorgaben zum Betrieb der Fachdienste sind nicht Bestandteil dieser Spezifikation.

1.5 Bestandsschutz

Für die Schnittstellen der Fachdienste der Kostenträger besteht Bestandsschutz. Nur in begründeten Fällen darf in Abstimmung mit den Kostenträgern davon abgewichen werden. Daher werden die Festlegungen bezüglich der Fehlerstruktur und Transport der fachlichen Inhalte aus dem Releasestand 4.0.0 in die Dokumente der Pflichtenheftphase übernommen.

Das Transportprotokoll Telematik Transport Details (TTD) ist gemäß Entscheidung der Basis-TI kein übergreifendes Protokoll, das von allen Fachanwendungen der TI zwingend zu verwenden ist. Zukünftig verantworten die Fachanwendungen das Kommunikationsprotokoll selbst. Um die Komplexität zu reduzieren, wird in Abstimmung mit den Kostenträgern in der Fachanwendung VSDM auf die TTD als Transportprotokoll verzichtet.

Stattdessen werden für die Fachdienste VSDM nur die Elemente zur Lokalisierung und Sessioninformation übernommen sowie die Standard SOAP-Struktur verwendet.

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

2 Allgemeine Festlegungen

Das vorliegende Dokument spezifiziert die Schnittstelle zwischen den Fachdiensten VSDM und dem Fachmodul VSDM. Zu den Fachdiensten VSDM zählen der Update Flag Service (UFS), das Kartenmanagementsystem (CMS) und der Versichertenstammdatendienst (VSDD). Die Fachdienste CMS und VSDD werden in Bezug auf ihre Schnittstelle als "Card Communication Service" (CCS) zusammengefasst.

Die Spezifikation der Schnittstelle des "Update Flag Service" und des "Card Communication Service" umfasst die Definition mehrerer Operationen. Ein Dienst, der eine dieser Schnittstellen anbietet, muss diese spezifizierten Operationen vollständig implementieren.

In Kapitel 3 und Kapitel 4 sind die Operationen der Schnittstellen detailliert beschrieben. Zu jeder Operation gibt es ein Request- und ein Response-Element. Die Request- und Response-Nachrichten, der von den Diensten implementierten Operationen, müssen zu den definierten Schemas konform sein.

Zusätzlich zu den hier getroffenen Festlegungen gelten für die hier beschriebenen Schnittstellen alle übergreifenden Festlegungen aus der Spezifikation [gemSpec_SST_VSDM].

2.1 Bezeichnung der Request-Elemente

Der Name eines Request-Elementes kann eindeutig einer Operation zugeordnet werden, die bei dem Dienst ausgeführt werden soll.

2.2 Bezeichnung der Response-Elemente

Ein Response-Element besteht aus dem Namen des zugehörigen Request-Elementes und dem Suffix Response.

2.3 Header-Elemente

In dieser Spezifikation werden keine eigenen Header-Elemente definiert. Es werden die Header-Elemente entsprechend der Spezifikation [gemSpec_SST_VSDM] verwendet. Für jeden Request, als auch für die Response, sind operationsspezifisch Header-Elemente festgelegt.

2.4 Visualisierung der XML-Schemata

Zur besseren Verständlichkeit werden in den folgenden Kapiteln XML-Schemas oder Teile hieraus grafisch dargestellt. Die Visualisierungen wurden aus den zugrunde liegenden Schemas generiert. Maßgeblich für die exakte Definition eines Elementes ist nicht die Visualisierung, sondern jeweils das zugrunde liegende Schema [UFS.wsdl] [CCS.wsdl].

3 Update Flag Service

Der Update Flag Service (UFS) bündelt den ggf. vorliegenden Aktualisierungsbedarf mehrerer Dienste (CMS und VSDD) und gibt über die UFS-Schnittstelle Auskunft zum Aktualisierungsbedarf. Damit entfällt der Aufwand, bei jedem Kontakt der eGK mit der Telematikinfrastruktur jeden Fachdienst, der potentiell auf die eGK zugreifen möchte, explizit nach einer Aktualisierung zu fragen. Der UFS optimiert somit diesen Ablauf.

Abbildung 2 – Darstellung der UFS-WSDL

Wenn ein Fachdienst eine Aktualisierung der eGK beabsichtigt, setzt dieser Fachdienst ein entsprechendes Update Flag im UFS. Sobald die eGK anschließend, z. B. im Rahmen eines Arztbesuches mit dem UFS in Kontakt tritt, zeigt dieser den Aktualisierungsbedarf an und es wird ggf. die Aktualisierung initiiert.

Wenn eine Optimierung von Aktualisierungen möglich ist, indem mehrere Aktualisierungen zusammen in einem Vorgang durchgeführt werden, nimmt der Fachdienst diese Optimierung vor, indem er die Änderungen zu einem Aktualisierungsvorgang zusammenführt. Fallen zum Beispiel mehrere Änderungen der VSD an, sollen die Änderungen in einer Aktualisierung mit dem ServiceType VSD zusammenfasst werden. [VSDM-A_2751]

Die Schnittstelle zum Hinzufügen und Entfernen eines Update Flags am UFS durch einen Fachdienst ist nicht Teil der Fachanwendung VSDM. Die Schnittstelle liegt in der Verantwortung der Fachdienstbetreiber und kann von diesen eigenverantwortlich implementiert werden.

In der Tabelle 1 sind die allgemeinen Werte der Schnittstelle aufgeführt. Diese Werte werden unter anderem für die Kodierung der Endpunkt-Adresse der Schnittstelle verwendet.

Tabelle 1: Tab_SST_FD_01 – Allgemeine Werte der UFS Schnittstelle

3.1 Operation GetUpdateFlags

Mit der Operation GetUpdateFlags können Update Flags zu einer bestimmten ICCSN ausgelesen werden. Ein vorhandenes Update Flag muss eindeutig über das Tupel ICCSN, Service-Localization und Update-Identifier identifiziert werden können. [VSDM-A_2280] [VSDM-A_2281]

Die Antwortnachricht der Operation enthält die Prüfziffer, wenn kein Aktualisierungsauftrag für den VSDD vorliegt, damit das Fachmodul den Prüfungsnachweis erstellen kann. Der Prüfungsnachweis dient als Nachweis einer durchgeführten Aktualisierungsanfrage der VSD. Das bedeutet, dass der UFS auch eine Prüfziffer sendet, wenn nur Aktualisierungsaufträge für das CMS vorliegen, z.B. zum Aktivieren der Gesundheitsanwendung. [VSDM-A_2287-*]

3.1.1 Request

Abbildung 3 – Element GetUpdateFlags

Tabelle 2: Tab_SST_FD_52 – Element GetUpdateFlags [VSDM-A_2310]

Tabelle 3: Tab_SST_FD_53 – Element Iccsn [VSDM-A_2310]

3.1.2 Request-Header

Damit ein Intermediär auf Nachrichtenebene eine Lokalisation des Fachdienstes vornehmen und der Fachdienst die Lokalisation prüfen kann, wird zusätzlich zu den fachlichen Daten das ServiceLocalization-Element gemäß [gemSpec_SST_VSDM] als SOAP-Header übertragen. Die Elemente des ServiceLocalization-Header müssen vom Fachmodul entsprechend der Tabelle 4 gesetzt werden. Die Werte des ServiceLocalization-Header müssen auf Korrektheit geprüft werden, damit von dem Intermediär fehlgeleitete Nachrichten erkannt und abgewiesen werden.

Tabelle 4: Tab_SST_FD_02 – Elemente des ServiceLocalization-Header für die Operation GetUpdateFlags [VSDM-A_2282] [VSDM-A_2283]

3.1.3 Response

Diese Response liefert eine Liste aller Update Flags zu einer bestimmten ICCSN. Die Reihenfolge der Update Flags in dieser Liste gibt die Reihenfolge vor, in der die zugehörigen Vorgänge angestoßen werden müssen.

Optionale Aktualisierungen sind derzeit nicht vorgesehen. Falls in der jetzigen Version optionale Aktualisierungen eingestellt werden, sollen diese ausgelassen werden (siehe hierzu das Element UpdatePriority). Für die tatsächlich angestoßenen, nicht optionalen Aktualisierungen ist die Reihenfolge aber bindend. [VSDM-A_2285] [VSDM-A_2286]

Alle in dieser Liste direkt hintereinander stehenden Update Flags zur gleichen Service-Localization müssen einzeln durch Aufrufe der Operation PerformUpdates durchgeführt werden.

Abbildung 4 – Element GetUpdateFlagsResponse

Tabelle 5: Tab_SST_FD_03 – Element GetUpdateFlagsResponse

Tabelle 6: Tab_SST_FD_04 - Element UpdateFlag

Tabelle 7: Tab_SST_FD_05 - Element ServiceReceipt

Abbildung 5 – Element UpdateFlag

Tabelle 8: Tab_SST_FD_06 – Element ServiceLocalization [VSDM-A_2288]

Tabelle 9: Tab_SST_FD_07 – Element UpdateId

Tabelle 10: Tab_SST_FD_08 – Element UpdatePriority

Tabelle 11: Tab_SST_FD_09 – Element ShortDescription

Abbildung 6 – Element ServiceLocalization

Tabelle 12: Tab_SST_FD_10 – Element Type [VSDM-A_2288]

Tabelle 13: Tab_SST_FD_11 – Element Provider [VSDM-A_2288]

Abbildung 7 – Element ServiceReceipt-Element

Tabelle 14: Tab_SST_FD_13 – Element ServiceLocalization [VSDM-A_2288]

Die Unterelemente Type und Provider sind bereits im Zusammenhang mit dem Element UpdateFlag beschrieben.

Tabelle 15: Tab_SST_FD_14 – Element Receipt [VSDM-A_2287-*]

3.2 Fehlerbehandlung

Die Beschreibung der Fehlerbehandlung und Struktur der gematik SOAP Faults erfolgt in der Spezifikation „Schnittstellenspezifikation Transport VSDM“ [gemSpec_SST_VSDM]. Für die hier beschriebene Schnittstelle der Anwendungsebene erfolgt lediglich die Festlegung der Fehlercodes auf Anwendungsebene (s. Tabelle 16).

Der ComponentType ist für alle an dieser Schnittstelle auftretenden, auch übergreifenden Fehlercodes gemäß [gemSpec_SST_VSDM], Fehler „UFS“. Da er für alle aufgeführten Fehlercodes gilt, wird er nicht extra pro Fehlercode angegeben. [VSDM-A_2329]

Tabelle 16: Tab_SST_FD_15 – Fehlercodes der UFS-Schnittstelle [VSDM-A_2290] [VSDM-A_2291] [VSDM-A_2292]

Für einen Fehler, der keinem bereits spezifizierten Fehlercode zugeordnet ist, soll der Fehlercode 11999 angegeben werden. Dieser Fehlercode soll nur in Ausnahmefällen verwendet werden.

Neben den in der Tabelle 16 aufgeführten Fehlercodes können die in der Tabelle 17 aufgeführten Fehlercodes vom Fachdienst verwendet werden, sofern das eingesetzte Webservice-Framework diesen Fehler nicht bereits erkennt und mit einem SOAP Fault darauf reagiert.

Tabelle 17: Tab_SST_FD_16 – Optionale Fehlercodes der UFS-Schnittstelle [VSDM-A_2293]

4 Card Communication Service

Erhält das Fachmodul ein oder mehrere Aktualisierungsaufträge (Update Flags), kann das Fachmodul diese Aktualisierungen über die Operation PerformUpdates der Schnittstelle CCS initiieren und durchführen. Beim ersten Aufruf übergibt das Fachmodul dem Dienst einen Update-Identifier (Bestandteil der Update Flags). Der Fachdienst ordnet den Update-Identifier dem durchzuführenden Vorgang zu. [VSDM-A_2294] [VSDM-A_2295]

Abbildung 8 – Darstellung der CCS-WSDL

Damit der Fachdienst die folgenden Nachrichten nach dem initiierenden Aufruf zuordnen kann, wird vom Dienst eine Sessioninformation erstellt und in der ersten Antwortnachricht an das Fachmodul übergeben. Diese Sessioninformation wird in den Aufrufen der Folgenachrichten angegeben. [VSDM-A_2297] [VSDM-A_2298]

Die Schnittstelle ermöglicht den Fachdiensten beliebige Kartenkommandos zur eGK zu senden. Zwischen dem Fachdiensten und der eGK wird ein Trusted Channel aufgebaut, über den die eigentliche Aktualisierung erfolgt. Aus diesem Grund wird für den Auf- und Abbau des Trusted Channels sowie für alle Aktionen innerhalb des Trusted Channels auf die Anwendung von zusätzlichen nachrichtenbasierten Sicherheitsmechanismen verzichtet. Der Ablauf zur Aktualisierung einer eGK wird in Kapitel 5 verdeutlicht. [VSDM-A_2302] [VSDM-A_2999]

Prinzipiell sollen die Fachdienste aus Performancegründen bei einer Aktualisierung der Stammdaten immer nur die VSD-Container aktualisieren, für die auch Änderungen vorliegen. Eine Ausnahme diesbezüglich besteht dann, wenn für die Aktualisierung des zu ändernden Containers eine neue Schemaversion verwendet wird. In diesem Fall müssen alle VSD-Container aktualisiert werden, um sicherzustellen, dass immer in allen drei VSD-Containern (PD, VD und GVD) die Daten in derselben Schemaversion vorliegen. [VSDM-A_2546]

Zum Abschluss einer erfolgreichen Aktualisierung der VSD erstellt der Fachdienst VSDD eine Prüfziffer, die vom Fachmodul in den Prüfungsnachweis aufgenommen wird. Der Prüfungsnachweis dient als Nachweis einer durchgeführten Aktualisierungsanfrage der VSD. Der Fachdienst CMS hingegen soll keine Prüfziffer erstellen, da das Fachmodul die Prüfziffer des CMS nicht nutzt. [VSDM-A_2341-*] [VSDM-A_2342]

Bei Änderung von Versichertenstammdaten muss der Fachdienst mit einem vorhergehenden Kommando den Transaktionsstatus auf der eGK auf ‚1’ setzen. Nach den Kommandos zum Ändern der Daten muss ein Kommando zum Zurücksetzen des Transaktionsstatus auf ‚0’ folgen. [VSDM-A_2961]

In der Tabelle 18 sind die allgemeinen Werte der Schnittstelle aufgeführt. Diese Werte werden unter anderem für die Kodierung der Endpunkt-Adresse der Schnittstelle verwendet.

Tabelle 18: Tab_SST_FD_17 – Allgemeine Werte der CCS Schnittstelle

4.1 Operation PerformUpdates

Die Operation PerformUpdates initiiert die Kommunikation zwischen Dienst und eGK. Durch die Übermittlung eines oder mehrerer Update-Identifier an den Dienst, wird beim Dienst der durchzuführende Vorgang angestoßen. In der Response zu dieser Operation wird vom Dienst bereits das erste Kommando-Paket angegeben. Die Chipkarten-Kommandos werden von dieser Spezifikation nicht beschränkt. Allerdings sind derzeit nur VSD-Aktualisierungen und die Sperrung der Gesundheitsanwendung vorgesehen (s. Kapitel 5).

4.1.1 Request

Abbildung 9 – Element PerformUpdates

Tabelle 19: Tab_SST_FD_18 – Element PerformUpdates [VSDM-A_2308]

Tabelle 20: Tab_SST_FD_19 – Element Iccsn [VSDM-A_2308]

Tabelle 21: Tab_SST_FD_20 – Element UpdateId [VSDM-A_2308]

Tabelle 22: Tab_SST_FD_21 – Element AdditionalInfo [VSDM-A_2308] [VSDM-A_2335] [VSDM-A_2314]

4.1.2 Request-Header

Damit  der Fachdienst die Lokalisierung durch den Intermediär prüfen kann, wird das ServiceLocalization-Element gemäß [gemSpec_SST_VSDM] im SOAP-Header übertragen. Die Elemente des ServiceLocalization-Header müssen entsprechend der Tabelle 23 gesetzt werden.

Tabelle 23: Tab_SST_FD_22 – Elemente des ServiceLocalization-Header der Operation PerformUpdates [VSDM-A_2303] [VSDM-A_2305]

4.1.3 Response

Die Response enthält für alle abgeschlossenen Aktualisierungsvorgänge eine Liste von UpdatePerformed-Elementen, welche die erfolgreiche Durchführung der Updates bestätigen, und das Element CommandPackage mit Chipkartenbefehlen zur Durchführung einer weiteren Aktualisierung der eGK. Sind alle Aktualisierungen abgeschlossen, enthält die Response anstelle des Elements CommandPackage das Element Close. [VSDM-A_2317]

Abbildung 10 – Element PerformUpdatesResponse

Tabelle 24: Tab_SST_FD_23 – Element PerformUpdatesResponse

Tabelle 25: Tab_SST_FD_24 – Element UpdatePerformed [VSDM-A_2315]

Tabelle 26: Tab_SST_FD_25 – Element CommandPackage [VSDM-A_2316]

Tabelle 27: Tab_SST_FD_26 – Element Close

Abbildung 11 – Element UpdatePerformed

Tabelle 28: Tab_SST_FD_27 – Element UpdateId [VSDM-A_2315]

Tabelle 29: Tab_SST_FD_50 – Element Receipt [VSDM-A_2341-*] [VSDM-A_2315]

Tabelle 30: Tab_SST_FD_28 – Element AdditionalInfo [VSDM-A_2315]

Abbildung 12 – Element CommandPackage

Tabelle 31: Tab_SST_FD_29 – Attribut LastIfOk [VSDM-A_2339] [VSDM-A_2316]

Tabelle 32: Tab_SST_FD_30 – Element CommandItem [VSDM-A_2316]

Abbildung 13 – Element CommandItem

Tabelle 33: Tab_SST_FD_31 – Element Command [VSDM-A_2318] [VSDM-A_2316]

Tabelle 34: Tab_SST_FD_32 – Element StatusCodeExpected [VSDM-A_2316]

4.1.4 Response-Header

In der Response ist die Sessioninformation gemäß [gemSpec_SST_VSDM] im SOAP-Header zu übertragen. Das Element des SessionIdentifier-Headers muss entsprechend der Tabelle 35 gesetzt werden.

Tabelle 35: Tab_SST_FD_33 – Elemente des SessionIdentifier-Header der Operation PerformUpdates

4.2 Operation GetNextCommandPackage

Das Fachmodul fordert mit der Operation GetNextCommandPackage ein weiteres Kommando-Paket für die eGK an. Vor der ersten Ausführung dieser Operation MUSS die Operation PerformUpdates ausgeführt worden sein.

Im Request für diese Operation werden dem Fachdienst die letzten Antworten der Chipkarte mitgeliefert. Diese Operation MUSS solange wiederholt abgesetzt werden bis vom Dienst durch die Übermittlung des Elements Close in der Response bestätigt wird, dass alle Aktualisierungen beendet sind.

4.2.1 Request

Im Request werden alle Antworten der eGK zu allen ausgeführten Kommandos aus dem letzten Kommando-Paket sequentiell aufgelistet. Liefert die eGK bei der Ausführung der Kommandos eines Kommando-Paketes einen unerwarteten Status-Code zurück, werden keine weiteren Kommandos aus dem Kommando-Paket ausgeführt. In einem solchen Fall, werden alle Antworten, der bis dahin erfolgreich ausgeführten Kommandos einschließlich des Kommandos, bei dem der Statuscode ungleich dem erwarteten Statuscode war, zurückgeliefert. [VSDM-A_2552] [VSDM-A_2553]

Ein Sonderfall bildet hier der Response-Code "63 Cx". Er ist für die Abarbeitung durch das Fachmodul wie ein "90 00" zu betrachten, sollte aber in der Response an den Fachdienst zurückgegeben werden. Die Abarbeitung der Kommando-Pakete wird hier nicht abgebrochen. [VSDM-A_2552]

Wenn die Verbindung zur eGK abbricht, wird hinter dem letzten Element CommandResponse das Element Abort angegeben. Konnte vorher kein Kommando ausgeführt werden, wird nur das Element Abort angegeben. [VSDM-A_3008]

Abbildung 14 – Element GetNextCommandPackage

Tabelle 36: Tab_SST_FD_34 – Element GetNextCommandPackage [VSDM-A_2311]

Tabelle 37: Tab_SST_FD_35 – Element CommandResponsePackage [VSDM-A_2311]

Abbildung 15 – Element CommandResponsePackage

Tabelle 38: Tab_SST_FD_36 – Element CommandResponse [VSDM-A_2311]

Tabelle 39: Tab_SST_FD_37 – Element Abort [VSDM-A_2311] [VSDM-A_3009]

Abbildung 16 – Element Abort

Tabelle 40: Tab_SST_FD_38 – Attribut CommandSentToCard [VSDM-A_2311]

4.2.2 Request-Header

Damit ein Intermediär auf Nachrichtenebene eine Lokalisierung des Fachdienstes vornehmen und der Fachdienst die Lokalisierung prüfen kann, wird zusätzlich zu den fachlichen Daten das ServiceLocalization-Element gemäß [gemSpec_SST_VSDM] als SOAP-Header übertragen. Die Elemente des ServiceLocalization-Header müssen entsprechend der Tabelle 41 gesetzt werden.

Tabelle 41: Tab_SST_FD_39 – Elemente des ServiceLocalization-Header der Operation GetNextCommandPackage [VSDM-A_2321] [VSDM-A_2305]

Ebenfalls in dem Request muss das SessionInformation-Element gemäß [gemSpec_SST_VSDM] als SOAP-Header übertragen werden. Das Element des SessionInformation-Header müssen entsprechend der Tabelle 42 gesetzt werden.

Tabelle 42: Tab_SST_FD_40 – Elemente des SessionInformation-Header der Operation GetNextCommandPackage [VSDM-A_2321] [VSDM-A_2322]

4.2.3 Response

Abbildung 17 – Element GetNextCommandPackageResponse

Die Response entspricht der Response der Operation PerformUpdates. Die Beschreibung der Response-Elemente erfolgt in dem Kapitel 4.1.3. [VSDM-A_2334]

4.3 Fehlerbehandlung

Die genaue Beschreibung der Fehlerbehandlung erfolgt in dem Dokument „Schnittstellenspezifikation Transport VSDM“ [gemSpec_SST_VSDM]. Für die hier beschriebene Schnittstelle erfolgt lediglich die Festlegung der sich aus der Schnittstelle ergebenen Fehlercodes (s. Tabelle 43).

Der ComponentType ist für alle an dieser Schnittstelle auftretenden, auch übergreifenden Fehlercodes gemäß [gemSpec_SST_VSDM], Fehler „CCS“. Da er für alle aufgeführten Fehlercodes gilt, wird er nicht extra pro Fehlercode angegeben. [VSDM-A_2328]

Tabelle 43: Tab_SST_FD_41 – Fehlercodes der CCS-Schnittstelle [VSDM-A_2323] [VSDM-A_2324] [VSDM-A_2325] [VSDM-A_2326] [VSDM-A_2327]

Ist für die Befüllung des Details-Elements die Angabe des Update-Identifier gefordert, muss das Element Detail eine Fehlermeldung im Format „plain“ enthalten, in der dieser Update-Identifier angegeben ist. Dieser Update-Identifier muss derjenige sein, zu dem der zugehörige Aktualisierungsvorgang nicht erfolgreich abgeschlossen werden konnte. [VSDM-A_2331]

Für einen Fehler, der keinem bereits spezifizierten Fehlercode zugeordnet ist, muss der Fehlercode 12999 angegeben werden. Dieser Fehlercode soll nur in Ausnahmefällen verwendet werden.

Bei "Fehlern", die mittels weiterer Command-Packages behoben werden können, darf keine Fehlermeldung vom Fachdienst erzeugt werden, sondern es müssen stattdessen die entsprechenden weiteren CommandPackage-Elemente übertragen werden. [VSDM-A_2332]

Neben den in der Tabelle 43 aufgeführten Fehlercodes können die in der Tabelle 44 aufgeführten Fehlercodes vom Fachdienst verwendet werden, sofern das eingesetzte Webservice-Framework diesen Fehler nicht bereits erkennt und mit einem SOAP Fault darauf reagiert.

Tabelle 44: Tab_SST_FD_42 – Optionale Fehlercodes der CCS-Schnittstelle [VSDM-A_2333]

5 Kommandosequenzen (informativ)

Die Fachdienste steuern mittels der Kommandopakete, die innerhalb der Operationen PerformUpdates und GetNextCommandPackage übermittelt werden, die Verarbeitung von Aktualisierungen durch die eGK. Dem Fachmodul fällt nur die Aufgabe zu, die jeweiligen Kartenkommandos vom Fachdienst abzufragen, sie an die eGK weiterzuleiten und die jeweiligen Ergebnisse der Kartenkommandos an den Fachdienst zurückzuliefern. Der Fachdienst organisiert hierbei sowohl den Aufbau des Trusted Channels als auch das Schreiben auf die eGK.

In diesem Kapitel werden exemplarisch die notwendigen Kommandosequenzen für eine Aktualisierung der eGK aufgeführt. Dabei werden sowohl die Kommandosequenz zum Aktualisieren der VSD als auch zum Sperren der Gesundheitsanwendung betrachtet.

Es sollen so wenig wie möglich Kommandopakete pro Aktualisierung entsprechend den Möglichkeiten der Kartensysteme gesendet werden. Die hier angegebenen Sequenzen soll keine Implementierungsvorschrift darstellen. So ist es durchaus vorstellbar, die Anzahl der Kartenbefehle durch eine andere Gruppierung der Kommandopakete zu minimieren.

5.1 Ablauf

Abbildung 18 - Ablauf "Aktualisierung der eGK"

In der Tabelle 45 sind die in der Abbildung 18 dargestellten Schritte während der Aktualisierung der eGK weiter erläutert. Sofern in den jeweiligen Schritten Kartenbefehle bzw. die Antworten relevant sind, ist in der Spalte APDUs eine Referenz zu der Tabelle aufgeführt, die die Kartenbefehle bzw. Antworten enthält.

Wenn in der Beschreibung eines Schrittes auf einen fachdienstspezifischen Schlüssel verwiesen wird, so wird für diesen die allgemeine Abkürzung „CM“ verwendet. Die Abkürzung „CM“ umfasst dabei jeweils die drei verschiedenen Schlüssel CMS, VSD und VSDCMS. Somit umfasst z.B. die Bezeichnung SK.CM die Schlüssel SK.CMS, SK.VSD und SK.VSDCMS. Welcher dieser Schlüssel konkret in dem Ablauf eingesetzt wird hängt vom jeweiligen Kontext ab.

Tabelle 45: Ablauf „Aktualisierung der eGK“

5.2 Kartenkommunikation

In den nachfolgenden Tabellen ist beispielhaft die direkte Kartenkommunikation bei einer Aktualisierung der eGK zwischen Fachdienst und eGK aufgeführt. Die kursiv dargestellten Kommandos sind optional.

Tabelle 46: PerformUpdatesResponse (ManageSecurityEnvironment)

Das Kommando RP1_01 ist optional, da diese Initialisierung schon beim Zurücksetzen der Karte vorgenommen werden muss.

Das Kommando RP1_02 ist ebenfalls optional. Es ist nicht notwendig, wenn dem Fachdienst der Inhalt von EF.ATR schon bekannt ist. Anderenfalls jedoch ist es notwendig.

Wenn die eGK-Fähigkeiten um Extended Length und Größe des APDU Buffer bekannt sind, können auch die Kommandos RP1_03ff bereits unter Verwendung dieser Informationen codiert sein.

Anmerkungen:

Ein Auslesen der ICCSN (ReadBinary EF.GDO) ist nicht notwendig, da die ICCSN dem Fachdienst in der Anfrage mitgeteilt wird. Eine von der gesteckten eGK abweichende ICCSN deutet auf einen Fehler der dezentralen TI oder einen Angriff hin. Entsprechend selten tritt dieser Fall ein. Wenn er eintritt, wird dies jedoch beim Aufbau des Secure Messaging bemerkt, da die ICCSN in EF.GDO zur Berechnung der Schlüssel herangezogen wird, welche deshalb nicht zu den im Fachdienst hinterlegten Schlüsseln passen. (Dabei gilt die Annahme, dass die symmetrischen Schlüssel eGK-spezifisch sind)

Ein Auslesen des Transaktions-Flag (ReadBinary EF.StatusVD) ist nicht notwendig, da der VSDD den Status der VSD-Aktualisierung aus den Response-APDUs der eGK ermittelt.

Tabelle 47: GetNextCommandPackage 1

Die Antwort RQ2_01 ist optional. Sie wird nur erwartet, wenn das Kommando RP1_01 gesendet wurde (s. Tabelle 46).

Tabelle 48: GetNextCommandPackageResponse (MutualAuthenticate)

Tabelle 49: GetNextCommandPackage 2

Tabelle 50: GetNextCommandPackageResponse (Gesundheitsanwendung entsperren)

Tabelle 51: GetNextCommandPackageResponse (Gesundheitsanwendung sperren)

Tabelle 52: GetNextCommand Package (Gesundheitsanwendung ent-/sperren beendet)

Tabelle 53: GetNextCommandPackageResponse (Stammdaten aktualisieren)

Anmerkung:

Im ersten Kommando RP3_01 muss das Transaktions-Flag gesetzt werden. Im letzten Kommando RP3_05 muss das Transaktions-Flag zurückgesetzt werden. Die Anzahl und Reihenfolge der dazwischen stattfindenden Update-Kommandos ist abhängig vom jeweiligen Update. Es sollen auch nur die geänderten Dateien aktualisiert werden. Die Dateigröße von EF.GVD ist so gering, dass es möglich ist, den gesamten Dateiinhalt mit einem Kommando zu beschreiben.

Tabelle 54: GetNextCommand Package (Stammdaten Aktualisierung beendet)

Anmerkung:

Am Ende eines erfolgreichen Updates ist das Transaktions-Flag zurückgesetzt (‚0’).

6 VSDM - Strukturierte Prüfziffer

6.1 Übersicht

Im Feature "Abruf der E-Rezepte in der Apotheke nach Autorisierung" der Anwendung E-Rezept soll der Anwendungsfall "Onlineprüfung und -aktualisierung" der Anwendung Versichertenstammdatenmanagement (VSDM) genutzt werden, um die Versicherten-ID (10-stelliger unveränderlicher Anteil der Krankenversicherungsnummer (KVNR)) von der in der Apotheke gesteckten eGK zu ermitteln und an den E-Rezept-Fachdienst zu übermitteln, um die offenen E-Rezepte zur Versicherten-ID abzurufen.

Hierbei soll sichergestellt werden, dass der E-Rezept-Fachdienst prüfen kann, dass die Versicherten-ID nicht manipuliert wurde.

6.2 Standardablauf

Voraussetzung: Es existiert jeweils ein geteiltes Geheimnis (kryptographischer Schlüssel) zwischen einem Fachdienst-Betreiber VSDM und dem E-Rezept-Fachdienst. Dieses gemeinsame Geheimnis bildet die Grundlage für die HMAC-Sicherung der  Prüfziffer. Damit kann der E-Rezept-Fachdienst prüfen, ob der Prüfziffer unverändert ist.

Standardablauf:

1. Der Versicherte übergibt dem Apotheker seine eGK und autorisiert diesen damit für den Abruf der E-Rezepte des Versicherten.
2. Die eGK wird in der Apotheke in das eHealth-Kartenterminal gesteckt.
3. Das Apothekenverwaltungssystem (AVS) ruft die Operation ReadVSD am Konnektor mit den Parametern PerformOnlineCheck=true und ReadOnlineReceipt=true auf.
4. Das Fachmodul VSDM führt die Onlineprüfung und ggf. -aktualisierung durch.
5. Der Fachdienst VSDM (UFS oder VSDD/CMS) verwendet als fachliche Information für die Prüfziffer u.a. die KVNR und den aktuellen Zeitpunkt als Zeitstempel. Es wird mit dem betreiberspezifischen Geheimnis eine HMAC-Sicherung über die fachlichen Informationen erzeugt. Die fachliche Information bilden zusammen mit dem HMAC-Wert die Prüfziffer.
6. Das Fachmodul VSDM erstellt den Prüfungsnachweis und fügt die vom Fachdienst VSDM erhaltene Prüfziffer ein.
7. Das Fachmodul VSDM liefert im Response die Versichertenstammdaten und den Prüfungsnachweis an das AVS.
8. Das AVS ruft den E-Rezept-Fachdienst auf und übermittelt den Prüfungsnachweis.
9. Der E-Rezept-Fachdienst prüft die Integrität und Authentizität der Prüfziffer mittels des HMAC-Werts.
10. Der E-Rezept-Fachdienst verifiziert, ob der in der Prüfziffer enthaltene Zeitstempel in einem definierten Zeitfenster zum aktuellen Zeitpunkt liegt.
11. Der E-Rezept-Fachdienst übermittelt die einlösbaren E-Rezepte zur in der Prüfziffer übermittelten KVNR an das AVS.

6.3 Vorgaben rund um den HMAC-Sicherungsschlüssel

Hinweis: weitere Vorgaben zum HMAC-Schlüssel befinden sich in [gemSpec_Krypt#3.18 HMAC-Sicherung der Prüfziffer VSDM].

Hinweis: wenn nach einem HMAC-Schlüsselwechsel in dem E-Rezept-Fachdienst dieser neue HMAC-Schlüssel eingebracht worden ist und der alte HMAC-Schlüssel im E-Rezept-Fachdienst gelöscht wurde, dann haben alte HMAC-Schlüssel keinen Schutzbedarf bezüglich Vertraulichkeit mehr.

{
    "betreiberkennung": "A",
    "version": "1",
    "exp": "2024-02-01",
    "encrypted_key": "0160141038f2f9b772621c1cf1b9a71c44fcf24766999392b3d184
        950a78c04f444d130be1f4bebd52f5fb9d1897475cac910b4aecbb4855c2f8692ab0f2d165777486
        421f7cc26654aeb5cb192118a5cc677cfad855fdc8d77a106f0d198e1147863171866a1e7a80a19c
        e528c94eb3884e4be13c4aaaaa48e292f8a1",
    "hmac_empty_string": "5ce3ee26f9956e7ef200481a891341760579ddbf566ec9bd43346ef432c2c3cb"
}

Hinweis: Bei dem Schlüsselaustausch gibt es nur wenige Betreiber. Die beteiligten Personen sind der gematik bekannt. Ein verschlüsselter Schlüsselaustausch in seiner Organisation und bei der Prüfung der Export-Pakete an verschiedenen Punkten des Transports des Exports wird u. a. von den SDMs der gematik persönlich begleitet.

Die gematik stellt Beispiel-Code für die Erzeugung eines Export-Pakets bereit.

6.4 Aufbau der Prüfziffer

Hinweise:

Die Liste mit den Kennungen der Betreiber wird durch die gematik bereitgestellt.

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

Beispiel:

Sei:

• KVNR = "A123456789"
• die aktuelle Unix-Zeit (int(number of seconds since the epoch)) = 1673551622
  (Hinweis:
  $ echo 1673551622  | perl -nE 'say scalar localtime $_'
  Thu Jan 12 20:27:02 2023
  )
• Grund des Updates = "U"
• Kennung des VSDM-Fachdienst-Betreibers = "A"
• Version des HMAC-Schlüssels = "1"
• der zufällig erzeugte HMAC-Schlüssel des Betreibers (hexdump) = 

  3a8e0064436bf2dbe7ca41ec6f1ed60beec083bc4100633281eb397cb294391c

Dann ist die Bytefolge über die der HMAC berechnet wird: 

A1234567891673551622UA1

Diese Bytefolge ist 23 Byte lang. Darüber wird der HMAC-SHA-256 mittels des HMAC-Schlüssels berechnet und davon die ersten 24 Byte genommen (hexdump):

f5f1201426d5841fa4536c83c114be136fc39d56f95e98dd

Beide Zeichenfolgen (23 Byte + 24 Byte) konkateniert und anschließend per Base64 kodiert:

QTEyMzQ1Njc4OTE2NzM1NTE2MjJVQTH18SAUJtWEH6RTbIPBFL4Tb8OdVvlemN0=

Dies ist die Prüfziffer.

7 Anhang A - Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar_TI] zur Verfügung gestellt.

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

7.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 passende jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellsten, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

7.5.2 Weitere Dokumente

8 Anhang B - Anforderungshaushalt

8.1 Eingangsanforderungen

Tabelle 55: Eingangsanforderungen mit Nachweis der Abdeckung

8.2 Ausgangsanforderungen