Aufbau des Berechtigungssystems¶

Das ELGA Berechtigungssystem besteht aus zentralen Kernkomponenten und vorgelagerten dezentralen Zugriffsteuerungsfassaden (ZGF), die in Form eines ELGA Anbindungsgateways (AGW) vom Betriebsdienstleister des BeS bereitgestellt werden.

Siehe ELGA Gesamtarchitektur 2.30b (ELGA GmbH, 2017): insbesondere die Kapitel 1.4. Übersicht über das Berechtigung- und Protokollierungssystem und 9. Berechtigungs- und Protokollierungssystem.

Zentralkomponenten¶

Alle Zentralkomponenten sind ausschließlich über zusätzliche Infrastrukturkomponenten des Betriebsdienstleisters, wie z.B. Load-Balancer und WAF (Web Application Firewall) erreichbar.

ETS – ELGA Tokenservice¶

Das ETS hat die Aufgabe mittels WS-TRUST SAML 2.0 Assertions auszustellen, zu validieren, zu invalidieren und zu erneuern. Die Implementierung des ETS basiert auf dem WS Trust Security Token Service Konzept [WS-TRUST Version 1.4].

Eine Vielzahl an Akteuren kommuniziert mit dem ETS. Beispielsweise fragt eine ELGA Bereichs- oder GDA-Software beim ETS um eine HCP Assertion an. Das EBP fragt um eine User I- oder Mandate I-Assertion für den angemeldeten ELGA Teilnehmer bzw. seinen Vertreter an. Die WIST ist mit einer WIST Assertion an ELGA angemeldet und beantragt für jeden bearbeiteten ELGA-Teilnehmer eine WIST Mandate Assertion. Bevor ELGA Login Assertions ablaufen, können sie spezifisch oft erneuert werden. Der General Policy Administrator beantragt beim ETS eine ELGA Service Assertion für den angemeldeten Regelwerkadministrator. Wird eine Benutzersession invalidiert, müssen ELGA Login Assertions via WS Trust Nachricht am ETS invalidiert werden. Die ZGF verwendet bei Hintergrundprozessen eine ZGF Service Assertion, die von der ZGF beim ETS beantragt wird. Für jede dokumentbezogene IHE Transaktion werden von der ZGF Treatment- bzw. User II- oder Mandate II- oder eMed Treatment-Assertions vom ETS angefordert, die nachfolgend für die remote Kommunikation und Berechtigungsprüfung verwendet werden.

Das ETS orchestriert den Nachrichtenaustausch zwischen den Diensten in der zentralen Umgebung (KBS, PAP, GDA Index, etc.) und erstellt, mit der von anderen Diensten zur Verfügung gestellten Information, ELGA Tokens. Beim Ausstellen von HCP Assertions wird beispielsweise der GDA-Index kontaktiert, bei Treatment-Assertions der Z-PI, PAP und das KBS. Zentralkomponenten wie KBS, PAP, A-ARR und CDM verwenden Methoden des ETS, um SAML Assertions zu validieren. Beim Ausstellen von Treatment, User II- und Mandate II-Assertions wird vom ETS mit Teilen der generellen und individuellen Policies ein XACML Enforcement durchgeführt. Abhängig von der durchgeführten Aktion werden vom ETS Protokolleinträge in das Z-L-ARR und in das A-ARR geschrieben. A-ARR Einträge werden nur beim Ausstellen von Treatment-, User II-, Mandate II- und eMed Treatment-Assertions protokolliert.

Das ETS stellt mehrere Serviceinstanzen für unterschiedliche Client Akteure bzw. Anwendungsfälle zur Verfügung. Die GDA Instanz wird verwendet, um ELGA HCP Assertions anzufordern, zu validieren oder zu invalidieren bzw. zu erneuern. Die EBP Instanz stellt die idente Funktionalität für ELGA User I-, Mandate I- und E-WIST-Assertions bereit. Die TRA Instanz steht ausnahmslos der ZGF zur Verfügung, um ELGA Treatment-Assertions sowie User II- und Mandate II-Assertions anzufordern. Die SRV (Service) Instanz steht internen ELGA Serviceanwendungen zur Verfügung.

