Spezifikation TelematikTransport-Details - Gematik

Einführung der GesundheitskarteSpezifikationTelematikTransport-DetailsVersion: 1.6.0Revision: main/rel_main/rel_r2.3.x/9Stand: 27.06.2008Status:freigegebengematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 1 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDokumentinformationenÄnderungen zur VorversionEs sind in diesem Release nur eine Anzahl kleinerer Änderungen zur Klarstellung erfolgt.Mit Hinblick auf eine Abwärtskompatibilität zur Vorversion des Dokumentes sind keineÄnderungen vorgenommen worden, die die Änderung einer technischen Umsetzung erfordern.Im Einzelnen sind folgende Punkte geändert worden:• Klarstellung, dass für die Bereitstellung der SOAP-Operationen nur eine URL-Endpoint vorgesehen ist.• Die Inhalte aus Anhang A3 wurden größtenteils als Bestandteil des Sicherheitskonzeptes[gemSiKo] aufgenommen und aus diesem Dokument entfernt. ImRahmen der Übernahme wurden editorische Anpassungen vorgenommen, diesich allerdings nicht auf die Implementierung auswirken.• Klarstellung, dass bei einem gematik Fault nur das spezifizierte Fehlerelementvorhanden sein darf und keine zusätzlichen (Debugging) Informationen. Dies istbereits durch die Sicherheitsanforderungen definiert.• Transformation der ObjektId zum Zwecke des Transports ist nun in einem eigenenKapitel normativ definiert und kann von anderen Spezifikationen referenziert werden.• In der Dokumentenschnittstelle ist die Angabe der Interface Version durch Facharchitekturennicht mehr zulässig. Hier sind Änderungen in [gemSpec_VersNr] berücksichtigtworden.• Bei der Verwendung von Elementen (Abschnitt 5) wurden im Hinblick auf die perspektivischeNutzung von TTD in anderen Kontexten als nur zwischen Konnektor,Broker und Fachdienst die Formulierungen angepasst. Hier wird nunmehr vomErsteller, Absender, Intermediär und Empfänger anstatt von Konnektor, Brokerund Fachdienst gesprochen.Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert.Sofern ganze Kapitel eingefügt wurden, wurde zur besseren Lesbarkeit lediglich dieÜberschrift durch gelbe Markierung hervorgehoben.ReferenzierungDie Referenzierung in weiteren Dokumenten der gematik erfolgt unter:[gemSpec_TTD] gematik: Einführung der Gesundheitskarte -Spezifikation TelematikTransport-Detailsgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 2 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDokumentenhistorieVersion StandKap./SeiteGrund der Änderung, besondere HinweiseBearbeitung0.0.1 26.10.06 Neuerstellung gematik, AG10.0.5 02.01.07 Vollständige Überarbeitung der TransportSchnittstelle / WSDLgematik, AG10.9.0 02.03.07 vorgelegt zur Freigabe gematik1.0.0 02.03.07 freigegeben gematik1.0.8 25.04.07 Einarbeitung von Kommentare und Ergebnissenaus der Prototypenentwicklunggematik, AG11.1.0 04.05.07 freigegeben gematik1.1.2 04.06.074.64.8A1Aufnahme der Versionsinformationen in Anhang-AEinarbeitung kleiner ÄnderungenSpezifikation des Gültigkeitszeitraums vonNachrichten (Kap. 4.6)Aufnahme eines Abschnitts zum Tracing derTelematiknachricht (Kap. 4.8)Überarbeitung der Schemabeschreibung undEinarbeitung von AnmerkungenBeschreibung der Verwendung von Elementenin der Response NachrichtAufnahme der Versionsübersicht in AnhangA1Möglichkeit zum Versenden unsignierterNachrichtenAufnahme eines Hinweises auf die geplanteSpezifikation des Authentifizierungs- und Autorisierungsdienstesin den AnhangAufnahme eines Hinweises auf die geplanteSpezifikation der FehlermeldungenAnpassung des Schemas:Aufnahme eines optionalen wsu:Timestampin den Transport header für unsignierte Nachrichten.Aufnahme des Elementes Identifier als Erweiterungsmöglichkeitfür die Identifizierung einesVersicherten oder Heilberuflersgematik,CHG1.1.3 11.7.074.7Korrekturen an der Beschreibung des Schemas;Überarbeitung der Abwehr von Replaygematik,CHGgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 3 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsVersion StandKap./SeiteGrund der Änderung, besondere HinweiseBearbeitungA2wenn ObjektTickets vorhanden sind.1.4.5 06.03.08 5.2.2.3 Definition eines konfigurierbaren Timeouts fürConversationIDITS/AP, MRA1.5.0 11.03.08 freigegeben gematik20.03.08 Interface Version darf nicht mehr als den Anwendungsfallübergreifender Parameter in derDokumentenschnittstelle angegeben werden.ITS/AP08.04.08 4.10 Einführung einer formalen Definition für SignaturprüfungenITS/AP, MRA20.05.08Diverse Änderungen:ITS/AP, MRA• Klarstellung, dass nur eine URL-Endpointals Webservice-Schnittstelle vorgesehenist,• Bei gematik Fault darf nur ein GERRORals fault enthalten sein.• Klarstellung Beschreibung Component-Version• Definiton einer Transformation für Transportvon ObjektId• Entfernen Interface-Version aus Dokumentenschnittstelle5.1.2• Einarbeitung SRQ 074221.05.08 A3 Übernahme von Inhalten aus A3 nach [gem-SiKo]ITS/AP, CHG1.6.0 27.06.08 freigegeben gematikgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 5 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInhaltsverzeichnisDokumentinformationen.....................................................................................2Inhaltsverzeichnis................................................................................................61 Zusammenfassung .....................................................................................102 Einführung...................................................................................................112.1 Zielsetzung und Einordnung des Dokumentes............................................112.1.1 Begriffsdefinitionen im TelematikTransport..............................................122.1.1.1 TelematikTransport-Schnittstelle (Technische Schnittstelle für SOAP-Nachrichtentransport)...........................................................................................122.1.1.2 Dokumentschnittstelle für Facharchitekturen.......................................122.1.1.3 TelematikTransport-Adaptierung..........................................................132.2 Zielgruppe.......................................................................................................132.3 Geltungsbereich.............................................................................................142.4 Arbeitsgrundlagen..........................................................................................142.5 Abgrenzung des Dokumentes.......................................................................142.6 Methodik..........................................................................................................142.6.1 Verwendung von Schüsselworten............................................................142.6.2 Konventionen zur Kennzeichnung von offenen Punkte............................153 Anforderungen und Annahmen.................................................................163.1 Eingangsanforderungen................................................................................164 TelematikTransport-Adaptierung...............................................................184.1 Dokumentenschnittstelle...............................................................................204.1.1 Aufgabe und Motivation...........................................................................204.1.2 Details der Dokumentenschnittstelle........................................................214.1.3 Verwendung in den Dokumenten der Facharchitekturen.........................244.2 Nachrichtenverarbeitung durch Fachdienste...............................................264.3 Logischer Aufbau der SOAP-Nachrichtenstruktur.......................................304.3.1 SOAP-Header.........................................................................................314.3.1.1 TransportHeader..................................................................................314.3.1.2 TelematikHeader.................................................................................314.3.1.3 SecurityHeader....................................................................................324.3.2 SOAP-Body.............................................................................................324.4 Zuordnung der Parameter in die SOAP-Nachrichtenstruktur......................324.5 Anwendungsfall übergreifende Parameter der Facharchitekturen.............35gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 6 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.6 Auswahl von Brokersequenzen durch die Facharchitekturen....................364.7 Gültigkeitszeitraum von Nachrichten............................................................374.8 Gültigkeitszeitraum von Nachrichten mit ObjektTickets.............................384.9 Verhinderung von Replay-Attacken..............................................................394.9.1 Erneutes Senden einer bereits gesendeten Nachricht.............................394.9.2 Replay-Attacke auf die Signatur der Datenautorität.................................404.10 Prüfung von Signaturen........................................................................414.11 Validierung der Nachricht.....................................................................424.11.1 Allgemeine Anforderungen an die Validierung der Telematiknachrichten 424.11.2 Anforderungen an die Validierung der Telematiknachrichten durch dieFachdienste.............................................................................................................434.12 Tracing der Telematiknachricht............................................................444.12.1 Konnektor................................................................................................444.12.2 Zentrale Anwendungs- und Infrastrukturdienste.......................................444.12.3 Fachdienst...............................................................................................454.13 Fehlermeldungen im TelematikTransport............................................454.13.1 Generische SOAP-Faults........................................................................464.13.2 Fehler auf HTTP Verbindungsebene.......................................................475 Detaillierte Beschreibung der Nachrichtenstruktur.................................485.1 Übergreifende Festlegungen.........................................................................485.1.1 Verwendung von Prefixes........................................................................485.1.2 Transport von ObjektID als ID-Attribut.....................................................485.2 Beschreibung der einzelnen Elemente.........................................................495.2.1 Elemente des GTEL:TransportHeader.....................................................495.2.1.1 GTEL:TransportHeader.......................................................................495.2.1.2 GTEL:InterfaceVersion........................................................................505.2.1.3 GTEL:MessageTrace...........................................................................505.2.1.4 GTEL:Hop............................................................................................515.2.1.5 GTEL:Sequence..................................................................................525.2.1.6 GTEL:Name.........................................................................................525.2.1.7 GTEL:Time..........................................................................................535.2.1.8 GTEL:AuditID......................................................................................535.2.1.9 wsu:Timestamp...................................................................................545.2.2 Elemente des GTEL:TelematikHeader....................................................555.2.2.1 GTEL:TelematikHeader.......................................................................555.2.2.2 GTEL:MessageID (TelematikHeader)..................................................565.2.2.3 GTEL:ConversationID..........................................................................575.2.2.4 GTEL:Insurant.....................................................................................585.2.2.5 GTEL:Identifier....................................................................................595.2.2.6 GTEL:Pseudonym...............................................................................595.2.2.7 GTEL:IssuerDomain............................................................................605.2.2.8 GTEL:ProviderGroup...........................................................................615.2.2.9 GTEL:ServiceLocalization....................................................................625.2.2.10 GTEL:Type......................................................................................625.2.2.11 GTEL:Provider.................................................................................635.2.2.12 GTEL:InstanceRef...........................................................................63gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 7 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.2.13 GTEL:MessageType........................................................................645.2.2.14 GTEL:Component............................................................................655.2.2.15 GTEL:ComponentVersion................................................................655.2.2.16 GTEL:Operation...............................................................................665.2.2.17 GTEL:ConversationStatus...............................................................675.2.2.18 GTEL:RoleDataProcessor................................................................675.2.3 Elemente des wsse:Security Header.......................................................685.2.3.1 wsse:Security......................................................................................695.2.3.2 wsu:Timestamp...................................................................................705.2.3.3 wsse:BinarySecurityToken...................................................................715.2.3.4 ds:Signature........................................................................................715.2.4 Elemente des SOAP-Body......................................................................725.2.4.1 GTEL:Payload.....................................................................................735.2.4.2 GTEL:EncryptedKeys..........................................................................745.2.4.3 xenc:EncryptedKey..............................................................................755.2.4.4 GTEL:ObjectTickets.............................................................................765.2.4.5 GTEL:Ticket (Subelement von ObjectTickets und ServiceTickets).......765.2.4.6 GTEL:ServiceTickets...........................................................................775.2.4.7 GTEL:Certificates................................................................................785.2.4.8 GTEL:Parameter..................................................................................795.2.4.9 GTEL:Parameter[Encoding].................................................................795.2.4.10 GTEL:Name.....................................................................................805.2.4.11 GTEL:Value.....................................................................................815.2.4.12 GTEL:MessageID (Payload)............................................................815.2.4.13 wsu:Timestamp................................................................................825.2.4.14 ds:Signature.....................................................................................836 TelematikTransport WSDL.........................................................................856.1 Generelle Festlegungen und Begriffsdefinitionen.......................................856.1.1 Operationen.............................................................................................856.1.2 Parameter................................................................................................856.1.3 WSDL-Datei............................................................................................856.1.4 Schnittstelle.............................................................................................866.1.5 Versionsnummer und Namensraum........................................................866.1.6 SOAP-Action...........................................................................................866.1.7 Fehlerbehandlung....................................................................................866.1.8 Allgemeine Anforderungen an die SOAP-Nachricht.................................866.2 Spezifikation der TelematikTransport WSDL................................................876.2.1 Messages................................................................................................886.2.2 PortType..................................................................................................886.2.3 Binding....................................................................................................886.3 WS-Policy........................................................................................................896.3.1 Anwendung von Policies auf WSDL-Bestandteile....................................906.3.1.1 Binding Level Security Policy...............................................................906.3.1.2 Eingabe, Ausgabe und Fehler Policies................................................907 Ausgangsanforderungen............................................................................91Anhang A............................................................................................................92gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 8 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsA1 - Versionsübersicht.............................................................................................92A2 – Authentifizierung in Telematiknachrichten.....................................................93A2.1 – Authentifizierung des Datenbearbeiters........................................................94A2.2 – Authentifizierung der Datenautorität.............................................................96A3 – Autorisierungsprüfung.....................................................................................99A3.1 – Abbildung von Akteuren, Rollen und OIDs..................................................99A3.1 – Rollenbasierte Autorisierungsprüfung von Telematiknachrichten..................99A4 – Fehlercodes TelematikTransport...................................................................102Anhang B..........................................................................................................111B1 – Abkürzungsverzeichnis..................................................................................111B2 – Glossar............................................................................................................111B3 – Abbildungsverzeichnis...................................................................................111B4 – Tabellenverzeichnis........................................................................................112B5 – Referenzierte Dokumente...............................................................................113gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 9 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details1 ZusammenfassungZiel des TelematikTransports ist es, den für alle Facharchitekturen einheitlichen Informationstransportzwischen Konnektor, Broker und Fachdienst von der fachlichen Verwendungder Informationen zu entkoppeln.Für den online-basierten Nachrichtenaustausch zwischen Komponenten der TI wird einTelematik-Protokoll spezifiziert. Das Telematik-Protokoll stellt sich bezogen auf die zuübertragenen Datenstrukturen der einzelnen Facharchitekturen transparent dar. Die hiervorliegende Spezifikation legt ein fachdienst-übergreifendes Transportkonzept normativfest. Hierzu• spezifiziert das Dokument die Struktur der zum Datentransport verwendetenProtokollelemente (Spezifikation der Telematiknachricht),• definiert das Dokument, in welcher Form Facharchitekturen die Befüllung derTelematiknachricht durch Fachanwendungen spezifizieren müssen (Dokumentenschnittstelle),• spezifiziert das Dokument mögliche Sicherheitstoken, Sicherheitsdienste undSicherheitsmechanismen.Die technische Realisierung des Telematik-Protokolls erfolgt auf der Grundlage vonSOAP. Aufbauend auf dieser technologischen Festlegung beschreibt das Dokument dieSpezifikation der SOAP-Aufrufe.Jede Komponente innerhalb der Telematikinfrastruktur (Konnektor, Broker, Fachdienst)bedient sich der in diesem Dokument spezifizierten SOAP-Nachrichtenstruktur. Diesschafft die notwendige Voraussetzung zur Nutzung weiterer Fachdienstanwendungen,deren Fachdatenstrukturen und fachbezogenen Datenaustauschverfahren zum heutigenZeitpunkt noch nicht spezifiziert sind. Ziel ist es, mit der Bereitstellung einer einheitlichenTelematikTransport-Schnittstelle auf Transportebene eine hohe Interoperabilität für denNachrichtenaustausch zwischen den Komponenten zu gewährleisten.Die Schnittstellenbeschreibung des SOAP-basierten Transportdienstes erfolgt auf Grundlagevon [WSDL1.1] und dem Standard WS-Policy [WSP1.1].gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 10 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details2 Einführung2.1 Zielsetzung und Einordnung des DokumentesEine Einführung in die Ziele und Aufgaben der logischen Architektur des TelematikTransportserfolgt in der Gesamtarchitektur [gemGesArch]. Ausgehend von der Motivationfür die Entwicklung einer logischen Architektur wird dort eine übergreifende logischeSicht auf den Transportmechanismus definiert. Mit der Festlegung von SOAP als Protokollfür den Nachrichtenaustausch beschreibt die Gesamtarchitektur auch die logische Datenstrukturfür Transportdaten und deren logische Einbindung in die Mechanismen desSOAP-Protokolls.Abbildung 1: Einordnung der Spezifikation TelematikTransport-DetailsZiel des vorliegenden Dokumentes ist es, die durch die Gesamtarchitektur vorgegebeneTelematikTransport-Architektur und die sich hieraus ergebende Entkopplung zwischenFachlichkeit und Transport aufzunehmen und in eine Detailbeschreibung zu überführen(siehe Abbildung 1). Zusätzlich wurde die Beschreibung der für die Implementierung notwendigenSicherheitsdienste aufgenommen. Die Detailbeschreibung umfasst die Spezifikationder TelematikTransport-Schnittstelle wie auch die Feinspezifikation der SOAP-Nachrichtenstruktur.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 11 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details2.1.1 Begriffsdefinitionen im TelematikTransportWie in der Zusammenfassung erläutert, verfolgt das Dokument zwei Ziele. Es soll durchdie normative Vorgabe der Telematiknachricht-Datenstruktur technische Interoperabilitäterreicht werden und zusätzlich für Facharchitekturen die Komplexität des Transports reduziertwerden.Bei der Umsetzung dieser beiden Ziele hat sich an zwei Stellen der Begriff Schnittstelle instark abweichendem Kontext etabliert. Da die Verwendung des Begriffs Schnittstelle voneiner rein technischen Schnittstelle im üblichen Sinne abweicht, erfolgt in den nächstenbeiden Abschnitten eine Erläuterung der verwendeten Begriffe.2.1.1.1 TelematikTransport-Schnittstelle (Technische Schnittstelle für SOAP-Nachrichtentransport)Für die Implementierung des SOAP-basierten Nachrichtenaustausches zwischen Telematik-Komponenten(wie zum Beispiel Konnektoren und Fachdiensten) kann technischeInteroperabilität nur über eine technische Schnittstellenspezifikation erfolgen. Die technischeRealisierung erfolgt auf der Grundlage von SOAP Version 1.1. Die Schnittstellenbeschreibungerfolgt daher auf Basis einer WSDL und zugehörigen XSDs und bietet damiteine plattformunabhängige Implementierungsgrundlage.Die Spezifikation der technischen Schnittstelle ist verbunden mit einer Schemadefinitionder SOAP-Nachrichtenstruktur. Das SOAP-Nachrichtenschema beschreibt alle Elemente,die im Rahmen des SOAP-basierten Nachrichtenaustausches verwendet werden. EineDarstellung der Motivation für die entwickelte Nachrichtenstruktur zusammen mit einervollständigen Detailbeschreibung aller Nachrichtenelemente sind Ergebnisse der vorliegendenSpezifikation.2.1.1.2 Dokumentschnittstelle für FacharchitekturenDas Dokument soll als Grundlagendokument für alle in der gematik beschriebenen Facharchitekturenund Spezifikationen zur Beschreibung von Transportaufgaben zwischenTelematik-Komponenten Anwendung finden. Eines der Ziele hierbei ist es insbesonderedie Komplexität der Spezifikation des Transports in den Facharchitekturen und Spezifikationenzu reduzieren. Nichts desto trotz muss bei der Verwendung des Transport spezifiziertwerden, wie die einzelnen Bestandteile der Telematiknachricht zu befüllen sind. DieSpezifikation der Befüllung MUSS durch alle Facharchitekturen und Spezifikationen formalidentisch erfolgen, um die Implementierung zu erleichtern und Missverständnissenvorzubeugen. Auch wenn es sich an dieser Stelle nicht um eine Schnittstelle im technischenSinne handelt, hat sich der Begriff Dokumentenschnittstelle etabliert.Es handelt sich bei der Dokumentenschnittstelle um einen Mechanismus, der Facharchitekturenund Spezifikationen auf effiziente Weise erlaubt, den Transport von Informationenzwischen Komponenten der TI mittels Telematiknachrichten zu spezifizieren unddennoch von den technischen Details unabhängig zu bleiben.Damit entsteht ein auf die Dokumentation bezogener Verbindungspunkt zwischen denFacharchitekturen und der hier vorliegenden Spezifikation. Es handelt sich hierbei umeine mögliche interne Schnittstelle einer Komponente (z. B. des Konnektors) die eineneinheitlichen Transportmechanismus für fachliche Module bereitstellt. Es ist aber keinegeforderte Schnittstelle im technischen oder logischen Sinne.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 12 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDie Trennung der Dokumente für Facharchitekturen von dem Dokument zur Spezifikationder SOAP-Nachrichtenstruktur vermeidet eine redundante Beschreibung innerhalb derFacharchitekturen und durch eine Referenzierung jeder Facharchitektur auf die vorliegendeSpezifikation verbessert sich die Lesbarkeit der Facharchitekturdokumente.2.1.1.3 TelematikTransport-AdaptierungDie Anwendung der vorgelegten Spezifikationen kann nur in Verbindung mit einer TelematikTransport-Adaptierungerfolgen. Als TelematikTransport-Adaptierung werden dieEinbettung sowie das spätere Auslesen fachlicher Informationen in eine Telematiknachrichtbasierend auf den in Facharchitekturen oder Spezifikationen enthaltenen Parameternder Dokumentenschnittstelle bezeichnet. Als Ergebnis der TelematikTransport-Adaptierung werden bereitgestellte fachliche Daten in einen TelematikTransport konformenSOAP-Request eingebettet, bzw. es wurden Informationen aus einem solchenSOAP-Request ausgelesen und einer Fachanwendung auf Empfängerseite zur Verfügunggestellt. Die vorliegende Spezifikation beschreibt das Konzept der TelematikTransport-Adaptierung.Die Implementierung der vorliegenden Spezifikation wird als TelematikTransport-Adaptierung bezeichnet. Es handelt sich also um die Erzeugung einer TelematikTransport-konformenSOAP-Struktur aus fachlichen Eingaben. Die TelematikTransport-Adaptierung beinhaltet somit:• die Transformation von fachlichen Datenstrukturen in transportfähige Formateund aus diesen zurück,• das für die Fachanwendungen transparente Einbringen und die Validierungvon Sicherheitsmerkmalen, unabhängig von den verwendeten Sicherheitsdiensten,-funktionen und -algorithmen,• sowie das Hinzufügen von für den Transport zusätzlich notwendigen Merkmalenund deren Auswertung.2.2 ZielgruppeDas Dokument richtet sich neben Personengruppen, die grundsätzlich an den Verfahrenfür die Umsetzung online-basierter Fachdienste wie z. B. VODM bzw. weiterer übergreifenderServices (z. B. Ticketservice) interessiert sind, an• Konnektorhersteller• Facharchitekten, Spezifikateure• Entwickler von Brokern• Entwickler von FachanwendungenDas vorliegende Dokument muss von allen Facharchitekturen aufgegriffen werden, um:• die in Kapitel 4.1.3 vorgegebene Struktur zur Befüllung der Telematiknachrichtfachspezifisch zu definieren, und• gemäß Abschnitt 4.6 zu jedem Fachdienstaufruf die zugehörige Brokersequenzzu definieren, sowiegematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 13 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details• die in Anhang A3 geforderte Berechtigungsmatrix für rollenbasierte Zugriffebereitzustellen.2.3 GeltungsbereichDas Dokument entsteht im Rahmen der Arbeiten der gematik zur Umsetzung der online-Fachdienste wie Verordnung, Versichertenstammdaten für Testmaßnahmen zur Einführungder elektronischen Gesundheitskarte [RVO2006] in der Bundesrepublik Deutschland.2.4 ArbeitsgrundlagenAusgangspunkt für die Ausführungen dieses Dokuments ist die Gesamtarchitektur[gemGesArch].Weitere Grundlage für die Ausarbeitung des Dokumentes ist das übergreifende Sicherheitskonzept[gemSiKo].Das vorliegende Dokument [gemSpec_TTD] ist für die Interoperabilität der Kommunikationzwischen Komponenten von entscheidender Bedeutung. Aus diesem Grund müssenim Produktivbetrieb Änderungen mit besonderer Berücksichtigung der Prozesse in [gem-GA_Wartg] durchgeführt werden.2.5 Abgrenzung des DokumentesIn der vorliegenden Spezifikation werden nur Funktionen und Datenelemente beschrieben,die für den SOAP-Nachrichtenaustausch von Bedeutung sind. Die Bereitstellungeiner TelematikTransport-Schnittstelle folgt dem Architekturkonzept, dass fachliche Anwendungenihre spezifischen Datenstrukturen über eine einheitliche TelematikTransport-Architektur austauschen. Durch die Entkopplung der Datenstrukturen für Transport undFachdaten, wirken sich fachliche Änderungen nicht auf den Transport aus. Es ist dahernicht die Aufgabe der vorliegenden Spezifikation, eine Beschreibung von Maßnahmen fürdie Bildung und Generierung fachspezifischer Datendetails (z. B. Fachdatenstrukturen,Bildung von Tickets, kryptographischen Schlüsseln etc.) vorzunehmen. Die Beschreibungdieser Funktionen liegt im Aufgabenbereich der jeweiligen Facharchitekturen bzw. wirddurch die Spezifikation für Ticketservices [gemSpec_Ticket] vorgenommen.2.6 Methodik2.6.1 Verwendung von SchüsselwortenFür die genauere Unterscheidung zwischen normativen und informativen Inhalten werdendie dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschenSchlüsselworte verwendet:MUSS. Absolut gültige und normative FESTLEGUNGEN sind durch das SchlüsselwortMUSS gekennzeichnet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 14 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDARF NICHT. Absolut gültige und normative AUSSCHLÜSSE sind durch das SchlüsselwortDARF NICHT gekennzeichnet.SOLL. EMPFEHLUNGEN ZU FESTLEGUNGEN sind durch das Schlüsselwort SOLL gekennzeichnet.Abweichungen sind in begründeten Fällen möglich.SOLL NICHT. EMPFEHLUNGEN ZU AUSSCHLÜSSEN sind durch das SchlüsselwortSOLL NICHT gekennzeichnet. Abweichungen sind in begründeten Fällen möglich.KANN. Vollständig FAKULTATIVE EIGENSCHAFTEN sind durch das SchlüsselwortKANN gekennzeichnet und haben keinen Normierungs- und keinen allgemeingültigenEmpfehlungscharakter.2.6.2 Konventionen zur Kennzeichnung von offenen PunkteOffene Punkte, die bis zur nächsten Dokumentversion bearbeitet werden, sind vorläufigmit den folgenden Konventionen gekennzeichnetOffene Punkte, die arbeitsgruppenübergreifend abgestimmt werden müssen, sind Magenta eingerahmt.Durch die Abteilung ITS/AP aufgrund bereits erfolgter Abstimmungen noch zu erweiternde Punkte sind violettmarkiert.Formale noch offene Inhalte sind blau markiert.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 15 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details3 Anforderungen und AnnahmenDie Gesamtarchitektur beschreibt im Wesentlichen die Anforderungen, Ziele und Motivationenfür die Spezifikation einer TelematikTransport-Schnittstelle. Ausgehend von der Gesamtarchitekturlassen sich die folgenden Anforderungen an die TelematikTransport-Schnittstelle zusammenfassen:3.1 EingangsanforderungenTabelle 1: Funktionale AnforderungenKennungA_00714BeschreibungSOAP als KommunikationsmittelKommunikation zwischen dezentralen Komponenten und dem Broker, sowiezwischen dem Broker und den Fachdiensten MUSS auf der Basis voneinheitlichen SOAP Messages realisiert werden.AF_TD_002 Für die Implementierung von Funktionen zur Absicherung der SOAP-NachrichtenMUSS der Web-Service-Security Standard 1.0 eingesetzt werden.AF_TD_003 Es soll eine einheitliche Verwendung von Transportdatenstrukturen für alleFacharchitekturen gewährleistet werden.AF_TD_004 Es MUSS möglich sein, nicht integritätsgeschützte Nachrichten zu versenden,sofern dies für den Anwendungsfall relevant ist.A_02221A_02222A_02223A_02224Bei Erstellen einer eVerordnung MUSS auf die Signatur der Payload einerTelematiknachricht durch die Datenautorität verzichtet werden, wenn einObjektTicket zur übertragenen Payload durch die Datenautorität signiertund in der Nachricht enthalten ist.Wird bei Erstellen einer eVerordnung auf die Signatur der Payload der Telematiknachrichtdurch die Datenautorität verzichtet, MUSS der angesprocheneFachdienst prüfen ob bereits ein ObjektTicket mit der OID des übermitteltenObjektTickets gespeichert ist und ob die ObjectID der fachlichenPayload mit der des übermittelten ObjektTickets übereinstimmt.Ergibt die Prüfung eines Fachdienstes bei Erstellung einer eVerordnung,dass bereits ein ObjektTicket mit der ObjectID des übermittelten ObjektTicketsgespeichert ist und die ObjectID der fachlichen Payload mit der desübermittelten ObjektTickets übereinstimmt, DARF die Nachricht NICHTdurch den Fachdienst akzeptiert werden.Es MUSS durch einen Fachdienst sichergestellt sein, dass ein bereits erstelltesObjektTicket nach Löschung nicht erneut eingestellt werden kann.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 16 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 2: Nicht-funktionale AnforderungenKennungBeschreibungAN_TD_001 Die Spezifikation von Datenstrukturen für Transport erfolgt unabhängig vonder Spezifikation fachlicher Datenstrukturen.AN_TD_002 Die Einrichtung neuer Funktionalitäten innerhalb eines Fachdienstes oderdie Einrichtung neuer Fachdienste SOLL ohne Änderung an der Transportebenemöglich sein.AN_TD_003 Sicherstellung einer Transparenz der Fachlichkeit für einen Intermediär(Broker). Die Zwischenschaltung von Broker MUSS möglich sein, ohne dieNotwendigkeit, dass ein Broker eine WSDL des Fachdienstes implementierenmuss.AN_TD_004 Das Schema der SOAP-Nachrichtenstruktur ist einheitlich für alle Fachdiensteund Telematik-Komponenten festzulegen.AN_TD_005 Die Beschreibung der TelematikTransport-Schnittstelle ist plattformunabhängigzu spezifizieren. Aufbauend auf dieser Spezifikation muss die Interoperabilitätder Implementierungen gewährleistet werden.Tabelle 3: SicherheitsanforderungenKennungBeschreibungAS_TD_001 Die TelematikTransport-Schnittstelle MUSS Mechanismen bereitstellen, diedie Authentizität und Integrität von gesendeten SOAP-Nachrichten (Transportdaten)gewährleisten.AS_TD_002 Die SOAP-Nachrichtenstruktur muss Möglichkeiten bereitstellen, so dassdie Identität eines Datenbearbeiters festgestellt werden kann.AS_TD_003 Die TelematikTransport-Schnittstelle muss Funktionen beschreiben undVorgaben machen, wie die Authentizität und Integrität von gesendetenfachlichen Daten (SOAP-Payload) zu gewährleisten ist.AS_TD_004 Die SOAP-Nachrichtenstruktur muss Möglichkeiten bereitstellen, so dassdie Identität einer Datenautorität festgestellt werden kann.AS_TD_005 Die SOAP-Nachrichtenstruktur muss Möglichkeiten bereitstellen, so dasseine unberechtigte Mehrfachverwendung ausgeschlossen werden kann(Abwehr von Replay-Angriffen).A_00095BDSG: Datenvermeidung und DatensparsamkeitDatenverarbeitungssysteme sollen so wenig personenbezogene Daten wiemöglich enthalten und von der Anonymisierung und PseudonymisierungGebrauch machen.Gestaltung und Auswahl von Datenverarbeitungssystemen haben sich andem Ziel auszurichten, keine oder so wenig personenbezogene Daten wiemöglich zu erheben, zu verarbeiten oder zu nutzen. Insbesondere ist vonden Möglichkeiten der Anonymisierung und Pseudonymisierung Gebrauchzu machen, soweit dies möglich ist und der Aufwand in einem angemessenenVerhältnis zu dem angestrebten Schutzzweck steht.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 17 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4 TelematikTransport-AdaptierungFachanwendungen benötigen eine TelematikTransport-Adaptierung, um eine Anpassungfachspezifischer Daten und Funktionsaufrufe an die durch die TelematikTransport-Schnittstelle einheitliche SOAP-Nachrichtenstruktur vorzunehmen.Die TelematikTransport-Adaptierung schafft die technische Grundlage dafür, dass beliebigefachspezifische Datenstrukturen über die TelematikTransport-Nachrichtenstrukturübertragen werden können. Es soll hier herausgestellt werden, dass die Nutzung der TelematikTransport-Schnittstellenur über Funktionen der TelematikTransport-Adaptierungerfolgen kann. Eine direkte Nutzung der TelematikTransport-Schnittstelle durch eineFachanwendung ist nicht möglich.Die in diesem Abschnitt beschriebenen Funktionen einer TelematikTransport-Adaptierungsind an beiden Kommunikationsendpunkten erforderlich. Nach Übertragung der Fachdatenauf Grundlage des Telematik-Protokolls werden die bei einem Empfänger durch dieSOAP-Transportschnittstelle zurück gelieferten SOAP-Datenelemente durch die TelematikTransport-Adaptierungwieder in die fachspezifischen Datenelemente und Funktionenzurück überführt.Die Aufgaben der TelematikTransport-Adaptierung werden in Abbildung 2 verdeutlicht:Abbildung 2: Einordnung der TelematikTransport-Adaptierunggematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 18 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsFolgende Funktionen muss eine TelematikTransport-Adaptierung bereitstellen:Vorbereitung FachdatenInnerhalb jeder Facharchitektur werden Prozesse für die Bearbeitung von fachspezifischenDaten beschrieben. Im Rahmen dieser Facharchitekturen entstehen konkreteFachdatenstrukturen, die für eine Online-Übertragung an die Vorgaben der TelematikTransport-Schnittstelleangepasst werden müssen. Die TelematikTransport-Adaptierungist für die Datenformatanpassung (Konvertierung) inklusive Kodierung (z. B. als Base64)der fachspezifischen Daten in das durch die TelematikTransport-Schnittstelle vorgeschriebeneTransport-Datenformat zuständig.Mapping der Daten auf SOAP-ElementeElemente der aufbereiteten Fachdaten und deren Funktionsaufrufe müssen spezifiziertenElementen der SOAP-Nachrichtenstruktur zugeordnet und in diese übertragen werden.Die Abbildung von fachlichen Funktionsaufrufen in SOAP-Transport-orientierte Funktionsaufrufeübernimmt die Telematik-Adaptierung. Die Benennung von fachlichen Funktionsaufrufenals Operation auf SOAP-Transportebene liegt in der Verantwortung der Facharchitekturen.Erweiterung um von Facharchitekturen unabhängige DatenFür die Durchführung einer Datenübertragung auf Transportebene sind neben den Fachdatenin Abhängigkeit vom Fachdienst weitere Datenobjekte, z. B. für Sicherheitsfunktionenund für die Steuerung des Datenflusses erforderlich.Um eine Unterscheidung zu den fachspezifischen Daten vorzunehmen, werden zusätzlicheDatenobjekte im Dokument als Parameter bezeichnet. Es ist Aufgabe der TelematikTransport-Adaptierungalle für einen Onlinedatenzugriff notwendigen Parameter bereitzustellenund die SOAP-Nachrichtenstruktur damit anzureichern (siehe oben: Mappingder Daten auf SOAP-Elemente).Aufbringung bzw. Überprüfung von SicherheitsmerkmalenDie TelematikTransport-Adaptierung muss Funktionen zur Absicherung des Nachrichtentransportsbereitstellen. Aus jeder Nachricht müssen sich später die Identitäten für denDatenbearbeiter bzw. der Datenautorität ermitteln lassen, sofern dies für den jeweiligenAnwendungsfall relevant ist. Die Anreicherung der SOAP-Nachrichtenstruktur vollziehtsich auch im Rahmen der Ausführung von Sicherheitsfunktionen. Es wird z. B. der privateSchlüssel des Datenbearbeiters dafür verwendet, um die SOAP-Nachricht digital zu signieren.Es entstehen damit entsprechende SOAP-Header bzw. Body-Strukturen für dieHinterlegung der Signaturen, inklusive des Zertifikats der entsprechenden Akteure. DieAbläufe zur Durchführung sind implementierungsabhängig. Aus diesem Grund wird indiesem Dokument lediglich das Ergebnis in Form der Nachrichtenspezifikation in Kapitel 5dargestellt.Für Anwendungsfälle, in denen das in [gemGesArch] definierte Webservice Kommunikationsmusterverwendet wird, MUSS vor Durchführung der Zugriffskontrolle auf einemFachdienst die Authentizität der übermittelten Nachricht für den Datenbearbeiter und dieDatenautorität auf Transportebene geprüft werden. Nach nachgewiesener Authentizitätder Nachricht wird dann anhand der Identität der Datenautorität und der Rolle des Datenbearbeitersdie Autorisierung der Anfrage durchgeführt. Die Protokollierungspflichten u. A.aus BDSG Anlage zu § 9 Satz 1 Nr. 5 sind einzuhalten. Dabei MUSS sichergestellt werden,dass diese Protokolle nur zur Datenschutzkontrolle verwendet werden können. Ana-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 19 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailslog MUSS auf dem Konnektor zuerst die Authentizität der Antwortnachricht geprüft werden,bevor eine weitere Verarbeitung erfolgen darf.4.1 Dokumentenschnittstelle4.1.1 Aufgabe und MotivationDie Spezifikation des TelematikTransports bezweckt die Entkopplung der Spezifikationder fachlichen Datenverarbeitung in den Facharchitekturen und die Spezifikation des Datentransportszwischen Konnektor, Broker und dem Fachdienst. Mit Hilfe der hier definiertennormativen Dokumentenschnittstelle legt eine Facharchitektur die Art und den Umfangder zu übermittelnden Daten fest. Die Spezifikation des TelematikTransports sichert zu,dass die fachlichen Daten zum Empfänger übertragen werden, und liefert dessen Rückantwort.Die Facharchitekturen benötigen hier keine gesonderte Spezifikation der Übertragungsprotokolleund technischen Schnittstellen.Die hier definierte Dokumentenschnittstelle ist keine Schnittstelle zwischen etwaigen Moduleninnerhalb einer Komponente und ist daher auch weder eine technische noch einelogische Schnittstelle. Vielmehr stellt sie eine Abstraktionshilfe dar.Darüber hinaus werden bestimmte Funktionen der TelematikTransport-Adaptierung nurdurch die Facharchitektur (FA) spezifiziert. Facharchitekturübergreifende Abläufe werdenzentral in diesem Dokument festgelegt. Benötigte Daten werden als Parameter modelliert,die durch die FA in der Dokumentenschnittstelle festgelegt werden.Die folgende Abbildung soll das Konzept der Dokumentenschnittstelle verdeutlichen.LayerAnwendungsebeneTypisierteFachdatenIdentitätDEIdentitätDAIdentitätDBTickets(OT/ST)TypisierteFachdatenIdentitätDEIdentitätDAIdentitätDBTickets(OT/ST)TelematikProtokollTelematik-Adaptierung(Befüllung in der FA)SOAPIntermediärTelematik-Adaptierung(Datenaufbereitung gemäß Dokumentenschnittstelle in FA)Service(FD)OperationSteuerdatenDaten-BearbeiterFach-DatenTickets(OT/ST)Daten-AutoritätService(FD)OperationSteuerdatenDaten-BearbeiterFach-DatenTickets(OT/ST)Daten-AutoritätSOAPSOAP HeaderSOAP BodyUmsetzenderTelematiksequenzSOAP HeaderSOAP BodyTelematik-HeaderSecurity-HeaderVerwendung von Telematik.wsdlBodyLokalisierung+AuditierungTelematik-HeaderSecurity-HeaderVerwendung von Telematik.wsdlBodyHTTPS+ NetzwerkTelematikExecuteSOAP CALLTelematikExecuteSOAP CALLKonnektor Broker FachdienstTierAbbildung 3: TelematikTransport-DetailsDie Dokumentenschnittstelle legt eine Liste von Parametern (wie Service, Operation,Fachdaten etc.) fest, die an die TelematikTransport-Schnittstelle übergeben werden können.Damit erfolgt die Übergabe auf Beschreibungsebene an das Dokument der TelematikTransport-Adaptierung.Nach Übernahme der Facharchitekturparameter wird die Beschreibungder TelematikTransport-Adaptierung und der Spezifikation der TelematikTransport-Detailsfortgesetzt.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 20 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDie Darstellung der Dokumentenschnittstelle bildet die Grundlage für die Anwendung desTelematikTransports in den Facharchitekturen. Im vorliegenden Dokument entstehennormative Vorgaben, wie diese Parameter in den Facharchitekturen einzusetzen sind.4.1.2 Details der DokumentenschnittstelleOffener Punkt: Einführung von Anwendungsfall-ProfilenEs ist in Diskussion, dass in Anwendungsfall-Profilen sinnvolle Parameter-Kombinationen (z. B. SIG, ENCPL) gruppiertwerden. Die Facharchitektur müsste dann das benötigte Profil auswählen.In der folgenden Tabelle sind sämtliche Parameter inklusive der Fachdatenobjekte aufgeführt,die durch die TelematikTransport-Adaptierung angepasst und bereitgestellt werden.Nicht jede Funktion für den Online-Nachrichtenaustausch erfordert, dass die in derTabelle aufgeführten Parameter vollständig bereitgestellt werden. Es ist Aufgabe der jeweiligenFacharchitektur, die funktionsabhängigen Parameter zu ermitteln und zu beschreiben.Tabelle 4: Übersicht fachspezifischer ParameterParameterKürzel Required/OptionalBeschreibungParameter für die Ausführung einer FachdienstfunktionTyp des Fachdienstes(Service-Typ)SVC Req Bezeichnung des Fachdienstes zum Zweck derDienstlokalisierung gemäß [gemGesArch#12.11.5.2].Dieser Begriff ist für jede Facharchitektur eindeutig.Die Liste der Schlüsselworte MUSS inder jeweiligen Facharchitektur definiert werden.Beispiel: VODDService Provider PROV Opt Mit diesem Parameter (in der Regel ist das einName einer Organisationseinheit) werden Informationenbereitgestellt, auf deren Grundlagedie Dienste für Service-Lokalisierung (mittelsSDS) die entsprechende Fachdienstinstanzermitteln.Als Beispiel für den VSDD kann das Institutionskennzeichen(IK) des Kostenträgers verwendetwerden.FachdienstkomponenteFDK Req Innerhalb eines Fachdienstes können differenzierteKomponenten (Interfaces) angebotenwerden. Als Fachdienstkomponente kann z. B.ein Fachdienst selbst, der zugehörige Ticketserviceoder die Schnittstelle für AdV angesprochenwerden. Jede Facharchitektur definiertdas durch sie verwendete Kürzel, und eserfolgt bei der gematik eine Konsolidierung sowieÜberprüfung zur Verhinderung von Duplikaten.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 21 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameterFachdienstoperationKürzel Required/OptionalBeschreibungOPE Req Bestimmt die fachliche Operation, die auf demFachdienst ausgeführt werden soll.Die Liste der verfügbaren Schlüsselworte istvon der Facharchitektur abhängig und wirddurch jede Facharchitektur definiert.Beispiel: WriteVOParameter für die Steuerung des DatenaustauschesConversation ID CID Opt Die CID dient zur Korrelierung zwischen verschiedenenAufrufen.Die CID kann dabei entweder durch den Absender(Konnektor oder Broker) im Requestoder durch den Fachdienst in der Responsevergeben werden. Die Entscheidung hierzu istvon dem konkreten Anwendungsfall der FAabhängig. Nach dieser einmaligen Festlegungdient sie dazu, alle Nachrichten die zu einerSitzung bzw. Gruppe von Nachrichten gehörenzu korrelieren.Das Format der CID ist von der Facharchitekturund vom Anwendungsfall abhängig. Sofern dasFormat für eine andere als die erzeugendeKomponente relevant ist, muss die Facharchitekturdie konkrete Ausprägung definieren.Bespiel:3182aab5-c4b3-4874-a8ae-3770ceea12ffAudit ID AID Opt Offener Punkt für R3 – Perspektivische Erweiterung um AuditIDDer Parameter AuditID ist als perspektivische Erweiterung vorgesehenund DARF im Rahmen des Release 2 NICHT verwendetwerden.Parameter für die Absicherung des DatenaustauschesSignierte NachrichtElektronischeIdentität einer DatenautoritätSIG Req Dieses Element gibt an, ob eine WSS-Signaturder Nachricht notwendig ist oder nicht. Fallseine WSS-Signatur erforderlich ist, muss zumindestdie Identität des Datenbearbeiters(IDB) angegeben werden. Die Angabe einerIdentität für die Datenautorität ist optional. ZulässigeWerte Ja/NeinBeispiel: JaIDA Opt Kryptographische Identität zur Überprüfungeiner Datenautorität.Wird für die Prozesse zur Authentifizierung derDatenautorität verwendet.(Signatur mittels SmartCard und privatemSchlüssel, Validierung mittels X.509-Zertifikatgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 22 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameterElektronischeIdentität einesDatenbearbeitersKürzel Required/OptionalBeschreibungder Datenautorität)Beispiel:AUT.N Zertifikat des VersichertenIDB Opt Kryptographische Identität zur Überprüfungeines Datenbearbeiters.Wird für die Prozesse zur Authentifizierung desDatenbearbeiters verwendet.(Signatur mittels SmartCard und privatemSchlüssel, Validierung mittels X.509-Zertifikatdes Datenbearbeiters, im Fall einer Responsewird hier das Zertifikat des Fachdienstes verwendet.)Sofern mehr als eine Identität angegebenwird, MUSS auf die Stelle im Dokumentverwiesen werden, an der die Entscheidung fürdie Verwendung erläutert wird.Beispiel:OSIG Zertifikat der SMC-B, HBA-Aut (Kapitel7.5.1)Versichertenbezug IREF Opt Mit diesem Eintrag wird der Versichertenbezugals Ordnungskriterium für einen Fachdienstfestgelegt. Sie dient gleichzeitig als Ordnungskriteriumfür die versichertenzentrierte Auditierung.Unterscheidung des Versichertenbezugs zwischen R2 undR3In R2 stimmt der Versichertenbezug immer mit der Datenautoritätüberein. Für R3 ist dies jedoch nicht mehr gegeben, da ab R3auch Berechtigte bzw. Beauftragte als Datenautorität agierenkönnen. Aus diesem Grund wurde das Element bereits jetztseparat in die Dokumentenschnittstelle aufgenommen.EncryptedKeyEK(Liste1...x)OptMit diesem Parameter können Hybridkeys fürden Transport zur Verfügung gestellt werden.Hybridkeys werden immer nur in Fachdienstantwortentransportiert. Der Transport vonHybridkeys von einem Konnektor zu einemFachdienst erfolgt immer über ObjektTicketsund den dafür vorgesehenen Parameter.TicketOT(Liste1..x)OptMit diesem Parameter können ObjektTickets fürden Transport bereitgestellt werden:ObjektTicket (OT)Eine detaillierte Beschreibung der Verwendungund der Datenstruktur erfolgt in [gemSpec-_Ticket].ST(Liste1..x)OptMit diesem Parameter können ServiceTicketsbereitgestellt werden:ServiceTicket (ST)gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 23 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameterKürzel Required/OptionalBeschreibungParameterliste für die zu übertragenen FachdatenServiceTickets werden hauptsächlich für dienachweisliche Ernennung von Berechtigtenbzw. Beauftragten eingesetzt. Der Parameterkann ein oder mehrere ServiceTickets enthalten.Eine detaillierte Beschreibung der Verwendungund der Datenstruktur erfolgt in[gemSpec_Ticket].Fachdaten werden als Liste von Name/Value-Paaren übergeben.Diese Kombination aus Name, Datenkodierung und Fachdaten muss durch die FA fürjeden Aufruf spezifiziert werden. Es können bis zu 200 Name/Value-Paare übergebenwerden. Falls keine Fachdaten zu übertragen sind, so ist die Parameterliste leer zu belassen.Bezeichnung derfachspezifischenDatenPAR Req. ParameternameBezeichnung des zu übertragenden Datenelements.Diese Angabe wird als Parameternameder Name/Value-Kombination zur Übertragungfachspezifischer Daten verwendet.Datenkodierung ENC Opt. Angabe der Kodierung für das zu übergebeneDatenelement. Zulässige Werte sind „base64“für die base64 codierte Übertragung von Datenwie beispielsweise binär oder XML Daten oder„plain“ für die Übertragung eines einfachenStrings.Beispiel:base64 (bei der Übermittlung von XML-Strukturen)Beispiel:plain (das bedeutet, dass einfach Datentypenals XML Datentyp xs:string übertragen werden.Dies wird z. B. für eine ObjektID, Oref, Zahlenoder sonstige Zeichenketten verwendet).FachspezifischeDatenFDD Req Übergabe der Fachdaten. Die Inhalte von FDDwerden als Value der Parameter/Value-Kombination zur Übertragung fachspezifischerDaten verwendet.4.1.3 Verwendung in den Dokumenten der FacharchitekturenDie folgende Tabelle stellt alle Parameter dar, wie sie einheitlich von den Facharchitekturenzu verwenden sind, und ist von ihrem Format her normativ. Die Spalte Inhalt ist durchdie einzelnen FAs für jede Nutzung der TelematikTransport-Schnittstelle auszufüllen. DieTabelle dient als Template für die Bereitstellung der erforderlichen Schnittstellenwerte, diezur Anwendung kommen. Die hier aufgeführten nicht-normativen Beispieldaten beziehensich auf einen VOD-spezifischen Aufruf.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 24 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsFür optionale Elemente, die für eine Fachanwendung nicht benötigt werden, kann die Befüllungder Spalte Inhalt entfallen. In diesem Fall wird das optionale Element nicht in dieNachricht aufgenommen. Sofern die Aufnahme eines Elementes mit leerem Inhalt durchdie Fachanwendung explizit gewünscht wird, ist dies durch den Inhalt „“ zu kennzeichnen.Tabelle 5: Normatives Format der Parameterliste für Facharchitekturen mit nicht normativen,exemplarischen InhaltenKurzbeschreibung Zweck Kürzel InhaltTyp des Fachdienstes(Service-Typ)Dienst Lokalisierung SVC „VODD“Service Provider Dienst Lokalisierung PROV IK der eGK des VersichertenDienstkomponente(FD/Ticket)Funktionsauswahl FDK „VOD“Fachdienst-Operation Funktionsauswahl OPE „WriteVO“Conversation ID Aufrufkorrelierung CID „3182aab5-c4b3-4874-a8ae-3770ceea12ff“Audit ID Aufrufkorrelierung AIDSignierte NachrichtIdentität des Datenbearbeiters/FachdienstesIdentität der DatenautoritätVerwendung einerWSS-SignaturSIG„Ja“Authentifizierung IDB OSIG X.509-Zertifikat derSMC-BAuthentifizierung IDA AUT.N X.509-Zertifikat desVersichertenEncryptedKey Transport Hybridkeys EK EncryptedKey mit zugehörigerObjektID des fachlichen DatenobjektesTicketsFachdatenObjektTicket der VerordnungServiceTicketsPARName desDatenobjektesOTSTENCEncoding(base64/plain)ObjektTicket der eVerordnungFDDFachdaten„VODocument“ base64 Verschlüsselte eVerordnung„OID“ plain OID„Zusatzparameter“ plain „“gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 25 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.2 Nachrichtenverarbeitung durch FachdiensteEines der Ziele des TelematikTransports ist die Entkopplung zwischen Transport undFachlichkeit. Das bedeutet, für die Anwendungen in einem Fachdienst ist die Art und Weisedes Transports nicht relevant. Damit die Transparenz gewährleistet ist, muss die Verarbeitungder Nachricht durch Fachdienste bis zum Weiterleiten an die Fachlichkeit füralle Implementierungen vergleichbar erfolgen und alle Implementierungen MÜSSEN inder gleichen Art und Weise reagieren.Abbildung 4 stellt den Ablauf der Verarbeitung graphisch dar. Die einzelnen Schritte werdennachfolgend kurz erläutert und die entsprechende Detailspezifikation wird referenziert.Die Aufteilung der Aktivitäten auf Komponenten ist dem Hersteller überlassen undfür die Implementierung sind gewisse Freiräume erlaubt. Es werden jedoch die folgendenAnforderungen gestellt:• Alle in dieser Abbildung dargestellten Aktivitäten MÜSSEN im Rahmen derVerarbeitung durchgeführt werden.• Die Reihenfolge der Verarbeitung SOLL wie vorgegeben durchgeführt werden.• Die Verarbeitung durch ein Fachmodul MUSS nach der Authentifizierung undAutorisierung erfolgen.• Es MUSS sichergestellt werden, dass durch eine abweichende Aufteilungoder Reihenfolge keine Auswirkung auf die Schnittstelle zur TI oder zumFachmodul entsteht.Es wird empfohlen die vorgeschlagene Aufteilung zu verwenden, da zukünftige Änderungenin diesem Dokument von dieser Aufteilung als Grundlage ausgehen.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 26 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsact Nachrichtenverarbeitung innerhalb eines FachdienstesStartValidierung dereingehenden NachrichtOKAuthentifizierung desDatenbearbeiters und derDatenautoritätOKAutorisierungsprüfung desDatenbearbeitersFehlerFehlerFehlerOKPrüfung derOperationsparameterFehlerAnwendungsebeneOKAutorisierungsprüfungder DatenautoritätFehlerOKVerarbeitung der Nachrichtdurch ein FachmodulFehlerOK / FehlerErstellen einer SOAPResponseErstellen einerFehlernachrichtEndeAbbildung 4: Aktivitätsdiagram Nachrichtenverarbeitung durch FachdiensteIn der nachfolgenden Beschreibung der Verarbeitungsschritte wird nicht explizit erwähnt,dass die Ergebnisse vorheriger Verarbeitungsschritte weitergereicht werden. Dies istaber, sofern nicht explizit ausgeschlossen, für alle Verarbeitungsschritte der Fall.Zur einfacheren Lesbarkeit wird an dieser Stelle auf die Spezifikation der Fehlercodesverzichtet. Alle Fehlercodes sind in Anhang A4 spezifiziert und können dort über die AuslösendeBedingung zugeordnet werden.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 27 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 6: Verarbeitungsschritt Validierung der eingehenden NachrichtEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleEs wurde eine Telematiknachricht empfangen.Nach dem Empfang der Telematiknachricht erfolgt eine Schemavalidierung gemäß Abschnitt 0. DieSchemavalidierung MUSS die Konformität zur WSDL und dem XSD beinhalten. Hierbei ist auch dieEinhaltung der Anforderung [A_01553] (Keine undefinierten Header vorhanden, siehe Tabelle 26)zu prüfen. Eine inhaltliche Prüfung gemäß der Schemabeschreibung in Abschnitt 5 DARF NICHTfür Elemente erfolgen, die in der weiteren Nachrichtenverarbeitung des Empfängers keine Verwendungfinden. Hierdurch wird vermieden, dass bei semantischen Änderungen, Komponenten angepasstwerden müssen, die eigentlich von der Änderung unberührt sind.Zusätzlich muss die Erkennung von Replay-Attacken gemäß Abschnitt 4.8 sowie eine Prüfung, obdie Nachricht innerhalb des in Abschnitt 4.7 definierten Gültigkeitszeitraumes liegt, erfolgen.Es liegt eine validierte Telematiknachricht vor. (In anderen Fällen wurde ein Fehler generiert)Dem nachfolgenden Verarbeitungsschritt wird die validierte Telematiknachricht bereitgestellt.Die Validierung der Nachricht ist fehlgeschlagen, die Verarbeitung wurde abgebrochen und es wirdeine Fehlernachricht generiert.Tabelle 7: Verarbeitungsschritt Authentifizierung des Datenbearbeiters und der DatenautoritätEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleEs liegt eine validierte Telematiknachricht vor.Die Verarbeitung beinhaltet die Authentifizierung des Datenbearbeiters und der Datenautoritätgemäß Anhang A2. Als Ergebnis dieses Schrittes wurde folgendes geprüft:Die Signaturen von Datenbearbeiter und Datenautorität sind integer (das bedeutet „mathematischkorrekt“).Die verwendeten Zertifikate sind gültig.Es wurden die korrekten Algorithmen verwendet.Es wurden die korrekten Bereiche der Nachricht signiert.Es findet in diesem Schritt eine Auflösung von Transportoptimierungen statt. Folgende Transportoptimierungenkönnen zum Einsatz kommen:Sofern Datenbearbeiter und Datenautorität identisch sind und nur eine Signatur der Nachrichterfolgt ist, wird in diesem Schritt dennoch ein Ergebnis für die Identität der Datenautorität und desDatenbearbeiters getrennt bereitgestellt.Enthält die Nachricht neu erstellte ObjektTickets und es wurde auf eine Signatur der Datenautoritätverzichtet, so wird die Identität der Datenautorität aus dem zuletzt erstellten ObjektTicket ermittelt.Bei späteren Autorisierungsentscheidungen kann es relevant sein zu unterscheiden, ob der Datenbearbeiterund die Datenautorität identisch sind. Diese Information kann später nur über Korrelationder Zertifikate wieder bestimmt werden, liegt aber im Rahmen der Authentifizierung bereits vor. Ausdiesem Grund soll diese Information ebenfalls weitergegeben werden.Ebenfalls Inhalt dieser Aktivität ist die Extraktion der eindeutigen Authentifizierungsmerkmale.Jedes Zertifikat enthält eine Vielzahl von Informationen, von denen allerdings nur die wenigstenbenötigt werden, um eine Identität eindeutig zu identifizieren. Für die Vergabe von Berechtigungensollen allerdings nicht alle Informationen hinterlegt werden, sondern es sollen nur die tatsächlichbenötigten Authentifizierungsmerkmale hinterlegt werden. Diese Authentifizierungsmerkmale werdenan dieser Stelle aus dem Zertifikat der Datenautorität ausgelesen und weiteren Verarbeitungsschrittenzur Verfügung gestellt.Die Authentifizierung des Datenbearbeiters und der Datenautorität wurde erfolgreich durchgeführt.(In anderen Fällen wurde ein Fehler generiert)Es werden die folgenden Informationen für die weitere Verarbeitung zur Verfügung gestellt:ein gültiges X.509-Zertifikat für den Datenbearbeiterein gültiges X.509-Zertifikat für die Datenautoritätdie Rolle des Datenbearbeitersdas eindeutige Authentifizierungsmerkmal der Datenautoritätdie Information, ob eine Transportoptimierung stattgefunden hat und Datenbearbeiter und Datenautoritätübereinstimmen.die Information, ob die Datenautorität der in der Nachricht enthaltene Dateneigentümer ist.die validierte TelematiknachrichtZur Vermeidung der Komplexität in der Beschreibung wird diese Beschreibung auch für unsignierteNachrichten beibehalten. Es wäre allerdings dann der Fall, dass die übergebenen Informationen(Zertifikate, Rollen usw.) leer sind. Im Rahmen der Autorisierung würde dann die Überprüfungstattfinden, ob eine fehlende Signatur für den Anwendungsfall zulässig ist. Eine Überprüfung andieser Stelle zu fordern, würde eine Performanceoptimierung für Fehlerfälle darstellen, die alsunnötig angesehen wird, dennoch ist es dem Hersteller überlassen, an dieser Stelle mit einemFehler abzubrechen, sofern unsignierte Nachrichten nicht unterstützt werden.Eine der Authentifizierungen ist fehlgeschlagen, die Verarbeitung wurde abgebrochen und es wirdeine Fehlernachricht generiertgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 28 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 8: Verarbeitungsschritt Autorisierungsprüfung des DatenbearbeitersEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleEs liegt eine validierte Telematiknachricht vor. Datenbearbeiter sowie Datenautorität wurden erfolgreichauthentifiziert.Die Rolle des Datenbearbeiters, die Telematiknachricht zur Bestimmung der aufgerufenen Operationsowie eine rollenbasierte Zugriffsmatrix, in der für jede Operation die für die Durchführung derOperation zulässigen Rollen aufgeführt sind, steht zur Verfügung.Die detaillierte Durchführung der Autorisierungsprüfung wird in Anhang A3 spezifiziert.Ziel ist es zu überprüfen, ob die Rolle des Datenbearbeiters dazu berechtigt ist, die in der Telematiknachrichtenthaltene Operation durchzuführen.Die Autorisierungsprüfung des Datenbearbeiters wurde erfolgreich durchgeführt, das bedeutet dieRolle des Datenbearbeiters ist zur Durchführung der aufgerufenen Operation berechtigt. (In anderenFällen würde ein Fehler generiert)Die Autorisierung des Datenbearbeiters ist fehlgeschlagen, die Verarbeitung wurde abgebrochenund es wird eine Fehlernachricht generiert.Tabelle 9: Verarbeitungsschritt Prüfung der OperationsparameterEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleEs liegt eine validierte Telematiknachricht vor, die Datenautorität und der Datenbearbeiter wurdenerfolgreich authentifiziert und eine erfolgreiche Autorisierungsprüfung für den Datenbearbeiter hatstattgefunden.Es liegt die Information vor, welche Operationen durch den Fachdienst verarbeitet werden können,welche Parameter sowie Kodierungen der Parameter für den Aufruf dieser Operation notwendigsind.Ziel dieses Verarbeitungsschrittes ist es, alle für die Verarbeitung der Operation notwendigen Inhalteder Telematiknachricht aus der Nachricht zu extrahieren, so dass für die Verarbeitung durch dasFachmodul kein weiterer direkter Zugriff auf die Nachricht mehr notwendig ist. Für die Zuordnungder Parameter zu Operationen muss insbesondere auch die ComponentVersion beachtet werden.Ebenfalls Aufgabe dieses Schrittes ist die Prüfung der Lokalisierungsparameter, sofern dies nicht ineinem vorhergehenden Schritt bereits erledigt wurde.Alle für die Verarbeitung der Operation notwendigen Daten wurden aus der Telematiknachrichtextrahiert. Die Inhalte der verwendeten Elemente wurden auf Konformität zu der Schemabeschreibunggemäß Kapitel 5 validiert. Eine Validierung der Inhalte einzelner Name/Value-Paare ist nochnicht erfolgt. (Sofern die Validierung der Name/Value-Paare notwendig ist, muss die Validierung inden Facharchitekturen spezifiziert werden.)Die Prüfung der Nachricht auf notwendige Parameter ist fehlgeschlagen, die Verarbeitung wurdeabgebrochen und es wird eine Fehlernachricht generiertTabelle 10: Verarbeitungsschritt Autorisierungsprüfung der DatenautoritätEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleDie Identität der Datenautorität wurde authentifiziert, die für die Authentifizierung notwendigenEigenschaften der Identität wurden extrahiert. Es ist bekannt, auf welches Objekt zugegriffen werdensoll. Die durchzuführende Operation ist bekannt.Die Autorisierungsprüfung kann verschiedene Autorisierungskonzepte verwenden.Jede Facharchitektur MUSS definieren, welches Autorisierungskonzept verwendet wird.Jede Facharchitektur MUSS auf das Dokument verweisen, das nähere Details für die Autorisierungsprüfungspezifiziert. Ein mögliches Verfahren für die Autorisierung ist in [gemSpec_Ticket]spezifiziert.Das Ergebnis der Autorisierungsprüfung kann abhängig vom gewählten Konzept variieren.Die möglichen Fehlerfälle der Autorisierungsprüfung können abhängig vom gewählten Konzeptvariieren.Tabelle 11: Verarbeitungsschritt Verarbeitung durch ein FachmodulEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleAlle für die Verarbeitung durch das Fachmodul notwendigen Daten wurden aus der Telematiknachrichtextrahiert. Die Identitäten des Datenbearbeiters und der Datenautorität liegen als X.509-Zertifikate vor. Der Datenbearbeiter ist zur Durchführung der aufgerufenen Operation berechtigt.Die Operation gemäß der Spezifikation der Facharchitektur wird durchgeführt. Innerhalb dieserOperation MUSS für Zugriffe auf Daten die Autorisierungsprüfung der Datenautorität erfolgen.Alle für die Generierung einer Responsenachricht benötigten Informationen wurden bereitgestellt.Die möglichen Fehlerfälle sowie deren Behandlung werden durch die Facharchitekturen spezifiziert.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 29 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 12: Verarbeitungsschritt Erstellen einer FehlernachrichtEingangsdaten /VorbedingungenBeschreibungAusgangsdaten/NachbedingungenFehlerfälleBei der Verarbeitung der Nachricht ist ein Fehler aufgetreten.Die Erstellung einer Fehlernachricht ist in [gemSpec_FM] spezifiziert.Es wurde eine Fehlernachricht an den Aufrufer gesendet und die Verarbeitung der Nachricht istabgeschlossen.KeineTabelle 13: Verarbeitungsschritt Erstellen einer SOAP ResponseEingangsdaten / Alle für die Generierung einer Responsenachricht benötigten Informationen gemäß Tabelle 4 wurdenbereitgestellt.VorbedingungenBeschreibung Basierend auf den Parametern des Fachmoduls wird die Responsenachricht gemäß Kapitel 5generiert.Ausgangsdaten/ Es wurde eine Responsenachricht an den Aufrufer gesendet.NachbedingungenFehlerfälleKeineOffener Punkt R2 – Nachrichtenverarbeitung durch IntermediäreDie hier beschriebenen Verarbeitungsschritte gelten weitestgehend auch für Intermediäre (z. B. Broker), die Nachrichten aneinem Empfänger weiterleiten.Es muss noch die Diskussion geführt werden, in wieweit diese Schritte in diesem Dokument beschrieben werden und eineAbgrenzung zu [gemBroker] vorgenommen wird.Das Ergebnis wird in der nächsten Version dieses Dokumentes dargelegt.4.3 Logischer Aufbau der SOAP-NachrichtenstrukturIm folgenden Abschnitt wird die SOAP-Nachrichtenstruktur spezifiziert und dargestellt.Im Anschluss daran werden Festlegungen getroffen, wie die übergebenen Datenelementeund Parameter in die SOAP-Nachrichtenstruktur eingeordnet werden.Die SOAP-Nachrichtenstruktur bildet die Grundlage für einen typisierten Nachrichtentransportdienst.Die Schnittstelle für diesen Dienst wird Kapitel 6 als WSDL beschrieben.Die Datenelemente der SOAP-Nachrichtenstruktur sind Bestandteil der WSDL (vgl. Kapitel6). Die SOAP-Nachrichtenstruktur wird durch folgende Transportelemente gebildet:gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 30 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAbbildung 5: Aufbau SOAP Nachrichtenstruktur4.3.1 SOAP-HeaderDer SOAP-Header ist in drei Subheader unterteilt. Die Verwendung der Subheader wirdnachfolgend erläutert.4.3.1.1 TransportHeaderAufgabe des TransportHeaders ist es, Informationen, die sich im Laufe des Transportsder Nachricht ändern können und die keines kryptographischen Integritätsschutzes bedürfen,zusammenzufassen. Hierzu gehören beispielsweise Informationen zur Korrelierungeinzelner Nachrichten zueinander oder auch Informationen die für die Fehlerbehandlungund das Logging benötigt werden. Innerhalb der TI dürfen keine Informationen desTransportHeaders für Authentifizierung oder Autorisierung herangezogen werden, da sienicht integritätsgeschützt sind.Die detaillierte Beschreibung der einzelnen Elemente erfolgt in Abschnitt 5.2.1.4.3.1.2 TelematikHeaderIm TelematikHeader werden Informationen gekapselt, die kryptographisch integritätsgeschütztwerden müssen. Hierzu gehören unter anderem Informationen für die Lokalisierungvon Fachdiensten und Informationen, die die Verarbeitung der Nachricht betreffen.Die Hauptaufgabe der Lokalisierungsinformationen die Lokalisierung des Fachdienstes istüber die SDS für den konkreten Anwendungsfall durchzuführen. Bei Verarbeitungsinformationenhandelt es sich beispielsweise um die Fachdienstoperation oder den Diensttyp.Dies hat einerseits Einfluss auf die durch den Broker durchgeführte Brokersequenz undandererseits Einfluss auf das fachliche Modul und die erwartete Payload innerhalb desFachdienstes. Hierbei ist zu beachten, dass die Lokalisierungs- und Verarbeitungsinformationenbei einer Response identisch zu den Lokalisierungs- und Verarbeitungsinformationendes Aufrufs sind, sofern dies nicht in der Beschreibung des Elementes explizit andersspezifiziert ist (z. B. das Element Insurant darf in der Response nicht enthalten sein).Die detaillierte Beschreibung der einzelnen Elemente erfolgt in Abschnitt 5.2.2.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 31 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.3.1.3 SecurityHeaderAufgabe des SecurityHeaders ist der Integritätsschutz der Nachricht sowie die Authentifizierungdes Datenbearbeiters. Der SecurityHeader wird im Gegensatz zumTransportHeader und TelematikHeader nicht über eine XSD beschrieben, stattdessenerfolgt die Definition der Sicherheitsmerkmale und der Datenstruktur über WS-Policy undWS-SecurityPolicy [WSPL1.1].Der Integritätsschutz des SecurityHeaders beinhaltet den TelematikHeader der Nachrichtsowie den gesamten SOAP Body. Alle im TelematikHeader und SOAP-Body enthaltenenInformationen können also während des Transports der Nachricht zwischen Konnektorbzw. Broker und Fachdienst nicht verändert werden, ohne die Signatur des Datenbearbeiterszu invalidieren.Der Aufbau des SecurityHeader wird nicht abgebildet. Er wird über WS-Policy beschriebenund die verwendeten Datenstrukturen sind in [WSS1.0] spezifiziert.In der TI kann zwischen signierten und unsignierten Telematiknachrichten unterschiedenwerden. Die Entscheidung, ob signierte oder unsignierte Nachrichten notwendig sind, istvon der jeweiligen Facharchitektur abhängig und wird auf Anwendungsfallebene bei derVerwendung der Dokumentenschnittstelle definiert. Sofern der Parameter SIG auf „Nein“gesetzt ist, MUSS der SecurityHeader entfallen.Die detaillierte Beschreibung der einzelnen Elemente erfolgt in Abschnitt 5.2.3.4.3.2 SOAP-BodyInnerhalb des SOAP-Bodies wird die fachliche Nutzlast der Nachricht und, sofern sie zurAuthentifizierung benötigt wird, die Signatur der Datenautorität, übertragen. Die Nutzlastbesteht aus 0 bis 200 Einträgen der Dreierkombination Name, Daten, Kodierung. Diesebewusst offen gehaltene Struktur bietet Facharchitekturen den Freiraum, logisch zusammengehörigeDaten als Paket zu transportieren. Die Möglichkeiten zur Kodierung werdenin Abschnitt 5.2.4.9 vorgegeben. Derzeit ist base64-Kodierung für den Transport von Binärdatenoder XML-Dokumenten vorgesehen. Einfache Datentypen können aber auchplain, das bedeutet ohne Kodierung, übermittelt werden.Unterhalb des SOAP-Bodies wird entweder ein Element TelematikExecute oder ein ElementTelematikExecuteUnsigned verwendet. Für die Responses müssen die zugehörigenElemente TelematikExecuteResponse und TelematikExecuteUnsignedResponse verwendetwerden. Diese Elemente sind vom gleichen XML-Typ und dienen ausschließlich zurUnterscheidung zwischen Nachrichten, die mittels WSS-Signatur integritätsgeschütztsind, und solchen, die es nicht sind. Sofern in der Spezifikation der FA der Parameter SIGauf „Nein“ gesetzt wurde, MUSS das Element TelematikExecuteUnsigned verwendetwerden und es DARF NICHT ein WSS SecurityHeader verwendet werden. Sollte dieserParameter auf „Ja“ gesetzt sein, so MUSS TelematikExecute als Element verwendet werden.Die detaillierte Beschreibung der einzelnen Elemente erfolgt in Abschnitt 5.2.4.4.4 Zuordnung der Parameter in die SOAP-NachrichtenstrukturEine Aufgabe der SOAP-Transportadaptierung ist es, eine Zuordnung der übergebenenFachdatenobjekte und Parameter in die SOAP-Nachrichtenstruktur vorzunehmen. Auf-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 32 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsbauend auf der Grobbeschreibung der Nachrichtenstruktur im Abschnitt 4.2 werden mitder nachfolgenden Tabelle die Zuordnungen beschrieben. Jedem übergebenen Parameterwertwird ein Element in der SOAP-Nachrichtenstruktur zugeordnet. Die Zuordnungenbeziehen sich auf die Bestandteile der Header und auf den Body.Tabelle 14: Zuordnung der Parameter zu Elementen der SOAP-NachrichtenstrukturParameterVerwendungParameter für die Ausführung einer FachdienstfunktionSVCPROVFDKOPETelematikHeader/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalization/GTEL:TypeTelematikHeader/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalization/GTEL:ProviderTelematikHeader/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:ComponentTelematikHeader/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:OperationParameter für die Steuerung des DatenaustauschesCIDAIDTelematikHeader/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ConversationIDTransportHeader/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:AuditIDParameter für die Absicherung des DatenaustauschesSIGIDASofern der Parameter SIG auf Ja gesetzt wurde, MUSS eine signierte SOAP-Nachricht gesendet werden und die Parameter IDA sowie IDB angegebenwerden. Die Facharchitekturen spezifizieren über diesen Parameter, ob eineNachricht signiert sein soll oder nicht. Die Entscheidung, ob in diesem Falleine WSS-Signatur und eine Payload-Signatur erfolgen, ist von den in IDA, OTund IDB angegebenen Parametern abhängig. Sofern IDA und IDB übereinstimmen,oder ObjektTickets (Parameter OT) vorhanden sind, wird nur eineWSS-Signatur verwendet.Die Verwendung einer signierten SOAP-Nachricht hat ebenfalls eine Auswirkungauf die verwendete SOAP Action wie in Abschnitt 6.2 spezifiziert.BodyDie Identität der Datenautorität wird nicht wie die vorherigen Parameter in einElement der Nachricht hineingeschrieben, sondern zur Erstellung einer XMLDSIG-Signatur der Payload verwendet. Sofern die Identität von IDB und IDAgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 33 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameterIDBEK(Liste1..X)OT(Liste1..x)ST(Liste1..x)Verwendungübereinstimmen oder ObjektTickets (Parameter OT) enthalten sind, entfällt dieSignatur der Payload.Das Format der Signatur wird in Abschnitt 5.2.4.14 beschrieben.SecurityHeader (Transportsicherheit)Die Identität des Datenbearbeiters wird nicht wie die vorherigen Parameter inein Element der Nachricht hineingeschrieben, sondern zur Erstellung einerWSS 1.0-konformen Signatur verwendet. Die Beschreibung erfolgt in Abschnitt5.2.3.BodyJeder EncryptedKey wird unterhalb des kapselnden Elements/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:EncryptedKeysin einem xenc:EncryptedKey Element transportiert.BodyFür den Transport eines ObjektTickets wird das Ticket immer im Element/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ObjectTickets/GTEL:Ticket gespeichert.Der Transport von ObjektTickets aus Fachdiensten in Richtung Konnektor istnur im Rahmen der Rechteverwaltung zulässig. Das bedeutet insbesonderefür R2 darf ausschließlich der notwendige Hybridkey (Parameter EK) übermitteltwerden.Alle zu übertragenden ObjektTickets MÜSSEN dieselbe Datenautorität habenund diese MUSS mit der Datenautorität der Nachricht (Parameter IDA) übereinstimmen.Weiterhin MÜSSEN die ObjektTickets in der Reihenfolge ihrer Erstellung in dieListe der ObjektTickets eingetragen werden. D. h. das zuletzt erstellte/geänderteObjektTicket wird als letztes Element der Liste eingetragen.Die Struktur eines ObjektTickets MUSS folgende Bedingungen erfüllen:Jedes ObjektTicket enthält eine eindeutige ObjektID als xs:string an der Position/ObjectTicket/ObjectIDJedes ObjektTicket ist von der Datenautorität XML-DSIG „embeded“ signiertund enthält die Signatur in der Struktur /ObjectTicket/ds:Signature.Jedes ObjektTicket hat einen Zeitstempel der letzten Änderung des Tickets alsxs:dateTime an der Position /ObjectTicket/LastChangeDateBody/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ServiceTickets/GTEL:TicketParameterliste für die zu übertragenen Fachdaten{PAR,ENC,FDD}(Liste1..x)Body/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parametergematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 34 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameterPARENCFDDVerwendungBody/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter/GTEL:NameBody/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter[@GTEL:Encoding]Das Attribut encoding entfällt, sofern plain als encoding des Parameters durchdie Facharchitektur vorgegeben ist.Body/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter/GTEL:Value4.5 Anwendungsfall übergreifende Parameter der FacharchitekturenNeben den Anwendungsfall spezifischen Vorgaben der Facharchitekturen gibt es allgemeineVorgaben, die durch jede Facharchitektur getroffen werden MÜSSEN, aber für alleAnwendungsfälle gelten. Hierbei kann es sich zum Beispiel um Vorgaben für den Aufbauder TelematikTransport-Nachricht oder Angaben zu zulässigen Zertifikaten handeln. Umdie Verständlichkeit zu erhöhen, sollen diese Informationen in einem standardisiertenFormat bereitgestellt werden. Das Format, sowie die für den Aufbau der Nachricht benötigtenInformationen werden analog zur Dokumentenschnittstelle nachfolgend tabellarischaufgeführt. Jede Facharchitektur MUSS das Format der Tabelle übernehmen und die inihr geforderten Informationen definieren.Tabelle 15: Anwendungsfall übergreifende Parameterliste TTDParameter Beschreibung Inhalt (Beispiel)Signatur der ResponsenachrichtZulässige Identitätenfür die Signatur desDatenbearbeitersReferenz auf dieBeschreibung derRollen und RechtezuordnungGibt an, ob eine Signatur aller Responsenachrichtennotwendig ist oder ob dies vomAnwendungsfall abhängig ist.Zulässige Einträge: Ja, NeinEs MUSS eine Auflistung der für die Signaturzulässigen Identitäten erfolgen (definiertdurch die zugehörigen Zertifikate). Es SOLLzusätzlich eine Beschreibung erfolgen, diedem Leser hilft, die Auswahl der Identitätenfür die jeweiligen Anwendungsfälle besserzu verstehen.Für jede Facharchitektur MÜSSEN für dieAutorisierung des DatenbearbeitersZugriffsrechte von Akteuren auf fachlicheOperationen festgelegt werden. Es MUSS„Ja“„HBA AUT“SMC_B OSIG… Erklärung[gemFA_xxx] Kapitel7.1 - Rechtematrixgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 35 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsParameter Beschreibung Inhalt (Beispiel)Verwendete Versionsnummerder Telematiknachricht(InterfaceVersion)Komponentenversiondes FachdienstesArt des Versichertenbezugsim Telematiktransportdurch jede Facharchitektur ein Verweis aufdas Dokument und Kapitel erfolgen, in demdie Zuordnung der Akteure zu fachlichenZugriffsrechten definiert ist.Die Dokumentation der Zugriffsrechte fürgesetzliche Rollen MUSS gemäß der Vorgabeaus Anhang A3 erfolgen.Jede Telematiknachricht MUSS eine eindeutigeVersionsnummer enthalten. DieseVersionsnummer beschreibt das Schemaund die Interpretation der Elemente derTelematiknachricht.Jede Telematiknachricht MUSS eindeutigangeben, welche Version des Fachdienstesangesprochen werden soll.Die Angabe der Version wird benötigt umAbweichungen für spätere Fachanwendungenvorzubereiten.Zulässige Optionen sind:Kein Bezug: In diesem Fall entfällt dasElement Insurant im TelematikHeader.Pseudonymer Bezug: In diesem Fall wirddas Header Element Insurant unter Verwendungdes Pseudonyms gemäß derSpezifikation in Abschnitt 5.2.2.4 befüllt.Identifier Bezug: Die Verwendung diesesBezugs ist für R2 nicht zulässig und wird fürspätere Releases definiert.Verwendung des Parameters in den FacharchitekturenDieser Parameter wird noch nicht durch alle Facharchitekturenspezifiziert. Sofern dieser Punkt in einer Facharchitekturnicht spezifiziert ist, wird Pseudonymer Bezug verwendet.„1.0.2“„2.4.1“oderGemäß Anhang XFachdienstversionoderz. B. VODD Versiongemäß DokumentenversionRelease 2.3.1„Pseudonymer Bezug“4.6 Auswahl von Brokersequenzen durch die FacharchitekturenAnhang D der Spezifikation der Broker Services [gemBroker#AnhangD] definiert ein füralle Facharchitekturen normatives Format für die Definition von Brokersequenzen in tabellarischerForm. Jede Facharchitektur MUSS die zulässigen Brokersequenzen sowie dieKombination der Headerelemente, anhand derer diese Brokersequenz erkannt wird, indem vorgegebenen Format spezifizieren.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 36 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.7 Gültigkeitszeitraum von NachrichtenJede Komponente der TI darf nur Nachrichten verarbeiten, deren Zeitstempel sie als innerhalbeines konfigurierbaren Zeitfensters liegend ausweist. Sofern sich der Zeitstempeleiner Nachricht außerhalb des Gültigkeitszeitraums befindet, MUSS die Verarbeitung miteiner Fehlermeldung abgebrochen und ein Sicherheitsevent erzeugt werden. Die Spezifikationder jeweiligen Komponenten KANN hier in begründeten Fällen eine Ausnahmemachen, sofern dem keine Sicherheitsbedenken entgegenstehen.Abbildung 6: Allgemeine Gültigkeitsdauer von TelematiknachrichtenDer Zeitstempel einer eingehenden Nachricht kann, verglichen mit der Systemzeit derverarbeitenden Komponenten (im Folgenden kurz als Systemzeit bezeichnet), in der Vergangenheitoder der Zukunft liegen, bzw. gleich der Systemzeit sein.Sofern der Zeitstempel der Nachricht in der Vergangenheit liegt, MUSS geprüft werden,ob die Zeitspanne zwischen Systemzeit und dem Zeitstempel der Nachricht größer als diekonfigurierbare Lebensdauer ist.Sofern sich der Zeitstempel der Nachricht in der Zukunft befindet, MUSS geprüft werden,ob die Zeitspanne zwischen Systemzeit und dem Zeitstempel der Nachricht größer als diekonfigurierbare Vorlaufzeit ist.Für jedes System MUSS sowohl die Lebensdauer, als auch die Vorlaufzeit unabhängigvon einander konfigurierbar sein. Im Rahmen der Implementierung MUSS für die Skalierbarkeitder Systeme eine Lebensdauer und Vorlaufzeit von 10 Minuten vorgesehen werden.Die genaue Lebensdauer und Vorlaufzeit wird durch die Betriebsorganisation dergematik festgelegt.Dies soll an einem Beispiel verdeutlicht werden. Zeitangaben sind im Format Stunde:Minute:Sekunde.Zur Vereinfachung wird hier auf die Angabe des Datums verzichtet.Systemzeit der Komponente: 14:31:17Konfigurierbare Lebensdauer:Konfigurierbare Vorlaufzeit:300 Sekunden120 Sekundengematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 37 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsHieraus ergibt sich, dass die Verarbeitung von Nachrichten deren Zeitstempel weiter inder Zukunft liegt als 14:33:17 oder weiter in der Vergangenheit liegt als 14:26:17, abgebrochenwerden müssen.Abbildung 7: Exemplarische Gültigkeitsdauer von Telematiknachrichten4.8 Gültigkeitszeitraum von Nachrichten mit ObjektTicketsIm Rahmen der Transportoptimierung wird bei Nachrichten, die ObjektTickets enthalten,auf die Signatur der Datenautorität der Payload der Nachricht verzichtet, da die Ticketsbereits eine Signatur der Datenautorität aufweisen und somit ist die Anwesendheit derDatenautorität zum Zeitpunkt der Nachrichtenerstellung prüfbar.In diesem Fall ist der in der Nachricht enthaltene Zeitstempel der Nachricht nicht durch dieDatenautorität signiert und somit kann er nicht uneingeschränkt als authentisch gelten.Wenn die Nachricht keine Signatur der Datenautorität aufweist und ObjektTickets beinhaltet,MUSS zusätzlich zu der Prüfung des Gültigkeitszeitraums der Nachricht gemäß Kapitel4.7 der Zeitpunkt der letzten Änderung des letzten ObjektTickets (im weiteren Ticket-Zeitstempel genannt) aus der Ticketliste geprüft werden. Dabei ist sicher zustellen, dassder Ticket-Zeitstempel nicht nach dem Zeitstempel der Nachricht liegt und von diesemhöchstens um eine konfigurierbare Erzeugungslatenz abweicht.Das bedeutet, dass der Zeitpunkt der Signatur der Tickets mit der Erstellung der Nachrichtin etwa zusammenfallen muss.Zusätzlich MUSS geprüft werden, dass die Zeitstempel aller ObjektTickets innerhalb eineskonfigurierbaren Zeitraums liegen und es MUSS geprüft werden, dass das letzte Objekt-Ticket aus der Liste nach allen anderen erzeugt/geändert wurde.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 38 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAbbildung 8: Gültigkeitsdauer von Telematiknachrichten mit ObjektTicket4.9 Verhinderung von Replay-AttackenBei Replay-Attacken handelt es sich um Angriffe auf die TI oder einen Fachdienst, diedarauf basieren, eine gültige Nachricht erneut zu senden. Dies könnte dazu missbrauchtwerden, dass z. B. eine Einwilligung des Versicherten, nachdem diese durch den Versichertenwiderrufen wurde, erneut eingestellt werden kann. Replay-Attacken müssen sowohldurch den Broker als auch durch die Fachdienste erkannt und abgewehrt werden.Nachfolgend werden die unterschiedlichen Typen von Replay-Attacken kurz vorgestelltund die Konzepte zur Verhinderung spezifiziert.Für die Verhinderung von Replay-Attacken ist es notwendig, diese zunächst als solche zuerkennen, um die entsprechenden Gegenmaßnahmen einzuleiten. Es kann in der TI zwischenzwei Typen von Replay-Attacken unterscheiden werden, die beide auf unterschiedlicheArt und Weise abgewehrt werden können. Diese beiden Typen sind in den nachfolgendenAbschnitten dargestellt und die entsprechenden Maßnahmen werden erläutert.4.9.1 Erneutes Senden einer bereits gesendeten NachrichtIn diesem Fall wird davon ausgegangen, dass ein Angreifer es geschafft hat, eine Nachrichtauf ihrem Weg zum Fachdienst abzufangen, und versucht, diese erneut zu senden,ohne eine Veränderung der Nachricht vorzunehmen. Die Nachricht wäre somit weiterhingültig signiert und könnte, sofern sie nicht als Replay-Attacke erkannt wird, durch denFachdienst fälschlicherweise autorisiert werden.Das Erkennen dieser Replay-Attacke erfolgt anhand einer in die Nachricht integriertenMessageID sowie eines Zeitstempels. Jede signierte Telematiknachricht enthält im SecurityHeadereinen Zeitstempel, der durch die Signatur des Datenbearbeiters (DB) geschütztist, sowie eine ebenfalls signierte MessageID. Für unsignierte Nachrichten ist der SecurityHeadernicht vorhanden. Aus diesem Grund wird für unsignierte Nachrichten imGTEL:TransportHeader ein Timestamp eingefügt, der für unsignierte Nachrichten zurReplay-Erkennung zu verwenden ist.Der Broker und die Fachdienste MÜSSEN Replay-Attacken abwehren, indem sie doppelteMessageIDs (vgl. Abschnitt 5.2.2.2 bzw. 5.2.4.12) sowie Nachrichten deren Versand-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 39 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.10 Prüfung von SignaturenEmpfänger von Nachrichten müssen ggf. die Signaturen der Nachricht (Signatur des Datenbearbeiters,Signatur der Datenautorität, etc.) prüfen und damit die Authentizität dersignierten Daten validieren. Die einzelnen Schritte zur Prüfung der Signatur sind inAbbildung 9 dargestellt und MÜSSEN durchgeführt werden. Die vorgegebene ReihenfolgeSOLL beibehalten werden.act Prüfung von SignaturenPrüfung einer SignaturMathematische Prüfungder SignaturokPrüfung der signiertenokPrüfung der verwendetenokZertifikatsprüfungokElementeAlgorithmenPrüfung desSignaturformatsFehler Fehler FehlerokFehlerFehler / AbbruchFehlerPrüfung erfolgreichAbbildung 9: Aktivitätendiagramm Prüfung von SignaturenAktivitätMathematische Prüfungder SignaturPrüfung der signiertenElementePrüfung der verwendetenAlgorithmenZertifikatsprüfungPrüfung des SignaturformatsBeschreibungDie mathematische Überprüfung der Signatur beinhaltet die Berechnung aller Hashwerteder signierten Teile, sowie den Vergleich mit dem SignatureValue der Signatur.Es muss geprüft werden, ob alle gemäß den Anforderungen spezifizierten Elemente signiertsind und keine zusätzlichen Elemente signiert wurden.Es muss geprüft werden, ob die verwendeten Signaturalgorithmen den Anforderungenentsprechen und keine unsicheren Algorithmen verwendet wurden.Es muss geprüft werden, ob das für die Signatur verwendete Zertifikat gültig ist. Eine nähereSpezifikation der Gültigkeitsprüfung wird in TUC_PKI_018 [gemVerw_Zert_TI] spezifiziert.Als Parameter Prüfzeitpunkt wird der Zeitstempel der Nachricht übergeben.Es muss geprüft werden, dass das XML-Format der Signatur den Anforderungen entspricht.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 41 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details4.11 Validierung der NachrichtJede Nachrichten verarbeitende Komponente innerhalb der TI muss im Zuge der Verarbeitungeiner Telematiknachricht vorgegebene Validierungen vornehmen. Diese Validierungensind teilweise komponentenübergreifend relevant und teilweise nur für eine spezifischeKomponente vorgesehen.4.11.1 Allgemeine Anforderungen an die Validierung der TelematiknachrichtenTabelle 16: Ausgangsanforderungen an die Validierung der Telematiknachrichten (allgemein)AFO-ID Titel AFO-Typ BeschreibungA_01513 Validierung Schemaeiner TelematiknachrichtaufKonformität WSDLund XSDA_01514 Telematiktransport:Validierung verwendeterNachrichtenelementeA_01515 Telematiktransport:Fehlertoleranz beiAbweichungen innicht verwendetenNachrichtenelementen.MUSSMUSSDARF NICHTDas Schema eingehender TelematiknachrichtenMUSS durch die empfangendeKomponente auf Konformität zurWSDL und den zugehörigen XSDs validiertwerden. Nicht zu der WSDL bzw.dem XSD konforme NachrichtenMÜSSEN mit einer Fehlermeldung zurückgewiesenwerden.Alle durch eine Komponente für die Verarbeitungbenötigten Elemente einer TelematiknachrichtMÜSSEN vor der Verwendungauf die Konformität zur inhaltlichenSchemabeschreibung validiert werden.Im Falle einer Abweichung des Inhaltsder einer Verarbeitung im Wegesteht, MUSS ein Fehler generiert werden.Eine nachrichtenempfangende KomponenteDARF Felder, die sie für ihreNachrichtenverarbeitung nicht benötigt,NICHT auf inhaltliche Übereinstimmungmit der Beschreibung gemäß[gemSpec_TTD] validieren, sofern essich nicht um eine inhaltliche Abweichunghandelt, die das WSDL- oderXSD-Schema betrifft. DementsprechendDARF die zuvor genannte inhaltlicheAbweichung auch NICHT zu einer Fehlermeldungführen.Eine inhaltliche Abweichung von derSchemabeschreibung gemäß[gemSpec_TTD] innerhalb des durch dasXSD oder die WSDL zugelassenenRahmens DARF NICHT zu einem Absturzder Komponenten oder zu undefi-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 42 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ Beschreibungnierten Zuständen führen.A_01516 Plausibilitäten einergeneriertenTelematiknachrichtMUSSJede durch eine Komponente generierteTelematiknachricht MUSS konform zuder zugehörigen WSDL und XSD sein,alle benötigten Elemente der NachrichtMÜSSEN vorhanden sein und der Inhaltaller befüllten Elemente MUSS der inhaltlichenSchemabeschreibung gemäß[gemSpec_TTD] entsprechen.Für jede Komponente, die bestehendeTelematiknachrichten weiterleitet bzw.bearbeitet und weiterleitet, nicht jedochneu generiert, gilt diese Anforderung nurfür Felder, die im Rahmen der Verarbeitungangepasst oder neu hinzugefügtwurden. Sie gilt explizit nicht für Elemente,die aus der eingegangenen Telematiknachrichtübernommen wurden.4.11.2 Anforderungen an die Validierung der Telematiknachrichten durch dieFachdiensteTabelle 17:Ausgangsanforderungen an die Validierung der Telematiknachrichten (Fachdienste)AFO-ID Titel AFO-TypBeschreibungA_01517 Validierung seitensFachdienst einerTelematiknachrichtbzgl. Broker-LokalisierungA_01518 Validierung seitensFachdienst einerTelematiknachrichtbzgl. ParameterMUSSMUSSFachdienste MÜSSEN bei eingehenden Telematiknachrichteneine Validierung der durchden Broker durchgeführten Lokalisierung vornehmenund einen Fehler generieren, soferndie Lokalisierung des Brokers zu einem falschenErgebnis geführt hatte. HierzuMÜSSEN in einem Fachdienst alle für diesenDienst gültigen Lokalisierungsmerkmale konfigurierbarsein und es MUSS beim Empfangeiner Telematiknachricht validiert werden, umso Fehler bei der Lokalisierung zu erkennen.Fachdienste MÜSSEN für alle eingehendenTelematiknachrichten überprüfen, ob die fürdie aufgerufene Operation notwendigen Parametergemäß der Facharchitektur korrektverwendet wurden und bei einer Abweichungeine Fehlermeldung generieren.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 43 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-TypBeschreibungA_03596 Validierung einerTelematiknachrichtbzgl. Dateneigentümerseitens FachdienstA_03597 Validierung einerTelematiknachrichtbzgl. ProviderGroupseitens FachdienstMUSSMUSSHandelt es sich bei dem Dateneigentümer ausdem TelematikHeader einer Nachricht umeinen Versicherten, so MÜSSEN Fachdienstenur Daten des Dateneigentümers (in diesemFall des Versicherten) verarbeiten und ggf.zurückliefern.[Hintergrund: Sonst ist die versichertenzentrierteAuditierung nicht gewährleistet.]Fachdienste MÜSSEN die Verarbeitung derNachricht mit einem TTD-Fehler (Fehlercode04001) abbrechen, wenn das Feld ProviderGroupdes Dateneigentümers aus demTelematikHeader vorhanden sein muss unddieser vom tatsächlichen Wert (selbst berechnetoder aus einem Ticket entnommen) abweicht.[Hintergrund: Sonst ist die versichertenzentrierteAuditierung nicht gewährleistet.].4.12 Tracing der TelematiknachrichtFür das Auffinden von Fehlern ist es notwendig zu verstehen, welche technischen Komponentenan der Verarbeitung einer Nachricht beteiligt waren. Die Nachverfolgung derVerarbeitung wird als Tracing bezeichnet und erfolgt im TransportHeader der Telematiknachrichtim Element GTEL:MessageTrace (Siehe Abschnitt 5.2.1.3) sowie den entsprechendenUnterelementen.Die effiziente Nutzung des Tracing kann nur erfolgen, wenn die Erzeugung der Einträgeeine komponentenübergreifende Strategie verfolgt. Diese Strategie wird nachfolgend beschrieben.Komponenten, die an der Verarbeitung einer Nachricht beteiligt sind, können unterteiltwerden in Konnektoren, Fachdienste und Anwendungsinfrastrukturdienste (wie beispielsweisedem Broker).4.12.1 KonnektorDer Konnektor DARF KEINE Einträge zum Tracing in die Telematiknachricht aufnehmen,da dies dem Grundsatz zur Verhinderung der Profilbildung widersprechen würde.4.12.2 Zentrale Anwendungs- und InfrastrukturdiensteZentrale Anwendungs- und Infrastrukturdienste, wie zum Beispiel der Broker agieren alsIntermediär bei der Verarbeitung der Nachricht und MÜSSEN mindestens einen Hop-Eintrag für jeden logischen Durchlauf der Nachricht schreiben. Request und Responsezählen hierbei als getrennte logische Durchläufe. Die genauere Spezifikation wie granula-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 44 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsre Hop-Einträge erzeugt werden müssen, wird in der Spezifikation der jeweiligen Komponentendefiniert. Das bedeutet, ob jeder Aufruf eines unterstützenden Dienstes oder abersogar verschiedene Verarbeitungsschritte zur Erzeugung eines Hop-Eintrages führen, istspezifikationsabhängig.4.12.3 FachdienstDer Fachdienst ist der Empfänger der Nachricht und MUSS als solcher genau einen Hop-Eintrag zum MessageTrace hinzufügen, bevor er die Response zurücksendet.4.13 Fehlermeldungen im TelematikTransportDer TelematikTransport spezifiziert die Kommunikation mittels Intermediären wie z. B.dem Broker. Sollte innerhalb des Transports ein Fehler auftreten, so ist dieser Fehler gemäßder Spezifikation in [gemSpec_FM] an den Initiator der Kommunikation zu melden.Damit eine automatisierte Fehlerbehandlung bei dem Initiator der Kommunikation möglichist, sollen Fehler, die auf dem Transportweg auftreten, übergreifend für alle Fachanwendungenspezifiziert werden. Die hierfür zur Verfügung stehende Liste der Fehlercodes mitder jeweils auslösenden Bedingung befindet sich in Anhang A4.Gemäß [gemSpec_FM] müssen alle Fehler als gematik SOAP-Fault oder als gematikPayload-Fehlermeldung transportiert werden. Als Ausnahme gelten Fehler, die auf dentiefen Ebenen des OSI-Stacks auftreten. Diese Fehler können nicht in allen Umgebungenabgefangen und dem Sender als gematik SOAP-Fault gemeldet werden. Dies gilt insbesonderedann, wenn Fehler auf Transportebenen wie HTTP und SSL/TLS auftreten. Analoggilt dies für Fehler, die durch SOAP-Frameworks gemäß dem SOAP 1.1 Standardgemeldet werden, ohne dass die Generierung eines gematik SOAP-Faults möglich ist. Indiesen Fällen MUSS die Komponente mit einem Fehler gemäß dem verwendeten Kommunikationsstandardantworten.Jede Komponente SOLL im Falle eines Fehlers eine Fehlermeldung gemäß[gemSpec_FM] erzeugen. In der Dokumentation der Komponenten MUSS dokumentiertund begründet werden, in welchen Fällen dies nicht möglich ist. In diesen Ausnahmefällenist es die Aufgabe des aufrufenden Intermediärs, den Fehler zu erkennen und in einenFehler gemäß [gemSpec_FM] umzuwandeln.Im Falle der Übermittlung von gematik SOAP-Faults DÜRFEN NICHT andere Elementeals die in [gemSpec_FM] definierten Error-Elemente in /Body/Fault/detail übertragen werden.Insbesondere DÜRFEN NICHT Debugging-Informationen bzw. Stacktraces übertragenwerden, um zu verhindern, dass Außenstehende auf Interna der Implementierungeines Services rückschließen können.Die Umwandlung der nicht [gemSpec_FM] konformen Fehler wird in den nachfolgendenAbschnitten beschrieben. Hierbei wird jeweils ein Fehlercode aus Anhang A4 verwendet.Die weiteren Details zur Befüllung der Fehlernachricht sind dort zu entnehmen.Es wurde hierbei bewusst gegen die Vorgabe verstoßen, dass Fehler, die aufgrund vonFehlern im Header-Bereich verursacht werden, nicht in der Payload transportiert werdensollen. Der Hintergrund ist, dass diese Vorgabe in SOAP 1.2 bereits nicht mehr bestehtund bereits durch Standards wie WSS übergangen wurde. Gleichzeitig wird davon ausgegangen,dass Fehler, die aus der Verarbeitung von syntaktisch korrekt gefüllten SOAPgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 45 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsHeadern resultieren, nicht als Header Fehler im Sinne der SOAP 1.1 Spezifikation verstandenwerden, sondern als Fehler die in der aufgerufenen Anwendung.4.13.1 Generische SOAP-FaultsJede Komponente, die einen SOAP-Fault als Antwort auf einen SOAP-Request erhält,muss unterscheiden können, ob es sich um einen gematik SOAP-Fault, also einen SOAP-Fault gemäß der Spezifikation in [gemSpec_FM] oder um einen generischen SOAP-Faulthandelt, der die benötigten Merkmale eines gematik Faults nicht enthält. Sofern es sichum einen generischen SOAP-Fault handelt, muss ein Mapping auf einen gematik SOAP-Fault durchgeführt werden.Der Entscheidungsbaum, ob es sich um einen gematik SOAP-Fault handelt und wie andernfallsmit dem SOAP-Fault zu verfahren ist, ist in Abbildung 10 dargestellt.act SOAP Fault BehandlungSOAP Fault EmpfangenIst der Faultcode= „gematikFault“NeinIst der Faultcode inder wsseFehlercodeTabelleenthalten?NeinDurchführung des SOAPMappings undFehlerbehandlung gemäß[gemSpec_FM]JaJaDurchführung derFehlerbehandlung gemäß[gemSpec_FM]Durchführung des WSSMappings undFehlerbehandlung gemäß[gemSpec_FM]Abbildung 10: Aktivitätendiagramm SOAP Fault BehandlungNach dem Empfang des SOAP-Faults wird zunächst anhand des Faultcodes entschieden,ob es sich um einen gematik SOAP-Fault handelt. Sofern der Faultcode „gematikFault“verwendet wurde, wird die in [gemSpec_FM] definierte Abarbeitung des Fehlers durchgeführt.Ein gesondertes Mapping ist nicht notwendig.Im Anschluss MUSS die Prüfung erfolgen, ob es sich um einen WSS-Fehler handelt. DerEmpfänger einer Response erkennt, ob es sich um einen WSS Fehler handelt, indem erprüft, ob der Faultcode eine Entsprechung in Tabelle 18 besitzt. Sofern dies der Fall ist,muss die aufgeführte Aktion durchgeführt werden.Tabelle 18: Mapping von WSS-Faultcodes auf gematik SOAP-FaultsFaultcode gemäß WSSAktion des Empfängers des Faultswsse:UnsupportedSecurityToken Gematik SOAP Fault mit Code 02002.wsse:UnsupportedAlgorithm Gematik SOAP Fault mit Code 02002.wsse:SecurityTokenUnavailable Gematik SOAP Fault mit Code 02002.wsse:InvalidSecurity Gematik SOAP Fault mit Code 02002.wsse:InvalidSecurityToken Gematik SOAP Fault mit Code 02004.wsse:FailedAuthentication Gematik SOAP Fault mit Code 02001.wsse:FailedCheck Gematik SOAP Fault mit Code 02003.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 46 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsSofern der eingegangene SOAP-Fault weder ein gematik SOAP-Fault noch ein WSS-Fault war, muss die Fehlerverarbeitung für sonstige Formen von SOAP-Faults durchgeführtwerden. In diesem Fall MUSS der Empfänger einen gematik SOAP-Fault mit Code01008 generieren. Das Fault Element des Bodies des ursprünglichen SOAP-Faults MUSSim Trace der Nachricht als base64 kodiertes XML mitgeliefert werden.4.13.2 Fehler auf HTTP VerbindungsebeneSollte während der Kommunikation zwischen zwei Komponenten ein HTTP Fehler auftreten,so MUSS dieser Fehler durch den Sender der Nachricht erkannt werden und es mussein gematik SOAP-Fault generiert werden. Gemäß http Spezifikation werden http Fehlercodeszwischen 100 und 599 verwendet. Dieser Fehlercode MUSS als Fehlercode in demgematik SOAP-Fault übernommen werden. Die weitere Befüllung der Fehlernachrichterfolgt gemäß Anhang A4.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 47 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5 Detaillierte Beschreibung der NachrichtenstrukturDie nachfolgenden Abschnitte beschreiben die einzelnen Elemente der SOAP-Nachrichtenstruktur.5.1 Übergreifende Festlegungen5.1.1 Verwendung von PrefixesInnerhalb der Nachrichtenbeschreibung werden Prefixes für die einfachere Beschreibungder Namespaces verwendet. Die in Tabelle 19 definierten Prefixes finden in der Beschreibungder Nachricht Verwendung. Die Verwendung der Prefixes für die gesendeten Nachrichtenist freigestellt.Tabelle 19: Verwendung von PrefixesPrefixxss11GTELdsxencwsuwsseNamespacehttp://www.w3.org/2001/XMLSchemahttp://schemas.xmlsoap.org/soap/envelope/http://ws.gematik.de/tel/transport/http://www.w3.org/2000/09/xmldsig#http://www.w3.org/2001/04/xmlenc#http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsdhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsdAnhang A1 definiert die Versionsübersicht für die anzuwendenden Schemaversionen.5.1.2 Transport von ObjektID als ID-AttributDie ObjektID ist eine UUID gemäß [gemGesArch] und dessen erste Ziffer ist ein nummerischerWert. Die Definition des Attributs-Typs xs:ID verlangt aber, dass dessen Inhalt miteinem Buchstaben bzw. ‚_’ (Unterstrich) beginnen muss.Für die Angabe des ObjektID als ein Attribut des Types xs:ID MUSS ein ‚OID-’ als Präfixvorangestellt werden. Beim Lesen eines solchen Wertes MUSS der Präfix wieder entferntwerden.Beispiel:ObjektID:ID-Attribut:07ac0c78-998a-4a54-b5c6-431960cacea2OID-07ac0c78-998a-4a54-b5c6-431960cacea2gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 48 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2 Beschreibung der einzelnen Elemente5.2.1 Elemente des GTEL:TransportHeaderDie folgende Abbildung zeigt eine graphische Darstellung des ElementesGTEL:TelematikHeader. Die Beschreibung der Subelemente erfolgt in den nachfolgendenAbschnitten.Abbildung 11: Graphische Darstellung des Elementes TransportHeader5.2.1.1 GTEL:TransportHeaderXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeaderxs:complexTypeNeinDas Element GTEL:TransportHeader dient zur Kapselung vonInformationen, die keines Integritätsschutzes bedürfen.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt. Das Element MUSS ein s11:mustUnderstand Attributenthalten, dessen Wert auf „1“ gesetzt ist.Informative Beispiele …Element Verwendung– SchreibendElement Verwendung– LesendJede Komponente, die eine Nachricht erstellt, befüllt das Element.Jede Komponente, die eine Nachricht empfängt und verarbeitet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 49 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseDer TransportHeader muss in der Response verwendet werden.Die Inhalte der einzelnen Elemente sind elementabhängig.5.2.1.2 GTEL:InterfaceVersionXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:InterfaceVersionxs:stringNeinDas Element GTEL:InterfaceVersion ist verpflichtend und MUSSin jeder TelematikTransportnachricht enthalten sein. Es enthältdie Version der verwendeten Transport-Interfaces. Die Beschreibungdes Versionierungs-Konzeptes erfolgt in[gemSpec_VersNr].Die InterfaceVersion der vorliegenden Version des Schemas ist inAnhang A1 – Versionsübersicht spezifiziert.Das Format von GTEL:InterfaceVersion ist in[gemSpec_VersNr#7.2.1] beschrieben.Informative Beispiele 1.4.3Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Jede Komponente, die eine Nachricht empfängt und verarbeitet.Die InterfaceVersion wird in der Response verwendet und MUSSidentisch sein mit der InterfaceVersion des Requests.5.2.1.3 GTEL:MessageTraceXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:MessageTracexs:complexTypeJaDieses optionale Element darf nur in einer Nachricht enthaltensein, wenn es Unterelemente enthält und diese gefüllt sind.Das Element MessageTrace dient zur Verfolgung der Nachrichtund somit als Grundlage für die Fehleranalyse. Es hat selbst keinenInhalt, enthält aber einen Hop-Eintrag für jede Komponente,die an der Verarbeitung der Nachricht beteiligt war. Einzige Ausnahmebildet der Konnektor, durch ihn wird kein Hop-Eintrag geschrieben.Das Element enthält ausschließlich Child-Elemente aber keineneigenen Inhalt.Informative Beispiele gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 50 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details……Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie Strategie, welche Komponenten Hop-Einträge erzeugen, istin Abschnitt 4.12 beschrieben.Automatische Verarbeitung des Elementes erfolgt nicht. Es dientlediglich zur Fehleranalyse.Das Element MessageTrace inklusive seiner Inhalte wird in dieResponse übernommen und durch jede Komponenten fortgeschrieben.5.2.1.4 GTEL:HopXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:MessageTrace/GTEL:Hopxs:complexTypeNeinJede Komponente (ausgenommen der Konnektor) inklusive allerIntermediäre, die an der Verarbeitung der Nachricht beteiligt sind,fügt einen Hop-Eintrag hinzu.Das Element enthält ausschließlich Child-Elemente aber keineneigenen Inhalt.Informative Beispiele ………Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie Strategie, welche Komponenten Hop-Einträge erzeugen, istin Abschnitt 4.12 beschrieben.Automatische Verarbeitung des Elementes erfolgt nicht. Es dientlediglich zur Fehleranalyse.Siehe Beschreibung des Elementes GTEL:MessageTrace(5.2.1.3).gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 51 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.1.5 GTEL:SequenceXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:MessageTrace/GTEL:Hop/GTEL:Sequencexs:byteNeinDie Sequence dient dazu, die Reihenfolge der Hops zu bestimmen.Es handelt sich hierbei um eine über alle Hops fortlaufendeZahl.Der Datentyp Byte deckt den Wertebereich -127 bis 127 ab. Fürdie Verwendung zur Nummerierung der Hops sind negative Werteunsinnig und es ist auch ein viel kleinerer Bereich ausreichend.Aus diesem Grund darf nur der Wertebereich 1 bis 127 verwendetwerden.Informative Beispiele 5Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie Strategie, welche Komponenten Hop-Einträge erzeugen, istin Abschnitt 4.12 beschrieben.Automatische Verarbeitung des Elementes erfolgt nicht. Es dientlediglich zur Fehleranalyse.Siehe Beschreibung des Elementes GTEL:MessageTrace(5.2.1.3)5.2.1.6 GTEL:NameXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:MessageTrace/GTEL:Hop/GTEL:Namexs:stringNeinDas Element GTEL:Name dient dazu, die Komponente, die ander Verarbeitung der Nachricht beteiligt war, eindeutig zu identifizieren.Es handelt sich hierbei um eine eindeutige Kennung derKomponente, die zentral durch die gematik vergeben wird. Diesemuss für jede Komponenten konfigurierbar sein, ist nach dieserKonfiguration aber fest.Der Komponentenname ist eine Aneinanderreihung der BetreiberIDgemäß [gemSysSLM], dem in der jeweiligen Spezifikationoder Architektur spezifizierten Komponentenkürzel und einemdurch den Betreiber frei wählbaren Merkmal, das dem Betreibereinen Rückschluss auf die verarbeitende Instanz ermöglicht. DieVerbindung der einzelnen Bestandteile erfolgt nach dem folgendenMuster.BetreiberID.KomponentenTyp.Instanzmerkmalgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 52 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInformative Beispiele 4711.VODD.Server17Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie Strategie, welche Komponenten Hop-Einträge erzeugen, istin Abschnitt 4.12 beschrieben.Automatische Verarbeitung des Elementes erfolgt nicht. Es dientlediglich zur Fehleranalyse.Siehe Beschreibung des Elementes GTEL:MessageTrace(5.2.1.3).5.2.1.7 GTEL:TimeXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:MessageTrace/GTEL:Hop/GTEL:Timexs:dateTimeNeinDas Element GTEL:Time dient dazu, den Zeitpunkt der Verarbeitungdurch eine Komponente zu dokumentieren.Das Format entspricht xs:dateTime mit verpflichtender Angabeder Zeitzone. Als Zeitzone wird die Verwendung von UTC empfohlen.Informative Beispiele 2001-12-17T09:30:47.0ZElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie Strategie, welche Komponenten Hop-Einträge erzeugen, istin Abschnitt 4.12 beschrieben.Automatische Verarbeitung des Elementes erfolgt nicht. Es dientlediglich zur Fehleranalyse.Siehe Beschreibung des Elementes GTEL:MessageTrace(5.2.1.3).5.2.1.8 GTEL:AuditIDXPATHDatentypOptionalInhaltliche Beschreibung/s11:Envelope/s11:Header/GTEL:TransportHeader/GTEL:AuditIDxs:stringJaDieses optionale Element darf nur in einer Nachricht enthaltensein, wenn die Verwendung durch die Facharchitektur explizitgefordert wird. Das Element muss, wenn es enthalten ist, mit einergültigen AuditID befüllt sein.Das optionale Element GTEL:Audit erlaubt es, mehrere Nachrichten,die zusammen einen Eintrag im AuditLog darstellen, zu korrelieren.Die Verwendung dieses Elementes ist derzeit nicht vorgesehen,aber perspektivisch für neue FAs möglich. Um eine Anpassungdes Schemas, die sich auf alle Komponenten auswirken würde,zu diesem Zeitpunkt zu vermeiden, wird dieses Element bereitsgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 53 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsNormative Beschreibungdes Formatesjetzt optional vorgesehen.Die Verwendung dieses Elementes DARF im derzeitigen Releasenicht zu einem Fehler und Abbruch der Verarbeitung führen,SOLL aber in den Logdateien als Warning auftauchen.Die Audit ID ist eine Zeichenkette mit 1 bis 120 Zeichen. ZulässigeZeichen sind [A-Za-z0-9] sowie „.“ und „-“.Informative Beispiele 234wqetq6h3fElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element dient der perspektivischen Erweiterung.Das Element dient der perspektivischen Erweiterung.Das Element dient der perspektivischen Erweiterung.5.2.1.9 wsu:TimestampXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TransportHeader/wsu:Timestampwsu:TimestampTypeJaDieses optionale Element MUSS in unsignierten Nachrichten enthaltensein. In signierten Telematiknachrichten darf es nicht enthaltensein.Das Element wsu:TimeStamp dient dazu, Replay-Attacken abzuwehrenund die Vorhaltezeit für MessageIDs zu verkürzen. DasElement ist für alle nicht durch einen Datenbearbeiter signiertenNachrichten verpflichtend. In Nachrichten die durch einen Datenbearbeitersigniert wurden, darf dieses Element nicht verwendetwerdenDas Format entspricht wsu:TimeStamp mit verpflichtender Angabeder Zeitzone. Der Timestamp MUSS ein wsu:Created Subelemententhalten, in dem die Zeit der Erzeugung der Nachrichtangegeben ist. Das Element darf kein wsu:Expires Subelemententhalten. Die Angabe des Timestamp muss konform zu [BasicSecurity Profile] Kapitel 6. Timestamps erfolgen.Informative Beispiele 2001-12-17T09:30:47.0ZElement Verwendung– SchreibendElement Verwendung– LesendDer Absender der Nachricht (Konnektor bzw. Broker) und derFachdienst tragen die aktuelle Systemzeit vor dem Versendeneiner unsignierten Nachricht ein.Das Element wird durch die die Nachricht empfangende Komponentefür unsignierte Nachrichten ausgewertet, um zu prüfen, obdie Gültigkeit abgelaufen ist. Die Gültigkeitsprüfung erfolgt gemäßgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 54 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAbschnitt 4.7.Element Verwendung– ResponseDas Element muss für alle unsignierten Responses mit der aktuellenSystemzeit gefüllt werden.5.2.2 Elemente des GTEL:TelematikHeaderAbbildung 12 zeigt eine graphische Darstellung des Elementes GTEL:TelematikHeader.Die Beschreibung der Subelemente erfolgt in den nachfolgenden Abschnitten.Abbildung 12: Graphische Darstellung des Elementes GTEL:TelematikHeader5.2.2.1 GTEL:TelematikHeaderXPATH/s11:Envelope/s11:Header/GTEL:TelematikHeadergematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 55 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formatesxs:complexTypeNeinDas Element GTEL:TransportHeader dient zur Kapselung vonInformationen, die integritätsgeschützt werden müssen.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt. Das Element MUSS ein s11:mustUnderstand Attributenthalten, dessen Wert auf „1“ gesetzt ist und KANN einwsu:Id Attribut enthalten, das zur Referenzierung durch die WSS-Signatur verwendet wird. Sofern keine WSS-Signatur gefordertwird, MUSS dieses Attribut entfallen.Informative Beispiele …Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Jede Komponente, die eine Nachricht empfängt und verarbeitet.Der TelematikHeader MUSS in der Response verwendet werden.Die Inhalte der einzelnen Elemente sind elementabhängig.5.2.2.2 GTEL:MessageID (TelematikHeader)XPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageIDxs:stringNeinDie MessageID dient zur eindeutigen Identifizierung einer Nachricht.Eine MessageID ist eine Objekt-ID gemäß der Spezifikation in[gemGesArch], String Repräsentation gemäß RFC 4122.Informative Beispiele 6f638460-b2d6-11db-abbd-0800200c9a66Element Verwendung– SchreibendElement Verwendung– LesendDie MessageID wird durch das die Nachricht initiierende Systemeingestellt. Nachricht initiierende Systeme sind beispielsweise:der Konnektor für Nachrichten an Fachdiensteder Broker für Nachrichten an den AuditservicePerspektivisch können auch andere Systeme als Nachrichteninitiierend spezifiziert werden.Die MessageID wird durch den Empfänger bzw. Intermediär zurAbwehr von Replay-Attacken verwendet. (Siehe auch Abschnitt4.9.2)gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 56 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseDie MessageID wird in die Response übernommen und MUSSidentisch zur MessageID des Requests sein.5.2.2.3 GTEL:ConversationIDXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ConversationIDxs:stringJaDie ConversationID darf nur enthalten sein, wenn dies durch dieFacharchitektur vorgegeben ist und muss dann mit einem gültigenWert befüllt sein. Die Verwendung einer leeren ConversationIDist nicht zulässig.Die ConversationID dient dazu, eine Folge von Nachrichten, diezusammen gehören, korrelieren zu können. Ein Beispiel hierzuwäre ein VSD-Stammdatenupdate. Hierbei werden für ein Updatemöglicherweise mehrere Nachrichten versandt. Damit der Fachdienstdiese jeweils einander zuordnen kann, werden sie alle mitder gleichen ConversationID versehen. Die Entscheidung, ob derAbsender oder der Fachdienst die ConversationID vergibt und inwelchen Fällen die ConversationID aus einer früheren Nachrichtübernommen werden soll, wird durch die Facharchitekturen definiert.Ein Fachdienst, der die Verwendung von ConversationID unterstützt,SOLL für die Gültigkeit der Daten zu einer ConversationIDeinen konfigurierbaren Timeout vorsehen. Der TimeoutzählerMUSS bei jedem Zugriff für eine bestimmte ConversationID zurückgesetztwerden. Die Facharchitekturen KÖNNEN Facharchitektur-spezifischeine Mindest-Timeout definieren.Im Rahmen der Implementierung MUSS für die Skalierbarkeit derSysteme ein Timeout von 1 Minute vorgesehen werden. Der genaueTimeout wird durch die Betriebsorganisation der gematikfestgelegt.Die ConversationID ist eine Zeichenkette mit 1 bis 60 Zeichen.Zulässige Zeichen sind [A-Za-z0-9] sowie „.“ und „-“.Informative Beispiele sdfli3h4p9wersdfwcfwElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie ConversationID wird abhängig von der Definition der FA entwederdurch den Absender oder den Fachdienst vergeben.Die ConversationID wird durch den Empfänger für die Zuordnungeiner Folge von Nachrichten verwendet. Der Zweck dieser Zuordnungund die sich daraus ergebenden Handlungen müssen inder FA definiert werden.Die Verwendung der ConversationID in der Response-Nachrichtist von der Facharchitektur abhängig.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 57 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.2.4 GTEL:InsurantXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:Insurantxs:complexTypeInformative Beispiele …Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJaDie Verwendung des Elementes ist von der Art des Versichertenbezugs,gemäß dem Anwendungsfall übergreifenden ParameterVersichertenbezug in den Facharchitekturen spezifiziert.Das Element GTEL:Insurant kapselt den Versichertenbezug unddient somit als Ordnungskriterium in Fachdiensten und als Ordnungskriteriumfür die versichertenzentrierte Auditierung. DasElement ist für alle Nachrichten, die sich auf nur einen Versichertenbeziehen, verpflichtend. In der Kommunikation zwischen Brokerund Auditdienst zum Zwecke der Auditierung (writeAudit) darfdieses Element nicht verwendet werden, da hier eine Liste vonAudit-Einträgen unabhängig vom Versicherten übertragen werdenkann.Die Facharchitekturen SOLLEN sich für den Versichertenbezugauf dieses Element beziehen. Dies ist jedoch nicht für alle Fachanwendungendirekt möglich. Ein Beispiel wären hier Dienste desCard2Server Kommunikationsmusters. Dienste, die den Versichertenbezugnicht direkt aus der Nachricht entnehmen können,MÜSSEN über ihre Abläufe sicherstellen, dass bei etwaiger Nennungeines Versicherten in den Parametern eine Übereinstimmungvorliegt. Dies ist notwendig, da nur so sichergestellt werdenkann, dass für den richtigen Versicherten auditiert wurde und einAngreifer einen Zugriff nicht verschleiern kann. Falls eine Diskrepanzzwischen dem Versichertenmerkmal in der Nachricht unddem der Payload vorliegt, MUSS die Verarbeitung mit einem Sicherheitsfehlerabgebrochen werden.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt.GTEL:Insurant wird durch den Konnektor geschrieben.Der Intermediär verwendet dieses Element zur Lokalisierung desAuditdienstes.Empfänger verwenden dieses Element als Ordnungskriterium.Das Element Insurant MUSS in der Response entfallen und darfnicht verwendet werden. Da die Informationen beiden Kommunikationsteilnehmernbekannt sind, würde ein erneutes Versendenpersonenbezogener Daten dem Sicherheitsziel Datensparsamkeitgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 58 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailswidersprechen.5.2.2.5 GTEL:IdentifierXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:Insurant/GTEL:Identifierxs:stringChoice (Identifier / Pseudonym)Die Verwendung des Elementes ist von der Art des Versichertenbezugs,gemäß dem Anwendungsfall übergreifenden ParameterVersichertenbezug in den Facharchitekturen spezifiziert.Das Element dient zur eindeutigen Identifizierung des Versichertenund kann ein von dem Pseudonym abweichendes eindeutigesMerkmal des Versicherten, das in einem seiner Zertifikate enthaltenist, wie zum Beispiel die KVNR, enthaltenDie Facharchitektur legt fest, welches eindeutige Merkmal zuverwenden ist. Je nach Art des eindeutigen Merkmals ist derenSpezifikation für die Bestimmung des Formates heranzuziehen.Informative Beispiele 922939D274609328C54FElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird bei dem Erstellen der Nachricht durch den Absendergeschrieben.Empfänger verwenden dieses Element als Bestandteil des Ordnungskriteriums.Siehe Beschreibung des Elementes GTEL:Insurant (5.2.2.4)5.2.2.6 GTEL:PseudonymXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:Insurant/GTEL:Pseudonymxs:stringChoice (Identifier / Pseudonym)Die Verwendung des Elementes ist von der Art des Versichertenbezugs,gemäß dem Anwendungsfall übergreifenden ParameterVersichertenbezug in den Facharchitekturen spezifiziert.Das Element GTEL:Pseudonym enthält das Pseudonym des Versicherten.Das Pseudonym des Versicherten ist aus dem CommonNamedes AUT.N-Zertifikates des Versicherten zu entnehmen.Es handelt sich um die String-Repräsentation eines 20-stelligenHex-Wertes. Die Bildung des Pseudonyms wird in[gemX.509_eGK] definiert.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 59 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInformative Beispiele 922939D274609328C54FElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:Pseudonym wird durch den Absender geschrieben.Der Intermediär verwendet dieses Element zur Erstellung einerAuditnachricht.Empfänger verwenden dieses Element als Bestandteil des Ordnungskriteriums.Siehe Beschreibung des Elementes GTEL:Insurant (5.2.2.4).5.2.2.7 GTEL:IssuerDomainXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:Insurant/GTEL:IssuerDomainxs:stringNeinDas Element GTEL:IssuerDomain enthält den Issuer Name derausstellenden CA als Distinguished Name (DN). Dies wird ausdem Issuer Attribut des AUT.N Zertifikats des Versicherten entnommen.Das Issuer Attribut wird in [gemX.509_eGK] definiert. Die StringDarstellung im Element IssuerDomain MUSS gemäß [RFC2253]erfolgen.Gemäß [RFC2253] wird das Komma als Trennzeichen zwischeneinzelnen RelativeDistinguishedNames und das Gleichheitszeichenals Trennzeichen zwischen AttributType und Value bei derErzeugung der Stringrepräsentation spezifiziert (vgl. [RFC2253]Absatz 2.1 und 2.3)[RFC2253] fordert zur Abwärtskompatibilität zusätzlich, dass beidem Auflösen der Stringrepräsentation zusätzlich auch Semikolonsanstelle des Kommas verstanden werden müssen und Whitespacesauf beiden Seiten des Trennzeichens zulässig sind.Diese Abwärtskompatibilität ist in der TI nicht notwendig und derEmpfänger einer Nachricht MUSS einen Fehler generieren, soferndie Angabe der IssuerDomain ein anderes Trennzeichen alsein Komma enthält oder wenn whitespaces vor bzw. hinter einemTrennzeichen auftreten.Informative Beispiele CN=gematik eGK TestreferenzCA01,OU=Testreferenz,O=gematik,C=DEElement Verwendung– SchreibendElement Verwendung– LesendGTEL:IssuerDomain wird durch den Konnektor geschrieben.Der Intermediär verwendet dieses Element zur Erstellung einerAuditnachricht.Empfänger verwenden dieses Element als Bestandteil des Ordnungskriteriums.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 60 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseSiehe Beschreibung des Elementes GTEL:Insurant (5.2.2.4).5.2.2.8 GTEL:ProviderGroupXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:Insurant/GTEL:ProviderGroupxs:intNeinDas Element GTEL:ProviderGroup findet zwei Verwendungen,die über den Wertebereich des Elementes getrennt sind. DerWertebereich 0-999 dient zur anonymen, zufälligen aber gleichmäßigenZuordnung von Versicherten zu Betreibergruppen. DieseGruppen können z. B. als Lokalisierungsmerkmal für alleDienste verwendet werden, bei denen aus Sicherheitsgründenmehr als ein Dienst gleichen Typs bestehen muss, die Instanzdes Dienstes durch den Versicherten nicht frei gewählt werdenkann und wo der Dienst für einen Versicherten kartenübergreifendidentisch sein muss. Diese Anforderung besteht zunächstnur für den Audit Service. Die Art der Lokalisierung ist aber füralle Dienste, bei denen diese Art der Lokalisierung verwendetwird, vorgesehen.Der Wert des Elementes wird berechnet als:SHA1-Hashwert über dem unveränderlichen Bestandteil derKVNR. Für diesen Hashwert wird eine Restwertdivision mit 1000durchgeführt und das Ergebnis eingetragen.In anderer Darstellung bedeutet dies:(SHA1(unveränderlicher Bestandteil der KVNR)) MOD 1000Der unveränderliche Anteil der KVNR kann gemäß[gemX.509_eGK] Abschnitt 4.5 aus dem AUT Zertifikat des Versichertenausgelesen werden.Der Wertebereich 1000-2000 ist für weitere Verwendungszweckeinnerhalb der Telematikinfrastruktur vorgesehen.Das Element ist ein Integer-Wert im Wertebereich 0-2000.Informative Beispiele 177Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:ProviderGroup wird durch den Absender geschrieben.Der Intermediär verwendet dieses Element zur Lokalisierung desAuditdienstes.Empfänger verwenden dieses Element als Bestandteil des Ordnungskriteriums.Siehe Beschreibung des Elementes GTEL:Insurant (5.2.2.4).gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 61 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.2.9 GTEL:ServiceLocalizationXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalizationxs:complexTypeNeinDas Element ServiceLocalization wird durch den Broker für dieLokalisierung eines Fachdienstes verwendet. Es hat selbst keinenInhalt, kapselt aber die für die Lokalisierung notwendigenInhalte.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt.Informative Beispiele ……Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Das Element wird durch den Intermediär zur Lokalisierung desFachdienstes verwendet.Das Element ServiceLocalization inklusive seiner Subelementewird in die Response übernommen.5.2.2.10 GTEL:TypeXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalization/ GTEL:Typexs:stringNeinDas Element GTEL:Type enthält den Typ des Fachdienstes, anden eine Anfrage gerichtet ist. Jede Facharchitektur definiert dasfür sie gültige Kürzel.Das Element GTEL:Type ist ein String bestehend aus 1 bis 16Großbuchstaben (A..Z).Informative Beispiele VODDElement Verwendung– SchreibendElement Verwendung– LesendGTEL:Type wird durch den Absender geschrieben und vom Empfängerin die Response übernommen.Der Intermediär verwendet GTEL:Type für die Lokalisierung desEmpfängers und kann, sofern dies notwendig ist, auch zur Bestimmungder Brokersequenz mit herangezogen werden.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 62 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseSiehe Beschreibung des Elementes GTEL:ServiceLocalization(5.2.2.9).5.2.2.11 GTEL:ProviderXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalization/GTEL:Providerxs:stringJaDas Element Provider darf nur verwendet werden, wenn durchdie Facharchitektur ein Providermerkmal spezifiziert ist. Die Angabeeines leeren Elementes ist nicht zulässig.Das Element GTEL:Provider enthält das Kennzeichen für die denFachdienst bereitstellende Organisation. Diese Organisation istnicht zwangsläufig der Betreiber. Z. B. im Falle VSD sind die bereitstellendenOrganisationen die Kostenträger. Somit wäre indiesem Fall das Provider-Merkmal die IK-Nummer der eGK desVersicherten. Sofern die Notwendigkeit das Providermerkmal zunutzen besteht, muss die FA die genaue Verwendung des Elementesdefinieren.Das Element GTEL:Provider ist eine ASCII-Zeichenkette aus 1bis 60 Zeichen. Sofern eine Spezifikation des Inhalts durch dieFacharchitektur erfolgt, SOLLEN ausschließlich die Zeichen [A-Za-z0-9] sowie „.“ und „-“ verwendet werden.Informative Beispiele 345isodf089234Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Der Intermediär verwendet dieses Element zur Lokalisierung desEmpfängers.Siehe Beschreibung des Elementes GTEL:ServiceLocalization(5.2.2.9).5.2.2.12 GTEL:InstanceRefXPATHDatentypOptionalInhaltliche Beschreibung/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:ServiceLocalization/InstanceRefxs:stringJaDie InstanceRef kann zur direkten Adressierung eines Fachdienstesverwendet werden. Falls eine Folge von Nachrichten für einenVersicherten an den gleichen Fachdienst gesendet werden soll,so ist die Lokalisierung des Fachdienstes nicht für jede dieserNachrichten notwendig. Der Konnektor kann das Ergebnis dergematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 63 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsersten Lokalisierung cachen und in den Folgenachrichten verwenden.Normative Beschreibungdes FormatesDas Element GTEL:InstanceRef ist ein Kürzel.Informative Beispiele in Klärung – Die Verwendung im Rahmen des R2 ist nicht zulässigElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:InstanceRef wird als Ergebnis der Lokalisierung einesEmpfängers durch den Broker geschrieben. Der Empfängerübernimmt dieses Ergebnis in die Antwortnachricht und fürFolgenachrichten wird es durch den Absender verwendet.Der Intermediär verwendet dieses Element zur Lokalisierung desEmpfängers.Siehe Beschreibung des Elementes GTEL:ServiceLocalization(5.2.2.9).Offener Punkt für R3 – Verwendung des Elementes InstanceRefDie genaue Spezifikation des Elementes InstanceRef ist derzeit in Klärung.5.2.2.13 GTEL:MessageTypeXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageTypexs:complexTypeNeinDas Element GTEL:MessageType dient zur Identifizierung desNachrichtentyps und dadurch auch zur Bestimmung der für diesenNachrichten-Typ notwendigen Elemente und Name/Value-Paare der Parameterliste der Payload.Es wird durch den Broker zur Bestimmung der Brokersequenzund durch den Fachdienst für die Bestimmung der Fachlichkeit,die zur Beantwortung der Anfrage relevant ist, verwendet und umzu erkennen, welche Payload er zu erwarten hat.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt.Informative Beispiele …………Element Verwendung– SchreibendElement Verwendung– LesendJede Komponente, die eine Nachricht erstellt, befüllt das Element.Das Element wird durch den Intermediär zur Bestimmung derBrokersequenz verwendet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 64 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseDas Element wird inklusive seiner Unterelemente in die Responsenachrichtübernommen.Der Inhalt des Elementes ConversationStatus kann, wenn notwendig,angepasst werden.5.2.2.14 GTEL:ComponentXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:Componentxs:stringNeinDas Element GTEL:Component dient zur Unterscheidung verschiedenerKomponenten (Interfaces) innerhalb eines Fachdienstes.Jeder Fachdienst enthält sowohl eine Komponente für diefachliche Verarbeitung einer Nachricht, und in den meisten Fachdienstenist auch eine Komponente für die Abfrage von Tickets(Ticketservice) und für die Rechteverwaltung durch den Versicherten(AdV) enthalten. Das Element GTEL:Component ermöglichteine Zuordnung der Nachricht, so dass die Webservices allerKomponenten eines Fachdienstes unter der gleichen URL erreichbarsind.Das Element GTEL:Component ist eine ASCII-Zeichenkette 1 bis10 Zeichen. Jede Facharchitektur definiert die durch sie spezifiziertenKomponenten. Durch die gematik erfolgt eine interneÜberprüfung zur Verhinderung von Duplikaten.Bei der Spezifikation des Inhalts durch die Facharchitektur,SOLLEN ausschließlich die Zeichen [A-Za-z0-9] sowie „.“ und „-“verwendet werden.Informative Beispiele TSElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Der Intermediär verwendet dieses Element zur Bestimmung derBrokersequenz und der Empfänger für die Zuordnung der Nachrichtzu der entsprechenden Komponente.Siehe Beschreibung des Elementes GTEL:MessageType(5.2.2.13).5.2.2.15 GTEL:ComponentVersionXPATHDatentypOptional/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:ComponentVersionxs:stringNeingematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 65 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInhaltliche BeschreibungNormative Beschreibungdes FormatesDas Element GTEL:ComponentVersion ist verpflichtend undMUSS in jeder TelematikTransportnachricht enthalten sein. Esenthält die Version der verwendeten Komponente eines Dienstes.Im Gegensatz zur InterfaceVersion beschreibt sie nicht die Versiondes Schemas der Telematiknachricht, sondern die Versiondes Schemas der fachlichen Komponente und somit der relevantenParameter.Die Definition des Inhalts der ComponentVersion erfolgt durch dieFacharchitekturen über die den Anwendungsfall übergreifendeParameterliste als „Komponentenversion des Fachdienstes“.Die Beschreibung des Versionierungskonzeptes erfolgt in[gemSpec_VersNr#8].Das Format von GTEL:ComponentVersion ist in[gemSpec_VersNr#8] beschrieben.Informative Beispiele 1.0.0Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:ComponentVersion wird durch den Absender geschrieben.Der Intermediär verwendet dieses Element zur Bestimmung derBrokersequenz, der Empfänger für die Zuordnung der Nachrichtzu der entsprechenden Komponente.Siehe Beschreibung des Elementes GTEL:MessageType(5.2.2.13).5.2.2.16 GTEL:OperationXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:Operationxs:stringNeinDas Element GTEL:Operation beschreibt die Funktionalität, diemit dem Inhalt dieser Funktion durchgeführt werden soll. DieseFunktion ist von der Facharchitektur abhängig.Das Element GTEL:Operation ist eine ASCII-Zeichenkette aus 1bis 60 Zeichen. Die für dieses Element zulässigen Schlüsselwortesind von der jeweiligen Facharchitektur abhängig und durch diesedefiniert.Bei der Spezifikation des Inhalts durch die Facharchitektur,SOLLEN ausschließlich die Zeichen [A-Za-z0-9] sowie „.“ und „-“verwendet werden.Informative Beispiele WriteVOElement Verwendung– SchreibendElement Verwen-Jede Komponente, die eine Nachricht erstellt, befüllt das Element.Der Intermediär kann dieses Element zur Bestimmung der Brokersequenzverwenden, sofern dies durch die FA vorgesehen ist.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 66 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsdung – LesendElement Verwendung– ResponseDer Empfänger bestimmt die für die Durchführung erwarteteFunktion.Siehe Beschreibung des Elementes GTEL:MessageType(5.2.2.13).5.2.2.17 GTEL:ConversationStatusXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:MessageType/GTEL:ConversationStatusxs:stringJaDas Element MUSS verwendet werden, sofern die Verwendungdurch die Facharchitektur spezifiziert ist. Das Element DARFNICHT in einer Nachricht enthalten sein, wenn diese nicht durchdie Facharchitektur gefordert ist.Das Element GTEL:ConversationStatus beschreibt für eine Folgevon Nachrichten den Status des Ablaufs. Die konkrete Verwendungdes Elementes muss durch die Facharchitektur definiertwerden.Das Element GTEL:ConversationStatus ist eine ASCII-Zeichenkette aus 1 bis 10 Zeichen. Die für dieses Element zulässigenSchlüsselworte sind von der Facharchitektur abhängig. Soferndieses Merkmal verwendet werden soll, definiert die Facharchitekturdie zulässigen Schlüsselworte.Bei der Spezifikation des Inhalts durch die Facharchitektur,SOLLEN ausschließlich die Zeichen [A-Za-z0-9] sowie „.“ und „-“verwendet werden.Informative Beispiele closingElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:ConversationStatus wird durch den Absender und demEmpfänger in der Response geschrieben.Der Empfänger verwendet dieses Element für die Durchführungder erwarteten Funktion, sofern dies durch die Facharchitekturvorgesehen ist.Siehe Beschreibung des Elementes GTEL:MessageType(5.2.2.13).5.2.2.18 GTEL:RoleDataProcessorXPATHDatentypOptional/s11:Envelope/s11:Header/GTEL:TelematikHeader/GTEL:RoleDataProcessorxs:stringJaDas Element darf nur durch den Broker im Rahmen dergematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 67 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInhaltliche BeschreibungNormative Beschreibungdes FormatesAnonymisierung in die Nachricht aufgenommen werden.Das Element GTEL:RoleDataProcessor enthält nach derAnonymisierung einer Nachricht durch den Broker die Rolle desHeilberuflers. Das Element wird benötigt, da nach der Anonymisierungdas Zertifikat des Heilberuflers aus der Nachricht entferntwird und somit die Rolle nicht mehr verfügbar ist.Das Element GTEL:RoleDataProcessor ist eine OID, die die Rolledes Leistungserbringers eindeutig definiert.Die Aufnahme eines leeren Elementes ist nicht zulässig.Informative Beispiele 1.3.6.1.4.1.24796.1.1Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseGTEL:RoleDataProcessor wird durch den SecurityValidationServiceals Bestandteil des Brokers beim Durchführen der Anonymisierunggeschrieben.Der Empfänger kann dieses Element im Falle der Anonymisierungzur Autorisierung des Datenbearbeiters verwenden. Diesdarf nur geschehen, wenn der Empfänger die Anonymisierungvon Nachrichten erwartet und die Signatur des Datenbearbeitersdurch die des Intermediärs ersetzt wurde.Wenn dieses Element in der Request-Nachricht vorhanden ist,MUSS es in die Response-Nachricht übernommen werden.Offener Punkt R2 – Schlüsselwortliste der RollenkennzeichenEs ist derzeit in Klärung, in welchem Dokument die normative Bereitstellung der Schlüsselworte erfolgt.5.2.3 Elemente des wsse:Security HeaderDie Telematiknachricht MUSS einen wsse.Security Header besitzen, sofern in der Parameterlistedes Anwendungsfalls der Parameter SIG auf „Ja“ gesetzt war.Zur Erzeugung des Codes zur Erzeugung der Elemente des wsse:Security Header werdenüblicherweise Codegenerierungswerkzeuge verwendet. Es soll daher keine Beschreibungder einzelnen Elemente erfolgen, sondern eine Spezifizierung der für die automatisierteErstellung der Elemente relevanten Informationen.Der wsse:Security Header MUSS aus drei Elementen bestehen. Einem wsu:Timestamp,einem wsse:BinarySecurityToken und einer ds:Signature. Die Eigenschaften dieser Elementewerden nachfolgend beschrieben.Nachfolgend ist ein exemplarischer WSS-Header aufgeführt. Die verwendeten Zeilenumbrüchewurden aus Gründen der Lesbarkeit eingefügt, MÜSSEN aber in der Telematiknachrichtentfallen. Die verwendeten Prefixes entsprechen Tabelle 19. MIIEzjC…==gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 68 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsKhHwsguZal3E7tWd0…=TIsY3/zRaDi4J1…=z09tq40td5CnL4DT…=WkM9EJMiY…=2007-12-10T08:51:14.245Z5.2.3.1 wsse:SecurityTabelle 20: Anforderungen an wsse:SecurityAFO-ID Titel AFO-Typ BeschreibungA_01519 Anforderungen an Telematiknachrichten:wsse:Security: HeaderA_01520 Anforderungen anwsse:Security: HeaderIA_01521 Anforderungen anwsse:Security: HeaderIIMUSSMUSSSignierte TelematiknachrichtenMÜSSEN genau einen wsse:SecurityHeader enthalten.Sofern eine Telematiknachricht einenwsse:Security Header besitzt, MUSSdieser ein s11:mustUnderstand-Attributbesitzen, dessen Wert auf 1 gesetztist.DARF NICHT Der wsse:Security Header einer TelematiknachrichtDARF das Attributs11:Actor NICHT gesetzt haben.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 69 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ BeschreibungA_01522 Anforderungen anwsse:Security: HeaderIIIA_01523 Anforderungen anwsse:Security: HeaderIVMUSSMUSSDer wsse:Security Header einer TelematiknachrichtMUSS genau drei Subelementebesitzen: wsu:Timestamp,wsse:BinarySecurityToken,ds:Signature.Innerhalb einer TelematiknachrichtMUSS sich daswsse:BinarySecurityToken imwsse:Security Header vor dem Elementds:Signature befinden.5.2.3.2 wsu:TimestampTabelle 21: Anforderungen an wsu:TimestampAFO-ID Titel AFO-Typ BeschreibungA_01524 Anforderungen anwsu:Timestamp IA_01525 Anforderungen anwsu:Timestamp IIA_01526 Anforderungen anwsu:Timestamp IIIA_01527 Anforderungen anwsu:Timestamp IVA_01528 Anforderungen anwsu:Timestamp VMUSSMUSSKANNMUSSDARFNICHTDer wsu:Timestamp im wsse:SecurityHeader einer TelematiknachrichtMUSS ein wsu:Id-Attribut besitzen, dasals Referenz für die Signatur verwendetwird.Der wsu:Timestamp im wsse:SecurityHeader einer TelematiknachrichtMUSS ein wsu:Created Subelemententhalten, in dem die Zeit der Erzeugungder Nachricht angegeben ist.Wenn der wsu:Timestamp imwsse:Security Header einer Telematiknachrichtdas optionale wsu:ExpiresSubelement enthält, MUSS das Elementausgewertet werden und denGültigkeitszeitraum weiter einschränken.Der Empfänger einer TelematiknachrichtMUSS auch Nachrichtenohne wsu:Expires Subelement verarbeitenkönnen.Die Bewertung der Gültigkeit einer TelematiknachrichtMUSS aus der Differenzzwischen der Zeit deswsu:Created Elementes und der aktuellenSystemzeit des Empfängers abgeleitetwerden. Die Größe der zulässigenZeitspanne MUSS auf dem Empfängerkonfigurierbar sein.Der wsu:Timestamp im wsse:SecurityHeader einer Telematiknachricht DARFgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 70 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ BeschreibungA_01529 Anforderungen anwsu:Timestamp VIMUSSNICHT Elemente enthalten, die vonwsu:Created und wsu:Expires abweichen.Die Angabe des wsu:Timestamp imwsse:Security Header einer TelematiknachrichtMUSS konform zu [BasicSecurity Profile] Kapitel 6. Timestampserfolgen.5.2.3.3 wsse:BinarySecurityTokenTabelle 22: Anforderungen an wsse:BinarySecurityTokenAFO-ID Titel AFO-Typ BeschreibungA_01530 Anforderungen anwsse:BinarySecurityToken IA_01531 Anforderungen anwsse:BinarySecurityToken IIA_01532 Anforderungen anwsse:BinarySecurityToken IIIMUSSMUSSMUSSDas wsse:BinarySecurityToken imwsse:Security Header einer TelematiknachrichtMUSS ein wsu:Id-Attributbesitzen, das als Referenz für die Signaturverwendet werden kann.Das wsse:BinarySecurityToken imwsse:Security Header einer TelematiknachrichtMUSS ein ValueType-Attribut besitzen, das den Typ des enthaltenenTokens angibt.Das wsse:BinarySecurityToken imwsse:Security Header einer TelematiknachrichtMUSS ein EncodingType-Attribut besitzen, das den Typ des enthaltenenTokens angibt.5.2.3.4 ds:SignatureTabelle 23: Anforderungen an ds:Signature (WSS Header)AFO-ID Titel AFO-Typ BeschreibungA_01533Anforderungen ands:Signature (WSSHeader) IMUSSDie ds:Signature im wsse:Security Headereiner Telematiknachricht MUSS XMLDSIG und WSS 1.0-konform sein.A_01534Anforderungen ands:Signature (WSSHeader) IIMUSSDie ds:Signatur im wsse:Security Headereiner Telematiknachricht MUSS als Kanonisierungsalgorithmus[gemSpec_Krypt#6.1.4] verwenden.A_01535Anforderungen ands:Signature (WSSMUSSDie ds:Signatur im wsse:Security Headereiner Telematiknachricht MUSS als Signaturalgorithmus[gemSpec_Krypt#6.1.4]gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 71 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ BeschreibungA_01536A_01537A_01538A_01539A_01540Header) IIIAnforderungen ands:Signature (WSSHeader) IVAnforderungen ands:Signature (WSSHeader) VAnforderungen ands:Signature (WSSHeader) VIAnforderungen ands:Signature (WSSHeader) VIIAnforderungen ands:Signature (WSSHeader) VIIIMUSSMUSSMUSSMUSSMUSSverwenden.Die ds:Signatur im wsse:Security Headereiner Telematiknachricht MUSS alsTransformationsalgorithmus[gemSpec_Krypt#6.1.4] verwenden.Die ds:Signatur im wsse:Security Headereiner Telematiknachricht muss als Digestalgorithmus[gemSpec_Krypt#6.1.4]verwenden.Als kryptographisches Token für dieds:Signatur im wsse:Security Headereiner Telematiknachricht MUSS einX.509-Zertifikat verwendet werden, dasim wsse:BinarySecurityTokenElement des wsse:Security Headershinterlegt werden MUSS.Die Referenzierung des SecurityTokensMUSS über direkte Referenzierung gemäß[WSS1.0] Abschnitt 7.2 erfolgen.Durch die ds:Signature im wsse:SecurityHeader einer TelematiknachrichtMÜSSEN die folgenden Elemente signiertwerden:s11:Envelope/s11:Header/GTEL:TelematikHeaders11:Envelope/s11:Header/wsse:Security/wsu:Timestamps11:Envelope/s11:BodyA_01541Anforderungen ands:Signature (WSSHeader) VIIIIMUSSDas wsse:BinarySecurityToken imwsse:Security Header einer TelematiknachrichtMUSS für eGKs, HBAs undSMC-Bs den Anforderungen gemäß[gemSpec_Krypt#5.1.1.2] und für Signaturendurch Fachdienste den Anforderungengemäß [gemSpec_Krypt#5.1.1.6]entsprechen.5.2.4 Elemente des SOAP-BodyDer SOAP-Body enthält genau ein Child-Element und MUSS, sofern eine WSS Datenbearbeiter-Signaturvorhanden ist, eine wsu:Id zur Referenzierung besitzen. Das Child-Element ist entweder TelematikExecute oder TelematikExecuteUnsigned für die Requests.Für die Responses müssen die zugehörigen Elemente TelematikExecuteResponseoder TelematikExecuteUnsignedResponse verwendet werden. Alle Elemente sind vomgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 72 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsgleichen Typ GTEL:TelematikExecuteType und es wird durch sie lediglich unterschieden,ob eine Nachricht eine WSS-Signatur enthalten muss oder nicht. Abbildung 13 zeigt einegraphische Darstellung des GTEL:TelematikExecuteType in der Verwendung bei TelematikExecute.Die Subelemente des Typs GTEL:TelematikExecuteType sind nachfolgend beschrieben.Abbildung 13: Graphische Darstellung des Elementes TelematikExecute5.2.4.1 GTEL:PayloadXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payloadxs:complexTypeNeinDas Element GTEL:Payload beinhaltet die Daten der Nachricht.In dem Falle, dass eine signierte Payload zu übertragen ist, dientes zur Kapselung der Elemente, die zu signieren sind. Innerhalbdes Elementes GTEL:Payload befindet sich eine Enveloped-Signature, die das Element Payload referenziert.Sofern eine Signatur der Payload stattfindet, MUSS das Elementein xs:Id Attribut enthalten, das zur Referenzierung durch dieSignatur der Payload verwendet wird. Sofern keine Signatur dergematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 73 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsPayload gefordert wird, MUSS dieses Attribut entfallen. Es enthältChild-Elemente, aber keinen eigenen Inhalt.Informative Beispiele ………………………Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseJede Komponente, die eine Nachricht erstellt, befüllt das Element.Das Element wird durch den Empfänger verarbeitet.Die Verwendung des Elementes in der Response ist von derFacharchitektur abhängig.5.2.4.2 GTEL:EncryptedKeysXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:EncryptedKeysxs:complexTypeJaDas Element darf nur enthalten sein, wenn Unterelemente vorhandensind.Das Element GTEL:EncryptedKeys dient zur Kapselung mehrererxenc:EncryptedKey Elemente. Das Element wird nur für Response-Nachrichtenverwendet und darf für Requests nicht gefülltsein.Das Element enthält 1 bis 200 EncryptedKeys, aber keinen eigenenInhalt.Informative Beispiele ………Element Verwendung– SchreibendElement Verwendung– LesendDas Element wird durch den Empfänger beim Übermitteln einesverschlüsselten Objektes an den Absender verwendet.Das Element wird durch den Absender zur Entschlüsselung vonmedizinischen Objekten verwendet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 74 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseSofern ein verschlüsseltes Datenobjekt übertragen werden soll,dient dieses Element für den Transport des Hybridschlüssels.5.2.4.3 xenc:EncryptedKeyDas Element EncryptedKey enthält den für die Datenautorität individuellen Objektschlüssel.Nähere Beschreibungen und Beispiele sind in [gemSpec_Ticket] bzw. [gemGesArch#7.6.2]enthalten.Zur Korrelierung des EncryptedKey mit einem Objekt muss der EncryptedKey dieObjektID unter Berücksichtigung des Abschnitts 5.1.2 als das Attribut ID enthalten.Die normativen Anforderungen an den EncryptedKey werden nachfolgend in tabellarischerForm aufgeführt.Tabelle 24: Anforderungen an xenc:EncryptedKeyAFO-ID Titel AFO-Typ BeschreibungA_01542Anforderungen anxenc:EncryptedKeyIMUSSIn einer Telematiknachricht MUSS das Elementxenc:EncryptedKey zum Transport vonHybridschlüsseln [XMLEnc] konform sein.A_01543Anforderungen anxenc:EncryptedKeyIIMUSSDas xenc:EncryptedKey Element in TelematiknachrichtenMUSS als EncryptionMethodden Algorithmus gemäß[gemSpec_Krypt#6.1.6] verwendet werden.A_01544Anforderungen anxenc:EncryptedKeyIIIMUSSDas xenc:EncryptedKey Element in TelematiknachrichtenMUSS ein ds:KeyInfo Elementmit ds:X509Data undds:X509IssuerSerial Subelement enthalten,in dem das zu dem öffentlichen Schlüsselgehörige Zertifikat über den Herausgeber(Issuer) und die Seriennummer (SerialNumber) referenziert.Das Element IssuerName MUSS sich aufdas Issuer Attribut eines HBA, einer eGKoder einer SMC-B beziehen.Die String Darstellung im Element Issuer-Name MUSS gemäß [RFC2253] erfolgen.A_01850Anforderungen anxenc:EncryptedKeyIVMUSSDer Empfänger eines xenc:EncryptedKeyMUSS einen Fehler generieren sofern dieAngabe der IssuerDomain ein anderesTrennzeichen als ein Komma enthält oderwenn whitespaces vor bzw. hinter einemTrennzeichen auftreten.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 75 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.4.4 GTEL:ObjectTicketsXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ObjectTicketsxs:complexTypeJaDas Element darf nur verwendet werden, wenn Unterelementevorhanden sind.Das Element GTEL:ObjectTickets dient zur Kapselung mehrererGTEL:Ticket Elemente.Das Element enthält 1 bis 200 Ticket-Unterelemente, hat aberkeinen eigenen Inhalt.Informative Beispiele ………Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird durch den Absender bei dem Einstellen einesObjektes in den Empfänger verwendet und durch den Empfängerbei einer Anfrage zur Rechteverwaltung gefüllt.Das Element wird durch den Empfänger verarbeitet.Für R2 DARF dieses Element NICHT in einer Response enthaltensein, da diese Funktionalität nur für die Rechteverwaltungbenötigt wird, die in R2 nicht im Funktionsumfang enthalten ist.5.2.4.5 GTEL:Ticket (Subelement von ObjectTickets und ServiceTickets)XPATHDatentypOptionalInhaltliche Beschreibung/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ObjectTickets/GTEL:Ticket/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ServiceTickets/GTEL:Ticketxs:base64BinaryNeinDas Element GTEL:Ticket enthält base64-kodierte Objekt- oderServiceTickets. Die Kodierung als base64 wurde aufgenommen,um eine Entkopplung zwischen Transportschema und Ticketschemazu erreichen. Der Import des Ticketschemas direkt würdehier eine Abhängigkeit zwischen der Transport-WSDL und demTicketschema verursachen und eine Anpassung der WSDL aufgrundvon Änderungen am Ticketschema wäre die Folge. Umden Transport von Tickets von der Verarbeitung von Tickets zutrennen, wurde die Kodierung als base64 gewählt. Die verschiedenenVersionen der Tickets sind somit für den Transport trans-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 76 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsNormative Beschreibungdes Formatesparent.Das Element enthält ein Base64 codiertes ObjectTicket bzw. ServiceTicket.Informative Beispiele AwXjELMAkGA1UEBhMCREUxEDAOBgNVBAoTB2dlbWF0aWsxFTATBgNVBAsTDF…Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird durch den Absender bei dem Einstellen einesObjektes in den Empfänger verwendet und durch den Empfängerbei einer Anfrage zur Rechteverwaltung gefüllt.Das Element wird durch den Empfänger verarbeitet.Siehe Beschreibung des Elementes GTEL:ObjectTicket (5.2.4.4).5.2.4.6 GTEL:ServiceTicketsXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:ServiceTicketsxs:complexTypeJaDas Element darf nur vorhanden sein, wenn darin Unterelementeenthalten sindDas Element GTEL:ServiceTickets dient zur Kapselung mehrererGTEL:Ticket Elemente.Das Element enthält 1 bis 200 Ticket-Unterelemente, hat aberkeinen eigenen Inhalt.Informative Beispiele ………Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird durch Absender und Empfänger zum übermittelnvon ServiceTickets im Rahmen der Berechtigungsverwaltungverwendet.Das Element wird durch den Empfänger verarbeitet.Für R2 DARF dieses Element NICHT in einer Response enthaltensein, da diese Funktionalität nur für die Rechteverwaltungbenötigt wird, die in R2 nicht im Funktionsumfang enthalten ist.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 77 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.4.7 GTEL:CertificatesXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Certificatesxs:complexTypeJaDas Element darf nur in einer Nachricht enthalten sein, wenn Unterelementemit Zertifikaten enthalten sind.Das Element GTEL:Certificates dient zur Kapselung mehrererds:X509Data Elemente.Jedes Ticket enthält Signaturen sowie Referenzen auf Zertifikate.Damit diese Zertifikate nicht redundant in der Nachricht enthaltensind und somit unnötiger Ballast geschaffen wird, werden Zertifikatean einer zentralen Stelle mitgeführt. Die einzigen Ausnahmensind hier die WSS-Signatur sowie in verschlüsselten Elementenenthaltene Zertifikate.Das Element enthält 1 bis 200 ds:X509Data Elemente, in demdas base64-codierte X509Zertifikat enthalten ist, sowie zur einfacherenReferenzierung ein ds:X509IssureSerial Element, in demder Herausgeber sowie die Seriennummer des Zertifikates enthaltenist. Dieser Eintrag MUSS mit dem entsprechenden Eintragim Ticket übereinstimmen.Das Element IssuerName bezieht sich auf das Issuer Attribut desjeweiligen Zertifikats eines HBA, einer eGK oder einer SMC-B.Das Issuer Attribut ist z. B. in [gemX.509_eGK] definiert. DieString Darstellung im Element IssuerName MUSS gemäß[RFC2253] erfolgen.Die Verwendung von Trennzeichen und Leezeichen in der StringrepräsentationMUSS dabei den Vorgaben der IssuerDomain inAbschnitt 5.2.2.7 entsprechen.Informative Beispiele MIIDljCCAn6gAwIBAgICJyswDQYJKoZIhvcNAQEFB34Z2Q…==CN=gematik eGK TestreferenzCA01,OU=Testreferenz,O=gematik,C=DE10212Element Verwendung– SchreibendElement Verwendung– LesendDas Element wird durch den Absender und Empfänger beimÜbermitteln von Tickets sowie einer signierten Payload verwendet.Das Element wird durch den Absender und Empfänger verarbeitet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 78 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseDas Element wird nur verwendet, wenn entweder eine Datenautoritätssignaturinnerhalb der Payload enthalten ist, oder Ticketstransportiert werden. Dies ist für R2 bei einer Response nie derFall. Somit darf dieses Element für R2 in einer Response nichtverwendet werden.5.2.4.8 GTEL:ParameterXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameterxs:complexTypeJaDas Element darf nur in einer Nachricht enthalten sein, wenn Unterelementevorhanden sind.Das Element GTEL:Parameter dient zur Kapselung von Name/Value/Encoding-Paaren,die als Parameter an den Fachdienstoder als Antwort des Fachdienstes übergeben werden sollen.Das Element enthält ausschließlich Child-Elemente, aber keineneigenen Inhalt.Informative Beispiele ……Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird beim Erstellen einer Anfrage durch den Absenderund beim Beantworten einer Anfrage durch den Empfängergefüllt.Die Verarbeitung des Elementes erfolgt durch den Empfängeroder den die Antwort empfangenden Absender.Die Verwendung in der Response ergibt sich aus der Schnittstellenbeschreibungder jeweiligen FA.5.2.4.9 GTEL:Parameter[Encoding]XPATHDatentypOptionalInhaltliche Beschreibung/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter[@Encoding]xs:stringJaDas Attribut muss vorhanden sein, wenn sich die Codierung von„plain“ unterscheidet.Das Attribut Encoding beschreibt die Kodierung der Values einesName/Value-Paares. Mögliche Kodierungen sind „plain“, für dieÜbertragung von einfachen Datentypen oder „base64“ für diegematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 79 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsNormative Beschreibungdes FormatesÜbertragung von Binärobjekten oder XML-Strukturen.Es handelt sich um ein optionales Attribut, das entfallen kann,wenn als Kodierung „plain“, das bedeutet keine Kodierung undsomit die Übertragung eines simplen Datatypes erfolgt. Das Attributkann ebenfalls den Wert „base64“ annehmen, der für dieÜbertragung von Binärdaten oder XML-Strukturen verwendetwird. Perspektivische Erweiterungen sind möglich.Informative Beispiele …Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Attribut wird beim Erstellen einer Anfrage durch den Konnektormit der Art der Kodierung des Values und beim Beantworteneiner Anfrage durch den Fachdienst gefüllt.Die Verarbeitung des Attributes erfolgt durch den Empfänger oderden die Antwort empfangenden Absender.Die Verwendung in der Response ergibt sich aus der Schnittstellenbeschreibungder jeweiligen FA.5.2.4.10 GTEL:NameXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter/GTEL:Namexs:stringNeinDie Verwendung der Name/Value-Paare der Payload wird durchdie Facharchitektur gemäß der Vorgabe aus Abschnitt 4.1 definiert.Bei dem Element Name handelt es sich um eine ASCII-Zeichenkette von 1 bis 50 Zeichen.Die zulässigen Werte sind von der Facharchitektur abhängig undwerden in diesen gemäß Abschnitt 4.1 definiert. Bei der Spezifikationdes Inhalts durch die Facharchitektur SOLLEN ausschließlichdie Zeichen [A-Za-z0-9] sowie „.“ und „-“ verwendet werden.Informative Beispiele eVerordnungElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird beim Erstellen einer Anfrage durch den Absenderund beim Beantworten einer Anfrage durch den Empfängergefüllt.Die Verarbeitung des Elementes erfolgt durch den die Empfängeroder den die Antwort empfangenden Absender.Die Verwendung in der Response ergibt sich aus der Schnittstellenbeschreibungder jeweiligen FA.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 80 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details5.2.4.11 GTEL:ValueXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:Parameter/GTEL:Valuexs:stringNeinDie Verwendung der Name/Value-Paare der Payload wird durchdie Facharchitektur gemäß der Vorgabe aus Abschnitt 4.1 definiert.Bei dem Element Value handelt es sich um eine ASCII-Zeichenkette beliebiger Länge. Der Inhalt der Zeichenkette wirddurch die Facharchitekturen gemäß Abschnitt 4.1 definiert.Es enthält entweder einfache Datentypen direkt in ihrer Stringrepräsentationoder als base64-kodierte binäre bzw. XML-Daten.Informative Beispiele 17Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDas Element wird beim Erstellen einer Anfrage durch den Absenderund beim Beantworten einer Anfrage durch den Empfängergefüllt.Die Verarbeitung des Elementes erfolgt durch den Empfängeroder den die Antwort empfangenden Absender.Die Verwendung in der Response ergibt sich aus der Schnittstellenbeschreibungder jeweiligen FA5.2.4.12 GTEL:MessageID (Payload)XPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/GTEL:MessageIDxs:stringJaDie MessageID MUSS vorhanden sein, wenn eine Signatur derPayload vorhanden ist und DARF NICHT verwendet werden,wenn keine Signatur der Payload verwendet wird.Die MessageID dient zur Korrelation zwischen Body und Headersignierter Nachrichten, falls die Identitäten von Datenbearbeiterund Datenautorität nicht identisch sind. Die Signatur der Payloadeiner Nachricht durch die Datenautorität muss in diesem Fall mitdem Header korrelierbar sein, um Replay-Attacken zu verhindern.Aus diesem Grund ist diese UUID identisch zur UUID des Headers.Sofern eine Nachricht keine Signatur der Payload enthält,weil es sich entweder um eine komplett unsignierte Nachrichthandelt oder Datenbearbeiter und Datenautorität übereinstimmenentfällt dieses Element.Eine MessageID ist eine Objekt-ID gemäß der Spezifikation in[gemGesArch], String Repräsentation gemäß RFC 4122.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 81 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsInformative Beispiele 6f638460-b2d6-11db-abbd-0800200c9a66Element Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– ResponseDie MessageID wird durch den Absender vergeben.Die MessageID wird durch den Empfänger zur Verhinderung vonReplay-Attacken bezüglich der Signatur der Datenautorität verwendet.Siehe auch Abschnitt 4.9.2Bei der Response durch einen Empfänger sind Datenbearbeiterund Datenautorität immer identisch, so dass keine separate Signaturder Payload durch eine Datenautorität erfolgt. Aus diesemGrund wird dieses Element in einer Response nicht verwendet.5.2.4.13 wsu:TimestampXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes Formates/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/wsu:Timestampwsu:TimestampTypeJaDer Timestamp MUSS vorhanden sein, wenn eine Signatur derPayload vorhanden ist und DARF NICHT verwendet werden,wenn keine Signatur der Payload verwendet wird.Das Element wsu:Timestamp dient dazu, Replay-Attacken aufden Body signierter Nachrichten abzuwehren und die Vorhaltezeitfür MessageIDs zu verkürzen. Dies ist nur notwendig, falls dieIdentitäten von Datenbearbeiter und Datenautorität nicht identischsind. Sofern eine Nachricht keine Signatur der Payload enthält,weil es sich entweder um eine komplett unsignierte Nachrichthandelt oder Datenbearbeiter und Datenautorität übereinstimmenentfällt dieses Element.Das Format entspricht wsu:Timestamp mit verpflichtender Angabeder Zeitzone. Der Timestamp MUSS ein wsu:Created Subelemententhalten, in dem die Zeit der Erzeugung der Nachrichtangegeben ist. Das Element darf kein wsu:Expires Subelemententhalten. Die Angabe des Timestamp muss konform zu [BasicSecurity Profile] Kapitel 6. Timestamps erfolgen.Informative Beispiele 2001-12-17T09:30:47.0ZElement Verwendung– SchreibendElement Verwendung– LesendDer Absender der Nachricht bzw. der Empfänger der Nachrichtbeim Erstellen der Response tragen die aktuelle Zeit vor Erstellender Signatur ein.Das Element wird durch die die Nachricht empfangende Komponenteausgewertet, um zu prüfen, ob die Gültigkeit des Elementesabgelaufen ist.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 82 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsElement Verwendung– ResponseBei der Response durch einen Empfänger sind Datenbearbeiterund Datenautorität immer identisch, so dass keine separate Signaturder Payload durch eine Datenautorität erfolgt. Aus diesemGrund wird dieses Element in einer Response nicht verwendet.5.2.4.14 ds:SignatureXPATHDatentypOptionalInhaltliche BeschreibungNormative Beschreibungdes FormatesInformative BeispieleElement Verwendung– SchreibendElement Verwendung– LesendElement Verwendung– Response/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:Payload/ds:Signatureds:SignatureTypeJaDie Signatur MUSS vorhanden sein, wenn sich Datenautoritätund Datenbearbeiter unterscheiden und DARF NICHT vorhandensein wenn Datenautorität und Datenbearbeiter identisch sind.Das ds:Signature Element enthält die Signatur der Datenautorität,sofern Datenautorität und Datenbearbeiter nicht übereinstimmen.Falls Datenbearbeiter und Datenautorität übereinstimmen, entfälltdieses Element.Die normative Beschreibung der Signatur erfolgt im Anschluss andiese Tabelle in Form von Anforderungen.Die Signatur wird durch den Absender erstellt.Die Signatur wird durch den Empfänger validiertBei der Response durch einen Empfänger sind Datenbearbeiterund Datenautorität immer identisch, so dass keine separate Signaturder Payload durch eine Datenautorität erfolgt. Aus diesemGrund wird dieses Element in einer Response nicht verwendet.Tabelle 25: Anforderungen an ds:Signature (Payload)AFO-ID Titel AFO-Typ BeschreibungA_01545Anforderungen ands:Signature (Body) IMUSSDie ds:Signature in der Payload einerTelematiknachricht MUSS XML DSIGkonformsein.A_01546Anforderungen ands:Signature (Body) IIMUSSDie ds:Signature in der Payload einerTelematiknachricht MUSS als Kanonisierungsalgorithmus[gemSpec_Krypt#6.1.2] verwenden.A_01547Anforderungen ands:Signature (Body) IIIMUSSDie ds:Signature in der Payload einerTelematiknachricht MUSS als Signaturalgorithmus[gemSpec_Krypt#6.1.2]verwenden.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 83 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ BeschreibungA_01548Anforderungen ands:Signature (Body) IVMUSSDie ds:Signature in der Payload einerTelematiknachricht MUSS als Transformationsalgorithmus[gemSpec_Krypt#6.1.2] verwenden.A_01549Anforderungen ands:Signature (Body) VMUSSDie ds:Signature in der Payload einerTelematiknachricht MUSS als Digestalgorithmus[gemSpec_Krypt#6.1.2] verwenden.A_01550Anforderungen ands:Signature (Body) VIMUSSAls kryptographisches Token für dieds:Signature in der Payload einer TelematiknachrichtMUSS ein X.509-Zertifikat verwendet werden. Das ZertifikatMUSS innerhalb des inGTEL:Certificates Element gespeichertund aus der Signatur über ein ds:X509IssuerSerial Element referenziert werden.A_01551Anforderungen ands:Signature (Body)VIIMUSSDurch die ds:Signature in der Payloadeiner Telematiknachricht MÜSSEN diefolgenden Elemente signiert werden:/s11:Envelope/s11:Body/GTEL:TelematikExecute/GTEL:PayloadA_01552Anforderungen ands:Signature (Body)VIIIMUSSDas für die Erstellung der ds:Signaturein der Payload einer Telematiknachrichtverwendete X.509-Zertifikat MUSS füreGKs, HBAs und SMC-Bs den Anforderungengemäß [gemSpec_Krypt#5.1.1.2]und für Signaturen durch Fachdiensteden Anforderungen gemäß[gemSpec_Krypt#5.1.1.6] entsprechen.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 84 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details6 TelematikTransport WSDLEs besteht die Anforderung, den Dienst für den Transport einer SOAP-Nachricht plattformunabhängigzu spezifizieren. Im Falle des Einsatzes von Webservices für den Nachrichtentransportist eine WSDL (Web Services Description Language) die standardisierteBeschreibungsform.Eine solche maschinenlesbare Beschreibung eines Webservices ermöglicht es, automatischeCodeerzeugungs-Werkzeuge zu benutzen, die von der SOAP-Kommunikation abstrahierenund dem Programmierer den Webservice als lokale Methode anbieten, welchediesen transparent aufruft. Damit wird gewährleistet, dass die entstandenen Serviceklassender jeweiligen Plattform, auf dem der Transportdienst implementiert werden soll, zweifelsfreider vorliegenden Spezifikation folgen und diese technisch korrekt abbilden.Für die Schnittstellenbeschreibung wird in dieser Spezifikation WSDL1.1 [WSDL1.1] eingesetzt.Die Interoperabilität zwischen verschiedenen SOAP-Implementierungen wirddurch die Vorgaben des WS-I Basic Profile V1.1 [WS-I1.1] erreicht.6.1 Generelle Festlegungen und BegriffsdefinitionenDie Schnittstellenspezifikation für den SOAP-Nachrichtentransport nutzt die folgendenBegriffe und Festlegungen:6.1.1 OperationenDie Schnittstelle des Transport-Dienstes KANN mehrere Operationen beinhalten. Innerhalbder TI werden die Operation TelematikExecute und TelematikExecuteUnsignedverwendet. Sollten perspektivisch weitere Operationsnamen verwendet werden, so müssendiese aus einem Verb und aus einem Substantiv gebildet werden. Die Namensbestandteilewerden zusammengeschrieben und beginnen jeweils mit einem Großbuchstaben.6.1.2 ParameterEine Operation hat mehrere Aufrufparameter und mehrere Rückgabeparameter. Diesewerden als XML-Elemente in den SOAP-Body eingepackt. Für eine Schnittstelle wird dieNachrichtenstruktur aller Operationen in einer XSD-Schemadatei beschrieben.Innerhalb der TI gilt für Transportnachrichten, dass der Name der Schemadatei mit demNamen der Schnittstelle identisch ist und die Dateiendung „.xsd“ angehangen wird.6.1.3 WSDL-DateiDer Nachrichtenaufbau sowie die Operationen und die Bindung an das Transportprotokollerfolgen in einer WSDL-Definitionsdatei. Die WSDL-Datei importiert die entsprechendeXSD-Schemadatei, um die Parameterdefinition der Operationen zu nutzen. Der Name derWSDL-Datei ist identisch mit dem Namen der Schnittstelle mit der Dateiendung .wsdl.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 85 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details6.1.4 SchnittstelleJede Schnittstelle hat einen Namen. Der Schnittstellenname (oder Dienstname) kannaus mehreren Wortteilen bestehen, konkateniert mit dem Suffix Service. Jeder Wortteilbeginnt mit einem Großbuchstaben. Der Schnittstellenname für die Telematikinfrastrukturist TelematikTransportService.6.1.5 Versionsnummer und NamensraumFestlegungen für Versionsnummer und Namensraum erfolgen außerhalb dieser Spezifikationund werden in [gemSpec_VersNr] beschrieben.Gemäß den Vorgaben in [gemSpec_VersNr] muss der Namensraum einer WSDL odereines Schemas bei einer nicht abwärtskompatiblen Änderung angepasst werden. Damitsich eine Änderung an der WSDL nicht auch auf die TelematikTransport.xsd auswirkt,wurden unterschiedlich Namespaces gewählt, um so eine Entkopplung der Schemadateienzu gewährleisten.6.1.6 SOAP-ActionDie für eine Operation im WSDL festgelegte SOAP-Action ist die Konkatenation des Namensraumesder Schnittstelle und dem Schnittstellennamen und dem Namen der Operation.6.1.7 FehlerbehandlungDie Fehlerbehandlung wird ausführlich in [gemSpec_FM] erläutert.6.1.8 Allgemeine Anforderungen an die SOAP-NachrichtTabelle 26: Anforderungen an die Erstellung und Verarbeitung von SOAP-NachrichtenAFO-ID Titel AFO-Typ BeschreibungA_01553A_01554A_01555Anforderungenan die Erstellungder SOAP-Nachricht IAnforderungenan die Erstellungder SOAP-Nachricht IIAnforderungenan die Erstellungder SOAP-Nachricht IIIDARF NICHTDARF NICHTMUSSDie Telematiknachricht DARF außer denexplizit spezifizierten SOAP-Headern, TelematikHeader,TransportHeader undwsse:Security Header KEINE weiterenHeader besitzen. Das Hinzufügen vonzusätzlichen Headern MUSS auf Seitendes Empfängers zu einem Fehler führen.Eine Telematiknachricht DARF KEINEWhitespaces zwischen einzelnen Elementender Nachricht enthalten.Alle Telematiknachrichten MÜSSEN konformzu WS-I Basic Profile V1.1 [WS-I1.1]sein.A_01556 Anforderungen MUSS Alle signierten Telematiknachrichten müs-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 86 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAFO-ID Titel AFO-Typ BeschreibungA_01588A_01589A_01590an die Erstellungder SOAP-Nachricht IVBegriffsdefinition:Größe einerTelematiknachrichtGröße gültigerTelematiknachrichtenEinschränkungder Größe erzeugterTelematiknachrichtenMUSSMUSSDARF NICHTsen konform zu [WS-I-BSP 1.0] sein.Die Größe einer Telematiknachricht bezeichnetdie Bruttogröße inklusive SOAPEnvelope, verwendeter Signaturen undZertifkate.Alle Komponenten die Telematiknachrichtenverarbeiten (erzeugen, weiterleitenoder als finaler Empfänger abarbeiten)MÜSSEN in der Lage sein, Telematiknachrichtenmit einer Größe von bis zu1 MB zu verarbeiten.Der Erzeuger einer TelematiknachrichtDARF KEINE Nachricht, die Größer als 1MB ist, erzeugen und in die Telematikinfrastrukturversenden.6.2 Spezifikation der TelematikTransport WSDLDie Definition der Schnittstelle ist ein Anhang zu dieser Spezifikation. Sie besteht aus dennachfolgend aufgeführten Dokumenten. Diese Dokumente werden zusammen mit denweiteren Schemen der gematik zur Verfügung gestellt.TelematikTransport.wsdl – Beschreibt das Binding, die Operations sowie die verwendetenElemente der SOAP-Nachrichtenstruktur für jede Operation. Der sich hieraus ergebendeAufbau der SOAP-Nachricht ist für Request und Response identisch und ist in Abschnitt4.2 aus einer logischen Sicht sowie in Kapitel 5 aus einer detaillierten Sicht spezifiziert.TelematikTransport.xsd – Die einzelnen Elemente, die zum Aufbau der SOAP-Nachrichtbenötigt werden, sind in diesem Dokument als XML-Schema definiert.TelematikPolicy.xml – Die für die Signatur einer Nachricht notwendigen Policies sind indiesem Dokument als WS-Policy spezifiziert.TelematikError.xsd – Für den Fall, dass Fehler bei der Verarbeitung vorkommen, erfolgtdie Fehlerbehandlung gemäß [gemSpec_FM]. Bei der Verwendung von SOAP Faults sinddie in TelematikError.xsd spezifizierten und in [gemSpec_FM] beschriebenen Datenstrukturenzu verwenden.Nachfolgend erfolgt eine zusammenfassende Beschreibung der sich aus diesen Dokumentenergebenden Elemente sowie ihre Verschachtelung.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 87 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details6.2.1 MessagesTabelle 27: Messages WSDL SOAP-TransportSpezifizierteMessageMessage01Request_SignedMessage02Request_HeaderMessage03Response_SignedMessage04FaultMessageMessage05Request_UnsignedMessage03Response_UnsignedVerwendete Elemente (Parts)6.2.2 PortTypeTabelle 28: PortType WSDL SOAP-TransportOperationTelematikExecuteTelematikExecuteUnsignedVerwendungRequestNameMessage(Input, Output,Fault)Input TelematikExecuteRequest GTEL:Request_SignedOutput TelematikExecuteResponse GTEL:Response_SignedFault TelematikExecuteFault GTEL:FaultMessageInput TelematikExecuteUnsignedRequest GTEL:Request_UnsignedOutput TelematikExecuteUnsignedResponse GTEL:Response_UnsignedFault TelematikExecuteFault GTEL:FaultMessage6.2.3 BindingMit einem WSDL Binding werden konkrete Vorgaben für die Implementierung gemacht.Die Bindung an das SOAP-Protokoll spezifiziert zusätzlich, dass die in der SOAP-Nachrichtenstruktur festgelegten Elemente „TelematikHeader“ und „TransportHeader“ alsHeader der SOAP-Nachricht zu verwenden sind.Die Kodierungsmethode der SOAP-Nachrichten ist „wrapped document/literal“[WSDL1.1]. Diese Methode hat die folgenden Eigenschaften:Das style-Attribut des soap:binding-Elements hat den Wert “document“.Das use-Attribut der input- bzw. output-Nachrichtenbindung hat den Wert “literal“.Die input-Nachricht enthält mehrere Parts. Es werden Header-Elemente beschrieben undauf zwei komplexe Elemente für den Header verwiesen. Die output-Nachricht enthält genauein Part, der auf ein komplexes Element ohne Attribute verweist.Der lokale Name des Elements im Body-Element der SOAP-Aufrufnachricht stimmt mitdem Namen der Operation überein.Der lokale Name des Elementes im Body-Element der SOAP-Antwort besteht aus demNamen der Operation konkateniert mit der Zeichenkette Response.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 88 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsIn der Telematik werden die zwei Operationen TelematikExecute und TelematikExecuteUnsignedspezifiziert. Die SOAP Actions für beide Operations sind wie folgt:OperationTelematikExecuteTelematikExecuteUnsignedSOAP Action#telematikexecute#telematikexecuteunsignedDie Operationen sind unter einer einzigen Endpoint-URL zu erreichen.Die Angabe zur WSDL-Namespace und der Version kann aus der Versionsübersicht inAnhang A1 entnommen werden.6.3 WS-PolicyZusätzlich zu der Beschreibung der inhaltlichen Elemente durch die WSDL muss auchnoch eine formale Beschreibung der notwendigen Sicherheitsmechanismen und Algorithmenerfolgen. Zu diesem Zweck wird zusätzlich zur WSDL eine WS-Policy zur Verfügunggestellt.Allgemein steht mit WS-Policy ein Framework zur Verfügung, um für bereitgestellte Web-Services konkrete Nutzungsanforderungen, Zusicherungen, nicht-funktionale Eigenschaften,wie auch Angaben über die Qualität of Service in einer standardisierten Form festzulegen.Während eine WSDL sich klar auf die Beschreibung funktionaler Anforderungen orientiert,konzentriert sich WS-Policy auf die Beschreibung nichtfunktionaler Anforderungen wiez. B. Sicherheitsanforderungen für Messages (Verschlüsselung, Signatur) oder in derFestschreibung traditioneller Anforderungen an den Transport (Transport-Protokoll-Auswahl, Authentifizierungsschema etc.).Mit WS-Policy steht ein Instrument zur Verfügung, um flexible Policy-Erweiterungen zuden funktionalen Vorgaben einer WSDL vorzunehmen. Es sichert eine hohe Interoperabilitätder beteiligten Komponenten und Prozesse. WS-Policy manifestiert in einer standardisiertenForm die Nutzungsbedingungen der gematik-Transportarchitektur.Das WS-Policy-Framework besteht aus einer Reihe weiterer Spezifikationen, die unter[WSPL1.1] und [WSP1.1] spezifiziert und erläutert sind. Eine nähere Beschreibung derPolicies soll an dieser Stelle nicht erfolgen, da es sich nur um eine formale, maschinenlesbareErweiterung der sicherheitsrelevanten in Kapitel 5 spezifizierten Nachrichtenstrukturhandelt.Die Erfahrung bei der Entwicklung von Prototypen hat gezeigt, dass in vielen Umgebungendie Verwendung von WS-Policy und vor alle WS-Security-Policy erst rudimentär vorhandenist. Aus diesem Grund wurde die Entscheidung getroffen, die WS-Policy und WS-Security-Policy als separates XML-Dokument zur Verfügung zu stellen. Hierdurch kannder Hersteller einer Komponente eine der folgenden Methoden für die Implementierungwählen.Manuelle Implementierung der Sicherheitsmerkmale – Sofern die verwendete Entwicklungsumgebungkeine Unterstützung von WS-Policy oder WS-Security-Policy liefert,kann die bestehende WSDL verwendet werden, um Client oder Server Stubs zu generieren.Sicherheitsmerkmale müssen dann in der Entwicklungsumgebung manuell konfigu-gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 89 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsriert werden. In diesem Fall dient die formale Beschreibung mittels WSDL als eine präziseBeschreibung der zu konfigurierenden Merkmale.Import der Sicherheitsmerkmale – In manchen Entwicklungsumgebungen wird die Generierungvon Client oder Server Stubs inklusive Umsetzung der durch WS-Security-Policy geforderten Merkmale nicht unterstützt. Es können jedoch WS-Security-Policiesüber zusätzliche Tools oder als Grundlage für die Konfiguration implementiert werden. Indiesem Fall wird die WSDL zur Generierung der Stubs verwendet und das zusätzlichepolicy Dokument dient als Grundlage für den Import der Sicherheitskonfiguration.Generierung von Client oder Server Stubs inklusive Sicherheitsmerkmalen – Soferneine Umgebung eingesetzt wird, in der die Verwendung von WS-Policy und WS-Security-Policy bei der Generierung von Stubs unterstützt wird, so wird empfohlen, die WSDL anzupassen,um die relevanten Policies zu referenzieren. Die Zusammengehörigkeit dereinzelnen Policies und der WSDL wird nachfolgend erläutert.6.3.1 Anwendung von Policies auf WSDL-BestandteileDie Sicherheitsmerkmale von Nachrichten werden über die nachfolgend erläuterten Policiesauf verschiedenen Ebenen der WSDL spezifiziert.6.3.1.1 Binding Level Security PolicyAuf Binding Ebene wird die Security Policy Telematik_Binding_Security_Policy verwendet.Die Telematik_Binding_Security_Policy spezifiziert Anforderungen, die für das gesamteBinding gelten, wie beispielsweise die Verwendung von WSS Security mittels X.509-Zertifikaten sowie die erlaubten Algorithmen.6.3.1.2 Eingabe, Ausgabe und Fehler PoliciesDie Policies Telematik_Operation_Input_ Security_Policy, Telematik_Operation_Output_Security_Policy und Telematik_Operation_Fault_ Security_Policy spezifizieren für Input-,Output- und Fault-Ebene die relevanten Sicherheitsmerkmale. Derzeit sind die Inhaltealler Policies identisch, es wurden jedoch aus Gründen der Erweiterbarkeit separate Policiesverwendet.Auf dieser Ebene werden z. B. die zu signierenden Bestandteile einer Nachricht spezifiziert.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 90 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details7 AusgangsanforderungenAusgangsanforderungen wurden an den jeweils relevanten Stellen des Dokumentes aufgenommen.Als Übersicht sind nachfolgend alle Tabellen, die Anforderungen definieren,zusammengefasst in einer Liste dargestellt.Tabelle 16: Ausgangsanforderungen an die Validierung der TelematiknachrichtenTabelle 17:Ausgangsanforderungen an die Validierung der Telematiknachrichten (FachdiensteTabelle 20: Anforderungen an wsse:SecurityTabelle 21: Anforderungen an wsu:TimestampTabelle 22: Anforderungen an wsse:BinarySecurityTokenTabelle 23: Anforderungen an ds:Signature (WSS Header)Tabelle 24: Anforderungen an xenc:EncryptedKeyTabelle 25: Anforderungen an ds:Signature (Payload)Tabelle 26: Anforderungen an die Erstellung und Verarbeitung von SOAP-Nachrichtgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 91 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAnhang AA1 - VersionsübersichtANGABEN ZUR KOMPONENTE/ SERVICEBezeichnungTelematik Transport DetailsKomponentenversion2.0.0(Interface Version)Versionsangaben zu in der Spezifikation definierten Artefakten1 WSDL Name TelematikTransport.wsdl1 WSDL-Version 2.0.01 TargetNamespace http://ws.gematik.de/tel/transportWSDL/v2.02 XSD Name TelematikTransport.xsd2 XSD Schemaversion 2.0.02 TargetNamespace http://ws.gematik.de/tel/transport/v2.03 Policy Name TelematikPolicy.xml3 XSD Schemaversion 2.0.0gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 92 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsA2 – Authentifizierung in TelematiknachrichtenAuthentifizierung und Autorisierung auf Nachrichtenebene stellt für Fachanwendungeneinen Mechanismus zur Verfügung, mit dem übergreifende Sicherheitsanforderungeneinheitlich umgesetzt werden können. Der Einsatz von Authentifizierung und Autorisierungauf Transportebene ist nicht für alle Anwendungsfälle sinnvoll. Insbesondere für kartennaheFachanwendungen wie VSDM und CAMS sind Mechanismen auf Anwendungsebeneeffizienter und sicherer umzusetzen. Die Unterscheidung, welche Sicherheitsmechanismenauf welcher Ebene eingesetzt werden, erfolgt durch die Gesamtarchitektur. Ausdiesem Grund wird die Verwendung von Authentifizierung und Autorisierung auf Transportebenenicht normativ vorgegeben.Um den Sprachgebrauch zu vereinfachen, wird in den Kapiteln zu Authentifizierung undAutorisierung davon ausgegangen dass die Sicherheitsmechanismen auf Transportebeneverwendet werden. Normative Aussagen gelten immer unter der Einschränkung, dass dieSicherheitsmechanismen der Transportebene verwendet werden.Authentifizierung bezeichnet den Vorgang, die Identität einer Person oder eines Rechnersystemsan Hand eines bestimmten Merkmals zu überprüfen. Im Kontext der Telematiknachrichtbedeutet dies konkret, dass überprüft wird, ob eine Nachricht tatsächlichdurch die vorgegebene Datenautorität und den vorgegebenen Datenbearbeiter signiertwurde. Hierdurch ist gleichzeitig die Authentizität der Nachricht geprüft und es ist sichergestellt, dass die Nachricht auf dem Transportweg nicht verändert wurde. Der hier beschriebeneProzess der Authentifizierung ist die Grundlage für die Autorisierungsentscheidungenbei der weiteren Verarbeitung beim Nachrichtenempfänger.Die Authentifizierung unterteilt sich in zwei Teilbereiche, die Authentifizierung des Datenbearbeitersund die Authentifizierung der Datenautorität. Sie ist nur erfolgreich, wenn jedeeinzelne Validierung erfolgreich durchgeführt wurde und die gesamte Nachricht somit authentischist.Nach erfolgreicher Authentifizierung sind die folgenden Sachverhalte sichergestellt:• Enthaltene Signaturen von Datenbearbeiter und Datenautorität sind integer(das bedeutet mathematisch korrekt).• Die verwendeten Zertifikate sind gültig.• Es wurden die korrekten Algorithmen verwendet.• Es wurden die korrekten Bereiche der Nachricht signiert.Insgesamt kann also die gesamte Nachricht als authentisch eingestuft werden.Es stehen folgende Informationen für die weitere Verwendung in der Autorisierungsfunktionoder in Fachmodulen zur Verfügung:• Zertifikat des Datenbearbeiters bzw. eindeutiges Identifikationsmerkmal desDatenbearbeiters• OID der Rolle des Datenbearbeiters• Zertifikat der Datenautorität bzw. eindeutiges Identifikationsmerkmal der Datenautoritätgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 93 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Details• Eindeutiges Authentifizierungsmerkmal der Datenautorität• Information darüber, ob die Identität für Datenbearbeiter und Datenautoritätidentisch sind.Es ist sichergestellt, dass bei der Signatur der Nachricht tatsächlich der zu einem Zertifikatgehörige Schlüssel anwesend war.Sofern eine Nachricht keine Signaturen enthält, sind die Eingangsinformationen für dieweitere Verarbeitung leer. In diesem Fall kann die Authentizität und die Authentifizierungnicht geprüft und garantiert werden. Dennoch sind für gewisse Anwendungsfälle unsignierteNachrichten unter Berücksichtigung der Performance-Anforderungen sinnvoll.A2.1 – Authentifizierung des DatenbearbeitersIn Telematiknachrichten wird die Identität des Datenbearbeiters immer durch die Signaturin einem WSS-Header übermittelt. Durch die Prüfung dieser Signatur kann validiert werden,dass bei der Erstellung der Nachricht die im Zertifikat angegebene Identität, also derprivate Schlüssel und somit die Karte, anwesend war. Nachdem überprüft wurde, dass dieNachricht authentisch signiert wurde, können alle in dem übermittelten Zertifikat enthaltenenInformationen als Basis für die Autorisierung herangezogen werden. Zu den für dieAutorisierung des Datenbearbeiters benötigten Informationen gehört insbesondere dieOID der Rolle des Datenbearbeiters.Abbildung 14 stellt den für die Authentifizierung des Datenbearbeiters notwendigen Ablaufin einer Übersicht dar. Die Beschreibung der einzelnen Verarbeitungsschritte erfolgt imAnschluss.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 94 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsact Authentifizierung DatenbearbeiterStart der AuthentifizierungNeinEnthält dieNachricht eineWSS SignaturJaRückgabe einer leerenRolle und eines leerenZertifikatsPrüfung der SignaturokRollenermittlungFehlerokNeinWird eineanonymisierteNachrichterwartetJaPrüfung auf Rolle BrokerFehlerokokAuslesen der Rolle aus derNachrichtFehlerGenerierung eines FehlersErfolgreicher Abschluss derAuthentifizierung (BereitstellungZertifikat und Rolle)Abbruch der Authentifizierung(Erstellung einer Fehlernachricht)Abbildung 14: Authentifizierung DatenbearbeiterAktivitätEnthält die Nachricht eine WSSSignatur?Rückgabe einer leeren Rolleund eines leeren ZertifikatsMathematische Prüfung derSignaturPrüfung der signierten ElementePrüfung der verwendeten AlgorithmenZertifikatsprüfungPrüfung des SignaturformatsBeschreibungInnerhalb der TI sind sowohl signierte als auch unsignierte Nachrichten zulässig. Ausdiesem Grund darf eine unsignierte Nachricht nicht direkt zu einer fehlgeschlagenenAuthentifizierung führen und es müssen getrennte Verarbeitungsabläufe durchlaufenwerden.Als Input für die Autorisierung muss eine leere Rolle und ein leeres Zertifikat übergebenwerden. Dieser Fall wird ausschließlich für unsignierte Nachrichten auftreten.Die Signatur ist gemäß Abschnitt 4.10 unter der Berücksichtung der Anforderung inAbschnitt 5.2.3 bzgl. Menge der zu signierenden Elmente, Signaturalgorithmen undSignaturformat zu prüfen.Insbesondere zählt hierzu die Einhaltung der nachfolgenden, in Abschnitt 5.2.3 gestelltenAnforderungen:A_01519, A_01521, A_01522, A_01525, A_01528, A_01529, A_01531, A_01532,A_01538, A_01539, A_01541 Die mathematische Überprüfung der Signatur beinhaltetdie Berechnung aller Hashwerte der signierten Teile, sowie den Vergleich mit demSignatureValue der Signatur.Es muss geprüft werden, ob alle gemäß den Anforderungen in Abschnitt 5.2.3 spezifiziertenElemente signiert sind und keine zusätzlichen Elemente signiert wurden.Es muss geprüft werden, ob die verwendeten Signaturalgorithmen den Anforderungenin Abschnitt 5.2.3 entsprechen und keine unsicheren Algorithmen verwendet wurden.Es muss geprüft werden, ob das Zertifikat des Datenbearbeiters gültig ist. Eine nähereSpezifikation der Gültigkeitsprüfung wird in TUC_PKI_018 spezifiziert.Es muss geprüft werden, dass das XML Format der Signatur den Anforderungenentspricht. Insbesondere zählt hierzu die Einhaltung der nachfolgenden, in Abschnittgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 95 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAktivitätRollenerrnittlungWird eine anonymisierte Nachrichterwartet?Prüfung auf Rolle BrokerAuslesen der Rolle aus derNachrichtGenerierung eines Fehlers mitden Details der fehlgeschlagenenAuthentifizierungBeschreibung5.2.3 gestellten Anforderungen:A_01519, A_01521, A_01522, A_01525, A_01528, A_01529, A_01531, A_01532,A_01538, A_01539, A_01541Aus dem Zertifikat des Datenbearbeiters muss die Rolle ausgelesen werden. DieBestimmung der Rolle aus den verschiedenen Zertifikatstypen wird in TUC_PKI_009spezifiziert.In diesem Entscheidungspunkt wird geprüft, ob durch diesen Fachdienst nur anonymisiertesignierte Nachrichten verarbeitet werden oder nicht.Anonymisierung innerhalb der TI darf nur durch den Broker durchgeführt werden. Andieser Stelle wird geprüft, ob die in dem Zertifikat enthaltene OID der Rolle Brokerentspricht. Die Liste der OIDs für Rollen stellt Konfigurationsinformationen dar undmuss durch den Betrieb zur Verfügung gestellt werden.Sofern eine Anonymisierung der Nachricht im Vorfeld stattgefunden hat, ist die Rolledes Datenbearbeiters in das Element GTEL:RoleDataProcessor (vgl. Abschnitt5.2.2.18) eingetragen. Diese Rolle wird der Autorisierungsfunktion zur Verfügunggestellt.Sofern einer der zuvor dargestellten Verarbeitungsschritte nicht erfolgreich zu Endegeführt werden konnte, muss die weitere Verarbeitung abgebrochen werden und miteiner Fehlermeldung reagiert werden. Die Fehlermeldungen sowie die auslösendenBedingungen sind in Anhang A4 spezifiziert.A2.2 – Authentifizierung der DatenautoritätDie Identität der Datenautorität wird üblicherweise über die Signatur der Payload übermittelt.Durch die Prüfung der Signatur der Payload kann validiert werden, dass bei der Erstellungder Nachricht die im Zertifikat angegebene Identität, anwesend war. Nachdem überprüftwurde, dass die Nachricht authentisch signiert wurde, können alle in dem übermitteltenZertifikat enthaltenen Informationen als Basis für die Autorisierung herangezogen werden.Für den Fall, dass die Identität der Datenautorität mit der Identität des Datenbearbeitersübereinstimmt oder bereits ObjektTickets in der Nachricht enthalten sind, wird auf die Erstellungeiner weiteren Signatur innerhalb einer Nachricht verzichtet. Aus diesem Grundwird, sofern eine Nachricht keine Signatur der Payload enthält, die Identität der Datenautoritätwie folgt ermittelt:• Enthält die Nachricht keine ObjektTickets, so wird die Identität der Datenautoritätmit der Identität des Datenbearbeiters gleichgesetzt.• Enthält die Nachricht mindestens ein ObjektTicket, so wird die Identität derDatenautorität für die Nachricht aus der Identität der Datenautorität des letztenObjektTickets (aus dem für die Signatur verwendeten Zertifikat) ermittelt. Fernerist zu prüfen, dass die Datenautorität aller ObjektTickets identisch sindund andernfalls MUSS die Nachrichtenverarbeitung mit dem Fehler 03007 abgebrochenwerden.Abbildung 15 stellt den für die Authentifizierung des Datenbearbeiters notwendigen Ablaufin einer Übersicht dar. Die Beschreibung der einzelnen Verarbeitungsschritte erfolgt imAnschluss.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 96 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-Detailsact Authentifizierung DatenautoritätStart der AuthentifizierungNeinIst die Payloadsigniert?NeinEnthält dieNachrichtObjektTicketsJaJaPrüfung, dass alle IDAs derTickets identisch sindokJaIst IDA des Ticketsidentisch zu IDBder Nachricht?NeinWähle Signatur des letztenTickets als Signatur derDatenautoritätPrüfungen gemäß gemSpec_TicketPrüfung der Ticket-SignaturFehlerPrüfung der SignaturFehlerFehlerVerwenden des Zertifikats derDatenbearbeiterauthentifizierungokokBestimmung des eindeutigenAuthentifizierungsmerkmalsAbhängig vom ZertifikatstypGenerierung eines Fehlersmit den Details derfehlgeschlagenenAuthentifizierungokEnde der AuthentifizierungAbbildung 15: Authentifizierung der DatenautoritätAktivitätIst die Payload signiert?Enthält die Nachricht ObjektTickets?BeschreibungDie Payload-Signatur kann zum Zwecke der Transportoptimierung weggelassenwerden, wenn die Identität der Datenautorität mittels anderen Mechanismen festgestelltwerden kann.Enthält die Nachricht ObjektTickets, so wird die Identität der Datenautorität derNachricht durch die Identität der Datenautorität eines Tickets bestimmt.Andernfalls wird davon ausgegangen, dass die Identität des Datenbearbeiters mitder Identität der Datenautorität übereinstimmt und es wird die zuvor validierte Identitätdes Datenbearbeiters als Identität der Datenautorität übernommen und für dieweitere Verarbeitung verwendet.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 97 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsAktivitätBeschreibungPrüfung, dass alle IDAs der Ticketsidentisch sindDatenautorität aller ObjektTickets identisch sind. Hierzu ist es ausreichend, dass dieSind mehrere ObjektTickets enthalten, so muss sichergestellt werden, dass dieZertifikatverweise in der Signatur bei allen Tickets identisch sind.Wähle Signatur des letzten ObjektTicketsals Signatur der Da-heran gezogen. Es wird aus dem für die Signatur verwendeten Zertifikat das eindeu-Die Signatur des letzten ObjektTickets wird zur Autorisierung der Datenautoritättenautoritättige Identifikationsmerkmal der Datenautorität ermittelt und für die weitere Verwendungals IDA der Nachricht benutzt werden.Ist IDA des Tickets identisch zur Sind die Identitäten der Datenautorität und die des Datenbearbeiters identisch, soIDB der Nachricht?wird auf eine weitere Prüfung der Signaturen verzichtet und die zuvor validierteIdentität des Datenbearbeiters als Identität der Datenautorität übernommen und fürdie weitere Verarbeitung verwendet.Verwenden des Zertifikats der Ziel der Authentifizierung ist es sicherzustellen, dass eine vorgegebene Identität anDatenbearbeiterauthentifizierung der Erstellung der Nachricht beteiligt war. Es wird im Rahmen der Authentifizierungkein Zugriff auf Daten gewährt. Dies erfolgt erst im Rahmen der Autorisierung.Die Anwesenheit des Datenbearbeiters wurde bereits in der Authentifizierung desDatenbearbeiters überprüft und somit kann die Identität als Grundlage für die weitereVerarbeitung verwendet werden.Prüfung gemäß gemSpec_Ticket Die Signatur des letzten ObjektTickets wird gemäß den Anforderungen in[gemSpec_Ticket#Tabelle 50, Anforderungen an ds:Signature des ObjectTickets]geprüft. Dabei ist die Prüfung der Ticket-Signatur gemäß Abschnitt 4.10 durchzuführen.Mathematische Prüfung der Die Signatur ist gemäß Abschnitt 4.10 unter der Berücksichtung der Anforderung inSignaturAbschnitt 5.2.4.14 bzgl. Menge der zu signierenden Elemente, Signaturalgorithmenund Signaturformat zu prüfen.Insbesondere zählt hierzu die Einhaltung der nachfolgenden, in Abschnitt 5.2.4.14gestellten Anforderung:A_01550 Die mathematische Überprüfung der Signatur beinhaltet die Berechnungaller Hashwerte der signierten Teile, sowie den Vergleich mit dem SignatureValueder SignaturPrüfung der signierten Elemente Es muss geprüft werden, ob alle gemäß den Anforderungen in Abschnitt 5.2.4.14spezifizierten Elemente signiert sind und keine zusätzlichen Elemente signiert wurden.Prüfung der verwendeten AlgorithmenZertifikatsprüfungPrüfung des SignaturformatsBestimmung des eindeutigenAuthentifizierungsmerkmalsabhängig vom ZertifikatstypEs muss geprüft werden, ob die verwendeten Signaturalgorithmen den Anforderungenin Abschnitt 5.2.4.14 entsprechen und keine unsicheren Algorithmen verwendetwurden.Es muss geprüft werden, ob das Zertifikat des Datenbearbeiters gültig ist. Einenähere Spezifikation der Gültigkeitsprüfung wird in TUC_PKI_018 spezifiziert.Es muss geprüft werden, dass das XML Format der Signatur den Anforderungenentspricht. Insbesondere zählt hierzu die Einhaltung der nachfolgend in Abschnitt5.2.4.14 gestellte Anforderung:A_01550Im Rahmen der Autorisierung muss ein in einem Zertifikat enthaltenes Authentifizierungsmerkmalmit einer hinterlegten Berechtigung verglichen werden. Hierdurch wirdverhindert, dass bei dem Hinterlegen der Berechtigung immer das gesamte Zertifikatgespeichert werden muss und ein langsamer Vergleich auf Bit-Ebene erfolgen muss.Stattdessen kann das Authentifizierungsmerkmal aus dem Zertifikat ausgelesen undim Rahmen der Autorisierung auf Stringebene verglichen werden.[gemGesArch#Anhang B2] definiert zu entsprechenden Zertifikaten, die Bestandteileaus denen das eindeutige Merkmal sich zusammensetzt.Release-Einschränkung R2 – Nur ID.CH.AUTN als DatenautoritätAls Grundlage für die Identität der Datenautorität darf in R2 ausschließlich daspseudonyme Zertifikat der eGK verwendet werden. (diese Validierung erfolgt gemäßTUC_PKI_007)Generierung eines Fehlers mitden Details der fehlgeschlagenenAuthentifizierungSofern einer der zuvor dargestellten Verarbeitungsschritte nicht erfolgreich zu Endegeführt werden konnte, muss die weitere Verarbeitung abgebrochen werden und miteiner Fehlermeldung reagiert werden. Die Fehlermeldungen sowie die auslösendenBedingungen sind in Anhang A4 spezifiziert.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 98 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsA3 – AutorisierungsprüfungDie Autorisierungsprüfung zerfällt gemäß [gemGesArch] in die Autorisierungsprüfung fürdie Datenautorität und den Datenbearbeiter. Wie in Abschnitt 4.2 erläutert, findet die Autorisierungsprüfungder Datenautorität nicht als Bestandteil des Transports sondern auf Anwendungsebenestatt. Nachfolgend wird aus diesem Grund auch nur die Autorisierungsprüfungdes Datenbearbeiters spezifiziert.A3.1 – Abbildung von Akteuren, Rollen und OIDsMigration der Inhalte nach [gemSiKo]Die in diesem Abschnitt definierten Inhalte stellen übergreifende Sicherheitsanforderungen dar und sind inhaltlich somit demSicherheitskonzept [gemSiKo] zugeordnet. Zur Unterstützung der Hersteller wurden die Inhalte bis zur Veröffentlichungeiner aktualisierten Version des Sicherheitskonzeptes temporär in diesem Dokument aufgenommen.Mit dem aktuellen Dokumentenpaket sind die Inhalte in editorisch überarbeiteter Form in Kapitel 6 des Sicherheitskonzeptesübernommen wurden. Inhaltliche Änderungen, die zu Anpassungen der Implementierung führen, entstehen durch dieseeditorische Überarbeitung nicht, und es wurden lediglich Anpassung an der Darstellung und Erläuterung vorgenommen.A3.1 – Rollenbasierte Autorisierungsprüfung von TelematiknachrichtenIn [gemGesArch] wird gefordert, dass für jeden Zugriff auf Daten eines Versicherten einhybrides Rechte- und Zugriffskonzept verwendet wird. Dieses Konzept unterscheidet zwischender Autorisierungsprüfung der Datenautorität und der Autorisierungsprüfung desDatenbearbeiters. Dieser Abschnitt spezifiziert, wie die Autorisierungsprüfung des Datenbearbeitersdurchgeführt werden muss und welche Informationen für diese Prüfung benötigtwerden.Generell ist der Datenbearbeiter autorisiert, einen Zugriff durchzuführen, wenn die im Zertifikatdes Datenbearbeiters enthaltene OID der Rolle in Kombination mit der Fachdienstoperation(z. B. ReadVO auf einem VODD usw.) als berechtigt spezifiziert wurde. DieseInformation ist teilweise Fachdienstspezifisch (Berechtigungen für Fachdienstoperationen)und teilweise den Fachdienst übergreifend (Zuordnung von Rollen OIDs zu Rollenbezeichnernund Zuordnung Rollenbezeichner zu fachlichen Akteuren). Um Inkonsistenzenzu vermeiden wurden die einzelnen Inhalte eindeutig dem relevanten Dokument zugeordnetund müssen im Rahmen der Implementierung eines Dienstes zu einer RBAC-Matrix(Role Based Access Control Matrix - rollenbasierten Zugriffsmatrix) zusammengeführtwerden. Die genaue Verteilung der Aufgaben der einzelnen Dokumente ist in [gemSi-Ko#6] definiert.In [gemSpec_OID] wird die Zuordnung zwischen OIDs für Rollen und den Rollenbezeichnerndefiniert. In [gemSiKo] ist die normative Liste der Rollenbezeichner aufgenommenund es werden dort auch die Rollenbezeichner den fachlichen Akteuren zugeordnet.Durch die Facharchitekturen werden für jeden fachlichen Akteur die Zugriffsberechtigungenfür Fachdienstoperationen spezifiziert. Die Zusammenführung der einzelnen Tabellensowie die Überlappung der einzelnen Tabellen zu einer RBAC-Matrix ist in Tabelle 29exemplarisch dargestellt.Es wird empfohlen im Rahmen der Implementierung eines Fachdienstes die RBAC-Matrixals Bestandteil der Konfiguration zu betrachten und nicht fest im Code zu verankern. Diegematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 99 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsKonfiguration der RBAC-Matrix MUSS in diesem Fall mit angemessenen Maßnahmengegen unerlaubte Manipulation abgesichert werden.Tabelle 29: Exemplarische RBAC-Matrix für DatenbearbeiterOID der Rolle desDatenbearbeiters[gemSpec_OID]Rollenbezeichnung[gemSiKo]Fachlicher AkteurFacharchitekturen1.2.3.4.5.6.7.8.9.5 Apotheker / -in Apotheker B B B1.2.3.4.5.6.7.8.9.2 Öffentliche Apotheke Mitarbeiter Apotheke B NB B1.2.3.4.5.6.7.8.9.5 Abrechnungsstelle Kein fachlicher Akteur NB NB NB1.2.3.4.5.6.7.8.9.6 Ärztin / Arzt Arzt B B NB1.2.3.4.5.6.7.8.9.7 Arztpraxis Mitarbeiter medizinische Institution B B NBReadVOWriteVODispenseVOBasierend auf der zuvor dargestellten RBAC-Matrix stellt sich die Autorisierungsprüfungfür den Datenbearbeiter als einfache Entscheidung dar, in dem geprüft wird ob die RollenOID des Datenbearbeiters eine Berechtigung für die Ausführung der Fachdienstoperationgemäß der RBAC-Matrix besitzt (B). Sofern dies der Fall ist, muss der Zugriff gewährtwerden, wenn keine Berechtigung vorliegt (NB) muss der Zugriff verweigert werden undeine Fehlermeldung generiert werden.Diese Information kann gemäß dem in Anhang A3.1 definierten Vorgehen in einer einfachenRBAC-Matrix (Role Based Access Control Matrix - rollenbasierten Zugriffsmatrix)abgebildet werden, in der für alle möglichen Kombinationen eine Aussage zur Berechtigungenthalten ist. Diese RBAC-Matrix würde die in Anhang A3.1 definierten Zusammenhängeredundant darstellen und mit hoher Wahrscheinlichkeit zu Inkonsistenzen führen.Aus diesem Grund wird die RBAC Matrix in ihrer Gesamtheit nicht bereitgestellt und mussdurch den Implementierer gemäß dem in Anhang A3.1 definierten Vorgehen entweder alsrelationale RBAC Matrix oder als einfache Tabelle zusammengesetzt werden. In Tabelle30 ist exemplarisch eine solche RBAC Matrix erstellt worden.Das Kürzel „B“ bedeutet in dieser Tabelle - berechtigt, „NB“ - nicht berechtigt und „KP“bedeutet es findet keine Berechtigungsprüfung statt, somit ist jede Rolle zur Ausführungberechtigt.Tabelle 30: Exemplarische RBAC-Matrix für DatenbearbeiterEine Institution (Arztpraxis, Krankenhaus, Apotheke) ist kein fachlicher Akteur gemäߧ291a und den Fachkonzepten der TI. Zusätzlich kann eine Institution nie selbst etwastun. Stattdessen benutzt ein Mitarbeiter einer medizinischen Institution oder einer Apothekeeine SMC-B mit der Rolle einer Institution, um sich in der Telematik auszuweisen undin deren Auftrag zu agieren. Dies erklärt die scheinbare Diskrepanz zwischen der Rollenbezeichnungund dem fachlichen Akteur.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 100 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsBasierend auf der zuvor dargestellten RBAC-Matrix stellt sich die Autorisierungsprüfungfür den Datenbearbeiter als einfache Entscheidung dar. Hierbei wird geprüft, ob die RollenOID des Datenbearbeiters eine Berechtigung für die Ausführung der Fachdienstoperationgemäß der RBAC-Matrix besitzt.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 101 von 115Version: 1.6.0 © gematik Stand:27.06.2008

SpezifikationTelematikTransport-DetailsA4 – Fehlercodes TelematikTransportDa es sich bei der Spezifikation [gemSpec_TTD] um ein Transportprotokoll handelt müssen gemäß [gemSpec_FM] alle Fehlermeldungen alsgematik SOAP-Fault transportiert werden. Bei einem gematik SOAP-Fault handelt es sich um eine spezifische Ausprägung eines SOAP-Faults gemäß [SOAP 1.1]. Die generelle Befüllung der SOAP-Fault Nachricht ist in [gemSpec_FM] spezifiziert.Die Details des aufgetretenen Fehlers, sowie die Information welcher Fehler aufgetreten ist, sind für das Eventmangement eines Betreiberszwingend notwendig, würden einem Angreifer jedoch möglicherweise Hinweise liefern, die dieser verwenden könnte. Aus diesem GrundMUSS zwischen den lokal protokollierten Fehlern und den an einen Aufrufer gemeldeten Fehlern unterschieden werden. In den nachfolgendenTabellen sind alle Fehler enthalten, die bei der Verarbeitung im Rahmen des TelematikTransports auftreten können. Falls für den aufgetretenenFehler eine abweichende allgemeine Meldung versandt werden muss, so wird gemäß [gemSpec_FM] in der Spalte „Abbildungdurch“ die Fehlermeldung angegeben, die an den Aufrufer gemeldeten werden muss. Falls in der Spalte „Abbildung durch“ kein Eintrag vorhandenist, so kann der angegebene Fehler direkt transportiert werden.Tabelle 31: TTD Fehlercodes allgemein (Code Bereich 01000 – 01999)ComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchTTD 00100-00599Technical gematik SOAPFaultFATAL Gemäß Definition in[gemSpec_FM]Es ist ein Kommunikationsfehlerauf der direkten Kommunikationzwischen zwei Komponentenaufgetreten.TTD 01001 Technical gematik SOAPFaultFATAL Der Sender verwendet einungültiges NachrichtenschemaTTD 01002 Technical gematik SOAPFaultTTD 01003 Technical gematik SOAPFaultTTD 01004 Technical gematik SOAPFaultFATALFATALFATALDer Sender verwendet einenicht unterstützte TransportschnittstellenVersionDer Sender verwendet einenicht unterstützte KomponentenversionDer Sender verwendet einenicht unterstützte Operationfür diese KomponenteEs sollen detaillierte Informationenbereitgestellt werden, die angeben,aus welchem Grund das Schemaungültig ist.Angabe der Interfaceversion, dereingegangenen Nachricht.Angabe der Interfaceversion, Componentversion,Component dereingegangenen Nachricht.Angabe der Interfaceversion, Componentversion,Component undOperation der eingegangenen Nach-Das Nachrichtenschema entsprachnicht dem Schema, dasgemäß Interfaceversion vorgegebenwurde.Die Version der Interfaceversionder Telematiknachricht wird durchden Empfänger nicht unterstütztDie Version der Component in derTelematiknachricht wird durchden Empfänger nicht unterstützt.Es wurde eine Fachdienstoperationaufgerufen, die durch denEmpfänger der Nachricht nichtgematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 102 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung Abbildungdurchricht.unterstützt wird.FATAL Nachricht zurückgewiesen.Die Nachricht wurde von dem 10004Die Anfrage wurde als Replay-Empfänger der Nachricht alsAttacke eingestuft und dieReplay-Attacke eingestuft.Verarbeitung abgebrochen.TTD 01005 Security gematik SOAPFaultTTD 01006 Security gematik SOAPFaultTTD 01007 Security gematik SOAPFaultTTD 01008 Technical gematik SOAPFaultTTD 01009 Technical gematik SOAPFaultTTD 01010 Technical gematik SOAPFaultTTD 01011 Technical gematik SOAPFaultTTD 01012 Technical gematik SOAPFaultFATALFATALFATALFATALFATALFATALFATALNachricht zurückgewiesen.Die Nachricht wurde an einenfür diese Anfrage nicht zuständigenFachdienst weitergeleitet.Nachricht zurückgewiesen.Der Zeitstempel der Nachrichtliegt außerhalb des zulässigenBereichs.Es ist ein Fehler in der SOAP-Übertragung aufgetreten.Die Dekodierung eines Parametersder Operation warnicht möglich.Die Parameter der aufgerufenenOperation oder die verwendeteKodierung entsprichtnicht der Vorgabe für denAufruf dieser Operation.Die aufgerufene Komponenteist temporär nicht verfügbar.Nachricht kann aufgrund derGröße nicht versendet wer-Angabe welcher der Lokalisierungsparameterungültig war und welcherWert stattdessen erwartet würde.Angabe von Creation- und Expiration-Dateder eingegangenen Nachricht,sowie des Systemdatums undder Systemzeit des überprüfendenSystems in UTC.SOAP Fault der auf dem intermediärempfangen wurde.Angabe des Parameter Namens dernicht dekodiert werden konnte sowieder gewählten Kodierung. Die Übertragungdes Inhalts des Parametersist nicht zulässig.Angabe der empfangenen und erwartetenParameter Namen undKodierungen.Die Details sollen Informationenenthalten, welche Komponente nichtverfügbar ist und aus welchemGrund die Komponente nicht verfügbarist und ob ein erneuter Versuchder Übertragung sinnvoll ist.Die Größe der zu versenden Nachrichtübersteigt die maximal zulässi-Die Überprüfung der Lokalisierungsinformationeninnerhalbeines Fachdienstes führt zu demErgebnis, dass die Nachricht anden falschen Empfänger (Fachdienst)gesendet wurde.Die Überprüfung des Zeitstempelseiner Nachricht hat ergeben, dasssich die Nachricht außerhalb desgültigen Zeitfensters befindet.Es wurde ein Fehler gemäß derSpezifikation des SOAP 1.1Standards empfangen. In diesemFall muss der Body des empfangenenSOAP Faults als Base64kodiertes XML in den gematikSOAP Fault übernommen werden.Die Dekodierung eines base64kodierten Parameters der Payloadist fehlgeschlagen.Es wurde eine Telematiknachrichtempfangen, bei der die zu deraufgerufenen Operation gehörigenParameter bzw. deren Kodierungnicht mit den Spezifikationender Architektur übereinstimmen.Bei der Verarbeitung einer Nachrichtwurde festgestellt, dass fürdie Verarbeitung dieser Nachrichteine benötigte Komponente nichtverfügbar ist.Bei der Erstellung der Nachrichtwurde festgestellt, dass die1000410004gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 103 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung Abbildungdurchden.ge Größe. Die Nachricht darf nichtversendet werden.Anforderung [A_01590] nichteingehalten werden kann.FATAL Nachricht kann nicht entschlüsseltDie verschlüsselte Nachricht kannwerden.nicht entschlüsseltwerden.TTD 01013 Technical gematik SOAPFaultFür die Verschlüsselung wurdeein Zertifikat verwendet, dessenzugehöriger privater Schlüsseldem Empfänger nicht vorliegt,oder es hat in der Zwischenzeitein Schlüsselwechsel statt gefunden.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 104 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 32: TTD Fehlercodes Datenbearbeiter (Code Bereich 02000 – 02999)ComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchTTD 02001 Security gematik SOAPFaultFATAL Es ist ein Fehler bei der Authentifizierungdes Datenbearbeitersaufgetreten.Nähere Angaben zu dem aufgetretenenFehlerDieser Fehler muss generiertwerden, wenn die eine Authentifzierungeines Datenbearbeitersfehlgeschlagen ist und kein detaillierterFehler spezifiziert wurde.Dieser Fehler resultiert immer inmanueller Fehlerbearbeitung undmuss in den Details zusätzlicheInformationen über den aufgetretenenFehler enthalten.10000TTD 02002 Security gematik SOAPFaultTTD 02003 Security gematik SOAPFaultTTD 02004 Security gematik SOAPFaultFATALFATALFATALDie Signatur des Datenbearbeitersentspricht nicht derSpezifikation.Die Signatur des Datenbearbeitersist kryptographischungültig.Das für die Signatur verwendeteZertifikat des Datenbearbeitersist nicht mehr gültig.Nähere Beschreibung aus welchemGrund die Signatur der empfangenenNachricht nicht der Spezifikationentspricht.Angabe des Hashwerts der signiertenDaten, der durch den Empfängererrechnet wurde, sowie der empfangeneSignaturwert (SignatureValue).Angabe aus welchem Grund dasZertifikat abgelehnt wurde. MöglicheUrsachen sind der Ablauf des imZertifikat angegebenen Gültigkeitszeitraumsbzw. eine Meldung desOCSP Responders.Sofern der Gültigkeitszeitraum desZertifikates abgelaufen war, mussDie Signatur des Datenbearbeitersentspricht nicht der Spezifikation.Dies kann zum Beispiel derFall sein, wenn ungültige Algorithmenverwendet wurden oderdie falschen Elemente signiertwurden. Dieser Fehler mussimmer manuell behandelt werden,da es sich um einen Fehler ineiner Implementierung handelt.Die Details sollen weitere Informationenüber den aufgetretenenFehler enthalten.Die Signatur des Datenbearbeitersist kryptographisch ungültig.Das bedeutet, der Hashwert dervorliegenden Daten wurde nichtmit dem zu dem Zertifikat gehörigenprivaten Schlüssel verschlüsselt.Dies kann z. B. durch eineManipulation der Daten oder dieAngabe eines falschen Zertifikatesverursacht sein.Das für die Datenbearbeitersignaturverwendete Zertifikat ist ungültig.Die Ursache kann entwedereine Antwort des OCSP Responderssein, der dieses Zertifikat alsExpired ausweist oder die Überschreitungdes im Zertifikat enthaltenenGültigkeitszeitraums.100001000010000gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 105 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung Abbildungdurchdas Systemdatum sowie die Systemzeitdes Empfängers als UTC angegebenwerden. Sofern die Meldungdes OCSP Responders das Zertifikatals ungültig meldet, muss die Antwortdes OCSP Responders mitgeliefertwerden.TTD 02005 Security gematik SOAPFaultTTD 02006 Security gematik SOAPFaultTTD 02007 Security gematik SOAPFaultFATALFATALFATALDie Rolle des Datenbearbeitersbesitzt keine Rechte aufdie aufgerufene Operation.Das für die Signatur verwendeteZertifikat des Datenbearbeitersist noch nicht gültig.Nicht erwartete anonymisierteNachricht wurde empfangen.Angabe der aufgerufenen Operationsowie der Rolle des Datenbearbeiters.Angabe aus welchem Grund dasZertifikat noch nicht gültig ist. MöglicheUrsache ist ein in der Zukunftliegender „gültig ab“ Zeitpunkt bzw.eine Meldung des OCSP-Responders.Sofern der Gültigkeitszeitraum desZertifikates in der Zukunft beginnt,muss das Systemdatum sowie dieSystemzeit des Empfängers als UTCangegeben werden. Sofern dieMeldung des OCSP-Responders dasZertifikat als ungültig meldet, mussdie Antwort des OCSP-Respondersmitgeliefert werden.Die Rolle des Datenbearbeiterserlaubt keinen Zugriff auf dieangefragte Operation.Das Zertifikat des Datenbearbeitersist noch nicht gültig. Dies istder Fall, wenn das in dem „Gültigab“ Feld des Zertifikats enthalteneDatum in der Zukunft liegt oderder OCSP-Responder das Zertifikatals noch nicht gültig meldet.Bei der Authentifzierung desDatenbearbeiters wurde eineanonymisierte Nachricht empfangen,obwohl für den vorgegebenenAnwendungsfall keine anonymisiertenNachrichten erwartetwurden.100021000010000gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 106 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 33: TTD Fehlercodes Datenautorität (Code Bereich 03000 – 03999)ComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchTTD 03001 Technical gematik SOAPFaultFATAL Es ist ein Fehler bei der Authentifizierungder Datenautoritätaufgetreten.Nähere Angaben zu dem aufgetretenenFehlerDieser Fehler muss generiertwerden, wenn die eine Authentifzierungeiner Datenautoritätfehlgeschlagen ist und kein detaillierterFehler spezifiziert wurde.Dieser Fehler resultiert immer inmanueller Fehlerbearbeitung undmuss in den Error Details (DetailError) zusätzliche Informationenüber den aufgetretenen Fehlerenthalten.10001TTD 03002 Security gematik SOAPFaultTTD 03003 Security gematik SOAPFaultTTD 03004 Security gematik SOAPFaultFATALFATALFATALDie Signatur der Datenautoritätentspricht nicht der Spezifikation.Die Signatur der Datenautoritätist kryptographisch ungültig.Das für die Signatur verwendeteZertifikat der Datenautoritätist nicht mehr gültig.Nähere Beschreibung aus welchemGrund die Signatur der empfangenenNachricht nicht der Spezifikationentspricht.Angabe des Hashwerts der signiertenDaten der durch den Empfängererrechnet wurde, sowie der empfangeneSignaturwert (Signature Value).Angabe aus welchem Grund dasZertifikat abgelehnt wurde. MöglicheUrsachen sind der Ablauf des imZertifikat angegebenen Gültigkeitszeitraumsbzw. eine Meldung desOCSP-Responders.Sofern der Gültigkeitszeitraum desDie Signatur der Datenautoritätentspricht nicht der Spezifikation.Dies kann zum Beispiel der Fallsein, wenn ungültige Algorithmenverwendet wurden oder die falschenElemente signiert wurden.Dieser Fehler muss immer manuellbehandelt werden, da es sichum einen Fehler in einer Implementierunghandelt. Das DetailElement soll weitere Informationenüber den aufgetretenenFehler enthalten.Die Signatur der Datenautorität istkryptographisch ungültig. Dasbedeutet, der Hashwert der vorliegendenDaten wurde nicht mitdem zu dem Zertifikat gehörigenprivaten Schlüssel verschlüsselt.Dies kann z. B. durch eine Manipulationder Daten oder die Angabeeines falschen Zertifikatesverursacht sein.Das für die Datenautoritätssignaturverwendete Zertifikat ist ungültig.Die Ursache kann entwedereine Antwort des OCSP-Responders sein, der diesesZertifikat als Expired ausweistoder die Überschreitung des im100011000110001gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 107 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchZertifikates abgelaufen war, mussdas Systemdatum sowie die Systemzeitdes Empfängers als UTC angegebenwerden. Sofern die Meldungdes OCSP-Responders das Zertifikatals ungültig meldet, muss die Antwortdes OCSP-Responders mitgeliefertwerden.Zertifikat enthaltenen Gültigkeitszeitraums.TTD 03005 Security Gematik SOAPFaultTTD 03006 Security Gematik SOAPFaultTTD 03007 Security Gematik SOAPFaultFATALFATALFATALReplay-Attacke erkannt. DieMessageID der Payloadstimmt nicht mit der MessageIDdes TelematikHeadersüberein.Die Datenautorität besitzt nichtdie notwendigen Zugriffsrechteauf die gewünschte OperationDie Datenautorität der Nachrichtkann nicht eindeutigbestimmt werden, da dieDatenautoritäten der enthaltenenObjektTickets von einanderabweichenAngabe der MessageID des TelematikHeadersund des Bodies.Dieser Fehler muss generiertwerden, wenn bei der Authentifizierungder Datenautorität dieMessageID des Bodies nicht mitder MessageID des Headersübereinstimmt.Dieser Fehlercode muss verwendetwerden, wenn die Autorisierungder Datenautorität fehlgeschlagenist. Generell ist dieserFehler nur zu verwenden, wennkein detaillierter Fehler z. B. in derSpezifikation Ticketservice definiertwurde.Dieser Fehlercode muss verwendetwerden, wenn in einer Nachrichtauf die Signatur der Datenautoritätverzichtet wurde undObjektTickets in der Nachrichtenthalten sind, die mit unterschiedlichenIdentitäten signiertwurden.100041000310004gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 108 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 34: TTD Fehlercodes Dateneigentümer (Code Bereich 04000 – 04999)ComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchTTD 04001 Technical gematik SOAPFaultFATAL Die ProviderGroup aus demTelematikHeader stimmt nichtmit dem tatsächlichen Wertüberein.10001Das Element/GTEL:TelematikHeader/GTEL:Insurant/GTEL:ProviderGroup beinhalteteine abweichende ProviderGroupvon dem tatsächlich zu erwartendemWert.Dieser Fehler muss generiertwerden, wenn das Feld ProviderGroupim Element DataOwnervorhanden sein muss und dieservom tatsächlich zu erwartendemWert abweicht. Der tatsächlich zuerwartende Wert kann aus einemObjektTicket entnommen werden,oder falls die KVNR dem Fachdienstbekannt ist, kann sie ausder KVNR berechnet werden.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 109 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 35: TTD Transportfehler (Code Bereich 10000 – 10100)ComponentTypeCode ErrorType Transportweg Severity Text Detail Auslösende Bedingung AbbildungdurchTTD 10000 Security Gematik SOAPFaultFATAL Der Datenbearbeiter konntenicht authentifiziert werdenDer Fehler wird nicht direkt ausgelöstsondern wird indirekt ausgelöst,TTD 10001 Security Gematik SOAPFaultFATAL Die Datenautorität konntenicht authentifiziert werdenwenn ein Sicherheitsfehlerausgelöst wurde der nicht transportiertTTD 10002 Security Gematik SOAPFaultFATAL Der Datenbearbeiter ist fürdiesen Zugriff nicht autorisiertwerden darf und ein Map-ping erfolgt.TTD 10003 Security Gematik SOAPFaultFATAL Die Datenautorität ist fürdiesen Zugriff nicht autorisiertTTD 10004 Security Gematik SOAPFaultFATAL Es ist ein technischer sicherheitsrelevanterFehler aufgetreten.gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 110 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsAnhang BB1 – AbkürzungsverzeichnisKürzelAdVDADBeGKFAHBAIDBIKKVNROTRBACSDSSIGSMCSOAPSTTIVODVODDVODMVSDVSDDVSDMWSDLWSSXSDErläuterungAnwendungen des VersichertenDatenautoritätDatenbearbeiterelektronische GesundheitskarteFacharchitekturHeilberufeausweisIdentität des DatenbearbeitersInstitutionskennzeichenKrankenversichertennummerObjektTicketRole Based Access ControlService Directory ServiceSignaturSecurity Module CardStandard für die Kommunikation innerhalb der WEB-ServicesServiceTicketTelematikinfrastrukturVerordnungsdatenVerordnungsdatendienstVerordnungsdatenmanagementVersichertendatenVersichertendatendienstVersichertendatenmanagementWeb Services Description LanguageWebservices Security SpezifikationExtensible Schema DefinitionB2 – GlossarDas Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.B3 – AbbildungsverzeichnisAbbildung 1: Einordnung der Spezifikation TelematikTransport-Details...........................11Abbildung 2: Einordnung der TelematikTransport-Adaptierung........................................18Abbildung 3: TelematikTransport-Details.........................................................................20gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 111 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsAbbildung 4: Aktivitätsdiagram Nachrichtenverarbeitung durch Fachdienste...................27Abbildung 5: Aufbau SOAP Nachrichtenstruktur..............................................................31Abbildung 6: Allgemeine Gültigkeitsdauer von Telematiknachrichten..............................37Abbildung 7: Exemplarische Gültigkeitsdauer von Telematiknachrichten.........................38Abbildung 8: Gültigkeitsdauer von Telematiknachrichten mit ObjektTicket.......................39Abbildung 9: Aktivitätendiagramm Prüfung von Signaturen..............................................41Abbildung 10: Aktivitätendiagramm SOAP Fault Behandlung..........................................46Abbildung 11: Graphische Darstellung des Elementes TransportHeader.........................49Abbildung 12: Graphische Darstellung des Elementes GTEL:TelematikHeader..............55Abbildung 13: Graphische Darstellung des Elementes TelematikExecute.......................73Abbildung 14: Authentifizierung Datenbearbeiter.............................................................95Abbildung 15: Authentifizierung der Datenautorität..........................................................97B4 – TabellenverzeichnisTabelle 1: Funktionale Anforderungen.............................................................................16Tabelle 2: Nicht-funktionale Anforderungen.....................................................................17Tabelle 3: Sicherheitsanforderungen...............................................................................17Tabelle 4: Übersicht fachspezifischer Parameter.............................................................21Tabelle 5: Normatives Format der Parameterliste für Facharchitekturen mit nichtnormativen, exemplarischen Inhalten.......................................................................25Tabelle 6: Verarbeitungsschritt Validierung der eingehenden Nachricht..........................28Tabelle 7: Verarbeitungsschritt Authentifizierung des Datenbearbeiters und derDatenautorität...........................................................................................................28Tabelle 8: Verarbeitungsschritt Autorisierungsprüfung des Datenbearbeiters..................29Tabelle 9: Verarbeitungsschritt Prüfung der Operationsparameter...................................29Tabelle 10: Verarbeitungsschritt Autorisierungsprüfung der Datenautorität......................29Tabelle 11: Verarbeitungsschritt Verarbeitung durch ein Fachmodul...............................29Tabelle 12: Verarbeitungsschritt Erstellen einer Fehlernachricht......................................30Tabelle 13: Verarbeitungsschritt Erstellen einer SOAP Response...................................30Tabelle 14: Zuordnung der Parameter zu Elementen der SOAP-Nachrichtenstruktur......33Tabelle 15: Anwendungsfall übergreifende Parameterliste TTD.......................................35Tabelle 16: Ausgangsanforderungen an die Validierung der Telematiknachrichten(allgemein)................................................................................................................42Tabelle 17:Ausgangsanforderungen an die Validierung der Telematiknachrichten(Fachdienste)...........................................................................................................43gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 112 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-DetailsTabelle 18: Mapping von WSS-Faultcodes auf gematik SOAP-Faults.............................46Tabelle 19: Verwendung von Prefixes.............................................................................48Tabelle 20: Anforderungen an wsse:Security...................................................................69Tabelle 21: Anforderungen an wsu:Timestamp................................................................70Tabelle 22: Anforderungen an wsse:BinarySecurityToken...............................................71Tabelle 23: Anforderungen an ds:Signature (WSS Header).............................................71Tabelle 24: Anforderungen an xenc:EncryptedKey..........................................................75Tabelle 25: Anforderungen an ds:Signature (Payload).....................................................83Tabelle 26: Anforderungen an die Erstellung und Verarbeitung von SOAP-Nachrichten..86Tabelle 27: Messages WSDL SOAP-Transport...............................................................88Tabelle 28: PortType WSDL SOAP-Transport.................................................................88Tabelle 29: Exemplarische RBAC-Matrix für Datenbearbeiter........................................100Tabelle 30: Exemplarische RBAC-Matrix für Datenbearbeiter........................................100Tabelle 31: TTD Fehlercodes allgemein (Code Bereich 01000 – 01999).......................102Tabelle 32: TTD Fehlercodes Datenbearbeiter (Code Bereich 02000 – 02999).............105Tabelle 33: TTD Fehlercodes Datenautorität (Code Bereich 03000 – 03999)................107Tabelle 34: TTD Fehlercodes Dateneigentümer (Code Bereich 04000 – 04999)...........109Tabelle 35: TTD Transportfehler (Code Bereich 10000 – 10100)...................................110B5 – Referenzierte DokumenteDie nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokumentreferenzierten Dokumente der gematik. Der mit dem vorliegenden Dokument korrelierendeEntwicklungsstand dieser Konzepte und Spezifikationen, die im Rahmen des Vorhabenszur Einführung der Gesundheitskarte veröffentlicht werden, wird pro Release in einerDokumentenlandkarte definiert. Version und Stand der referenzierten Dokumente sinddaher in der nachfolgenden Tabelle nicht aufgeführt. Die jeweils gültige Version und dasFreigabedatum der aufgeführten gematik-Dokumente entnehmen Sie bitte der von dergematik veröffentlichten Dokumentenlandkarte (aktuell [gemDokLK_2.3.4]), wobei jeweilsder aktuellste Releasestand maßgeblich ist, in dem die vorliegende Version aufgeführtwird. Zur Unterstützung der Zuordnung wird in der Dokumentenlandkarte im Kapitel 4 eineÜbersicht über die Dokumentenversionen und deren Zuordnung zu den verschiedenenReleases bereitgestellt.[Quelle]Herausgeber (Erscheinungsdatum): Titel[gemBroker] gematik: Einführung der Gesundheitskarte -Spezifikation der Broker Services[gemDokLK_2.3.4] gematik: Einführung der Gesundheitskarte –Dokumentenlandkarte Releasestand 2.3.4 – Online Feldtest 10.000gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 113 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-Details[Quelle]Herausgeber (Erscheinungsdatum): TitelFestlegung der Versionsstände[gemGA_Wartg] gematik: Einführung der Gesundheitskarte -Anforderungen an die Komponenten zur Unterstützung der Wartungs-und Änderungsprozesse[gemGesArch] gematik: Einführung der Gesundheitskarte -Gesamtarchitektur,[gemSiKo] gematik: Einführung der Gesundheitskarte –Übergreifendes Sicherheitskonzept der Telematikinfrastruktur[gemSpec_FM] gematik: Einführung der Gesundheitskarte -Spezifikation Fehlerbehandlung[gemSpec_Krypt]gematik: Einführung der Gesundheitskarte - Verwendung kryptographischerAlgorithmen in der Telematikinfrastruktur,5.1.1.2 X.509-Zertifikate für nicht qualifizierte Signaturen der eGK,HBA oder SMC-B5.1.1.6 X.509 Zertifikate für Signaturen durch Fachdienste6.1.2 XML-Signaturen für nicht qualifizierte Signaturen6.1.4 Webservice Security Standard (WSS)6.1.6 XML-Verschlüsselung – Hybrid[gemSpec_OID] gematik: Einführung der Gesundheitskarte -Spezifikation: Festlegung von OIDs[gemSpec_Ticket] gematik: Einführung der Gesundheitskarte -Spezifikation Ticketservice[gemSpec_VersNr] gematik: Einführung der Gesundheitskarte -Spezifikation von Versionsnummern in Schnittstellendefinitionenund Softwarekomponenten[gemSysSLM] gematik: Einführung der Gesundheitskarte –Spezifikation System und Service Level Monitoring,[gemX.509_eGK] gematik: Einführung der Gesundheitskarte -Festlegungen zu den X.509-Zertifikaten der Versicherten[gemVerw_Zert_TI] gematik: Einführung der Gesundheitskarte -Verwendung von Zertifikaten in der TIWeitere Referenzen[Quelle][Basic Security Profile][WS-I-BSP 1.0]Herausgeber (Erscheinungsdatum): TitelWeb Services Interoperability Organization (2006):Basic Security Profile Version 1.0Stand 2007-03-30http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html[RFC2119] RFC 2119 (März 1997):Key words for use in RFCs to Indicate Requirement LevelsS. Bradner, http://www.ietf.org/rfc/rfc2119.txt (zuletzt geprüft am14.12.2006)[RFC2253] RFC 2253 (December 1997):gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 114 von 115Version: 1.6.0 © gematik Stand: 27.06.2008

SpezifikationTelematikTransport-Details[Quelle][RVO2006]Herausgeber (Erscheinungsdatum): TitelLightweight Directory Access Protocol (v3): UTF-8 String Representationof Distinguished Nameshttp://www.ietf.org/rfc/rfc2253.txt (zuletzt geprüft am 24.04.2007)Bundesgesetzblatt I (2006) vom 10.10.2006, Seite 2199 ff.: Verordnungüber Testmaßnahmen für die Einführung der elektronischenGesundheitskarte in der Fassung der Bekanntmachung vom 5.Oktober 2006[SOAP 1.1] W3C Note (8.5.2000):Simple Object Access Protocol (SOAP) 1.1 ,http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ (zuletzt geprüftam 14.12.2006)[WSS1.0] OASIS Open (2004): Web Services Security v1.0http://www.oasis-open.org/specs/index.php#wssv1.0 (zuletzt geprüftam 14.12.2006)[WSPL1.1][WSP1.1]OASIS (July 2005): Web Services Security Policy Language (WS-SecurityPolicy), Version 1.1http://specs.xmlsoap.org/ws/2005/07/securitypolicy/OASIS (March 2006): Web Services Policy Framework (WS-Policy)and Web Services Policy Attachment (WS-PolicyAttachment), Version1.2http://specs.xmlsoap.org/ws/2004/09/policy/[WSDL1.1] W3C Note (15.03.2001):Web Services Description Language (WSDL) 1.1http://www.w3.org/TR/2001/NOTE-wsdl-20010315 (zuletzt geprüftam 14.12.2006)[WS-I1.1]Web Services Interoperability Organization (2006): Basic ProfileVersion 1.1 (Final)[XMLEnc] Donald Eastlake, Joseph Reagle et. al. (2002):XML Encryption Syntax and Processinghttp://www.w3.org/TR/xmlenc-core (zuletzt geprüft am 14.12.2006)gematik_GA_Spezifikation_Telematik-Transport-Details.doc Seite 115 von 115Version: 1.6.0 © gematik Stand: 27.06.2008