gemSpec_SST_VSDM_V2.3.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Schnittstellenspezifikation

Transport VSDM

    

     

      
Version
      
2.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
14.05.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_SST_VSDM
     
    

Dokumentinformationen

Änderung zur Vorversion

Einarbeitung lt. Änderungsliste P15.4

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument spezifiziert die übergreifenden Anforderungen und die Meta-Informationen für die Transportschnittstelle zwischen den Fachdiensten VSDM (UFS, VSDD, CMS) und dem Fachmodul VSDM auf Nachrichtenebene. Ziel ist es für alle Fachdienste VSDM die übergreifenden Anforderungen zusammenzufassen und den Informationstransport von Meta-Informationen vorzugeben. Um die Komplexität der Transportschnittstelle auf Nachrichtenebene zu reduzieren, wird hierbei in Abstimmung mit den Kostenträgern vom Bestandsschutz abgewichen (s. Kapitel 1.6).

Die Abbildung 1 zeigt schematisch die Dokumentenhierarchie im Projekt VSDM, in welcher die Schnittstellenspezifikation Transport 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

Kapitel 2 enthält eine Zusammenfassung der übergreifenden Festlegungen, die unter Berücksichtigung allgemeingültiger Standards für die Kommunikation mit Diensten der Fachanwendung VSDM gelten.

Kapitel 3 stellt die Festlegungen für den Transport von Meta-Informationen dar. Es wird die Struktur der Daten beschrieben, sowie Festlegungen für die Einbindung bzw. Verwendung der Informationen getroffen.

Die Festlegungen zur Fehlerbehandlung und übergreifende Fehlercodes sind in Kapitel 4 aufgeführt und zu wesentlichen Teilen der Spezifikation Fehlerbehandlung [gemSpec_OM] aus Bestandsschutzgründen übernommen.

Kapitel 5 beschreibt ein einheitliches Performance-Berichtsformat für eine übergreifende Auswertung der Performance-Kennzahlen.

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 werden durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

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

1.4 Arbeitsgrundlagen

Grundlagen für die Ausführungen dieses Dokumentes sind

• Systemspezifisches Konzept Versichertenstammdatenmanagement (VSDM) [gemSysL_VSDM]
• Übergreifende Spezifikation Operations und Maintenance [gemSpec_OM]

1.5 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 Nachrichtenebene, die in diesem Dokument behandelt wird, zählen die Meta-Informationen (SOAP-Header).

Das Dokument [gemSpec_SST_FD_VSDM] spezifiziert die Schnittstelle zwischen den Fachdiensten VSDM und dem Fachmodul VSDM auf Anwendungsebene und bezieht sich auf den SOAP-Body.

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.6 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 mehr, 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 und die Standard SOAP-Struktur verwendet. Die Spezifikation der fachlichen Schnittstelle, wie sie im Dokument [gemSpec_SST_FD_VSDM] beschrieben ist, bleibt erhalten.

Abbildung 2: Schematischer Vergleich der SOAP-Struktur mit und ohne TTD

1.7 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 (Anforderungszusammenhang) dieses Dokuments werden in der Tabelle 16 die Eingangsanforderungen aufgelistet, die in diesem Ergebnisdokument berücksichtigt sind. In der Spalte "umgesetzt durch" finden sich die eindeutigen Referenzen auf die dazu erarbeiteten Umsetzungsanforderungen. In Anhang B2, Tabelle 17 stehen die Umsetzungsanforderungen mit ihrem Text und dem entsprechenden Vorgänger.

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

2 Allgemeine Festlegungen

2.1 Eingesetzte Standards

Um Interoperabilität zwischen verschiedenen SOAP-Implementierungen [SOAP1.1] zu gewährleisten, erfolgt die technische Umsetzung der Schnittstellen konform zum WS-I Basic Profile in der Version 1.2 [BasicProfile1.2]. [VSDM-A_2189] [VSDM-A_2241]

Die Fachdienstschnittstellen werden in Form von WSDL [WSDL1.1] und XML-Schemas definiert. Gemäß dem WS-I Basic Profile muss für die Definition die Web Services Description Language (WSDL) in der Version 1.1 verwendet werden. Die aus der WSDL resultierende Nachricht muss dem Simple Object Access Protocol (SOAP) in der Version 1.1 entsprechen und die Übertragung erfolgt mittels des Hypertext Transfer Protocols (HTTP) in der Version 1.1.