KBS – Kontaktbestätigungsservice¶

Aufgabe des Kontaktbestätigungsservices ist die Speicherung eines Nachweises mit Zeitstempel eines Behandlungskontaktes zwischen einem GDA und einem Patienten. Die Schnittstellen sind an WS Trust angelehnt.

GDA Systeme sind dafür verantwortlich Behandlungskontakte einzubringen. Das EBP greift lesend auf das KBS zu, um Behandlungskontakte dem Bürger zu präsentieren. Beim Ausstellen von Treatment-Assertions wird vom ETS lesend auf das KBS zugegriffen. Vom KBS werden SAML Assertion Validierungsmethoden des ETS verwendet.

Die KBS GDA Instanz stellt schreibende Schnittstellen zum Einbringen, Delegieren und Invalidieren von Kontakten bereit, die über das AGW angesprochen werden können. Um alle Kontakte eines ELGA Teilnehmers abfragen zu können, stellt die KBS EBP Instanz eine read-only Schnittstelle für das EBP bereit.

PAP – Policy Adminstration Point¶

Der Policy Administration Point hat die Aufgabe individuelle Zugriffsrechte und generelle ELGA Policies zu verwalten.

Individuelle Zugriffsrechte werden vom EBP eingebracht und diesem auch wieder lesend zur Verfügung gestellt. Die WIST hat nur schreibenden Zugriff auf einen Teil der Zugriffsrechte eines ELGA Teilnehmers. GDA können den Teilnehmerstatus vom PAP abfragen. Der Teilnahmestatus gibt darüber Auskunft, ob ein ELGA Teilnehmer ein generelles oder partielles (eBefund/ eMedikation) Opt-Out bzw. eine Service-Restriction hat. Zusätzlich werden vom PAP bei individuellen Berechtigungsänderungen Löschaufträge an das CDM (Content Delete Management) Service bereitgestellt. Das ETS greift lesend auf den PAP zu, um generelle und individuelle Policies abzufragen. Die ZGF greift lesend auf generelle Policies zu, um diese zu synchronisieren. Alle Aktionen werden vom PAP in das Z-L-ARR protokolliert. Beim Ändern von Zugriffsrechten eines ELGA Teilnehmers wird vom PAP ein A-ARR Protokolleintrag erstellt.

Die PAP WIST Instanz steht ausschließlich der WIST zur Verfügung, um einen Teil der individuellen Bürgerpolicies zu ändern. Die WIST Instanz stellt keine lesende Schnittstelle bereit. Die PAP EBP Instanz wird vom EBP verwendet, um individuelle Policies abzufragen und wieder zu speichern. Die EBP Instanz kann ebenfalls verwendet werden, um den Teilnahmestatus abzufragen. Die PAP GDA Instanz wird verwendet, um vom GDA den Teilnahmestatus abfragen zu können. Die PAP Service Instanz wird verwendet, um generelle Policies zu verwalten.

CDM - Content Delete Management¶

Das Content Delete Management Service stellt Dienste bereit, die beim physischen Löschen aus ELGA Anwendungen bzw. Bereichen Verwendung finden. Der PAP speichert Löschaufträge im CDM, wenn individuelle Policies geändert werden, die physische Löschaktionen nach sich ziehen. Der CDD (Content Delete Daemon) der ZGF fragt um Löschaufträge an bzw. bestätigt durchgeführte Löschaufträge beim CDM.

A-ARR – Aggregiertes Audit Record Repository¶

Dem ELGA-Gesetz entsprechend ist ein Aggregiertes Audit Record Repository (A-ARR) als zentrales Service zu errichten, das es ELGA-Teilnehmern (Bürgern) ermöglicht, Einsicht in die aufgezeichneten Protokolldaten, die ihre eigenen Gesundheitsdaten betreffen, zu ermöglichen. Die Protokolldaten werden von der ZGF bzw. von ETS und PAP erstellt und an das A-ARR mittels https weitergeleitet. Dem Bürgerportal steht eine lesende SOAP Schnittstelle zum Abrufen aller Protokolleinträge eines Bürgers zur Verfügung.

