Einführung der Gesundheitskarte
Spezifikation
Fachdienste EFA
Version | 0.8.7 |
Revision | 548770 |
Stand | 08.10.15 |
Status | freigegeben |
Klassifizierung | nicht öffentlich |
Referenzierung | gemSpec_FD_EFA |
Dokumentinformationen
Änderungen zur Vorversion
1. Kleinere Textkorrekturen und Klarstellungen im Rahmen der internen Kommentierung.
2. Inhaltliche Streichungen und Ergänzungen im Rahmen der internen Kommentierung
<<kurze Beschreibung der inhaltlichen Änderungen (max. ½ Seite)>>
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
0.1.0 |
04.07.14 |
Initiale Erstellung |
P75 |
|
0.2.0 |
22.07.14 |
Detaillierung |
P75 |
|
0.2.1 |
23.07.14 |
Detaillierung Funktionen, Schnittstellen, NFA und OP |
P75 |
|
0.3 |
29.07.14 |
Detaillierung, Straffung, Formulierung der Anforderungen |
P75 |
|
0.3.1 |
29.07.14 |
Kap 5 |
Korrekturen Ergänzungen weiterer Punkte, Umsetzung & Präzisierung, Löschung gelöster Punkt |
P75 |
K3.2 K 3.5 |
Schlüsselmaterial Korrektur IDP, Ergänzung PolicyProvider |
P75 |
||
0.3.3 |
01.08.14 |
Zeilennummern; Rechtschreibfehler; Policy Provider entfernt ; Listings in Abbildungen konvertiert; Offene Punkte umformuliert; Liste der Schlüssel in Excel verschoben, Detaillierung |
P75 |
|
0.4 |
01.08.14 |
K B |
Anforderungshaushalt initial etabliert |
P75 |
0.4.1 |
13.08.14 |
Kommentare eingearbeitet |
P75 |
|
0.4.2 |
14.08.14 |
Kommentare eingearbeitet, Arbeitsvermerke |
P75 |
|
0.4.3 |
15.08.14 |
Kommentare eingearbeitet, Arbeitsvermerke |
P75 |
|
0.5 |
16.09.14 |
Abschluss Kommentierung |
P75 |
|
0.5.1 |
23.09.14 |
Strukturelle Überarbeitung |
P75 |
|
0.6 |
12.11.14 |
Abschluss strukturelle Überarbeitung |
P75 |
|
0.6.1 |
13.11.14 |
Editorial |
P75 |
|
0.6.2 |
17.11.14 |
[MTOM1.1] eingearbeitet |
P75 |
|
0.6.3 |
20.11.14 |
Ergänzungen / Korrekturen / Klarstellungen |
P75 |
|
0.6.4 |
26.11.14 |
Ergänzungen / Korrekturen / Klarstellungen |
P75 |
|
0.6.5 |
02.12.14 |
Ergänzungen / Korrekturen / Klarstellungen PIX ergänzt |
P75 |
|
0.6.6 |
03.12.14 |
Korrekturen, Ergänzungen, MEX und DNS-SD überarbeitet |
P75 |
|
0.6.7 |
05.12.14 |
Korrekturen, Klarstellungen |
P75 |
|
0.6.8 |
11.12.14 |
Korrekturen, PIX Manager, Dokument Referenzen |
P75 |
|
0.7 |
29.01.15 |
Klarstellungen |
P75 |
|
0.7.1 |
02.02.15 |
Kommentare IW Kap 1-3 Korrekturen Trennung / Deutsch / Englisch Klarstellung OfflineToken (RDT / ARIT ) Lesbarkeit Tabellen |
P75 |
|
0.7.2 |
02.02.15 |
Lesbarkeit Tabellen (Nutzung) Parameter analog zu EFA Spec Validierungsschritte zusammengefasst |
P75 |
|
0.7.3 |
09.02.15 |
Allgemeine Funktionen zusammengefasst Parameter strukturiert Lesbarkeit Nutzung POP& IDP überarbeitet |
P75 |
|
0.7.4 |
16.02.15 |
Interner Review: Klarstellungen, Ergänzungen und Korrekturen |
P75 |
|
0.7.5 |
20.02.05 |
Interner Review: Klarstellungen, Ergänzungen und Korrekturen |
P75 |
|
0.8.0 |
23.02.15 |
Anforderungshaushalt in contour importiert; DNS CERT hinzugefügt; Validierung von SecurityHeadern, SAML Assertions und Zertifikaten vervollständigt; HPD nicht länger optional. |
P75 |
|
0.8.2 |
10.03.15 |
Ergänzungen und Korrekturen zu: „IssueAccessToken“ und DNS-CERT. |
P75 |
|
0.8.3 |
19.03.15 |
AFO Haushalt ergänzt, Fehlermeldungen zusammengefasst (Schritt 1), ARIT entfernt. |
P75 |
|
0.8.4 |
22.04.15 |
AFo Haushalt ergänzt. RFC Notation für eFA2-A_2129, eFA2-A_2134, eFA2-A_2135, eFA2-A_2137, eFA2-A_2139, eFA2-A_2236 |
P75 |
|
0.8.5 |
02.06.15 |
Änderungen im Rahmen der internen Kommentierung |
P75 |
|
0.8.7 |
08.10.15 |
Änderungen im Rahmen der Kommentierung durch DKG |
P75 |
Inhaltsverzeichnis
1 Einordnung des Dokuments
1.1 Zielsetzung
Dieses Dokument enthält die Anforderungen an den Produkttyp Fachdienst EFA. Der Fachdienst ist verantwortlich für die Verarbeitung elektronischer Fallakten, zur Registrierung seiner Dienste gegenüber der TI-Plattform, sowie der Registrierung und Deregistrierung von EFA-Teilnehmern (TN).
Im Kontext der Migration in die TI werden EFA-Fachdienst Instanzen in der Provider Zone an das zentrale Netz der TI-Plattform angeschlossen und so für EFA Clients aus der Consumer Zone erreichbar. EFA-Fachdienste können Nutzeridentitätsbestätigungen nach den in der Systemlösung [gemSysL_EFA2.0] vorgegebenen Regeln prüfen und nach eigenem Ermessen akzeptieren.
Dieses Dokument beschreibt normativ die Schnittstellen, welche die FD EFA zur Realisierung der Kommunikationsbeziehungen mit EFA Clients des Leistungserbringers und der Telematik Infrastruktur anbieten müssen
1.2 Zielgruppe
Das Dokument richtet sich Personengruppen, die grundsätzlich an der Migration von EFA Fachanwendungsinstanzen in die TI interessiert sind, insbesondere an
- Hersteller und Entwickler der Fachdienste
- Anbieter und Betreiber von EFA Fachanwendungen
- Verantwortliche Test
1.3 Geltungsbereich
Dieses Dokument enthält normative Anforderungen und Festlegungen, die von Herstellern und Betreibern von Komponenten und Diensten im Rahmen der Projekte der Neuausrichtung zur Einführung der elektronischen Gesundheitskarte und der Telematik Infrastruktur des Deutschen Gesundheitswesens zu beachten sind.
Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
1.4 Arbeitsgrundlagen
Grundlagen für die Ausführung dieses Dokumentes sind
- das systemspezifische Konzept EFA2.0 [gemSysL_EFA]
- EFA v2.0 Spezifikation vom 2013-11-18 [efa2spec]
- Gesamtarchitektur der TI [gemÜK_Arch_TI]
- das Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
- die Netzwerk Spezifikation der TI-Plattform [gemSpec_Net]
- die OASIS WS-Security Spezifikation [WSSE-1.0]
- die OASIS WS-Trust Spezifikation [WS-Trust]
- die HL7v3 Spezifikation [HL7v3]
- IHE Cookbook [IHE-Cookbook]
- IHE PIXv3 Profile [IHE ITI TF Vol.3]
- HPD (ITI-58, ITI-59) [IHE ITI TF Vol.2b]
1.5 Abgrenzungen des Dokuments
Spezifiziert werden in dem Dokument die vom Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.
Die Systemlösung der Fachanwendung EFA ist im systemspezifischen Konzept [gemSysL_EFA2.0] beschrieben. Dieses Konzept setzt die fachlichen Anforderungen des Lastenheftes auf Systemebene um, zerlegt die Fachanwendung EFA in die zugehörigen Produkttypen, darunter das EFA Fachmodul und den EFA-Fachdienst. Ferner definiert es die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemSysL_EFA2.0] vorausgesetzt.
Die Fachdienste EFA sind außerhalb der TI spezifiziert und verantwortet [efa2spec]. Diese Spezifikation beschreibt jene zusätzlichen Anforderungen an deren Schnittstellen, die für eine Migration in die TI-Plattform erforderlich sind.
Für das Verständnis dieser Spezifikation wird die Kenntnis von [efa2spec], [gemSysL_EFA2.0] und [gemSpec_FM_EFA] vorausgesetzt.
1.6 Methodik
1.6.1 Anforderungen
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
<Sofern die neue Nomenklatur der Afos verwendet wurde, zusätzlich:>
Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.
1.6.2 Diagramme
Die Darstellung der Spezifikationen von Komponenten erfolgt auf der Grundlage einer durchgängigen Use-Case-Modellierung als
- technische Use Cases (eingebundene Graphik sowie tabellarische Darstellung mit Vor- und Nachbedingungen gemäß Modellierungsleitfaden),
- Klassen-, Sequenz- und Aktivitäten- Diagramme sowie
- XML-Strukturen und Schnittstellenbeschreibungen.
1.6.3 Nomenklatur <<optional, nur bis einschl. Abstimmphase >>
Hinweise zur Nomenklatur:
- Schnittstellen-, Operations-, Parameter- und Dateinamen sowie Bezeichner für Objekte auf den verwendeten elektronischen Zertifikatsspeichern, den Namen der referenzierten Technischen Use Cases (TUCs) des Konnektors und Extensible-Markup-Language(XML)-Elemente oder -Attribute werden in diesem Dokument in nicht-proportionaler Schriftart gesetzt.
- Hexadezimale Zahlen und Oktett-Zeichenketten werden in Hochkommata eingeschlossen (z. B. ´2F 03´).
- Sofern im Text dieser Spezifikation auf die Ausgangsanforderungen verwiesen wird, erfolgt dies in eckigen Klammern, z.B. [KOMLE-A_2015]. Wird auf Eingangsanforderungen verwiesen, erfolgt dies in runden Klammern, z.B. (KOMLE-A_202).
1.6.4 Hinweis auf offene Punkte
Offene Punkte werden in blauer Schrift auf gelbem Hintergrund markiert und in 6 unten detailliert behandelt
Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.
2 Systemüberblick
Der EFA-Fachdienst ist in der Provider Zone an das zentrale Netz der TI-Plattform angeschlossen. Er realisiert alle Schnittstellen zur Verarbeitung elektronischer Fallakten durch einen EFA-Provider.
Der EFA-Fachdienst ist für eine bestimmte „EFA-Affinity-Domain“ (Community) konfiguriert. Leistungserbringer Institutionen werden als berechtigte Institution auf der Grundlage eines Vertrages mit einem EFA-Provider zur Nutzung der EFA-Dienste dieses EFA-Providers registriert. Durch die Patienteneinwilligung werden die Mitarbeiter einer berechtigten Leistungserbringer Institution im Kontext einer spezifischen Fallakte eines Patienten für die Rolle EFA-Teilnehmer autorisiert. Eine EFA-Fachdienst-Instanz versorgt eine „Community“ von EFA-Teilnehmern.
2.1 Systemkontext
Eine EFA-Instanz umfasst anwendungsspezifische und sicherheitsrelevante Funktionen. Die logischen Komponenten ResourceManager, DocumentRepository, DocumentRegistry und optional die HPD Services und der PIX Manager realisieren die Schnittstellen der Anwendungsdienste. Die logischen Komponenten IdentityProvider und PolicyProvider realisieren die Schnittstellen der Sicherheitsdienste. Ein optionales Provider Info Portal kann der einfachen Registrierung von Leistungserbringern als Vertragspartner eines EFA-Providers dienen.
Abbildung 1 Systemkontext der EFA-Fachdienste
2.1.1 EFA Business Services
Die logischen Komponenten ResourceManager, DocumentRepository und DocumentRegistry realisieren die Schnittstellen zu den fachlichen Kerndiensten der EFA-Instanz. Sie authentifizieren eingehende EFA-Nachrichten anhand der darin enthaltenen SAML-Nutzeridentitätsbestätigung. Sie prüfen die Autorisierung des Datenzugriffs anhand mitgelieferter SAML Subject Access Policies oder mithilfe interner Schnittstellen zum PolicyProvider. Im Sinne des Informationsmodells aus [XACML2.0] implementieren ihre Dienstinstanzen den PolicyDecisionPoint (PDP) und PolicyEnformcementPoint (PEP) für jeglichen fachlichen Zugriff auf die Daten einer elektronischen Fallakte.
2.1.2 EFA Security Services
Die logische Komponente PolicyProvider stellt dem EFA Fachmodul eine Schnittstelle zum Abruf von AccessPolicies in Form von „SAML Subject Access Policy Assertions“ bereit. Im sogenannten „PolicyPush“ Verfahren, das ein EFA-Provider optional anbieten kann, fügen EFA Clients ihren fachlichen Aufrufen solcherart bezogene Assertions zur Autorisierung des Datenzugriffes bei. Im sogenannten „PolicyPull“ Verfahren, dass von allen EFA-Providern unterstützt werden muss, beschafft sich die den fachlichen Aufruf bedienende EFA Service Schnittstelle die Policies selbst und wertet sie aus.
Technisch ist der PolicyProvider als ein STS WebService nach [WS-Trust] Spezifikation zu verstehen, welcher Policies in Form von SAML Subject Access Assertions erstellt und mittels SOAP Nachrichten kommuniziert. Im Sinne des Informationsmodells aus XACML2.0 implementiert die Dienstinstanz den PolicyInformationPoint (PIP) und PolicyAdministrationPoint (PAP) für die Sicherheitsarchitektur einer elektronischen Fallakte.
Die optionale Komponente Identity Provider liefert SAML Nutzeridentitätsbestätigungen für Nutzer, deren EFA Nutzerkonten in der EFA-Instanz beim Provider verwaltet werden. Technisch handelt es sich um einen STS WebService nach [WS-Trust], welcher SOAP Nachrichten verarbeitet.
2.1.3 EFA Supplemental Services
2.1.3.1 HPD Services
Anwendungsfälle im Kontext „Verwaltung von Fallakten“ zur Änderung des Kreises der Zugriffsberechtigten erfordern das Finden und Identifizieren von Teilnehmern. Aus diesem Anwendungsfall ist die Annahme eines beim EFA-Provider vorhandenen Verzeichnisdienstes motiviert, welcher relevante Daten seiner Teilnehmer bereitstellt.
Die logische Komponente HPD Services wird in der EFA 2.0 Spezifikation nicht als fachlicher Dienst geführt. Sie stellt dem EFA Fachmodul eine Schnittstelle auf den Verzeichnisdienst des EFA-Providers zur Verfügung.
Es ist nicht ausgeschlossen, dass eine HPD Instanz eines EFA-Providers mehrere Communities desselben Providers versorgt. Diese Spezifikation will sicherstellen, dass die HPD-Instanz in der Community adressierbar ist. Mit einer HPD Instanz über mehrere Communities muss die Zuordnung providerseitig verwaltet werden, welcher Teilnehmer in welchen Communities registriert bzw. adressierbar ist. Bei Abfragen eines HPD ist der Parameter „CommunityID“ bereits im Aufrufer-Kontext (Service-Endpoint URL) festgelegt. Somit könne auch Ansätze eines Multi-Community Providers unterstützt werden.
2.1.3.2 PIX Manager Services
Aus dem Informationsmodell des Anwendungskontextes „EFA Sicherheitskontext aufbauen“ ist die Identifikation der „Patienten ID beim Anbieter“ motiviert.
Die logische Komponente „Patient Identity Cross-Reference Manager“ (PIX Manager) realisiert die Schnittstellen zur Unterstützung der dienstanbieterseitigen Identifikation von Patienten anhand lokaler (teilnehmerseitig verwalteter) Identitätsmerkmale. Dabei kommt das „IHE PIXv3 profile“ zur Anwendung.
Mithilfe der Schnittstelle I_PIX_Manager kann die „patientID“ des Anbieters in der Community anhand einer zuvor beim Anbieter registrierten, lokalen Identifikation ermittelt werden.
Die optionale, logische Komponente PIXManager wird in der EFA 2.0 Spezifikation nicht als fachlicher Dienst geführt. Sie stellt dem EFA Fachmodul eine Schnittstelle auf die Patienten identifizierenden Dienste des EFA-Providers zur Verfügung.
Die Nutzung demographischer Daten zur Ermittlung der „provider_patientID“, zum Beispiel mit Hilfe eines „IHE PDQ profile“ wird nicht betrachtet.
2.1.3.3 EFA Info Portal
Eine optionale Komponente EFA Info Portal dient der einfachen Registrierung von Leistungserbringern in der TI als Teilnehmer einer EFA-Provider Domäne. Logisch kann es sich um ein Internetportal handeln, welches den Geschäftsprozess „Registrierung“ des Providers unterstützt.
Die Komponente ist kein unmittelbarer Bestandteil der EFA Fachanwendung, wird aber hier mit aufgeführt, da sie im Kontext der Lokalisierung der Fachdienste erwähnt ist.
2.2 Informationsmodell Provider und Teilnehmer
Ein EFA-Provider ist der organisatorische Anbieter von EFA Diensten gegenüber EFA-Teilnehmern, er verantwortet eine oder mehrere EFA Communities und stellt dazu je eine Instanz der EFA-Fachdienste mit den technischen Service Endpunkten bereit.
Abbildung 2 Informationsmodell zu EFA-Provider und EFA Community
EFA-Teilnehmer einer berechtigten Leistungserbringer Institution in einer EFA-Affinity-Domain (Community, EFA Versorgungsdomäne) sind mit deren EFA-Provider vertraglich verbunden. Eine EFA Community ist durch ihre CommunityID identifiziert. Ein EFA-Teilnehmer kann mehreren Communities angehören.
Die Institution, Provider und Community werden in der TI mithilfe von IDs vom Typ UUID identifiziert. Die Verwendung von UUIDs ist motiviert aus dem Bedarf nach „Identifier“ mit den Eigenschaften „fester Länge“ und „hinreichender Eindeutigkeit in konkreten Verwendungsdomänen. Derartige Identifier bieten generell eine sehr einfache Verarbeitung bei Einsatz von Hardware und zusammen mit weiteren limitierten Ressourcen wie z.B. Ablagespeicher auf SmartCards.
2.3 Weitere Informationen
2.3.1 Kryptographisches Schlüsselmaterial
Diese Spezifikation bezieht sich auf kryptographisches Schlüsselmaterial und X.509v3 Zertifikate, die im Abschnitt 4.9.9 eingeführt und beschrieben werden.
2.3.2 Lokalisierung der Fachdienste in der TI
Die Schnittstellen der EFA-Fachdienste in der Provider Zone sind als Web Services realisiert und verarbeiten SOAP 1.2 Nachrichten, ihre Service Endpunkte sind jeweils in einer WSDL Spezifikation technisch beschrieben.
Die Service Endpunkte der EFA-Fachdienste werden mithilfe von DNS-SD Datensätzen im Namensdienst der TI propagiert definiert. Dem Fachmodul EFA wird durch die Schnittstelle I_DNS_Service_Information ermöglicht, relevante Information zu den Service Endpunkten der registrierten EFA-Fachdienst Instanzen einfach zu ermitteln. Die Details sind in Kapitel 4.9.4.1 definiert.
2.3.3 EFA-Teilnehmerverzeichnisse
EFA-Teilnehmerverzeichnisse, wie in Abschnitt 2.1.3.1 oben erwähnt, sind durch die Anwendungsfälle „Finden“ und „Registrierung“ motiviert:
Das Finden von EFA-Teilnehmern zur Erweiterung des Kreises der Berechtigten an einer Fallakte soll unterstützt werden, insbesondere im Zusammenhang mit dem Aspekt der freien Arztwahl.
Die Registrierung eines Leistungserbringers bei einem EFA-Provider soll auf einfache Weise unterstützt werden.
2.3.3.1 Finden registrierter EFA-Teilnehmer in Verzeichnissen aus der TI
Diese Spezifikation geht von der Annahme aus, dass jeder EFA Provider im Zuge der Registrierung von EFA Teilnehmern Daten zu diesen Teilnehmern speichert, insbesondere zur Abbildung von Datenzugangs- und Datenzugriffsberechtigungen innerhalb der EFA Community.
Eine Suche auf diesem Datenbestand durch EFA Clients über die TI setzt dessen Verfügbarkeit in der TI voraus. Die Verfügbarkeit kann durch Bereitstellung einer Fachdienstschnittstelle (HPD Service beim Provider) oder durch Import und Pflege der Daten in den TI VZD erreicht werden. Eine einschränkende Anforderung hierzu ist nicht formuliert.
Ist der HPD Service des Providers nicht instanziiert, muss der EFA Client bedarfsweise im TI VZD nach EFA-Teilnehmern suchen. Der EFA-Provider muss in diesem Falle die relevanten Daten seiner Teilnehmer im TI VZD pflegen.
2.3.3.2 Einfache Registrierung weiterer EFA-Teilnehmer
Die Spezifikation macht keine Vorgaben zum organisatorischen Prozess der Registrierung von EFA-Teilnehmern beim Provider. Sie trifft die Annahme, dass vor der Konfiguration eines EFA-Teilnehmersystems in der TI eine hinreichende Vertragsbeziehung zwischen Leistungserbringerorganisation und EFA-Provider besteht.
Ein EFA-Teilnehmer in der TI vermag dann, mittels der Administrationsschnittstelle des EFA Fachmoduls, die Mitgliedschaft in einer oder mehreren bestimmten EFA Communities zu konfigurieren. Die EFA-Fachdienste prüfen ihrerseits die Autorisierung jeder Fallaktentransaktion in Bezug auf die Vertragsbeziehung und die diskreten Zugriffsrechte. Besteht eine Vertragsbeziehung, werden die fachlichen Transaktionen wie spezifiziert authentisiert, autorisiert und ausgeführt.
2.3.4 Ressource Referenz der Patienteneinwilligung (ConsentInfo) zur Fallakte – XDS-Binding
Mit dem Ziel, eine geeignete Repräsentation eines Resource Discovery Token auf der eGK speichern zu können, wurde das Fachmodul GDDATD entworfen. Im Kontext der Mehrwertanwendung EFA in der TI steht damit ein Mechanismus zur Verfügung, Anwendungstoken als Referenzen auf medizinische Resourcen mit unterschiedlicher Ausprägung zu definieren und mittels des Transportmediums eGK zu verteilen.
Im Kontext der Mehrwertanwendung EFA in der TI kann dieser Mechanismus für den Transport sogenannter Resource Discovery Token (RDT) einer spezifischen Fallakteninstanz eingesetzt werden. Die Erzeugung der RDT erfolgt dabei providerseitig und bildet eine TI-weit eindeutige Referenz auf das ConsentInfo Dokument dieser Fallakte ab. Die Assoziation der erforderlichen Identifier mit der Resource erfolgt auf Ebene der Dokument-Metadaten dieser Resource innerhalb der Komponente IHE XDS Registry. Geeignete Implementierungen eines EFA ResourceManager MÜSSEN deshalb die „ReferenceId Option“ gemäß [IHE ITI TF Vol.3] unterstützen.
Bei der Anlage einer Fallakte MUSS der providerseitige XDS Document Registry Actor die Metadaten des ConsentInfo Dokuments um diese extern verwendbare Referenz ergänzen, wenn die Unterstützung der eGK als Transportmedium für RDT gegeben sein soll.
GDD Anwendungstoken für EFA in der Ausprägung RDT sind zusammengesetzt aus einem fest vorgegebenen Identifikator der Anwendungsklassse, einem anwendungsspezifischen Flag, der CommunityID und der ResourceReferenceID. Die CommunityID wird in Form einer UUID bei der Inbetriebnahme einer EFA-Community in der TI festgelegt.
Die ResourceReferenceID wird vom Provider bei Anlegen der Resource gemäß [gemSpec_FM_GDDATD]#Kapitel 5.13.4 erzeugt und zu den Metadaten des ConsentInfo Dokuments unter Berücksichtigung von [IHE ITI TF Vol.3] mit dem Datentyp CXi enkodiert und beigefügt:
<rim:Slot name="urn:ihe:iti:xds:2013:referenceIdList ">
<rim:ValueList>
<rim:Value>
ecd446ee-e988-52d7-8561-4ef5f0acdb23^^^^urn:ihe:iti:xds:2013:accession
</rim:Value>
</rim:ValueList>
</rim:Slot>
Die Nutzung des RDT durch vorab autorisierte EFA-Teilnehmer
3 Funktionsmerkmale
3.1 Funktionsmerkmale der EFA Business Services
Das fachliche Verhalten der EFA Business Services wird in dieser Spezifikation nicht behandelt, Tabelle 1 verweist auf weiterführende Textstellen der EFA 2.0 Spezifikation.
Tabelle 1 Informative Textstellen der EFA Spezifikation zu den logischen Fachdiensten
Aspekt |
Textstelle |
---|---|
Interaktionsmuster |
[efa2spec] Seite 56 ff. |
Kommunikationsmuster |
[efa2spec] Seite 168 ff. |
Anwendungsdienste |
[efa2spec] Seite 188 ff. |
Sicherheitsdienste |
[efa2spec] Seite 218 ff. |
Gruppierung der Fachdienste |
[efa2spec] Seite 218 ff. |
Abbildung logischer Fachdienste auf IHE XDS/XDR Integrationsprofile |
[efa2spec] Seite 266 ff. |
Die in Tabelle 2 aufgeführten Funktionsmerkmale der EFA Business Services sind in [efa2spec] spezifiziert und in [gemSysL_EFA2.0] in Beziehung zur TI gesetzt.
Tabelle 2 Funktionsmerkmale der EFA Business Services
Kommunikationsmuster des Funktionsmerkmals |
Operation (logisch) |
Fachdienst Schnittstelle (logisch) |
Anlegen einer Fallakte |
createECR |
I_Resource_Manager |
Anlegen einer Partition zu einer bestehenden Fallakte |
createPartition |
|
Schließen einer Fallakte |
closeECR |
|
Auflisten von Partitionen |
listPartitions |
|
Registrierung einer neuen Einwilligung |
registerConsent |
|
Abrufen von Dokumenten |
retrieveData |
I_Document_Repository |
Einstellen von Dokumenten |
provideData |
|
registerData |
I_Document_Registry |
|
Auflisten von Dokumenten (einer Partition) |
listPartitionContent |
Zur Unterstützung des optionalen Einsatzes der eGK für die Speicherung von ResourceDiscoveryToken (RDT) MUSS ein EFA2.0 Provider in seiner XDS Registry die „ReferenceId Option“ gemäß [IHE ITI TF Vol.3] unterstützen. Bei den EFA-Transaktionen ‚createECR‘ (ITI-41) und ‚registerConsent‘ (ITI-41) ist die Resource Referenz des ConsentInfo Dokuments in den zugehörigen Metadaten wie im Kapitel 2.3.4 beschrieben zu ergänzen. Die Beschreibung zur Nutzung des RDT befindet sich in Kapitel 4.2.2.
3.2 Funktionsmerkmale der EFA Security Services
Die in Tabelle 3 aufgeführten Funktionsmerkmale der EFA Business Services sind in [efa2spec] spezifiziert und in [gemSysL_EFA2.0] in Beziehung zur TI gesetzt.
Tabelle 3 Funktionsmerkmale der EFA Security Services
Kommunikationsmuster des Funktionsmerkmals |
Operation (logisch) |
Fachdienst Schnittstelle (logisch) |
Abruf einer gültigen Subject Identity Assertion zum Aufbau des Sicherheitskontextes |
requestHPIdentityAssertion |
I_eCR_Identity_Provider |
Abruf einer gültigen Subject Access Policy Assertion zur Verwendung in Fachdienstaufrufen |
requestPolicy |
I_eCR_Policy_Provider |
Offline Token anfordern |
issueAccessToken |
3.2.1 Funktionsmerkmale des Identity Providers
Die optionale Komponente EFA Identity Provider stellt einem EFA Client auf Anfrage eine Nutzeridentitätsbestätigung in Form einer SAML 2.0 Identity Assertion aus. Mit dieser Identitätsbestätigung kann ein Nutzer, dessen Nutzerkonto beim EFA-Provider verwaltet wird, seine Aufrufe gegenüber EFA-Fachdienstschnittstellen autorisieren.
3.2.2 Funktionsmerkmale des Policy Providers
Die logische Komponente EFA Policy Provider stellt dem EFA Client auf Anfrage über das EFA Fachmodul eine Subject Access Policy Assertion zur Verwendung in Fachdienstaufrufen bereit. Mithilfe dieser Policy Assertion kann die Fachdienst Instanz eine Autorisierungsentscheidung für Fachdienstaufrufe von EFA Clients treffen und durchsetzen. Dazu nutzt der Client die Schnittstelle I_eCR_Policy_Provider, um eine auf seinen Sitzungskontext bezogene Subject Access Policy Assertion abzurufen. Diese Assertion fügt er anschließend jedem Aufruf desselben fachlichen Kontexts bei.
3.3 Funktionsmerkmale der EFA Supplemental Services
Die in Tabelle 4 aufgeführten Funktionsmerkmale der EFA Supplemental Services sind in [efa2spec] spezifiziert und in [gemSysL_EFA2.0] in Beziehung zur TI gesetzt.
Tabelle 4 Funktionsmerkmale der EFA Supplemental Services
Kommunikationsmuster des Funktionsmerkmals |
Operation (logisch) |
Fachdienst Schnittstelle (logisch) |
Finden von EFA TN einer bestimmten Community zur Vergabe von Berechtigungen auf Fallakten. |
provider Information Query (ITI-58) „search“ |
I_HPD_Services |
Pflegen der Attribute eines HPD Datensatzes zu einem bestimmten EFA-Teilnehmer |
Provider Information feed (ITI-59) „add“, „modify“, „delete“ |
|
Identifikation eines Patienten anhand eines registrierten Identifikationsmerkmals |
PIXv3 Query (ITI-45) |
I_PIX_Manager |
Identifikationsmerkmale eines Patienten registrieren |
Patient Identity Feed (ITI-44) |
3.3.1 Funktionen des EFA HPD Service
Die Funktionsmerkmale des in einer EFA Community angebotenen HPD Service ermöglichen die Verwaltung und Abfrage von Informationen zu Leistungserbringern, welche als Teilnehmer dieser EFA Community registriert sind.
Die Information kann vom EFA Fachmodul nach Leistungserbringern, die in der EFA-Provider Instanz als Teilnehmer registriert sind, durchsucht werden. Ein HPD Service verarbeitet Nachrichten vom Typ „Provider Information Query [ITI-58]“ und „Provider Information Feed [ITI-59]“.
3.3.2 Funktionen des PIX Manager Services
Die logische Komponente „Patient Identity Cross-Reference Manager“ (PIX Manager) realisiert die Schnittstelle zur providerseitigen Identifikation von Patienten anhand lokaler (teilnehmerseitig verwalteter) Identitätsmerkmale. Dabei kommt das „IHE PIXv3 Profile“ zur Anwendung.
Die Schnittstelle ermöglicht es, eine beim EFA Teilnehmer gepflegte, lokale „patientID“ in der EFA-Community beim PIX-Manager mit der dort gepflegten, anbieterseitigen „patientID“ zu registrieren. So wird die Ermittlung der „patientID“ des Anbieters anhand der lokalen „patientID“ unterstützt.
Auf eine Erweiterung des Mechanismus zur Ermittlung der providerseitig bekannten Patienten-ID nach IHE Profil PDQ wird derzeit verzichtet unter Berücksichtigung des Minimalitätsprinzips in puncto Datenschutz.
3.4 Audit Trail / Logging
Gemäß IHE Integrationsprofilen im IHE Cookbook ist für die grundlegende Aktenkommunikation in einer EFA-Instanz das Profil „ATNA Logging“ vorgegeben.
eFA2-A_2140 - Audit Trail von EFA-Fachdiensten
Die Service Endpunkte der EFA-Fachdienste einer EFA Community MÜSSEN die Protokollierung von Datenzugriffen aus der TI gemäß IHE ATNA umsetzen. Die Protokolleinträge sind nach mit dem Datenschützer abgestimmten Fristen, spätestens jedoch nach 183 Tagen, zu löschen.
[<=]3.5 Skalierbarkeit
eFA2-A_2160 - Skalierung im „Single-Peer Modell“
Die EFA-Fachdienste MÜSSEN im „EFA single-peer Modell“ mit der vorgesehen Anzahl von Teilnehmern skalieren
[<=]3.5.1 Verarbeitung großer Dokumente
Auf die TI migrierte EFA 2.0 Fachanwendungen müssen elektronische Dokumente verschiedenster Formate, wie zum Beispiel Bilder, Filme, Berichte, Schriftwechsel, Befunde, Grafiken, in „im Klinikalltag üblicher Größe“ handhaben können.
Tabelle 5 beschreibt Annahmen zu Anzahl und Umfang elektronischer Dokumente in den von EFA Clients genutzten Operationen der EFA Fachdienste.
Tabelle 5 Annahmen zu Größe und Anzahl elektronischer Dokumente in EFA Operationen
Logische Operation |
Datum |
Anzahl |
Volumen |
createECR |
consentDoc |
1 |
< 25MByte |
registerConsent |
consentDoc |
1 |
< 25MByte |
closeECR |
consentDoc |
1 |
< 25MByte |
createPartition |
verschiedene |
mindestens 1 |
beliebig ( > 25MByte) |
provideData |
verschiedene |
mindestens 1 |
beliebig ( > 25MByte) |
retrieveData |
verschiedene |
mindestens 1 |
beliebig ( > 25MByte) |
Für EFA Schnittstellen, welche Dokumente > 25 Mbyte handhaben müssen, fordert die Spezifikation EFA2.0 die Implementierung von „SOAP Message Transmission Optimization Mechanism“ Version 1.1 [MTOM1.1] und die Unterstützung datenstromorientierter Verarbeitung. Die Anforderungen bzgl. der Unterstützung von [XOP] und [MTOM1.1] ist motiviert durch die in der Spezifikation EFA2.0 verwendeten IHE-Transaktionen (ITI-41, ITI-42 und ITI-43) gemäß IHE ITI TF-2b.
eFA2-A_2192 - Skalierung der Verarbeitung von Dokumenten
Die EFA-Fachdienste SOLLEN alle Operationen, welche elektronische Dokumente von EFA Clients annehmen oder an EFA Clients ausliefern nach [XOP] und [MTOM1.1] implementieren. Die Annahme und Verarbeitung der Dokumente SOLL im „streaming mode“ erfolgen.
[<=]eFA2-A_2208 - Skalierung der Verarbeitung von großen Dokumenten
Die EFA-Fachdienste MÜSSEN alle Operationen, welche an Schnittstellen mit EFA Clients elektronische Dokumente mit Dokumentengrößen von mutmaßlich mehr als 25 MByte handhaben nach [MTOM1.1] implementieren.
Die betroffenen Schnittstellen MÜSSEN die Annahme und Verarbeitung von Dokumenten datenstromorientiert bis zur maximal möglichen Größe der Laufzeitumgebung des Fachdienstes sicher und robust handhaben.
In jedem Falle gilt vorstehendes für die logischen Operationen „createPartition“, „provideData“ und „retrieveData“.
[<=]
4 Schnittstellen
Das fachliche Verhalten der EFA-Fachdienst Schnittstellen ist in [efa2spec] definiert, es wird in dieser Spezifikation nicht behandelt. Siehe hierzu auch Tabelle 1 im Sinne einer Orientierungshilfe für die EFA 2.0 Spezifikation.
eFA2-A_2209 - Festlegung der Fachdienst Schnittstellen
Der Produkttyp „Fachdienst EFA“ MUSS die Schnittstellen gemäß Tabelle 6 implementieren („bereitgestellt“) und nutzen („benötigt“).
Tabelle 6 EFA-Fachdienst Schnittstellen
Schnittstelle |
bereitgestellt / benötigt |
obligatorisch / optional |
Bemerkung |
---|---|---|---|
I_Resource_Manager |
bereitgestellt |
obligatorisch |
Definition in [efa2spec] |
I_Document_Registry |
bereitgestellt |
obligatorisch |
Definition in [efa2spec] |
I_Document_Repository |
bereitgestellt |
obligatorisch |
Definition in [efa2spec] |
I_eCR_Policy_Provider |
bereitgestellt |
obligatorisch |
Definition in [efa2spec] |
I_HPD_Services |
bereitgestellt |
obligatorisch |
Definition in [gemSysL_EFA2.0] |
I_eCR_Identity_Provider |
bereitgestellt |
optional |
Definition in [gemSysL_EFA2.0] |
I_PIX_Manager |
bereitgestellt |
optional |
Definition in [gemSysL_EFA2.0] |
I_TLS |
bereitgestellt |
obligatorisch |
Definition in [gemSpec_Krypt] |
I_NTP_Time_Information |
benötigt |
obligatorisch |
Definition in [gemSpec_Net] |
I_OCSP_Status_Information |
benötigt |
obligatorisch |
Definition in [gemSpec_PKI] |
I_TSL_Download |
benötigt |
obligatorisch |
Definition in [gemSpec_TSL] |
I_Directory_Maintenance_FA |
benötigt |
obligatorisch |
Definition in [gemSpec_VZD] |
I_Monitoring_Update |
benötigt |
obligatorisch |
Definition durch den Anbieter der Störungsampel |
I_Monitoring_Read |
benötigt |
obligatorisch |
Definition durch den Anbieter der Störungsampel |
[<=]
4.1 Schnittstelle I_eCR_Identity_Provider
Diese optionale Schnittstelle stellt auf Anforderung anbieterseitige Nutzeridentitätsbestätigungen aus.
eFA2-A_2210 - Schnittstelle I_eCR_Identity_Provider
Eine EFA-Community KANN die Schnittstelle I_eCR_Identity_Provider gemäß Tabelle 11 in der Providerzone anbieten. Die Schnittstelle muss dabei einen STS gemäß [WS-TRUST] implementieren.
Tabelle 7 Schnittstelle I_eCR_Identity_Provider
Name |
I_eCR_Identity_Provider |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: requestHPIdentityAssertion Technisch: Issue |
Liefert eine HPIdentityAssertion für die angegebene Identität. |
|
WSDL |
[ws-trust-1.3.wsdl] |
|
Schema |
[ws-trust-1.3.xsd] |
[<=]
4.1.1 Operation requestHPIdentityAssertion
Diese Operation stellt zu einer bestimmten, durch den EFA Anbieter verwalteten Nutzeridentität eine Nutzeridentitätsbestätigung in Form einer „SAML 2.0 Assertion“ gemäß „SAML2.0 Profile for ECR Identity Assertion“ konform zur Spezifikation EFA2.0 aus.
4.1.1.1 Umsetzung
eFA2-A_2211 - Umsetzung I_eCR_Identity_Provider::requestHPIdentityAssertion
Bietet der EFA Provider in einer Community das Funktionsmerkmal IdentityProvider an, so MUSS die EFA-Fachdienst Schnittstelle I_eCR_Identity_Provider die logische Operation requestHPIdentityAssertion nach den Vorgaben Tabelle 8, Tabelle 9 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 8 Übersicht Operation requestHPIdentityAssertion
Name |
requestHPIdentityAssertion |
|
---|---|---|
Beschreibung |
Die Operation liefert eine SAML Identity Assertion zu den angegebenen Berechtigungsnachweisen/Anmeldeinformationen, z.B. Nutzername und Kennwort |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client, der zum Aufbau eines EFA Sitzungskontext eine Nutzeridentitätsbestätigung des EFA Anbieters beziehen möchte. |
|
Parameter |
||
Name |
Beschreibung |
|
credential |
Anmeldeinformationen zur eindeutigen Identifikation einer anbieterseitig verwalteten, prüfbaren Nutzeridentität in Form eines SAMLToken entsprechend „SAML 2.0 Profile for ECR Identity Assertion“. Weitere Token Profile gemäß WS-Security können ohne Nutzung der TI-PKI zusätzlich angeboten werden, wie z.B. Kerberos Token, Username Token, Kerberos Token |
|
endpointURL |
URL der EFA Community, auf deren Endpunkte die Gültigkeit der Assertion eingeschränkt sein soll. |
|
holder.Puk |
Public RSA Key des aufrufenden EFA Clients welcher mit der subjectConfirmation bestätigt werden soll. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
RSTR mit HPIdentityAssertion |
HPIdentityAssertion im Body des RSTR, entsprechend SAML 2.0 Profile for ECR Identity Assertion, wie in [efa2spec#244] ff. beschrieben |
|
Vorbedingung |
Der Anbieter unterstützt die Ausgabe von HPIdentityAssertions für die EFA Community Die übermittelte Nutzeridentität ist anbieterseitig prüfbar. Alle für eine HPIdentityAssertion erforderlichen Informationen zur „SubjectIdentity“ sind anbieterseitig bekannt oder dem Request beigefügt. Der Typ der übermittelten Nutzeridentität kann anbieterseitig verarbeitet werden, Mindestanforderung ist SAMLToken gemäß „SAML 2.0 Profile for ECR Identity Assertion“. Unterstützte Token Profile müssen in der zugehörigen WS-Security Policy des Service Endpunkt signalisiert werden. Optional sind weitere Token Profile möglich:
|
|
Nachbedingung |
Keine |
Tabelle 9 Ablauf Operation requestHPIdentityAssertion
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
RST annehmen |
|
2 |
Interne Verarbeitung |
1. Prüfe das „credential“ als behauptete Nutzeridentität in der Form UsernameToken, BinarySecurityToken (vom Typ X509v3 Token oder Kerberos Token) oder SAMLToken aus dem Security Header des RST Request 2. Ermittle lokale Nutzeridentität zu der behaupteten Nutzeridentität aus Schritt 1. 3. Ermittle fehlende Nutzeridentitätsmerkmale. 4. Erstelle / ergänze die HPIdentityAssertion entsprechend „SAML 2.0 Profile for ECR Identity Assertion“ mit der Einschränkung der subjectConfirmationMethod = „HoK“. Beispiel: [efa2spec#244] ff 5. Füge die Issuer Information in die HPIdentityAssertion ein: @Format=“urn:dns-name:instancename“ Value: IDP DnsName in der Provider Zone 6. Lese den öffentlichen Schlüssel des Aufrufers (holder-of-key) aus dem Security Header des Request (bei UserNameToken, BinarySecurityToken aus dem RST-UseKey Parameter) und übertrage ihn in die subjectConfirmation. 7. Signiere die HPIdentityAssertion mit dem Schlüssel C.FD.STS-SIG.Prk |
3 |
RSTR und Response vorbereiten |
1. Erstelle den RSTR und füge die HPIdentityAssertion in den Body des RSTR. 2. Erstelle Response und füge den RSTR ein |
4 |
Response senden |
Liefere die Response an den Aufrufer |
[<=]
4.1.1.2 Nutzung der Operation requestHPIdentityAssertion
Der Nutzer der Schnittstelle SOLL die Operation „requestHPIdentityAssertion“ gemäß Tabelle 10 verwenden.
Tabelle 10 Nutzung Operation requestHPIdentityAssertion
Name |
requestHPIdentityAssertion |
|
---|---|---|
Beschreibung |
Die Operation liefert eine SAML Identity Assertion zu den angegebenen Berechtigungsnachweisen, z.B. Nutzername und Kennwort |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client, der zum Aufbau eines EFA Sitzungskontext eine Nutzeridentitätsbestätigung des EFA Anbieters beziehen möchte. |
|
Parameter |
||
Name |
Beschreibung |
|
credential |
Merkmale zur eindeutigen Identifikation einer anbieterseitig verwalteten Nutzeridentität in Form eines UsernameToken, X509Token, KerberosToken oder SAMLToken entsprechend „SAML 2.0 Profile for ECR Identity Assertion“. |
|
endpointURL |
URL der EFA Community, auf deren Endpunkte die Gültigkeit der Assertion eingeschränkt sein soll. |
|
holder.Puk |
Public Key des aufrufenden EFA Clients zur Nutzung in der subjectConfirmation. |
|
Rückgabe |
||
Name |
Beschreibung |
|
token |
Security Token in der Ausprägung HPIdentityAssertion im Body des RSTR, entsprechend SAML 2.0 Profile for ECR Identity Assertion, wie in [efa2spec#244] ff. beschrieben |
|
Vorbedingung |
||
Ablauf |
1. Erstelle ein RST Element 1.1. Füge die endPointURL unter „AppliesTo“ ein 1.2. Füge den holder.Puk unter „UseKey“ ein. 2. Erstelle einen SOAP Request mit SecurityHeader und Action „http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue“ 3. Füge TimeStamp in SecurityHeader ein. 4. Füge das credential in den Security Header ein als UsernameToken, BinarySecurityToken oder SAMLToken.
4.a) bei BinarySecurityToken (X509-Token Profile, Kerberos Token Profile): signiere den Timestamp mit dem korrespondierenden X.509.Prk und füge die Signatur in den WS-Security-Header ein
4.b) bei SAMLToken: signiere den Timestamp mit dem korrespondierenden holder.prk und füge die Signatur in den WS-Security-Header ein
5. Verbindungsaufbau zur Gegenstelle6. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 7. SOAP Response entgegennehmen 8. RSTR Element vom Typ SAMLV2.0 aus dem Body nehmen 9. Entnehme das Token (Element SAML 2.0 Identity Assertion) aus dem RSTR und liefere es zurück. |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
4.1.2 WSDL Definition einer IdentityProvider Instanz
<!-- EFA IDP WSDL-->
<!--
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2002-2006. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-->
<wsdl:definitions
targetNamespace="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
xmlns:tns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" >
<!-- this is the WS-I BP-compliant way to import a schema -->
<wsdl:types>
<xs:schema>
<xs:import namespace=0
schemaLocation="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.xsd"/>
</xs:schema>
</wsdl:types>
<!-- WS-Trust defines the following GEDs -->
<wsdl:message name="RequestSecurityTokenMsg">
<wsdl:part name="request" element="wst:RequestSecurityToken" />
</wsdl:message>
<wsdl:message name="RequestSecurityTokenCollectionMsg">
<wsdl:part name="request" element="wst:RequestSecurityTokenCollection" />
</wsdl:message>
<wsdl:message name="RequestSecurityTokenResponseMsg">
<wsdl:part name="response" element="wst:RequestSecurityTokenResponse" />
</wsdl:message>
<wsdl:message name="RequestSecurityTokenResponseCollectionMsg">
<wsdl:part name="responseCollection"
element="wst:RequestSecurityTokenResponseCollection"/>
</wsdl:message>
<wsdl:portType name="SecurityTokenService">
<wsdl:operation name="RequestSecurityToken">
<wsdl:input message="tns:RequestSecurityTokenMsg"/>
<wsdl:output message="tns:RequestSecurityTokenResponseMsg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
4.1.3 Beispiele von Transaktionen mit einem EFA IdentityProvider
4.1.3.1 requestHPIdentityAssertion - RST (X509TokenProfile mit BinarySecurityToken)
<!-- EFA IDP Issue RST -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">
urn:uuid:0afde815-7059-438e-a42b-59c35c5212cd
</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">
https://10.11.12.12:443/SecurityTokenService/X509
</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/anonymous
</Address>
</ReplyTo>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/
2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-55846762-9fd6-4203-861d- 06537c382b60">
<wsu:Created>2015-01-27T16:33:23.016Z</wsu:Created>
<wsu:Expires>2015-01-27T16:38:23.016Z</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-soap-message- security-1.0#Base64Binary" ValueType="http://docs.oasis- open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="X509-94419760-2d63-4ea6-ab46-2b7587c0b603">
MIIEqjCCA5KgAwIBAgIDAdRsMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAkRFMRUwEwYDVQQKDAxnZW1hdGlrIEdtYkgxJDAiBgNVBAMMG2dlbWF0aWsgR21iSCBDQSBmw7xyIMOEcnp0ZTAeFw0xNDA0MDkwOTA2MTZaFw0xNzA0MDkwOTA2MTZaMIGLMQswCQYDVQQGEwJERTFEMEIGA1UEAww7RHIuIG1lZC4gSGVpbnJpY2ggRml0LCBGYWNoYXJ6dCBmw7xyIFBoeXNpa2FsaXNjaGUgVGhlcmFwaWUxDDAKBgNVBAQMA0ZpdDERMA8GA1UEKgwISGVpbnJpY2gxFTATBgNVBAUTDDEyMzQ1Njc4OTAxMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKIfNyqevj4+cqGJpdbmsjtlFKQquvaWcVm4QnKOkO1+GGkUPmXNwxqilFPFPPdf6rdoVXvcgI03vW7TynQvIMonWYvv9GPodfShkQPBhqwm0kGvIDJP/RSaiReNgqkmQADgG9mf7AGTnuGwojtQ9YtigAvv3B1BMvkcl+tbne/N9xgHRtCcY3FUx4PpCA0wEgteq+SgE7BKzx5oI5hRGppwgUTfVkw8pkMUhqLUGBW3UoBkyraz3qBJSOjHFzmTdFaKg0PuxtjoRi8assgN4KU/o7NI+o94yC3cU1hjAQnnioKt5H6D9jqjsA9BCBUFZw9kmpiYWpuTuOZ+LW6xj8cCAwEAAaOCAVUwggFRMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdDgQKBAhF9206u425vjBiBgNVHSAEWzBZMEwGByqCFABMBD4wQTA/BggrBgEFBQcCARYzaHR0cDovL3d3dy5lLWFyenRhdXN3ZWlzLmRlL3BvbGljaWVzL0VFX3BvbGljeS5odG1sMAkGByqCFABMBEswQQYFKyQIAwMEODA2MDQwMjAwMC4wDgwMw4RyenRpbi9Bcnp0MAkGByqCFABMBB4TETEtMjEyMzQ1Njdhc2RmZ2hiMBMGA1UdIwQMMAqACE96nT5LKIgdMEMGCCsGAQUFBwEBBDcwNTAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AuZ2VtYXRpay5kZTo4MDgwL0NNT0NTUC9PQ1NQMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAQEA09nrrjbKxYzdcxWE9wpEQpqiRDOxEmgwBgxO9ssx/a71F+C4k5lNExKwecpSEnl8F2BYRfEGZYHwGygYudk938rf/Qtl3X6T/pk677r3QPsuzATHJokr9a/GuAowrRQ3oWyDHEgrc2g0bsJTDpBaEWyHGcBbI5IOf1+ExN+FcrFcgXufdxTTSARm9RISn2IGfg0+mYWTSJPKB9NBVs7IIJ3Pctg0+MVKDlbxqwDGcZzC1QadWK2e8+Lp6ZEdEthTMGUPpYlVoJKolyn4nzIdqdIJ/SmtzX1qn+CdDLhr8a4vzvUze4IiNRP1IP+OI8VgCWD68RQ87k3oGrZOMSaKrg==
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="htp://www.w3.org/2000/09/xmldsig#" I="SIG-7bab80bf-8769-48c9-a0c1-af6361063e58">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/
xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml- exc-c14n#" PrefixList="soap"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#rsa-sha1"/>
<ds:Reference URI="#TS-55846762-9fd6-4203-861d- 06537c382b60">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/
2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.or
g/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/
2000/09/xmldsig#sha1"/>
<ds:DigestValue>pSotIWlOAi21YUhI
F6V0u2gxQY0=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo> <ds:SignatureValue>X5CRAkBT2ldRbqrNli5LBqH9hSYuHv+
iLQEE07zG3D4xd/2bp5OOg+qxpx73N5WI5ZcEkmxmlUU79AMOCxzYeqVsZ9ekp3+K5Fvz0x7Yr8IONNlPPT8I/SmLlEHtiYXoCPALFkxW4F3z3w+kQC6aylb++JDLoib1guKCYOnTkQ+yA0Vvg0wp0GRcZ9XGE8KbUSvkIQLCTtpUBsyPA9q/UXQE37UhyN6rGcNh9mYzAOHRA/Qw6YoyXvOMuflcr7xpjqjL2e+CLpOnRDBv4eQ2vdFVVHKkHRXMiQyrWcl35BnVGL37OZk7K5saQwjFkdKhKA0nn0e/52cs/2MmqetCVg==
</ds:SignatureValue>
<ds:KeyInfo Id="KI-6bb42220-daeb-4df0-b368- b0a348ce12d2">
<wsse:SecurityTokenReference wsu:Id="STR- 3af04eed-4c32-4ec9-aa24-386618533e55">
<wsse:Reference URI="#X509-94419760- 2d63-4ea6-ab46-2b7587c0b603" ValueType="http://docs.oasis-
open.org/wss/2004/01/oasis-200401
-wss-x509-token-profile- 1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body>
<wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws- sx/ws-trust/200512">
<wst:SecondaryParameters>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile- 1.1#SAMLV2.0</wst:TokenType>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>
<wst:KeySize>2048</wst:KeySize>
</wst:SecondaryParameters>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws- trust/200512/Issue</wst:RequestType>
<wsp:AppliesTo xmlns:wsp="http://www.w3.org/ns/ws-policy">
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/
addressing">
<wsa:Address>https://10.11.12.13:8443/efa2ti
</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:UseKey>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/
Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgygUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4wRE0lwA7SjrPaCgdlTiM=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</wst:UseKey>
<wst:Renewing/>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>
4.1.3.2 requestHPIdentityAssertion – RSTR (X509TokenProfile)
<!-- EFA IDP Issue RSTR -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:bc0ed99d-017a-4ab2-9595-8f8a44583e3e</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:0afde815-7059-438e-a42b-59c35c5212cd</RelatesTo>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-a668eb37-a0b5-4c61-81ed-6db5e3bd9ce1">
<wsu:Created>2015-01-27T16:33:19.236Z</wsu:Created>
<wsu:Expires>2015-01-27T16:38:19.236Z</wsu:Expires>
</wsu:Timestamp>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-80e38d77-6489-44ef-9e9b-355a6647acbe">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#TS-a668eb37-a0b5-4c61-81ed-6db5e3bd9ce1">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>QLRAuQCEBTuAmo8gyRb7GcAcnZY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>enTjIRhhV6j5o8HqHlvu+NkDCk8aXnJLjbU48yNLcahJSxlUM9vVEa82Bz5FUQYzfdngacfo3irzg0bdisO1RnFDd76sn186/GMTVvZhsd4dUZGKnJ5VPtEK96hfas6ZCOJ/bx5EvDWgSgsHUTHCYkYUDP6ycLwvpE02wPfctdwK+P689BzE6RZ2mTdIkwYDIp3+lw9s86snNOUkfVtbj14Y6PsaqBCU/8QWSYDosal7GNYSDvvPj3UNAMP85usvwqKkzbMzEQVKsZwPeoQ7hby56oWuyjX0btmzQLsF+s3ly456i1XiAYlFcLfp+ncaOLtUFSX46KwD8XV/ofxiIQ==</ds:SignatureValue>
<ds:KeyInfo Id="KI-8f3dc331-4b2a-41b3-9c69-282b1ca7d447">
<wsse:SecurityTokenReference wsu:Id="STR-d55ff445-7601-4275-999f-f18bcf24183e">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=C.GEM.SMCB-CA1 TEST-ONLY,OU=Institution des Gesundheitswesens-CA der Telematikinfrastruktur,O=gematik GmbH NOT-VALID,C=DE</ds:X509IssuerName>
<ds:X509SerialNumber>119868</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body>
<ns2:RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://www.w3.org/2005/08/addressing">
<ns2:RequestSecurityTokenResponse>
<ns2:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</ns2:TokenType>
<ns2:RequestedSecurityToken>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_b6de765a-a362-47c6-89c1-eed8c3eabbbb" IssueInstant="2015-01-27T16:33:19.179Z" Version="2.0" xsi:type="saml2:AssertionType">
<saml2:Issuer>EFA2Provider IDP</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_b6de765a-a362-47c6-89c1-eed8c3eabbbb">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>/eU+RJsKC/HbtW+9heJHhpJor74=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>dUSIdOXuJFOQfkQolOmunUNlyIc8rDt4zkPvJoFm13NYrvVopkHO/uMgfYTwOlau+zBHJ2mgE+wKKDJ6PiKNBJu3J7574ATRomxNSZRQMjbpcAgCaFyyZnFWz5Hfh1lKmcPIkTfkbXeYb7Wj/KixRUA2LBVHqIeXgii6xF9mNIBYxqS96bEKo4vOxp+XBg3d9pFVoPgbQE5W8KOjfYPCocZHlHkIO5CkAyym15re6P8xCVCIzN3GX2p5f/I6AS2Ftejo39M9P4MSdKERdEVj+UEGAziesDaWfJasqI3nkkEFXKu2cKVTJ08q3+f0zbKHRlnq3348KSUN/xtBOTRg3A==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFCDCCA/CgAwIBAgIDAdQ8MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJERTEfMB0GA1UECgwWZ2VtYXRpayBHbWJIIE5PVC1WQUxJRDFIMEYGA1UECww/SW5zdGl0dXRpb24gZGVzIEdlc3VuZGhlaXRzd2VzZW5zLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSEwHwYDVQQDDBhDLkdFTS5TTUNCLUNBMSBURVNULU9OTFkwHhcNMTQwMzI1MTQwMTM5WhcNMTcwMzI1MTQwMTM5WjCB8jELMAkGA1UEBhMCREUxGjAYBgNVBAoMEWdlbWF0aWsgTk9ULVZBTElEMT4wPAYDVQQDDDVQcmF4aXMgRHIuIG1lZC4gSm9zZWYgTmllZGVybWV5ZXIgQ2hpcnVyZ2llIFRFU1QtT05MWTEUMBIGA1UEBAwLTmllZGVybWV5ZXIxDjAMBgNVBCoMBUpvc2VmMSQwIgYDVQQFExsxMDAwMC1HT1JJeFNNQ0J4T1NJR3gwMDB4MDAxFzAVBgNVBAkMDlJpbmdlbGdhc3NlIDE5MQ8wDQYDVQQRDAYwMTIzNCcxETAPBgNVBAwMCERyLiBtZWQuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuuXCdKRC0YP3nLEFlIDtYX1kthI8lMoDkaEC3+I+dH7+mDcoRIOFyEDLl42B3UHOcjVN4LXrxQFltzYD4nKJYCnT8r/tL6kAwEusRQF4xSt9nwsHWwYvpqjrmHWLUgZi0jHGyP6mue8juEMJqRv1pGdhTUG81dEU0YwJn+Th7P5nF/yh+HV7qMmqxMRN2FIIqc2gMo7/heDTGyAxW7CTBsijqciC7fpesQUMxtghC9veWEl4S2nvlHxafvWOME96GNDaJkxjscK/3/t3+0Qhyi2Y4FVDXetDA4NHae6KRA5UFUTc89LSrrWNCKMFKj4TW+64jI90uuPUMrj6BOTYwwIDAQABo4H7MIH4MAwGA1UdEwEB/wQCMAAwEQYDVR0OBAoECE2vw2YZBe+fMCAGA1UdIAQZMBcwCgYIKoIUAEwEgSMwCQYHKoIUAEwETjBJBgUrJAgDAwRAMD4wPDA6MDgwNjAWDBRCZXRyaWVic3N0w6R0dGUgQXJ6dDAJBgcqghQATAQyExExLTIxMjM0NTY3YXNkZmdoYTATBgNVHSMEDDAKgAhIfuZUyHoLkDBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLmdlbWF0aWsuZGU6ODA4MC9DTU9DU1AvT0NTUDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggEBAAtsod6fz/s/VdnoMBMfNyvY2nPAzItkfHZSABIl8Dj0qxTnWNNC9U1moayLwKcXyH/GeA6Sho0uRGeHAf4Zu9fawTXkq7fpQwaHX/M9FlVizekOnYRtQji+IwzNG2DTENkc8ZDzmHbB8ldBoSaOIvaSBLPCvOX8PoH7uSYqoTaqqVLZoxH1d51ERywYL6ZCVi1hVlE7+W1h1uDcqrEceYCHvpHk2IoosWJdh9sG3jnLJ+Ysp9yVUkuzdQOlEhQOlwXNtoxFnYih3UGmG0LEUtTuxBdneivaIak3pQ3MS2aPrOZdJN7NH6jWPF6ej3UrLqZZR/20MZ3c1ZWZy4XlIBU=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="http://cxf.apache.org/sts">2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt f³r Physikalische Therapie,C=DE</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgygUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4wRE0lwA7SjrPaCgdlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2015-01-27T16:33:19.181Z" NotOnOrAfter="2015-01-27T17:03:19.181Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://10.11.105.2:8444/efa2ti/services/efa2ti</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2015-01-27T16:33:19.179Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="XSPA Subject" Name="urn:oasis:names:tc:xacml:1.0:subject:subject-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt f³r Physikalische Therapie,C=DE</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA role" Name="urn:oasis:names:tc:xacml:2.0:subject:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">physician</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA organisation" Name="urn:oasis:names:tc:xspa:1.0:subject:organization" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Organisation Id" Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">urn:oid</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Purpose of Use" Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">TREATMENT</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA locality" Name="urn:oasis:names:tc:xspa:1.0:environment:locality" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="Clinical Speciality" Name="urn:tobedefined" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Fachklinik für Herzchirurgie</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</ns2:RequestedSecurityToken>
<ns2:RequestedAttachedReference>
<ns4:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns4:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_b6de765a-a362-47c6-89c1-eed8c3eabbbb</ns4:KeyIdentifier>
</ns4:SecurityTokenReference>
</ns2:RequestedAttachedReference>
<ns2:RequestedUnattachedReference>
<ns4:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns4:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_b6de765a-a362-47c6-89c1-eed8c3eabbbb</ns4:KeyIdentifier>
</ns4:SecurityTokenReference>
</ns2:RequestedUnattachedReference>
<wsp:AppliesTo xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://10.11.105.2:8444/efa2ti/services/efa2ti</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<ns2:Lifetime>
<ns3:Created>2015-01-27T16:33:19.181Z</ns3:Created>
<ns3:Expires>2015-01-27T17:03:19.181Z</ns3:Expires>
</ns2:Lifetime>
<ns2:KeySize>2048</ns2:KeySize>
</ns2:RequestSecurityTokenResponse>
</ns2:RequestSecurityTokenResponseCollection>
</soap:Body>
</soap:Envelope>
4.1.3.3 HPIdentityAssertion
<!-- EFA HPIdentityAssertion -->
<saml2:Assertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="_b6de765a-a362-47c6-89c1-eed8c3eabbbb"
IssueInstant="2015-01-27T16:33:19.179Z"
Version="2.0" xsi:type="saml2:AssertionType">
<saml2:Issuer>gematikLocalAuthority</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_b6de765a-a362-47c6-89c1-eed8c3eabbbb">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec=http://www.w3.org/2001/10/xml-exc-c14n#
PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>/eU+RJsKC/HbtW+9heJHhpJor74=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
dUSIdOXuJFOQfkQolOmunUNlyIc8rDt4zkPvJoFm13NYrvVopkHO/uMgfYTwOlau+zBHJ2mgE+wKKDJ6PiKNBJu3J7574ATRomxNSZRQMjbpcAgCaFyyZnFWz5Hfh1lKmcPIkTfkbXeYb7Wj/KixRUA2LBVHqIeXgii6xF9mNIBYxqS96bEKo4vOxp+XBg3d9pFVoPgbQE5W8KOjfYPCocZHlHkIO5CkAyym15re6P8xCVCIzN3GX2p5f/I6AS2Ftejo39M9P4MSdKERdEVj+UEGAziesDaWfJasqI3nkkEFXKu2cKVTJ08q3+f0zbKHRlnq3348KSUN/xtBOTRg3A==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFCDCCA/CgAwIBAgIDAdQ8MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJERTEfMB0GA1UECgwWZ2VtYXRpayBHbWJIIE5PVC1WQUxJRDFIMEYGA1UECww/SW5zdGl0dXRpb24gZGVzIEdlc3VuZGhlaXRzd2VzZW5zLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSEwHwYDVQQDDBhDLkdFTS5TTUNCLUNBMSBURVNULU9OTFkwHhcNMTQwMzI1MTQwMTM5WhcNMTcwMzI1MTQwMTM5WjCB8jELMAkGA1UEBhMCREUxGjAYBgNVBAoMEWdlbWF0aWsgTk9ULVZBTElEMT4wPAYDVQQDDDVQcmF4aXMgRHIuIG1lZC4gSm9zZWYgTmllZGVybWV5ZXIgQ2hpcnVyZ2llIFRFU1QtT05MWTEUMBIGA1UEBAwLTmllZGVybWV5ZXIxDjAMBgNVBCoMBUpvc2VmMSQwIgYDVQQFExsxMDAwMC1HT1JJeFNNQ0J4T1NJR3gwMDB4MDAxFzAVBgNVBAkMDlJpbmdlbGdhc3NlIDE5MQ8wDQYDVQQRDAYwMTIzNCcxETAPBgNVBAwMCERyLiBtZWQuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuuXCdKRC0YP3nLEFlIDtYX1kthI8lMoDkaEC3+I+dH7+mDcoRIOFyEDLl42B3UHOcjVN4LXrxQFltzYD4nKJYCnT8r/tL6kAwEusRQF4xSt9nwsHWwYvpqjrmHWLUgZi0jHGyP6mue8juEMJqRv1pGdhTUG81dEU0YwJn+Th7P5nF/yh+HV7qMmqxMRN2FIIqc2gMo7/heDTGyAxW7CTBsijqciC7fpesQUMxtghC9veWEl4S2nvlHxafvWOME96GNDaJkxjscK/3/t3+0Qhyi2Y4FVDXetDA4NHae6KRA5UFUTc89LSrrWNCKMFKj4TW+64jI90uuPUMrj6BOTYwwIDAQABo4H7MIH4MAwGA1UdEwEB/wQCMAAwEQYDVR0OBAoECE2vw2YZBe+fMCAGA1UdIAQZMBcwCgYIKoIUAEwEgSMwCQYHKoIUAEwETjBJBgUrJAgDAwRAMD4wPDA6MDgwNjAWDBRCZXRyaWVic3N0w6R0dGUgQXJ6dDAJBgcqghQATAQyExExLTIxMjM0NTY3YXNkZmdoYTATBgNVHSMEDDAKgAhIfuZUyHoLkDBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLmdlbWF0aWsuZGU6ODA4MC9DTU9DU1AvT0NTUDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggEBAAtsod6fz/s/VdnoMBMfNyvY2nPAzItkfHZSABIl8Dj0qxTnWNNC9U1moayLwKcXyH/GeA6Sho0uRGeHAf4Zu9fawTXkq7fpQwaHX/M9FlVizekOnYRtQji+IwzNG2DTENkc8ZDzmHbB8ldBoSaOIvaSBLPCvOX8PoH7uSYqoTaqqVLZoxH1d51ERywYL6ZCVi1hVlE7+W1h1uDcqrEceYCHvpHk2IoosWJdh9sG3jnLJ+Ysp9yVUkuzdQOlEhQOlwXNtoxFnYih3UGmG0LEUtTuxBdneivaIak3pQ3MS2aPrOZdJN7NH6jWPF6ej3UrLqZZR/20MZ3c1ZWZy4XlIBU=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="http://cxf.apache.org/sts">
2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt f³r Physikalische Therapie,C=DE
</saml2:NameID>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData
xsi:type="saml2:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue> <ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgygUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4wRE0lwA7SjrPaCgdlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions
NotBefore="2015-01-27T16:33:19.181Z"
NotOnOrAfter="2015-01-27T17:03:19.181Z">
<saml2:AudienceRestriction>
<saml2:Audience>
https://10.11.105.2:8444/efa2ti/services/efa2ti
</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2015-01-27T16:33:19.179Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="XSPA Subject" Name="urn:oasis:names:tc:xacml:1.0:subject:subject-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt f³r Physikalische Therapie,C=DE</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA role" Name="urn:oasis:names:tc:xacml:2.0:subject:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">physician</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA organisation" Name="urn:oasis:names:tc:xspa:1.0:subject:organization" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Organisation Id" Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">urn:oid</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Purpose of Use" Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">TREATMENT</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA locality" Name="urn:oasis:names:tc:xspa:1.0:environment:locality" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="Clinical Speciality" Name="urn:tobedefined" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Fachklinik für Herzchirurgie</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
4.1.3.4 requestHPIdentityAssertion - RST (UsernameTokenProfile mit Username/Password)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9513ce1d-363b-43f3-b74b-54a27c922a62</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">https://10.11.105.10:9443/SecurityTokenService/Transport</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ReplyTo>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-abdc1e7c-5359-4d93-b5f8-91542803877a">
<wsu:Created>2015-02-13T13:12:52.932Z</wsu:Created>
<wsu:Expires>2015-02-13T13:17:52.932Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken wsu:Id="UsernameToken-5e646fc3-e031-4426-a145-7b47aafb90ea">
<wsse:Username>alice</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wst:SecondaryParameters>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>
<wst:KeySize>2048</wst:KeySize>
</wst:SecondaryParameters>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:UseKey>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgygUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4wRE0lwA7SjrPaCgdlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</wst:UseKey>
<wst:Renewing/>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>
4.1.3.5 requestHPIdentityAssertion - RSTR (UsernameTokenProfile mit Username/Password)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:062a3f64-89ec-4cb4-b45c-4e5079360599</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9513ce1d-363b-43f3-b74b-54a27c922a62</RelatesTo>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-46ced40b-651d-4328-a8a1-35e0edf908c4">
<wsu:Created>2015-02-13T13:12:56.265Z</wsu:Created>
<wsu:Expires>2015-02-13T13:17:56.265Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body>
<ns2:RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://www.w3.org/2005/08/addressing">
<ns2:RequestSecurityTokenResponse>
<ns2:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</ns2:TokenType>
<ns2:RequestedSecurityToken>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_008a3642-f39f-4143-9c4f-00266a76802c" IssueInstant="2015-02-13T13:12:55.928Z" Version="2.0" xsi:type="saml2:AssertionType">
<saml2:Issuer>GuarantorTokenService</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_008a3642-f39f-4143-9c4f-00266a76802c">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>oLkrgh04C6OaeTbh2vg4B9bH4Qc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>TzOkcuekpUocqRqe2n0vuPr1L/Kl4aV9Npi/Rwieyp9rSSub7r95QfISJmlS0jIqV9DDRr7ora9SjQQoPcj7L1ool0x7qsRNPYiNHomXnqAY7pGlYJG1Ynqxqh0ushgiwJ7l7fF2kuZgXge4NgU0hg9CMvW2W7uxsmRcTp73cZanuXoXbEbStSPursa5qL5NwD0+axpAkzPxZo99TEZORjXH6oXHzP0SErXwsppvXcVghFhgLloRBhsuLYPq2DYfFTTnaQIVIxNt1shz4RHm88SvDtDHOKKA3vPPL6XS1iDOUs+rKL2GhWB+9imeBUeuLc2pbKiqd4OcYp48zQYz+g==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFCDCCA/CgAwIBAgIDAdQ8MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJERTEfMB0GA1UECgwWZ2VtYXRpayBHbWJIIE5PVC1WQUxJRDFIMEYGA1UECww/SW5zdGl0dXRpb24gZGVzIEdlc3VuZGhlaXRzd2VzZW5zLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSEwHwYDVQQDDBhDLkdFTS5TTUNCLUNBMSBURVNULU9OTFkwHhcNMTQwMzI1MTQwMTM5WhcNMTcwMzI1MTQwMTM5WjCB8jELMAkGA1UEBhMCREUxGjAYBgNVBAoMEWdlbWF0aWsgTk9ULVZBTElEMT4wPAYDVQQDDDVQcmF4aXMgRHIuIG1lZC4gSm9zZWYgTmllZGVybWV5ZXIgQ2hpcnVyZ2llIFRFU1QtT05MWTEUMBIGA1UEBAwLTmllZGVybWV5ZXIxDjAMBgNVBCoMBUpvc2VmMSQwIgYDVQQFExsxMDAwMC1HT1JJeFNNQ0J4T1NJR3gwMDB4MDAxFzAVBgNVBAkMDlJpbmdlbGdhc3NlIDE5MQ8wDQYDVQQRDAYwMTIzNCcxETAPBgNVBAwMCERyLiBtZWQuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuuXCdKRC0YP3nLEFlIDtYX1kthI8lMoDkaEC3+I+dH7+mDcoRIOFyEDLl42B3UHOcjVN4LXrxQFltzYD4nKJYCnT8r/tL6kAwEusRQF4xSt9nwsHWwYvpqjrmHWLUgZi0jHGyP6mue8juEMJqRv1pGdhTUG81dEU0YwJn+Th7P5nF/yh+HV7qMmqxMRN2FIIqc2gMo7/heDTGyAxW7CTBsijqciC7fpesQUMxtghC9veWEl4S2nvlHxafvWOME96GNDaJkxjscK/3/t3+0Qhyi2Y4FVDXetDA4NHae6KRA5UFUTc89LSrrWNCKMFKj4TW+64jI90uuPUMrj6BOTYwwIDAQABo4H7MIH4MAwGA1UdEwEB/wQCMAAwEQYDVR0OBAoECE2vw2YZBe+fMCAGA1UdIAQZMBcwCgYIKoIUAEwEgSMwCQYHKoIUAEwETjBJBgUrJAgDAwRAMD4wPDA6MDgwNjAWDBRCZXRyaWVic3N0w6R0dGUgQXJ6dDAJBgcqghQATAQyExExLTIxMjM0NTY3YXNkZmdoYTATBgNVHSMEDDAKgAhIfuZUyHoLkDBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLmdlbWF0aWsuZGU6ODA4MC9DTU9DU1AvT0NTUDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggEBAAtsod6fz/s/VdnoMBMfNyvY2nPAzItkfHZSABIl8Dj0qxTnWNNC9U1moayLwKcXyH/GeA6Sho0uRGeHAf4Zu9fawTXkq7fpQwaHX/M9FlVizekOnYRtQji+IwzNG2DTENkc8ZDzmHbB8ldBoSaOIvaSBLPCvOX8PoH7uSYqoTaqqVLZoxH1d51ERywYL6ZCVi1hVlE7+W1h1uDcqrEceYCHvpHk2IoosWJdh9sG3jnLJ+Ysp9yVUkuzdQOlEhQOlwXNtoxFnYih3UGmG0LEUtTuxBdneivaIak3pQ3MS2aPrOZdJN7NH6jWPF6ej3UrLqZZR/20MZ3c1ZWZy4XlIBU=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="http://cxf.apache.org/sts">alice</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgygUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4wRE0lwA7SjrPaCgdlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2015-02-13T13:12:56.038Z" NotOnOrAfter="2015-02-13T13:42:56.038Z"/>
<saml2:AuthnStatement AuthnInstant="2015-02-13T13:12:55.988Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="XSPA Subject" Name="urn:oasis:names:tc:xacml:1.0:subject:subject-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">alice</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA role" Name="urn:oasis:names:tc:xacml:2.0:subject:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">physician</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA organisation" Name="urn:oasis:names:tc:xspa:1.0:subject:organization" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Organisation Id" Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">urn:oid</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA Purpose of Use" Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">TREATMENT</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="XSPA locality" Name="urn:oasis:names:tc:xspa:1.0:environment:locality" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">Kreiskrankenhaus Neustadt</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="Clinical Speciality" Name="urn:tobedefined" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xsi:type="xs:string">…</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</ns2:RequestedSecurityToken>
<ns2:RequestedAttachedReference>
<ns4:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns4:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_008a3642-f39f-4143-9c4f-00266a76802c</ns4:KeyIdentifier>
</ns4:SecurityTokenReference>
</ns2:RequestedAttachedReference>
<ns2:RequestedUnattachedReference>
<ns4:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns4:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_008a3642-f39f-4143-9c4f-00266a76802c</ns4:KeyIdentifier>
</ns4:SecurityTokenReference>
</ns2:RequestedUnattachedReference>
<ns2:Lifetime>
<ns3:Created>2015-02-13T13:12:56.038Z</ns3:Created>
<ns3:Expires>2015-02-13T13:42:56.038Z</ns3:Expires>
</ns2:Lifetime>
<ns2:KeySize>2048</ns2:KeySize>
</ns2:RequestSecurityTokenResponse>
</ns2:RequestSecurityTokenResponseCollection>
</soap:Body>
</soap:Envelope>
4.2 Schnittstelle I_eCR_Policy_Provider
Die Schnittstelle stellt die logische Operation requestPolicy für EFA Clients bereit, welche über das Fachmodul EFA eine Subject Access Policy Assertion zur Autorisierung ihrer fachlichen Aufrufe mittels „policy push“ anfragen.
eFA2-A_2212 - Schnittstelle I_eCR_Policy_Provider
Der EFA-Fachdienst MUSS die Schnittstelle I_eCR_Policy_Provider gemäß Tabelle 11 in der Providerzone anbieten. Die Schnittstelle muss dabei einen STS gemäß [WS-TRUST] implementieren.
Tabelle 11 Schnittstelle I_eCR_Policy_Provider
Name |
I_eCR_Policy_Provider |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: requestPolicy Technisch: Issue |
Stellt für einen bestimmten Sicherheitskontext (wer), eine bestimmte EFA Dienstinstanz (was) und bestimmte Patienten-Einwilligungen (wie) eine subjectAccessPolicy Assertion aus. Siehe auch “SAML 2.0 Profile for ECR Policy Assertions” in [efa2spec#253] |
|
Logisch: issueAccessToken Technisch: Issue |
Diese Operation liefert eine Objektreferenz auf Offline Token in Form einer UUID und der Bedeutung „RDT“ (Resource Discovery Token) zurück. |
|
WSDL |
ws-trust-1.3.wsdl |
|
Schema |
ws-trust-1.3.xsd |
[<=]
4.2.1 Operation requestPolicy
Nach Ablauf der Operation erhält der Anfrager zur übermittelten „Subject Identity“ eine „Subject Access Policy Assertion“ mit dessen Berechtigungen auf die Fachdienstschnittstellen.
4.2.1.1 Umsetzung
Diese Operation stellt für das Tupel {Nutzer, Fallaktenreferenz} ({„wer“, „was“}) eine „Subject Access Policy“ in Form einer SAML 2.0 Policy Assertion aus. Die Operation ist fachlich im Detail in [efa2spec#S217] beschrieben.
Hinweis: Die [efa2spec] sieht – anders als diese Spezifikation - die Verarbeitung eines optionalen Parameters „consentInfo“ vor. Der Parameter consentInfo kann von der Komponente PolicyProvider in der vorgesehenen Bauart „WS-TRUST STS“ ohne funktionale Erweiterungen technisch nicht verarbeitet werden. Dazu dient die Operation „registerConsent“ der Komponente ResourceManager.
eFA2-A_2213 - Umsetzung I_eCR_Policy_Provider::requestPolicy
Der EFA-Fachdienst MUSS an der Schnittstelle I_eCR_Policy_Provider die logische Operation requestPolicy nach den Vorgaben aus Tabelle 12, Tabelle 13 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 12 Übersicht Operation requestPolicy
Name |
requestPolicy |
|
---|---|---|
Beschreibung |
Diese Operation stellt für einen bestimmten Sicherheitskontext (wer), eine bestimmte elektronische Fallakte (was) und bestimmte Patienten- Einwilligungen (wie) eine subjectAccessPolicy Assertion aus. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. Motivation: ein EFA Client möchte seine fachlichen EFA Transaktionen anstelle von „PolicyPull“ mithilfe des „PolicyPush“ Verfahrens autorisieren lassen. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
ecrRef Datenobjekt gemäß EFA Policy Provider wie in [efa2spec#217] ff sowie http://wiki.hl7.de/index.php/cdaefa:EFA_WS_Trust_Policy_Provider beschrieben. Beispiel: <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005 /02/trust" xmlns:xacml- context="urn:oasis:names:tc:xacml:2.0:context:sche ma:os" xmlns:hl7="urn:hl7-org:v3"> <wst:RequestType>http://schemas.xmlsoap.org /ws/2005/02/trust/Issue</wst:RequestType> <wst:TokenType>http://docs.oasis-open.org /wss/oasis-wss-saml-token-profile- 1.1#SAMLV2.0</wst:TokenType> <xacml-context:Attribute AttributeId="urn:ihe:iti:xds- b:2007:patient-id" DataType="urn:hl7-org:v3#II"> <xacml-context:AttributeValue> <hl7:InstanceIdentifier extension="6578946" root="1.3.6.1.4.1.21367.2005.3.7"/> </xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:ihe:iti:xds- b:2007:folder:code" DataType="urn:hl7-org:v3#CV"> <xacml-context:AttributeValue> <hl7:CodedValue code="K70.0" codeSystem="1.2.276.0.76.5.311"/> </xacml-context:AttributeValue> </xacml-context:Attribute> </wst:RequestSecurityToken> |
|
Rückgabe |
||
Name |
Beschreibung |
|
token |
Security Token in der Ausprägung „XACML 2.0 Subject Access Policy“ im Body des RSTR, entsprechend „SAML 2.0 Profile for ECR Policy Assertion“. Referenz und Beispiel: EFA Policy Assertion SAML 2 Binding, wie in [efa2spec#253] ff. beschrieben |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 13 Ablauf Operation requestPolicy
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
1 |
Lese Parameter |
Lese die IdentityAssertion (context) aus dem aus dem Header und die ecrRef Information (patientID, folder.code) aus dem Body des RST. |
2 |
Ermittle Policy Set |
Ermittle die anzuwendenden Access Policies (Anwendungs- und Ressourcen Berechtigungen) anhand der Kriterien „HPIdentityAssertion“ und „ecrRef“. |
3 |
Erstelle PolicyAssertion |
1. Erstelle die „XACML 2.0 Subject Access Policy“ (SAML 2.0 Profile for ECR Policy Assertion) 2. Übertrage den subjectIdentifier aus der HPIdentityAssertion in die subjectAccessPolicy 3. Füge das Policy Set aus 2 in die Policy Assertion ein 4. Füge die Issuer Information in die Policy Assertion ein: @Format=“urn:dns-name:instancename“ Value: PoP DnsName in der Provider Zone |
4 |
Signiere PolicyAssertion |
Signiere die subjectAccessPolicy mit dem Schlüssel C.FD.STS-SIG.Prk |
5 |
RSTR vorbereiten |
Erstelle einen RSTR, füge die subjectAccessPolicy ein. Erstelle den Response und füge den RSTR in den Body ein. |
6 |
Response senden |
Liefere RSTR an den Aufrufer |
[<=]
4.2.1.2 Nutzung der Operation requestPolicy
Der Nutzer der Schnittstelle SOLL die Operation „requestPolicy“ gemäß Tabelle 14 verwenden.
Tabelle 14 Nutzung Operation requestPolicy
Name |
requestPolicy |
|
---|---|---|
Beschreibung |
Diese Operation stellt für einen bestimmten Sicherheitskontext (wer), eine bestimmte elektronische Fallakte (was) und bestimmte Patienten-Einwilligungen (wie) eine subjectAccessPolicy Assertion aus. |
|
Auslöser |
Ein EFA Client möchte seine fachlichen EFA Transaktionen anstelle von „PolicyPull“ mithilfe des „PolicyPush“ Verfahrens autorisieren. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
Sicherheitskontext (HPIdentityAssertion) |
|
ecrRef |
ecrRef Datenobjekt gemäß EFA Policy Provider wie in [efa2spec#217] ff sowie http://wiki.hl7.de/index.php/cdaefa:EFA_WS_Trust_Policy_Provider beschrieben. Beispiel: <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005 /02/trust" xmlns:xacml- context="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:hl7="urn:hl7-org:v3"> <wst:RequestType>http://schemas.xmlsoap.org/ws/2005 /02/trust/Issue</wst:RequestType> <wst:TokenType>http://docs.oasis-open.org/wss/oasis- wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType> <xacml-context:Attribute AttributeId="urn:ihe:iti:xds-b:2007:patient-id" DataType="urn:hl7-org:v3#II"> <xacml-context:AttributeValue> <hl7:InstanceIdentifier extension="6578946" root="1.3.6.1.4.1.21367.2005.3.7"/> </xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:ihe:iti:xds-b:2007:folder:code" DataType="urn:hl7-org:v3#CV"> <xacml-context:AttributeValue> <hl7:CodedValue code="K70.0" codeSystem="1.2.276.0.76.5.311"/> </xacml-context:AttributeValue> </xacml-context:Attribute> </wst:RequestSecurityToken> |
|
Rückgabe |
||
Name |
Beschreibung |
|
token |
Security Token in der Ausprägung „XACML 2.0 Subject Access Policy“ im Body des RSTR, entsprechend „SAML 2.0 Profile for ECR Policy Assertion“. Referenz und Beispiel: EFA Policy Assertion SAML2 Binding Example wie in [efa2spec#260] ff sowie http://wiki.hl7.de/index.php /cdaefa:EFA_Policy_Assertion_SAML2Binding#Example_Assertion beschrieben. |
|
Vorbedingung |
||
Ablauf |
1. Erstelle einen SOAP Request mit SecurityHeader und Action „http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue“ 2. Füge die HPIdentityAssertion aus „context“ in den Security Header ein 3. Füge TimeStamp in SecurityHeader ein und signiere ihn mit dem Schlüssel holder.Prk. Füge die Signatur über den Timestamp in den SecurityHeader ein. 4. Erstelle ein RST Element 4.1. Füge hinzu Element RequestType „http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue“ 4.2. Füge hinzu Element TokenType „http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0“ 4.3. Füge hinzu Element xacml-context mit ecrRef.patientID im IHE-XACML Binding 4.4. Füge hinzu Element xacml-context mit folder:code im IHE-XACML Binding 5. Verbindungsaufbau zur Gegenstelle 6. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 7. SOAP Response entgegennehmen 8. RSTR Element vom Typ SAMLV2.0 aus dem Body nehmen 9. Entnehme das Token (Element SAML 2.0 Subject Access Policy Assertion) aus dem RSTR und liefere es zurück. |
|
Nachbedingung |
4.2.2 Operation issueAccessToken
Diese Operation liefert eine Objektreferenz auf ein internes OfflineToken in Form einer UUID und der Bedeutung „RDT“ (Resource Discovery Token) zurück.
4.2.2.1 RDT - Resource Discovery Token
Umgangssprachlich formuliert bedeutet die Information eines ausgegebenen RDT: In einer EFA Community Instanz eines bestimmten Provider existiert eine Fallakte. Ein Teilnehmer dieser Community KANN diese Akte lokalisieren. Ein Teilnehmer dieser Community kann die Akte öffnen, wenn dem Kreis der Berechtigten angehört, wenn er zum Beispiel mit der Operation „registerConsent“ berechtigt wurde.
Die UUID der Objektreferenz kann zur patientenfreundlichen Handhabung auf ein Trägermedium aufgebracht und bei Leistungserbringern wieder eingelesen werden.
Das RDT entspricht technisch dem Attribut „ XDSDocumentEntry.referenceIdList (ITI TF-2a Revision 11 Kapitel 3.18.4.1.2.3.7.14 FindDocumentsByReferenceId)“ im Format „UUID“ desjenigen XDSDocumentEntry, welcher die Patienteneinwilligung (consentInfo) der Fallakte enthält. Die Operation zur Ausgabe (issue) des OfflineTokens liest die UUID(Aus einer UUID, welche mittels einer OID gebildet wurde kann die ursprüngliche OID nicht mehr ermittelt werden.) Typ 5 aus der XDSDocumentEntry.referenceIdList. Die UUID wird – als externe Repräsentation des RDT – gemeinsam mit der communityID (UUID2 Typ 5) an den Aufrufer zurückgegeben.
Eine Einlösung des RDT ist nicht erforderlich, da der bereits vorab berechtigte Teilnehmer Zugriff auf die Dokumente einer Fallakte hat. Zur Ermittlung der zugehörigen Fallakte setzt das TNS zunächst einen Aufruf der consentInfo XDSDocumentEntry Metadaten an das DocumentRegistry als RegistryStoredQuery ITI-18 ab (in der Ausprägung FindDocumentsByReferenceId).Dabei muss die providerseitig geführte PatientenId zuvor bekannt sein und in diesem Aufruf als Eingabeparameter verwendet werden. In der Antwort der DocumentRegistry müssen die XDSDocumentEntry uniqueId und die Document Repository repositoryUniqueId enthalten sein.
Unter Verwendung der XDSDocumentEntry uniqueId und der Document Repository repositoryUniqueId wird dann ein retrieveData (ITI-43) request an das Document Repository gesendet und die aktuell gültige Patienteneinwilligung (consentInfo) an das EFA-Teilnehmersystem zurückgeliefert. Mit den darin enthaltenen Informationen zur Zweck der Fallakte, kann das TNS nun alle weiteren EFA-Transaktionen ausführen. Berechtigte Personenkreise haben Zugriff auf die Inhalte einer identifizierbaren, offenen Fallakte.
4.2.2.2 Umsetzung
Die Operation zur Ausgabe des OfflineTokens (RDT) liest die UUID aus der XDSDocumentEntry.referenceIdList. Die UUID wird gemeinsam mit der communityID an den Aufrufer zurückgegeben.
eFA2-A_2220 - Umsetzung I_eCR_Policy_Provider::issueAccessToken
EFA-Fachdienst Schnittstelle I_eCR_Policy_Provider MUSS die logische Operation issueAccessToken nach den Vorgaben von Tabelle 15, Tabelle 16 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 15 Übersicht Operation issueAccessToken
Name |
issueAccessToken |
|
---|---|---|
Beschreibung |
Die Operation liefert eine Objektreferenz in Form einer UUID als OfflineToken zu einer elektronischen Fallakte. In der Ausprägung RDT verweist die UUID auf das consentInfo Document einer eFA, dessen Metadaten eine „urn:ihe:iti:xds:2013:accession number“ zugeordnet haben. |
|
Auslöser |
EFA Teilnehmer fordert einen Offline Token an. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten dessen Fallakte(n) gemeint sind. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation |
|
accessToken |
Objektreferenz auf das ConsentInfo Objekt in Form einer UUID |
|
communityID |
ID des Herausgebers des OfflineToken in Form einer UUID |
|
Vorbedingung |
|
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 16 Ablauf Operation issueAccessToken
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung RDT |
Ermittle XDS Document Entry.referenceIdList des consentInfo Document Entry zu der mit ecrRef identifizierten Fallakte. Breche die Operation bei auftretenden Fehlern mit Fehlercode FC0003 ab Falls noch nicht vorhanden, generiere UUID aus der uniqueID (OID) und speichere die Relation intern in den Metadaten. Die UUID MUSS innerhalb der EFA Community eindeutig sein. Liefere die UUID zurück Breche die Operation bei auftretenden Fehlern mit Fehlercode FC0004 ab |
5 |
Response vorbereiten |
Füge die UUID in die Response ein |
6 |
Response senden |
Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.2.2.3 Nutzung der Operation issueAccessToken
Der Nutzer der Schnittstelle SOLL die Operation „issueAccessToken“ gemäß Tabelle 17 verwenden.
Tabelle 17 Nutzung der Operation issueAccessToken
Name |
issueAccessToken |
|
---|---|---|
Beschreibung |
Diese Operation stellt ein AccessToken zur späteren Einlösung aus. Ein Token vom Typ „RDT“ dient der Lokalisierung einer Fallakte. |
|
Auslöser |
Ein EFA Client nutzt diese Operation zum Anfordern eines OfflineToken. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
Fallaktenreferenz (patientID, purpose) |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation |
|
accessToken |
Objektreferenz auf das Offline Token in Form einer UUID |
|
communityID |
ID des Herausgebers des Offline Token in Form einer UUID |
|
Vorbedingung |
||
Ablauf |
||
Nachbedingung |
Keine |
4.2.3 WSDL Definition eines PolicyProviders
<!-- EFA PP WSDL-->
Siehe WS-Trust STS
4.2.4 Beispiele von Transaktionen mit einem EFA PolicyProvider
4.2.4.1 requestPolicy - RST
<!-- EFA Policy RST -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">
urn:uuid:a4f2d8f8-9fa5-415b-8ed3-08cd5250eac0
</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">
https://pp.vivant.efa.telematik/SecurityTokenService/X509
</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ReplyTo>
<!-- EFA Policy RST : Security Header -->
<wsse:Security soap:mustUnderstand="1" xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:TimeStamp wsu:Id="TS-6C35EEB46F52DD432514044648226717">
<wsu:Created>2014-07-04T09:07:02.671Z</wsu:Created>
<wsu:Expires>2014-07-04T09:12:02.671Z</wsu:Expires>
</wsu:TimeStamp>
<!-- EFA Policy RST : SAML2 Assertion -->
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="_AF3CD17A2B64022F6114044648256971"
IssueInstant="2014-07-04T09:07:05.753Z" Version="2.0"
xsi:type="saml2:AssertionType">
<saml2:Issuer>23343536373839</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_AF3CD17A2B64022F6114044648256971">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>AGx9Hn3QLnCwM69TP5A0cRUOWp4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>h10s10t+...s+2ToJ8k=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIID5jCC...tYm1Dm/f</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<!-- EFA Policy RST : SAML2 Assertion / Subject -->
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="http://cxf.apache.org/sts"> 1.2.840.113549.1.9.1=#1611636c69656e7440636c69656e742e636f6d,CN=Zimmer1,OU=Zentrum,O=Beispiel -- Nicht fuer Produktionszwecke,L=Berlin,C=DE
</saml2:NameID>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData
xsi:type="saml2:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVa...dlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
</saml2:Subject>
<!-- EFA Policy RST : SAML2 Assertion / Conditions -->
<saml2:Conditions NotBefore="2014-07-04T09:07:06.092Z"
NotOnOrAfter="2014-07-04T09:37:06.092Z">
<saml2:AudienceRestriction>
<saml2:Audience>
https://pp.vivant.efa.telematik/SecurityTokenService/X509
</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="token-requestor"
NameFormat="23343536373839/Zimmer1">
<saml2:AttributeValue
xsi:type="xs:string">authenticated</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Id="SIG-6C35EEB46F52DD432514044648226719">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="soap"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#TS-6C35EEB46F52DD432514044648226717">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec=http://www.w3.org/2001/10/xml-exc-c14n#
PrefixList="wsse soap"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>lGgiBm1EhVywgMZfuqhKcrTqaV4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>KswB4U...f/HxYCVM=</ds:SignatureValue>
<ds:KeyInfo Id="KI-6C35EEB46F52DD432514044648226718">
<ns3:SecurityTokenReference xmlns:ns3=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd xmlns:wsse11=http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns3:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile1.1#SAMLID">
_AF3CD17A2B64022F6114044648256971
</ns3:KeyIdentifier>
</ns3:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<!-- EFA Policy RST : Body -->
<soap:Body>
<wst:RequestSecurityToken
xmlns:wst=http://schemas.xmlsoap.org/ws/2005/02/trust
xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:hl7="urn:hl7-org:v3">
<wst:RequestType>
http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
</wst:RequestType>
<wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
</wst:TokenType>
<xacml-context:Attribute
AttributeId="urn:ihe:iti:xds-b:2007:patient-id"
DataType="urn:hl7-org:v3#II">
<xacml-context:AttributeValue>
<hl7:InstanceIdentifier
extension="6578946"
root="1.3.6.1.4.1.21367.2005.3.7"/>
</xacml-context:AttributeValue>
</xacml-context:Attribute>
<xacml-context:Attribute
AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
DataType="urn:hl7-org:v3#CV">
<xacml-context:AttributeValue>
<hl7:CodedValue
code="K70.0"
codeSystem="1.2.276.0.76.5.311"/>
</xacml-context:AttributeValue>
</xacml-context:Attribute>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>
4.2.4.2 requestPolicy - RSTR
<!-- EFA Policy RSTR -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:cfcaeae0-fae7-44c4-9ade-1abfb6d2af40</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing"> urn:uuid:a4f2d8f8-9fa5-415b-8ed3-08cd5250eac0</RelatesTo>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-3d785e77-f86a-46b3-9726-50a4d5a277ca">
<wsu:Created>2015-03-18T14:51:07.157Z</wsu:Created>
<wsu:Expires>2015-03-18T14:56:07.157Z</wsu:Expires>
</wsu:Timestamp>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-7d7b5ae5-b1b9-47d9-9ccc-3c3481445dbb">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#TS-3d785e77-f86a-46b3-9726-50a4d5a277ca">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>h6FXxAjWpFZgPos3z1Ulk9y+Nrn1etrSOyyUoY9laWc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ARnZid0iEJJ8rSLSYG+BOXZO4DiTFlZIhHa+ef/zSu/h1UHgJJpb/n7COIyxhozMWVJaNuZPUnMInGK/onSX1gPl7AZyqmn+tBX1iQP+RrZnDqvMAH1LkpCd8v1aZg9tPpGB7TiMufj9fUkMtDh3esxZCQj2HbFo9vrBVMot/cAn8XsXgll3R4V0pBJn9aCAJptzXqZK+eTEqJ5vg8AEFH2lQLDy9uIDKGTW/FqD03f1WZnCwBLrShj8nfFyAb/9fxNRQb9WhKG/qhg3sGezqdJ/nKn0DxP+lBq0q2PiJi+5/ZaZuzyvT5guoeAu2vH2bF0lEiMpLkd1i/SG4VGc0Q==</ds:SignatureValue>
<ds:KeyInfo Id="KI-1696a524-7c8a-4e72-8a94-5032dccb7a06">
<wsse:SecurityTokenReference wsu:Id="STR-d3d2cae3-1b7c-4052-b1e2-a37f5a291164">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=C.GEM.FD-CA1 TEST-ONLY,OU=gematik ProviderZone-CA der Telematikinfrastruktur,O=gematik GmbH NOT-VALID,C=DE</ds:X509IssuerName>
<ds:X509SerialNumber>119868</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body>
<RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="http://www.w3.org/2005/08/addressing" xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200802">
<RequestSecurityTokenResponse>
<TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</TokenType>
<RequestedSecurityToken>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_2667e9e9-7612-44c9-bd80-4c1df6b2127b" IssueInstant="2015-03-18T14:51:07.102Z" Version="2.0" xsi:type="saml2:AssertionType">
<saml2:Issuer>http://ws.gematik.de:443/conn/efa2/LocalAuthority</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_2667e9e9-7612-44c9-bd80-4c1df6b2127b">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>/2nXTNAmTcleh3pUhLYY15zsW/Y=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>jpzdhfQVjRY1H0nNqIZo/mqrBJ4FuZ+SSe25SeNHs0/5X+rbhQdemaXt2zYGPpIRBIIhL2ni19Ng6nAlE0EiYHCwAn1GMVu8OwOS5lMZHDqgpocN8qY2QB3vCIeoSg2X7m56YomQTVzoMX5XG29rAqMivHenC+0S1K6u6GbOjUe0PhQfaT465fOda7JU2j9o8thoUFevDC17xoC8EFW9/2/4M4N/9g46t6Jv6hwhLcGUx2Pim/CQFNP/2zL0mwk+YOK8PP5qOubLeNuW3YGCeBtYcvN37vsTi4mWKWjZU5czCSF5N2YJzbgAEeD9OpGvjfrzlPEQQZH1Xw9OIT6teg==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFCDCCA/CgAwIBAgIDAdQ8MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJERTEfMB0GA1UE
CgwWZ2VtYXRpayBHbWJIIE5PVC1WQUxJRDFIMEYGA1UECww/SW5zdGl0dXRpb24gZGVzIEdlc3Vu
ZGhlaXRzd2VzZW5zLUNBIGRlciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMSEwHwYDVQQDDBhDLkdF
TS5TTUNCLUNBMSBURVNULU9OTFkwHhcNMTQwMzI1MTQwMTM5WhcNMTcwMzI1MTQwMTM5WjCB8jEL
MAkGA1UEBhMCREUxGjAYBgNVBAoMEWdlbWF0aWsgTk9ULVZBTElEMT4wPAYDVQQDDDVQcmF4aXMg
RHIuIG1lZC4gSm9zZWYgTmllZGVybWV5ZXIgQ2hpcnVyZ2llIFRFU1QtT05MWTEUMBIGA1UEBAwL
TmllZGVybWV5ZXIxDjAMBgNVBCoMBUpvc2VmMSQwIgYDVQQFExsxMDAwMC1HT1JJeFNNQ0J4T1NJ
R3gwMDB4MDAxFzAVBgNVBAkMDlJpbmdlbGdhc3NlIDE5MQ8wDQYDVQQRDAYwMTIzNCcxETAPBgNV
BAwMCERyLiBtZWQuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuuXCdKRC0YP3nLEF
lIDtYX1kthI8lMoDkaEC3+I+dH7+mDcoRIOFyEDLl42B3UHOcjVN4LXrxQFltzYD4nKJYCnT8r/t
L6kAwEusRQF4xSt9nwsHWwYvpqjrmHWLUgZi0jHGyP6mue8juEMJqRv1pGdhTUG81dEU0YwJn+Th
7P5nF/yh+HV7qMmqxMRN2FIIqc2gMo7/heDTGyAxW7CTBsijqciC7fpesQUMxtghC9veWEl4S2nv
lHxafvWOME96GNDaJkxjscK/3/t3+0Qhyi2Y4FVDXetDA4NHae6KRA5UFUTc89LSrrWNCKMFKj4T
W+64jI90uuPUMrj6BOTYwwIDAQABo4H7MIH4MAwGA1UdEwEB/wQCMAAwEQYDVR0OBAoECE2vw2YZ
Be+fMCAGA1UdIAQZMBcwCgYIKoIUAEwEgSMwCQYHKoIUAEwETjBJBgUrJAgDAwRAMD4wPDA6MDgw
NjAWDBRCZXRyaWVic3N0w6R0dGUgQXJ6dDAJBgcqghQATAQyExExLTIxMjM0NTY3YXNkZmdoYTAT
BgNVHSMEDDAKgAhIfuZUyHoLkDBDBggrBgEFBQcBAQQ3MDUwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9v
Y3NwLmdlbWF0aWsuZGU6ODA4MC9DTU9DU1AvT0NTUDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcN
AQELBQADggEBAAtsod6fz/s/VdnoMBMfNyvY2nPAzItkfHZSABIl8Dj0qxTnWNNC9U1moayLwKcX
yH/GeA6Sho0uRGeHAf4Zu9fawTXkq7fpQwaHX/M9FlVizekOnYRtQji+IwzNG2DTENkc8ZDzmHbB
8ldBoSaOIvaSBLPCvOX8PoH7uSYqoTaqqVLZoxH1d51ERywYL6ZCVi1hVlE7+W1h1uDcqrEceYCH
vpHk2IoosWJdh9sG3jnLJ+Ysp9yVUkuzdQOlEhQOlwXNtoxFnYih3UGmG0LEUtTuxBdneivaIak3
pQ3MS2aPrOZdJN7NH6jWPF6ej3UrLqZZR/20MZ3c1ZWZy4XlIBU=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="http://cxf.apache.org/sts">2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt für Physikalische Therapie,C=DE</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>2rhTVaouAdvrvzwvZLQ5J/Nm4JREGHC+KOSUVIUFRIUytohJaM9Ub6P6snw4QT3NZcyFJ+GprPgy
gUko2TAoKKd123gl8yFT+/OK7gvBxeUK2LF1EH03O5c6mn12Vx/AZPPYEknANXxZnuk6b2MzNM4w
RE0lwA7SjrPaCgdlTiM=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2015-03-18T14:51:07.104Z" NotOnOrAfter="2015-03-18T15:21:07.104Z">
<saml2:AudienceRestriction>
<saml2:Audience>urn:uuid:5f894f75-60ac-4cea-82b8-f0c7766f5d75</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2015-03-18T14:51:07.102Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<xacml-saml:XACMLPolicyStatement>
<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
xmlns:hl7="urn:hl7-org:v3"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os access_control-xacml-2.0-policy-schema-os.xsd"
PolicySetId="2B789DEE-9CB6-11E4-97F9-246A95DB5880"
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">
<Target>
<Resources>
<Resource>
<!-- ECR Folder Code -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
<AttributeValue DataType="urn:hl7-org:v3#CV">
<hl7:CodedValue code="ECR"
codeSystem="IHE-D-Cookbook-FolderClassCode" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
DataType="urn:hl7-org:v3#CV" />
</ResourceMatch>
<!-- Purpose Folder Code -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
<AttributeValue DataType="urn:hl7-org:v3#CV">
<hl7:CodedValue code="K70.0" codeSystem="1.2.276.0.76.5.311" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
DataType="urn:hl7-org:v3#CV" />
</ResourceMatch>
<!-- Patient -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:II-equal">
<AttributeValue DataType="urn:hl7-org:v3#II">
<hl7:InstanceIdentifier extension="6578946"
root="1.3.6.1.4.1.21367.2005.3.7" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:patient-id"
DataType="urn:hl7-org:v3#II" />
</ResourceMatch>
</Resource>
</Resources>
</Target>
<Policy PolicyId="urn:ecr:2.0:xacml:policyid:1"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
<Target>
<Subjects>
<!-- An HC professional and its role -->
<Subject>
<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
>urn:oid:1.2.276.0.76.3.1.81.1.76.4</AttributeValue>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xspa:1.0:subject:organization-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
</SubjectMatch>
<SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"
>physician</AttributeValue>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<!-- Document.availabilityStatus -->
<Resource>
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:availability-status"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
</ResourceMatch>
</Resource>
</Resources>
<Environments>
<Environment>
<!-- Begin of grace period -->
<EnvironmentMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#dateTime"
>2014-12-24T22:00:00Z</AttributeValue>
<EnvironmentAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-dateTime"
DataType="http://www.w3.org/2001/XMLSchema#dateTime" />
</EnvironmentMatch>
</Environment>
</Environments>
</Target>
</Policy>
</PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml2:Assertion>
</RequestedSecurityToken>
<RequestedAttachedReference>
<ns3:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns3:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_2667e9e9-7612-44c9-bd80-4c1df6b2127b</ns3:KeyIdentifier>
</ns3:SecurityTokenReference>
</RequestedAttachedReference>
<RequestedUnattachedReference>
<ns3:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
<ns3:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_2667e9e9-7612-44c9-bd80-4c1df6b2127b</ns3:KeyIdentifier>
</ns3:SecurityTokenReference>
</RequestedUnattachedReference>
<wsp:AppliesTo xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>urn:uuid:5f894f75-60ac-4cea-82b8-f0c7766f5d75</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<Lifetime>
<ns2:Created>2015-03-18T14:51:07.104Z</ns2:Created>
<ns2:Expires>2015-03-18T15:21:07.104Z</ns2:Expires>
</Lifetime>
<KeySize>2048</KeySize>
</RequestSecurityTokenResponse>
</RequestSecurityTokenResponseCollection>
</soap:Body>
</soap:Envelope>
4.2.4.3 SubjectAccessPolicyAssertion
<!-- EFA SubjectAccessPolicyAssertion -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
xmlns:hl7="urn:hl7-org:v3"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os access_control-xacml-2.0-policy-schema-os.xsd"
PolicySetId="2B789DEE-9CB6-11E4-97F9-246A95DB5880"
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">
<Target>
<Resources>
<Resource>
<!-- ECR Folder Code -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
<AttributeValue DataType="urn:hl7-org:v3#CV">
<hl7:CodedValue code="ECR"
codeSystem="IHE-D-Cookbook-FolderClassCode" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
DataType="urn:hl7-org:v3#CV" />
</ResourceMatch>
<!-- Purpose Folder Code -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
<AttributeValue DataType="urn:hl7-org:v3#CV">
<hl7:CodedValue code="K70.0" codeSystem="1.2.276.0.76.5.311" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
DataType="urn:hl7-org:v3#CV" />
</ResourceMatch>
<!-- Patient -->
<ResourceMatch MatchId="urn:hl7-org:v3:function:II-equal">
<AttributeValue DataType="urn:hl7-org:v3#II">
<hl7:InstanceIdentifier extension="6578946"
root="1.3.6.1.4.1.21367.2005.3.7" />
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:patient-id"
DataType="urn:hl7-org:v3#II" />
</ResourceMatch>
</Resource>
</Resources>
</Target>
<Policy PolicyId="urn:ecr:2.0:xacml:policyid:1"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
<Target>
<Subjects>
<!-- An HC professional and its role -->
<Subject>
<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
>urn:oid:1.2.276.0.76.3.1.81.1.76.4</AttributeValue>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xspa:1.0:subject:organization-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
</SubjectMatch>
<SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"
>physician</AttributeValue>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<!-- Document.availabilityStatus -->
<Resource>
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:ihe:iti:xds-b:2007:availability-status"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
</ResourceMatch>
</Resource>
</Resources>
<Environments>
<Environment>
<!-- Begin of grace period -->
<EnvironmentMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#dateTime"
>2014-12-24T22:00:00Z</AttributeValue>
<EnvironmentAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-dateTime"
DataType="http://www.w3.org/2001/XMLSchema#dateTime" />
</EnvironmentMatch>
</Environment>
</Environments>
</Target>
</Policy>
</PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
4.3 Schnittstelle I_Resource_Manager
Folgend sind die logischen und technischen Operationen und Parameter der Schnittstelle aufgeführt.
eFA2-A_2214 - Schnittstelle I_Resource_Manager
Der EFA-Fachdienst MUSS die Schnittstelle I_Resource_Manager gemäß Tabelle 18 anbieten.
Tabelle 18 Schnittstelle I_Resource_Manager
Name |
I_eCR_Policy_Provider |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: createPartition Technisch: ITI-41 (Provide and Register Document Set) |
Siehe [efa2spec#266], EFA XDR/XDS Binding |
|
Logisch: registerConsent Technisch: ITI-41 (Provide and Register Document Set) |
Siehe [efa2spec#266], EFA XDR/XDS Binding |
|
Logisch: createECR Technisch: ITI-41 (Provide and Register Document Set) |
Siehe [efa2spec#266], EFA XDR/XDS Binding |
|
Logisch: closeECR Technisch: ITI-41 (Provide and Register Document Set) |
Siehe [efa2spec#266], EFA XDR/XDS Binding |
|
Logisch: listPartitions Technisch: ITI-18 (Registry Stored Query) |
Siehe [efa2spec#266], EFA XDR/XDS Binding |
|
WSDL |
||
Schema |
[<=]
4.3.1 Operation createPartition
Diese Operation erzeugt eine weitere Partition und verknüpft diese mit einer existierenden Fallakte. Die Operation ist fachlich im Detail in [efa2spec#266] und [efa2spec#278] beschrieben.
4.3.1.1 Umsetzung
eFA2-A_2215 - Umsetzung I_Resource_Manager::createPartition
Der EFA-Fachdienst MUSS an der Schnittstelle I_Resource_Manager die Operation createPartition nach den Vorgaben aus
Tabelle 19, Tabelle 20 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 19 Übersicht Operation createPartition
Name |
createPartition |
|
---|---|---|
Beschreibung |
Die Operation erzeugt eine weitere Partition zu der angegebenen Fallakte. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
partitionInfo |
partitionID (XDSFolder.uniqueID) Titel (XDSFolder.title) Behandlungszeitraum |
|
initialDocs[1..*] |
XDSDocument mindestens ein einzufügendes Dokument (Siehe auch ITI-TF-2b 3.41.6.1) |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
partitionID |
Optional : XDSFolder.uniqueID Eindeutige Identifikation der angelegten Partition |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 20 Ablauf Operation createPartition
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht ProvideAndRegisterDocumentSetRequest entgegen, berücksichtige XOP/MTOM. 2. Interne Verarbeitung der ITI-41 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RegistryResponse zurück, berücksichtige XOP/MTOM. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.3.1.2 Nutzung der Operation createPartition
Der Nutzer der Schnittstelle SOLL die Operation „createPartition“ gemäß Tabelle 21 verwenden.
Tabelle 21 Nutzung der Operation createPartition
Name |
createPartition |
|
---|---|---|
Beschreibung |
Die Operation erzeugt eine weitere Partition zu der angegebenen Fallakte. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
Context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
partitionInfo |
partitionID (XDSFolder.uniqueID) Titel (XDSFolder.title) Behandlunszeitraum () |
|
initialDocs[1..*] |
XDSDocument mindestens ein einzufügendes Dokument (Siehe auch ITI-TF-2b 3.41.6.1) |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
partitionID |
Optional : XDSFolder.uniqueID Eindeutige Identifikation der angelegten Partition |
|
Vorbedingung |
Die Gegenstelle ist unter der angegebenen Adresse und Port erreichbar. Die HPIdentityAssertion ist gültig, ihre SubjectIdentity hat Berechtigungen auf die Fallakte Die Fallakte ist mit ecrRef(patientID, codeList) in der Community identifiziert |
|
Ablauf |
1. Erstelle Nachricht ProvideAndRegisterDocumentSetRequest 2. Füge Information ecrRef (XDS Folder Attributes PatientID, codeList) ein 3. Füge partitionInfo ein 4. Füge initiale Dokumente ein und kodiere sie gemäß [MTOM1.1] 5. SOAP Request erstellen und die ProvideAndRegisterDocumentSetRequest Nachricht in den Body einfügen. 6. Verbindungsaufbau zur Gegenstelle 7. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 8. SOAP Response entgegennehmen 9. RegistryResponse Element aus dem Body entnehmen, partitionID und folderID auslesen und zurückliefern. |
|
Nachbedingung |
Keine |
4.3.2 Operation registerConsent
Diese Operation registriert eine neue Patienteneinwilligung zu einer existierenden Fallakte. Die Operation ist fachlich im Detail in [efa2spec#197] und [efa2spec#278] beschrieben.
4.3.2.1 Umsetzung
eFA2-A_2216 - Umsetzung I_Resource_Manager::registerConsent
Der EFA-Fachdienst MUSS an der Schnittstelle I_Resource_Manager die Operation registerConsent nach den Vorgaben aus Tabelle 22, Tabelle 23 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 22 Übersicht Operation registerConsent
Name |
registerConsent |
|
---|---|---|
Beschreibung |
Die Operation registriert eine neue Patienteneinwilligung zu der angegebenen Fallakte. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
consentInfo |
Strukturiertes Dokument gemäß „ITI-TF 3#5.1“ (XDS mit CDA Konformität) mit Angaben zur neuen Einwilligung. |
|
docRelationship |
Das neue Dokument MUSS über docRelationship (Wert "ersetzt") mit dem gültigen consentInfo-Dokument in der Fallakte assoziiert werden. |
|
Optional: consentDoc |
Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments. |
|
Optional: docRelationship |
Wenn consentDoc gegeben ist, dann MUSS consentDoc über docRelationship (Wert "ersetzt") mit dem gültigen consentDoc-Dokument in der Fallakte assoziiert werden. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
Vorbedingung |
Das übergebene consentInfo Dokument ist konsistent:
Es ist ein Gültigkeitsdatum benannt.
Die EFA Teilnehmer sind benannt.
Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen
|
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 23 Ablauf Operation registerConsent
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht ProvideAndRegisterDocumentSetRequest entgegen. 2. Interne Verarbeitung der ITI-41 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RegistryResponse zurück |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.3.2.2 Nutzung der Operation registerConsent
Der Nutzer der Schnittstelle SOLL die Operation „registerConsent“ gemäß Tabelle 24 verwenden.
Tabelle 24 Nutzung der Operation registerConsent
Name |
registerConsent |
|
---|---|---|
Beschreibung |
Die Operation registriert eine neue Patienteneinwilligung zu der angegebenen Fallakte. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
ecrRef (XDS Folder Attributes PatientID, codeList, title) |
|
consentInfo |
XDS Document mit Angaben zur neuen Einwilligung. |
|
docRelationShip |
Die consentInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen consentInfo-Dokument in der Fallakte assoziiert werden. |
|
Optional: consentDoc |
Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments. |
|
Opetional: docRelationShip |
Wenn consentDoc gegeben ist, dann MUSS consentDoc über docRelationship (Wert "ersetzt") mit dem gültigen consentDoc-Dokument in der Fallakte assoziiert werden. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
Vorbedingung |
Keine |
|
Ablauf |
1. Erstelle Nachricht ProvideAndRegisterDocumentSetRequest 2. Füge Information ecrRef (XDS Folder Attributes PatientID, codeList, title) ein 3. Füge consentInfo und docRelationship ein 4. Füge optionale consentDocs und deren docRelationships ein und kodiere sie gemäß [MTOM1.1] 5. SOAP Request erstellen und die ProvideAndRegisterDocumentSetRequest Nachricht in den Body einfügen. 6. Verbindungsaufbau zur Gegenstelle 7. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 8. SOAP Response entgegennehmen 9. RegistryResponse Element aus dem Body entnehmen und Statusinformation auslesen und zurückliefern. |
|
Nachbedingung |
Keine |
4.3.3 Operation createECR
Diese Operation legt eine neue Fallakte an. Wird mit den gegebenen Attributen eine existierende Fallakte identifiziert so wird diese um eine Partition erweitert. Die Operation ist fachlich im Detail in [efa2spec#190] und [efa2spec#269] beschrieben.
4.3.3.1 Umsetzung
eFA2-A_2217 - Umsetzung I_Resource_Manager::createECR
Der EFA-Fachdienst MUSS an der Schnittstelle I_Resource_Manager die Operation createECR nach den Vorgaben aus Tabelle 25, Tabelle 26 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 25 Übersicht Operation createECR
Name |
createECR |
|
---|---|---|
Beschreibung |
Die Operation legt eine neue Fallakte an oder erweitert die angegebene Fallakte um eine Partition. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
ecrStatus |
XDSFolder.availabilityStatus = approved ecrStatus = „open“ |
|
consentInfo |
XDSDocument Strukturiertes Dokument gemäß „ITI-TF 3#5.1“ (XDS mit CDA Konformität, siehe auch BPPC) mit Angaben zur neuen Einwilligung, insbesondere Gültigkeit und Berechtigte für die Fallakte des Patienten. |
|
Optional: consentDoc |
Optional: XDSDocument Elektronische Einwilligungsdokumente des Patienten für die Anlage der Fallakte. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
Optional: partitionID |
Optional : XDSFolder.uniqueID Eindeutige Identifikation der angelegten Partition |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 26 Ablauf Operation createECR
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht ProvideAndRegisterDocumentSetRequest entgegen. 2. Interne Verarbeitung der ITI-41 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RegistryResponse zurück |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.3.3.2 Nutzung der Operation createECR
Der Nutzer der Schnittstelle SOLL die Operation „createECR“ gemäß Tabelle 27 verwenden.
Tabelle 27 Nutzung der Operation createECR
Name |
createECR |
|
---|---|---|
Beschreibung |
Die Operation erzeugt eine weitere Partition zu der angegebenen Fallakte. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
patientID |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. |
|
purpose |
XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
ecrStatus |
XDSFolder.availabilityStatus = approved |
|
consentInfo |
XDSDocument Einwilligung des Patienten für die Anlage der Fallakte. |
|
Optional: consentDoc |
XDSDocument BPPC Datenstruktur mit Definitionen der Gültigkeit und der Berechtigten für die Fallakte des Patienten. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Informationen zur Durchführung der Operation |
|
partitionID |
Eindeutige ID der neu angelegten Partition |
|
Vorbedingung |
Keine |
|
Ablauf |
1. Erstelle Nachricht ProvideAndRegisterDocumentSetRequest 2. Füge Information ecrRef (patientID, purpose codeList,consentInfo), ein 3. Füge initiale Dokumente ein und kodiere sie gemäß [MTOM1.1] 4. SOAP Request erstellen und die ProvideAndRegisterDocumentSetRequest Nachricht in den Body einfügen. 5. Verbindungsaufbau zur Gegenstelle 6. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 7. SOAP Response entgegennehmen 8. RegistryResponse Element aus dem Body entnehmen, statusInfo und partitionID auslesen und zurückliefern. |
|
Nachbedingung |
Keine |
4.3.4 Operation closeECR
Diese Operation schließt eine existierende Fallakte, die damit in den Status „grace“ übergeht. Die Operation ist fachlich im Detail in [efa2spec#194] und [efa2spec#282] beschrieben.
4.3.4.1 Umsetzung
eFA2-A_2218 - Umsetzung I_Resource_Manager::closeECR
Der EFA-Fachdienst MUSS an der Schnittstelle I_Resource_Manager die Operation closeECR nach den Vorgaben aus Tabelle 28, Tabelle 29 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 28 Übersicht Operation closeECR
Name |
closeECR |
|
---|---|---|
Beschreibung |
Schließt eine Fallakte. Sie wechselt in den Status "Gesperrt" („grace“). |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
consentInfo |
XDSDocument Strukturiertes Dokument gemäß „ITI-TF 3#5.1“ (XDS mit CDA Konformität, siehe auch BPPC) mit Angaben zur Schließung der Fallakte und Widerruf von Gültigkeit und Berechtigungen für die Fallakte des Patienten. |
|
Optional: consentDoc |
Optional: XDSDocument. Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist kann eine elektronische Version eines Einwilligungsdokumentes beigefügt sein. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 29 Ablauf Operation closeECR
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht ProvideAndRegisterDocumentSetRequest entgegen. 2. Interne Verarbeitung der ITI-41 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RegistryResponse zurück |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.3.4.2 Nutzung der Operation closeECR
Der Nutzer der Schnittstelle SOLL die Operation „closeECR“ gemäß Tabelle 30 verwenden.
Tabelle 30 Nutzung der Operation closeECR
Name |
closeECR |
|
---|---|---|
Beschreibung |
Schließt eine Fallakte. Sie wechselt in den Status "Gesperrt" („grace“). |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
consentInfo |
XDSDocument BPPC Datenstruktur mit Angaben zum Grund für die Schließung der Fallakte des Patienten |
|
Optional: consentDoc |
Optional: XDSDocument. Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist Elektronische Version eines Einwilligungsdokumentes |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Informationen zur Durchführung der Operation |
|
Vorbedingung |
Keine |
|
Ablauf |
1. Erstelle Nachricht ProvideAndRegisterDocumentSetRequest 2. Füge Information ecrRef und consentInfo ein 3. SOAP Request erstellen und die ProvideAndRegisterDocumentSetRequest Nachricht in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. RegistryResponse Element aus dem Body entnehmen, statusInfo auslesen und zurückliefern. |
|
Nachbedingung |
Keine |
4.3.5 Operation listPartitions
Die Operation listet Informationen zu allen Partitionen und deren übergeordnete Fallakten, zu denen der Aufrufer Zugangsberechtigt ist. Sie ist fachlich im Detail in [efa2spec#195] und [efa2spec#286] beschrieben.
4.3.5.1 Umsetzung
eFA2-A_2219 - Umsetzung I_Resource_Manager::listPartitions
Der EFA-Fachdienst MUSS an der Schnittstelle I_Resource_Manager die Operation listPartitions nach den Vorgaben aus Tabelle 31, Tabelle 32 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 31 Übersicht Operation listPartitions
Name |
listPartitions |
|
---|---|---|
Beschreibung |
Die Operation listet Informationen zu allen Partitionen und deren übergeordnete Fallakten, zu denen der Aufrufer zugangsberechtigt ist. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
ecrRef |
XDSFolder.patientID Die providerseitige ID des Patienten für den eine Fallakte angelegt wird. XDSFolder.codeList Liste mit Zweckcodes (codesystem@code) |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
partitionList |
Liste mit XDSFolder.uniqueID der gefundenen Partitionen |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 32 Ablauf Operation listPartitions
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht RegistryStoredQuery entgegen. 2. Interne Verarbeitung der ITI-18 Nachricht gemäß EFA2 Spezifikation. 2.1. Identifiziere alle Partitionen 2.1.1. die mit den Parametern patientID und purpose (codeList) verknüpft sind 2.1.2. für welche der Aufrufer zugriffsberechtigt ist 3. erstelle das der partitionList Objekt für diese Partitionen 4. Stelle PartitionList und statusInfo in die Nachricht RegistryStoredQueryResponse ein und liefere die Nachricht zurück. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.3.5.2 Nutzung der Operation listPartitions
Der Nutzer der Schnittstelle SOLL die Operation „listPartitions“ gemäß Tabelle 33 verwenden.
Tabelle 33 Nutzung Operation listPartitions
Name |
listPartitions |
||
---|---|---|---|
Beschreibung |
Die Operation listet Informationen zu allen Partitionen und deren übergeordnete Fallakten, zu denen der Aufrufer zugangsberechtigt ist. |
||
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
||
Parameter |
|||
Name |
Beschreibung |
||
context |
HPIdentityAssertion |
||
ecrRef |
ecrRef (XDS Folder Attributes PatientID, codeList, title) |
||
Rückgabe |
|||
Name |
Beschreibung |
||
statusInfo |
Information zur Durchführung der Operation statusInfo: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
||
partitionList |
Liste mit XDS Folder Attribute uniqueID der gefundenen Partitionen |
||
Vorbedingung |
|||
Ablauf |
1. Erstelle ein RegistryStoredQuery Element und füge die partitionID ein. 2. Erstelle den SOAP Request und füge das RegistryStoredQuery Element in den Body ein. 3. Füge die Autorisierungsinformation aus dem context in den SecurityHeader ein 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. RegistryStoredQueryResponse Element aus dem Body nehmen. 8. Entnehme docMetaData und docRelationShip Elemente liefere diese zurück. |
||
Nachbedingung |
Keine |
4.4 Schnittstelle I_Document_Registry
Folgend sind die logischen Operationen und Parameter der Schnittstelle aufgeführt.
eFA2-A_2222 - Schnittstelle I_Document_Registry
Der EFA-Fachdienst MUSS die Schnittstelle I_Document_Registry gemäß Tabelle 34 anbieten.
Tabelle 34 Schnittstelle I_Document_Registry
Name |
I_Document_ Registry |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: listPartitionContent Technisch: ITI-18 (Registry Stored Query) |
Siehe [efa2spec#203] und EFA XDR/XDS Binding [efa2spec#298] |
|
Logisch: registerData Technisch: nicht vorgesehen |
Siehe [efa2spec#202] und EFA XDR/XDS Binding [efa2spec#296]. Die Operation wird ausschließlich intern zwischen Fachdiensten genutzt. |
|
WSDL |
||
Schema |
[<=]
4.4.1 Operation listPartitionContent
Diese Operation ruft die Metadaten zu den an einer Partition einer Fallakte registrierten Dokumenten ab. Die Operation ist fachlich im Detail in [efa2spec#203] und [efa2spec#298] beschrieben.
4.4.1.1 Umsetzung
eFA2-A_2223 - Umsetzung I_Document_Registry::listPartitionContent
Der EFA-Fachdienst MUSS an der Schnittstelle I_Document_Registry die Operation listPartitionContent nach den Vorgaben aus Tabelle 35: Übersicht Operation listPartitionContent implementieren:
Tabelle 35 Übersicht Operation listPartitionContent
Name |
listPartitionContent |
|
---|---|---|
Beschreibung |
Die Operation gibt die Liste der Dokumente, die in einer Partition enthalten sind, zurück. Die Liste enthält die Dokument-Metadaten und Dokument-Beziehungen. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
partitionID |
XDSFolder.uniqueID Identifikationsmerkmal der Partition, deren Inhalte ausgelesen werden sollen |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
registryObjectList |
docMetadata[0..*] Metadaten der an der ausgewählten Partition registrierten Dokumente docRelationship[0..*] Beziehungen zwischen den Dokumenten der aufzulistenden Partition und Dokumenten dieser und anderer Partitionen. |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 36 Ablauf Operation listPartitionContent
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht RegistryStoredQuery entgegen. 2. Interne Verarbeitung der ITI-18 Nachricht gemäß EFA2 Spezifikation. 2.1. Identifiziere alle Dokumente 2.1.1. die mit partitionID verknüpft sind 2.1.2. für welche der Aufrufer zugriffsberechtigt ist 3. Identifiziere alle Dokumentbeziehungen der identifizierten Dokumente 4. Ermittle die Metadaten der Dokumente und Dokumentbeziehungen, stelle sie in die Nachricht RegistryStoredQueryResponse ein und liefere die Nachricht zurück. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.4.1.2 Nutzung der Operation listPartitionContent
Der Nutzer der Schnittstelle SOLL die Operation „listPartitionContent“ gemäß Tabelle 37 verwenden.
Tabelle 37 Nutzung Operation listPartitionContent
Name |
listPartitionContent |
|
---|---|---|
Beschreibung |
Die Operation gibt die Liste der Dokumente, die in einer Partition enthalten sind, zurück. Die Liste enthält die Dokument-Metadaten und Dokument-Beziehungen. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
partitionID |
Eindeutige Identifizierung der Partition, in die die Daten eingestellt werden sollen. |
|
Rückgabe |
||
Name |
Beschreibung |
|
docMetadata[1..*] |
Metadaten der an der ausgewählten Partition registrierten Dokumente |
|
docRelationShip[0..*] |
Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. |
|
Vorbedingung |
||
Ablauf |
1. Erstelle ein RegistryStoredQuery Element und füge die partitionID ein. 2. Erstelle den SOAP Request und füge das RegistryStoredQuery Element in den Body ein. 3. Füge die Autorisierungsinformation aus dem context in den SecurityHeader ein 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. RegistryStoredQueryResponse Element aus dem Body nehmen. 8. Entnehme docMetaData und docRelationShip Elemente liefere diese zurück. |
|
Nachbedingung |
Keine |
4.4.2 Operation registerData
Die Operation dient dem Registrieren von Daten an einer bestehenden Partition einer Fallakte. Es handelt sich um eine interne Funktion der Fachdienste auf Seiten des Anbieters, die ausschließlich vom DocumentRepository aufgerufen wird.
Die Operation steht für Aufrufe durch EFA Clients nicht zur Verfügung.
4.5 Schnittstelle I_Document_Repository
Folgend sind die logischen Operationen und Parameter der Schnittstelle aufgeführt.
eFA2-A_2224 - Schnittstelle I_Document_Repository
Der EFA-Fachdienst MUSS die Schnittstelle I_Document_Repository gemäß Tabelle 38 anbieten.
Tabelle 38 Schnittstelle I_Document_Repository
Name |
I_Document_Repository |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: provideData Technisch: ITI-41 (Provide and Register Document Set) |
Siehe [efa2spec#205] und EFA XDR/XDS Binding [efa2spec#303] |
|
Logisch: retrieveData Technisch: ITI-43 (Retrieve Document Set) |
Siehe [efa2spec#206] und EFA XDR/XDS Binding [efa2spec#307] |
|
WSDL |
||
Schema |
[<=]
4.5.1 Operation provideData
Diese Operation stellt Daten in eine bestehende Partition einer Fallakte ein. Die Operation ist fachlich im Detail in [efa2spec#205] und [efa2spec#303] beschrieben.
4.5.1.1 Umsetzung
eFA2-A_2225 - Umsetzung I_Document_Repository::provideData
Der EFA-Fachdienst MUSS an der Schnittstelle I_Document_Repository die Operation provideData nach den Vorgaben aus Tabelle 39, Tabelle 40 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 39 Übersicht Operation provideData
Name |
provideData |
|
---|---|---|
Beschreibung |
Diese Operation stellt Daten in eine Partition einer Fallakte ein. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
partitionID |
XDSFolder.uniqueID Eindeutige Identifizierung der Partition, in welche die Daten eingestellt werden sollen. |
|
docMetadata[1..*] |
docMetadata[1..*] Metadaten zu den bereits in der Partition abgelegten Dokumenten. |
|
docRelationShip[0..*] |
docRelationship[0..*] Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 40 Ablauf Operation provideData
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht ProvideAndRegisterDocumentSetRequest entgegen, berücksichtige XOP/MTOM. 2. Interne Verarbeitung der ITI-41 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RegistryResponse zurück, berücksichtige XOP/MTOM. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RegistryResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.5.1.2 Nutzung der Operation provideData
Der Nutzer der Schnittstelle SOLL die Operation „provideData“ gemäß Tabelle 41 verwenden.
Tabelle 41 Nutzung Operation provideData
Name |
provideData |
|
---|---|---|
Beschreibung |
Diese Operation stellt Daten in eine Partition einer Fallakte ein. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
partitionID |
Eindeutige Identifizierung der Partition, in die die Daten eingestellt werden sollen. |
|
Document[1..*] |
In die Partition einzustellende Dokumente mitsamt ihrer Metadaten. |
|
docRelationShip[0..*] |
Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation |
|
Vorbedingung |
Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide. |
|
Ablauf |
1. Erstelle ein ProvideAndRegisterDocumentSetRequest Element und füge die Dokumente und Metadaten sowie die Verknüpfungen der Dokumente ein. 2. Erstelle den SOAP Request und füge das ProvideAndRegisterDocumentSetRequest Element in den Body ein. 3. Füge die Autorisierungsinformation aus dem context in den SecurityHeader ein 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. RegistryResponse Element aus dem Body nehmen. 8. Entnehme statusInfo Element und liefere es zurück. |
|
Nachbedingung |
Keine |
4.5.2 Operation retrieveData
Diese Operation ruft Daten aus einer Fallakte ab. Die Operation ist fachlich im Detail in [efa2spec#206] und [efa2spec#307] beschrieben.
4.5.2.1 Umsetzung
eFA2-A_2226 - Umsetzung I_Document_Repository::retrieveData
Der EFA-Fachdienst MUSS an der Schnittstelle I_Document_Repository die Operation retrieveData nach den Vorgaben aus Tabelle 42, Tabelle 43 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 42 Übersicht Operation retrieveData
Name |
retrieveData |
|
---|---|---|
Beschreibung |
Die Operation ruft Daten aus einer Fallakte ab. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
documentID |
Eindeutige Identifizierung der abzurufenden Dokumente: repositoryUniqueId und documentUniqueId |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation status: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success |
|
docData[0..*] |
[BLOB] angeforderte Dokumente |
|
Vorbedingung |
Keine über [efa2spec] hinausgehenden |
|
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
Tabelle 43 Ablauf Operation retrieveData
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
Interne Verarbeitung |
1. Nehme Nachricht RetrieveDocumentSetRequest entgegen, berücksichtige XOP/MTOM. 2. Interne Verarbeitung der ITI-43 Nachricht gemäß EFA2 Spezifikation. 3. Liefere Nachricht RetrieveDocumentSetResponse zurück, berücksichtige XOP/MTOM. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die RetrieveDocumentSetResponse Nachricht in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.5.2.2 Nutzung der Operation retrieveData
Der Nutzer der Schnittstelle SOLL die Operation „retrieveData“ gemäß Tabelle 44 verwenden
Tabelle 44 Nutzung Operation retrieveData
Name |
retrieveData |
|
---|---|---|
Beschreibung |
Die Operation ruft Daten aus einer Fallakte ab. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
documentID |
Eindeutige Identifizierung der abzurufenden Dokumente |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Information zur Durchführung der Operation |
|
docData[0..n] |
angeforderte Dokumente |
|
Vorbedingung |
Keine |
|
Ablauf |
1. Erstelle RetrieveDocumentSetRequest Element und füge die documentIDs der abzurufenden Dokumente ein. 2. SOAP Request erstellen und das RetrieveDocumentSetRequest Element in den Body einfügen. 3. Autorisierungsinformation aus dem context in den SecurityHeader einfügen 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. RetrieveDocumentSetRequest Element aus dem Body nehmen und MTOM 1.1 Nachrichtenanteile verarbeiten, falls vorhanden. 8. Entnehme docData Element und liefere es zurück. |
|
Nachbedingung |
Keine |
4.5.2.3 Beispiel retrieveData: Request
<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
<DocumentRequest>
<RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId>
<DocumentUniqueId>1.42.20101110141555.15</DocumentUniqueId>
</DocumentRequest>
</RetrieveDocumentSetRequest>
4.5.2.4 Beispiel retrieveData: Response
<xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<rs:RegistryResponse
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-egrep:ResponseStatusType:Success"/>
<xdsb:DocumentResponse>
<xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId>
<xdsb:DocumentUniqueId>1.2009.0827.08.33.5124</xdsb:DocumentUniqueId>
<xdsb:mimeType>application/pdf</xdsb:mimeType>
<xdsb:Document>
<xop:Include
href=cid:1.urn:uuid:C2CD255C5B1A1D72A41259184933880@apache.org
xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
</xdsb:Document>
</xdsb:DocumentResponse>
</xdsb:RetrieveDocumentSetResponse>
4.5.2.5 Beispiel retrieveData: Response mit Fehler
<xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<rs:RegistryResponse
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-egrep:ResponseStatusType:Failure"/>
<rs:RegistryErrorList>
<rs:RegistryError
severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”
errorCode=”$errorCode”
codeContext=”$errorMessage”
location=”$documentUniqueID”/>
</rs:RegistryErrorList>
</rs:RegistryResponse>
</xdsb:RetrieveDocumentSetResponse>
4.6 Schnittstelle I_HPD_Services
Die Schnittstelle I_HPD_Services ermöglicht die Verwaltung und Abfrage eines der EFA Community zugeordneten Verzeichnisses mit Informationen und Attributen zu Leistungserbringern, welche als Teilnehmer der EFA Community registriert sind.
eFA2-A_2227 - Schnittstelle I_HPD_Services
Der EFA-Fachdienst SOLL die Schnittstelle I_HPD_Services gemäß Tabelle 45 anbieten. Die Parameter folgen dabei ITI-58 bzw. ITI-59.
Tabelle 45 Schnittstelle I_HPD_Services
Name |
I_HPD_Services |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: read Technisch: ITI-58 (Provider Information Query) |
Liest die Inhalte eines Verzeichniseintrages. |
|
Logisch: add, modify, delete Technisch: ITI-59 (Provider Information Feed) |
„add“: Fügt einen neuen Verzeichniseintrag hinzu oder überschreibt einen bestehenden Verzeichniseintrag. „modify“: Ändert die Inhalte eines Verzeichniseintrages „delete“: Löscht einzelne Inhalte oder den gesamten Verzeichniseintrag |
|
WSDL |
HPD_ProviderInformationDirectory.wsdl |
|
Schema |
DSMLv2.xsd |
[<=]
Informativ: Gemäß DSMLv2 können die logischen Operationen „add“, „modify“ und „delete“ ein und desselben Aufrufers innerhalb einer ITI-59 Transaktion als „DSMLv2 batchRequest“ gebündelt werden. Der Fachdienst muss dabei zu jedem Element des batchRequest ein korrespondierendes Antwortelement, gebündelt in einem DSML batchResponse Element, zurückliefern.
Die Authentisierung der technischen Kommunikationsverbindung zum HPD erfolgt gegenseitig per TLSv1.2. Die Authentisierung gegenüber dem HPD Dienst auf (logischer) Ebene des Aufrufers erfolgt mithilfe HPIdentityAssertion. Die Autorisierung auf Ebene der HPD Operation und auf Ebene der Datenanzeige basiert auf den Berechtigungen des identifizierten Aufrufers (Rollenrechte, Attributrechte). Zu diesen operativen Aspekten macht diese Spezifikation bewusst keine Vorgaben.
4.6.1 Operation providerInformationQuery
Diese Operation liest einen oder mehrere Verzeichniseinträge aus einem HPD.
4.6.1.1 Umsetzung
eFA2-A_2228 - Umsetzung I_HPD_Services::providerInformationQuery
Der EFA Anbieter MUSS an der EFA-Fachdienst Schnittstelle I_HPD_Services die Operation providerInformationQuery nach den Vorgaben Tabelle 46, Tabelle 47 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 46 Übersicht Operation providerInformationQuery
Name |
providerInformationQuery |
||
---|---|---|---|
Beschreibung |
Diese Operation liest einen oder mehrere Verzeichniseinträge aus einer Health Provider Directory Service Instanz (HPD). |
||
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client, der EFA Teilnehmer zwecks Erweiterung des Kreises der Berechtigten auf eine Fallakte finden möchte. |
||
Parameter |
|||
Name |
Beschreibung |
||
context |
HPIdentityAssertion |
||
batchRequest |
DSMLv2 batchRequest mit einem oder mehreren “searchRequest“ Elementen. |
||
Rückgabe |
|||
Name |
Beschreibung |
||
Status |
Enthält den Ausführungsstatus der Operation |
||
batchResponse |
DSMLv2 batchResponse mit einer Anzahl dem Request entsprechenden “searchResponse“ Elementen. |
||
Vorbedingung |
|
||
Nachbedingung |
|||
Varianten |
Mehrfache Operationen |
Technisch können mehrere verschiedene Leseoperationen in einem Request beauftragt werden. Das Lesen mehrerer HPD Einträge ist analog zum Lesen eines Eintrages, lediglich die Menge an «searchRequest» Elementen im batchRequest, sowie die Menge an «searchResponse» Elementen im batchResponse ändern sich von „1“ auf „n“. |
|
Multiple Operationen |
Technisch können mehrere verschiedene Operationen wie lesen, ändern, erzeugen, löschen in einem Request beauftragt werden. |
Tabelle 47 Ablauf Operation providerInformationQuery
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
HPD: Interne Verarbeitung |
1. Erstelle batchResponse Element 2. Für jedes searchRequest Element im batchRequest: 2.1. Durchsuche Verzeichnis 2.2. Erstelle korrespondierendes Element searchResultEntry. 2.3. Füge Suchergebnis in searchResultEntry 2.4. Gebe searchResultEntry zurück 2.5. Füge searchResultEntry in das batchResponse Element ein. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge das DSML batchResponse Element in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.6.1.2 Nutzung der Operation providerInformationQuery
Der Nutzer der Schnittstelle SOLL die Operation „providerInformationQuery“ gemäß Tabelle 48 verwenden
Tabelle 48 Nutzung Operation providerInformationQuery
Name |
providerInformationQuery |
|
---|---|---|
Beschreibung |
Ermittelt die providerseitig registrierte patientID zu den angegebenen Suchmerkmalen, z.B. lokale patientID oder demographische Daten. |
|
Auslöser |
Ein EFA Client nutzt diese Operation im Rahmen des Aufbaues eines sicheren Anwendungskontextes für eine Fallakte zur Ermittlung der providerseitigen patientID. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
batchRequest |
DSMLv2 batchRequest mit einem oder mehreren “searchRequest“ Elementen. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
batchResponse |
DSMLv2 batchResponse mit einer Anzahl dem Request entsprechenden “searchResponse“ Elementen. |
|
Vorbedingung |
||
Ablauf |
1. DSML „batchRequest“ Element entgegennehmen und prüfen, dass mindestens ein „searchRequest“ Element enthalten ist. 2. Ein DSMLRequest Element erstellen und das batchRequest darin einfügen. 3. SOAP Request erstellen und das DSMLRequest Element in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. DSMLResponse Element aus dem Body nehmen 8. DSML batchResponse Element aus der DSML Response entnehmen und zurückliefern. Das Element „batchResponse“ enthält zu jedem „searchRequest“ Element das Requests ein korrespondierendes „searchResponse“ Element |
|
Nachbedingung |
Keine |
4.6.2 Operation providerInformationFeed
Diese Operation verändert den Datenbestand von Verzeichniseinträgen in einem HPD. Sie unterstützt die HPD Operationen „add“, „modify“ und „delete“, welche in der Nachricht an den HPD durch verschiedene DSML Elemente ausgewiesen werden.
Die HPD Operation „add“ fügt ein oder mehrere Einträge zu einem HPD hinzu, bereits existierende Einträge werden überschrieben.
Die HPD Operation „modify“ ändert einen oder mehrere bestehende HPD Einträge.
Die HPD Operation „delete“ löscht einen oder mehrere bestehende HPD Einträge.
4.6.2.1 Umsetzung
eFA2-A_2229 - Umsetzung I_HPD_Services::providerInformationFeed
Der EFA Anbieter KANN an der EFA-Fachdienst Schnittstelle I_HPD_Services die Operation providerInformationFeed nach den Vorgaben von Tabelle 49, Tabelle 50 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 49 Übersicht Operation providerInformationFeed
Name |
providerInformationFeed |
||
---|---|---|---|
Beschreibung |
Diese Operation fügt einer Health Provider Directory Service Instanz (HPD) einen oder mehrere Verzeichniseinträge hinzu, oder verändert oder löscht einen oder mehrere Verzeichniseinträge. |
||
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client, der Verzeichniseinträge im HPD im Rahmen seiner Datenzugriffsrechte modifizieren möchte. |
||
Parameter |
|||
Name |
Beschreibung |
||
context |
HPIdentityAssertion |
||
batchRequest |
DSMLv2 batchRequest mit einem oder mehreren Elementen vom Typ „addRequest“, „modifyRequest“ oder „deleteRequest“. |
||
Rückgabe |
|||
Name |
Beschreibung |
||
Status |
Enthält den Ausführungsstatus der Operation |
||
batchResponse |
DSMLv2 batchResponse mit einer Anzahl dem Request entsprechenden Elementen vom Typ “addResponse“, „modifyResponse“ und „deleteResponse“. |
||
Vorbedingung |
|
||
Nachbedingung |
Keine über [efa2spec] hinausgehenden |
||
Varianten |
Mehrfache Operationen |
Technisch können mehrere verschiedene DSML Operationen in einem Request beauftragt werden. Das Verarbeiten mehrerer HPD Einträge geschieht analog zur Verarbeitung eines Eintrages, lediglich die Menge an «*Request» Elementen im batchRequest, sowie die Menge an «*Response» Elementen im batchResponse ändern sich von „1“ auf „n“. |
|
Multiple Operationen |
Technisch können mehrere verschiedene Operationen wie lesen, ändern, erzeugen, löschen in einem Request beauftragt werden. Die operativen Konsequenzen sind mit dem HPD Betreiber abzustimmen. |
Tabelle 50 Ablauf Operation providerInformationFeed
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
HPD: Interne Verarbeitung |
1. Erstelle batchResponse Element 2. Für jedes addRequest Element im batchRequest: 2.1. Ermittle existierenden Eintrag 2.1.1. falls vorhanden und überschreibe diesen. 2.2.2. Erstelle neuen Eintrag, falls nicht vorhanden. 2.2. Erstelle korrespondierendes addResponse Element und füge es in das batchResponse Element ein. 3.1. Für jedes modifyRequest Element im batchRequest: 3.1. Ermittle existierenden Eintrag 3.1.1. falls vorhanden ändere / ergänze diesen. 3.2. Erstelle korrespondierendes modifyResponse Element und füge es in das batchResponse Element ein. 3.1. Für jedes deleteRequest Element im batchRequest: 3.1. Ermittle existierenden Eintrag 3.1.1. falls vorhanden lösche diesen. 3.2. Erstelle korrespondierendes deleteResponse Element und füge es in das batchResponse Element ein. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge das DSML batchResponse Element in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.6.2.2 Nutzung der Operation providerInformationFeed
Der Nutzer der Schnittstelle SOLL die Operation „providerInformationFeed“ gemäß Tabelle 51 verwenden
Tabelle 51 Nutzung Operation providerInformationFeed
Name |
providerInformationFeed |
|
---|---|---|
Beschreibung |
Ermittelt die providerseitig registrierte patientID zu den angegebenen Suchmerkmalen, z.B. lokale patientID oder demographische Daten. |
|
Auslöser |
Ein EFA Client nutzt diese Operation im Rahmen des Aufbaues eines sicheren Anwendungskontextes für eine Fallakte zur Ermittlung der providerseitigen patientID. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
batchRequest |
DSMLv2 batchRequest mit einem oder mehreren “searchRequest“ Elementen. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
batchResponse |
DSMLv2 batchResponse mit einer Anzahl dem Request entsprechenden “searchResponse“ Elementen. |
|
Vorbedingung |
Die Gegenstelle ist unter der angegebenen Adresse und Port erreichbar. |
|
Ablauf |
1. DSML „batchRequest“ Element entgegennehmen und prüfen, dass mindestens ein „searchRequest“ Element enthalten ist. 2. Ein DSMLRequest Element erstellen und das batchRequest darin einfügen. 3. SOAP Request erstellen und das DSMLRequest Element in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOAP Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. DSMLResponse Element aus dem Body nehmen 8. DSML batchResponse Element aus der DSML Response entnehmen und zurückliefern. Das Element „batchResponse“ enthält zu jedem „searchRequest“ Element das Requests ein korrespondierendes „searchResponse“ Element |
|
Nachbedingung |
Keine |
4.6.3 Beispiel einer WSDL Definition eines HPD
<?xml version="1.0" encoding="utf-8"?>
<!-- EFA HPD Provider Information Directory -->
<definitions name="HPDProviderInformationDirectory"
targetNamespace="urn:ihe:iti:hpd:2010"
xmlns:tns="urn:ihe:iti:hpd:2010"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<documentation>
IHE HPD Provider Information Directory
</documentation>
<!-- EFA HPD types -->
<types>
<xsd:schema
targetNamespace="urn:oasis:names:tc:DSML:2:0:core"
xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core">
<xsd:include schemaLocation="../schema/DSML/DSMLv2.xsd"/>
</xsd:schema>
</types>
<!-- EFA HPD messages -->
<message name="ProviderInformationRequestMessage">
<documentation>
Provider Information Query/Feed Request Message
</documentation>
<part name="body" element="dsml:batchRequest" />
</message>
<message name="ProviderInformationResponseMessage">
<documentation>
Provider Information Query/Feed ResponseMessage
</documentation>
<part name="body" element="dsml:batchResponse"/>
</message>
<!-- EFA HPD port types -->
<portType name="ProviderInformationDirectory_PortType">
<operation name="ProviderInformationQueryRequest">
<input message="tns:ProviderInformationRequestMessage"
wsaw:Action="urn:ihe:iti:2010:ProviderInformationQuery"/>
<output message="tns:ProviderInformationResponseMessage"
wsaw:Action="urn:ihe:iti:2010:ProviderInformationQueryResponse"/>
</operation>
<operation name="ProviderInformationFeedRequest">
<input message="tns:ProviderInformationRequestMessage"
wsaw:Action="urn:ihe:iti:2010:ProviderInformationFeed"/>
<output message="tns:ProviderInformationResponseMessage"
wsaw:Action="urn:ihe:iti:2010:ProviderInformationFeedResponse"/>
</operation>
</portType>
<!-- EFA HPD bindings -->
<binding name="ProviderInformationDirectory_Binding"
type="tns:ProviderInformationDirectory_PortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="ProviderInformationQueryRequest">
<soap:operation
soapAction="urn:ihe:iti:hpd:2010:ProviderInformationQueryRequest" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="ProviderInformationFeedRequest">
<soap:operation
soapAction="urn:ihe:iti:hpd:2010:ProviderInformationFeedRequest" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<!-- EFA HPD services -->
<service name="ProviderInformationDirectory_Service">
<port name="ProviderInformationDirectory_Port_Soap"
binding="tns:ProviderInformationDirectory_Binding">
<soap:address
location="https://localhost:${HttpsDefaultPort}/
ProviderInformationDirectoryService"/>
</port>
</service>
</definitions>
4.6.4 Beispiel „modify HPD Provider Information Feed“
4.6.4.1 Update Request an einen HPD
<?xml version="1.0" encoding="utf-8"?>
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" >
<soap-env:Body>
<dsml:batchRequest
xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<dsml:modifyRequest
dn="uid=hpdtest:6,ou=Individual Provider,O=HPDTEST,DC=HPD,C=US" >
<dsml:modification name="HcSpecialisation" operation="delete">
<dsml:value>Orthopedic</dsml:value>
</dsml:modification>
<dsml:modification name="HcSpecialisation" operation="add">
<dsml:value>Cadiology</dsml:value>
</dsml:modification>
</dsml:modifyRequest>
</dsml:batchRequest>
</soap-env:Body>
</soap-env:Envelope>
4.6.4.2 Modify Response eines HPD
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >
<SOAP-ENV:Body>
<batchResponse
xmlns="urn:oasis:names:tc:DSML:2:0:core" />
<modifyResponse>
<resultCode code="0 />
</modifyResponse>
</batchResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
4.6.5 Beispiel „search HPD Provider Information Query“
4.6.5.1 Search Request an einen HPD
<?xml version="1.0" encoding="utf-8"?>
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
<soap-env:Body>
<dsml:batchRequest>
xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<dsml:searchRequest
dn="O=HPDTEST,DC=HPD,C=US"
scope="wholeSubtree"
derefAliases="neverDerefAliases"
sizeLimit="100">
<dsml:filter>
<dsml:approxMatch name="displayName">
<dsml:value>Mark Smith</dsml:value>
</dsml:approxMatch>
</dsml:filter>
<dsml:attributes>
<dsml:attribute name="HcPracticeLocation" />
<dsml:attribute name="HcPrincipalPracticeLocation" />
<dsml:attribute name="HcRegisteredAddr" />
<dsml:attribute name="HcServiceLocations" />
<dsml:attribute name="hpdProviderPracticeAddress" />
<dsml:attribute name="HcIdentifier" />
<dsml:attribute name="HcRegisteredName" />
<dsml:attribute name="HcRole" />
<dsml:attribute name="HcSpecialisation" />
<dsml:attribute name="HcOperatingHours" />
<dsml:attribute name="givenName" />
<dsml:attribute name="cn" />
<dsml:attribute name="memberOf" />
</dsml:attributes>
</dsml:searchRequest>
</dsml:batchRequest>
</soap-env:Body>
</soap-env:Envelope>
4.6.5.2 Search Response eines HPD
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<batchResponse
xmlns="urn:oasis:names:tc:DSML:2:0:core"
xmlns:xsd="http: //www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<searchResponse requestID="4">
<searchResultEntry dn="cn=JSmith,o=test" requestID="4">
<attr name="l">
<value>Alaska</value>
</attr>
<attr name="cn">
<value>James Smith</value>
<value>Jim Smith</value>
<value>Jimmy Smith</value>
<value>JSmith</value>
</attr>
<attr name="sn"><value>Smith</value></attr><
/searchResultEntry><searchResultEntry dn="cn=sunil,o=test"
requestID="4"><attr name="cn"><value>sunil</value></attr><attr
name="sn"><value>kr</value></attr></searchResultEntry>
<searchResultDone requestID="4"><resultCode code="0" descr="Success" /><
/searchResultDone>
</searchResponse>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>
4.7 Schnittstelle I_PIX_Manager
Die optionale Schnittstelle I_PIX_Manager realisiert die Schnittstelle zur übergreifenden Identifikation von Patienten anhand verteilter Identitätsmerkmale [IHE PIXv3 Profile].
Der EFA Client nutzt zur Ermittlung der providerseitigen patientID anhand demographischer Daten die Transaktion „ITI-45 PIX Query (HL7v3) Transaction“, Siehe auch [IHE PIXv3 Profile#3.45].
Zur Registrierung der lokalen Patientenidentifikation in der EFA Community nutzt der EFA Client die Transaktion „ITI-44 Patient Identity Feed (HL7v3)“.
Die Schnittstelle I_PIX_Manager ermittelt die auszuführend Operation anhand des in der Transaktion ITI-44 übermittelten Nachrichtentyps: Eine Nachricht vom Typ PRPA_IN201301UV02 signalisiert die Operation „patientActivate“, die Nachricht vom Typ PRPA_IN201302UV02 die Operation „patientRevise“
Die Nutzung der „ITI-46 PIX Update Notification (HL7v3) Transaction“ ist für die EFA 2.0 Migration nicht vorgesehen.
eFA2-A_2230 - Schnittstelle I_PIX_Manager
Der EFA-Fachdienst KANN die Schnittstelle I_PIX_Manager gemäß Tabelle 52 anbieten. Die Parameter folgen dabei ITI-44 bzw. ITI-46.
Tabelle 52 Schnittstelle I_PIX_Manager
Name |
I_PIX_Manager |
|
---|---|---|
Version |
wird im Produktsteckbrief der EFA Fachdienste definiert |
|
Namensraum |
Siehe Anhang D |
|
Operationen |
Name (logisch, technisch) |
Kurzbeschreibung |
Logisch: getCorrespondingIdentifiersQuery Technisch: ITI-45 (Patient Registry Get Identifiers) Input: PRPA_IN201309UV02 Output: PRPA_IN201310UV02 |
Abfrage des PIXManager nach mit einer lokalen patientID korrespondierenden, providerseitigen patientIDs. |
|
Logisch: „add“ patientActivate Technisch: ITI-44 (Patient Identity Feed HL7 V3) Input: PRPA_IN201301UV02 Output: MCCI_IN00002UV01 |
Neuanlage eines Patientendatensatzes beim Anbieter und Registrierung der lokalen patientID mit der anbieterseitigen patientID. |
|
Logisch: „revise“ patientRevise Technisch: ITI-44 (Patient Identity Feed HL7 V3) Input: PRPA_IN201302UV02 Output: MCCI_IN00002UV01 |
Ergänzung eines Patientendatensatzes beim Anbieter durch Registrierung der lokalen patientID mit der anbieterseitigen patientID |
|
WSDL |
PIXManager.wsdl |
|
Schema |
ITI/schema/HL7V3/NE2008/multicacheschemas/*.xsd |
[<=]
4.7.1 Operation getCorrespondingIdentifiersQuery (ITI-45)
Diese Operation identifiziert einen Patienten anhand demographischer Merkmale wie zum Beispiel einer lokalen Patientenidentifikation und liefert die patientID und eventuell weitere, in der EFA Community registrierte Identifikationsmerkmale des Patienten zurück.
Vorbedingung ist die Verknüpfung der lokalen „Patientenidentifikation“ mit der „patientID“ der EFA Community, die bei Anlage der Fallakte vergeben wurde. Diese Verknüpfung kann mithilfe der Operation patientRevise erfolgen.
4.7.1.1 Umsetzung
Die Operation wird umgesetzt durch die HL7v3 Transaktion ITI-45 „Patient Registry Get Identifiers“ mit der Nachricht PRPA_IN201309UV02.
eFA2-A_2231 - Umsetzung I_PIX_Manager::getCorrespondingIdentifiersQuery
Bietet der EFA Anbieter in einer Community das Funktionsmerkmal PIXManager an, so MUSS die EFA-Fachdienst Schnittstelle I_PIX_Manager die Operation getCorrespondingIdentifiersQuery nach den Vorgaben aus Tabelle 46, Tabelle 54 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 53 Übersicht Operation getCorrespondingIdentifiersQuery
Name |
getCorrespondingIdentifiersQuery |
|
---|---|---|
Beschreibung |
Diese Operation identifiziert einen Patienten anhand einer lokalen Patientenidentifikation und liefert die patientID in der EFA Community zurück. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201309UV02 |
Nachricht PRPA_IN201309UV02 |
|
Rückgabe |
||
Name |
Beschreibung |
|
statusInfo |
Enthält den Ausführungsstatus der Operation |
|
PRPA_IN201310UV02 |
Nachricht PRPA_IN201310UV02 |
|
Vorbedingung |
Die mitgelieferte patientID und Domäneninformation identifiziert einen Patienten in der Community. |
|
Nachbedingung |
Keine |
|
Varianten |
Keine |
Tabelle 54 Ablauf Operation getCorrespondingIdentifiersQuery
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
PIX Manager: Interne Verarbeitung |
1. Verarbeite die ITI-45 Nachricht PRPA_IN201309UV02 2. Erstelle die Nachricht PRPA_IN201310UV02 und trage das Ergebnis der Transaktion ein. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die Nachricht PRPA_IN201310UV02 in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.7.1.2 Nutzung der Operation getCorrespondingIdentifiersQuery
Der Nutzer der Schnittstelle SOLL die Operation „getCorrespondingIdentifiersQuery“ gemäß Tabelle 55 nutzen.
Tabelle 55 Nutzung der Operation getCorrespondingIdentifiersQuery
Name |
getCorrespondingIdentifiersQuery |
|
---|---|---|
Beschreibung |
Ermittelt die providerseitig registrierte patientID zu den angegebenen Suchmerkmalen, z.B. lokale patientID oder demographische Daten. |
|
Auslöser |
Ein EFA Client nutzt diese Operation im Rahmen des Aufbaus des sicheren Anwendungskontextes zur Nutzung einer Fallakte für Ermittlung der providerseitigen patientID. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201309UV02 |
Nachricht mit lokaler patientID zu welcher die providerseitige patientID gefunden werden soll. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
PRPA_IN201310UV02 |
Ergebnis der Suchtransaktion des PIX Managers |
|
Vorbedingung |
Die Gegenstelle ist unter der angegebenen Adresse und Port erreichbar. |
|
Ablauf |
1. PRPA_IN201309UV02 Nachricht entgegennehmen. 2. SOAP Request erstellen und das PRPA_IN201309UV02 Element in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOPA Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. PRPA_IN201310UV02 Element aus dem Body entnehmen und zurückliefern. |
|
Nachbedingung |
Keine |
4.7.2 Operation patientActivate
Diese Operation legt einen neuen Patientendatensatz im PIXManager der EFA Community an und registriert ihn mit der lokalen Identifikation eines Patienten.
Die Verwendung durch EFA Clients erscheint fraglich, da die Neuanlage von Patienten – dann auch im PIXManager – keine unmittelbare Transaktion eines EFA Client ist.
4.7.2.1 Umsetzung
Die Operation wird umgesetzt durch die HL7v3 Transaktion ITI-44 „Patient Identity Feed“ mit der Nachricht PRPA_IN201301UV02.
eFA2-A_2232 - Umsetzung I_PIX_Manager::patientActivate
Bietet der EFA Anbieter in einer Community das Funktionsmerkmal PIXManager an, so MUSS die EFA-Fachdienst Schnittstelle I_PIX_Manager die Operation patientActivate nach den Vorgaben aus Tabelle 56, Tabelle 57 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 56 Übersicht Operation patientActivate
Name |
patientActivate |
|
---|---|---|
Beschreibung |
Diese Operation legt einen neuen Patientendatensatz im PIXManager der EFA Community an und registriert ihn mit der lokalen Identifikation eines Patienten. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201301UV02 |
Nachricht PRPA_IN201301UV02 |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
MCCI_IN00002UV01 |
Nachricht MCCI_IN00002UV01 |
|
Vorbedingung |
|
|
Nachbedingung |
Keine |
|
Varianten |
Keine |
Tabelle 57 Ablauf Operation patientActivate
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
PIX Manager: Interne Verarbeitung |
1. Verarbeite die ITI-45 Nachricht PRPA_IN201301UV02 2. Erstelle die Nachricht MCCI_IN00002UV01 und trage das Ergebnis der Transaktion ein. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die Nachricht MCCI_IN00002UV01 in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.7.2.2 Nutzung der Operation patientActivate
Der Nutzer der Schnittstelle SOLL die Operation „patientActivate“ gemäß Tabelle 58 verwenden.
Tabelle 58 Nutzung der Operation patientActivate
Name |
patientActivate |
|
---|---|---|
Beschreibung |
Ermittelt die providerseitig registrierte patientID zu den angegebenen Suchmerkmalen, z.B. lokale patientID oder demographische Daten. |
|
Auslöser |
Ein EFA Client nutzt diese Operation im Rahmen des Aufbaues eines sicheren Anwendungskontextes für eine Fallakte zur Ermittlung der providerseitigen patientID. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201301UV02 |
Nachricht PRPA_IN201301UV02 |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
MCCI_IN00002UV01 |
Nachricht MCCI_IN00002UV01 |
|
Vorbedingung |
Die Gegenstelle ist unter der angegebenen Adresse und Port erreichbar. |
|
Ablauf |
1. PRPA_IN201301UV02 Nachricht entgegennehmen. 2. SOAP Request erstellen und das PRPA_IN201301UV02 Element in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOPA Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. MCCI_IN00002UV01 Element aus dem Body entnehmen und zurückliefern. |
|
Nachbedingung |
Keine |
4.7.3 Operation patientRevise
Diese Operation registriert die lokale Identifikation eines Patienten zu einer Fallakte in der EFA Community hinzu. So wird die lokale „patientID“ mit der „patientID“ der Fallakte in der Community verknüpft.
4.7.3.1 Umsetzung
Die Operation wird umgesetzt durch die HL7v3 Transaktion ITI-44 „Patient Identity Feed“ mit der Nachricht PRPA_IN201302UV02.
eFA2-A_2233 - Umsetzung I_PIX_Manager::patientRevise
Bietet der EFA Anbieter in einer Community das Funktionsmerkmal PIXManager an, so MUSS die EFA-Fachdienst Schnittstelle I_PIX_Manager die Operation patientRevise nach den Vorgaben aus Tabelle 59, Tabelle 60 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 59 Übersicht Operation patientRevise
Name |
patientRevise |
|
---|---|---|
Beschreibung |
Diese Operation registriert die lokale Identifikation eines Patienten zu einer Fallakte in der EFA Community hinzu. So wird die lokale „patientID“ mit der „patientID“ der Fallakte in der Community verknüpft. |
|
Auslöser |
Aufruf durch das EFA Fachmodul aus der TI, initiiert durch einen EFA Client. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201302UV02 |
Nachricht PRPA_IN201301UV02 |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
MCCI_IN00002UV01 |
Nachricht MCCI_IN00002UV01 |
|
Vorbedingung |
|
|
Nachbedingung |
Keine |
|
Varianten |
Keine |
Tabelle 60 Ablauf Operation patientRevise
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Vorbereitung |
TUC siehe 4.9.1 unten 1. Verbindungsannahme, 2. Prüfung Security Header, 3. Schemaprüfung, 4. Authentisierung und Autorisierung |
2 |
PIX Manager: Interne Verarbeitung |
1. Verarbeite die ITI-45 Nachricht PRPA_IN201302UV02 2. Erstelle die Nachricht MCCI_IN00002UV01 und trage das Ergebnis der Transaktion ein. |
3 |
Response vorbereiten und senden |
Erstelle die SOAP Response und füge die Nachricht MCCI_IN00002UV01 in den SOAP Body. Liefere Response an den Aufrufer und gebe TLS Verbindung frei. |
[<=]
4.7.3.2 Nutzung der Operation patientRevise
Der Nutzer der Schnittstelle SOLL die Operation „patientRevise“ gemäß Tabelle 61 verwenden.
Tabelle 61 Nutzung der Operation patientRevise
Name |
patientRevise |
|
---|---|---|
Beschreibung |
Diese Operation registriert die lokale Identifikation eines Patienten zu einer Fallakte in der EFA Community hinzu. So wird die lokale „patientID“ mit der „patientID“ der Fallakte in der Community verknüpft. |
|
Auslöser |
Ein EFA Client nutzt diese Operation bei der erstmaligen Registrierung eines Patienten mit einer elektronischen Fallakte. |
|
Parameter |
||
Name |
Beschreibung |
|
context |
HPIdentityAssertion |
|
PRPA_IN201302UV02 |
Nachricht PRPA_IN201302UV02 |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
MCCI_IN00002UV01 |
Nachricht MCCI_IN00002UV01 |
|
Vorbedingung |
Die Gegenstelle ist unter der angegebenen Adresse und Port erreichbar. |
|
Ablauf |
1. PRPA_IN201302UV02 Nachricht entgegennehmen. 2. SOAP Request erstellen und das PRPA_IN201302UV02 Element in den Body einfügen. 4. Verbindungsaufbau zur Gegenstelle 5. SOPA Request versandfertig aufbereiten und an Gegenstelle senden. 6. SOAP Response entgegennehmen 7. MCCI_IN00002UV01 Element aus dem Body entnehmen und zurückliefern. |
|
Nachbedingung |
Keine |
4.8 Beispiel einer WSDL Definition für eine EFA-Fachdienst Instanz
Zur Beschreibung der Charakteristik der EFA2.0 Fachdienst Schnittstelle ist im folgenden Abschnitt eine beispielhafte WSDL abgebildet.
Das Format der Darstellung soll die Lesbarkeit und Bezugnahme mithilfe von Zeilennummern, XML Kommentaren, Zeilenumbrüchen und Einrückungen unterstützen.
Die referenzierten WS-Policies sind separat in Abschnitt 4.8.2.1 abgebildet.
4.8.1 WSDL einer EFA-Fachdienst Instanz
<?xml version="1.0" encoding="UTF-8"?>
<!-- EFA Services WSDL -->
<wsdl:definitions name="EFA-v2-Provider-Services"
targetNamespace="http://fokus.fraunhofer.de/cc-ehealth/efa-v2/"
xmlns:efa2="http://fokus.fraunhofer.de/cc-ehealth/efa-v2/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsp="http://www.w3.org/ns/ws-policy/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xdsb="urn:ihe:iti:xds-b:2007"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- EFA2 Services WSDL: Type Definitions -->
<wsdl:types>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:ihe:iti:xds-b:2007">
<xs:include schemaLocation="XDS.b_DocumentRepository.xsd"/>
</xs:schema>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">
<xs:include schemaLocation="rs.xsd"/>
</xs:schema>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
<xs:include schemaLocation="query.xsd"/>
</xs:schema>
</wsdl:types>
<!-- EFA2 Services WSDL: Message Definitions -->
<wsdl:message name="RegistryStoredQuery_Message">
<wsdl:documentation>Registry Stored Query [ITI-18] Request
</wsdl:documentation>
<wsdl:part element="query:AdhocQueryRequest" name="body"/>
</wsdl:message>
<wsdl:message name="RegistryStoredQuery_Response_Message">
<wsdl:documentation>Registry Stored Query [ITI-18] Response
</wsdl:documentation>
<wsdl:part element="query:AdhocQueryResponse" name="body"/>
</wsdl:message>
<wsdl:message name="ProvideAndRegisterDocumentSetRequest">
<wsdl:documentation>Provide and Register Document Set-b [ITI-41] Request
</wsdl:documentation>
<wsdl:part element="xdsb:ProvideAndRegisterDocumentSetRequest" name="body"/>
</wsdl:message>
<wsdl:message name="RegistryResponse">
<wsdl:documentation>Provide and Register Document Set-b [ITI-41] Response
</wsdl:documentation>
<wsdl:part element="rs:RegistryResponse" name="body"/>
</wsdl:message>
<wsdl:message name="RetrieveDocumentSetRequest">
<wsdl:documentation>Retrieve Document Set [ITI-43] Request
</wsdl:documentation>
<wsdl:part element="xdsb:RetrieveDocumentSetRequest" name="body"/>
</wsdl:message>
<wsdl:message name="RetrieveDocumentSetResponse">
<wsdl:documentation>Retrieve Document Set [ITI-43] Response
</wsdl:documentation>
<wsdl:part element="xdsb:RetrieveDocumentSetResponse" name="body"/>
</wsdl:message>
<wsdl:message name="RegisterDocumentSet-b_Message">
<wsdl:documentation>Register Document Set - b [ITI-42] Request
</wsdl:documentation>
<wsdl:part element="lcm:SubmitObjectsRequest" name="body"/>
</wsdl:message>
<wsdl:message name="RegisterDocumentSet-bResponse_Message">
<wsdl:documentation>Register Document Set - b [ITI-42] Response
</wsdl:documentation>
<wsdl:part element="rs:RegistryResponse" name="body"/>
</wsdl:message>
<!-- ITI-44 Patient Identity Feed -->
<!-- ITI-53 Document Metadata Notify -->
<!-- ITI-56 Patient Location Query -->
<!—EFA2 Services WSDL: Port Type Definitions -->
<wsdl:portType name="EFA-Provider_DedicatedClient">
<wsdl:operation name="RegistryStoredQuery">
<wsdl:input message="efa2:RegistryStoredQuery_Message"
wsaw:Action="urn:ihe:iti:2007:RegistryStoredQuery"/>
<wsdl:output message="efa2:RegistryStoredQuery_Response_Message"
wsaw:Action="urn:ihe:iti:2007:RegistryStoredQueryResponse"/>
</wsdl:operation>
<wsdl:operation name="DocumentRepository_ProvideAndRegisterDocumentSet-b">
<wsdl:input message="efa2:ProvideAndRegisterDocumentSetRequest"
wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"/>
<wsdl:output message="efa2:RegistryResponse"
wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse"/>
</wsdl:operation>
<wsdl:operation name="RetrieveDocumentSetDocumentConsumer_RetrieveDocumentSet">
<wsdl:input message="efa2:RetrieveDocumentSetRequest"
wsaw:Action="urn:ihe:iti:2007:RetrieveDocumentSet"/>
<wsdl:output message="efa2:RetrieveDocumentSetResponse"
wsaw:Action="urn:ihe:iti:2007:RetrieveDocumentSetResponse"/>
</wsdl:operation>
<wsdl:operation name="DocumentRegistry_RegisterDocumentSet-b">
<wsdl:input message="efa2:RegisterDocumentSet-b_Message"
wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-b"/>
<wsdl:output message="efa2:RegisterDocumentSet-bResponse_Message"
wsaw:Action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse"/>
</wsdl:operation>
</wsdl:portType>
<!-- EFA2 Services WSDL: Binding Definitions -->
<wsdl:binding name="EFA-Provider_DedicatedClientSoap12Http"
type="efa2:EFA-Provider_DedicatedClient">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:PolicyReference URI="#EFA-Provider_DedicatedClientSoap12HttpPolicy"/>
<wsdl:operation name="RegistryStoredQuery">
<soap12:operation soapAction="urn:ihe:iti:2007:RegistryStoredQuery"/>
<wsdl:input>
<soap12:body parts="body" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body parts="body" use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DocumentRepository_ProvideAndRegisterDocumentSet-b">
<soap12:operation
soapAction="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"/>
<wsdl:input>
<soap12:body parts="body" use="encoded"/>
</wsdl:input>
<wsdl:output>
<soap12:body parts="body" use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation
name="RetrieveDocumentSetDocumentConsumer_RetrieveDocumentSet">
<soap12:operation soapAction="urn:ihe:iti:2007:RetrieveDocumentSet"/>
<wsdl:input>
<soap12:body parts="body" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body parts="body" use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DocumentRegistry_RegisterDocumentSet-b">
<soap12:operation soapAction="urn:ihe:iti:2007:RegisterDocumentSet-b"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<!—EFA2 Services WSDL: Service Definitions -->
<wsdl:service name="EFA">
<wsdl:port binding="efa2:EFA-Provider_DedicatedClientSoap12Http"
name="EFA-Provider">
<soap12:address location="http://localhost"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
4.8.2 Web Service Policies für EFA-Fachdienste
4.8.2.1 Allgemeine Policy (alle Dienste außer IDP / PP )
<!-- EFA2 Services WSDL: Policy Definitions -->
<wsp:Policy wsu:Id="EFA-Provider_DedicatedClientSoap12HttpPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false"/>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="true"/>
</wsp:Policy>
</sp:TransportToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimeStamp/>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:SHA256/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:SamlToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
4.9 Übergreifende Funktionen
Die folgenden Abschnitte formulieren übergreifende Anforderungen für alle Fachdienstschnittstellen normativ.
4.9.1 Allgemeine Funktionen
Die Operationen der Fachdienstschnittstellen durchlaufen „allgemeine“, stets gleiche Funktionen. Dazu gehören zum Bespiel der Aufbau einer TLS Server Verbindung auf Anforderung, die Schemaprüfung des SOAP Request, die Validierung des SecurityHeader und der HPIdentityAssertion.
Diese Funktionen sind folgend an einer Stelle beschrieben, und werden bei den Operationen nicht mehr erwähnt.
eFA2-A_2234 - Allgemeine Funktionen an den Schnittstellen
Jede EFA-Fachdienst Schnittstelle MUSS die Funktionen gemäß Tabelle 62 anbieten. Diese allgemeinen Funktionen stehen allen Schnittstellenoperationen zur Verfügung.
Tabelle 62 Allgemeine Funktionen an den Schnittstellen
Name |
Allgemeine Funktionen |
|
---|---|---|
Version |
||
Namensraum |
||
Funktionen |
Name |
Kurzbeschreibung |
TLSHandShakeServer |
Die Funktion verarbeitet einen eingehenden Request eines TLS Client aus der Secure Consumer Zone, etabliert die serverseitige TLS Session und liefert den Session Handle zurück. Siehe 4.9.1.1 unten. |
|
validateSOAPRequest |
SOAP Request gegen Mindestanforderungen an die XML Schema Konformität prüfen. Siehe Kapitel 4.9.1.3 unten |
|
validateWSSecurityHeader |
Überprüft die Authentizität und Integrität eines WS Security Headers. Siehe Kapitel 4.9.1.3 unten |
|
validateHPIdentityAssertion |
Überprüft die Integrität und Authentizität einer HPIdentityAssertion. Siehe Kapitel 4.9.4 unten. |
|
WSDL |
n.v. |
|
Schema |
Verschiedene |
[<=]
eFA2-A_2141 - Verhalten bei Abbruch der Verarbeitung
Kann im Rahmen der Validierung eines EFA-Fachdienst Aufrufs einer oder mehrere der formulierten Anforderungen nicht erfüllt werden MUSS die Prüfung und Verarbeitung mit einer Fehlermeldung abgebrochen werden.
[<=]4.9.1.1 TLS Verbindungsanfragen annehmen
eFA2-A_2235 - TLS Accept für eingehende Requests
Jede Fachdienstschnittstelle in der Provider Zone MUSS zur Beantwortung eingehender TLS Verbindungsanfragen aus der Secure Consumer Zone die Funktion TLSHandShakeServer wie in Kapitel 4.9.5.1 beschrieben, implementieren.
[<=]4.9.1.2 XML Schema eingehender SOAP Requests validieren
eFA2-A_2236 - XML Schema Validierung eingehender Requests
Jede Fachdienstschnittstelle in der Provider Zone MUSS eingehende SOAP Requests mithilfe einer XML Schemaprüfung wie folgt beschrieben validieren.
1. Jeder eingehende Request MUSS dem Schema SOAP Version 1.2 (Namespace http://www.w3.org/2003/05/soap-envelope) entsprechen.
2. Jeder eingehende Request MUSS genau einen SOAP Header mit den Elementen „Action“, „MessageID“ und „To“ aus dem Namespace WS-Addressing (http://www.w3.org/2005/08/addressing ) enthalten.
3. Das WS Adressing Element „To“ und die Endpunkt Adresse der aufgerufenen Fachdienst Instanz stimmen überein.
3. Das WS Adressing Element „Action“ und die aufgerufene Aktion der Fachdienst Instanz stimmen überein.
4. Jeder eingehende Request MUSS genau ein SOAP Body Element enthalten.
5. Jeder eingehende Request MUSS im SOAP Header ein SecurityHeader Element enthalten, welches den in [WSSE-1.0]“, Kapitel 2.2 „Namespaces“ aufgeführten Schemas entspricht:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0
http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
4.9.1.3 WSSecurityHeader eingehender SOAP Requests validieren
eFA2-A_2237 - Validierung WSSecurityHeader
Jede Fachdienstschnittstelle in der Provider Zone MUSS zu jedem eingehenden gültigen SOAP Request dessen WS Security Header wie in Kapitel 4.9.3 unten beschrieben validieren.
[<=]4.9.1.4 HPIdentityAssertion validieren
eFA2-A_2238 - Validierung HPIdentityAssertion
Jede Fachdienstschnittstelle in der Provider Zone MUSS die Authentisierungs und Autorisierungsmerkmale des Aufrufers in Form einer SAML 2.0 Identity Assertion wie in Kapitel 4.9.4 unten beschrieben validieren.
[<=]4.9.2 Nachrichtenformat, allgemein
Requests, die den geprüften Anforderungen nicht vollständig entsprechen, dürfen nicht weiter verarbeitet werden.
eFA2-A_2239 - SOAP Protokollversion für EFA-Fachdienstaufrufe
Requests an EFA-Fachdienstschnittstellen und Responses von EFA-Fachdienst Schnittstellen MÜSSEN gemäß SOAP Version 1.2 formuliert sein.
[<=]eFA2-A_2152 - WS-Security Header für EFA-Fachdienstaufrufe
Jeder gültige EFA-Fachdienst Aufruf ist als SOAP Request formuliert und MUSS ein WS Security Header Element gemäß [WSSE-1.0] enthalten.
[<=]eFA2-A_2153 - SAML Assertion im Security Header
Jeder gültige EFA-Fachdienst Aufruf MUSS im Security Header eine SAML Assertion enthalten, die mit dem Schlüssel aus
[XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/ds:Signature/ds:KeyInfo/ds:X509Data/ds:X509Certificate
signiert ist. Ausgenommen davon sind Aufrufe an die Fachdienst Schnittstelle „I_eCR_Identity_Manager.
[<=]eFA2-A_2154 - Zugelassene SAML SubjectConfirmationMethod
Eine gültige SAML Assertion im Security Header eines EFA-Fachdienst Aufrufes MUSS als „SubjectConfirmationMethod“ unter
[XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/@Method
„urn:oasis:names:tc:SAML:2.0:cm:holder-of-key“ referenzieren.
[<=]eFA2-A_2155 - TimeStamp Signatur im Security Header
Ein TimeStamp im Security Header eines EFA-Fachdienstaufrufs MUSS mit dem Schlüssel/dem Zertifikat unter
[XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/saml2:SubjectConfirmationData/ds:KeyInfo/ds:KeyValue/ds:RSAKeyValue
signiert sein. Die Signatur MUSS GS-A_4371 (XML-Signaturen für nicht-qualifizierte Signaturen) erfüllen.
Bei ungültiger Signatur MUSS der Request abgewiesen werden.
[<=]4.9.3 Funktion validateWSSecurityHeader
Die Funktion dient der technischen Validierung eines WS Security Headers.
4.9.3.1 Umsetzung
eFA2-A_2240 - Umsetzung validateWSSecurityHeader
Die Implementierung der Fachdienstschnittstellen MUSS die Vorgaben für die Funktion „Validierung WS Security Header“ gemäß Tabelle 63 und Tabelle 64 umsetzen.
Tabelle 63 Übersicht Funktion validateWSSecurityHeader
Name |
validateWSSecurityHeader |
|
---|---|---|
Beschreibung |
Überprüft die Authentizität, Integrität und Konformität zu [WS-I Basic Security Profile 1.0] eines WS Security Headers. |
|
Auslöser |
An der Fachdienstschnittstelle in der Providerzone geht ein SOAP Request ein, dessen SOAP Header ein Element SecurityHeader enthält. Die Schnittstelle übergibt dieses Element zur Validierung an diese Funktion |
|
Parameter |
||
Name |
Beschreibung |
|
securityHeader |
SOAP Message Security 1.1. Header Element |
|
Rückgabe |
||
Name |
Beschreibung |
|
Boolean status |
Enthält den Ausführungsstatus der Operation |
|
Vorbedingung |
Keine |
|
Nachbedingung |
Keine |
Tabelle 64 Ablauf Funktion validateWSSecurityHeader
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Das Element SecurityHeader SOLL mindestens ein Element Signature enthalten, welches den Timestamp mit dem SignedEndorsingSupportingToken des Nutzers signiert. Einzige Ausnahme: RST mit UsernameToken an providerseitigen IdentityProvider. |
|
2 |
Das Element „SecurityHeader“ enthält genau ein Element „TimeStamp“ |
|
3 |
Das Element „TimeStamp“ weist ein gültiges Zeitfenster aus: Der im Element „Creation“ angegebene Zeitpunkt ist gültig und liegt vor der aktuellen Zeit. Der im Element „Expiration“ angegebene Zeitpunkt ist gültig und liegt nach der aktuellen Zeit. |
|
4 |
Der „TimeStamp“ ist signiert mit dem Schlüssel XPATH: Signature/SignedInfo/Reference/@URI aus einem der Signature Elemente. |
|
5 |
Die „TimeStamp“ Signatur ist prüfbar mit dem Schlüssel / der Schlüsselreferenz unter „Signature/KeyInfo“ |
|
5.1. |
Einzige Ausnahme: RST mit UsernameToken an providerseitigen IdentityProvider: Das Element SecurityHeader SOLL mindestens ein Element Signature enthalten, welches den Timestamp mit dem SignedEndorsingSupportingToken des Nutzers signiert. |
|
5.2. |
Normalfall „alle Requests außer IDP-RST (UT)“: Der TimeStamp MUSS signiert sein mit dem privaten RSA Schlüssel der subjectIdentity aus der gültigen HPIdentityAssertion: [XPATH] SecurityHeader/Assertion/ Subject/SubjectConfirmation/ SubjectConfirmationData/ds:KeyInfo/ ds:KeyValue/ds:RSAKeyValue |
|
6. |
Konformitätsanforderungen zum WS-I BasicSecurityProfile 1.0 müssen erfüllt sein. |
[<=]
4.9.4 Funktion validateHPIdentityAssertion
Diese Funktion überprüft eine im SecurityHeader eines Fachdienstaufrufs übermittelten HPIdentityAssertion auf ihre Gültigkeit.
4.9.4.1 Umsetzung
eFA2-A_2241 - Umsetzung validateHPIdentityAssertion
Die Implementierung der Fachdienstschnittstellen MUSS die Vorgaben für die Funktion „validateHPIdentityAssertion“ gemäß Tabelle 65, Tabelle 66 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 65 Funktion validateHPIdentityAssertion
Name |
validateHPIdentityAssertion |
|
---|---|---|
Beschreibung |
Diese Funktion überprüft die Authentizität und Integrität einer HPIdentityAssertion und liefert einen Status Code zurück. |
|
Auslöser |
Der SecurityHeader eines an der Fachdienstschnittstelle eingehenden Requests enthält eine SAML 2.0 HPIdentityAssertion, welche den Anfrager identifiziert und authentisiert. Der Fachdienst übergibt diese Assertion zur Validierung an die Funktion validateHPIdentityAssertion. |
|
Parameter |
||
Name |
Beschreibung |
|
token |
[XPATH] /soap:Envelope/soap:Header/wsse:Security /wsse:Assertion/saml2:Assertion |
|
Rückgabe |
||
Name |
Beschreibung |
|
Boolean Status |
Enthält den Ausführungsstatus der Operation |
|
Vorbedingung |
Das Token ist eine SAML 2.0 Assertion aus dem gültigen Security Header eines gültigen Fachdienstaufrufs. Die Assertion ist eine eCR-Identity Assertion gemäß „SAML 2.0 Profile for ECR Identity Assertions“ [efa2spec#245]. Die Assertion ist signiert durch C.HCI.STS-SIG (LocalAuthority im Fachmodul) oder C.FD.STS-SIG (IDP des EFA-Providers). |
|
Assertion@Version: = „2.0“ |
||
Assertion@ID: UUID |
||
Assertion@IssueInstant: jetzt() – 4h < t < jetzt() |
||
Assertion/Issuer: urn:dns-name:instancename für IDP STS der Fachdienst Instanz urn:gematik:components:decentral:localauthority:telematikid:id für LocalAuthority (STS im Konnektor der LEO) url:gts-service-endpoint für GTS in der Leistungserbringer Umgebung. DARF NICHT über die TI verwendet werden! |
||
Assertion/Subject/NameID: Persönliches Identifkationsmerkmale des LE im angebebenen Format |
||
Assertion/Subject/NameID@Format: Format der persönlichen Identifkationsmerkmale des LE urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
||
Assertion/SubjectConfirmation@Method: urn:oasis:names:tc:SAML:2.0:cm:holder- of-key |
||
Assertion/SubjectConfirmation/SubjectConfirmationData/ KeyInfo/KeyValue/RSAKeyValue: holderKey |
||
Assertion/Conditions@NotBefore: t <= now() |
||
Assertion/Conditions@NotOnOrAfter: now() < t |
||
Assertion/AuthnStatement@AuthnInstant: t =< now() |
||
Assertion/AuthnStatement@SessionNotOnOrAfter: now() >= t |
||
Assertion/AuthnStatement/AuthnContext |
||
Assertion/AuthnStatement/AuthnContext/AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport UsernameToken an providerseitigem IDP urn:oasis:names:tc:SAML:2.0:ac:classes:X509 GTS Authentikation mit X509 Token urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI HBA Authentikation bei der LocalAuthority (STS im Konnektor) urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos GTS Authentikation mit Kerberos Token |
||
Assertion/AttributeStatement Das Element AttributeStatement führt mehrere verbindliche und optionale Attribute (siehe unten) welche im als zugesicherte Eigenschaften des Nutzers dessen Kontext beschreiben. Siehe auch http://wiki.hl7.de/index.php /cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes bzw. [efa2spec#247]. |
||
EFA Attribut=“HP Identifier“ Verbindlich: Ja @FriendlyName=“XSPA Subject“ @Name=“urn:oasis:names:tc:xacml:1.0:subject:subject-id“ @Values=”givenName, Surname” of the health care professional |
||
EFA Attribut=“Structural Role of the HCP“ Verbindlich: Ja @FriendlyName=“XSPA Role“ @Name=“ urn:oasis:names:tc:xacml:2.0:subject:role“ @Values=Only the ASTM structural roles “dentist”, “nurse”, “pharmacist”, “physician”, “nurse midwife”, “admission clerk”, “ancillary services”, “clinical services”, and “health records management” MUST be used. |
||
EFA Attribut=“Delegated Rights“ Verbindlich: Ja, wenn „role“ aus (“ancillary services”,“clinical services“) @FriendlyName=“OnBehalfOf“ @Name=“urn:oasis:names:tc:xacml:1.0:subject:subject-id“ @Values= Only the ASTM structural roles “dentist”, “pharmacist”, “physician”, “nurse midwife”, and “health record management” MUST be used. |
||
EFA Attribut=“Healthcare Professional Organisation“ Verbindlich: Nein @FriendlyName=“XSPA Organization“ @Name=“ urn:oasis:names:tc:xspa:1.0:subject:organization“ @Values=NameString |
||
EFA Attribut=“Healthcare Professional Organisation ID“ Verbindlich: Ja @FriendlyName=“XSPA Organization ID“ @Name=“ urn:oasis:names:tc:xspa:1.0:subject:organization-id“ @Values=OID (URN encoded) Die OID muss bei der Registrierung des EFA Teilnehmers vom EFA Provider vergeben und zu den Teilnehmerattributen im HPD registriert werden. |
||
EFA Attribut= „Purpose of Use“ Verbindlich: Nein @FriendlyName=“XSPA Purpose of Use“ @Name=“ urn:oasis:names:tc:xspa:1.0:subject:purposeofuse“ @Values=TREATMENT |
||
EFA Attribut=“Point of Care“ Verbindlich: Nein @FriendlyName=“XSPA Locality“ @Name=“ urn:oasis:names:tc:xspa:1.0:subject:locality“ @Values=““ |
||
In der EFA Community dürfen nach Bedarf weitere Attribute genutzt werden. |
||
Assertion/Signature: Signer = C.HCI.STS-SIG oder C.FD.STS-SIG |
||
Assertion/Signature/SignedInfo/CanonicalizationMethod: http://www.w3.org/2001/10/xml-exc-c14n# |
||
Assertion/Signature/Reference/Transforms/Transform Siehe [efa2-spec#246] |
||
Assertion/Signature/SignatureMethod http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 Die “Signature Method” http://www.w3.org/2000/09/xmldsig#rsa-sha1 SOLL NICHT verwendet warden. |
||
Assertion/Signature/DigestMethod: http://www.w3.org/2001/04/xmlenc#sha256 Die “Digest Method” http://www.w3.org/2000/09/xmldsig#sha1 SOLL NICHT verwendet werden. |
||
Assertion/Signature/KeyInfo: MUSS entweder ein Element SecurityTokenReference enthalten. welches mittels “SubjectKeyIdentifier” das X.509 Zertifikat des Assertion Herausgebers referenzier, oder es MUSS ein X509Data Element mit dem X.509 Zertifikat des Assertion Herausgebers enthalten. |
||
Nachbedingung |
Keine |
Tabelle 66 Ablauf Funktion validateHPIdentityAssertion
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
Prüfe Gültigkeitszeitraum |
Assertion/Conditions@NotBefore < jetzt() Assertion/Conditions/@NotOnOrAfter > jetzt() |
|
Ausgebende Stelle |
Assertion/Issuer identifiziert die ausgebenden Stelle eindeutig innerhalb der TI:
|
|
Assertion Signatur |
Prüfe die Gültigkeit der Assertion-Signatur, Die Signatur MUSS GS-A_4371 (XML-Signaturen für nicht-qualifizierte Signaturen) erfüllen. |
|
Prüfe AudienceRestriction |
Die in der AudienceRestriction ausgewiesene CommunityID muss der „CommunityID“ des adressierten Service Endpunkte entsprechen. (Keine DNS Domainname oder IP Adressen). IP ServiceEndpunkte und CommunityID einer Community werden in der TI mithilfe von DNS-SD Einträgen registriert |
|
[<=]
4.9.5 Transportsicherheit
4.9.5.1 Funktion TLSHandshakeServer – Aufbau eingehende TLS Verbindung
Diese Funktion ist in der TLS Server Komponente jeder Fachdienst Instanz verortet. Sie verarbeitet einen eingehenden Request eines TLS Client, etabliert die serverseitige TLS Session und liefert den TLS Session Handle zurück.
Das Kapitel wird in einer späteren Version des Dokumentes ggf. ausgelagert in [gemSpec_Krypt] oder [gemSpec_Kon]
4.9.5.1.1 Umsetzung
eFA2-A_2242 - Umsetzung TLSHandshakeServer
Die Implementierung der Fachdienstschnittstellen MUSS die Vorgaben für die Funktion „TLSHandshakeServer“ gemäß TLS 1.2 Spezifikation [RFC5246] sowie Tabelle 67, Tabelle 68 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 67 Übersicht Funktion TLSHandshakeServer
Name |
TLSHandshakeServer |
|
---|---|---|
Beschreibung |
Diese Funktion der TLS Server Komponente eine Fachdienst Instanz verarbeitet einen eingehenden Request eines TLS Client, etabliert die serverseitige TLS Session und liefert den TLS Session Handle zurück. Die Beschreibung fasst wesentliche Aspekte von RFC5246 zusammen und profiliert diese für die Nutzung durch EFA Fachdienst Instanzen. |
|
Auslöser |
An der Fachdienstschnittstelle in der Providerzone geht eine neue TLS Verbindungsanfrage ein, die Schnittstelle übergibt diese Anfrage an die Funktion TLSHandshakeServer. |
|
Parameter |
||
Name |
Beschreibung |
|
ClientHello Header (Version, Algo, Hash) |
TLS Version (1.2), Hash-, Verschlüsselungs- uns Kompressionsalgorithmen auf Seiten des Clients, Client Hash (Zufallswert) |
|
Client Zertifikat |
C.HCI.AUT.PuK – X.509v3 Institutionsausweis einer Leistungserbringer Organisation mit deren öffentlichen Schlüssel |
|
PreMasterSecret |
TLS Pre Master Secret verschlüsselt mit C.FD.TLS-S.PuK |
|
Handshake Data |
Sammlung aller TLS Handshake Nachrichten mit C.HCI.AUT.PrK verschlüsselt |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
ServerHello Header (Hash, Algo, SessionID) |
Server Hash (Zufallswert) Serverseitig akzeptierte Hash-, Verschlüsselungs- und Kompressionsalgorithmen TLS Session ID |
|
Server Zertifikat |
C.FD.TLS-S.PuK – X.509v3 Zertifikat der Fachdienst Instanz mit deren öffentlichen Schlüssel |
|
Handshake Data |
Sammlung aller TLS Handshake Nachrichten mit C.FD.TLS-S.PrK verschlüsselt |
|
Vorbedingung |
|
|
Nachbedingung |
|
Tabelle 68 Ablauf Funktion TLSHandshakeServer
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Verständigung auf Protokoll, Algorithmen und Austausch der Hashwerte |
Die Funktion prüft im Parametersatz: 1.: die angeforderte TLS Version. Abbruch wenn nicht TLS v1.2 2.: die Hash- und Verschlüsselungsalgorithmen gegen die Liste der zulässigen (und unterstützten) Algorithmen. Abbruch wenn keine Übereinstimmung möglich. 3.: Die Funktion merkt sich die eingegangene Nachricht mit dem Client Hash für die spätere Kalkulation des Master Secret. 4.: Die Funktion generiert den Hash eines Zufallswerts 5.: Die Funktion sendet die Liste der unterstützten Algorithmen aus 2. und den Hashwert aus 4. als ServerHash an die Gegenstelle |
2 |
Identitätsausweise austauschen (Server Auth.) |
1. Die Funktion sendet C.FD.TLS-S.PuK an die Gegenstelle. 2. Die Funktion fordert C.HCI.AUT.PuK von der Gegenstelle |
3 |
Client Identität prüfen |
1. Die Funktion erwartet C.HCI.AUT.PuK Abbruch bei Time Out 2. Prüfe das TLS Client Zertifikat C.HCI.AUT.PuK nach dessen Eintreffen gemäß TUC_PKI_018 (GS-A_4652) auf diese qualifizierten Inhalte: { certificate = C.HCI.AUT; qualifiedCheck = not_required; offlineAllowNoCheck = false; policyList = oid_smc_b_aut; intendedKeyUsage = digitalSignature & keyEncipherment; intendedExtendedKeyUsage = id-kp-clientAuth; validationMode = OCSP } Abbruch bei Fehlern, Unstimmigkeiten. 3. Prüfe, ob das Client-Zertifikat zu einem registrierten Teilnehmer gehört (z.B. über Telematik-Id, CommonName, etc.) Abbruch bei unbekanntem Client-Zertifikat bzw. nicht registrierter Client-Identität. 4. Die Funktion nimmt den Client Hashwert und dessen Signatur des gesamten bisherigen Nachrichtenaustausches mit der Gegenstelle entgegen und prüft dessen Integrität und Authentizität |
4 |
Master Secret kalkulieren |
1. Die Funktion nimmt das Pre Master Secret (PMS) der Gegenstelle entgegen Abbruch bei Fehlern 2. Die Funktion entschlüsselt das PMS mit C.FD.TLS-S.PrK Abbruch bei Fehlern 3. Die Funktion kalkuliert das Master Secret aus PMS, Client Hashwert und Server Hashwert. |
6 |
Wechsel auf TLS Record Protocol und Abschluss |
1. Die Funktion erwartet die Signale „change cipher spec“ und „client finished“ der Gegenstelle, welche mit PMS als symmetrischem Schlüssel verschlüsselt sein müssen. Abbruch bei Time Out oder Fehlern 2. Die Funktion sendet die mit PMS verschlüsselten Signale „change cipher spec“ und „server finished“ an die Gegenstelle. 3. Die Funktion liefert den mit PMS symmetrisch verschlüsselten Handle (SessionID) des erfolgreich etablierten Kommunikationskanals zurück an den Aufrufer. |
[<=]
4.9.5.1.2 Nutzung Funktion TLSHandshakeServer
Siehe Kapitel 4.9.5.2 unten.
4.9.5.2 Funktion TLSHandshakeClient – (Nutzung TLSHandshakeServer)
Diese Funktionsbeschreibung analog zu TLSHandshakeServer vermittelt exemplarisch den Aufbau einer TLS 1.2 Verbindung eines Clients (Fachmodul EFA im Konnektor) mit einer Fachdienst Instanz in der Provider Zone.
Zum Aufbau eines sicheren Kommunikationskanals mit einer EFA Fachdienst Instanz nach [RFC5246] sendet der Client die Nachricht „TLS ClientHello“ an die TLS Server Instanz und absolviert folgend die in [RFC5246] beschrieben Schritte um lokal eine TLS Client Session mit der entsprechenden Session auf der Serverseite zu etablieren.
4.9.5.2.1 Umsetzung
eFA2-A_2243 - Umsetzung TLSHandshakeClient
Die Implementierung der EFA Fachdienst Clients in der TI MUSS die Vorgaben für die Funktion „TLSHandshakeClient“ gemäß TLS 1.2 Spezifikation [RFC5246] Tabelle 69, Tabelle 70 und Tabelle 82: Fehlermeldungen EFA implementieren:
Tabelle 69 Übersicht Funktion TLSHandshakeClient
Name |
TLSHandshakeClient |
|
---|---|---|
Beschreibung |
Diese Funktion der TLS Client Komponente im Zugriff des EFA Fachmoduls sendet einen TLS Request an den TLS Server, behandelt den TLS Handshake bis zur Etablierung der TLS Session und verwaltet die Clientseitige Session mindestens bis zu deren Abkündigung durch das EFA Fachmodul. Die Beschreibung fasst wesentliche Aspekte von RFC5246 für die Nutzung durch das EFA Fachmodul und EFA Fachdienst Instanzen zusammen. |
|
Auslöser |
Eine Operation des EFA Fachmoduls erfordert eine TLS Verbindung mit einer EFA Fachdienst Instanz in der Provider Zone. |
|
Parameter |
||
Name |
Beschreibung |
|
Serveradresse |
IP Adresse und Port der gewünschten Gegenstelle |
|
Optional: Algo |
Optional: Hash-, Verschlüsselungs- uns Kompressionsalgorithmen auf Seiten des Clients. Diese sollen durch die Konfiguration der TLS Client Implementierung im Konnektor vorgegeben werden. |
|
Client Zertifikat |
C.HCI.AUT.PuK – X.509v3 Institutionsausweis einer Leistungserbringer Organisation mit deren öffentlichen Schlüssel. Dies soll i.d.R. ein gültiger CardHandle auf eine SMC-B sein. |
|
Rückgabe |
||
Name |
Beschreibung |
|
Status |
Enthält den Ausführungsstatus der Operation |
|
SessionID |
TLS Session ID |
|
Vorbedingung |
|
|
Nachbedingung |
|
Tabelle 70 Ablauf Funktion TLSHandshakeClient
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1 |
Verbindungsaufbau |
1. Verbindungsaufbau zum Server (Address:Port) Abbruch bei Fehlern |
2 |
Verständigung auf Protokoll, Algorithmen und Austausch der Hashwerte |
1. Sende Nachricht ClientHello ( Version 1.2, Algorithmen, ClientHash) 2. Erwarte Nachricht ServerHello Abbruch bei Time Out Die Funktion nimmt die ServerHello Nachricht entgegen, legt die zu nutzenden Algorithmen fest und speichert den ServerHash in den Sitzungsdaten. |
3 |
Server Identität prüfen |
1. Erwarte Nachricht Certificate mit dem Server Zertifikat C.FD.TLS-S.PuK. Abbruch bei Time Out 2. Prüfe das TLS Server Zertifikat C.FD.TLS-S.PuK nach dessen Eintreffen gemäß TUC_PKI_018 (GS-A_4652) auf diese qualifizierten Inhalte: { certificate = C.FD.TLS-S; qualifiedCheck = not_required; offlineAllowNoCheck = false; policyList = oid_fd_tls_s; intendedKeyUsage = digitalSignature & keyEncipherment; intendedExtendedKeyUsage = id-kp-serverAuth; validationMode = OCSP } Abbruch bei Fehlern, Unstimmigkeiten. 3. Erwarte die Nachricht CertificateRequest Abbruch bei Time Out 4. Erwarte die Nachricht ServerHelloDone Abbruch bei Time Out |
4 |
Client Identität übermitteln und beweisen |
1. Sende Nachricht Certificate mit C.HCI.AUT.PuK an die Gegenstelle Abbruch bei Fehler 2. Sende Nachricht CertificateVerify an die Gegenstelle, Hash über alle bis hier ausgetauschten Nachrichten mit C.HCI.AUT.PrK verschlüsselt. Abbruch bei Fehler |
5 |
Sitzungsschlüssel übermitteln |
1. Generiere den Sitzungsschlüssel (PMS), verschlüssele ihn mit C.FD.TLS-S.Pub. 2. Sende Nachricht ClientKeyExchange mit dem Sitzungsschlüssel an die Gegenstelle Abbruch bei Fehler |
6 |
Sitzungsaufbau Client abschließen |
1. Kalkuliere Master Secret (MS) aus ClientHash, ServerHash und PMS. 2. Sende Nachricht „ChangeCipherSpec“ mit MS verschlüsselt. (Zeigt an das der Client von nun an mit den vereinbarten Optionen und Schlüsseln kommuniziert) 2. Sende Nachricht ClientFinished, mit dem Hashwert über alle bis hier ausgetauschten Nachrichten, verschlüsselt mit dem Sitzungsschlüssel MS. |
7. |
1. Erwarte die mit MS verschlüsselte Nachricht „ChangeCipherSpec“ Abbruch bei Time Out oder Fehler 2. Erwarte die mit MS verschlüsselte Nachricht ServerFinished“, die SessionID der TLS Verbindung auf der Serverseite enthaltend. Abbruch bei Time Out oder Fehler |
|
8. |
Rückgabe, Ende |
1. SessionID zurück an den Aufrufer geben. |
[<=]
eFA2-A_2136 - Zuordnung EFA-Fachdienste Service Endpunkt zu TLS Server Zertifikat
Einem Service Endpunkt der EFA-Fachdienste einer EFA Community in der TI MUSS genau ein TLS Zertifikat der TI zugeordnet SEIN. Mindestens ein SubjectAlternativeName des TLS Zertifikats MUSS auf den DNS Domainname des Service Endpunktes ausgestellt SEIN.
[<=]eFA2-A_2137 - Zuordnung TLS Server Zertifikate zu EFA-Fachdienste Service Endpunkten
Das TLS Serverzertifikat einer EFA Fachdienst Instanz eines Anbieters KANN für mehrere EFA-Fachdienst Instanzen dieses Anbieters verwendet werden. Denn die EFA-Fachdienste der jeweils betriebenen EFA Community werden vom selben Betreiber gestellt.
[<=]eFA2-A_2142 - TLS1.2 mit Serverauthentisierung an EFA Service Endpunkten
Die Service Endpunkte der EFA-Fachdienste MÜSSEN bei der Datenkommunikation dem EFA Fachmodul das Protokoll TLS1.2 mit Serverauthentisierung gewährleisten.
[<=]eFA2-A_2143 - Zertifikat für TLS Serverauthentisierung von EFA Service Endpunkten
Die Service Endpunkte der EFA-Fachdienste MÜSSEN für die TLS1.2 Serverauthentisierung das TI Zertifikat C.FD.TLS-S verwenden.
[<=]eFA2-A_2145 - TLS1.2 mit Clientauthentisierung an EFA Service Endpunkten
Die Service Endpunkte der EFA-Fachdienste MÜSSEN bei der Datenkommunikation mit dem EFA Fachmodul aus der Secure Consumer Zone das Protokoll TLS1.2 mit Clientauthentisierung gewährleisten.
[<=]eFA2-A_2148 - Validierung der TSL
Die Service Endpunkte der EFA-Fachdienst Instanzen in der TI MÜSSEN „GS-A_4648 TUC_PKI_019: Prüfung der Aktualität der TSL“ umsetzen.
[<=]eFA2-A_2149 - Verifikation des TLS Client Zertifikates
Beim Aufbau der TLS-Verbindung durch das Fachmodul EFA MUSS jede EFA-Fachdienst Instanz das vorgelegte Zertifikat (C.HCI.AUT) gemäß „GS-A_4652 TUC_PKI_018: Zertifikatsprüfung in der TI“ prüfen.
[<=]4.9.6 Dienstlokalisierung
Zur Erleichterung der Konfiguration der Fachanwendungskomponenten bei den EFA-Teilnehmern wird die Lokalisierung der EFA-Fachdienste mittels DNS Service Discovery nach [RFC 6763] unterstützt.
Die Signatur Zertifikate des Policy Provider und – falls eingesetzt - des providerseitigen Identity Provider müssen in der TI verfügbar gemacht werden um deren Import in den Truststore des jeweiligen allgemein „assertion consumers“ (hier: FM EFA) zu unterstützen.
Zwecks Bereitstellung dieser Zertifikate wird der DNS-SD Eintrag der EFA-Community Instanz je Signatur Zertifikat um einen DNS Resource Record vom Typ Cert gemäß [RFC4398] ergänzt.
eFA2-A_2194 - EFA2, Bereitstellung von DNS Resource Records für DNS-SD
Der EFA Anbieter MUSS für jede EFA-Fachdienst Instanz DNS Resource Records vom Typ SRV, TXT und PTR im Namensraum der TI verwalten.
Wenn die sog. DNS-SD Service Domain „efa“ nicht durch den Anbieter des EFA-Fachdienst selbst verwaltet wird, erfolgt der Betrieb dieser Zone beim Anbieter des Namensdienstes und die Resource Records müssen an den Anbieter des Namensdienstes zur Eintragung in die Nameserverkonfiguration übergeben werden.
Der Anbieter MUSS den SRV Resource Record gemäß Tabelle 71 bereitstellen:
Tabelle 71 Tab_EFA2_SRV-RR
Feld |
Max. Länge [Byte] |
Wert |
Beschreibung |
Service Instance Name |
63 |
Eindeutiger Name der EFA-Fachdienst Instanz innerhalb der Domäne „servicedomain-servicename“ in der TI Providerzone. Dieser wird bei der Inbetriebnahme des Fachdienstes im Rahmen des im Betriebskonzept im Detail zu regelnden Freigabeprozesses durch die gematik registriert. |
|
Service Name |
15 |
efa2 |
Der Name des Services, „efa2“ ist ein fixer Vorgabewert der TI. |
Service Domain |
64 |
efa |
Die Subdomain des Services, „efa“ ist ein fixer Vorgabewert der TI |
Parent Domain |
telematik. |
„telematik.“ ist die fix vorgegebene „top level domain“ der TI. |
|
Service Priority |
2 |
0 |
Empfohlener Vorgabewert |
Service Weight |
2 |
0 |
Empfohlener Vorgabewert |
Service Port |
2 |
443 |
Empfohlener Vorgabewert |
Service Target |
DNS FQDN der EFA-Fachdienst Instanz in der TI Providerzone |
Tabelle 72 Tab_EFA2_PTR-RR
Feld |
Inhalt |
NAME |
_efa2._tcp.efa.telematik. |
PTRDNAME |
{Service Instance Name}._tcp.efa.telematik. |
Tabelle 73 Tab_EFA2_TXT-RR
key |
Value |
typ |
Beschreibung |
txtvers |
1 |
int |
Obligatorisch: Service Version nach GS-A_4810, initialer Vorgabewert = 1 |
id |
[A-Fa-f0-9]{16} |
urn:uuid |
Obligatorisch: In der TI eindeutige ID der Fachdienst Instanz (=CommunityID) welche bei der Zulassung der Instanz durch die gematik vergeben wird. Die UUID ist als „IDRef“ mit der OID verknüpft, sie SOLL aus der OID generiert werden. |
oid |
urn:oid |
Obligatorisch: In der TI eindeutige ID der Fachdienst Instanz (=CommunityID) welche bei der Zulassung der Instanz durch die gematik vergeben wird. |
|
bspath |
„/“ |
pathexpr |
Obligatorisch: Pfad der Fachdienst Business Services. Vorgabewert ist „/“. |
remurl |
„/“ |
url | pathexpr |
URL oder Pfad des ResourceManagers für diese Instanz. |
regurl |
„/“ |
url | pathexpr |
URL oder Pfad der DocumentRegistry für diese Instanz. |
repurl |
„/“ |
url | pathexpr |
URL oder Pfad zur WSDL des DocumentRepository für diese Instanz. |
idpurl |
url | pathexpr |
Optional: URL oder Pfad des Identity Providers für diese Instanz. Ist kein IDP vorgesehen ist dieser Eintrag leer oder nicht vorhanden. |
|
popurl |
url | pathexpr |
Obligatorisch: URL oder Pfad des Policy Providers für diese Instanz. Ist kein Policy Push vorgesehen ist dieser Eintrag leer oder nicht vorhanden. |
|
hpdurl |
url | pathexpr |
Obligatorisch: URL oder Pfad des HPD Services für diese Instanz. Ist kein HPD Service vorgesehen ist dieser Eintrag leer oder nicht vorhanden. |
|
pixurl |
url | pathexpr |
Optional: URL oder Pfad des PIX Services für diese Instanz. |
|
pturl |
url |
Optional: URL zu einem Web Informationsportal des EFA-Providers. Über dieses Portal kann der Prozess der Teilnehmer Registrierung angeboten werden. Ist kein Informationsportal vorgesehen ist dieser Eintrag leer oder nicht vorhanden. |
Zu jedem SRV Resource Record MUSS der Anbieter je einen CERT Resource Record gemäß [RFC4389] ]für den „Policy Provider“ und – falls vorhanden – für den „Identity Provider“ gemäß Tabelle 74 bereitstellen.
Tabelle 74: DNS CERT Resource Records für Policy und Identity Provider
Feld |
Inhalt |
name |
DNS Name der „popurl“ bzw. „idpurl“ |
type |
1 („PKIX“ , siehe [rfc4398#2.1]) |
key tag |
0 ([rfc#4398#2], Keine Kompatibilität mit DNSSEC angestrebt). |
algorithm |
0 ([rfc#4398#2], Keine Kompatibilität mit DNSSEC angestrebt). |
certificate |
Zertifikat C.FD.STS-SIG bzw. STS-ENC (PublicKeys) |
[<=]
4.9.7 Migration einer EFA-Fachdienst Instanz in die TI
Die fachlichen Funktionen der EFA-Fachdienste sollen bei einer Migration in die TI unverändert erhalten bleiben. Zugleich müssen die migrierten EFA-Fachdienste den Anforderungen der TI genügen.
Weitere Aufwände, auch bezüglich der Migration des Datenbestandes (z.B: Wechsel einer CommunityID in den Metadaten der Dokumente und Folder, Wechsel der Autor-Metadaten etc.), werden im spezifischen Migrationskonzept [gemKPT_Migr_eFA] beschrieben.
eFA2-A_2381 - Voraussetzungen zur Migration einer Fachdienst Instanz
Zum Anschluss einer EFA-Instanz an die TI MUSS der EFA Provider die Erfüllung dieser Voraussetzungen sicherstellen:
Die EFA-Fachdienste Instanz des Providers hat eine Betriebsfreigabe in der TI erhalten und ist registriert.
Die TI Softzertifikate nach Tabelle 75 stehen dem EFA-Provider zur Verwendung an den Service Endpunkten der Fachdienste Instanz zur Verfügung.
Zu jedem Service Endpunkt der EFA-Fachdienste Instanz wurden DNS Domain Namen und Hostnames definiert und in der TI registriert.
Service Instance Name, Community ID und die Service Endpunkt der zum Betrieb bereitgestellten EFA-Fachdienst Instanz sind per DNS-SD konfiguriert.
Den Service Endpunkten der EFA Community in der Provider Zone sind gültige IP-Adressen dieses Netzwerkbereiches zugewiesen und im DNS der TI registriert.
4.9.8 Registrierung von EFA-Fachdiensten
Bei der Zulassung einer EFA-Fachdienst Instanz in der TI wird ein organisatorischer Registrierungsprozess der TI durchlaufen. Dabei werden verschiedene TI Attribute und Artefakte, wie zum Beispiel Identifikationskennzeichen, Schlüsselmaterial, DNS Namen, IP Adressen und Web Service Endpunkte, erstellt, zugeordnet und ausgegeben.
4.9.8.1 ID für EFA-Provider, EFA Community
eFA2-A_2126 - Provider ID für EFA-Provider
Ein EFA-Provider als organisatorisch verantwortliche Institution SOLL in der TI durch seine eindeutige Provider ID im Format einer OID identifiziert sein.
Diese Provider ID identifiziert einen EFA Provider, keine EFA Community. Deshalb ist sie keine Community ID.
[<=]eFA2-A_2127 - Community ID (OID) für EFA Communities
Eine EFA Community MUSS in der TI durch eine eigene Community ID in Form einer „OID kodierten UUID“ identifiziert sein. Sie hat den Präfix „2.25.“ und schließt mit dem als String kodierten 128Bit Integer Wert der UUID
Die OID MUSS aus der UUID der Community generiert werden..
Die OID MUSS unter dem Key „oid“ in den DNS-SD TXT Resource Records der Community registriert sein.
[<=]
eFA2-A_2382 - Community ID (UUID) für EFA Communities
Eine EFA Community MUSS in der TI durch eine eigene Community ID in Form einer UUID identifiziert sein. Die UUID MUSS bei der Registrierung der Community in der TI generiert werden. Sie MUSS für die Generierung der Community OID verwendet werden.
Die UUID MUSS unter dem Key „id“ in den DNS-SD TXT Resource Records der Community registriert sein.
[<=]eFA2-A_2244 - Namen für EFA Communities
Eine EFA Community MUSS in der TI im DNS-SD Namensraum „efa2“ durch einen eindeutigen Namen identifiziert sein, der mit der Community ID registriert ist.
[<=]4.9.8.2 DNS Namen der EFA-Fachdienste
Die Service Endpunkte der EFA-Fachdienste werden in der URL mit ihrem FQDN adressiert. Der Domainname des FQDN soll in den verwendeten TLS Serverzertifikaten dergestalt konfiguriert sein, dass die Zertifikate neutral sind gegenüber Änderungen des Hostnamens der Service Endpunkte.
eFA2-A_2129 - In TI registrierter DNS Domainname für EFA Service Endpunkte
Der DNS Domainname aller Service Endpunkte einer EFA Community MUSS im Namensdienst der TI registriert sein.
[<=]eFA2-A_2402 - DNS Domainname für EFA Service Endpunkte
Allen Service Endpunkten einer EFA Community SOLL derselbe DNS Domainname zugewiesen sein.
[<=]eFA2-A_2403 - FQDN für EFA Service Endpunkte
Der FQDN eines Service Endpunktes KANN innerhalb der so vorgegebenen DNS Domain variieren.
[<=]eFA2-A_2130 - DNS Einträge für EFA Service Endpunkte
Die IP Adressen der Service Endpunkte einer EFA-Fachdienst Instanz MÜSSEN in der TI mittels der Schnittstelle I_DNS_Name_Resolution und dem FQDN als Parameter aufgelöst werden können.
[<=]eFA2-A_2131 - DNS Domainname in EFA-Fachdienst Server Zertifikaten
Die Anforderung „GS-A_4720 Verwendung registrierter Werte für subjectDN„ MUSS erfüllt sein.
Das Feld „Subject Alternate Name“ in den TLS Serverzertifikaten an den EFA Service Endpunkten MUSS die FQDN DNS Domainnamen der Service Endpunkte dieser EFA Community in der TI enthalten.
[<=]4.9.8.3 DNSSEC für EFA-Fachdienste
Der Download der TSL sowie die Prüfung von TI Zertifikaten erfordert die Auflösung von DNS Namen durch den DNSSEC fähigen TI Namensdienst durch die genutzten DNS Resolver der EFA-Fachdienste.
eFA2-A_2132 - DNS SEC für EFA-Fachdienste
EFA-Fachdienste, welche DNS Abfragen gegen den TI Namensdienst über die Schnittstelle „I_DNS_Name_Information“ absetzen, MÜSSEN die Anforderungen GS-A_3833 und GS-A_3840 erfüllen.
[<=]4.9.9 Kryptographisches Schlüsselmaterial in EFA-Fachdiensten
Die bei Betrieb und Nutzung der EFA-Fachdienste zur Anwendung kommenden kryptographischen Schlüssel und Zertifikate sind nachfolgend erläutert.
Im Zuge des Registrierungsprozesses einer EFA-Provider Domäne in der TI erstellt die gematik für die EFA-Fachdienst Instanz des Providers sogenannte „Softzertifikate“ mit kryptographischem Schlüsselmaterial gemäß Tabelle 75 und händigt diese einem Vertreter des EFA-Providers aus. Der EFA-Provider konfiguriert diese Schlüssel zur Nutzung in den Fachdienst Komponenten.
Bei den Softzertifikaten STS-SIG und STS-ENC handelt es sich um neuartiges, bisher in der TI nicht definiertes Schlüsselmaterial.
eFA2-A_2133 - Kryptographisches Schlüsselmaterial für EFA Fachdienste
Eine EFA Fachdienste-Instanz MUSS über einen Satz kryptographisches Schlüsselmaterial der TI gemäß Tabelle 75 verfügen, das seine in der TI registrierte und publizierte DNS Domain referenziert.
Tabelle 75 Kryptographisches Schlüsselmaterial der EFA-Fachdienste
Schlüssel |
Zweck |
Nutzung durch |
---|---|---|
C.FD.TLS-C |
TLS client authentication |
Die Komponenten ResourceManager, DocumentRegistry, DocumentRepository, Policy Provider, Identity Provider, HPD Services und PIXManager innerhalb derselben EFA-Provider Domäne authentifizieren sich mit diesem Schlüssel als Aufrufer gegenüber Diensten der TI. Die Nutzung dieses Schlüssels für Aufrufe untereinander wird empfohlen. |
C.FD.TLS-S |
TLS server authentication |
Die Komponenten ResourceManager, DocumentRegistry, DocumentRepository, PolicyProvider, IdentityProvider, HPD Services und PIXManager innerhalb derselben EFA-Provider Domäne authentifizieren sich mit diesem Schlüssel als Dienst gegenüber dem EFA Fachmodul und bei Aufrufen untereinander. |
C.FD.STS-SIG |
token signing |
Die Komponente Identity Provider nutzt den Schlüssel STS-SIG zur Signatur von Identity Assertion und den Schlüssel STS-ENC zur Verschlüsselung von Inhalten einer Identity Assertion |
C.FD.STS-ENC |
token encryption |
|
C.FD.STS-SIG |
token signing |
Die Komponente Policy Provider nutzt den Schlüssel STS-SIG zur Signatur von Subject Access Policy Assertions und den Schlüssel STS-ENC zur Verschlüsselung von Inhalten einer Access Policy Assertion. |
C.FD.STS-ENC |
token encryption |
[<=]
eFA2-A_2134 - Sichere Aufbewahrung der EFA Fachdienste TLS Schlüssel
Die privaten TLS Schlüssel der EFA Fachdienstinstanz MÜSSEN in einem sicheren Speicher aufbewahrt werden.
[<=]eFA2-A_2135 - Zugriff auf die TLS Schlüssel durch die EFA Fachdienste
Die privaten TLS Schlüssel MÜSSEN für die EFA Fachdienstinstanz zugänglich aufbewahrt werden.
[<=]Das Fachmodul EFA nutzt das in Tabelle 76 aufgeführte Schlüsselmaterial beim Aufruf der EFA-Fachdienste.
Tabelle 76 Kryptographisches Schlüsselmaterial des Fachmoduls EFA
Schlüssel |
Zweck |
Nutzung |
---|---|---|
C.HCI.AUT |
TLS client authentication |
Das Fachmodul EFA authentifiziert Aufrufe an die EFA-Fachdienste mit der Identität der Leistungserbringer Organisation. |
C.HCI.STS-SIG |
token signing |
Das Fachmodul EFA nutzt den Schlüssel STS-SIG der LEO zur Signatur von Identity Assertions und den Schlüssel STS-ENC zur Verschlüsselung von Inhalten einer Security Assertion |
C.HCI.STS-ENC |
token encryption |
|
ID.AK.AUT |
TLS server authentication |
Der Anwendungs-Konnektor authentisiert sich mit diesem Zertifikat gegenüber den EFA Client Systemen. |
Weitere Details zur technischen Ausprägung des Schlüsselmaterials liefert Tabelle 77.
Tabelle 77 Technische Ausprägung des Schlüsselmaterials
OID Ref. |
Zert.-Typ |
Typ & Länge |
Lebensdauer |
Herausgeber |
---|---|---|---|---|
oid_fd_tls_c |
C.FD.TLS-C |
R2048 |
1 Jahr |
TI |
oid_fd_tls_s |
C.FD.TLS-S |
R2048 |
1 Jahr |
TI |
oid_fd_sts_sig |
C.FD.STS-SIG |
R2048 |
1 Jahr |
TI |
oid_fd_sts_enc |
C.FD.STS-ENC |
R2048 |
1 Jahr |
TI |
oid_hci_sts_sig |
C.HCI.STS-SIG |
R2048 |
1 Jahr |
TI |
oid_hci_sts_enc |
C.HCI.STS-ENC |
R2048 |
1 Jahr |
TI |
oid_cm_tls_c |
C.CM.TLS-C |
R2048 |
1 Jahre |
LE |
2015-01: Die Bezeichner der OIDs für den STS sind seitens BTI2 nicht bestätigt.
4.9.9.1 Zusätzliche Zertifikatstypen für die EFA Fachanwendung
Zur eindeutigen Festlegung von Zertifikatstyp und spezifischer Zertifikat-Policies für die EFA-Fachanwendung gemäß [gemSpec_OID#3.5.3] MÜSSEN zusätzliche OID erzeugt werden. Diese sind in Tabelle 78 aufgeführt.
Tabelle 78 OID Festlegung für X.509v3 Zertifikatstypen der EFA Fachanwendung
OID-Referenz in anderen Dokumenten |
ProfessionItem (Beschreibung der technischen Rolle) |
ProfessionOID (OID der technischen Rolle) |
---|---|---|
Hinweis: Für EFA derzeit nicht erforderlich.
4.9.9.2 OID für technische Rollen von EFA- Fachanwendungskomponenten
Die EFA-Fachdienste nutzen Rollenprofile für das Objekt „Person“ in der HPIdentityAssertion, deren Ausprägung und Abbildung ist im Zusammenhang mit HBA und SMC_B in [gemSysL_EFA2.0] beschrieben.
Die Berücksichtigung technischer Rollen im Zusammenhang mit kryptographischen Identitäten setzt eine differenzierte Ausgestaltung von [gemSpec_OID#3.5.4] voraus. Zum Referenzieren der Rollen der EFA-Fachanwendungs-Komponenten werden OIDs der folgenden Ausprägung zur Aufnahme in gemSpec_PKI vorgeschlagen.
Tabelle 79 OIDs für technische Rollen
OID Ref. |
OID |
Beschreibung |
---|---|---|
oid_efa |
? |
EFA allgemein als Ordnungsbegriff bzw. Zweig |
oid_efa_fd_bs |
? |
EFA Business Services des Anbieters: - ResourceManager - DocumentRegistry - DocumentRepository |
oid_efa_hpd |
? |
Health Provider Directory Services |
oid_efa_pix |
? |
Patient Identity Cross Reference Manager |
oid_efa_idp |
? |
Identity Provider des Anbieters |
oid_efa_pop |
? |
Policy Provider des Anbieters |
OP: Die Bezeichner der OIDs sind seitens BTI nicht bestätigt.
4.9.10 Zeitnormal für EFA-Fachdienste
Eine Synchronisation mit den Stratum-1-NTP-Servern des TI Produkttyps Zeitdienst ist empfohlen. Siehe hierzu auch die Vorgaben des IHE Cookbook, IHE Profil „Consistent Time“.
4.9.10.1 Synchronisation mit dem TI Zeitdienst
eFA2-A_2139 - Zeitnormal für Signaturen
Die Fachdienste EFA MÜSSEN ihr Zeitnormal dergestalt mit jenem der TI synchronisieren, dass dessen Abweichung jederzeit maximal 1 (eine) Sekunde beträgt.
[<=]eFA2-A_2138 - Synchronisation mit dem TI Zeitdienst
Die EFA-Fachdienste MÜSSEN die Anforderungen [GS_A_3934] und [GS_A_4819] umsetzen.
[<=]4.9.11 TI-Plattform - nachgenutzte Schnittstellen
Die von den EFA-Fachdiensten genutzten Schnittstellen der TI sind in Tabelle 80 aufgeführt, sie sind in [gemKPT_Arch_TIP] beschrieben.
Tabelle 80 Schnittstellen des EFA-Fachdienstes zur TI-Plattform
Schnittstelle |
Operation |
benutzt durch |
---|---|---|
I_TLS |
Sicherer Datentransport mit anderen Fachdiensten und dem Fachmodul EFA |
|
I_Directory_Maintenance_FA |
CRUD von Informationen über zugelassene EFA Teilnehmer, falls ein Verzeichnisdienst der TI zur Anwendung kommt. |
|
SZZP |
Anschluss der EFA-Fachdienste über den Sicheren Zentralen Zugangspunkt an die Transportplattform des TI Netzproviders |
|
I_NTP_Time_Information |
sync_Time |
Zeitnormal der TI für die korrekte und hinreichend synchrone Zeit im Verbund verteilter, voneinander unabhängiger Dienste |
I_OCSP_Status_Information |
check_Revocation_Status |
Überprüfung des Gültigkeitsstatus von Identitäten in der TI-Plattform |
I_TSL_Download |
download_TSL |
Nachladen der Trust-Service Status List, aus dem zentralen Vertrauensraum der TI-Plattform |
5 Nicht funktionale Anforderungen
5.1 Monitoring
Relevante Monitoring Informationen der EFA-Fachdienste MÜSSEN mittels der Schnittstelle „I_Monitoring_Update“ an die TI Störungsampel übermittelt werden.
Die Schnittstelle „I_Monitoring_Update“ ist nicht ausspezifiziert. Siehe 6.1.1 unten.
Relevante Monitoring Informationen der EFA-Fachdienste sind in Tabelle 81 aufgeführt, die Tabelle stellt einen Auszug aus [gemSpec_Perf#Anhang C] (Performance Kenngrößen) dar.
Tabelle 81 An TI Störungsampel zu übermittelnde Information
Performance- Kenngröße |
Performance-Größe |
Datentyp |
Einheit |
PDT28-S01-D1-G01 |
Anzahl der Aufrufe im Erfassungszeitraum |
int |
- |
PDT28-S01-D2-G03 |
Anzahl der summierten Bearbeitungszeiten |
int |
- |
PDT28-S01-D2-G04 |
Summe der Bearbeitungszeiten in [ms] im Erfassungszeitraum |
int |
ms |
PDT28-S01-D2-G05 |
Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps |
int |
- |
PDT28-S01-D3-G10 |
Startzeitpunkt eines Ausfalls (volle Sekunden) |
time |
|
PDT28-S01-D3-G11 |
Endezeitpunkt eines Ausfalls (volle Sekunden) |
time |
5.2 Mengengerüst
Das für die Fachanwendung EFA relevante Mengengerüst ist in [gemSpec_Perf#3.1.6], „3.1.6 Lastmodell Elektronische Fallakte (eFA)“ definiert.
5.3 Verfügbarkeit
Die Anforderungen an die Verfügbarkeit der Fachanwendung EFA sind in [gemSpec_Perf#4.5] mit formuliert.
HINWEIS 2015-02-20:
In den gemSpec_perf Revisionen von \main\rel_online\216 bis \main\rel_online\224 sind Performance Angaben zu eFA enthalten, aktuelle Versionen enthalten diese Inhalte nicht, deshalb sind sie hier aufgenommen.
NEU_AFO_0000 - Performance – eFA Fachdienst – Verfügbarkeit
Der Produkttyp eFA Fachdienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.
Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]
Außerdem gelten folgende Anforderungen für das Erfassen und Reporten von Performance-Kennzahlen: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].
5.4 Performance
Die durch die EFA-Fachdienste zu erfüllenden Performance Anforderungen sind durch die Vorgaben zu Bearbeitungszeiten im Normalbetrieb sowie die Bearbeitungszeiten unter Last bestimmt.
eFA2-A_2189 - Performance - Performance-Daten erfassen
Der eFA-Fachdienst MUSS in einem konfigurierbaren Zeitintervall Performance-Daten erfassen. Voreingestellt für das Zeitintervall sind 5 Minuten.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen in [gemSpec_Perf].
[<=]eFA2-A_2190 - Performance - Störungsampel – Performance-Daten
Der Fachdienst EFA MUSS die Performance-Reporting-Daten jeweils im Zeitintervall der Erfassung an die Störungsampel senden.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen in [gemSpec_Perf].
[<=]eFA2-A_2191 - Performance - Störungsampel - Ereignisnachricht bei Ausfall
Der eFA-Fachdienst MUSS den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht innerhalb von einem Zeitraum von 10 sec an die Störungsampel senden. Der Zeitraum beinhaltet die Feststellung des Ereignisses und das Senden der Ereignisnachricht
[<=]Die „Bearbeitungszeiten eFA“ im Normalbetrieb sind in [gemSpec_Perf#3.2.3] definiert. Für Bearbeitungszeiten unter Last gilt gemäß [gemSpec_Perf#4.5] die in [GS-A_4147] vorgegebene Anforderung.
6 Offene Punkte
Dieses Kapitel wird mit dem Abschluss der Spezifikationsphase obsolet.
6.1 Verweise auf andere TI Spezifikationen
6.1.1 Schnittstelle zur TI Störungsampel
Die Schnittstelle „I_Monitoring_Update“ ist noch nicht ausspezifiziert. Auf welche Weise soll ein EFA Anbieter die geforderten Monitoring Daten an die TI Störungsampel übermitteln?
Die Fähigkeit der Fachdienste, Monitoring Daten bereitzustellen, wird als Aufgabe der Fachdienstspezifikation gesehen. Die EFA-Fachdienste stellen intrinsische Monitoring Daten in Form von Logdateien bereit, welche mit geeigneten Werkzeugen von Betrieb und Servicemanagement für die Störungsampel nachgenutzt werden können.
6.1.2 OIDs für die EFA Komponenten in gemSpec_OID
Abschnitt 4.9.9.2 verwendet Objektbezeichner, welche noch nicht in gemSpec_OID geführt werden, diese Notiz erinnert daran.
6.2 EFA-Teilnehmer Verzeichnis - Registrierung / De-Registrierung
Der Anwendungsfall „Kreis der Berechtigten einer EFA erweitern“ erfordert in der technischen Umsetzung einen Mechanismus einem Adressbuch ähnlich, um EFA-Teilnehmer nach konkreten Kriterien zu suchen und gewählte Teilnehmer eindeutig zu adressieren.
Diese Spezifikation trifft die Annahme, dass eine EFA Community ihre Teilnehmer mithilfe einer Art „elektronischem Adressbuch“ registriert und so den oben genannten Anwendungsfall unterstützt. Weiter wird angenommen, dass dieses „Adressbuch“ nicht exklusiv dem EFA Anwendungssystem zur Verfügung steht, sondern einen größeren Systemkontext mehrerer voneinander unabhängiger Anwendungen bedient.
Im Rahmen der EFA Migration in die TI muss eine übergreifende, hinreichend einfache Möglichkeit zur Adressierung von EFA TN bereitgestellt werden, Veränderungen an womöglich bestehenden „elektronischen Adressbüchern“ sollen soweit wie möglich unterbleiben.
Prämissen einer Lösung:
- Die Registrierung und De-Registrierung von EFA-Teilnehmern für eine Community ist eine Aufgabe in der Verantwortung des EFA-Providers. Sie findet mit dessen Verfahren und Werkzeugen statt. In dieser Hinsicht unterstützt eine migrierte EFA Community die Angabe einer URL eins Registrierungsportals, definiert aber nicht, wie dies ausgestaltet ist und nicht, ob und wie es genutzt wird. Die „führenden Daten“ befinden sich beim Provider.
- Ein EFA-Provider KANN zur Unterstützung des genannten Anwendungsfalles ein HPD (Health Provider Directory) bereitstellen. Ist dies konfiguriert, kann der EFA Client über das EFA Fachmodul darauf zugreifen. Das HPD enthält dann Adressierungsinformation zu den Teilnehmern dieser Community. Über das EFA Peer-to-Peer Szenario ist hiermit nichts ausgesagt.
- Ein EFA-Provider KANN zur Unterstützung des genannten Anwendungsfalles Adressierungsinformation seiner Teilnehmer über eine definierte Schnittstelle in den VZD der TI kopieren und dort verwalten. Die Schnittstelle ist in Bezug auf die Operationen „CRUD“ automatisierbar. Sind die Adressierungsinformationen der EFA TN einer Community im TI VZD verfügbar, ist kein expliziter HPD konfiguriert, der EFA Client greift über Mechanismen des Konnektors auf den VZD zu.
Dieser Aspekt ist unklar.
Ein Hersteller müsste demnach in einen Client zwei sehr verschieden zu testende Schnittstellen für dieselbe Information berücksichtigen:
A) HPD per DSML/SOAP/HTTPS mit Proxy im Fachmodul und Fachdienst-Fassade
sowie
B) VZD per LDAPS über den TI Konnektor gegen eine VZD Instanz
6.3 EFA Teilnehmer Identifikation
Stichworte:
Provider registriert TN mit OID.
TNID soll unter anderem im eGK Resource Record für die eGK - GDD - EFA Einwilligung notiert werden. Es stehen 16Byte zur Verfügung, eine UUID ist vorgesehen. Diese MUSS als ID_Reference mit der TN OID verknüpft werden. Zudem muss über den HPD mit dieser ID als Parameter die OID eines Teilnehmers ermittelt werden können.
6.4 Identifikation von Patienten (patientID)
Die Spezifikation trifft zunächst die Annahme dass dem Aufrufer von „createECR“ bereits eine providerseitige patientID vorliegt. Relevante Patienteninformation wurde vor der Anlage einer EFA im Patientenregister des Providers eingetragen.
Zur Registrierung einer lokalen patientID zu einer providerseitigen patientID wird festgelegt dass einzig die KVNR des Patienten als lokale patientID zur providerseitigen patientID hinzu registriert werden kann.
Zur Abfrage der providerseitigen patientID mithilfe der Operation getCorrespondingIdentifiersQuery werden demnach als Parameter vorrangig die KVNR und optional demographische Daten übergeben.
Dazu soll die Operation „patientActivate“ genutzt werden, sie motiviert die Neuanlage eines Patientendatensatz mit allen vom TNS übergebenen demographischen Merkmalen zum Patienten, sowie dessen KVNR.
Die Funktionsweise der – nicht im Fokus dieser Spezifikation befindlichen - Systeme hinter einer PIX Manager Schnittstelle ermöglicht die kontrollierte und selektive Übernahme der Attribute dieses neuen Datensatzes in den vorhandenen Datensatz.
6.5 Nutzung fehlererkennender Codes bei der Speicherung von EFA Daten
Die Nutzung des Schlüsselmaterials C.HCI.OSIG zur Generierung fehlererkennender Codes beim Speichern von EFA Daten kann durch einen EFA-Client erfolgen. Unabhängig davon ist jeder Fachdienstinstanz freigestellt, eigene Mechanismen zu nutzen.
6.6 Editorials
- Diagramme.
- Nutzung anderer Schnittstellen
- Schemata bereitstellen
- Nutzung des VZD durch Fachdienste (Feed von Teilnehmerinformation)
7 Anhang A - Verzeichnisse
7.1 A1 – Abkürzungen
Kürzel |
Erläuterung |
---|---|
7.2 A2 – Glossar
Begriff |
Erläuterung |
---|---|
Funktionsmerkmal |
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems. |
EFA Community |
Affinity Domain |
Affinity Domain |
IHE: Ein Netzwerk von kooperierenden Einrichtungen, in dem es festgelegte Regeln zur technischen und semantischen Umsetzung von Diensten zum Austausch medizinischer Informationen sowie zur Umsetzung von IT-Sicherheit und Datenschutz gibt, wird als Affinity Domain bezeichnet. http://wiki.hl7.de/index.php/cdaefa:EFA_Provider Der orginären Definition einer Affinity Domain durch IHE folgend wird eine Affinity Domain immer von einem EFA-Provider mit einem EFA-Peer bedient (wobei umgekehrt ein Provider auch mehrere Affinity Domains realisieren kann). Alle Einrichtungen der Affinity Domain nutzen bevorzugt die EFA-Dienste des die Affinity Domain technisch abbildenden EFA-Peers und sind mit dem entsprechenden Provider vertraglich verbunden. Die Zugehörigkeit einer Arztpraxis oder eines Krankenhauses wird somit alleine durch die vertragliche Bindung dieser Einrichtung an einen EFA-Provider bestimmt. http://wiki.hl7.de/index.php/cdaefa:EFA_Provider |
EFA-Instanz |
EFA Plattform |
EFA Plattform |
Die Dienste einer EFA Community |
EFA Peer |
Technischer Anbieter von EFA Diensten |
EFA-Provider |
Organisatorischer Anbieter von EFA Diensten |
Versorgungsdomäne |
Diametral zu der Affinity Domain ist zusätzlich jede an einer EFA teilnehmende Einrichtung auch einer oder mehreren Versorgungsdomänen zugeordnet. Hierbei handelt es sich um einen regionalen (ggf. nationalen) Zusammenschluss von Einrichtungen zur kooperativen und einheitlichen fachlichen Vorgaben folgenden Behandlung von bestimmten Patientengruppen; z.B. im Rahmen eines Trauma-Netzwerks oder eines Palliativnetzes. http://wiki.hl7.de/index.php/cdaefa:EFA_Provider |
EFA-Provider Domäne |
Eine EFA-Affinity-Domain |
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
7.3 A3 – Abbildungsverzeichnis
7.4 A4 – Tabellenverzeichnis
- Tabelle 1 Informative Textstellen der EFA Spezifikation zu den logischen Fachdiensten
- Tabelle 2 Funktionsmerkmale der EFA Business Services
- Tabelle 3 Funktionsmerkmale der EFA Security Services
- Tabelle 4 Funktionsmerkmale der EFA Supplemental Services
- Tabelle 5 Annahmen zu Größe und Anzahl elektronischer Dokumente in EFA Operationen
- Tabelle 6 EFA-Fachdienst Schnittstellen
- Tabelle 7 Schnittstelle I_eCR_Identity_Provider
- Tabelle 8 Übersicht Operation requestHPIdentityAssertion
- Tabelle 9 Ablauf Operation requestHPIdentityAssertion
- Tabelle 10 Nutzung Operation requestHPIdentityAssertion
- Tabelle 11 Schnittstelle I_eCR_Policy_Provider
- Tabelle 12 Übersicht Operation requestPolicy
- Tabelle 13 Ablauf Operation requestPolicy
- Tabelle 14 Nutzung Operation requestPolicy
- Tabelle 15 Übersicht Operation issueAccessToken
- Tabelle 16 Ablauf Operation issueAccessToken
- Tabelle 17 Nutzung der Operation issueAccessToken
- Tabelle 18 Schnittstelle I_Resource_Manager
- Tabelle 19 Übersicht Operation createPartition
- Tabelle 20 Ablauf Operation createPartition
- Tabelle 21 Nutzung der Operation createPartition
- Tabelle 22 Übersicht Operation registerConsent
- Tabelle 23 Ablauf Operation registerConsent
- Tabelle 24 Nutzung der Operation registerConsent
- Tabelle 25 Übersicht Operation createECR
- Tabelle 26 Ablauf Operation createECR
- Tabelle 27 Nutzung der Operation createECR
- Tabelle 28 Übersicht Operation closeECR
- Tabelle 29 Ablauf Operation closeECR
- Tabelle 30 Nutzung der Operation closeECR
- Tabelle 31 Übersicht Operation listPartitions
- Tabelle 32 Ablauf Operation listPartitions
- Tabelle 33 Nutzung Operation listPartitions
- Tabelle 34 Schnittstelle I_Document_Registry
- Tabelle 35 Übersicht Operation listPartitionContent
- Tabelle 36 Ablauf Operation listPartitionContent
- Tabelle 37 Nutzung Operation listPartitionContent
- Tabelle 38 Schnittstelle I_Document_Repository
- Tabelle 39 Übersicht Operation provideData
- Tabelle 40 Ablauf Operation provideData
- Tabelle 41 Nutzung Operation provideData
- Tabelle 42 Übersicht Operation retrieveData
- Tabelle 43 Ablauf Operation retrieveData
- Tabelle 44 Nutzung Operation retrieveData
- Tabelle 45 Schnittstelle I_HPD_Services
- Tabelle 46 Übersicht Operation providerInformationQuery
- Tabelle 47 Ablauf Operation providerInformationQuery
- Tabelle 48 Nutzung Operation providerInformationQuery
- Tabelle 49 Übersicht Operation providerInformationFeed
- Tabelle 50 Ablauf Operation providerInformationFeed
- Tabelle 51 Nutzung Operation providerInformationFeed
- Tabelle 52 Schnittstelle I_PIX_Manager
- Tabelle 53 Übersicht Operation getCorrespondingIdentifiersQuery
- Tabelle 54 Ablauf Operation getCorrespondingIdentifiersQuery
- Tabelle 55 Nutzung der Operation getCorrespondingIdentifiersQuery
- Tabelle 56 Übersicht Operation patientActivate
- Tabelle 57 Ablauf Operation patientActivate
- Tabelle 58 Nutzung der Operation patientActivate
- Tabelle 59 Übersicht Operation patientRevise
- Tabelle 60 Ablauf Operation patientRevise
- Tabelle 61 Nutzung der Operation patientRevise
- Tabelle 62 Allgemeine Funktionen an den Schnittstellen
- Tabelle 63 Übersicht Funktion validateWSSecurityHeader
- Tabelle 64 Ablauf Funktion validateWSSecurityHeader
- Tabelle 65 Funktion validateHPIdentityAssertion
- Tabelle 66 Ablauf Funktion validateHPIdentityAssertion
- Tabelle 67 Übersicht Funktion TLSHandshakeServer
- Tabelle 68 Ablauf Funktion TLSHandshakeServer
- Tabelle 69 Übersicht Funktion TLSHandshakeClient
- Tabelle 70 Ablauf Funktion TLSHandshakeClient
- Tabelle 71 Tab_EFA2_SRV-RR
- Tabelle 72 Tab_EFA2_PTR-RR
- Tabelle 73 Tab_EFA2_TXT-RR
- Tabelle 74: DNS CERT Resource Records für Policy und Identity Provider
- Tabelle 75 Kryptographisches Schlüsselmaterial der EFA-Fachdienste
- Tabelle 76 Kryptographisches Schlüsselmaterial des Fachmoduls EFA
- Tabelle 77 Technische Ausprägung des Schlüsselmaterials
- Tabelle 78 OID Festlegung für X.509v3 Zertifikatstypen der EFA Fachanwendung
- Tabelle 79 OIDs für technische Rollen
- Tabelle 80 Schnittstellen des EFA-Fachdienstes zur TI-Plattform
- Tabelle 81 An TI Störungsampel zu übermittelnde Information
- Tabelle 82 Fehlermeldungen EFA Fachdienste
- Tabelle 83 Eingangsanforderungen der Systemlösung mit Nachweis der Abdeckung
- Tabelle 84 Ausgangsanforderungen mit Nachweis der Erfüllung
7.5 A5 - Referenzierte Dokumente
A5.1 – Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
---|---|
[gemGlossar] |
gematik: Glossar |
[gemKPT_Arch_TIP] |
gematik: Konzept Architektur der TI-Plattform |
[gemSysL_EFA2.0] |
gematik: Systemspezifisches Konzept Migration EFA 2.0 |
[gemSpec_FM_EFA] |
gematik: Spezifikation Fachmodul EFA 2.0 |
[gemSpec_Perf] |
gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform |
[gemSpec_Net] |
gematik: Übergreifende Spezifikation Netzwerk |
[gemUeK_Sich_TI] |
gematik (02.07.2013): Übergreifendes Sicherheitskonzept der Telematikinfrastruktur |
[gemSpec_FM_GDDATD] |
gematik: Spezifikation Fachmodul GDD Anwendungstokendienst |
[gemSpec_Krypt] |
gematik (V.2.4.0): Übergreifende Spezifikation - Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur |
[gemSpec_Kon] |
gematik (V.4.7.0): Spezifikation Konnektor |
[gemKPT_Migr_eFA] |
gematik (V.0.9): Konzept zur Migration elektronischer Fallakten in die Telematikinfrastruktur |
A5.2 – Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
RFC2119 |
RFC 2119 (März 1997): Key words for use in RFCs to indicate Requirement Levels S. Bradner, http://www.ietf.org/rfc/rfc2119.txt (zuletzt geprüft am 14.12.2006) |
efa2spec |
http://wiki.hl7.de/index.php/Datei:EFAv2.0-freeze-131118.pdf |
WS-Trust |
A. Nadalin et al. (2007), WS-Trust 1.3. OASIS. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.pdf |
SOAP1.1 security |
A. Nadalin et al. (2006), Web Service Security: SOAP Message Security 1.1. OASIS. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf |
WSSE-1.0 |
SOAP Message Security 1.0 (WS-Security 2004) http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf |
WSSE-1.1.1 |
Web Services Security: SOAP Message Security 1.1.1 http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SOAPMessageSecurity-v1.1.1-os.doc |
SAML2.0 |
S. Cantor et al. (2005), Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. |
SAML2.0 bindings |
S. Cantor et al. (2005), Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf |
SAML2.0 profiles |
J. Hughes et al. (2005), Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf |
WSS SAML Token Profile 1.1 |
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf |
[WS-I Basic Security Profile 1.0] |
The Web Services Interoperability Organisation, 30.03.2007, http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html |
XACML2.0 |
T. Moses (2005), eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf |
MTOM1.1 |
W3C (2005), SOAP Message Transmission Optimization Mechanism (MTOM) Version 1.1. W3C http://www.w3.org/TR/soap12-mtom/ |
XOP |
XML-binary Optimized Packaging W3C Recommendation 25 January 2005 http://www.w3.org/TR/xop10/ |
WS-MEX |
D. Davis et al. (2011), Web Services Metadata Exchange (WS-MetadataExchange), OASIS. http://www.w3.org/TR/ws-metadata-exchange |
HL7v3 |
http://www.hl7.org/ |
IHE ITI TF Vol.3 |
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf |
IHE ITI TF Vol.2b |
IHE IT Infrastructure Technical Framework,Volume 2b (ITI TF-2b),Transactions Part B, Revision 11 – Final Text, September 23, 2014, http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf |
IHE-Cookbook |
http://wiki.hl7.de/index.php/IHE_DE_Cookbook |
IHE ITI-58, ITI-59 |
http://wiki.ihe.net/index.php?title=HPD |
eCR OT |
EFA-1.2-Spezifikation eCR Offline Token - Service Architecture |
[IHE PIXv3 Profile] |
IHE IT Infrastructure Technical Framework – Patient Identifier Cross-Reference HL7 V3 (PIXV3) and Patient Demographic Query HL7 V3 (PDQV3) Supplement |
RFC5246 |
The Transport Layer Security Protocol Version 1.2 http://tools.ietf.org/html/rfc5246 |
RFC 6763 |
DNS-Based Service Discovery http://www.ietf.org/rfc/rfc6763.txt |
RFC4398 |
Storing Certificates in the Domain Name System (DNS) http://tools.ietf.org/html/rfc4398.txt |
7.6 A7 – Fehlermeldungen
Die Tabelle richtet sich nach den Vorgaben von [gemSpec_OM#5.3.1.2].
Tabelle 82 Fehlermeldungen EFA Fachdienste
Com- ponent Type |
Code |
Code FINAL |
Error Type |
Severity |
ErrorText |
Befüllung Details |
---|---|---|---|---|---|---|
FC0001 |
Technical |
ERROR |
Fehler bei der Annahme der TLS Verbindung |
Der Detailtext SOLL den Fehler näher beschreiben. |
||
FC0002 |
||||||
FC0003 |
||||||
FC0004 |
Logical |
ERROR |
Schema- prüfung fehl- geschlagen |
Der Detailtext KANN den Fehler näher beschreiben. |
||
FC0005 |
Logical |
ERROR |
Fehler bei der Autorisierungs- prüfung |
Der Detailtext SOLL den Fehler näher beschreiben. |
||
FC0006 |
Logical |
ERROR |
Fehlende oder fehlerhafte Aufruf- parameter |
|||
FC0008 |
||||||
FC0009 |
||||||
FC0039 |
||||||
FC0040 |
Logical |
ERROR |
Kein Element "Signature" im WS-Security Header gefunden. |
|||
FC0041 |
Logical |
ERROR |
Kein oder mehrere Elemente "TimeStamp" im WS-Security Header gefunden. |
|||
FC0042 |
Logical |
ERROR |
Das Element TimeStamp weist ein ungültiges Zeitfenster aus. |
|||
FC0043 |
Logical |
ERROR |
Fehlende Signatur des TimeStamp oder fehlender Signaturschlüssel bzw. Schlüsselreferenz nicht auflösbar. |
|||
FC0044 |
Logical |
ERROR |
Nicht prüfbare Signatur des TimeStamp. |
|||
FC0045 |
Logical |
ERROR |
WS-Security- Header unvollständig (Nutzer Credential fehlt) |
|||
FC0046 |
Logical |
ERROR |
Die Signatur des TimeStamp ist ungültig. |
|||
FC0048 |
||||||
FC0050 |
Logical |
ERROR |
SAML Assertion für den Service Endpunkt {$serviceEndpunkt} in der Community {$communityID} nicht erlaubt |
|||
FC0051 |
Logical |
ERROR |
Aktuelle Zeit ${time()} nicht im Gültigkeitsfenster der SAML Assertion |
|||
FC0052 |
Logical |
ERROR |
Ausgebende Stelle ${URI} der SAML Assertion nicht erlaubt |
|||
FC0053 |
Logical |
ERROR |
Signatur der SAML Assertion ungültig |
|||
FC0059 |
||||||
FC0062 |
Logical |
ERROR |
Fehlende Signatur der Assertion |
|||
FC0063 |
Logical |
ERROR |
Ungültige Signatur der Assertion |
|||
FC0070 |
Logical |
ERROR |
Fehlerhafter oder fehlender EphemeralKey |
|||
FC0080 |
Logical |
ERROR |
Nicht vorgesehene Art der Authentifizierung ${detail_message} |
${detail_message} SOLL den Fehler näher beschreiben. |
||
request HPIdentity Assertion |
Logical |
Error |
Es sind keine Nutzeridentitäts- merkmale im RST enthalten |
|||
request HPIdentity Assertion |
Logical |
Error |
Zu den gegebenen Nutzer- identitätsmerkmalen kann keine Nutzeridentität ermittelt werden |
|||
request HPIdentity Assertion |
Logical |
Error |
Gegebene und zentral vorhandene Nutzeridentitäts- merkmale stimmen nicht überein |
|||
request HPIdentity Assertion |
Technical |
Error |
Fehler beim Ausstellen der HPIdentityAssertion |
|||
request HPIdentity Assertion |
Technical |
Error |
Fehler bei der Signatur |
|||
request HPIdentity Assertion |
Technical |
Error |
Fehler beim Versand |
|||
request Policy |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
request Policy |
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWSSecurity Header |
|||
request Policy |
Logical |
Error |
Die Identität des Aufrufers konnte anhand der HPIdentityAssertion nicht erfolgreich validiert werden. Aufrufer unbekannt. |
|||
request Policy |
Technical |
Error |
Fehler bei der Ermittlung der Access Policies |
|||
request Policy |
Technical |
Error |
Fehler bei der Signatur |
|||
request Policy |
Technical |
Error |
Fehler beim Versand |
|||
issue Access Token |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
issue Access Token |
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
|||
issue Access Token |
Logical |
Error |
Fehler bei der Erstellung des RDT |
|||
issue Access Token |
Logical |
Error |
Fehler bei der Erstellung der UUID |
|||
issue Access Token |
Technical |
Error |
Fehler beim Versand |
|||
issue Access Token |
1102 |
Logical |
Error |
Die Nachricht enthält keine Daten |
||
create Partition |
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
||
4701 |
Logical |
Error |
Ungültiges oder unerlaubtes Dokument |
|||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentisierung |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert (Siehe [efa2spec#273]). |
|||
4709 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebenen Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
register Consent |
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Anlage einer neuen Partition und /oder Registrierung neuer Berechtigter. |
||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentication |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert (Siehe [efa2spec#273]). |
|||
4709 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebenen Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
create ECR |
2201 |
Logical |
Warn |
Fallakten können bei diesem Provider nur manuell erzeugt werden. |
||
2202 |
Logical |
Warn |
Zu den Parametern existierte bereist eine Fallakte, es wurde eine neue Partition hinzugefügt |
|||
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
|||
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Anlage einer neuen Partition und /oder Registrierung neuer Berechtigter. |
|||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentication |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert (Siehe [efa2spec#273]). |
|||
4111 |
Logical |
Error |
Eine oder mehrere Teilnehmer- identitäten {OID}/HPIdentity aus dem consentInfo Dokument sind nicht bekannt. |
|||
1102 |
Logical |
Error |
Die ITI-41 Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
close ECR |
2202 |
Logical |
Warn |
Zu den Parametern existierte bereist eine Fallakte, es wurde eine neue Partition hinzugefügt |
||
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
|||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentikation |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert (Siehe [efa2spec#273]). |
|||
4709 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebenen Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die ITI-41 Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im Resource- Manager |
||||
Technical |
Error |
Fehler beim Versand |
||||
list Partitions |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
Logical |
Error |
Authentisierungs- fehler |
||||
Logical |
Error |
Autorisierungs- fehler |
||||
1102 |
Logical |
Error |
Die ITI-18 Nachricht enthält keine Daten |
|||
Logical |
Error |
Verarbeitungs- fehler im ResourceManager |
||||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
list Partition Content |
1102 |
Logical |
Error |
Unbekannte Partition |
||
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
|||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentikation |
|||
4703 |
Logical |
Error |
Authentisierungs- fehler : Unbekanntes / ungültiges Subjekt |
|||
4709 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebene Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die ITI-18 Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
register Data |
Nicht implementiert |
|||||
provide Data |
2201 |
Logical |
Warn |
Fallakten können bei diesem Provider nur manuell erzeugt werden. |
||
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
|||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentication |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert. |
|||
4107 |
Logical |
Error |
Die angelieferten Daten sind nicht im Datenformat PDF. |
|||
4109 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebenen Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die ITI-41 Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im ResourceManager |
||||
Technical |
Error |
Fehler beim Versand |
||||
retrieve Data |
4701 |
Logical |
Error |
Gemäß gültiger ConsentInfo keine Berechtigung zur Durchführung der Operation |
||
4702 |
Logical |
Error |
Authentisierungs- fehler : Schwache Authentication |
|||
4703 |
Logical |
Error |
Authentisierungs- fehler : Unbekanntes / ungültiges Subjekt |
|||
4704 |
Logical |
Error |
Das consentInfo Dokument {OID} ist nicht vom LE signiert. |
|||
4109 |
Logical |
Error |
Autorisierung nicht möglich. Eine Fallakte zum gegebenen Zweck existiert nicht für diesen Patienten. |
|||
1102 |
Logical |
Error |
Die ITI-43 Nachricht enthält keine Daten |
|||
Technical |
Error |
Technischer Fehler im Resource Manager |
||||
Technical |
Error |
Fehler beim Versand |
||||
provider Information Query |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
Logical |
Error |
Authentisierungsfehler, „bind“ Fehler |
||||
Logical |
Error |
Autorisierungs- fehler im HPD |
||||
Logical |
Error |
Der DSML Request enthält keine Daten |
||||
Logical |
Error |
Verarbeitungs- fehler im HPD |
||||
Technical |
Error |
Technischer Fehler im HPD |
||||
Technical |
Error |
Fehler beim Versand |
||||
provider Information Feed |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
Logical |
Error |
Authentisierungsfehler, „bind“ Fehler |
||||
Logical |
Error |
Autorisierungsfehler im HPD |
||||
1102 |
Logical |
Error |
Der DSML Request enthält keine Daten |
|||
Logical |
Error |
Verarbeitungsfehler im HPD |
||||
Technical |
Error |
Technischer Fehler im HPD |
||||
Technical |
Error |
Fehler beim Versand |
||||
get Corre- sponding Identifiers Query |
Logical |
Error |
Die Schemaprüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
Logical |
Error |
Authentisierungs- fehler |
||||
Logical |
Error |
Autorisierungs- fehler |
||||
1102 |
Logical |
Error |
Der Transaktions- request enthält keine Daten |
|||
Logical |
Error |
Verarbeitungs- fehler im PIX Manager |
||||
Technical |
Error |
Technischer Fehler im PIX Manager |
||||
Technical |
Error |
Fehler beim Versand |
||||
patient Activate |
Logical |
Error |
Die Schema- prüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
Logical |
Error |
Authentisierungs- fehler |
||||
Logical |
Error |
Autorisierungs- fehler |
||||
1102 |
Logical |
Error |
Der Transaktions- request enthält keine Daten |
|||
Logical |
Error |
Verarbeitungsfehler im PIX Manager |
||||
Technical |
Error |
Technischer Fehler im PIX Manager |
||||
Technical |
Error |
Fehler beim Versand |
||||
patient Revise |
Logical |
Error |
Die Schemaprüfung war nicht erfolgreich |
|||
Logical |
Error |
Der WS Security Header konnte nicht erfolgreich validiert werden, Meldung und Code aus dem Kontext validateWS SecurityHeader |
||||
4701, 4702, 4703 |
Logical |
Error |
Authentisierungs- fehler |
|||
4109 |
Logical |
Error |
Autorisierungs- fehler |
|||
1102 |
Logical |
Error |
Der Transaktions- request enthält keine Daten |
|||
Logical |
Error |
Verarbeitungs- fehler im PIX Manager |
||||
Technical |
Error |
Technischer Fehler im PIX Manager |
||||
Technical |
Error |
Fehler beim Versand |
||||
validate HPIdentity Assertion |
FC0001 |
Assertion abgelaufen / noch nicht gültig |
||||
FC0002 |
Ausgebende Stelle nicht zugelassen / bekannt |
|||||
FC0003 |
Signatur ungültig |
|||||
FC0004 |
Assertion für den ServiceEndpunkt in der Community nicht zugelassen |
|||||
TSL Handshake Server |
FC0001 |
Logical |
Error |
TLS Version nicht mindestens 1.2 mit Ausgabe der angefragten Version im Fehlertext |
||
FC0002 |
Logical |
Error |
TLS Version unbekannt (z.B. 1.3) mit Ausgabe der angefragten Version im Fehlertext |
|||
FC0003 |
Logical |
Error |
Keine kompatiblen TLS Verschlüsselungs- algorithmen angegeben mit Ausgabe angegebenen und der konfigurierten Algorithmen im Fehlertext |
|||
FC0004 |
Logical |
Error |
Abbruch des Verbindungsaufbaus durch die Gegenstelle |
|||
FC0005 |
Logical |
Error |
Kein Client Zertifikat erhalten |
|||
FC0006 |
Logical |
Error |
Client Zertifikat nicht akzeptiert (policy, keyusage, ext keyusage, …) |
|||
FC0007 |
Logical |
Error |
Client Zertifikat ungültig |
|||
FC0008 |
Logical |
Error |
Client Message Exchange Hash ungültig |
|||
FC0009 |
Logical |
Error |
Client Change CipherSpec nicht empfangen |
|||
FC0010 |
Logical |
Error |
Client Finish nicht empfangen |
|||
TLS Handshake Client |
Technical |
Error |
Server (Adresse:Port) nicht erreichbar |
|||
FC0001 |
Technical |
Error |
Time Out beim Warten auf Serverantwort {message} |
|||
FC0002 |
Logical |
Error |
Keine kompatiblen TLS Verschlüsselungs- algorithmen ermittelt mit Ausgabe Algorithmen von Client und Server im Fehlertext |
|||
FC0003 |
Logical |
Error |
Abbruch des Verbindungs- aufbaus durch die Gegenstelle |
|||
FC0004 |
Logical |
Error |
Kein Server Zertifikat erhalten |
|||
FC0005 |
Logical |
Error |
Server Zertifikat nicht akzeptiert (policy, keyusage, ext keyusage, …) |
|||
FC0006 |
Logical |
Error |
Server Zertifikat ungültig |
|||
FC0007 |
Logical |
Error |
Server Message Exchange Hash ungültig |
|||
FC0008 |
Logical |
Error |
Server Change CipherSpec nicht empfangen |
|||
FC0009 |
Logical |
Error |
Server Finish nicht empfangen |
|||
7.7 A8 – Klärungsbedarf <<optional>>
Kap. |
Offener Punkt |
Zuständig |
---|---|---|
7.8 A9 – Allgemeine Erläuterungen
8 Anhang B - Anforderungen
8.1 B1 – Eingangsanforderungen (Umsetzungsanforderungen)
Nachfolgend sind die Eingangsanforderungen aus der Systemlösung Migration EFA 2.0 aufgelistet. Eine Zuordnung zu den jeweiligen Anwendungsfällen und den sich ergebenden Ausgangsanforderungen aus diesem Dokument erfolgt in folgenden Versionen dieser Spezifikation.
Tabelle 83 Eingangsanforderungen der Systemlösung mit Nachweis der Abdeckung
AFO-ID |
Quelle |
Beschreibung |
Umgesetzt durch |
---|---|---|---|
eFA2-A_2060 |
gem_SysL_EFA2.0 |
Die TI-Plattform MUSS das Verfahren der föderierten Nutzerauthentifizierung und die Bestätigung sicherheitsrelevanter Nutzermerkmale durch Sicherheitstoken ausstellende Dienste unterstützen. |
|
eFA2-A_2061 |
Die TI-Plattform MUSS für die Funktionen von Sicherheitstoken ausstellenden Diensten einer Institution des Gesundheitswesens zum Zweck der Zusicherung sicherheitsrelevanter Merkmale erforderliches Schlüsselmaterial und X.509 Zertifikate in einem sicheren Schlüsselspeicher bereitstellen. |
||
eFA2-A_2062 |
Die Fachanwendung EFA2.0 SOLL nach der Migration die Richtwerte zur Performanz gemäß Tabelle 1: Tab_EFA2_SysL_0001 - Obergrenzen der Verarbeitungszeit und -Datenvolumen pro Anwendungsfall“ einhalten. |
||
eFA2-A_2063 |
Die TI-Plattform MUSS für alle angebundenen EFA-Client Systeme gewährleisten, dass das TLS1.2 Protokoll mit gegenseitiger, zertifikatsbasierter Authentisierung bei der Kommunikation mit dem Fachmodul EFA zum Einsatz kommt. |
||
eFA2-A_2066 |
Alle Teilkomponenten der Fachanwendung EFA2.0 MÜSSEN das Konzept der beteiligten Akteure und Rollen mit den zugehörigen Berechtigungen gemäß Tabelle 2: Tab_EFA2_SysL_0002 - Zusammenhang der strukturellen Rollen aus EFA2.0 Spezifikation, ASTM E1986-98 (2005) und TI-Plattform und Tabelle 3: Tab_EFA2_SysL_0003 - Rollen und Berechtigunsmatrix der EFA-Nutzer-Aktionen“ einhalten. <Tabelle> Tabelle 2: Tab_EFA2_SysL_0002 - Zusammenhang der strukturellen Rollen aus EFA2.0 Spezifikation, ASTM E1986-98 (2005) und TI-Plattform <Tabelle> Tabelle 3: Tab_EFA2_SysL_0003 - Rollen und Berechtigunsmatrix der EFA-Nutzer-Aktionen |
||
eFA2-A_2067 |
Produktanbieter von EFA2.0-Teilnehmersystemen (eCR-Consumer/eCR ContextManager) und EFA-Provider MÜSSEN alle Kommunikationsmuster der EFA2.0 Spezifikation umsetzen. |
||
eFA2-A_2068 |
Produktanbieter von EFA2.0-Teilnehmersystemen (eCR-Consumer/eCR ContextManager) und EFA-Provider MÜSSEN bei EFA2.0 konforme Produkte nach erfolgter Migration in die TI den EFA-Nutzern denselben Funktionsumfang bieten, wie im Ausgangszustand vor der Migration. |
||
eFA2-A_2069 |
Die Leistungserbringerinstitution in der Rolle als EFA-Teilnehmer KANN ein lokales Nutzerverwaltungssystem (IAM) betreiben, mit dessen Hilfe die Authentifizierung eines EFA-Nutzers und die Anwendungsberechtigung dieses Nutzers vom Fachmodul EFA gemäß WS-Trust Standard geprüft werden kann. |
||
eFA2-A_2070 |
Das Fachmodul EFA MUSS es dem Administrator der teilnehmenden Leistungserbringer Institution ermöglichen, ein oder mehrere Provider-Konfigurationen zu hinterlegen. |
||
eFA2-A_2071 |
Das Fachmodul EFA MUSS es dem Administrator der teilnehmenden Leistungserbringer Institution ermöglichen, für jeden Mandanten ein oder mehrere EFA-Teilnehmer-Konfigurationen zu hinterlegen. |
||
eFA2-A_2072 |
Ein EFA-Provider MUSS die Anforderungen der EFA2.0 Spezifikation und der implizit gültigen Anforderungen darin verwendeter Spezifikationen (z.B. IHE IT-Infrastructure Profile „AuditTrail and Node Authentication“) im Kontext der Verarbeitung von AuditLog Daten erfüllen. |
||
eFA2-A_2073 |
Die Erfüllung der Anforderung ist nur organisatorisch erreichbar, z.B. - durch Schulung der Anwender, EFA-Teilnehmer / teilnehmende LE-Institution, - Nutzungsrichtline für EFA-Teilnehmer / teilnehmende LE-Institution, - Vorgaben zu Formaten und Inhalten von in der EFA eingestellten Dokumenten, - Vorgaben für EFA-Teilnehmer / teilnehmende LE-Institution bei föderierter Nutzerauthentifizierung (GTS), - Vertragliche Vereinbarungen zwischen EFA-Teilnehmer / teilnehmende LE-Institution und Provider |
||
eFA2-A_2074 |
Entfällt im Single-Peer Szenario |
||
eFA2-A_2075 |
Die Fachanwendung EFA2.0 MUSS die logischen Klassenobjekte gemäß Abb_EFA2_SysL_0037 „Klassendiagramm zum Sicherheitskontext der EFA2.0 Spezifikation“ umsetzen. |
||
eFA2-A_2076 |
Der Verwendungszweck des Schlüsselmaterials für Sicherheitstoken ausstellende Dienste ist auf die Signatur bzw. die Verschlüsselung von Sicherheitstoken beschränkt, die von einem derartigen Dienst erzeugt wurden. Die TI MUSS sicherstellen, dass dieses Schlüsselmaterial zu keinem anderen Zweck verwendet werden kann. |
||
eFA2-A_2077 |
Die TI-Plattform MUSS das Schlüsselmaterial von Sicherheitstoken ausstellenden Diensten dem sehr hohen Schutzbedarf entsprechend schützen und den unautorisierten Zugriff auf das Schlüsselmaterial verhindern. |
||
eFA2-A_2078 |
Die Zertifizierungsdiensteanbieter der TI MÜSSEN sicherstellen, dass kryptographische Identitäten (X.509 Zertifikate) von Sicherheitstoken ausstellenden Diensten einer Institution des Gesundheitswesens die Telematik ID dieser Institution enthalten, wenn dieser Dienst in der TI angeboten wird. |
||
eFA2-A_2079 |
Die TI MUSS sicherstellen, dass die technische Komponente Sicherheitstoken ausstellender Dienst nach erfolgreicher Aktivierung durch einen autorisierten Administrator verfügbar ist. |
||
eFA2-A_2080 |
Die TI-Plattform MUSS sicherstellen, dass das Fachmodul EFA das Client Zertifikat oder eine eindeutige Referenz des Client Zertifikats (Fingerprint) erhält, mit dem eine TLS1.2 Session zum Fachmodul EFA mit gegenseitiger zertifikatsbasierter Authentisierung erfolgreich aufgebaut wurde. |
||
eFA2-A_2081 |
Die TI-Plattform MUSS einem lokalen IT-Administrator einer Institution des Gesundheitswesens in der Rolle EFA-Teilnehmer eine Möglichkeit zur Erzeugung lokal prüfbarer Zertifikate im PKCS#12 Format bereitstellen. Im Kontext der Anwendung EFA2.0 sind dies X.509v3 Zertifikate und zugehörige private Schlüssel für EFA-Client Systeme. |
||
eFA2-A_2197 |
Ein Dienstanbieter der Fachanwendung EFA2.0 in der TI MUSS die Fachanwendung EFA2.0 innerhalb einer sicheren Leistungserbringer-Umgebung betreiben. |
||
eFA2-A_2198 |
Das Fachmodul EFA MUSS das Einstellen und Abrufen von Dokumenten einer Fallakte ohne Größenbeschränkung durch eine Stream orientierte Verarbeitungsweise unterstützen. |
||
eFA2-A_2199 |
Nach erfolgter Aktivierung durch den autorisierten Admin DARF eine erneute Aktivierung NICHT erforderlich sein, selbst wenn die Laufzeitumgebung der technischen Komponente Sicherheitstoken ausstellender Dienst gestoppt bzw. neu gestartet wird. |
||
eFA2-A_2200 |
Ein EFA-Provider in der TI MUSS ein Schulungskonzept für seine Mitarbeiter und seine EFA-Teilnehmer bereitstellen zur Wahrung des Schutzbedarfs von maximal „hoch“ gemäß BSI-Grundschutz bei der Nutzung der EFA2.0 Anwendung. |
||
eFA2-A_2201 |
Ein EFA-Provider in der TI MUSS die Durchführung der Schulungsmaßnahmen für seine Mitarbeiter und seine EFA-Teilnehmer sicherstellen und schriftlich dokumentieren. |
||
eFA2-A_2202 |
Die TI-Plattform MUSS X.509v3 Zertifikate und zugehörige private Schlüssel für EFA-Client Systeme so bereitstellen, dass diese kryptographischen Identitäten in vorhandene Systeme der lokalen Umgebung (EFA2.0 Client) durch einen Administrator sicher eingebracht werden können. |
||
eFA2-A_2203 |
Produktanbieter von EFA2.0-Teilnehmersystemen (eCR-Consumer/eCR ContextManager) und EFA-Provider MÜSSEN die Konformität zur EFA2.0 Spezifikation durch eine Hersteller-Konformitätserklärung des EFA-Vereins belegen. |
||
eFA2-A_2204 |
Das Fachmodul EFA MUSS für die Provider-Konfiguration an der Adminschnittstelle folgende Parameter übergeben können: - ProviderID (TI weit eindeutige Identifikation des EFA2.0 Dienstanbieters = community ID) - Provider Name - Service Endpunkt URLs des Fachdienstes |
||
eFA2-A_2205 |
Das Fachmodul EFA MUSS für die EFA-Teilnehmer-Konfiguration an der Adminschnittstelle folgende Parameter übergeben können: - Provider-Konfiguration ID (communityID) - Identifikator der zu verwendenden SMC-B (Identität des Zertifikats SMC-B STS-AUT bzw. Telematik ID) - PIN der SMC-B STS-AUT - Optional: Identität (Signatur Zertifikat) des lokal verwendeten GuarantorTokenServers (C.FD.STS-AUT) - Client-Zertifikate der lokal eingerichteten EFA-Clients |
||
eFA2-A_2206 |
Der EFA-Providers MUSS das AuditLog im Rahmen einer Auditierung des Dienstanbieters konsistent, maschinenlesbar und integer bereitstellen können. |
||
eFA2-A_2207 |
Die Umsetzung wird in der Spezifikation der elektronischen Fallakte (EFA2) beschrieben. Diese Spezifikation wird vom Verein 'elektronische FallAkte e.V.' und Fraunhofer FOKUS verantwortet. |
||
eFA2-A_2247 |
Das Fachmodul FM-EFA MUSS zur Verbindung mit dem Fachdienst FD-EFA TLS1.2 mit gegenseitiger zertifikatsbasierter Authentisierung unter Nutzung des SMC-B AUT Zertifikats (TLS-Client) und des Provider-Zertifikats ID.FD.TLS-S (TLS-Server) verwenden und eine Transport-Sicherheit Bindung mit SAML 2.0 HoK über SSL gemäß WS-Trust etablieren. |
||
eFA2-A_2309 |
ITS/AM: * Methodik-Konzept Die Methodik-Konzepte beschreiben keine Anforderungen. |
||
eFA2-A_2310 |
Die Anforderungen sind nicht relevant / obsolete. |
8.2 B2 – Ausgangsanforderungen (Blattanforderungen)
Nachfolgend sind die Ausganganforderungen aus dieser Spezifikation aufgelistet.
Tabelle 84 Ausgangsanforderungen mit Nachweis der Erfüllung
AFO-ID |
Beschreibung |
erfüllt |
eFA2-A_2126 |
Ein EFA-Provider als organistorisch verantwortliche Institution MUSS in der TI durch seine eindeutige Telematik ID identifiziert sein. |
|
eFA2-A_2127 |
Eine EFA-Affinity-Domain KANN in der TI durch eine eigene Telematik ID identifiziert sein. |
|
eFA2-A_2128 |
Ein EFA Peer als Daten verarbeitender Dienstleister MUSS in der TI durch seine eindeutige Telematik ID identifiziert sein. |
|
eFA2-A_2129 |
Der DNS Domainname der Service Endpunkte einer EFA-Affinity-Domain MUSS im Namensdienst der TI registriert sein. Allen Service Endpunkten einer Affinity Domains SOLL soll der selbe DNS Domainname zugewiesen sein |
|
eFA2-A_2130 |
Die IP Adressen der Service Endpunkte einer EFA-Fachdienst Instanz MÜSSEN in der TI mittels der Schnittstelle I_DNS_Name_Resolution und den FQDN als Parameter aufgelöst werden können. Service Endpunkte aus verschiedener EFA-Affinity-Domains MÜSSEN durch verschiedene DNS Namen unterschiedbar sein. Einzelne Fachdienste einer Affinity Domain KÖNNEN verschiedenen DNS Domains zugeordnet sein. |
|
eFA2-A_2131 |
Die Anforderung „GS-A_4720 Verwendung registrierter Werte für subjectDN„ MUSS erfüllt sein. Das Feld „Subject Alternate Name“ in den TLS Serverzertifikaten an den EFA Service Endpunkte MUSS die FQDN DNS Domainnamen der Service Endpunkte dieser Affinity Domain der EFA-Providers in der TI enthalten. |
|
eFA2-A_2132 |
EFA-Fachdienste, welche DNS Abfragen gegen den TI Namensdienst über die Schnittstelle „I_DNS_Name_Information“ absetzten, MÜSSEN die Anforderungen GS-A_3833 und GS-A_3840 erfüllen. |
|
eFA2-A_2133 |
Im Zuge des Registrierungsprozesses wird dem EFA Peer für die betriebenen Fachdienste jeder Affinity Domain kryptographisches Schlüsselmaterial aus der PKI der TI mit konkretem Verwendungszweck gemäß Tabelle 5 zugewiesen. <Tabelle> Tabelle 5: Kryptographisches Schlüsselmaterial der EFA-Fachdienste Ein EFA Peer MUSS für die EFA-Fachdienste einer Affinity Domain über einen Satz kryptographisches Schlüsselmaterial der TI verfügen, das seine in der TI registrierte und publizierte DNS Domain referenziert. Die Schlüssel C.FD.TLS* dienen dem sicheren Datentransport von und zu den Fachdiensten. Ein Satz Schlüssel C.FD.STS* dient der Signatur und Verschlüsselung von Sicherheitstoken für den Anwendungszugriff durch die Komponente EFA Identity Provider bzw. EFA Policy Provider. |
|
eFA2-A_2134 |
Die privaten TLS Schlüssel der EFA-Fachdienste einer Affinity Domain müssen in einem sicheren Speicher aufbewahrt werden. |
|
eFA2-A_2135 |
Die privaten TLS Schlüssel müssen für die EFA-Fachdienste der Affinity Domain zugänglich aufbewahrt werden. |
|
eFA2-A_2136 |
Einem Service Endpunkt der EFA-Fachdienste einer Affinity Domain in der TI MUSS genau ein TLS Zertifkat aus der PKI der TI zugeordnet sein. Das TLS Zertifikat ist auf den DNS Domainname des Service Endpunktes ausgestellt. |
|
eFA2-A_2137 |
Das TLS Serverzertifikat eines EFA Peers DARF für mehrere EFA-Fachdienst Instanzen dieses Peers verwendet werden. Denn die EFA-Fachdienste der jeweils betriebenen Affinity Domains werden vom selben Betreiber gestellt. |
|
eFA2-A_2138 |
Die EFA-Fachdienste MÜSSEN die Anforderungen [GS_A_3934] und [GS_A_4819] umsetzen. |
|
eFA2-A_2139 |
Die Fachdienste EFA müssen ihr Zeitnormal dergestalt mit jenem der TI synchronisieren, dass dessen Abweichung jederzeit maximal 1 (eine) Sekunde beträgt. |
|
eFA2-A_2140 |
Die Service Endpunkte der EFA-Fachdienste einer Affinity Domain MÜSSEN die Protokollierung von Datenzugriffen aus der TI gemäß IHE ATNA umsetzen. |
|
eFA2-A_2141 |
Kann im Rahmen der Validierung eines EFA-Fachdienst Aufrufs einer oder mehrere der formulierten Anforderungen nicht erfüllt werden MUSS die Prüfung und Verarbeitung mit einer Fehlermeldung abgebrochen werden. |
|
eFA2-A_2142 |
Die Service Endpunkte der EFA-Fachdienste aus Tabelle 4 MÜSSEN bei der Datenkommunikation mit EFA Clients aus der Consumer Zone das Protokoll TLS1.2 mit Serverauthentisierung gewährleisten. |
|
eFA2-A_2143 |
Die Service Endpunkte der EFA-Fachdienste aus Tabelle 4 MÜSSEN für die TLS1.2 Serverauthentifikation das TI Zertifikat C.FD.TLS-S verwenden. |
|
eFA2-A_2148 |
Die Service Endpunkte der EFA-Fachdienst Instanzen in der TI MÜSSEN „GS-A_4648 TUC_PKI_019: Prüfung der Aktualität der TSL“ umsetzen. |
|
eFA2-A_2149 |
Beim Aufbau der TLS-Verbindung durch das Fachmodul EFA MÜSSEN die EFA-Fachdienste das vorgelegte Zertifikat (C.HCI.AUT) gemäß „GS-A_4652 TUC_PKI_018: Zertifikatsprüfung in der TI“ prüfen |
|
eFA2-A_2150 |
Erfolgt ein EFA-Fachdienst Aufruf mit Client Authentisierung nach „SAML2.0 Bearer über TLS“ MUSS als Zertifikat des Client Zertifikat der TLS1.2 Kommunikation (C.HCI.AUTH) verwendet werden. Anforderung an FD EFA klären: TLS Client Zertifikat Attribute im Request Header verfügbar machen. . |
|
eFA2-A_2151 |
Erfolgt ein EFA-Fachdienst Aufruf mit Client Authentisierung nach „SAML2.0 holder-of-key über TLS“ MUSS der TimeStamp Security Header des Requests vorhanden und mit dem lokalen Schlüssel des EFA-Client signiert sein, der in der mit C.HCI.AUTH oder C.FD.STS-AUTH signierten SAML-Assertion des Requests enthalten ist. |
|
eFA2-A_2152 |
Jeder gültige EFA-Fachdienst Aufruf ist als SOAP Request formuliert und MUSS ein WS Security Header Element gemäß [WSSE-1.0] enthalten. |
|
eFA2-A_2153 |
Jeder gültige EFA-Fachdienst Aufruf MUSS im Security Header eine SAML Assertion enthalten, die mit dem Schlüssel aus [XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/ds:Signature/ds:KeyInfo/ds:X509Data/ds:X509Certificate signiert ist. |
|
eFA2-A_2154 |
Eine gültige SAML Assertion im Security Header eines EFA-Fachdienst Aufrufes MUSS als „SubjectConfirmation Method“ unter [XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/@Method entweder „urn:oasis:names:tc:SAML:2.0:cm:holder-of-key“ oder „urn:oasis:names:tc:SAML:2.0:cm:bearer“ referenzieren. |
|
eFA2-A_2155 |
Ein TimeStamp im Security Header eines EFA-Fachdienstaufrufs MUSS mit dem Schlüssel/dem Zertifkat unter [XPATH] soap:Envelope/soap:Header/wsse:Security/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/saml2:SubjectConfirmationData/ds:KeyInfo/ds:KeyValue/ds:RSAKeyValue signiert sein. Bei ungültiger Signatur MUSS der Request abgewiesen werden. |
|
eFA2-A_2156 |
Die Schnittstelle MUSS bei Aufrufen aus der TI durch EFA-Clients SOAP Requests gemäß EFA 2.0 Spezifikation verarbeiten. Eine entsprechende Security Policy zeigt das Listing [Abb_EFA2_Spec_FD_0005]. Die Schnittstelle MUSS eine gültige SAML Assertion vom Typ „Authorisierung EFA FD“ gemäß „SAML 2.0 Profile for ECR Identity Assertions“ einfordern, die durch C.HCI.STS-AUT (Fachmodul EFA) oder C.FD.STS-AUT (Fachdienst EFA, Identity Provider) signiert wurde Sie MUSS ein Signaturelement mit Referenzen auf den TimeStamp und das Signaturelement in der SAML Assertion „Authorisierung EFA FD“ enthalten. |
|
eFA2-A_2158 |
Die Schnittstellen - I_Resocure_Manager - I_Document_Registry - I_Document_Respository - I_HPD_Services MÜSSEN das folgend beschriebene Verhalten implementieren: Bei Fehlern in Ablauf oder Ergebnis der Validierung MUSS eine Fehlermeldung erzeugt und die Verarbeitung mit einem SOAP Fault abgebrochen werden. Gemäß Abschnitt 3.3 oben erfolgreich Validierter EFA-Client Requests werden der adressierten Schnittstellenoperation - die SAML Assertion aus dem Security Header und - die SOAP Body Elemente zur fachlichen Verarbeitung übergeben. |
|
eFA2-A_2159 |
Die EFA-Fachdienst Schnittstelle I_eCR_Identity_Provider MUSS mit der logischen Operation „requestHPIdentityAssertion“ die Operation „Issue“ eines STS nach WS-Trust 1.3 abbilden. 3.6.1.1 Ablauf Operation „requestHPIdentityAssertion Details zum erwarteten Verhalten der Schnittstelle sind in Tabelle 7 definiert. <Tabelle> Tabelle 7: Ablauf „requestHPIdentityAssertion“ 3.6.1.2 WS Policy der Schnittstelle I_eCR_Identity_Provider Die dargstellte WS-Policy formuliert die Anforderungen zur Verwendung in der WSDL der Schnittstelle [Abb_EFA2_Spec_FD_0007] WS Policy ausarbeiten und kommentieren Ende der Anforderung |
|
eFA2-A_2160 |
Die EFA-Fachdienste MÜSSEN im „EFA single-peer Modell“ mit der vorgesehen Anzahl von Teilnehmern skalieren |