Die WSDL-Dateien und XML-Schemadateien müssen neben den fachdienstspezifischen Schnittstellenspezifikationen zur Verfügung gestellt werden, um eine einfache Implementierung zu gewährleisten und eine maschinelle Prüfung der spezifizierten Elemente zu ermöglichen. Die in den WSDLs verwendete Kodierungsmethode der SOAP-Nachrichten muss „wrapped document/literal“ sein, um Interoperabilität zu gewährleisten. [VSDM-A_2243]

2.2 No Pipelining

Um Abhängigkeiten zwischen verschiedenen Requests des Fachmoduls zu vermeiden, darf das Fachmodul in der Kommunikation zum Intermediär kein Pipelining verwenden. Parallelität von Requests vom Fachmodul an den Intermediär VSDM kann ohne Pipelining über mehrere HTTP-connections erreicht werden. [VSDM-A_3066]

Der Intermediär darf beim Verbindungsaufbau zu einem Fachdienst kein Pipelining verwenden. Die einzelnen Request/Reply-Paare dürfen sich nicht beeinflussen. Eine HTTP-connection wird daher zu einem Zeitpunkt immer nur für ein Request/Reply-Paar verwendet. [VSDM-A_3021]

Abbildung 3: Vergleich no-pipelining vs. pipelining

2.3 Connection pooling durch den Intermediär

Der Aufbau einer HTTP-connection vom Intermediär zum Fachdienst ist zeitaufwendig. Um Verzögerungen bei der Abarbeitung eines Aufrufs vom Fachmodul zu minimieren, wird die HTTP-connection nicht für jedes Request/Reply-Paar neu aufgebaut. Der Intermediär hält dauerhaft HTTP-connections zu den Fachdiensten offen. Jede HTTP-connection kann nacheinander für mehrere Request/Reply-Paare genutzt werden.

Der Intermediär muss zu jedem Fachdienst (UFS, VSDD und CMS) einen permanenten Pool von jeweils 5 HTTP-connections halten. Dieser Wert muss konfigurierbar sein. Wenn eine der permanenten Verbindungen, z.B. durch einen Fehler, abgebaut wird, dann muss der Intermediär die Verbindung innerhalb einer Zeit von höchstens 1s wieder aufbauen. [VSDM-A_3022]

Der Intermediär muss die Verarbeitung der Anfragen von Fachmodulen und die Verwaltung der HTTP-connections im eingeschwungenen Zustand im Rahmen seiner Bearbeitungszeit erledigen. Zwei Request/Reply-Paare, die auf Anwendungsebene zur gleichen Conversation gehören, können über verschiedene HTTP-connections übertragen werden.

Sollten die permanenten Verbindungen bei Lastspitzen nicht ausreichen, muss der Intermediär zusätzliche Verbindungen etablieren, die dann nach Bedarf wieder geschlossen werden [VSDM-A_3023] [VSDM-A_3028].

Wenn der Fachdienst beim Aufbau der Verbindungen nicht erreichbar ist, dann soll der Intermediär das Connection pooling für einen Zeitraum aussetzen, bis der Fachdienst wieder erreichbar ist. Wird während dieser Phase vom Fachmodul ein Request an den Fachdienst gestellt, dann muss der Intermediär versuchen, eine Verbindung zum Fachdienst aufzubauen.

Werden mehrere Fachdienste an einem Endpunkt (FQDN:Port) betrieben, dann kann der Intermediär einen gemeinsamen Pool mit der aufaddierten Anzahl der permanent je Fachdienst zu haltenden HTTP-connection aufbauen und verwalten. Innerhalb des aggregierten Pools muss technisch nicht nach den Fachdiensten unterschieden werden.

Abbildung 4: Beispiel für den Connection-Pool des Intermediärs

2.4 Transportsicherung