Details zum A-ARR können im PH A-ARR nachgeschlagen werden.

Z-L-ARR - Zentrales Lokales Audit Record Repository¶

Das Z-L-ARR stellt eine zentrale Instanz eines Lokalen Audit Record Repository für alle ELGA Zentralkomponenten dar. Technologisch basiert das Z-L-ARR auf dem A-ARR. Alle Zentralkomponenten wie ETS, KBS, PAP erzeugen Protokolleinträge und leiten diese mittels TLS an das Z-L-ARR weiter.

Das Z-L-ARR stellt einen eigenen Endpunkt zur Verfügung und verwendet eine spezifische Instanz in einer Datenbank bzw. eine eigene Datenbank.

Dezentrale Komponenten¶

Alle dezentralen Komponenten der ZGF sind ausschließlich über zusätzliche Infrastrukturkomponenten der AGW, wie z.B. der WAF (Web Application Firewall) erreichbar. Eine Prüfung der Requests auf Schemakonformität muss bereits auf dieser vorgelagerten WAF stattfinden, da sämtliche Komponenten vom BeS schemavalidierte Requests erwarten (BeS validiert keine Schema von eingehenden Nachrichten). Eine Limitierung der Transaktionsgröße muss ebenfalls auf der WAF erfolgen.

ZGF - Dezentrale Zugriffssteuerungsfassade¶

Das AGW und die ZGF werden in unterschiedlichen Ausprägungen vom BeS Betriebsdienstleister zur Verfügung gestellt. In allen Varianten agiert die ZGF als Nachrichten-Interzeptor und Mediator und stellt für die Client Systeme den Eintrittspunkt zu ELGA dar.

Das AGW ist eine virtuelle Maschine, die vom Betriebsdienstleister des BeS bereitgestellt wird. Das AGW wird in diesem Dokument nur am Rande behandelt und dient nur zur leichteren Orientierung für den Leser. Dieses Dokument beschäftigt sich vorwiegend mit dem Softwareteil (ZGF), der zur Absicherung von IHE XDS-, XCA- und e-Medikations-Transaktionen am AGW installiert ist.

Siehe: ELGA Gesamtarchitektur 2.30b (ELGA GmbH, 2017), Kapitel 9.1.3.5. UML Komponentendiagramm eines E-AGW.

ZGF e-Befunde¶

Diese ZGF Variante steht dem ELGA Bereich bzw. GDA zur Verfügung, um auf e-Befund- und e-Medikations-Daten zuzugreifen. Außerdem wird diese ZGF Instanz vom ELGA Bereich bzw. GDA verwendet, um e-Befund-Daten in die Bereichs-XDS-Infrastruktur einzubringen bzw. e-Medikations-Daten an die e-Medikations-ELGA-Applikation weiterzuleiten. Als Schnittstellen werden IHE XDS- und XCA-Transaktionen angeboten. ETS- bzw. KBS WS Trust- Transaktionen werden von der AGW abgehandelt und von diesem nicht an die ZGF weitergereicht. ZGF zu ZGF Kommunikation wird ausschließlich über die ZGF Instanz aufgebaut. Eine Ausnahme bilden hier die EMEDAT-1 und PHARM-1 Transaktionen, die schon vom Apache der AGW an das eMed AGW weitergeleitet werden.

ZGF Read-Only¶

Die read-only ZGF findet Verwendung, wenn keine XDS Infrastruktur zum Speichern von Dokument- bzw. deren Metadaten vorhanden ist. In dieser Variante stellt die ZGF ausschließlich XCA Methoden zum Lesen von Metadaten und Dokumenten zur Verfügung. Es können jedoch keine XDS write Transaktionen zum Einbringen bzw. Ändern von Dokumenten durchgeführt werden. Als Folge entfallen alle Transaktionen der e-Befund ZGF Richtung lokalen ELGA Bereich. Da keine Daten im ELGA Bereich persistiert werden, kommt auch kein CDD (Content Delete Daemon) zum physischen Löschen zum Einsatz. Lesende Zugriffe verhalten sich identisch zur e-Befund ZGF. Eine read-only ZGF wird von anderen ZGFs nicht abgefragt, aus diesem Grund stehen keine XCA Responding Gateway Schnittstellen zur Verfügung. Die read-only ZGF kann lesend und schreibend auf die e-Medikation zugreifen.

ZGF eMed¶

Die eMed ZGF stellt den antwortenden Teil einer ZGF für die ELGA Applikation e-Medikation bereit. Diese ZGF Variante wird ausschließlich von anderen ZGF bzw. AGW Instanzen angesprochen und unterstützt nur e-Medikations-spezifische Transaktionen. Die eMed ZGF stellt keinen anfragenden (Initiating) Teil einer ZGF bereit.

Es gibt folgende Typen von Transaktionen, die von der eMed ZGF unterstützt werden:

IHE PHARM-1 – Diese Transaktionen werden von der initiierenden ZGF an die eMed ZGF weitergeleitet
FindPrescriptionsForDispense, FindMedicationList, FindDispenses, FindPrescriptions
IHE XDS - Diese Transaktionen werden von der initiierenden ZGF an die eMed ZGF weitergeleitet
[ITI-41] Provide and Register, [ITI-43] Retrieve Document Set sowie [ITI-57] Update Document Set Transaktionen werden mittels ZGF geprüft
EMEDAT-1 - Diese Transaktionen werden vom Apache der initiierenden AGW an die eMed ZGF weitergeleitet
GenerateDocumentID, RequestSecurityToken

Bei allen eMed Transaktionen wird das HTTP Headerattribute "x-gdaswinfo" (falls vorhanden) auf dem initiierenden Request bis zur e-Medikation im HTTP_Header weitergereicht. Derzeit ist eine Zeichenbegrenzung für dieses Attribute mit 256 von der e-Medikation festgelegt. Details zu Headerattributen siehe RFC 2616.

ZGF EBP¶

Dem EBP ZGF stehen die gleichen IHE Transaktionen wie der read-only ZGF zur Verfügung. WS Trust KBS Transaktionen werden von der AGW an die KBS/EBP (nur KBS read access) Instanz weitergeleitet. Es dürfen keine KBS Issue WS Trust Transaktionen über den Apache des AGW weitergeleitet werden. WS Trust ETS Transaktionen werden von der AGW an die ETS/EBP (User I-, Mandate I-Assertions) Instanz weitergeleitet. Zusätzlich bietet die EBP ZGF noch lesenden Zugriff auf A-ARR Protokolldaten und lesenden und schreibenden Zugriff auf die individuellen Policies des ELGA Teilnehmers.

Verwendete Standards¶

SOAP Kommunikation¶