Zur Absicherung der Datenübertragung muss der Transport der SOAP-Nachrichten mittels HTTPS erfolgen. Abweichend von [BasicProfile1.2] ist Transport Layer Security (TLS) gemäß den Vorgaben des [gemSpec_Krypt#3.3.2] einzusetzen. Dies gilt sowohl für die Strecke zwischen der dezentralen TI und dem Intermediär VSDM, als auch für die Strecke zwischen dem Intermediär und dem Fachdienst. [VSDM-A_3001] [VSDM-A_3002] [VSDM-A_3003]

Da der Verbindungsaufbau in der Regel ein zeitaufwändiger Vorgang ist, sollen die Verbindungen für einen konfigurierbaren Zeitraum offen gehalten werden. Wenn dennoch Verbindungen erneut aufgebaut werden müssen, soll für die Verbindung zwischen Fachmodul und Intermediär VSDM das Session-Resumption-Verfahren verwendet werden, um eine Session ohne Neuaushandlung der Parameter fortführen zu können. [VSDM-A_2225] [VSDM-A_2226] [VSDM-A_3026]

2.4.1 Transportsicherung zwischen Fachmodul und Intermediär

Beim Verbindungsaufbau zwischen Fachmodul und Intermediär authentisiert sich das Fachmodul mit C.HCI.AUT Zertifikats des SM-B gegenüber dem Intermediär und der Intermediär mit seinem TLS-Server-Zertifikat (C.FD.TLS-S) gegenüber dem Fachmodul. [VSDM-A_2227] [VSDM-A_2194]

Das Fachmodul kann als Ablaufumgebung den Konnektor oder die KTR-AdV nutzen, wobei sich diese in ihrem technischen Ansatz unterscheiden.

Im Konnektor baut das Fachmodul mit Hilfe des technischen Use Cases (TUCs) des Konnektors TUC_KON_110 "Kartenbasierte TLS-Verbindung aufbauen" die TLS-Verbindung mit dem Intermediär auf. Der TUC_KON_110 wird mit CardSession der entsprechenden SM-B und URI des Intermediärs als Parameter aufgerufen. Der TUC führt die Prüfung des TLS-Server-Zertifikats des Intermediärs durch (siehe [gemSpec_Kon]).

In der KTR-AdV baut der serverseitige Anteil des Fachmodules mit Hilfe der Plattformleis-tung PL_TUC_TLS_SECURE_CHANNEL die TLS-Verbindung mit dem Intermediär auf. PL_TUC_TLS_SECURE_CHANNEL wird mit der URI des Intermediärs und dem Rollen-bezeichner oid_int_vsdm als Parameter aufgerufen. Die Plattformleistung führt die Prüfung des TLS-Server-Zertifikats des Intermediärs durch (siehe [gemSpec_KTR-AdV]).

Der Intermediär prüft beim Verbindungsaufbau das Client-Zertifikat des Fachmoduls entsprechend der Vorgaben von [gemSpec_PKI] bez. des TLS-Verbindungsaufbaus mit den in Tabelle 1 aufgezählten Parametern. Die OID-Werte sind [gemSpec_OID] festgelegt.

Tabelle 1: Tab_SST_VSDM_62 – Eingangsdaten für die Prüfung des Fachmodul Client-Zertifikats [VSDM-A_2228]

Der TUC gibt neben dem Status der Zertifikatsprüfung auch die im Zertifikat enthaltene Rolle (Admission) zurück. Diese müssen in der Liste der vorgesehenen Rollen enthalten sein. [VSDM-A_3027]

Tabelle 2: Tab_SST_VSDM_65 – Zulässige Rollen bei Prüfung des Fachmodul Client-Zertifikats [VSDM-A_2228]

2.4.2 Transportsicherung zwischen Intermediär und Fachdienst

Beim Verbindungsaufbau zwischen Intermediär und Fachdienst authentisiert sich der Intermediär mit seinen TLS-Client-Zertifikat (C.FD.TLS-C) gegenüber dem Fachdienst und der Fachdienst mit seinem TLS-Server-Zertifikat (C.FD.TLS-S) gegenüber dem Intermediär. [VSDM-A_2253] [VSDM-A_2222]

Der Intermediär prüft beim Verbindungsaufbau das Server-Zertifikat des Fachdienstes entsprechend der Vorgaben von [gemSpec_PKI] bez. des TLS-Verbindungsaufbaus mit den in Tabelle 3 aufgezählten Parametern. Die OID- Werte sind [gemSpec_OID] festgelegt.

Tabelle 3: Tab_SST_VSDM_63 – Eingangsdaten für die Prüfung des Fachdienste Server-Zertifikats [VSDM-A_2223]

Der TUC gibt neben dem Status der Zertifikatsprüfung auch die im Zertifikat enthaltene Rolle (Admission) zurück. Diese müssen in der Liste der vorgesehenen Rollen enthalten sein. [VSDM-A_3027]

Tabelle 4: Tab_SST_VSDM_66 – Zulässige Rollen bei Prüfung des Fachdienste Server-Zertifikats [VSDM-A_2223]

Der Fachdienst prüft beim Verbindungsaufbau das Client-Zertifikat des Intermediärs entsprechend der Vorgaben von [gemSpec_PKI] bez. des SSL-Verbindungsaufbaus mit den in Tabelle 5 aufgezählten Parametern. Die OID- Werte sind [gemSpec_OID] festgelegt.

Tabelle 5: Tab_SST_VSDM_64 – Eingangsdaten für die Prüfung des Intermediär Client-Zertifikats [VSDM-A_2254]

Der TUC gibt neben dem Status der Zertifikatsprüfung auch die im Zertifikat enthaltene Rolle (Admission) zurück. Diese müssen in der Liste der vorgesehenen Rollen enthalten sein. [VSDM-A_3027]

Tabelle 6: Tab_SST_VSDM_67 – Zulässige Rollen bei Prüfung des Intermediär VSDM Client-Zertifikats [VSDM-A_2254]

2.5 Transport-Komprimierung

Um die Menge der zu übertragenen Daten zu reduzieren und damit die Antwortzeiten zu verbessern, ist es sinnvoll, die Daten für den Transport zu komprimieren. Das Fachmodul und die Fachdienste müssen eine HTTP-Komprimierung [HTTP1.1-sec3] unterstützen.

Das Fachmodul muss die Unterstützung der Komprimierung den Fachdiensten über das HTTP-Header-Feld Accept-Encoding mitteilen. Im Request muss das HTTP-Header-Feld Accept-Encoding mit den unterstützen Kompressions-Algorithmen angeben werden. Es muss mindestens der gzip-Algorithmus unterstützt werden. [VSDM-A_2200] [VSDM-A_2255]

Eine Komprimierung des ersten Requests darf derzeit nicht erfolgen, da eine Komprimierung dieser Nachricht erst durchgeführt werden kann, wenn sichergestellt ist, dass alle Fachdienste eine solche Nachricht verarbeiten könnten. Die Fachdienste sollen mit dem angegebenen Kompressions-Algorithmus aus dem HTTP-Header-Feld Accept-Encoding die Response für den Transport komprimieren. Auch die Fachdienste sollen so umgesetzt werden, dass sie komprimierte Nachrichten vom Fachmodul verarbeiten können. [VSDM-A_2199] [VSDM-A_2256]

2.6 Nachrichtenerzeugung

Der Sender muss valide SOAP-Nachrichten konform der WSDL bzw. der XSDs der aufgerufenen SOAP-Schnittstelle erzeugen. Es sind nur die in der fachdienstspezifischen WSDL-Datei definierten Header-Elemente erlaubt. Zusätzliche Header-Elemente (z.B. WS-Addressing-Header) sind verboten. [VSDM-A_2190] [VSDM-A_2242] [VSDM-A_2202] [VSDM-A_2262]

Die Nachrichten sollen keine Whitespaces zwischen einzelnen Elementen enthalten, da durch diese die Nachrichtengröße unnötig erhöht wird. Zudem schränken Whitespaces bei signierten Nachrichten die Interoperabilität ein. Signierte Nachrichten sind im derzeitigen Projektumfang zwar nicht enthalten, könnten aber zukünftig relevant werden. Daher ist es durchaus sinnvoll, bereits jetzt darauf zu achten, dass das eingesetzte Framework keine überflüssigen Whitespaces erzeugt. [VSDM-A_2203] [VSDM-A_2261]

2.7 Nachrichtverarbeitung

Jede Komponente, die Nachrichten auf SOAP-Ebene verarbeitet, muss im Zuge der Verarbeitung die Nachricht gegen die WSDL und den zugehörigen XSDs validieren. Das transparente Weiterleiten von Nachrichten wird nicht als Nachrichtenverarbeitung verstanden. Nicht zu der WSDL bzw. dem XSD valide Nachrichten müssen mit einer Fehlermeldung zurückgewiesen werden. [VSDM-A_2205] [VSDM-A_2257] [VSDM-A_2204] [VSDM-A_2231] [VSDM-A_2263]

Neben der Schemavalidierung muss die nachrichtenverarbeitende Komponente auch die Inhalte aller zur Verarbeitung benötigten Elemente auf zulässige Werte validieren. Es ist eine Fehlertoleranz gegenüber nicht verarbeiteten Elementen erlaubt, es sei denn, die Validierung dieser Elemente ist explizit durch eine Anforderung aus z.B. Sicherheitsgründen gefordert. [VSDM-A_2206] [VSDM-A_2258] [VSDM-A_2312] [VSDM-A_2313]

Das XML-Schema für SOAP-Nachrichten erlaubt im Standard zusätzliche Elemente im Header und Body, wobei der Sender einer Nachricht nur die spezifizierten Elemente verwenden darf. Der Empfänger einer Nachricht ist nicht verpflichtet auf unzulässige, zusätzliche Elemente zu prüfen, da nur getestete und zugelassene Komponenten zum Betrieb in der TI aufgenommen werden. Damit muss der Hersteller eines Produkttyps keine Prüfungen implementieren, um unzulässige Elemente zu erkennen. [VSDM-A_2207] [VSDM-A_2259]

Die Reihenfolge der Header-Elemente in der Nachricht muss für die verarbeitende Komponente unerheblich sein. [VSDM-A_2208] [VSDM-A_2260]

2.8 Nachrichtenweiterleitung durch den Intermediär

Der Intermediär VSDM muss für alle HTTP Nachrichten [HTTP 1.1]

• den HTTP payload body und
• end-to-end HTTP message header

unverändert zwischen Fachmodul und Fachdienst weiterleiten.

Die hop-by-hop Header (z.B. Transfer-Encoding, Connection) sind davon nicht betroffen. Sie werden vom Intermediär VSDM so gesetzt, wie für die Kommunikation zwischen Fachmodul und Intermediär sowie zwischen Intermediär und Fachdienst notwendig. [VSDM-A_2233]

Der Intermediär VSDM muss das HTTP Header-Field „Via“ in jeder weitergeleiteten Nachricht (Request-, Response- und Fehlernachricht) gemäß [HTTP1.1] setzen oder ergänzen. [VSDM-A_2271]

Der Intermediär DARF NICHT HTTP Header Informationen gemäß [RFC7239] ergänzen, die den Konnektor eindeutig identifizieren. [VSDM-A_3068]

2.9 Lokalisierung durch den Intermediär

Damit der Intermediär VSDM eine Lokalisierung des Fachdienstes ausschließlich anhand der Endpunkt-Adresse ohne Verarbeitung der SOAP-Nachricht durchführen kann, muss das Fachmodul die Lokalisierungsinformationen in die Endpunkt-Adresse aufnehmen.

Die Endpunkt-Adresse wird gebildet, in dem über eine konfigurierbare interne Zuordnungstabelle oder Service-Discovery der feste Bestandteil der Adresse ermittelt wird. Der feste Bestandteil besteht aus scheme, authority und Prefix des path. Der restliche Bestandteil wird dynamisch durch das Fachmodul gebildet. Die Endpunkt-Adresse ist entsprechend der Tabelle 7 aufgebaut.

Tabelle 7: Tab_SST_VSDM_01 Kodierung der Endpunkt-Adresse [VSDM-A_2209] [VSDM-A_2234]

Das Fachmodul muss sicherstellen, dass die Trennzeichen zwischen den einzelnen Werten korrekt gesetzt sind. In Abbildung 5 ist anhand einer Beispiel Endpunkt-Adresse die Kodierung exemplarisch dargestellt. [VSDM-A_2235]

Abbildung 5: Beispiel Endpunkt-Adresse

3 Meta-Informationen

3.1 Allgemeine Festlegungen

Bei der Definition der Schnittstelle mittels der WSDL wird festgelegt, welche Meta-Informationen zusammen mit den Fachdaten in den Nachrichten übertragen werden. So kann ein Request bzw. Response keine, eine oder mehrere Meta-Informationen zusätzlich zu den fachlichen Daten enthalten.

Es werden in dieser Spezifikation Elemente für die Meta-Information definiert, die für die Fachdienste VSDM relevant sind. Für die Schnittstellen selbst können innerhalb der jeweiligen Schnittstellenspezifikation auch noch weitere Elemente definiert werden. Die aufgeführten Elemente sind in der XSD [CMCommon.xsd] spezifiziert.

3.2 Lokalisierungsinformationen

Im Folgenden wird das Element definiert, welches die Lokalisierungsinformationen ServiceType und Provider-Kennung enthält. Die Information über die Schnittstellen-Version und den Operationsnamen ergeben sich bereits durch den Namespace und die SOAP-Operation der SOAP-Nachricht.

Dieses Header-Element verwendet der Fachdienst, um die korrekte Lokalisierung durch den Intermediär zu validieren und fehlgeleitete Nachrichten abzuweisen. Das Fachmodul muss deswegen nicht nur die Endpunkte, wie in Kapitel 2.9 beschrieben, kodieren, sondern auch die Felder im Header der Request-Nachricht korrekt setzen.

Abbildung 6: Element ServiceLocalization

Tabelle 8: Tab_SST_VSDM_02 – Element ServiceLocalization [VSDM-A_2211]

Tabelle 9: Tab_SST_VSDM_03 – Element Type [VSDM-A_2211]

Tabelle 10: Tab_SST_VSDM_04 – Element Provider [VSDM-A_2211]

3.3 Sessioninformation

Im Folgenden wird das Element definiert, welches es ermöglicht, eine Folge von zusammengehörigen Nachrichten zu korrelieren. Dafür wird innerhalb des Elements eine eindeutige Kennung der Session übertragen.

Abbildung 7: Element SessionIdentifier

Tabelle 11: Tab_SST_VSDM_05 – Element SessionIdentifier [VSDM-A_2212] [VSDM-A_2264]

Tabelle 12: Tab_SST_VSDM_06 - Element ConversationID [VSDM-A_2212] [VSDM-A_2264] [VSDM-A_2299] [VSDM-A_2301] [VSDM-A_2330]

4 Fehlerbehandlung

Für alle Fehler, die innerhalb der Nachrichtenverarbeitung auftreten, muss ein gematik SOAP Fault erzeugt werden. Die Struktur des gematik SOAP Fault ist in Kapitel 4.2 spezifiziert. Tritt der Fehler nicht auf Nachrichtenebene, sondern auf einer tieferen Ebene des OSI-Stacks auf (z.B. bei der HTTP-Übertragung oder TLS-Verbindungsaufbau), wird kein gematik SOAP Fault erzeugt. Der Fehler wird stattdessen auf der tieferen Protokollebene behandelt, auf der dieser Fehler aufgetreten ist. [VSDM-A_2214]

In der Fehlermeldung dürfen keine sicherheitsrelevanten Informationen enthalten sein (Stacktraces, Bezeichnung bzw. Version eingesetzter Basissoftware), die Außenstehenden Rückschlüsse auf Interna der Implementierung eines Services erlauben und für Angriffe genutzt werden könnten. [VSDM-A_2236] [VSDM-A_2266]

Bei Fehlern, die auf Ebene des HTTP-Protokolls außerhalb der Nachrichtenverarbeitung auftreten, soll der Fachdienst mit einer HTTP-Fehlermeldung antworten. Ist zum Beispiel die vom Intermediär aufgerufene URL falsch, soll der Fachdienst mit dem Code 504 – Not Found antworten. [VSDM-A_2279]

Bei Fehlerzuständen, die bereits durch das eingesetzte Webservice-Framework erkannt werden und bei denen das Framework mit einem „normalen“ SOAP Fault reagiert, ist es nicht notwendig einen gematik SOAP Fault zu erzeugen. Zu diesen Fehlerzuständen zählen: Verletzung des Schemas, Abweichungen von der technischen Schnittstellenbeschreibung (WSDL), fehlerhaftes Encoding oder unerwartet große Nachrichten. Der Fachdienst muss in solchen Fällen dennoch sicherstellen, dass der durch das Webservice-Framework erzeugte SOAP Fault keine Implementierungsdetails (z.B. Stacktraces, Bezeichnung oder Versionen eingesetzter Bibliotheken) enthält, die Außenstehenden Rückschlüsse auf Interna der Implementierung eines Services erlauben und für Angriffe genutzt werden könnten. [VSDM-A_2270]

Es soll bei der Spezifikation der Fehlercodes darauf geachtet werden, dass für solche Fehlerzustände, die bereits durch Webservice-Frameworks erkannt werden, keine eigenen gematik Fehlercodes definiert werden. Die Verwendung von SOAP Faults ohne gematik-Fehlerstruktur ist in diesen Fällen vorzuziehen, damit Hersteller die industrieüblichen Webservice-Frameworks nicht anpassen müssen und die Komplexität der Fachanwendung nicht unnötig erhöht wird. Die Empfänger von SOAP Faults müssen mit SOAP Faults umgehen können, unabhängig davon, ob sie die gematik-Fehlerstruktur enthalten oder nicht. [VSDM-A_2213]

Die Fachdienste müssen den Zugriff auf interne Logdateien ermöglichen. Der Zugriff auf Protokolldateien muss auf autorisierte Personen durch angemessene technische oder organisatorische Maßnahmen eingeschränkt werden. [VSDM-A_2958]

4.1 Intermediär (HTTP-Gateway)

Der Intermediär reicht Fehlermeldungen der Fachdienste unverändert weiter, wobei das HTTP Header-Field Via hinzugefügt oder, wenn es bereits enthalten ist, ergänzt wird. Das Fachmodul erkennt durch das Vorhandensein des Feldes Via im HTTP-Header, ob es sich um eine Fehlermeldung vom Fachdienst handelt. [VSDM-A_2215]

4.2 Struktur

Bei einem gematik SOAP Fault handelt es sich um eine Erweiterung des SOAP Faults gemäß [SOAP1.1] und [BasicProfile1.2], deren Vorgaben zu SOAP Faults normativ gelten. Die Struktur eines SOAP Faults und der Inhalt der Datenelemente bei einem gematik SOAP Fault sind in [gemSpec_OM#3.2.3] beschrieben. [VSDM-A_2269] [VSDM-A_2216]

Die Fehlermeldungen sollen in der verteilten Fachanwendung eindeutig einem Betreiber zuzuordnen sein. Das Feld Instance soll dafür genutzt werden, dass jeder Fachdienst eines Betreibers einen eindeutigen Wert erhält, der die zweifelsfreie Zuordnung von
SOAP Faults mit gematik-Fehlerstruktur zu einem Betreiber ermöglicht. Die Kombination aus EventID und LogReference muss für den Betreiber eine eindeutige Referenzierung des Fehlers in seiner Systemumgebung erlauben. [VSDM-A_2273]

Die Struktur des Error-Elements und der Inhalt der Datenelemente sind in [gemSpec_OM#3.2.1] beschrieben. Auch wenn das Schema mehrere Trace-Elemente zulässt, ist nur ein Trace-Element pro Fehlermeldung erlaubt. [VSDM-A_2272]

Die Werte für das Element Severity sind in [gemSpec_OM] beschrieben.Von der Fachanwendung VSDM wird nur der Wert Fatal genutzt.

Für generische Fehler müssen die Error-Elemente entsprechend der in [gemSpec_OM] dargestellten Tabelle Tab_Gen_Fehler befüllt werden. [VSDM-A_2955] [VSDM-A_2956]

4.3 Speicherung von HTTP- und SOAP-Nachrichten

Im Zusammenhang mit der Speicherung von HTTP- und SOAP-Nachrichten ist eine Betrachtung der Datensicherheit und die Umsetzung des Prinzips der Datensparsamkeit erforderlich.

Zur Umsetzung der Datensparsamkeit ist es notwendig, so wenige personenbezogene Daten wie möglich zu speichern und die benötigten Daten nur so lange wie nötig vorzuhalten. Im Kontext VSDM werden unter Umständen Nachrichten mit Personenbezug transportiert, daher sollen grundsätzlich keine Nachrichten gespeichert werden. [VSDM-A_2218]

In Fehlersituationen hingegen wird zur Fehleranalyse die fehlerverursachende Nachricht benötigt. Aus Datenschutzgründen darf aber der Intermediär keine personenbezogenen Daten speichern. Daher kann im Fehlerfall lediglich nur der HTTP-Header der fehlerverursachenden Nachricht im Fehlerprotokoll gespeichert werden. Wenn die fehlerverursachende HTTP-Nachricht die SOAP-Antwort des Fachdienstes transportiert, kann, zusätzlich zum HTTP-Header der fehlerverursachenden HTTP-Nachricht des Fachdienstes, der HTTP-Header der entsprechenden Anfragenachricht gespeichert werden. Fehlermeldungen dürfen keine personenbezogenen Daten enthalten und können demnach gespeichert werden, um im laufenden Betrieb Fehler zu erkennen und zu analysieren. [VSDM-A_2267] [VSDM-A_2217] [VSDM-A_2238] [VSDM-A_2268] [VSDM-A_2219] [VSDM-A_2240] [VSDM-A_2274] [VSDM-A_2674] [VSDM-A_2790]

Für die Speicherung der SOAP-Nachrichten müssen die Schutzbedarfe der Nachrichten bei der Konzeption der Datenspeicher für Nachrichten berücksichtigt werden (siehe [gemKPT_Sich_VSDM]).

4.4 Liste der Fehlercodes

In der Tabelle 13 und Tabelle 14 werden die Fehlercodes definiert, die übergreifend gelten und die im Zusammenhang mit den im Kapitel 3 beschriebenen Header-Elementen auftreten können. Für diese Fehlercodes wird der ComponentType nicht aufgeführt. Dieser Wert muss in der Schnittstellenspezifikationen Fachdienste (UFS/VSDD/CMS) festgelegt werden. Außerdem muss in dem Dokument die Definition der speziell an der jeweiligen Schnittstelle auftretenden Fehlercodes erfolgen. [VSDM-A_2902]

Tabelle 13: Tab_SST_VSDM_11 – Übergreifende Fehlercodes

Tabelle 14: Tab_SST_VSDM_12 – Fehlercodes bezogen auf die Header-Elementen

5 Performance-Evaluierung

Alle VSDM Produkttypen müssen Performance-Kennzahlen erfassen, in einem Performance-Protokoll protokollieren und in dem hier festgelegten Performance-Berichtsformat bereitstellen. Diese Kennzahlen sollen genutzt werden, um während der Testdurchführung und Erprobung sowie bei Bedarf selektiv im Produktivbetrieb die Performance-Kennzahlen zu erheben und auszuwerten. Um die Performance der Fachanwendung VSDM mit wenig Aufwand auswerten zu können, wird in diesem Kapitel ein einheitliches Format für die Auswertung der Performance-Kennzahlen beschrieben.

5.1 Performance-Berichtsformat

Um die automatisierte Auswertung von Performance-Kennzahlen zu erleichtern, wird das von [Perf4J] verwendete Format übernommen. Perf4J ist ein Satz von Utilitys, das ein Java Framework für die Protokollierung von Performance-Messungen beinhaltet sowie die Tools für die automatisierte Auswertung von Protokollen.

Die Einträge in Performance-Berichten müssen dem folgenden Format entsprechen:

INFO: start[$timestamp] time[$duration_in_ms] tag[$operation] message[$message],

mit

• $timestamp eine Unixzeit-Zeitstempel in Millisekunden,
• $duration_in_ms die gemessene Bearbeitungszeit einer Operation in Millisekunden,
• $operation die ausgeführte Operation des Produkttyps gemäß Tabelle 15
• $message eine Beschreibung der gemessenen Operation (dieser Feld ist optional).

Ein Beispiel vom Eintrag, der dem oben formulierten Format entspricht:

INFO: start[1000212390109] time[447] tag[UFS.GetUpdateFlags]

Tabelle 15: Tab_SST_VSDM_15 – Operationen des Performance-Berichts

Die Performanceprotokolle, die von den VSDM Produkttypen geführt werden, dürfen von dem beschriebenen Format abweichen und können herstellerspezifisch sein. Es muss aber sichergestellt werden, dass die originär erfassten Performance-Protokolle in das hier beschrieben Berichtsformat automatisiert überführt werden, bevor sie zur Auswertung übergeben werden. [VSDM-A_2951] [VSDM-A_2952]

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

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

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

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

6.5.2 Weitere Dokumente

7 Anhang B – Anforderungshaushalt

7.1 Eingangsanforderungen

Tabelle 16: Tab_SST_VSDM_13 – Eingangsanforderungen mit Nachweis der Abdeckung

7.2 Ausgangsanforderungen