Alle Komponenten des ELGA Berechtigungssystems kommunizieren mittels SOAP 1.2 (http://www.w3.org/TR/soap).

Alle SOAP-Verbindungen vom Client müssen https TLS V1.2 basierend sein.

WS Security¶

Die WSS: SOAP Message Security-Spezifikation definiert ein Standard-Set von SOAP-Erweiterungen bezüglich SOAP-Message Authentifizierung und Verschlüsselung.
http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SOAPMessageSecurity-v1.1.1-os.html

Das WSS: SAMLTokenProfile definiert die Verwendung der Security Assertion Markup Language (SAML) Assertions als Sicherheitstoken unter Verwendung der SOAP Message Security-Spezifikation.
http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SAMLTokenProfile-v1.1.1-os.html

Security Header Fehlermeldungen¶

Alle Fehlermeldungen, die das Prozessieren von Security Header Informationen betreffen, werden gemäß http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SOAPMessageSecurity-v1.1.1-os.html#_Toc307407975 abgebildet.

OASIS WS Trust¶

Die Komponenten PAP, KBS und ETS basieren auf dem OASIS Standard WS Trust http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html.

WSDL Files für WS Trust¶

siehe Kapitel WSDL Files WS Trust RST (Request Security Token)

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658937

Ein WSDL (=Web Services Description Language) beschreibt für Entwickler-Usergruppen die verfügbaren WebServices, SoapActions, sowie SoapRequest und SoapResponse (bzw. deren Payload). Request und Response-Strukturen des SoapBodys sind hierbei über XSD (=XML Schema Definition) Dateien definiert.

Mithilfe dieser Definitionen können (z.B. mit SoapUI) Testanfragen, Assertions und Mock Services generiert werden. Diese können anschließend zur Implementierung herangezogen werden. Zur endgültigen Verifizierung, ob der Code daraus auch wie gewünscht funktioniert, wird ein Zugriff auf eine ELGA-Testumgebung empfohlen.

WSDL Files werden vom ELGA BeS selbst nicht verwendet und deshalb nicht automatisch generiert sondern manuell gepflegt. Wie bei IHE Akteuren stellen auch für ELGA BeS Services die WSDL Files keine normative Spezifikation dar sondern werden als Unterstützung für die Entwicklung bereitgestellt. Als normative Spezifikation ist wie bei IHE der geschriebene Text des Schnittstellendokumentes bzw. des Pflichtenheftes und die drunterliegenden Standards zu sehen.

Die bereitgestellten WSDL Files sind in zwei Gruppen unterteilt:

Die Files aus dem Ordner "WSDL IHE" wurden initial von online verfügbaren IHE Download-Sourcen übernommen und bezüglich ELGA manuell erweitert. Die Erweiterungen beziehen sich auf sicherheitsrelevante Anpassungen wie z.B.: das Hinzufügen einer ws-policy/PolicyReference für den SOAP Security Header.
Der Ordner "WSDL Files" beinhaltet alle anderen WSDL- und Schemafiles, die für die Verbindung mit ELGA BeS notwendig sind. Diese umfassen einerseits "nicht von IHE verwendete Standards" wie z.B WS-Trust und andererseits BeS spezifische Services wie ETS und KBS.

Zu beachten: WSDLs stellen keine fertige Transaktion dar und beschreiben keine konkreten Dateninhalte, sondern bieten lediglich die informellen Bausteine, um einen Request zu erstellen (siehe auch diverse Schnittstellenbeschreibung-Verlinkungen bzw. Beispiele von WSDL Files). Diese Files sind als eine Art Datenstruktur- bzw. Kommunikations-Schablone zu betrachten, mit der u.a. auch Klassengenerierung möglich ist. Die Durchführung von kompletten ELGA Test-Transaktionen ist damit alleine nicht möglich. Grund dafür ist, dass die verwendeten WSDL- und Schemafiles nicht alle relevanten Details und ELGA-Spezifika beinhalten. Beispiel hierfür sind fehlende Inhalte für XDS Metadaten wie z.B. ClassCode, TypeCode, etc. Des Weiteren existiert in den WSDL Files keine Logik bezüglich welche Sicherheitsnachweise (Typen von SAML Assertions) in den SOAP Security Header einzufügen sind bzw. auch welche Rollen bei der Anmeldung verwendet werden können.

WS Trust RSTR (Request Security Token Response)¶

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658938

WS Trust Fehlermeldungen¶

Alle Fehlermeldungen betreffend WS Trust werden gemäß http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658986 abgebildet.

SAML2¶

Für alle empfangenen und ausgestellten Security Assertions wird der OASIS Standard SAML2 verwendet.

SAML2.0 core specifications:

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

SAML2.0 authentication contexts:

http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

SAML2.0 security and privacy consideration:

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

IHE XUA Profil:

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev10.0_Vol2b_FT_2013-09-27.pdf

3.40 Provide X-User Assertion

ELGA Assertion Signaturlayout

Signature Parameter	Usage Convention
CanonicalizationMethod	XML canonicalization. Set as "http://www.w3.org/2001/10/xml-exc-c14n#"
Transformation	Enveloped signature transform according to section 6.6.4 of [W3C XMLDSig]. In addition, exclusive canonicalization is defined as transformation ("http://www.w3.org/2001/10/xml-exc-c14n#", acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]).
SignatureMethod	Signature's algorithms for signing assertions are defined as: "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
DigestMethod	For signing assertions the digest methods http://www.w3.org/2001/04/xmlenc#sha256
KeyInfo	This element contains the X509Data referring to the base-64 encoding of the certificate, as defined in [W3C XMLDsig]. This certificate is bound to the ETS. For BeS a certificate must be embedded in the X509Certificate inside the X509Data

Datenelemente: Assertion Signaturlayout

IHE XDS.b¶

Dokumentenbezogene Kommunikation wird mittels Cross-Enterprise Document Sharing (XDS.b) IHE Integration Profile realisiert. http://www.ihe.net/Technical_Frameworks/#IT

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev10.1_Vol1_FT_2013-10-25.pdf

2.2.10 Cross-Enterprise Document Sharing (XDS)
10 Cross-Enterprise Document Sharing (XDS.b)
13.6.2 Cross-Enterprise Document Sharing (XDS)

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev10.0_Vol2a_FT_2013-09-27.pdf

3.18 Registry Stored Query

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev10.0_Vol2b_FT_2013-09-27.pdf

3.41 Provide and Register Document Set-b
3.42 Register Document Set-b
3.43 Retrieve Document Set

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_XDS_Metadata_Update.pdf

Update Document Set [ITI-57]

Hilfreiche IHE Wiki-Links:

MTOM vs. SIMPLE SOAP¶

XDS Transaktionen¶

Die Transaktionen Provide and Register Document Set-b, Retrieve Document Set und Cross Gateway Retrieve müssen wie von IHE definiert, sowohl für den Request wie auch für die Response, MTOM verwenden und werden vom BeS nur als MTOM akzeptiert. Alle anderen verwendeten XDS Transaktionen werden, wie von IHE vorgeschrieben, als Simple SOAP erwartet. Obwohl technisch vom BeS "MTOM/XOP with optimized content" wie auch "MTOM/XOP with un-optimized content" unterstützt wird, muss bei allen XDS MTOM Transaktionen "MTOM/XOP with optimized content" verwendet werden.

MTOM/XOP mit "optimized content"

<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">
    <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
        <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
            <rim:ExtrinsicObject id="Document01" mimeType="text/plain"/>
        </rim:RegistryObjectList>
    </lcm:SubmitObjectsRequest>
    <xdsb:Document id="Document01">
<!-- Document href link to multipart -->
        <xop:Include href="cid:1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
    </xdsb:Document>
</xdsb:ProvideAndRegisterDocumentSetRequest>

MTOM/XOP mit "un-optimized content"

<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">
    <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
        <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
            <rim:ExtrinsicObject id="Document01" mimeType="text/plain"/>
        </rim:RegistryObjectList>
    </lcm:SubmitObjectsRequest>
<!-- Document directly embedded as base64 -->
    <xdsb:Document id="Document01">base64 content goes here</xdsb:Document>
</xdsb:ProvideAndRegisterDocumentSetRequest>

Beispielsource - IHE Wiki:

http://wiki.ihe.net/index.php?title=XDS.b_Implementation#Example_SOAP.2C_MTOM.2C_and_MTOM.2FXOP_Messages

IHE Referenz:

http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf

XDS.b Fehlerhandling¶

Für alle XDS.b Transaktionen werden die Fehlermeldungen gemäß IHE XDS.b Profil zurückgeliefert. Details: http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf (Kapitel: 4.2.4 Error Reporting). Wenn vom BeS spezifische Fehlercodes definiert wurden, werden diese in den nachfolgenden Kapiteln erläutert.

PVP 2.1¶

Bürgerbezogene SAML2 Assertions werden gemäß Portalverbundprotokoll Version 2 Spezifikation an das ELGA Berechtigungssystem übergeben.
https://ref.gv.at/ag-resi-common-audit-trail/-/document_library/9mDlQxAIAgwy/view/27743818

ELGA ValueSets¶

Kodierte Werte müssen gemäß der Definition der ELGA ValueSets übergeben werden.

Patient ID Encoding¶

Alle Patientenidentifikationen werden im Format **CX HL7 V2.5 **gemäß IHE XDS.b Profil erwartet: http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf

Table 4.2.3.1.7-2: Data Types, Data Type: CX