Schnittstellen des Berechtigungssystems¶

Anbindung GDA- und ELGA Bereichs- Systeme¶

GDA Systeme können sowohl direkt als auch mittels Gateway eines ELGA Bereichs an das Berechtigungssystem von ELGA angebunden werden.

HCP Assertion anfordern¶

Ein GDA System oder ein Gateway eines ELGA Bereichs sendet eine WS Trust RST Issue Transaktion an die ZGF des ELGA Bereichs, um sich bei ELGA anzumelden
Im Security Header der SOAP Nachricht befindet sich die Identity Assertion des lokalen IdPs
Der Apache der lokalen AGW leitet die RST Nachricht zum zentralen ETS weiter.
Die HCP Assertion wird in einer WS Trust RSTR zurückgeliefert
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Läuft eine Benutzersession ab oder wurde invalidiert, muss auch die HCP Assertion beim ETS invalidiert werden (Invalidieren von Login Assertions).

HCP RST Issuer Anfrage¶

Um sich bei ELGA anzumelden, muss mit einer lokalen Identity Assertion mittels WS Trust RST, um eine ELGA HCP Assertion angefragt werden. Die HCP Assertion muss für alle nachfolgenden Transaktionen im SOAP Security Header mitgeführt werden.

Siehe: Externe Identity Assertions, Login Assertions, e-card Identity Assertion

Datenelemente:

wst:RequestType

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue

wst:TokenType

"urn:elga:bes:2013:HCP:assertion" Wird verwendet, um die unterschiedlichen Token Typen unterscheiden zu können.

urn:tiani-spirit:bes:2013:claims:requested-role

Die verwendete ELGA Rolle des Anfragenden muss in der HCP Issue Anfrage mit übergeben werden.

(siehe ELGA Value Set "ELGA_Rollen_VS")

Datenelemente: HCP RST Issuer Anfrage

ETS IssueHCP Rq.xml

Interface: HCP RST Issuer Anfrage

HCP RSTR Issuer Antwort¶

Die ELGA HCP Assertion wird mittels WS Trust RSTR an den Anfragenden zurückgeliefert. Die erhaltene HCP Assertion muss bei allen nachfolgenden Transaktionen an das ELGA Berechtigungssystem im SOAP Security Header mitgeliefert werden.

Datenelemente HCP RSTR:

Element	Beschreibung
RequestSecurityTokenResponseCollection	RequestSecurityTokenResponseCollection (RSTRC) wird in der abschließenden Antwort an eine RST Anfrage verwendet werden, um ein Security Token zu retournieren
RequestSecurityTokenResponse	Body der Antwort
TokenType	urn:elga:bes:2013:HCP:assertion
RequestedSecurityToken	Beinhaltet die ELGA SAML2 HCP Assertion

Datenelemente: HCP RSTR Issuer Antwort

ETS IssueHCP Rsp.xml

Interface: HCP RSTR Issuer Antwort

Kontaktbestätigungen¶

Kontaktbestätigungen sind ein Nachweis mit Zeitstempel eines Behandlungskontaktes zwischen einem GDA und einem Patienten. Es wird für alle Transaktionen WS Trust als Schnittstelle eingesetzt.

Siehe: KBS – Kontaktbestätigungsservice

KBS Berechtigungsmatrix¶

Achtung

Aktuell ist die KBS Berechtigungsmatrix wie unten dargestellt nicht zu 100% vollständig bzw. korrekt. An einer verbesserten Version wird gearbeitet. Für eine korrekte Darstellung wird auf die xml's aus dem Source Code verwiesen.

Für eine andere Darstellung siehe xml's aus der Konfiguration aus dem Source Code zu Kontakttypen und Identifikationsmethoden.

ELGA Rolle	Kontakte(e) abfragen	Ambulanten Kontakt einbringen	Internetkontakt einbringen	Stationären Kontakt einbringen	Entlassungs- Kontakt einbringen	Kontakt delegieren	EHDS	Kontakt stornieren
GDA Arzt
GDA Zahnarzt
GDA Apotheke
GDA KH
GDA PH
Bürger
Labor und Pathologie
NCPeH cross-border services
Rettungsdienst
Gesundheitsberatung 1450

Tabelle: KBS Sendeverhalten

	Zugriff für alle erlaubten PIMs pro Rolle
	Zugriff explizit nur für PIM101 (= e-Card Kontaktbestätigung)
	Kein Zugriff

KBS Subsequent Type Handling¶

				Folge-Transaktion*
KB-Type	Status	berechtigte Rolle (Ident Method)	listKBgda	Amb. & Inter. Kontakt	Stat. Kontakt	Entl. Kontakt	Delegation	Intern. Kontakt	EHDS	KB Storno
kein Kontakt						4				5
Stat. Kontakt (K101)	aktiv inaktiv invalidated	702 (kein PIM106) 703 (kein PIM106)			1
Amb. Kontakt (K102)	aktiv inaktiv invalidated ignored	700 (nur PIM101) 701 (nur PIM101) 702 (alle) 703 (kein PIM106) 704 (nur PIM101) 724 (nur PIM101 & 106) 728 (nur PIM101 & 103)				2
Entl. Kontakt (K103)	aktiv inaktiv invalidated	702 (kein PIM106) 703 (kein PIM106)				3
Del. Kontakt (K104)	aktiv inaktiv invalidated	Keine Rollenbeschränkungen				6
Inter. Kontakt (K105)	aktiv inaktiv invalidated ignored	700 (nur PIM101) 701 (nur PIM101) 702 (nur PIM101) 703 (nur PIM101) 704 (nur PIM101) 724 (nur PIM101) 729 (nur PIM101 & PIM107 & PIM108)				7
Europäischer Gesundheitsdatenraum (EHDS) (K106)	aktiv inaktiv invalidated	727 (nur PIM107 & PIM108)

Tabelle: KBS Empfangsverhalten

* Die Folge-Transaktion bezieht sich auf eine nachfolgende Transaktion auf einen aktiven KB-Type.

Berechtigte Rolle

700	Arzt
701	Zahnarzt
702	Krankenanstalt
703	Pflegeeinrichtung
704	Apotheke
724	Labor und Pathologie
727	NCPeH cross-border services
728	Rettungsdienst
729	Gesundheitsberatung 1450

Ident Method

PIM101	e-card mit stecken
PIM102	Bürgerkarte
PIM103	L-PI
PIM104	e-card ohne stecken
PIM106 *	Zuweisung
PIM107	eIDAS konforme Identifikation inklusive ID Austria
PIM108	Identifikation anhand amtlichen Lichtbildausweis

* Anmerkung zu PIM106: Kann nur mit einer gültigen HCP-Assertion (Kontext Assertion Einbringung nicht möglich) eingebracht werden.

Folge-Transaktionen

Erlaubt

Erlaubt (ignored)

Verboten

Allgemeine Fehlermeldungen

key	display
wst:InvalidRequest	Kontakteinmeldung zu weit in der Zukunft
wst:InvalidRequest	Kontakteinmeldung zu weit in der Vergangenheit

Detaillierte Fehlermeldungen - wst:InvalidRequest

1	Stat. Aufnahme auf bereits erfolgte stat. Aufnahme
2	Stationäre Entlassung auf ambulante Aufnahme
3	Stationäre Entlassung auf stationäre Entlassung
4	Entlassung ohne Aufnahme
5	Storno eines Kontakts ohne vorherige Kontakteinbringung
6	Stationäre Entlassung auf delegierten Kontakt
7	Stationäre Entlassung auf Internet Kontakt

Registrieren einer Kontaktbestätigung¶

Ein GDA, ein Middleware Gateway bzw. ein "externes KBS" (e-card KBS) kann mittels einer von WS Trust abgeleiteten RST Issue Transaktion eine Kontaktbestätigung einbringen.

Die GDA Software, ein Middleware Gateway bzw. ein "externes KBS" übermittelt mittels WS Trust RST die Daten der Kontaktbestätigung an die ZGF des ELGA Bereichs.
- Im Security Header der SOAP Nachricht befindet sich die ELGA HCP Assertion
Der Apache der lokalen AGW leitet die Nachricht zum zentralen KBS weiter
Die XSPA Organization ID der HCP Assertion muss mit der XSPA Organisation ID der Kontaktbestätigung übereinstimmen
In der WS Trust RSTR wird eine eindeutige Identifikation für diese Kontaktbestätigung zurückgegeben
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.
Kontakte können grundsätzlich bis zu 90 Tage in der Vergangenheit und bis zu 24 Stunden in der Zukunft eingebracht werden.
Der aktuelle Kontaktstatus ermittelt sich bei der Einbringung, aus der aufsteigenden Reihenfolge der Zeitstempel und nicht aus der zeitlichen Reihenfolge der Einbringung. Pro GDA zählt immer nur der chronologisch jüngste, bezogen auf den Zeitstempel, ambulante Kontakt. Neu eingebrachte ambulante Kontakte, mit älterem Zeitstempel, werden gespeichert, sind aber automatisch inaktiv. Neu eingebrachte ambulante Kontakte mit jüngerem Zeitstempel, werden als aktiv gespeichert und führen zur Inaktivierung des zuvor aktiven Kontaktes.
Es ist zulässig, zeitsynchrone Kontakte (identischer Zeitstempel und unterschiedlicher Kontakttyp) im Status ACTIVE oder INACTIVE, bezogen auf einen GDA zu einem Patienten, einzubringen. Dies dient zum Zweck des Fallartwechsels, der ausschließlich von ambulanten Kontakt (über K102) auf stationären (über K101) unterstützt wird und vice versa. Ein Fallartwechsel von einem stationären Kontakt K101 zu einem ambulanten Kontakt K102 ist nur dann zulässig, wenn für den stationären Kontakt noch kein Entlassungskontakt eingebracht wurde. Der initale Kontakt mit identem Zeitstempel muss hierbei entweder über den Status ACTIVE oder INACTIVE verfügen und darf zusätzlich nur bis zu 90 Tage in der Vergangenheit oder bis zu 24 Stunden in der Zukunft liegen. Der neu eingebrachte, zeitsynchrone Kontakt (soweit anwendbar) wird daraufhin gespeichert und automatisch auf ACTIVE gesetzt. Alle Kontakte zwischen initialem Kontakt und Fallwechsel-Kontakt müssen anschließend auf INVALIDATED gesetzt werden, mit einer Ausnahme: Zwischenzeitliche Kontaktdelegation (über K104) an einem anderen GDA, siehe dazu auch Stornieren einer Kontaktbestätigung.
Sollte man einem existierenden Kontakt (identischer Zeitstempel und identem Kontakttyp) zu einem bereits im KBS gespeicherten Kontakt im Status ACTIVE oder INACTIVE erneut einbringen, so wird dieser nicht gespeichert, jedoch als erfolgreich übermittelt angesehen, ohne Fehlermeldung. Das KBS retourniert ein Success mit Zusatzinformation (ts:TRInfo) des bestehenden Kontaktes. Sollte ein zeitsynchroner Kontakt (identischer Zeitstempel), zu einem bereits im KBS enthaltenen Kontakt im Status IGNORED oder INVALIDATED gemeldet werden, so ist dies ebenfalls zulässig.
Die Einbringung eines Entlassungskontaktes ist, bezogen auf den Zeitstempel, ausschließlich nach einer stationären Aufnahme möglich.
ELGA-GDA in der ELGA-Rolle Krankenhaus oder Pflegeeinrichtung dürfen sowohl ambulante wie auch stationäre Kontakte melden. Zulässige Qualitäten der Patientenidentifikation sind die Nutzung des L-PI, des e-card Systems mit und ohne Stecken der e-card sowie das Stecken der Bürgerkarte.
Ein stationärer Aufenthalt ist ausnahmslos mit einem Entlassungskontakt zu beenden.
Eine Entlassungsmeldung ohne einer, mit ihr in Verbindung stehender, aktiven stationären Aufnahme, führt zur Fehlermeldung und wird vom KBS nicht gespeichert.
Pro GDA und pro Patient (bPK-GH) darf nur ein stationärer Kontakt aktiv sein. Weitere stationäre Meldungen müssen zu einer Fehlermeldung führen und werden vom KBS nicht gespeichert.
Stationäre Kontakte gehen immer vor ambulanten/Internet Kontakten. Ambulante Kontakte mit jüngerem Zeitstempel werden gespeichert (IGNORED), beenden die Gültigkeit eines stationären Kontaktes nicht.
Bei der Ermittlung des aktiven Kontakts wird der Zeitstempel in Kombination von ambulanten/Internet und stationären Kontakten (stationärer Kontakt wird mit älterem Zeitstempel nach einem ambulanten/Internet Kontakt mit jüngerem Zeitstempel eingebracht) nicht herangezogen, sondern in diesem Fall hat der stationäre Kontakt Vorrang, auch wenn dieser älter ist.

Eingangsdaten für das Einbringen einer Kontaktbestätitung:

Element	Beschreibung	Opt
HCP Assertion	Elternknoten: Security Es muss eine HCP Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:Claims.Dialect	Fester Wert={"urn:tiani-spirit:bes:2013:claims"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:tr-type"	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Werte={"K101", "K102", "K103", "K104", "K105"} siehe "ELGA_Kontakttypen" in ELGA Value Sets Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Qualifikation des Behandlungskontaktes: Ambulanter Kontakt, Aufnahme in eine stationäre Einrichtung, Entlassung aus einer stationären Einrichtung, Delegation	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:ident-method"	ts:ClaimValue Werte={"PIM102", "PIM103", "PIM106", "PIM107", "PIM108"} siehe "ELGA_Patienten-Identifizierungsmethoden" in ELGA Value Sets Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 Qualität der Identifikation (z.B. Bürgerkarte, , LPID)	R
ts:ClaimType.name= "urn:oasis:names:tc:xspa:1.0:subject:organization-id"	Wert={OID des GDA vom GDA-Index} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 OID vom GDA Index des behandelnden GDA. Muss dem Wert "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der HCP Assertion entsprechen.	R
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Wert={PID vom Z-PI im HL7 CX Format } Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Eine dem Z-PI bekannte eindeutige Patientenidentifikation im HL7 CX Format (siehe Patient ID Encoding).	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:tr-date"	Wert={Zeitstempel im Format "yyyy-MM-dd‘T‘HH:mm:ss‘Z‘"} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#dateTime" Kardinalität: 1 Datum und Zeitpunkt (UTC) des Behandlungskontaktes	R

Datenelemente: Eingangsdaten – Kontaktbestätigung

Kontaktbestätigung einbringen – Anfrage:

KBS IssueKB Rq.xml

Interface: Kontaktbestätigung einbringen Anfrage

Ausgangsdaten für das Einbringen einer Kontaktbestätitung:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact"} Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
ts:TRID	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Wert={eindeutige UUID (RFC 4122)} Elternknoten: wst:RequestedSecurityToken ID der Kontaktbestätigung	R
ts:TRInfo	Fester Wert ={xmlns:ts="urn:tiani-spirit:ts"} Wert={Contact with same values already stored} Elternknoten: wst: RequestSecurityTokenResponse Optionale Info über die Verarbeitung	O

Datenelemente: Ausgangsdaten – Kontaktbestätigung

Kontaktbestätigung einbringen – Antwort:

KBS IssueKB Rsp.xml

Interface: Kontaktbestätigung einbringen - Antwort

Übersetzen der Patientenidentifikation¶

Wird eine Kontaktbestätigung eingebracht, bei der die Assigning Authority nicht der der bPK-GH entspricht (1.2.40.0.10.2.1.1.149), wird die Patientenidentifikation mittels PIX Query Transaktion (IHE ITI-45) via Z-PI auf die bPK-GH des ELGA Teilnehmers übersetzt. Die Daten der Kontaktbestätigung werden mit der bPK-GH des ELGA Teilnehmers gespeichert. Wird im Z-PI keine bPK-GH für den Bürger gefunden, wird vom Kontaktbestätigungsservice eine RequestFailed SOAP Fault retourniert. Wenn der Bürger nicht im Z-PI enthalten ist, wird vom Kontaktbestätigungsservice eine wsse:FailedAuthentication SOAP Fault retourniert.

Zwecks Verifikation der bPK-GH bei KBS Meldungen, wird für jede neu eingemeldete Kontaktbestätigung vom KBS eine Prüfung bzw. ein PIX Query durchgeführt. Hiermit soll verhindert werden, erfolgreich einen Kontakt einzumelden, obwohl die bPK-GH im Request nicht korrekt (unvollständig) übermittelt wird.

Generell ist anzumerken, dass das Einbringen von Kontakten im KBS mittels bPK-GH, mit oder ohne "GH" Präfix erfolgen kann.

Hinweis: Es muss jedoch nachfolgend die Patientenidentifikation durchgängig entweder mit oder ohne dem Präfix angegeben werden. Ein Einbringen ohne Präfix, aber Abfragen mit Präfix ist somit nicht möglich.

Registrieren einer Kontaktbestätigung (e-card)¶

Die e-card Infrastruktur bringt mittels WS Trust RST Issue Transaktion eine Kontaktbestätigung in Form eines e-card Kontaktbestätigungs-Tickets ein. (Details zum e-card Kontaktbestätigungs-Ticket siehe (SVC))

e-card Kontakte werden mit einem spezifischen RST TokenType "urn:elga:kbs:contact:ecard" in das BeS eingebracht. Wird dieser TokenType verwendet, ist zusätzlich zu den RST Inhalten, die in Registrieren einer Kontaktbestätigung beschrieben sind, die base64 kodierte e-card Kontaktbestätigung in "urn:tiani-spirit:bes:2013:claims:ecardkb" zwingend erforderlich. Zusätzlich wird auf Übereinstimmung eines subSets von Werten der RST gegen das e-card Kontaktbestätigung s-Ticket geprüft.

Die e-card Infrastruktur übermittelt mittels WS Trust RST ein e-card Kontaktbestätigungs-Ticket an die ZGF des ELGA Bereichs.
- Im Security Header der SOAP Nachricht befindet sich die ELGA HCP Assertion
- Im Body der RST Nachricht wird das e-card Kontaktbestätigungs-Ticket in einer WS Trust Claim transportiert
Der Apache der lokalen AGW leitet die Nachricht zum zentralen KBS weiter
Die Kontaktbestätigungsdaten werden aus der WS Trust RST Nachricht extrahiert
Übersetzen der Patientenidentifikation
In der WS Trust RSTR wird eine eindeutige Identifikation für diese Kontaktbestätigung zurückgegeben
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.
Kontakte können grundsätzlich bis zu 90 Tage in der Vergangenheit und bis zu 24 Stunden in der Zukunft eingebracht werden.
Der aktuelle Kontaktstatus ermittelt sich bei der Einbringung, aus der aufsteigenden Reihenfolge der Zeitstempel und nicht aus der zeitlichen Reihenfolge der Einbringung. Pro GDA zählt immer nur der chronologisch jüngste, bezogen auf den Zeitstempel, ambulante Kontakt. Neu eingebrachte ambulante Kontakte, mit älterem Zeitstempel, werden gespeichert, sind aber automatisch inaktiv. Neu eingebrachte ambulante Kontakte, mit jüngerem Zeitstempel, werden als aktiv gespeichert und führen zur Inaktivierung des zuvor aktiven Kontaktes.
Es ist zulässig, zeitsynchrone Kontakte (identischer Zeitstempel und unterschiedlicher Kontakttyp) im Status ACTIVE oder INACTIVE, bezogen auf einen GDA zu einem Patienten, einzubringen. Dies dient zum Zweck des Fallartwechsels, der ausschließlich von ambulanten Kontakt (über K102) auf stationären (über K101) unterstützt wird und vice versa. Ein Fallartwechsel von einem stationären Kontakt K101 zu einem ambulanten Kontakt K102 nur dann zulässig ist, wenn für den stationären Kontakt noch kein Entlassungskontakt eingebracht wurde. Der initiale Kontakt mit identem Kontakt muss hierbei entweder über den Status ACTIVE oder INACTIVE verfügen und darf zusätzlich nur bis zu 90 Tage in der Vergangenheit oder bis zu 24 Stunden in der Zukunft liegen. Der eingebrachte, zeitsynchrone Kontakt (soweit anwendbar) wird daraufhin gespeichert und automatisch auf ACTIVE gesetzt. Alle Kontakte zwischen initialem Kontakt und Fallartwechsel-Kontakt müssen anschließend auf INVALIDATED gesetzt werden, mit einer Ausnahme: Zwischenzeitliche Kontaktdelegation (über K104) an einem anderen GDA, siehe dazu auch Kapitel Stornieren einer Kontaktbestätigung
Sollte man einem existierenden Kontakt (identischer Zeitstempel und identem Kontakttyp) zu einem bereits im KBS gespeicherten Kontakt im Status ACTIVE oder INACTIVE erneut einbringen, so wird dieser nicht gespeichert, jedoch als erfolgreich übermittelt angesehen, ohne Fehlermeldung. Das KBS retourniert ein Success mit Zusatzinformation (TRInfo) des bestehenden Kontaktes. Sollte ein zeitsynchroner Kontakt (identischer Zeitstempel), zu einem bereits im KBS enthaltenen Kontakt im Status IGNORED oder INVALIDATED gemeldet werden, so ist dies zulässig.
ELGA-GDA in der ELGA-Rolle (niedergelassener) Arzt, Zahnarzt, Apotheker oder Labor und Pathologie dürfen nur ambulante/Internet Kontakte melden. Zulässige Qualität der Patientenidentifikation ist ausschließlich die Nutzung des e-card Systems.

Datenelemente e-card RST:

Element	Beschreibung	Opt
HCP Assertion	Elternknoten: Security Es muss eine HCP Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:ecard"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:Claims.Dialect	Fester Wert={"urn:tiani-spirit:bes:2013:claims"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:tr-type"	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Werte={"K101", "K102" , "K105"} siehe "ELGA_Kontakttypen" in ELGA Value Sets Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Qualifikation des Behandlungskontaktes: Ambulanter Kontakt, Internetkontakt, Aufnahme in eine stationäre Einrichtung, Entlassung aus einer stationären Einrichtung. Prüfung gegen e-card Kontakt: Wert ist im e-card Kontaktbestätigungs-Ticket nicht vorhanden. Es wird der Wert der RST gegen ein internes ValueSet geprüft.	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:ident-method"	ts:ClaimValue Werte={"PIM101","PIM104"}Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 Qualität der Identifikation (Stecken der e-card) Prüfung gegen e-card Kontakt: Der Wert "PAT_Kontaktbestaetigung _Qualitaet" aus dem e-card Kontaktbestätigungs-Ticket wird mittels internem ValueSet auf einen in BeS zulässigen Wert gewandelt und nachfolgend gegen den Wert, der in der RST empfangen wurde, auf Übereinstimmung geprüft. Zusätzlich wird der jeweilige Wert aus "PAT_Kontaktbestaetigung_Qualitaet" gegen den jeweils zu verwendenden AuthnContextClassRef des e-card Kontaktbestätigungs-Tickets geprüft (z.B: PAT_Kontaktbestaetigung_Qualitaet 1.0 erfordert urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI als AuthnContextClassRef) PIM101: PAT_Kontaktbestaetigung_Qualitaet = 1.0 PIM104: PAT_Kontaktbestaetigung_Qualitaet = 2.0 Ohne Stecken der e-Card	R
ts:ClaimType.name= "urn:oasis:names:tc:xspa:1.0:subject:organization-id"	Wert={OID des GDA vom GDA-Index} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 OID vom GDA Index des behandelnden GDA. Muss dem Wert "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der HCP Assertion entsprechen Prüfung gegen e-card Kontakt: Im RST wird zwingend die GDA-I OID des Vertragspartners erwartet. Dieser Wert wird gegen die empfangende HCP Assertion geprüft. Die "VP_Vertragspartnernummer" im e-card Kontakt wird gegen die "Local Organisation ID" der HCP Assertion geprüft.	R
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Wert={PID vom Z-PI im HL7 CX Format} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Eine dem Z-PI bekannte eindeutige Patientenidentifikation im HL7 CX Format. (siehe Patient ID Encoding) Prüfung gegen e-card Kontakt: Es wird geprüft, ob der Wert mit dem in "PAT_Patientenversicherungsnummer" übereinstimmt.	R
ts:ClaimType.name= "urn:tiani-spirit:bes: 2013:claims:tr-date"	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss'Z'"} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#dateTime" Kardinalität: 1 Datum und Zeitpunkt (UTC) des Behandlungskontaktes Prüfung gegen e-card Kontakt: Dieser Wert muss mit dem in "PAT_Kontaktbestaetigung_Datum" im e-card Kontakt übereinstimmen	R
urn:tiani-spirit:bes:2013:claims:ecardkb	Beinhaltet die base64 kodierte e-card Kontaktbestätigung in Form einer SAML2 Assertion Datentyp: http://www.w3.org/2001/XMLSchema#base64Binary Kardinalität: 1 Im e-card Kontaktbestätigungs-Ticket muss "*sha256" als SignatureMethod und DigestMethod verwendet werden, sha1 ist nicht zulässig

Datenelemente: Daten e-card Kontaktbestätigung RST

Kontaktbestätigung einbringen (e-card) – Anfrage:

KBS IssueKBeCard Rq.xml

Interface: Kontakbestätigung einbringen (e-card) Anfrage

Ausgangsdaten e-card RST:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:e-card"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
ts:TRID	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Wert={eindeutige UUID (RFC 4122)} Elternknoten: wst:RequestedSecurityToken ID der Kontaktbestätigung	R

Datenelemente: Ausgangsdaten - e-card Kontaktbestätigung RST

Kontaktbestätigung einbringen (e-card) – Antwort:

KBS IssueKBe-card Rsp.xml

Interface: Kontaktbestätigung einbringen (e-card) Antwort

Übersetzen der Patientenidentifikation¶

Siehe ersten Absatz in Kapitel Übersetzen der Patientenidentifikation.

Delegieren einer Kontaktbestätigung¶

Ein GDA System oder ein ELGA Bereichs Gateway kann mittels WS Trust RST Issuer Transaktion eine Kontaktbestätigung an einen anderen GDA weitergeben.

Ein GDA System oder ein Gateway des ELGA Bereichs übermittelt mittels WS Trust RST Transaktion die folgenden Inhalte an die ZGF des ELGA Bereichs
- eine dem Z-PI bekannte Patientenidentifikation
- die OID des GDAs dessen Patientenkontakt delegiert werden soll
- die OID des GDAs zu dem der Patientenkontakt delegiert werden soll
- Im Security Header der SOAP Nachricht wird die ELGA HCP Assertion mitgeliefert.
Der Apache der lokalen AGW leitet die Nachricht zum zentralen KBS weiter.
Die OrganisationsID der mitgelieferten ELGA HCP Assertion muss der OrganisationsID der zu delegierenden Kontaktbestätigung entsprechen.
Es wird eine RegEx Prüfung auf die OID des GDAs, zu dem der Kontakt delgiert wird, gemacht. Diese Prüfung soll validieren, ob es sich tatsächlich um eine OID handelt, indem diese nach dem Schema (urn\oid\)([0-2]$\d+$+\d+) geprüft wird.
Nach der RegEx Prüfung wird zusätzlich geprüft, ob die OID des GDAs zu dem der Patientenkontakt delegiert werden soll, im GDA-I als aktiver GDA geführt wird.
In der WS Trust RSTR wird eine eindeutige Identifikation für die delegierte Kontaktbestätigung zurückgegeben.
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.
Aktive stationäre, ambulante, Internet und Entlassungskontakte können an jene GDA delegiert werden, die in die Behandlung des Patienten explizit einbezogen werden. Delegierte Kontakte verhalten sich grundsätzlich wie ambulante Kontakte, wobei sich die Gültigkeit der delegierten Kontakte auf die Gültigkeit der zugrundeliegenden Kontakte stützt.
Internet und Ambulante Kontakte sowie Entlassungskontakte vererben dem delegierten Kontakt ihren Startzeitpunkt und ihre PIM.
Stationäre Kontakte vererben als Startzeitpunkt den Delegationszeitpunkt. Ebenso wird ihre PIM vererbt.
Delegierte Kontakte dürfen nicht weiterdelegiert werden und unterliegen keinerlei Rollenbeschränkungen.
Es ist nicht zulässig, zeitsynchrone Kontakte (identischer Zeitstempel und unterschiedlicher Kontakttyp) im Status ACTIVE oder INACTIVE, bezogen auf einen GDA zu einem Patienten, einzubringen.
Sollte es dennoch versucht werden einem existierenden Kontakt (identischer Zeitstempel und identem Kontakttyp) zu einem bereits im KBS gespeicherten Kontakt im Status ACTIVE oder INACTIVE erneut einzubringen, so wird dieser nicht gespeichert, jedoch als erfolgreich übermittelt angesehen, ohne Fehlermeldung. Das KBS retourniert ein Success mit Zusatzinformation (ts:TRInfo) des bestehenden Kontaktes. Sollte ein zeitsynchroner Kontakt (identischer Zeitstempel), zu einem bereits im KBS enthaltenen Kontakt im Status IGNORED oder INVALIDATED gemeldet werden, so ist dies zulässig.

Eingangsdaten für das Delegieren einer Kontaktbestätigung:

Element	Beschreibung	Opt
HCP Assertion	Elternknoten: Security Es muss eine HCP Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:delegate"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:Claims.Dialect	Fester Wert={"urn:tiani-spirit:bes:2013:claims"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:oasis:names:tc:xspa:1.0:subject:organization-id"	Wert={OID des GDA vom GDA-Index} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 OID vom GDA Index des behandelnden GDA, gemäß URN-Notation. Muss dem Wert "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der HCP Assertion entsprechen.	R
ts:ClaimType.name= "urn:elga:bes:2013:OrganizationIDDelegate"	Wert={OID des GDA vom GDA-Index} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 OID vom GDA Index des GDA zu dem der Kontakt delegiert werden soll, gemäß URN-Notation. Ab BeS 4.3 wird darüber hinaus die OID gemäß dem Schema (urn\:oid\:)([0-2]\.(\d+\.)+\d+) validiert.	R
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Wert={PID vom Z-PI im HL7 CX Format } Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Eine dem Z-PI bekannte eindeutige Patientenidentifikation im HL7 CX Format (siehe Patient ID Encoding).	R

Datenelemente: Eingangsdaten - Delegieren einer Kontaktbestätigung

Delegieren einer Kontaktbestätigung – Anfrage:

KBS DelegateKB Rq.xml

Interface: Delegieren einer Kontaktbestätigung Anfrage

Ausgangsdaten für das Delegieren einer Kontaktbestätigung:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:delegate"} Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
ts:TRID	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Wert={eindeutige UUID (RFC 4122)} Elternknoten: wst:RequestedSecurityToken ID der delegierten Kontaktbestätigung	R

Datenelemente: Ausgangsdaten - Delegieren einer Kontaktbestätigung

Delegieren einer Kontaktbestätigung – Antwort:

KBS DelegateKB Rsp.xml

Interface: Delegieren einer Kontaktbestätigung - Antwort

Stornieren einer Kontaktbestätigung¶

Ein GDA System, ein ELGA Bereichs Gateway bzw. ein "externes KBS" kann mittels WS Trust RST Cancel Transaktion eine Kontaktbestätigung als ungültig kennzeichnen.

Das GDA System, ein Middleware Gateway bzw. ein "externes KBS" übermittelt mittels WS Trust RST die eindeutige Identifikation der Kontaktbestätigung, die bei der Issue KB in der RSTR zurückgeliefert wurde an die ZGF des ELGA Bereichs.
- Im Security Header der SOAP Nachricht befindet sich die HCP Assertion
Der Apache der lokalen AGW leitet die Nachricht zum zentralen KBS weiter.
Die Organisations ID der mitgelieferten ELGA HCP Assertion muss der Organisations ID der zu annullierenden Kontaktbestätigung entsprechen
Es wird eine WS Trust RSTR mit dem Element "RequestedTokenCancelled" retourniert
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.
Sämtliche Kontakte, außer bereits stornierte Kontakte (STATUS=INVALIDATED), können auch storniert werden. Nach dem Stornieren des jüngsten Kontaktes wird der zweitjüngste inaktive Kontakt, bezogen auf den Zeitstempel, zur Zugriffsprüfung herangezogen. (Im Fehlerfall wird der Fehler "The request was invalid or malformed" zurückgegeben.)
Wenn der, einem delegierten Kontakt, zugrundeliegende Kontakt storniert wird, muss auch der delegierte Kontakt für ungültig erklärt und automatisiert storniert werden.
Eine Stornierung einer stationären Aufnahme, bei aktiver stationärer Entlassung, storniert gleichzeitig auch die stationäre Entlassung. Dies führt zur Reaktivierung des nächstjüngsten inaktiven Kontaktes, bezogen auf den Zeitstempel (sofern vorhanden).
Eine Stornierung der Entlassung führt zur Reaktivierung der, damit in Verbindung stehenden, stationären Aufnahme.

Eingangsdaten für das Stornieren einer Kontaktbestätigung:

Element	Beschreibung	Opt
HCP Assertion	Elternknoten: Security Es muss eine HCP Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Cancel"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
TRID	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Wert={eindeutige UUID (RFC 4122)} Elternknoten: wst:RequestedSecurityToken ID der zu stornierenden Kontaktbestätigung	R

Datenelemente: Eingangsdaten - Stornieren einer Kontaktbestätigung

Kontaktbestätigung stornieren – Anfrage:

KBS CancelKB Rq.xml

Interface: Stornieren einer Kontaktbestätigung Anfrage

Ausgangsdaten für das Stornieren einer Kontaktbestätigung:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact"} Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R
wst:RequestedTokenCancelled	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS 2012)	R

Datenelemente: Ausgangsdaten - Stornieren einer Kontaktbestätigung

Kontaktbestätigung stornieren – Antwort:

KBS CancelKB Rsp.xml

Interface: Stornieren einer Kontaktbestätigung - Antwort

Abfragen der Kontaktbestätigungen durch den GDA¶

Eine GDA-SW, ein Middleware Gateway bzw. ein "externes KBS" (e-card KBS) kann mittels einer von WS Trust abgeleiteten RST Status Transaktion eine Liste von Kontaktbestätigungen abfragen.

Die GDA Software, ein Middleware Gateway bzw. ein "externes KBS" übermittelt mittels WS Trust RST die Organisation ID, die Patienten ID und ein StatusFlag an die ZGF des ELGA Bereichs.
- Im Security Header der SOAP Nachricht befindet sich die ELGA HCP Assertion
Der Apache der lokalen AGW leitet die Nachricht zum zentralen KBS weiter
Die XSPA Organisation ID der HCP Assertion muss mit der XSPA Organisation ID im WS Trust Request übereinstimmen
Ist die im Request angegebene XACML Ressource ID keine bPK-GH, wird diese übersetzt. (Siehe Übersetzen der Patientenidentifikation.)
Ist das KBSStatusFlag des Requests auf "ListAllContacts" gesetzt, werden alle Kontakte des Patienten, sortiert nach TRDate, retourniert welche vom GDA eingebracht wurden (ProviderOID des Kontakts entspricht der XSPA Organisation ID) oder von diesem delegiert wurden (ProviderDelegatedOID des Kontakts entspricht der XSPA Organisation ID)
Ist das KBSStatusFlag des Requests auf "ListActiveContact" gesetzt, wird der derzeit aktive (TRStatus = ACTIVE) Kontakt des Patienten für diesen GDA (ProviderOID des Kontakts entspricht der XSPA Organisation ID) retourniert
In der WS Trust RSTR wird eine Liste der jüngsten Kontaktbestätigungen entsprechend des TRDate (max. 3000 konfigurierbar) absteigend zurückgegeben. Sollte im KBS kein Kontakt zu einem GDA für einen Patienten gespeichert sein, wird eine leere RequestSecurityToken-ResponseCollection zurückgegeben.
Fehlerfälle werden gemäß Security Header Fehlermeldungen bzw. WS Trust Fehlermeldungen prozessiert und sind in Kapitel Fehlermeldungen beschrieben. Folgende Fehler werden vom KBS retourniert:
wst:InvalidRequest: Die WS Trust Anfrage ist nicht valide. z.B. durch fehlende bzw. nicht korrekte Werte.
wst:RequestFailed: Beim Prozessieren der Anfrage ist ein Fehler aufgetreten

Eingangsdaten für das Abfragen von Kontaktbestätigungen durch den GDA zu einem Patienten:

Element	Beschreibung	Opt
HCP Assertion	Elternknoten: Security Es muss eine HCPAssertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS, 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:gda:list"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS, 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS, 2012)	R
wst:Claims.Dialect	Fester Wert={"urn:tiani-spirit:bes:2013:claims"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:oasis:names:tc:xspa:1.0:subject:organization-id"	Wert={OID des GDA vom GDA-Index} Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#anyURI" Kardinalität: 1 OID vom GDA Index des behandelnden GDA. Muss dem Wert "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der HCP Assertion entsprechen.	R
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Wert={PID vom Z-PI im HL7 CX Format } Elternknoten: wst:Claims Datentyp="http://www.w3.org/2001/XMLSchema#string" Kardinalität: 1 Eine dem Z-PI bekannte eindeutige Patientenidentifikation im HL7 CX Format (siehe Patient ID Encoding).	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013:claims:kb-status-flag"	Wert = {"ListAllContacts", "ListActiveContact"} Elternknoten: wst:Claims Datentyp=http://www.w3.org/2001/XMLSchema#string Kardinalität: 1 ListAllContacts: Alle Kontakte werden zurückgeliefert. (max. 3000) ListActiveContact: Nur der aktive Kontakt des GDA wird zurückgeliefert.	R

Datenelemente: Eingangsdaten – Abfragen der Kontaktbestätigungen des GDAs zu einem Patienten

KBS ListKBGDA Rq.xml

Interface: Abfragen der Kontaktbestätigungen des GDAs zu einer Patienten Anfrage

Ausgangsdaten für das Abfragen von Kontaktbestätigungen durch den GDA zu einem Patienten:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS, 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS, 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:gda:list"} Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS, 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS, 2012)	R
ts:TR	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestedSecurityToken Enthält Informationen zu einer Kontaktbestätigung.	R
ts:IdentMethod	Werte={"PIM101", "PIM102", "PIM103", "PIM104", "PIM106", "PIM107", "PIM108"} Elternknoten: ts:TR Qualität der Identifikation	R
ts:ProviderOID	Wert={OID des GDA aus dem GDA-Index} Elternknoten: ts:TR OID des behandelnden GDA	R
ts:PatientID	Wert={bPK-GH des Patienten im HL7 CX Format} Elternknoten: wst:ValidateTarget bPK-GH des Patienten - HL7 CX Data Type (inkludiert Assigning Authority)
ts:TRDate	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"} Elternknoten: ts:TR Datum und Zeitpunkt (UTC) des Behandlungskontaktes	R
ts:TRType	Werte={"K101", "K102", "K103", "K104" , "K105"}, siehe "ELGA_Kontakttypen" in ELGA Value Sets Elternknoten: ts:TR Qualifikation des Behandlungskontaktes	R
ts:TRStatus	Werte={"ACTIVE", "INACTIVE", "INVALIDATED", "IGNORED"} Elternknoten: ts:TR Status der Kontaktbestätigung: ACTIVE: Aktiver Kontakt zw. Patient und GDA INACTIVE: Ein neuerer Kontakt ist vorhanden INVALIDATED: Kontakt wurde storniert IGNORED: Ein Kontakt wurde empfangen, der ignoriert wurde (z.B. ambulanter Kontakt bei bereits aktiver stationärer Aufnahme)	R
ts:TRID	Wert= {UUID (RFC 4122) der Kontaktbestätigung} Elternknoten: ts:TR Eindeutige ID des Kontakts	R
ts:ProviderDelegatedOID	Wert={OID des GDA aus dem GDA-Index} Elternknoten: ts:TR OID des GDA welcher den Kontakt delegiert hat	O

Datenelemente: Ausgangsdaten - Abfragen der Kontaktbestätigungen des GDAszu einem Patienten

Antwort:

KBS ListKBGDA Rsp.xml

Interface: Abfragen der Kontaktbestätigungen des GDAs zu einer Patienten Antwort

GDA-Abfrage des ELGA-Teilnahmestatus¶

siehe Abfragen des ELGA-Teilnahmestatus

Dokumentenbezogene Transaktionen - Client¶

Um in ELGA Dokumente zu registrieren oder abzufragen, wird das IHE XDS.b Profil verwendet. Asynchrone Webservice Anfragen werden nicht unterstützt.

Abfragen von Dokumenten¶

Bei der Dokumentenabfrage unterscheidet das IHE XDS.bProfil zwischen der Anfrage von Dokument Metadaten und dem Anfragen von CDA Dokumenten. Alle XDS Abfragen werden vom XDS Consumer an die ZGF (ZGF - Dezentrale Zugriffssteuerungsfassade) des ELGA Bereichs gesendet und müssen im SOAP Security Header die ELGA HCP Assertion mitführen.

Aus dem Blickwinkel des XDS Consumer stellt die ZGF ein XCA Initiating Gateway dar. Details siehe:

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

2.2.18 Cross-Community Access (XCA)

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

3.38 Cross Gateway Query
3.39 Cross Gateway Retrieve

Abfragen von Dokument-Metadaten¶

Zum Abfragen von Dokument Metadaten wird die IHE Transaktion "Registry Stored Query (ITI-18)" vom XDS Consumer an die ZGF (ZGF - Dezentrale Zugriffssteuerungsfassade) des ELGA Bereichs gesendet. Im SOAP Security Header muss die ELGA HCP Assertion mit übergeben werden. Es muss eine dem Z-PI bekannte Patientenidentifikation in der ITI-18 Transaktion verwendet werden.

Details bezüglich IHE ITI-18 siehe:

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

3.18 Registry Stored Query

Wenn auf bestimmte Dokument Metadaten nicht zugegriffen werden darf, werden diese von der ZGF aussortiert, ohne einen Fehler zu retournieren. Eine leere Success XDS.b RegistryResponse wird retourniert, wenn alle Dokument Metadaten aussortiert wurden, der ELGA Teilnehmer keine LPID hat oder in keinem ELGA Bereich Dokument Metadaten gefunden wurden.

Es werden nur die folgenden ITI-18 Registry Stored Queries unterstützt:

GetAll urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3
FindDocuments urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d
FindDocumentsBySubmission urn:uuid:5BE09E2B-47E3-40AF-8F1E-7D84A9461E1F

<AdhocQueryRequest ………….
<AdhocQuery id="urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3"
Kommentat: Beispiel bezieht sich auf ein getAll StoredQuery 
xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

Details bezüglich der ELGA-spezifischen Query FindDocumentsBySubmission sind im ELGA-Integrations-Support Extranet zu finden:

https://confluence.elga.gv.at/display/IPSE/ELGA+IHE+Erweiterungen

Sollte die Anzahl der gefundenen Query-Resultate den vorkonfigurierten Wert (Wertebereich von 0 bis 1000 Dokumente (e-Befund & e-Medikation Document Ressource Elementen)) übersteigen, muss die Fehlermeldung "Too much Data", lt. Fehlermeldungen, mit einer leeren Liste zurückgeliefert werden. Dieses Limit gilt sowohl für die Initiating ZGF als auch für die Responding ZGF. Der vorkonfigurierte Wert gilt für alle zulässigen ITI-18 Query-Abfragen.

In der ITI-18 Transaktion muss als "ResponseOption" returnType="LeafClass" verwendet werden, returnType="ObjectRef" wird nicht unterstützt.

<AdhocQueryRequest ………….
<ResponseOption returnComposedObjects="true" returnType="LeafClass"/>

Abfragen von Dokumenten¶

Zum Abfragen von CDA Dokumenten wird die IHE Transaktion "Retrieve Document Set (ITI-43)" vom XDS Consumer an die ZGF (ZGF - Dezentrale Zugriffssteuerungsfassade) des ELGA Bereichs gesendet. Im SOAP Security Header muss die ELGA HCP Assertion mit übergeben werden.

Der XDS Dokument Consumer muss bei der "Retrieve Document Set (ITI-43)" Anfrage die in der vorhergegangenen "Registry Stored Query (ITI-18)" Antwort empfangene homeCommunityId mitliefern (Details:IHE XDS.b 2.3.5).

Details bezüglich IHE ITI-43 siehe:

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

3.43 Retrieve Document Set

Da von der ZGF bei einer "Registry Stored Query (ITI-18)" bzw. bei "PHARM-1" Transaktion notwendige Metadaten für die Prüfung von nachfolgenden "Retrieve Document Set (ITI-43)" Transaktionen temporär zwischengespeichert werden, kann eine "Retrieve Document Set (ITI-43)" Transaktion nur innerhalb eines Zeitraumes von 30 min nach einer "Registry Stored Query (ITI-18)" Transaktion erfolgreich durchgeführt werden. Um nach Ablauf der 30 min den Cache wieder zu erneuern, muss eine Registry Stored Query (ITI-18) bzw. "PHARM-1" Transaktion druchgeführt werden. Eine Ausnahme stellt die eMed-ZGF (Responding ZGF) dar, hier gibt es keinen Cache.

Darf auf ein bestimmtes Dokument nicht zugegriffen werden, antwortet die ZGF mit einem SOAP Fault "DocumentRetrieveDenied" siehe XDS.b Fehlerhandling.

Werden die Metadaten eines bestimmten Dokuments von der ZGF nicht im Zwischenspeicher gefunden, antwortet die ZGF mit einem "XDSMissingPatientContext" XDS Registry Error.

Registrieren von Dokumenten¶

Auch das Registrieren von Dokumenten für ELGA muss verpflichtend über die ZGF ausgeführt werden.

Beim Registrieren von Dokumenten über die ZGF schickt der XDS Source bzw. das XDS Repository eine IHE "Provide and Register Document Set-b (ITI-41)" bzw. eine "Register Document Set-b (ITI-42)" oder eine "Update Document Set (ITI-57)" Transaktion an die ZGF (ZGF - Dezentrale Zugriffssteuerungsfassade) des ELGA Bereichs. Im SOAP Security Header muss die ELGA HCP Assertion mit übergeben werden.

Details bezüglich IHE ITI-41 und ITI-42 siehe:

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

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

Details bezüglich IHE ITI-57 siehe:

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

In allen schreibenden Transaktionen Richtung ZGF muss die LPID (Bereichs Patienten ID) in den XDS Metadaten enthalten sein. (XDSSubmissionSet.patientid und XDSDocumentEntry.patientId)

Dem ELGA Bereich stehen zum Registrieren von Dokumenten unterschiedliche Varianten zur Verfügung, die in der aktuellen Version der ELGA Gesamtarchitektur beschrieben sind.

Sind an der ZGF für den ELGA Bereich mehrere XDS Repositories konfiguriert, muss die "repositoryUniqueId" in den XDS Metadaten bereits in der Provide and Register Document Set-b Transaktion an die ZGF enthalten sein.

(Ab Version 2.3)

Beim Einbringen eines Dokumentes muss der Organisationsname in den Metadaten vorhanden sein. Es wird geprüft, ob das Metadatenattribute authorInstitution vorhanden und dessen Elemente XON.1 (Organisationname) und XON.10 (GDA-OID) kein NULLSTRING ist.

Beim Updaten eines Dokumentes wird anhand des Metadatenattributs authorInstitution des SubmissionSets überprüft, ob der anfragende GDA mit dem Erstellen des gespeicherten SubmissionsSets übereinstimmt. Hierfür werden die GDA-OIDs (XON.10) verglichen.

Beim Einbringen, sowie Updaten eines Dokumentes wird geprüft, ob der Parameter "XDSDocumentEntryCreationTime" den im ELGA XDS Metadatenleitfaden V2.06 Kapitel 2.2.7, creationTime, spezifizierten Formaten entspricht. Sollte das Format abweichen, erfolgt die Fehlermeldung "Error detected in metadata", lt. Fehlermeldungen. Darüber hinaus erfolgt eine inhaltliche Plausibilitätsprüfung, ob das Jahr (Datum) des XDS Metadatenattribut >= 01.01.2000 & \<= 31.12.2999 ist. Sollte das Jahr nicht dem definierten Kriterium entsprechen, erfolgt die Fehlermeldung "Error detected in metadata", lt. Fehlermeldungen.

Für die Bereichsvarianten A und C ist ein Konfigurationsparameter verfügbar, um die ITI-41 Transaktion Provide And Register Document Set zu aktivieren bzw. zu deaktivieren.

Beschreibung des Konfigurationsparameters siehe Kapitel Registrieren von Dokumenten.

Responseverhalten der ZGF im Fehlerfall¶

Alle Fehlermeldungen betreffend WS Trust werden gemäß (OASIS, 2012), Abschnitt 11 Error-Handling, abgebildet.

Alle Fehlermeldungen, die das Prozessieren von Security Header Informationen betreffen, werden gemäß (OASIS, 2012), Abschnitt 12 Errror Handling, abgebildet.

Treten beim Assertion Anfordern von ZGF zu ETS Fehler auf, wird mit einer "XDSRequestFailed" SOAP Fault geantwortet.

Treten während XDS bzw. XCA Transaktionen Fehler auf, werden diese mittels XDS spezifischen Errors retourniert.

Etwaige XDS Registry Errors, die von den ELGA Bereichen zurückgeliefert werden, werden von der initiierenden ZGF gesammelt an den Anfrager zurückgeliefert.

Sollte ein ELGA Bereich beim Abfragen von Dokumenten nicht kontaktiert werden können, wird ein "XDSUnavailableCommunity" XDS Registry Error zurückgeliefert.

Wird der SOAP Action nicht unterstützt, wird eine "addressing:ActionNotSupported" SOAP Fault zurückgeliefert.

Responseverhalten der initiierenden bzw. lokalen ZGF¶

Hat der Bürger individuelle Request Policies, die auf der initiierenden bzw. lokalen ZGF schlagend werden (Opt-Out, Opt-Out ELGA-Applikation, Kontakt nicht gültig, GDA gesperrt, etc.) oder wird dem GDA aus anderen Gründen (z.B. die Rolle darf nicht zugreifen) vom ETS der Zugriff verweigert, wird von der ZGF im Falle einer Dokument-Metadaten Abfrage eine "DocumentQueryDenied" SOAP Fault retourniert. Werden Dokumentinhalte abgefragt, wird eine "DocumentRetrieveDenied" SOAP Fault zurückgeliefert. Beim Einbringen von Dokumenten wird in den Varianten A, C (siehe Gesamtarchitektur 2.11 oder höher) eine "DocumentSubmitDenied" SOAP Fault retourniert, wenn zumindest eines der eingebrachten Dokumente der Transaktion nicht gespeichert werden darf. Sollten die Dokument Metadaten (DocumentEntry.ClassCode, referenceIDList, authorInstitution, creationTime) nicht dem XDS Metadatenleitfaden entsprechen, antwortet die ZGF in allen Varianten mit einem XDS spezifischen "XDSRegistryMetadataError" bzw. "XDSRepositoryMetadataError".

Ist das Ergebnis beim Enforcement (ETS) "deny", wird mit einer AccessDenied SOAP Fault geantwortet.

Ist an der ZGF mehr als ein XDS Repository für den ELGA Bereich konfiguriert und sind in einer Provide and Register Document Set-b Transaktion mehrere Dokumente mit unterschiedlichen "repositoryUniqueId" enthalten, wird von der ZGF ein "XDSRepositoryMetadataError" zurückgeliefert.

Wird bei der Retrieve Document Set Transaktion keine oder einer falsche "homeCommunityId" angegeben, wird ein "XDSUnknownCommunity" XDS Registry Error zurückgeliefert.

Weiters wird bei einer ITI-39/43 Anfrage, welche in einem Bereich mehrere Repositorien adressiert, bereits auf der initiierenden AGW der Retrieve Request in mehrere separate (parallele) Anfragen aufgeteilt. Somit gesehen erhält dann die antwortende AGW/ZGF weiterhin Anfragen, die nach wie vor eine einzige Repository adressieren.

Wird vom ETS keine Treatment-Assertion zurückgeliefert (keine LPID im Z-PI gefunden), wird anstelle eines Fehlers eine leere Dokumentenliste zurückgegeben.

Responseverhalten der antwortenden ZGF¶

Bei einer ITI-18 Query Transaktion sortiert die antwortende ZGF Dokumentmetadaten, die nicht retourniert werden dürfen, bei der Berechtigungsprüfung aus und gibt keine Fehlermeldung zurück.

Werden im Falle einer Dokument-Metadaten Abfrage vom ELGA Bereich Metadaten mit einer Patientenidentifikation zurückgeliefert, die nicht der Patientenidentifikation der Anfrage entsprechen, werden diese Dokument-Metadaten aussortiert und zusätzlich mit den verbleibenden, korrekten Dokument-Metadaten ein XDS Registry Error "XDSPatientIdDoesNotMatch" zurückgeliefert.

Wird die uniqueID des abgefragten Dokuments nicht im Zwischenspeicher der ZGF gefunden, wird mit einem XDSMissingPatientContext Registry Error geantwortet.

Schlägt die Berechtigungsprüfung für ein bestimmtes Dokument fehl, wird mit einem DocumentRetrieveDenied SOAP Fault geantwortet.

Ist die referenceIDList nicht korrekt gemäß Kapitel IHE referenceIdList, werden die betroffenen Dokument-Metadaten aussortiert.

Einbetten von Security Assertion¶

Bei allen dokumentenbezogenen Transaktionen muss die ELGA HCP Assertion in den SOAP Security Header eingebettet werden. Details bezüglich des Einbettens von SAML2 Assertions in SOAP Security Header siehe: WS Security.

Dokumentenbezogene Transaktionen - Server¶

Die initiierende ZGF des anfragenden ELGA Bereichs kommuniziert mittels XCA mit der antwortenden ZGF des entfernten ELGA Bereichs. Um ELGA Dokumente vom entfernten ELGA Bereich abzufragen, wird das IHE XDS.b bzw. XCA Profil verwendet.

Um die für ELGA relevanten Transaktionen zu ermöglichen, muss der antwortende ELGA Bereich alle hierfür erforderlichen ITI Transaktionen unterstützen.

Außerdem muss der ELGA Bereich alle verwendeten Transaktionen der Kapitel Dokument aktualisieren und Transaktion zum Ändern des ELGA-Flags in Variante C unterstützen.

In Fällen, in denen die XDS Registry des ELGA Bereichs ELGA Dokumente und nicht ELGA Dokumente (eHealth) beinhaltet, ist die XDS Registry des ELGA Bereichs dafür verantwortlich, nicht ELGA Dokumente (XDS Metadaten ClassCode) sowie Dokumente, die in ELGA nicht sichtbar sein dürfen (siehe: XDS Metadaten ELGA-Flag), auszusortieren und nicht an die ZGF zurückzuliefern.

Abfragen von Dokumenten¶

Die antwortende ZGF bietet zwei Schnittstellen, um sich an den antwortenden ELGA Bereich anzubinden. Die erste Möglichkeit und gleichzeitig die Default Variante ist sich direkt an die XDS Registry und die XDS Repositories anzubinden. Die zweite Möglichkeit besteht darin, die empfangene XCA Transaktion an ein XCA Responding Gateway des ELGA Bereichs weiterzuleiten.

Aus dem Blickwinkel des antwortenden ELGA Bereichs agiert die ZGF folgendermaßen:

Bei der Default Variante kontaktiert die ZGF den antwortenden ELGA Bereich mittels:
- IHE ITI-18 um Dokument Metadaten abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf
    - 3.18 Registry Stored Query
- IHE ITI-43 um Dokumentinhalte abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.43 Retrieve Document Set
- PHARM-1 um Medikationsmetadaten abzufragen
Bei Variante 2 wird der ELGA Bereich mittels XCA Transaktion kontaktiert:
- IHE ITI-38 um Dokument Metadaten abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.38 Cross Gateway Query
- IHE ITI-39 um Dokumentinhalte abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.39 Cross Gateway Retrieve

Abfragen von Dokument-Metadaten¶

Zum Abfragen von Dokument Metadaten wird die IHE Transaktion "Registry Stored Query (ITI-18)" bzw. "Cross Gateway Query (ITI-38)" von der ZGF (siehe ZGF - dezentrale Zugriffsteuerungsfassade) an die XDS Registry bzw. an das XCA Responding Gateway des ELGA Bereichs geschickt. Im SOAP Security Header werden die in Kapitel Community Assertions beschriebenen mit übergeben. Es wird die LPID des ELGA Bereichs als Patientenidentifikation in der ITI-18 bzw. ITI-38 übergeben. Für den Fall einer e-Med-Transaktion wird die LPID des initiierenden ELGA-Bereichs durch die bPK-GH ersetzt.

Aus dem Blickwinkel des antwortenden ELGA Bereichs agiert die ZGF folgendermaßen:

Bei der Default Variante kontaktiert die ZGF den antwortenden ELGA Bereich mittels:
- IHE ITI-18 um Dokument Metadaten abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf
    - 3.18 Registry Stored Query
Bei Variante 2 wird der ELGA Bereich mittels XCA Transaktion kontaktiert:
- IHE ITI-38 um Dokument Metadaten abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.38 Cross Gateway Query

Abfragen von Dokumentinhalten¶

Zum Abfragen von Dokumentinhalten wird die IHE Transaktion "Retrieve Document Set (ITI-43)" bzw. "Cross Gateway Retrieve (ITI-39)" von der ZGF (ZGF - Dezentrale Zugriffssteuerungsfassade) an das XDS Repository bzw. an das XCA Responding Gateway des ELGA Bereichs geschickt. Im SOAP Security Header wird die in Kapitel Responseverhalten der initiierenden bzw. lokalen ZGF beschriebene Assertion mit übergeben.

Aus dem Blickwinkel des antwortenden ELGA Bereichs agiert die ZGF folgendermaßen:

Bei der Default Variante kontaktiert die ZGF den antwortenden ELGA Bereich mittels:
- IHE ITI-43 um Dokumentinhalte abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.43 Retrieve Document Set
Bei Variante 2 wird der ELGA Bereich mittels XCA Transaktion kontaktiert:
- IHE ITI-39 um Dokumentinhalte abzufragen
  - http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf
    - 3.39 Cross Gateway Retrieve

Weiterleiten von SAML2 Assertions¶

Siehe: Community Assertions und SAML Assertion Übersicht

ELGA spezifische XDS Metadaten¶

Im Zuge des Speicherns von Dokumenten bzw. von Dokument-Metadaten fügt die ZGF ELGA spezifische XDS Datenelemente zu den Dokument-Metadaten hinzu. Diese müssen vom empfangenden XDS Repository an die XDS Registry weitergeleitet werden. Die XDS Registry muss die ELGA spezifischen Metadaten speichern und auch bei einer Stored Query Anfrage der ZGF zurückliefern. Die ELGA spezifischen Metadaten dürfen jedoch nur an die ZGF zurückgeliefert werden und dürfen von der XDS Registry weder weitergeleitet noch bei etwaigen internen Anfragen eines XDS Consumers, welche direkt an die XDS Registry gestellt werden, zurückgeliefert werden.

XDS Metadaten ELGA-Flag¶

Dieses Attribut beinhaltet das Ergebnis der Berechtigungsprüfung durch XACML-Enforcement (true oder false) der ZGF zum Zeitpunkt des Einbringens bzw. Aktualisierens eines Dokuments. Das ELGA-Flag muss in allen Varianten (A, C) gesetzt werden.

ELGA-Flag kodiert als ebRIM Slot im ExtrinsicObject

<Slot name="urn:elga-bes:elgaFlag">
    <ValueList>
        <Value>true</Value>
    </ValueList>
</Slot>

Das ELGA-Flag wird von der ZGF bei einer Suchanfrage aus den Dokumentmetadaten entfernt und nicht an den Client zurückgeliefert.

XDS Metadaten ELGA-Hash¶

Beim Einbringen bzw. Aktualisieren von Dokumenten wird von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet, der in diesem Slot gespeichert wird.

ELGA-Hash kodiert als ebRIM Slot im ExtrinsicObject

<Slot name="urn:elga-bes:elgaHash">
    <ValueList>
        <Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</Value>
    </ValueList>
</Slot>

Der ELGA-Hash wird von der ZGF bei einer Suchanfrage aus den Dokumentmetadaten entfernt und nicht an den Client zurückgeliefert.

Bei Suchanfragen werden Dokumente mit gebrochenem ELGA-Hash nicht an den Client zurückgegeben und es wird auch kein XDS RegistryError zurückgeliefert. Gebrochene ELGA-Hashes werden im STL (Spirit Transaction Log) protokolliert (MetadataHashMismatch).

Bei Storno und Replace wird die Transaktion mit einem MetadataHashMismatch RegistryError abgebrochen, wenn der ELGA-Hash der zu aktualisierenden Dokumentmetadaten gebrochen ist.

IHE referenceIdList¶

Das ELGA Berechtigungssystem verwendet den von IHE definierten ebRIM Slot "referenceIdList" zur Darstellung von Dokumentabhängigkeiten. Diese ebRIM Slot Liste muss von der XDS Registry gespeichert werden können und bei Stored Queries zurückgeliefert werden.

Details siehe:

ELGA Implementierungsleitfäden: "XDS Metadaten zur Registrierung der CDA Dokumente (Version 2.03a)" Kapitel "2.2.17. referenceIdList"

Im Falle einer XDS Stored Query Abfrage wird der Slot "$OwnDocumentSetId" als Abfrage-wert verwendet.

IHE Referenz: http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf Kapitel "4.2.3.2.28 DocumentEntry.referenceIdList"

Damit der CDM ein zu löschendes Dokument eindeutig einem Bereich zuordnen kann, muss die ReferenceID, welche für die Berechtigungsprüfung verwendet wird, die HomeCommunityID des Bereichs enthalten. Dies bedeutet:

Ein ELGA-Dokument muss eine ReferenceId vom Type CXi enthalten, welche als Identifier Type Code (CXi.5) den Wert urn:elga:iti:xds:2014:ownDocument_setId enthält.
Diese ReferenceId muss das Element CXi.6 enthalten, in welchem die homeCommunityID im ISO Format angegeben sein muss.
Wird beim Einbringen eines Dokumentes keine ReferenceID gefunden, welche als Identifier Type Code den Wert urn:elga:iti:xds:2014:ownDocument_setId enthält, wird ein Fehler (XDS request failed) retourniert.
Wird beim Einbringen eines Dokumentes oder beim Enforcement in den Metadaten eines Dokumentes eine ReferenceID gefunden, welche als Identifier Type Code den Wert urn:elga:iti:xds:2014:ownDocument_setId enthält, bei welcher das Element CXi.6 fehlt, wird von der ZGF ein Fehler (XDS request failed) retourniert.
Wird beim Einbringen eines Dokumentes mehr als eine ReferenceID gefunden, welche als Identifier Type Code den Wert urn:elga:iti:xds:2014:ownDocument_setId enthält, wird ein Fehler (XDS request failed) retourniert.

Dokument aktualisieren¶

Problemstellung¶

Der Dokument-erfassende GDA muss die Möglichkeit haben, auch

ohne Kontaktbestätigung,
nach Ausblendung des betreffenden Dokumentes durch den Patienten,
trotz Sperre des betroffenen GDA durch den Patienten

genau das von ihm eingebrachte Dokument richtigzustellen, ohne dadurch Zugriff auf andere Dokumente zu erlangen.

Aussetzen der Kontaktprüfung¶

Durch diese Anpassung wird die Kontaktprüfung bei einer Richtigstellung ausgesetzt. Es wird vom ETS nur für eine Richtigstellung eine Treatment-Assertion ausgestellt, ohne den Kontakt zu prüfen.

Bedingung:

Die bestehende Protokollierung muss beibehalten werden.

Zulässige Transaktionen:

Versionierung / Richtigstellung eines bestehenden Dokumentes
- IHE ITI-41 oder ITI-42 RPCL Transaktion
- Stornierung eines fälschlich registrierten Dokumentes
- IHE ITI-57 Status Update Transaktion

Nicht zulässige Transaktionen:

Registrierung eines neuen Dokumentes
IHE ITI-41 oder ITI-42 Transaktion ohne RPLC
Lesende Transaktionen wie eine ITI-18 Abfrage

Umsetzung:

Der Anwendungsfall laim 'urn:tiani-spirit:bes:2013:claims:action' enthält den Wert 'RichtigstellungRPLC41', 'RichtigstellungRPLC42' oder 'RichtigstellungSTORNO57'
Handelt es sich um eine Richtigstellung, wird kein Kontakt abgefragt und geprüft
Vom ETS wird eine Treatment-Assertion zurückgeliefert, die von der lokalen ZGF verwendet wird, um die Korrektur zu berechtigen

Betroffene Transaktionen¶

ITI-57 Update Document Set: Update DocumentEntry AvailabilityStatus
ITI-41 Provide and Register Document Set-b: Replace Document
ITI-42 Register Document Set-b: Replace Document
Anmerkung: Es sind nur Transaktionen im Kontext des ELGA Service "e-Befunde" betroffen.

Berechtigungsprüfung durch die ZGF¶

Eine Berechtigungsprüfung durch die ZGF kann drei mögliche Zustände zur Folge haben:

"Permit"

Eine Treatment-Assertion wurde vom ETS ausgestellt, ohne den Kontakt zu prüfen

"Deny"

Generelles Opt-Out
Service Opt-Out

"Kontakt"

Bei der Richtigstellung von Dokumenten wird kein Kontakt geprüft

ZGF Workflow¶

Trigger Event: Dokument stornieren¶

Transaktion:

ITI-57 Update Document Set:

associationType="urn:ihe:iti:2010:AssociationType:UpdateAvailabilityStatus"

Das zu stornierende Dokument (rim:Association\@targetObject) kann entweder durch eine entryUUID oder eine ownDocument_setId referenziert sein.

Die Nachricht an die ZGF muss exakt eine rim:Association mit AssociationType:UpdateAvailabilityStatus und StatusType:Deprecated beinhalten. Es darf kein DocumentEntry (ExtrinsicObject) in der Nachricht enthalten sein.

Da nicht in allen relevanten Transaktionen ein DocumentEntry vorhanden ist (z.B. UpdateAvailabilityStatus), wird der Author des Submission Sets verwendet.

Abgrenzung: In e-Medikation ist ein Update mittels ITI-57 nur über eine zuvor durchgeführte PHARM-1 zulässig. ITI-57 wird in e-Medikation nur für das Stornieren eines Dokuments erlaubt. Die fachlichen Prüfungen dafür erfolgen seitens der Kernanwendung e-Medikation.

Berechtigungsprüfung ergibt "Permit"¶

Enthält die Transaktion eine entryUUID als Zielobjekt, ergibt sich der folgende Ablauf:

Die ZGF holt sich mittels ITI-18 Stored Query - Get All das Dokument (und damit verbundene Objekte) aus dem Zielbereich (returnType = 'LeafClass')
Es wird anhand des Metadatenattributs authorInstitution des SubmissionSets überprüft, ob der anfragende GDA mit dem Ersteller des gespeicherten SubmissionsSets übereinstimmt. (Ab Version 2.3 wird nicht mehr der komplette String geprüft, sondern nur die GDA-OID (XON.10) wird verglichen.)
Ist die Prüfung nicht erfolgreich, wird der SOAP Fault "DocumentStatusUpdateDenied" an das anfragende System zurückgeliefert.
Die ZGF berechnet den neuen "ELGA-Hash" (für den geänderten Dokumentenstatus), fügt diesen in die ursprüngliche Transaktion ein und leitet die Transaktion an den Zielbereich weiter.

Enthält die Transaktion eine ownDocument_setId als Zielobjekt, ergibt sich der folgende Ablauf:

Die ZGF sucht im Zielbereich mittels ITI-18 Stored Query - Get All unter Angabe der ownDocument_setId nach Dokumenten mit Status approved (returnType = 'LeafClass')
Wird kein Dokument gefunden, wird der XDS Registry Error "XDSDocumentUniqueIdError" an das anfragende System zurückgeliefert.
Werden mehrere Dokumente (mit Status "approved") gefunden, wird der XDS Registry Error "XDSTooManyResults" an das anfragende System zurückgeliefert.
Bei erfolgreicher Suche wird anhand des Metadatenattributs authorInstitution des SubmissionSets überprüft, ob der anfragende GDA mit dem Erstellen des gespeicherten SubmissionsSets übereinstimmt. (Ab Version 2.3 wird nicht mehr der komplette String geprüft, sondern nur die GDA-OID (XON.10) wird verglichen.)
Ist die Prüfung nicht erfolgreich, wird der SOAP Fault "DocumentStatusUpdateDenied" an das anfragende System zurückgeliefert.
Die ZGF ersetzt die ownDocument_setId der ursprünglichen Anfrage durch die entryUUID des - in der zuvor durchgeführten Abfrage - zurückgelieferten Dokuments.
Die ZGF berechnet den neuen "ELGA-Hash" (für den geänderten Dokumentenstatus), fügt diesen in die ursprüngliche Transaktion ein und leitet die Transaktion an den Zielbereich weiter.

Berechtigungsprüfung ergibt "Deny"¶

Die ZGF sendet den SOAP Fault "DocumentStatusUpdateDenied" an das anfragende System zurück.

Trigger Event: Ersetzen eines existierenden Dokuments¶

Transaktionen:

ITI-41 Provide and Register Document Set-b:

associationType="urn:ihe:iti:2007:AssociationType:RPLC"

ITI-42 Register Document Set-b:

associationType="urn:ihe:iti:2007:AssociationType:RPLC"

Das zu ersetzende Dokument (rim:Association\@targetObject) kann über die ZGF entweder durch eine entryUUID oder eine ownDocument_setId referenziert sein.

Die Nachricht an die ZGF muss exakt zwei rim:Associations mit AssociationType: RPLC und AssociationType:HasMember beinhalten. Es muss exakt ein DocumentEntry (ExtrinsicObject) in der Nachricht enthalten sein. Sind andere Associations enthalten, wird ein ‚XDS Request failed’ Fehler zurückgeliefert.

Berechtigungsprüfung ergibt "Permit"¶

Enthält die Transaktion eine entryUUID als Zielobjekt, ergibt sich der folgende Ablauf:

Die ZGF holt sich mittels ITI-18 Stored Query - Get All das Dokument (und damit verbundene Objekte) aus dem Zielbereich (returnType = 'LeafClass')
Es wird anhand des Metadatenattributs authorInstitution des SubmissionSets überprüft, ob der anfragende GDA mit dem Erstellen des gespeicherten SubmissionsSets übereinstimmt.
Ist die Prüfung nicht erfolgreich, wird der SOAP Fault "DocumentSubmitDenied" an das anfragende System zurückgeliefert.
Die ZGF berechnet den neuen "ELGA-Hash" (für den geänderten Dokumentenstatus), fügt diesen in die ursprüngliche Transaktion ein und leitet die Transaktion an den Zielbereich weiter.

Enthält die Transaktion eine ownDocument_setId als Zielobjekt, ergibt sich der folgende Ablauf:

Die ZGF sucht im Zielbereich mittels ITI-18 Stored Query - Get All unter Angabe der ownDocument_setId nach Dokumenten mit Status approved (returnType = 'LeafClass').
Wird kein Dokument gefunden, wird der XDS Registry Error "XDSDocumentUniqueIdError" an das anfragende System zurückgeliefert.
Bei erfolgreicher Suche wird anhand des Metadatenattributs authorInstitution des SubmissionSets überprüft, ob der anfragende GDA mit dem Erstellen des gespeicherten SubmissionsSets übereinstimmt.
Ist die Prüfung nicht erfolgreich, wird der SOAP Fault "DocumentSubmitDenied" an das anfragende System zurückgeliefert.
Die ZGF ersetzt die ownDocument_setId der ursprünglichen Anfrage durch die entryUUID des - in der zuvor durchgeführten Abfrage - zurückgelieferten Dokuments.
Die ZGF berechnet den neuen "ELGA-Hash" (für den geänderten Dokumentenstatus), fügt diesen in die ursprüngliche Transaktion ein und leitet die Transaktion an den Zielbereich weiter.

Berechtigungsprüfung ergibt "Deny"¶

Die ZGF sendet den SOAP Fault "DocumentSubmitDenied" an das anfragende System zurück.

Transport des neuen ELGA-Hash bei Änderung eines Dokuments¶

Findet eine transaktionsbedingte Statusänderung (von "approved" auf "deprecated") eines vorhandenen Dokuments statt, muss der ELGA-Hash dieses Dokuments geändert werden.

Um eine (weitere) Versionierung des Dokuments durch eine ITI-57 Update Document Set, ITI-41 Provide and Register Document Set-b oder ITI-42 Register Document Set-b Transaktion seitens der ZGF - und mögliche Inkonsistenzen im ELGA-Hash durch ein fehlgeschlagenes Update - zu vermeiden, wird der neue (d.h. zukünftige) ELGA-Hash von der ZGF bereits bei Empfang der jeweiligen Transaktion berechnet und in dieser an das Zielsystem weitergeleitet.

Der neue ELGA-Hash wird in Forms eines eigenen Slots in der Association zum existierenden Dokument der jeweiligen Transaktion mitgegeben. Das entspricht der von IHE definierten Vorgehensweise für erweiterte Metadaten (siehe ITI-TF Rev.11, Vol 3, 4.2.3.1.6 Extra Metadata Attributes).

Die empfangende XDS Registry ist dafür verantwortlich den Slot auszuwerten bzw. den vorhandenen ELGA-Hash des zu ändernden Dokuments entsprechend dem neuen ELGA-Hash zu korrigieren.

Im Falle einer ITI-42 Register Document Set-b Transaktion (RPLC) muss die XDS Registry den ELGA-Hash in den bereits vorhandenen Metadaten ändern, bevor die eigentliche Replace Transaktion durchgeführt wird.

Erfolgt seitens der XDS Registry keine Korrektur des ELGA-Hash Wertes, ist der ELGA-Hash nicht mehr gültig und das Dokument kann nicht mehr in ELGA verarbeitet werden.

Die folgenden Beispiele zeigen den Transport des neuen ELGA-Hash in den jeweiligen Transaktionen zum Ändern eines Dokuments.

Transaktionen:

ITI-41 Provide and Register Document Set-b:

associationType="urn:ihe:iti:2007:AssociationType:RPLC"

ITI-42 Register Document Set-b:

associationType="urn:ihe:iti:2007:AssociationType:RPLC"

<rim:Association associationType="urn:ihe:iti:2007:AssociationType:RPLC" sourceObject="source" targetObject="urn:uuid:XXX" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association" id="IdExample_42">
      <rim:Slot name="urn:elga-bes:elgaHash">
            <rim:ValueList>
                  <rim:Value>3b63df50f6fe0f88ff7c2ea1a0b0e186</rim:Value>
            </rim:ValueList>
      </rim:Slot>
</rim:Association>

Interface: Association Type:RPLC

Transaktion:

ITI-57 Update Document Set:

associationType="urn:ihe:iti:2010:AssociationType:UpdateAvailabilityStatus"

<rim:Association associationType="urn:ihe:iti:2010:AssociationType:UpdateAvailabilityStatus"    sourceObject="SubmissionSetOfUpdates" targetObject="urn:uuid:XXX" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association" id="IdExample_57">
      <rim:Slot name="urn:elga-bes:elgaHash">
            <rim:ValueList>
                  <rim:Value>3b63bf50f6fe0f88ff7c2ea1a0d0e186</rim:Value>
            </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="NewStatus">
            <rim:ValueList>
                  <rim:Value>urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated</rim:Value>
            </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="OriginalStatus">
            <rim:ValueList>
                  <rim:Value>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</rim:Value>
            </rim:ValueList>
      </rim:Slot>
</rim:Association>

Interface: AssociationType:UpdateAvailabilityStatus

Transaktion zum Ändern des ELGA-Flags in Variante C¶

Problemstellung¶

In der Variante C ist vorgesehen, dass von der ZGF das ELGA-Flag auf ein Dokument mittels ITI-57 Update Document Set Transaktion gesetzt wird. Diese Transaktion erzeugt eine neue Version des Dokuments mit den neuen Metadaten. Die alte Version würde nach wie vor abrufbar bleiben.

Sollte der Patient dieses Dokument löschen wollen (alle Dokumente mit derselben ownDocument_setId), wird von der ZGF eine weitere ITI-57 Transaktion mit ELGA-Flag="false" gesendet. Auch diese Aktion erzeugt eine neue Version des Dokuments. Sollte das Dokument bereits den Status "deprecated" aufweisen, so wäre die vorherige Version (mit ELGA-Flag="true") nach wie vor gültig (ELGA-Hash würde noch stimmen) und könnte auch von der ZGF noch abgerufen werden.

Proprietärer ITI-57 Trigger Event "NonVersioningUpdate"¶

Um die Versionierung eines Dokuments durch Einfügen oder Änderung des ELGA-Flags zu vermeiden, wird von der ZGF ein eigenes Association Objekt mit associationType "NonVersioningUpdate" in der ITI-57 Update Document Set Transaktion verwendet.

Dies stellt eine Erweiterung der IHE Spezifikation dar.

Das sourceObject der Association referenziert das SubmissionSet Objekt der Übertragung.

Als targetObject der Association wird eine DocumentEntry.entryUUID eines bereits existierenden Dokuments referenziert**.**

Der ebRIM Slot "urn:elga-bes:elgaFlag" kennzeichnet das Dokument als ELGA relevant.

Der ebRIM Slot "urn:elga-bes:elgaHash" beinhaltet den entsprechenden ELGA Hash Wert.

<rim:RegistryPackage id="SubmissionSetOfUpdates">
...
</rim:RegistryPackage>
<rim:Association associationType="urn:elga-bes:AssociationType:NonVersioningUpdate" sourceObject="SubmissionSetOfUpdates" 
    targetObject="urn:uuid:XXX" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association" id="NonVersioning_57">
      <rim:Slot name="urn:elga-bes:elgaFlag">
            <rim:ValueList>
                  <rim:Value>true</rim:Value>
            </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="urn:elga-bes:elgaHash">
            <rim:ValueList>
                  <rim:Value>3b63bf50f6fe0f88ff7c2ea1a0d0e186</rim:Value>
            </rim:ValueList>
      </rim:Slot>
</rim:Association>

Interface: AssociationType:NonVersioningUpdate

Der Trigger Event "NonVersioningUpdate" muss bereits vom "Document Adminstrator" Actor an die ZGF gesendet werden.

Die ZGF führt keine Übersetzung eines "Standard" Metadaten Updates auf ein "NonVersioningUpdate" durch.

LPI-Anbindung¶

Um Dokumente in ELGA einstellen bzw. abrufen zu können, ist es notwendig die Identität des Patienten im lokalen Patienten-Index (L-PI) des jeweiligen ELGA-Bereiches einzumelden bzw. abzurufen. Die hierfür notwendigen IHE-standardkonformen PDQv3, PIXv3 bzw. PIFv3 Transaktionen können über das ELGA Anbindungsgateway (Standardbereichs-AGW) an den lokalen Patienten-Index geschickt werden.

Die GDA Software schickt eine PDQv3, PIXv3 oder PIFv3 Transaktion an die ZGF des ELGA Bereichs.
Im SOAP-Header muss die HCP Assertion enthalten sein.
Die ZGF validiert die empfangene HCP Assertion.
Schlägt die Validierung fehl, wird ein SOAP Fault retourniert.
Die ZGF erstellt auf Basis der HCP Assertion eine Community Assertion.
Die ZGF schickt die Transaktion an den lokalen Patienten Index.
Im SOAP-Header muss die Community Assertion (siehe Community Assertions) enthalten sein (die Community Assertion kann in diesem Fall keine bPK-GH / PID enthalten).
Falls der LPI kein Ergebnis liefert, wird ein SOAP Fault von der ZGF retourniert.
Der LPI validiert die empfangene Community Assertion.
Schlägt die Validierung fehl, wird ein SOAP Fault retourniert.
Der LPI verarbeitet den Request und retourniert entweder eine Antwort oder eine (IHE) Fehlermeldung.
Die ZGF retourniert den vom LPI empfangen Response unverändert an die GDA Software (enthält der Response des LPI ein SOAP Fault, wird diese durch eine externe Fehlermeldung (SOAP Fault) ersetzt). Fachliche (IHE) Fehlermeldungen des LPI werden von der ZGF unverändert an die GDA Software weitergeleitet.

Details zum Aufbau der Nachrichten können dem WSDL des ZPI (zpi-wsdl-informative.zip) entnommen werden.

ELGA-1 Transaktion - Notify ELGA XAD-PID Link Change¶

Problemstellung¶

Wenn der PIX Manager eines ELGA Bereichs die IHE Transaktion ITI-64 (Notify XAD-PID Link Change) - bereichsintern - an die XDS Registry schickt, ändern sich in der ELGA Registry die Patient IDs (XDSDocumentEntry.patientId / ELGA LPID) vorhandener Dokument-Referenzen und die entsprechenden ELGA-Hash Werte werden ungültig. Die entsprechenden Dokumente sind in ELGA nicht mehr sichtbar.

Die bereichsinterne Durchführung der Transaktion ITI-64 ist sowohl in Variante C als auch in Variante A zulässig.

Generell wird das Clearing bereichsspezifisch umgesetzt und kann unterschiedlichste Ausprägungen aufweisen. In den nachfolgenden Anwendungsfällen wird nur schematisch auf die auslösenden Szenarien eingegangen.

Details zum Clearingprozess kann dem Auszug aus der Gesamtarchitektur "ELGA_Gesamtarchitektur_2.30_Auszug.pdf" entnommen werden.

Es existieren zwei Anwendungsfälle für die bereichsinterne Durchführung der ITI-64 Transaktion:

Link Change
Dieser Anwendungsfall entspricht einem "Link" oder "Unlink" eines lokalen Patienten, d.h. einer Verschiebung eines lokalen Patienten von einer Linkgruppe im L-PI in eine andere.
Die Zuordnung einer lokalen Patient ID (XDSDocumentEntry.sourcePatientId) zu einer ELGA Bereich spezifischen Patient ID (XDSDocumentEntry.patientId, ELGA LPID) ändert sich. In der XDS Registry ändert sich die Patient ID der betroffenen Dokumentreferenzen. Die entsprechenden ELGA-Hash Werte werden ungültig.
Local Merge
Es werden zwei lokale Patient IDs in einem patientenführenden System (z.B. KIS) zusammengeführt. Die Zuordnung zu einer ELGA Bereich spezifischen PatientID (ELGA LPID) in den Dokumentmetadaten kann sich dabei ändern oder nicht ("Merge" innerhalb derselben Linkgruppe im L-PI oder in unterschiedlichen Linkgruppen).

Um die entstandenen ungültigen ELGA-Hash Werte zu korrigieren, wird eine proprietäre ELGA-1 Transaktion definiert.

Details zur ITI-64 Transaktion siehe IHE ITI-TF Supplement "XAD-PID" Change Management (XPID)" (IHE, 2015)

Anmerkung: Der Standard verlangt, dass beim Neuanlegen eines Submission Sets aufgrund einer Änderung der Patienten ID, die XDS Registry das Feld "authorInstitution" nicht befüllt. Da beim Ändern eines Dokumentes in ELGA, die authorInstitution geprüft wird, muss diese auch im neuen Submission Set vorhanden sein und dem Wert des alten Submission Sets entsprechen.

ELGA-1 Transaktion¶

Die ELGA-1 Transaktion wird vom "XPID Manager" Akteur an die ZGF gesendet, um sämtliche ELGA-Hash Werte korrigieren zu lassen, welche durch eine zuvor bereichsintern durchgeführte ITI-64 ungültig wurden.

ELGA-1 entspricht inhaltlich der IHE Transaktion ITI-64 - Notify XAD-PID Link Change. Die im Folgenden verwendeten Bezeichnungen "new XAD-PID", "previous XAD-PID", "local patient ID" und "subsumed local patient ID" der ELGA-1 Transaktion haben dieselbe Bedeutung wie diejenigender IHE Transaktion ITI-64.

Das folgende Diagramm zeigt eine Übersicht der Interaktionen zwischen der ZGF und den direkt beteiligten Komponenten:

Sequenzdiagramm: Verarbeitung der ELGA-1 Transaktion

Der XPID Manager des ELGA Bereichs schickt einen ELGA-1 Request an die ZGF.
Im SOAP-Header muss eine HCP Assertion enthalten sein.
Die ZGF fordert mittels HCP Assertion beim ETS eine Treatment-Assertion an
Das ETS validiert die empfangene HCP Assertion (siehe Generelle Assertion Validierungssemantik)
Schlägt die Validierung fehl, wird ein SOAP Fault retourniert.
Es wird ein Phase 1 A-ARR Audit geschrieben (EventType 51)
Die ZGF erstellt auf Basis der Treatment-Assertion eine Community Assertion.
Die ZGF versucht sämtliche ELGA-Hash Werte in der Registry des Bereichs zu korrigieren, welche durch eine zuvor bereichsintern durchgeführte ITI-64 ungültig wurden. Die Dokumente werden mittels ITI-18 Registry Stored Query (FindDocuments) gesucht. Die Korrektur wird mittels ITI-57 Transaktion, Trigger Event "NonVersioningUpdate" durchgeführt.
Voraussetzung für die Durchführung ist eine vorhandene gültige Kontaktbestätigung für denjenigen Patienten, wohin die Dokumente verschoben wurden.
Zusätzlich fällt die ELGA-1 Transaktion nicht unter das Recht auf Richtigstellung und es müssen, wie in ELGA üblich, die entsprechenden Berechtigungen vorhanden sein.
In diesem Fehlerfall wird eine wst:RequestFailed SOAP Fault zurückgegeben.
Die Transaktionsklammer der empfangenen ELGA-1 Nachricht wird von der ZGF als Transaktions ID (Transaktionsklammer) in den ITI-18 und ITI-57 Nachrichten mitgeschickt.
Es werden 2 A-ARR Audits geschrieben (EventType 52 und 53)
Es werden 2 L-ARR Audits geschrieben (EventType 52 und 53)
Die ZGF schickt eine ELGA-1 Response Nachricht an den ELGA Bereich.

Semantik der Nachricht¶

Der XPID Manager erstellt eine HL7v3 "Patient Registry Duplicates Resolved" (PRPA_IN201304UV02) Nachricht / Trigger Event PRPA_TE201304UV02.

Die Nachricht entspricht einer IHE ITI-44 Patient Identity Merge Nachricht mit den folgenden vorgeschriebenen Änderungen (es sind nur die Erweiterungen und Änderungen angeführt).

Beschreibung der IHE ITI-44 Transaktion siehe IHE_ITI_TF_Vol2b.pdf, Kapitel 3.44 Patient Identity Feed HL7 V3 (IHE, 2013)

Beschreibung der IHE ITI-44 Patient Identity Merge Nachricht siehe IHE_ITI_TF_Vol2b.pdf, Kapitel 3.44.4.2 Patient Identity Management – Patient Identity Merge (IHE, 2013)

Transmission Wrapper

Das Informationsmodel des Transmission Wrappers entspricht dem von IHE definierten HL7v3 Send Message Payload Information Model (MCCI_RM000100IHE) mit folgenden Bedingungen:

../sender/device/id/@root	OID des ELGA Bereichs
../receiver/device/id/@root	OID der empfangenden ZGF

Datenelemente: ELGA-1 Transmission Wrapper

Control Act Wrapper

Das Informationsmodel des Control Act Wrappers entspricht dem von IHE definierten HL7v3 Master File/Registry Event Notification Control Act (Role Subject) Information Model (MFMI_MT700701IHE) mit folgender Erweiterung:

ControlActProcess/reasonCode/ Attribut	Inhalt
@code	"XPID"

Datenelemente: ELGA-1 Control Act Wrapper

IHE Referenz: IHE_ITI_TF_Vol2x.pdf, Kapitel O.2.1 (IHE_ITI_TF_Vol2x, 2016)

Message Content - Anwendungsfall Link Change

Abbildung von "new XAD-PID", "local patient ID" und "previous XAD-PID" gemäß IHE Transaktion ITI-64 - Notify XAD-PID Link Change in der Nachricht:

PRPA_IN201304UV02 Element	Bedeutung
RegistrationEvent/Subject1/Patient/id [1]	new XAD-PID
RegistrationEvent/Subject1/Patient/id [2]	local patient ID
RegistrationEvent/ReplacementOf/PriorRegistration/ Subject1/PriorRegisteredRole/id	previous XAD-PID

Datenelemente: ELGA-1 Link Change

Beispielnachricht:

ELGA-1 Link Change Rq.xml

Message Content - Anwendungsfall Local Merge

Abbildung von "new XAD-PID", "local patient ID", "previous XAD-PID" und "subsumed local patient ID" gemäß IHE Transaktion ITI-64 - Notify XAD-PID Link Change in der Nachricht:

PRPA_IN201304UV02 Element	Bedeutung
RegistrationEvent/Subject1/Patient/id [1]	new XAD-PID
RegistrationEvent/Subject1/Patient/id [2]	local patient ID
RegistrationEvent/ReplacementOf/PriorRegistration/ Subject1/PriorRegisteredRole/id [1]	previous XAD-PID
RegistrationEvent/ReplacementOf/PriorRegistration/ Subject1/PriorRegisteredRole/id [2]	subsumed local patient ID

Datenelemente: ELGA-1 Local Merge

Beispielnachricht:

ELGA-1 Local Merge Rq.xml

ELGA-1 Response¶

Die Responsenachricht ist eine Standard HL7v3 Accept Acknowledgement Nachricht (MCCI_MT000200UV01)

IHE Referenz: IHE_ITI_TF_Vol2x.pdf, Kapitel O.1.2 (IHE_ITI_TF_Vol2x, 2016)

Die ELGA-1 Response Nachricht wird von der ZGF an den ELGA Bereich geschickt, nachdem von der ZGF versucht wurde, eventuell ungültige ELGA Hashes in der XDS Registry des Bereichs zu korrigieren. Fehlermeldungen der XDS Registry, welche während der Verarbeitung der ITI-18 oder ITI-57 Transaktion entstehen, werden von der ZGF in die ELGA-1 Response übernommen.

Allgemeine transaktions-relevante Attribute der ELGA-1 Response Nachricht:

../sender/device/id/@root

OID der ZGF

../acknowledgement/typeCode/@code

Antwortcode der Nachricht

Mögliche Inhalte:

"CA" – Accept Acknowledgement Commit Accept,
wenn die Einmeldung erfolgreich war

"CE" – Accept Acknowledgement Commit Error, wenn bei der Verarbeitung ein Fehler aufgetreten ist

"CR" – Accept Acknowledgement Commit Reject,
wenn keine gültige Kontaktbestätigung für denjenigen Patienten, wohin die Dokumente verschoben wurden, vorliegt
Hinweis: In der derzeitigen BeS Version wird ein SOAP Fault statt ein "CR" zurückgeliefert, dies soll in einer zukünftigen BeS Release behoben werden.

Datenelemente: ELGA-1 Response

ELGA-1 Response Antwortdetails:

In den Antwortdetails werden Fehler- oder Hinweismeldungen geliefert, welche bei der Verarbeitung durch die ZGF generiert werden. Antwortdetails sind nur Teil der Nachricht, wenn ein Hinweis oder Fehler an das anfragende System übermittelt werden muss.

Attribut	Beschreibung
../acknowledgementDetail/@typeCode	Beschreibung, um welche Art von Meldung es sich handelt: "I" = Information (Hinweismeldung) "E" = Error (Fehlermeldung)
../acknowledgementDetail/code/@code	Spezifischer Code der Fehler- oder Hinweismeldung (siehe nächste Tabelle)
../acknowledgementDetail/text	Text der Fehler- oder Hinweismeldung
../acknowledgementDetail/location	Optionaler Pfad zum Element, welches in der Anfrage zur Generierung der Hinweis- bzw. Fehlermeldung geführt hat.

Datenelemente: ELGA-1 Response Detail

Folgende Fehlercodes (../acknowledgementDetail/code/@code) werden von der ZGF in den Antwortdetails der ELGA-1 Response Nachricht zurückgeliefert:

code	type-Code	text
NewXadPidEqualsPreviousXadPid	I	"New XAD-PID == Previous XAD-PID (Link Change)"
NoDocumentForNewXadPid	I	"No Document found with new XAD-PID" <new XAD-PID der ELGA-1 Nachricht>
NoDocumentForPreviousXadPid	I	"No Document found with previous XAD-PID" <previous XAD-PID der ELGA-1 Nachricht>
NoDocumentForLocalPatientId	I	"No Document found with local patient ID" <local patient ID der ELGA-1 Nachricht>
NoDocumentForSubsumedLocalPatientId	I	"No Document found with subsumed local patient ID " <subsumed local patient ID der ELGA-1 Nachricht>
NoDocumentToUpdate	I	NoDocumentToUpdate
LocalPatientIdMissing	E	"LocalPatientIdMissing (second repetition of RegistrationEvent/Subject1/Patient/id)"
PreviousXadPidMissing	E	"PreviousXadPidMissing (RegistrationEvent/ReplacementOf/PriorRegistration/ Subject1/PriorRegisteredRole/id)"
UnexpectedDocumentStatus	E	"Document was expected to be deprecated" <DocumentUniqueId>
XdsRegistryQueryError	E	<Inhalt des gesamten RegistryResponse Elements der ITI-18 Transaktion>
XdsRegistryUpdateError	E	<Inhalt des gesamten RegistryResponse Elements der ITI-57 Transaktion>
MetadataHashMismatch	E	"Metadata hash mismatch detected for document"
XpidInvalidRequest	E	"Internal Request validation failed"
XpidProcessingFailed	E	"Internal Processing Error"

Tabelle: ELGA-1 Response Fehlermeldungen

Beispielnachricht:

ELGA-1 Ack Rsp.xml

Audit Record des Client Actors im ELGA Bereich (L-ARR)¶

IHE verlangt die Gruppierung von Akteuren der XDS Domäne mit dem Secure Node oder Secure Application Actor des ATNA Profils und damit die Erstellung eines Audit Records. Die folgenden Tabellen beschreiben die erforderlichen Inhalte des Audit Records im ELGA Kontext.

	Feld Name	Opt	Inhalt
Event AuditMessage/ EventIdentification	EventID	M	EV("110110", "DCM", "Patient Record")
	EventActionCode	M	"U" (Update)
	EventDateTime	M
	EventOutcomeIndicator	M
	EventTypeCode	M	EV("51", "ELGA_AuditEventType_VS", "Notify ELGA XAD-PID Link Change")
Source (1)
Destination (1)
Human Requestor (1)
Audit Source (1)
New PatientId (1)
SourcePatientId (1)
Previous PatientId (1)
Subsumed SourcePatientId (0..1)
ELGA Transaction (1)

Source AuditMessage/ ActiveParticipant	UserID	M	OID des Senders (ControlActProcess/reasonCode//sender/device/id/@root der Nachricht)
	AlternativeUserID	M	Prozess ID / Kennung des Prozesses
	UserName	U
	UserIsRequestor	M	"true"
	RoleIDCode	M	EV("110153", "DCM", "Source")
	NetworkAccessPointTypeCode	M	"1" bei hostname, "2" für die IP Addresse
	NetworkAccessPointID	M	Hostname oder IP Adresse gemäß RFC3881 Kapitel 5.3 Network Access Point Identification

Destination AuditMessage/ ActiveParticipant	UserID	M	SOAP Endpunkt URI der empfangenden ZGF
	AlternativeUserID	U
	UserName	U
	UserIsRequestor	M	"false"
	RoleIDCode	M	EV("110152", "DCM", "Destination")
	NetworkAccessPointTypeCode	M	"1" bei hostname, "2" für die IP Addresse
	NetworkAccessPointID	M	Hostname oder IP Adresse gemäß RFC3881 Kapitel 5.3 Network Access Point Identification

Human Requestor AuditMessage / ActiveParticipant	UserID	M	<XSPA Subject>@<XSPA Organisation Id> der HCP Assertion
	AlternativeUserID	U
	UserName	U
	UserIsRequestor	M	"true"
	RoleIDCode	M	EV(<code>,<codeSystemName>,<displayName>) des SAML2 Attributes <urn:oasis:names:tc:xacml:2.0:subject:role> der HCP Assertion
	NetworkAccessPointTypeCode	U
	NetworkAccessPointID	U

Audit Source AuditMessage / AuditSourceIdentification	AuditSourceID	U
	AuditEnterpriseSiteID	U
	AuditSourceTypeCode	U

newPatientId AuditMessage / ParticipantObjectIdentification	ParticipantObjectTypeCode	M	"1" (Person)
	ParticipantObjectTypeCodeRole	M	"1" (Patient)
	ParticipantObjectID	M	Die "new XAD-PID" im HL7v2 CX Format
	ParticipantObjectIDTypeCode	M	EV("2", "RFC-3881", "Patient Number") siehe RFC 3881 Kapitel 5.5.4 Participant Object ID Type Code
	ParticipantObjectDataLifeCycle	U
	ParticipantObjectSensitivity	U
	ParticipantObjectName	U
	ParticipantObjectQuery	U
	ParticipantObjectDetailType	U
	ParticipantObjectDetailValue	U

sourcePatientId AuditMessage / ParticipantObjectIdentification	ParticipantObjectTypeCode	M	"1" (Person)
	ParticipantObjectTypeCodeRole	M	"1" (Patient)
	ParticipantObjectID	M	Die "local Patient ID" im HL7v2 CX Format
	ParticipantObjectIDTypeCode	M	EV("2", "RFC-3881", "Patient Number") siehe RFC 3881 Kapitel 5.5.4 Participant Object ID Type Code
	ParticipantObjectDataLifeCycle	U
	ParticipantObjectSensitivity	U
	ParticipantObjectName	U
	ParticipantObjectQuery	U
	ParticipantObjectDetailType	U
	ParticipantObjectDetailValue	U

previousPatientId AuditMessage / ParticipantObjectIdentification	ParticipantObjectTypeCode	M	"1" (Person)
	ParticipantObjectTypeCodeRole	M	"1" (Patient)
	ParticipantObjectID	M	Die "previous XAD-PID" im HL7v2 CX Format
	ParticipantObjectIDTypeCode	M	EV("2", "RFC-3881", "Patient Number") siehe RFC 3881 Kapitel 5.5.4 Participant Object ID Type Code
	ParticipantObjectDataLifeCycle	U
	ParticipantObjectSensitivity	U
	ParticipantObjectName	U
	ParticipantObjectQuery	U
	ParticipantObjectDetailType	U
	ParticipantObjectDetailValue	U

previousSourcePatientId AuditMessage / ParticipantObjectIdentification	ParticipantObjectTypeCode	M	"1" (Person)
	ParticipantObjectTypeCodeRole	M	"1" (Patient)
	ParticipantObjectID	M	Die "subsumed local Patient ID" im HL7v2 CX Format
	ParticipantObjectIDTypeCode	M	EV("2", "RFC-3881", "Patient Number") siehe RFC 3881 Kapitel 5.5.4 Participant Object ID Type Code
	ParticipantObjectDataLifeCycle	M	EV("7", "RFC-3881", "De-identification") siehe RFC 3881 Kapitel Participant Object Data Life Cycle
	ParticipantObjectSensitivity	U
	ParticipantObjectName	U
	ParticipantObjectQuery	U
	ParticipantObjectDetailType	U
	ParticipantObjectDetailValue	U

ELGA Transaction AuditMessage / ParticipantObjectIdentification	Participant Object Type Code	M	"2" (System)
	Participant Object Type Code Role	M	"13" (Security Resource)
	Participant Object ID	M	<Transaktions-ID (Transaktionsklammer)>
	Participant Object ID Type Code	M	EV("0","ELGA_AuditParticipantObjectIdType_VS", "Transaktions ID")
	Participant Object Sensitivity	U
	Participant Object Name	U
	Participant Object Query	U
	Participant Object Detail Type	M	"wsa:MessageID"
	Participant Object Detail Value	M	Die WS-Addressing MessageID base-64 kodiert
	Participant Object Detail Type	M	"Ergebnismeldung"
	Participant Object Detail Value	M	Erfolgs- oder Fehlermeldung base-64 kodiert

Verarbeitung der ELGA-1 Transaktion durch die ZGF¶

Die ZGF validiert die empfangene HCP Assertion (siehe Generelle Assertion Validierungssemantik)

Schlägt die Validierung fehl, wird ein SOAP Fault zurückgegeben.

Die ZGF prüft, ob eine gültige Kontaktbestätigung für denjenigen Patienten, wohin die Dokumente verschoben wurden (new XAD-PID) vorliegt, indem eine Treatment-Assertion vom ETS angefordert wird – (siehe Treatment-Assertions (Delegierte Assertions)).

Schlägt die Prüfung fehl, wird ein SOAP Fault zurückgegeben.
Das ETS erstellt einen AARR Audit Event "Notify ELGA XAD-PID Link Change"

Die ZGF erstellt auf Basis der Treatment-Assertion eine Community Assertion, welche für alle Folgetransaktionen verwendet wird.

Die ZGF wertet den Inhalt des ELGA-1 Request bezüglich vorhandener Patient IDs aus.

Fehlt die "local Patient ID" (RegistrationEvent/Subject1/Patient/id[2]), wird der Fehler "LocalPatientIdMissing" zurückgegeben.
Fehlt die "previous XAD-PID" (RegistrationEvent/ReplacementOf/PriorRegistration/ Subject1/PriorRegisteredRole/id [2]), wird der Fehler "PreviousXadPidMissing" zurückgegeben.

Die Transaktionsklammer der empfangenen ELGA-1 Nachricht wird von der ZGF als Transaktions ID (Transaktionsklammer) in allen Folgetransaktionen mitgeschickt.

Anwendungsfall Link Change¶

Suche nach "neuen Dokumenten":

Die ZGF sucht in der Registry des Bereichs mittels ITI-18 Registry Stored Query - FindDocuments nach Dokumenten mit der PatientID "New XAD-PID" und Status "approved".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForNewXadPid" zurückgegeben.

Die ZGF filtert innerhalb der Ergebnisliste nach Dokumenten mit der SourcePatientId "local Patient ID".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForLocalPatientId" zurückgegeben.

Suche nach "alten Dokumenten":

Die ZGF sucht in der Registry des Bereichs mittels ITI-18 Registry Stored Query - FindDocuments nach Dokumenten mit der PatientID "Previous XAD-PID" und Status "approved" und "deprecated".

Werden keine Dokumente mit status "deprecated" gefunden, wird die Hinweismeldung "NoDocumentForPreviousXadPid" zurückgegeben.

Die ZGF prüft, ob in der Ergebnisliste Dokumente mit der SourcePatientId "local Patient ID" und Status "approved" vorhanden sind.

Werden Dokumente gefunden, wird der Fehler "UnexpectedDocumentStatus" zurückgegeben.

Die ZGF filtert innerhalb der Ergebnisliste nach Dokumenten mit der SourcePatientId "local Patient ID" und Status "deprecated".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForLocalPatientId" zurückgegeben.

Die ZGF prüft ob ein Dokument bereits von der ZGF mit einem inaktiven ELGA-Hash versehen wurde. - ein inaktiver ELGA-Hash ist ein Wert der von der ZGF für deprecated Dokumente im Zuge der ELGA-1 Transaktion gesetzt wird. - wird dieser Wert als ELGA-Hash gefunden wird dieses Dokument nicht erneut aktualisiert

Die ZGF prüft bei allen "neuen" und "alten" Dokumenten ob der aktuelle ELGA Hash bereits der korrekte neue ELGA-Hash ist.

ist der aktuelle ELGA-Hash bereits der neue korrekte ELGA-Hash wird dieses Dokument nicht erneut aktualisiert.

Die ZGF prüft bei allen "neuen" und "alten" Dokumenten den ELGA-Hash.

Die ZGF errechnet für jedes Dokument den ELGA-Hash mit denjenigen Patienten IDs und dem Status, welche vor der Änderung in Verwendung waren.
Schlägt die ELGA-Hash Prüfung - gemäß oben angeführter Berechnung - fehl, wird der Fehler "MetadataHashMismatch" zurückgegeben.

Wenn durch die Filterung keine "neuen" und "alten" Dokumente für ein Update vorhanden sind, wird die Hinweismeldung "NoDocumentToUpdate" zurückgegeben.

Die ZGF korrigiert mittels ITI-57 Transaktion, Trigger Event "NonVersioningUpdate" den ELGA-Hash der "neuen" Dokumente und setzt das ELGA-Flag der "alten" Dokumente auf "false" (eine ITI-57 Transaktion kann mehrere "NonVersioningUpdate" Associations enthalten).

Die Dokumente werden aus dem Cache der ZGF entfernt.

Die ZGF erstellt einen ATNA Audit Event "Notify ELGA XAD-PID Link Change" im L-ARR.

Die ZGF erstellt einen A-ARR Audit Event "Registrieren von Dokumenten im Rahmen eines Clearings" für den Patienten mit der Patient ID "new XAD-PID" mit einer Referenz auf sämtliche "neue" Dokumente (d.h. Dokumentreferenzen, welche für diesen Patienten neu registriert wurden).

Die ZGF erstellt einen A-ARR Audit Event "Stornieren von Dokumenten im Rahmen eines Clearings" für den Patienten mit der Patient ID "previous XAD-PID" mit einer Referenz auf sämtliche "alte" Dokumente (d.h. Dokumentreferenzen, welche für diesen Patienten aus ELGA entfernt wurden).

Anwendungsfall Local Merge¶

Suche nach "neuen Dokumenten":

Die ZGF sucht in der Registry des Bereichs mittels ITI-18 Registry Stored Query - FindDocuments nach Dokumenten mit der PatientID "New XAD-PID" und Status "approved".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForNewXadPid" zurückgegeben.

Die ZGF filtert innerhalb der Ergebnisliste nach Dokumenten mit der SourcePatientId "local Patient ID".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForLocalPatientId" zurückgegeben.

Suche nach "alten Dokumenten":

Die ZGF sucht in der Registry des Bereichs mittels ITI-18 Registry Stored Query - FindDocuments nach Dokumenten mit der PatientID "Previous XAD-PID" und Status "approved" und "deprecated".

Werden keine Dokumente mit Status "deprecated" gefunden, wird die Hinweismeldung "NoDocumentForPreviousXadPid" zurückgegeben.

Die ZGF prüft, ob in der Ergebnisliste Dokumente mit der SourcePatientId "subsumed local Patient ID" und Status "approved" vorhanden sind.

Werden Dokumente gefunden, wird der Fehler "UnexpectedDocumentStatus" zurückgegeben.

Die ZGF filtert innerhalb der Ergebnisliste nach Dokumenten mit der SourcePatientId "subsumed local Patient ID" und Status "deprecated".

Werden keine Dokumente gefunden, wird die Hinweismeldung "NoDocumentForSubsumedLocalPatientId" zurückgegeben.

Die ZGF prüft ob ein Dokument bereits von der ZGF mit einem inaktiven ELGA-Hash versehen wurde. - ein inaktiver ELGA-Hash ist ein Wert der von der ZGF für deprecated Dokumente im Zuge der ELGA-1 Transaktion gesetzt wird. - wird dieser Wert als ELGA-Hash gefunden wird dieses Dokument nicht erneut aktualisiert

Die ZGF prüft bei allen "neuen" und "alten" Dokumenten ob der aktuelle ELGA Hash bereits der korrekte neue ELGA-Hash ist.

ist der aktuelle ELGA-Hash bereits der neue korrekte ELGA-Hash wird dieses Dokument nicht erneut aktualisiert.

Die ZGF prüft bei allen "neuen" und "alten" Dokumenten den ELGA-Hash.

Die ZGF errechnet für jedes Dokument den ELGA-Hash mit denjenigen Patienten IDs und dem Status, welche vor der Änderung in Verwendung waren.
Schlägt die ELGA-Hash Prüfung fehl, wird der Fehler "MetadataHashMismatch" zurückgegeben.

Wenn durch die Filterung keine "neuen" und "alten" Dokumente für ein Update vorhanden sind, wird die Hinweismeldung "NoDocumentToUpdate" zurückgegeben.

Die ZGF korrigiert mittels ITI-57 Transaktion, Trigger Event "NonVersioningUpdate" den ELGA-Hash der "neuen" Dokumente und setzt das ELGA-Flag der "alten" Dokumente auf "false" (eine ITI-57 Transaktion kann mehrere "NonVersioningUpdate" Associations enthalten).

Die Dokumente werden aus dem Cache der ZGF entfernt.

Die ZGF erstellt einen ATNA Audit Event "Notify ELGA XAD-PID Link Change" im L-ARR.

Die ZGF erstellt einen A-ARR Audit Event "Registrieren von Dokumenten im Rahmen eines Clearings" für den Patienten mit der Patient ID "new XAD-PID" mit einer Referenz auf sämtliche "neue" Dokumente (d.h. Dokumentreferenzen, welche für diesen Patienten neu registriert wurden).

Die ZGF erstellt einen A-ARR Audit Event "Stornieren von Dokumenten im Rahmen eines Clearings" für den Patienten mit der Patient ID "previous XAD-PID" mit einer Referenz auf sämtliche "alte" Dokumente (d.h. Dokumentreferenzen, welche für diesen Patienten aus ELGA entfernt wurden).

Tritt während der Verarbeitung von XDS Transaktionen (ITI-18 oder ITI-57) ein Fehler auf, wird der Registry Error aus dem Bereich von der ZGF in die ELGA-1 Response übernommen.

Anbindung ELGA Bürgerportal (EBP)¶

Die gesamte Kommunikation des ELGA Bürgerportals wird mittels einer EBP spezifischen AGW (ZGF EBP) entweder zu den Zentralkomponenten des Berechtigungssystems weitergeleitet oder von der ZGF EBP applikatorisch geprüft. Als Kommunikationsmittel wird für alle dokumentenbezogenen Zugriffe das IHE XDS.b Profil eingesetzt. Die gesamte nicht dokumentenbezogene Kommunikation wird mit einem Protokoll realisiert, das vom WS-Trust abgeleitet und zweckangepasst wurde. Für alle Verbindungen wird https TLS V1.2 eingesetzt.

Siehe: Aufbau des Berechtigungssystems, SAML Assertion Übersicht, Einbetten von Security Assertion

User I-Assertion anfordern¶

Siehe: User I-Assertion, Bürgerkartenumgebung Assertion (BKUA)

Das Bürgerportal sendet eine WS Trust RST Issue Transaktion an die AGW des EBP, um den ELGA Teilnehmer bei ELGA anzumelden
- Im Security Header der Nachricht befindet sich eine SAML2 Assertion der Bürgerkartenumgebung (BKUA)
Der Apache der Bürgerportal AGW schickt die Nachricht zum ETS weiter
Die User I-Assertion wird in der WS Trust RSTR zurückgeliefert
Bei der Ausstellung der Assertion am ETS wird zursätzlich zum Z-L-ARR eventType 21 ein A-ARR Audit mit eventType "25" (BürgerIn Anmeldung) erstellt.
Für alle nachfolgenden Transaktionen an die Komponenten des BeS muss vom Bürgerportal die User I-Assertion verwendet werden
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Läuft eine Benutzersession ab oder wurde invalidiert, muss auch die User I-Assertion beim ETS invalidiert werden (Invalidieren von Login Assertions).

User I RST Issuer Anfrage¶

Die User I RST Issue Transaktion fragt beim ETS um eine ELGA User I-Assertion an.

Datenelemente User I RST:

Element	Beschreibung
wst:RequestType	http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
wst:TokenType	"urn:elga:bes:2013:user:assertion:1" Wird verwendet, um die unterschiedlichen Token Typen unterscheiden zu können.

Datenelemente: User I RST Issuer Anfrage

ETS IssueUserI Rq.xml

Interface: User I RST Issuer Anfrage

User I RSTR Issuer Antwort¶

Die ELGA User I-Assertion wird mittels RSTR an den Anfragenden zurückgeliefert.

Datenelemente User I RSTR:

Element	Beschreibung
RequestSecurityTokenResponseCollection	RequestSecurityTokenResponseCollection (RSTRC) muss in der abschließenden Antwort an eine RST Anfrage verwendet werden, um ein Security Token zu retournieren
RequestSecurityTokenResponse	Body der Antwort
TokenType	urn:elga:bes:2013:user:assertion:1
RequestedSecurityToken	Beinhaltet die ELGA SAML2 User I-Assertion

Datenelemente: User I RSTR Issuer Antwort

ETS IssueUserI Rsp.xml

Interface: User I RSTR Issuer Antwort

Mandate I-Assertion anfordern¶

Siehe: Mandate I-Assertion, Bürgerkartenumgebung Mandate Assertion (BKUAM)

Das Bürgerportal sendet eine WS Trust RST Issue Transaktion an die ZGF des EBP, um den Bevollmächtigten bei ELGA anzumelden
- Im Security Header der SOAP Nachricht befindet sich eine SAML2 Assertion der Bürgerkartenumgebung (BKUAM), welche Identitätsattribute, Rollenattribute und Zugriffsart des bevollmächtigten ELGA Teilnehmers, wie auch Identitäts- und Rollenattribute des vollmachtgebenden ELGA Teilnehmers beinhaltet
Der Apache der Bürgerportal AGW leitet die Nachricht zum ETS weiter
Die Mandate I-Assertion wird in der WS Trust RSTR zurückgeliefert
Bei der Ausstellung der Assertion am ETS wird zusätzlich zum Z-L-ARR eventType 21 ein A-ARR Audit mit eventType "26" (BürgerIn Anmeldung in Vertretung) erstellt
Für alle nachfolgenden Transaktionen an die Komponenten des BeS, muss vom Bürgerportal die Mandate I-Assertion verwendet werden
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Mandate I RST Issuer Anfrage¶

Die Mandate I RST Issue Transaktion fragt beim ETS um eine ELGA Mandate I-Assertion an.

Datenelemente Mandate I RST

wst:RequestType

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue

wst:TokenType

EBP: "urn:elga:bes:2013:mandate:assertion:1"

WIST: "urn:elga:bes:2013:mandate:assertion:WIST"

OBST/eHS: "urn:elga:bes:2013:mandate:assertion:OBST:1" Wird verwendet, um die unterschiedlichen Token Typen unterscheiden zu können.

Datenelemente: Mandate I RST Issuer Anfrage

ETS IssueMandateI Rq.xml

Interface: Mandate I RST Issuer Anfrage

Mandate I RSTR Issuer Antwort¶

Die ELGA Mandate I-Assertion wird mittels RSTR an den Anfragenden zurückgeliefert.

Datenelemente RSTR Mandate I:

Element	Beschreibung
RequestSecurityTokenResponseCollection	RequestSecurityTokenResponseCollection (RSTRC) muss in der abschließenden Antwort an eine RST Anfrage verwendet werden, um ein Security Token zu retournieren
RequestSecurityTokenResponse	Body der Antwort
TokenType	urn:elga:bes:2013:mandate:assertion:1
RequestedSecurityToken	Beinhaltet die ELGA SAML2 Mandate I-Assertion

Datenelemente: Mandate I RSTR Issuer Antwort

ETS IssueMandateI Rsp.xml

Interface: Mandate I RSTR Issuer Antwort

Ombudsstelle (OBST) Mandate I-Assertion¶

Für die OBST wird in ELGA eine Mandate I-Assertion ausgestellt. Die OBST führt in der Mandate I RST Issuer Anfrage eine BKUAM mit. In der BKUAM müssen Attribute vorhanden sein, die die anfragende Stelle eindeutig als OBST kennzeichnet (urn:oid:1.2.40.0.10.2.1.1.261.86 (MOA_MANDATE_PROF_REP_OID) & urn:oid:1.2.40.0.10.2.1.1.261.88 (MOA_MANDATE_PROF_REP_DESCRIPTION)). Außerdem ist die AuthnContextClassRef für die OBST auf http://www.ref.gv.at/ns/names/agiz/pvp/secclass/3" zu setzen. Es wird eine Mandate I-Assertion mit dem Purpose Of Use MANDATE ausgestellt. Anstelle der Rolle "BÜRGER", wird die Rolle "ELGA-Ombudsstelle" (gem. ELGA_Rollen_VS siehe ELGA Value Sets) in die Mandate I-Assertion eingesetzt. Als Organizan-ID wird urn:oid:1.2.40.0.34.3.1.3 in die Mandate I-Assertion eingesetzt. Das Attribute MANDATE-TYPE der BKUAM muss für die Produktionsumgebung den Wert "ELGA-Ombudsstelle" und für andere Stages den Wert "ELGA-Ombudsstelle-TEST" enthalten.

Bei der Ausstellung der Assertion am ETS wird zusätzlich zum Z-L-ARR eventType "21" ein A-ARR Audit mit eventType "27" (BürgerIn Anmeldung der OBST in Vertretung) erstellt.
Das SAML Attribute urn:oid:1.2.40.0.10.2.1.1.261.86 wird gegen folgende RegEx validiert 1.2.40.0.34.3.1.3|1.2.40.0.34.3.1.1234|urn:oid:1.2.40.0.34.3.1.3|urn:oid:1.2.40.0.34.3.1.1234.

eHealth-Servicestelle (eHS) Mandate I-Assertion¶

Die eHS unterscheidet sich von der OBST durch folgende Merkmale:

Das Attribute MANDATE-TYPE der BKUAM muss für die Produktionsumgebung den Wert "eHealth-Servicestelle" und für andere Stages den Wert "eHealth-Servicestelle-TEST" enthalten.
als Rolle (urn:oasis:namesxacml:2.0:subject:role) wird 707 (eHealth-Servicestelle) in die Mandate I-Assertion eingesetzt
als Organization-ID (urn:oasis:namesxspa:1.0:subject:organization-id) wird urn:oid:1.2.40.0.34.3.1.1234 in die Mandate I-Assertion eingesetzt
Es wird ein A-ARR Audit mit eventType "28" (BürgerIn Anmeldung der eHealth-Servicestelle in Vertretung) erstellt.
Das SAML Attribute urn:oid:1.2.40.0.10.2.1.1.261.86 wird gegen folgende RegEx validiert 1.2.40.0.34.3.1.3|1.2.40.0.34.3.1.1234|urn:oid:1.2.40.0.34.3.1.3|urn:oid:1.2.40.0.34.3.1.1234.

Abfragen aller Kontaktbestätigung eines Patienten¶

Siehe: KBS – Kontaktbestätigungsservice

Das Bürgerportal fragt mittels WS Trust RST Status Transaktion, um eine Liste aller Kontaktbestätigungen eines bestimmten Patienten an.

Das Bürgerportal übergibt die bPK-GH des Patienten mittels WS Trust RST an die ZGF des EBP
- Die User I- bzw. Mandate I-Assertion wird im SOAP Security Header mit übergeben.
Der Apache der Bürgerportal AGW leitet die Nachricht zum KBS weiter
In der WS Trust RSTR wird eine Liste der jüngsten Kontaktbestätigungen entsprechend des TRDate (max. 3000 konfigurierbar), und TRType (K105 - K104 – K103 – K101 – K102) absteigend zurückgegeben. Sollte im KBS kein Kontakt für einen Patienten gespeichert sein, wird eine leere RequestSecurityToken-ResponseCollection zurückgegeben.
Im Falle eines identen TRDate und TRType wird als zusätzliches Sortierkriterium der TRStatus (Select Statements) herangezogen, welche folgende Sortier-Reihenfolge vorsieht: "ACTIVE", "INACTIVE", "INVALIDATED", "IGNORED".
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Eingangsdaten für das Abfragen von Kontaktbestätigungen zu einem Patienten:

Element	Beschreibung
User I- oder Mandate I-Assertion	Elternknoten: Security Es muss eine User I- oder Mandate I-Assertion im WS-Security Header inkludiert sein
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS, 2012)
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:list"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS, 2012)
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS, 2012)
wst:ValidateTarget	Elternknoten: wst:RequestSecurityToken Details siehe (OASIS, 2012)
ts:PatientID	Wert={bPK-GH des Patienten im HL7 CX Format} Elternknoten: wst: ValidateTarget bPK-GH des Patienten - HL7 CX Data Type (inkludiert Assigning Authority)

Datenelemente: Eingangsdaten - Abfragen aller Kontaktbestätigungen eines Patienten

Kontaktbestätigungen eines Patienten abfragen – Anfrage:

KBS ListKB Rq.xml

Interface: Abfragen aller Kontaktbestätigung eines Patienten Anfrage

Ausgangsdaten für das Abfragen von Kontaktbestätigungen zu einem Patienten:

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS, 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS, 2012)	R
wst:TokenType	Fester Wert={"urn:elga:kbs:contact:list"} Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS, 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityTokenResponse Details siehe (OASIS, 2012)	R
ts:TR	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestedSecurityToken Enthält Informationen zu einer Kontaktbestätigung.	R
ts:IdentMethod	Werte={"PIM101", "PIM102", "PIM103", "PIM104", "PIM106", "PIM107", "PIM108"} Elternknoten: ts:TR Qualität der Identifikation (z.B. Bürgerkarte anwesend, Stecken der e-card, ...)	R
ts:ProviderOID	Wert={OID des GDA aus dem GDA-Index} Elternknoten: ts:TR OID des behandelnden GDA	R
ts:PatientID	Wert={bPK-GH des Patienten im HL7 CX Format} Elternknoten: wst: ValidateTarget bPK-GH des Patienten - HL7 CX Data Type (inkludiert Assigning Authority)
ts:TRDate	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"} Elternknoten: ts:TR Datum und Zeitpunkt des Behandlungskontaktes	R
ts:TRType	Werte={"K101", "K102", "K103", "K104", "K105"} siehe "ELGA_Kontakttypen" in ELGA Value Sets Elternknoten: ts:TR Qualifikation des Behandlungskontaktes: Ambulanter Kontakt, Aufnahme in eine stationäre Einrichtung, Entlassung aus einer stationären Einrichtung, Überweisung, Internetkontakt.	R
ts:TRStatus	Werte={"ACTIVE", "INACTIVE", "INVALIDATED", "IGNORED"} Elternknoten: ts:TR Status der Kontaktbestätigung: ACTIVE: Aktiver Kontakt zw. Patient und GDA INACTIVE: Ein neuerer Kontakt ist vorhanden INVALIDATED: Kontakt wurde storniert IGNORED: Ein Kontakt wurde empfangen, der ignoriert wurde (z.B. ambulanter Kontakt bei bereits aktiver stationärer Aufnahme)	R
ts:ProviderDelegatedOID	Wert={OID des GDA aus dem GDA-Index} Elternknoten: ts:TR OID des GDA, welcher den Kontakt delegiert hat	O

Datenelemente: Ausgangsdaten - Abfragen aller Kontaktbestätigungen eines Patienten

Kontaktbestätigungen eines Patienten abfragen – Antwort:

KBS ListKB Rsp.xml

Interface: Abfragen aller Kontaktbestätigung eines Patienten - Antwort

Verwaltung individueller Policies¶

Die Verwaltung der individuellen Policies, sowie die Darstellung von Textbausteinen für den Bürger, obliegen dem Bürgerportal. Individuelle Policies unterliegen keiner Größenlimitierung, eine ev. gewünschte Prüfung bzw. Limitierung der Größe muss am eBP erfolgen. Die Schnittstelle zum PAP wird mittels eines von WS Trust abgeleiteten Protokolls RST/RSTR/RSTRC realisiert.

Abfragen der individuellen Policies¶

Anmerkung: Die Abbildung und der Ablauf berücksichtigt nicht die Möglichkeit, diese Anfrage über ein AGW weiterzuleiten. Diese Anforderung ist mit dem Betriebsdienstleister abzustimmen.

Das Bürgerportal fragt mittels RST Status Transaktion beim PAP um die Policies des Patienten an
Die bPK-GH des Patienten wird in der RST Anfrage übergeben. Im Security Header der SOAP Transaktion muss eine User I- bzw. eine Mandate I-Assertion mitgeführt werden
Der PAP validiert die User I- bzw. Mandate I-Assertion
Der PAP lädt die Request Policy, die Response Policy und die Metadaten der zugehörigen signierten Dokumente vom Policy Repository. Mehr als eine Referenz zu einem signierten Dokument kann zurückkommen, wenn ein Policy-Merge vom PAP durchgeführt werden musste (siehe PAP Merge Routine - da die WIST nur schreibenden Zugriff hat, wird vom PAP eine Routine bereitgestellt, die dafür sorgt, dass der initiale Consent des Bürgers berücksichtigt und nicht überschrieben wird. Nachfolgend wird das Verhalten für die verschiedenen Fälle des initialen Consents und des Consents, der durch die WIST eingebracht wird, beschrieben.). Zusätzlich wird eine StateID übermittelt, die die Request und Response Policy eindeutig beschreiben. Diese StateID muss im Falle einer Aktualisierung der Patienteneinwilligung bei den Transaktionen für das Einbringen des Consent mitgeschickt werden.
Es wird ein ATNA Protokolleintrag generiert
Der PAP generiert aus den XACML Policies die RSTR Nachricht und gibt sie an das Bürgerportal zurück
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Eingangsdaten für Consent abfragen (urn:elga:pap:query):

Element	Beschreibung	Opt
User I-/Mandate I-Assertion	Elternknoten: Security Es muss eine User I- bzw. Mandate I-Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:query"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:ValidateTarget	Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ConsentQuery	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:ValidateTarget Beinhaltet die Werte, die für das Query vom PAP benötigt werden.	R
ts:PatientID	Wert={bPK-GH in HL7 CX Format (siehe Patient ID Encoding), Data Type (inkludiert Assigning Authority ‘1.2.40.0.10.2.1.1.149’)} Elternknoten: ts:ConsentQuery	R
ts:ReturnConsentData	Wertebereich={true, false} Elternknoten: ts:ConsentQuery Wenn dieser Wert bei der Abfrage nach individuellen Policies mit ‘true’ übergeben wird, wird die technische Repräsentation der individuellen Policies zurückgeliefert. Wird der Wert ‘false’ übergeben und ‘ReturnSignedDoc’ ist ‘true‘, werden die Metadaten zu den signierten Dokumenten zurückgeliefert.	R2
ts:ReturnSignedDoc	Wertebereich={true, false} Elternknoten: ts:ConsentQuery Wenn dieser Wert bei der Abfrage nach individuellen Policies mit ‘true’ übergeben wird, werden die Metadaten der signierten Dokumente zurückgeliefert. Wird der Wert 'false’ übergeben und ‘ReturnConsentData’ ist ‘true‘, wird nur die technische Repräsentation der individuellen Policies retourniert, nicht aber das signierte Dokument.	R2

Datenelemente: Eingangsdaten - Abfragen der individuellen Policies

Consent Abfrage:

PAP QueryConsent Rq.xml

Interface: Consent Abfrage

Ausgangsdaten für Consent abfragen (urn:elga:pap:query):

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:query"} Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
ts:ElgaToken	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestSecurityToken Response Beinhaltet die Elemente, die den Willen des Patienten widerspiegeln.	R
ts:StateID	Wert={String; Hashwert, der die retournierten Policies eindeutig widerspiegelt} Elternknoten: ts:ElgaToken Wird der Patienten Consent (ReturnConsentData=’true’) abgefragt und in Form von XACML Policies retourniert, wird ebenfalls eine StateID, die diese Policies eindeutig beschreibt, generiert und ebenfalls übermittelt. Diese StateID muss in Folge beim Einbringen des PatientenConsent mitgesendet werden. Wird lediglich das signierte Dokument abgefragt, wird keine StateID übermittelt.	O
ts:IsOptOut	Wertebereich={true, false} Elternknoten: ts:ElgaToken Wenn dieses Feld den Wert 'true' beinhaltet, hat der Bürger OptOut erklärt.	O
ts:ServiceRestrictionList	Werte={ServiceRestriction (1..n)} Elternknoten: ts:ElgaToken Listenelement für Service Einschränkungen (Ausblenden von Services)	O
ts:ServiceRestriction.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceRestrictionList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, die der Bürger ausgeblendet hat.	R
ts:ServiceOptOutList	Werte={ServiceOptOut (1..n)} Elternknoten: ts:ElgaToken Listenelement für OptOut von Services	O
ts:ServiceOptOut.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceOptOutList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, für die der Bürger OptOut bzw. ein ReOptIn erklärt hat. Wurde ein ReOptIn durchgeführt, muss eine reOptInDateTime angegeben werden.	R
ts:ServiceOptOut.reOptInDateTime	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss'Z'"} Folgende Datumsformate werden unterstützt: yyyy-MM-dd’T’HH:mm:ss Elternknoten: ts:ServiceOptOutList Der Zeitstempel des letzten ReOptIn, für das jeweilige Service, wird vom Bürgerportal gesetzt, wenn ein Patient, der OptOut erklärt hatte, für einen Service wieder teilnimmt. Für diesen Wert wird vom PAP eine ReOptIn Service Policy in der Individuelle Response Policy hinzugefügt.	O
ts:ServiceDeletionList	Werte={ServiceDeletion (1..n)} Elternknoten: ts:ElgaToken Listenelement für Services, die gelöscht wurden	O
ts:ServiceDeletion.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceDeletionList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, die der Bürger gelöscht hat.	R
ts:ServiceDeletion.deletionDateTime	Wert={Zeitstempel im Format "yyyy-MM-dd‘T‘HH:mm:ss.SSS‘Z‘"} Elternknoten: ts:ServiceDeletionList Zeitstempel des letzten Löschens für den Service. Wird vom Bürgerportal gesetzt, wenn ein Patient einen Service löschen möchte. Für diesen Wert wird vom PAP eine Service Deletion Policy (urn:elga:bes:2013:1.2.3.2.2.2.2) in der Individuelle Response Policy hinzugefügt.	R
ts:ProviderRestrictionList	Werte={ProviderRestriction (1..n)} Elternknoten: ts:ElgaToken Listenelement für GDA Zeiteinschränkungen bzw. -erweiterungen	O
ts:ProviderRestriction.providerID	Wert={urn:oid: OID des GDA aus dem GDA-Index} Elternknoten: ts:ProviderRestrictionList OID des GDAs für den zeitliche Einschränkungen bzw. Erweiterungen gesetzt wurden	R
ts:ProviderRestriction.days	Wertebereich={0..365} Elternknoten: ts:ProviderRestrictionList Zeitraum in Tagen, die der GDA Zugriff auf Daten nach dem letzten Behandlungskontakt hat.	R
ts:DocumentRestrictionList	Werte={DocumentRestriction (1..n)} Elternknoten: ts:ElgaToken Listenelement für Dokumenteneinschränkungen	O
ts:DocumentRestriction.id	Wert={referenceIdList-Eintrag für "urn:elga.iti:xds:2014:ownDocument_setId", Format siehe ( (ELGA, 2014)), Kapitel "2.2.17 referenceIdList"} Elternknoten: ts:DocumentRestrictionList XDSDocumentEntry.referenceIdListdes Dokuments, das ausgeblendet wurde.	R
DocumentDeletionList	Werte={DocumentDeletion (1..n)} Elternknoten: ts:ElgaToken Listenelement für Dokumentenlöschungen	O
ts:DocumentDeletion.id	Wert={referenceIdList-Eintrag für "urn:elga.iti:xds:2014:ownDocument_setId", Format siehe ( (ELGA, 2014)), Kapitel "2.2.17 referenceIdList"} Elternknoten: ts:DocumentDeletionList XDSDocumentEntry.referenceIdListInformation des Dokuments, das gelöscht wurde. Diese Id wird in die Quarantäneliste aufgenommen und zusätzlich in eine Policy eingetragen, um den Zugriff für GDA zu untersagen.	R
ts:SignedDocumentList	Wert={SignedDocument (1..n)} Elternknoten: ts:ElgaToken Listenelement für Patienteneinwilligungen (PDF)	O
ts:SignedDocument.id	Wert={Dokument-Referenz als UUID} Eindeutige Identifikation für die Patienteneinwilligung, mit welcher diese abgefragt werden kann.	R
ts:SignedDocument.creationDateTime	Wert={Zeitstempel im Format "yyyy-MM-dd‘T‘HH:mm:ss.SSS'Z'"} Datum, an welchem die Patienteneinwilligung im PAP gespeichert wurde.	R

Datenelemente: Ausgangsdaten - Abfragen der individuellen Policies

Consent Abfrage Antwort:

PAP QueryConsent Rsp.xml

Interface: Consent Abfrage Antwort

Umwandlung von XACML Policies¶

Aus den geladenen XACML Policies vom Policy Repository werden die Daten aus den individuellen Request und Response Policies extrahiert. Die Daten: isOptOut, ServiceRestrictionList und ProviderRestrictionList werden aus den Request Policies und die Daten: ServiceOptOutList mit reOptInDateTime, DocumentRestrictionList und DocumentDeletionList werden aus der Response Policy in die RSTR übernommen. Zusätzlich sind Metadaten der zugehörigen, signierten Dokumente in die RSTR eingebettet.

Abfragen des signierten Dokuments¶

Vorbedingung: Abfragen der individuellen Policies
Das Bürgerportal fragt mittels RST Status Transaktion beim PAP um ein signiertes Dokument des Patienten an.
Die bPK-GH des Patienten und die UUID des abzufragenden signierten Dokuments wird in der RST Anfrage übergeben. Im Security Header der SOAP Transaktion muss eine User I- bzw. eine Mandate I-Assertion mitgeführt werden.
Der PAP validiert die User I- bzw. Mandate I-Assertion
Der PAP ladet das signierte Dokument anhand der UUID vom Policy Repository.
Es wird ein ATNA Protokolleintrag generiert
Der PAP bettet das base64 kodierte, signierte Dokument in die RSTR Nachricht und gibt sie an das Bürgerportal zurück.

Eingangsdaten für signiertes Dokument abfragen (urn:elga:pap:retrieve:signed:doc):

Element	Beschreibung	Opt
User I-/Mandate I-Assertion	Elternknoten: Security Es muss eine User I bzw. Mandate I-Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:retrieve:signed:doc"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:ValidateTarget	Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ConsentRetrieve	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:ValidateTarget Beinhaltet die Werte, die für das Retrieve des signierten Dokuments vom PAP benötigt werden.	R
ts:PatientID	Wert={bPK-GH in HL7 CX Format (siehe Patient ID Encoding), Data Type (inkludiert Assigning Authority ‘1.2.40.0.10.2.1.1.149’)} Elternknoten: ts:ConsentQuery	R
ts:SignedDocument.id	Wert={Dokument-Referenz als UUID} Elternknoten: ts:ConsentQuery Eindeutige Referenz auf das signierte Dokument mittels UUID, auf das abgefragt wird.	R

Datenelemente: Eingangsdaten - Abfragen des signierten Dokuments

Abfrage des signierten Dokuments:

PAP RetrieveSignedDocument Rq.xml

Interface: Abfrage des signierten Dokuments

Ausgangsdaten für signiertes Dokument abfragen (urn:elga:pap:retrieve:signed:doc):

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:retrieve:signed:doc"} Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
ts:ElgaToken	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestSecurityToken Response Beinhaltet das Element, das das signierte Dokument enthält	R
ts:SignedDocData	Wertebereich={Base64 encoded signiertes Dokument} Elternknoten: ts:ElgaToken Beinhaltet das abgefragte, signierte, base64 encoded Dokument.	R

Datenelemente: Ausgangsdaten - Abfragen des signierten Dokuments

Abfrage des signierten Dokuments - Antwort:

PAP RetrieveSignedDocument Rsp.xml

Interface: Abfrage des signierten Dokuments - Antwort

Einbringen der individuellen Policies¶

Die Schnittstelle zum Einbringen von individuellen Policies wird mittels eines von WS Trust abgeleiteten Protokolls RST/RSTR/RSTRC in zwei Schritten realisiert. Im ersten Schritt wird mittels WS Trust RST Transaktion die technische Repräsentation der Patienteneinwilligung vom Bürgerportal an den PAP übermittelt. Der PAP generiert daraus XACML Policies und ermittelt den Hashwert der Policies (Details dazu siehe (ELGA GmbH, 2014)). Dieser Hashwert wird in einem Cache für die übermittelte SessionID zwecks späterer Überprüfung gehalten. Anschließend werden die XACML Policies mittels RSTR an das Bürgerportal retourniert. Das Bürgerportal generiert ein signiertes PDF Dokument, welches dem Bürger zur Kontrolle angezeigt wird. Zusätzlich wird ein Hashwert aus den Policies generiert und in den Metadaten des PDFs eingebettet. Im nächsten Schritt übermittelt das Bürgerportal das signierte Dokument und die XACML Policies erneut mittels WS Trust RST Transaktion an den PAP. Aus den übermittelten Policies wird ein Hashwert generiert. Dieser Hashwert, der zur SessionID gespeicherte Hashwert, sowie der Hashwert, der in den Metadaten des PDFs gespeichert ist, wird auf Übereinstimmung überprüft. Sind die drei Hashwerte nicht ident, wird ein InvalidRequest SOAP Fault retourniert. Ist die Überprüfung erfolgreich, speichert der PAP nun die XACML Policies und das signierte Dokument im Policy Repository. Es gibt zu jedem Zeitpunkt maximal ein Set an aktuellen XACML Policies, welches den Willen des Bürgers widerspiegelt. Ändert der Bürger erneut seine Einstellungen, wird wiederum ein alles beinhaltendes Set an XACML Policies für den Bürger gespeichert, welches den gesamten, aktuellen Willen des Bürgers widerspiegelt. Es ist Aufgabe des Bürgerportals, vor dem erneuten Speichern der individuellen Policies diese auch abzufragen und dem Bürger seine aktuellen Einstellungen anzuzeigen, sowie diese auch gesamtheitlich einzubringen.

Das bedeutet im Umkehrschluss auch, dass vorhandene Einschränkungen aufgehoben werden, wenn sie beim neuerlichen Einbringen nicht mehr angegeben werden.

Sequenzdiagramm: Einbringen der individuellen Policies

Vorbedingung: Abfragen der individuellen Policies
Das Bürgerportal übermittelt mittels WS Trust RST Issue Transaktion die technische Repräsentation der Patientenzustimmung an den PAP
Die bPK-GH des Patienten wird in der RST Anfrage übergeben. Im Security Header der SOAP Transaction muss eine User I- bzw. Mandate I-Assertion mitgeführt werden
Der PAP validiert die User I-Assertion
Der PAP prüft, ob die bPK-GH der RST Anfrage mit der bPK-GH der Assertion übereinstimmt
Der PAP prüft, ob die übermittelte StateID aus der QueryConsent Transaktion mit dem Letztstand der Patienteneinwilligung für diesen Bürger übereinstimmt, ansonsten wird ein Fehler retourniert (ExpiredData). Im Falle der WIST wird die Überprüfung implizit vom PAP durchgeführt (state ID wird vom PAP zwischen create und submit Transaktion persistiert und beim submit geprüft).
Der PAP generiert aus den Daten der RST Transaktion individuelle Request und Response XACML Policies
Der PAP generiert einen Hashwert für die XACMl Policy und speichert diesen. "Technisch erfolgt die Bildung des Hashwertes, indem jeweils für das Element PolicySet die kanonisierte Form mit der Algorithmus-Id http://www.w3.org/2001/10/xml-exc-c14n#" (exclusive canonicalization without comments) berechnet und darüber der SHA256 Hashwert berechnet wird." Details siehe ELGA Pflichtenheft SSt PAP WIST V1.0 Kapitel "2.4. Integritätssicherung" (ELGA GmbH, 2014)
Es wird ein ATNA Protokolleintrag generiert
Der PAP retourniert die generierten XACML Policies mittels RSTR Nachricht an das Bürgerportal. Das Bürgerportal generiert ein signiertes PDF Dokument, welches dem Bürger angezeigt wird.
Das Bürgerportal übermittelt das signierte PDF Dokument und die XACML Policies mittels RST Transaktion an den PAP. Im Security Header der SOAP Transaktion muss eine User I- bzw. Mandate I-Assertion mitgeführt werden.
Im signierten PDF Dokument muss ein Hashwert je XACML Policy eingebettet sein. Siehe (ELGA GmbH, 2014).
Der PAP validiert die User I- bzw. Mandate I-Assertion
Der PAP validiert den Hashwert (gesendet gegenüber dem selbst berechneten Wert). Ist die Validierung der Hashwerte nicht erfolgreich, wird ein InvalidRequest gesendet.
Der PAP prüft, ob die übermittelte StateID aus der QueryConsent Transaktion mit dem Letztstand der Patienteneinwilligung für diesen Bürger übereinstimmt, ansonsten wird ein Fehler retourniert (ExpiredData). Im Falle der WIST wird die Überprüfung implizit vom PAP durchgeführt (state ID wird vom PAP zwischen create und submit Transaktion persistiert und beim submit geprüft).
Der PAP speichert die XACML Policies, den Hashwert und das signierte Dokument im Policy Repository
Löschaufträge werden an das CDM übermittelt (Details siehe Kapitel Content Delete management). Hierunter fallen ein OptOut, ein partielles OptOut für Services, sowie Dokumentenlöschungen.
Es wird ein ATNA Protokolleintrag generiert
Der PAP retourniert eine RSTRC Nachricht an das Bürgerportal
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

(Anmerkung: Da die Implementierungen der betroffenen Systempartner die XML Struktur der XACML Policy nicht unverändert in den Submit Consent Request einfügen können, wird die XACML Policy beim CreateConsent im Cache des PAP zwischengespeichert und die Hashwertprüfung beim SubmitConsent deaktiviert.)

Eingangsdaten für Consent einbringen (urn:elga:pap:create):

Element	Beschreibung	Opt
User I-/Mandate I-Assertion	Elternknoten: Security Es muss eine User I- bzw. Mandate I-Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityToken.Context	Wert={eindeutige ID} Elternknoten: env:Body RST Context. Eindeutiger Wert, der in beiden aufeinanderfolgenden RST Transaktionen identisch sein muss. Details siehe (OASIS 2012), Section 3.1	R
wst:TokenType	Fester Wert={"urn:elga:pap:create"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:Claims.Dialect	Fester Wert={"urn:tiani-spirit:bes:2013:claims"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013:claims:state-id"	Wert={StateID, die beim QueryConsent RSTR übermittelt wurde} Elternknoten: wst:Claims DataType="http://www.w3.org/2001/XMLSchema#string" Die StateID, die bei der vorherigen QueryConsent Transaktion übermittelt wurde, ist verpflichtend mitzuführen. Im Falle der WIST ist dieser Wert nicht verpflichtend.	O
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} ts:ClaimValue Wert={bPK-GH in HL7 CX Format (siehe Patient ID Encoding), Data Type (inkludiert Assigning Authority ‘1.2.40.0.10.2.1.1.149’)} Elternknoten: wst:Claims DataType="http://www.w3.org/2001/XMLSchema#string" In der ersten RST Consent Einbringen Nachricht wird die bPK-GH des Bürgers in HL7 CX Format (siehe Patient ID Encoding) Data Type (inkludiert Assigning Authority ‘1.2.40.0.10.2.1.1.149’) in diesem Feld übergeben.	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013: claims:is-opt-out"	Wertebereich={true, false} Elternknoten: wst:Claims DataType= "http://www.w3.org/2001/XMLSchema#boolean" Wenn dieses Feld den Wert true beinhaltet, wird für den Bürger eine OptOut Policy gespeichert. Eine Kombination weiterer Werte, wie ServiceRestriction, ProviderRestriction, etc., ist nicht valide.	O
ts:ClaimType.name= "urn:tiani-spirit: bes:2013: claims:service-restriction-list"	Werte={ServiceRestrictionList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#service-restriction-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine ServiceRestrictionList beinhalten.	O
ts:ServiceRestrictionList	Werte={ServiceRestriction (1..n)} Elternknoten: ts:ClaimType.name= "urn:tiani-spirit: bes: 2013:claims:service-restriction-list" Listenelement für Service Einschränkungen (Ausblenden von Services)	O
ts:ServiceRestriction.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceRestrictionList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, die der Bürger ausgeblendet hat. Falls ein NULLSTRING als Wert übergeben wird, oder keinen validen Wert lt. ELGA Value Sets darstellt, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R
ts:ClaimType.name= "urn:tiani-spirit: bes:2013: claims:service-opt-out-list"	Werte={ServiceOptOutList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#service-opt-out-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine ServiceOptOutList beinhalten.	O
ts:ServiceOptOutList	Werte={ServiceOptOut (1..n)} Elternknoten: ts:ClaimType.name= "urn:tiani-spirit: bes: 2013:claims:service-opt-out-list" Listenelement für OptOut von Services	R
ts:ServiceOptOut.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceOptOutList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, für die der Bürger OptOut bzw. ein ReOptIn erklärt hat. Wurde ein ReOptIn durchgeführt, muss eine reOptInDateTime angegeben werden. Falls ein NULLSTRING als Wert übergeben wird, oder keinen validen Wert lt. ELGA Value Sets darstellt, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R
ts:ServiceOptOut.reOptInDateTime	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss'Z'"} folgende Datumsformate werden unterstützt: yyyy-MM-dd’T’HH:mm:ss Elternknoten: ts:ServiceOptOutList Zeitstempel des letzten ReOptIn für den Service. Wird vom Bürgerportal gesetzt, wenn ein Patient, der OptOut erklärt hatte, für einen Service wieder an ELGA teilnimmt. Für diesen Wert wird vom PAP eine ReOptIn Service Policy in der Individuelle Response Policy hinzugefügt.	O
ts:ClaimType.name= "urn:tiani-spirit: bes:2013: claims:service-deletion-list"	Werte={ServiceRestrictionList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#service-deletion-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine ServiceDeletionList beinhalten.	O
ts:ServiceDeletionList	Werte={ServiceDeletion (1..n)} Elternknoten: ts:ClaimType.name= "urn:tiani-spirit: bes: 2013:claims:service-deletion-list" Listenelement für Services, die gelöscht wurden	R
ts:ServiceDeletion.service	Wertebereich={ValueSet ELGA Services} siehe "ELGA_Anwendungen" in ELGA Value Sets Elternknoten: ts:ServiceDeletionList Gibt eine dedizierte Serviceinstanz/ELGA Applikation an, die der Bürger gelöscht hat. Falls ein NULLSTRING als Wert übergeben wird, oder keinen validen Wert lt. ELGA Value Sets darstellt, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R
ts:ServiceDeletion.deletionDateTime	Wert={Zeitstempel im Format "yyyy-MM-dd'T'HH:mm:ss'Z'"} folgende Datumsformate werden unterstützt: yyyy-MM-dd’T’HH:mm:ss Elternknoten: ts:ServiceDeletionList Zeitstempel des letzten Löschens für den Service. Wird vom Bürgerportal gesetzt, wenn ein Patient einen Service löschen möchte. Für diesen Wert wird vom PAP eine Service Deletion Policy in der Individuelle Response Policy hinzugefügt.	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013: claims:provider-restriction-list"	Werte={ProviderRestrictionList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#provider-restriction-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine ProviderRestrictionList beinhalten.	O
ts:ProviderRestrictionList	Werte={ProviderRestriction (1..n)} Elternknoten: ts:ClaimType.name="urn:tiani-spirit:bes: 2013:claims:provider-restriction-list" Listenelement für GDA Zeiteinschränkungen bzw. Erweiterungen. Für jedes Element in dieser Liste wird vom PAP eine GDA zeitliche Zugriffsteuerungspolicy für den Bürger hinzugefügt.	R
ts:ProviderRestriction.providerID	Wert={urn:oid: OID des GDA aus dem GDA-Index} Elternknoten: ts:ProviderRestrictionList OID des GDAs, für den zeitliche Einschränkungen bzw. Erweiterungen gesetzt wurden Falls ein NULLSTRING als Wert übergeben wird, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R
ts:ProviderRestriction.days	Wertebereich={0..365} Elternknoten: ts:ProviderRestrictionList Zeitraum in Tagen, die der GDA Zugriff auf Daten nach dem letzten Behandlungskontakt hat.	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013: claims:document-restriction-list"	Werte={DocumentRestrictionList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#document-restriction-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine DocumentRestrictionList beinhalten.	O
ts:DocumentRestrictionList	Werte={DocumentRestriction (1..n)} Elternknoten: ts:ClaimType.name="urn:tiani-spirit:bes: 2013:claims:document-restriction-list" Listenelement für Dokumenteneinschränkungen. Für jedes Element in dieser Liste wird vom PAP ein Eintrag in der Individuelle Response Policy hinzugefügt, um das angegebene Dokument auszublenden.	R
ts:DocumentRestriction.id	Wert={referenceIdList-Eintrag für "urn:elga.iti:xds:2014:ownDocument_setId", Format siehe ( (ELGA, 2014)), Kapitel "2.2.17 referenceIdList"} Elternknoten: ts:DocumentRestrictionList XDSDocumentEntry.referenceIdList des Dokuments, das ausgeblendet wurde. Falls ein NULLSTRING als Wert übergeben wurde oder der Wert nicht den Kriterien einer referenceIDList gemäß Kapitel IHE referenceIdList entspricht, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013: claims:document-deletion-list"	Werte={DocumentDeletionList} Elternknoten: wst:Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#document-deletion-list" Wenn dieser ClaimType vorhanden ist, muss dieser eine DocumentDeletionList beinhalten.	O
ts:DocumentDeletionList	Werte={DocumentDeletion (1..n)} Elternknoten: ts:ClaimType.name="urn:tiani-spirit:bes: 2013:claims:document-deletion-list" Listenelement für Dokumentenlöschungen. Für jedes Element in dieser Liste wird vom PAP ein Eintrag in der Individuelle Response Policy hinzugefügt, um das angegebene Dokument zu löschen.	R
ts:DocumentDeletion.id	Wert={referenceIdList-Eintrag für "urn:elga.iti:xds:2014:ownDocument_setId", Format siehe ( (ELGA, 2014)), Kapitel "2.2.17 referenceIdList"} Elternknoten: ts:DocumentDeletionList XDSDocumentEntry.referenceIdList Information des Dokuments, das gelöscht wurde. Diese Id wird als Löschauftrag an das CDM übermittelt (Details siehe Kapitel Content Delete Management) und zusätzlich in eine Policy eingetragen, um den Zugriff für GDA zu untersagen, bis der Löschauftrag durchgeführt wurde. Falls ein NULLSTRING als Wert übergeben wurde oder der Wert nicht den Kriterien einer referenceIDList gemäß Kapitel IHE referenceIdList entspricht, wird vom PAP eine wst:InvalidRequest SOAP Fault retourniert.	R

Datenelemente: Eingangsdaten - Einbringen des Patientenwillen (urn:elga:pap:create)

Consent Einbringen erste RST Nachricht:

PAP CreateConsent Rq.xml

Interface: Consent Einbringen erste RST

Ausgangsdaten für Consent einbringen (urn:elga:pap:create):

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:create"} Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
ts:GeneratedPolicies	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestedSecurityToken Wird vom PAP in RSTR der ersten RST Transaktion zurückgegeben und beinhaltet die individuelle Request und Response Policy des Patienten.	R
ts:IndividualRequestPolicy	Elternknoten: ts:GeneratedPolicies Beinhaltet ein individuelles Request PolicySet.	R
ts:IndividualResponsePolicy	Elternknoten: ts:GeneratedPolicies Beinhaltet ein individuelles Response PolicySet.	R

Datenelemente: Ausgangsdaten - Einbringen des Patientenwillen (urn:elga:pap:create)

Consent Einbringen RSTR Antwort:

PAP CreateConsent Rsp.xml

Interface: Consent Einbringen RSTR Antwort

Eingangsdaten für Consent einbringen (urn:elga:pap:submit):

Element	Beschreibung	Opt
User I-/Mandate I-Assertion	Elternknoten: Security Es muss eine User I- bzw. Mandate I-Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert: xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityToken.Context	Wert={eindeutige ID} Elternknoten: env:Body RST Context. Eindeutiger Wert, der in beiden aufeinanderfolgenden RST Transaktionen identisch sein muss. Details siehe (OASIS 2012), Section 3.1	R
wst:TokenType	Fester Wert: urn:elga:pap:submit Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert: "http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue" Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:Claims.Dialect	Fester Wert: "urn:tiani-spirit:bes:2013:claims" Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:ClaimType.name= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"	Fester Wert: xmlns:ts="urn:tiani-spirit:ts" Wert={ts:GeneratedPolicies} Elternknoten: Claims DataType="http://www.tiani-spirit.com/2013/BeS/ TRSchema#PoliciesType"	R
ts:GeneratedPolicies	Fester Wert: xmlns:ts="urn:tiani-spirit:ts" Elternknoten: wst:RequestedSecurityToken Wird vom Bürgerportal in der zweiten RST Transaktion an den PAP übergeben und beinhaltet die Elemente IndividualRequestPolicy und IndividualResponsePolicy, die in der ersten RSTR Transaktion im Element GeneratedPolicies retourniert wurden.	R
ts:StateID	Wert={String; StateID, die beim QueryConsent RSTR übermittelt wurde} Elternknoten: wst:RequestedSecurityToken Die StateID, die bei der vorherigen QueryConsent Transaktion übermittelt wurde, ist verpflichtend mitzuführen. Im Falle der WIST ist dieser Wert nicht verpflichtend.	O
ts:IndividualRequestPolicy	Wert={PolicySet} Elternknoten: ts:GeneratedPolicies Beinhaltet ein individuelles Request PolicySet.	R
ts:IndividualResponsePolicy	Wert={PolicySet} Elternknoten: ts:GeneratedPolicies Beinhaltet ein individuelles Response PolicySet.	R
ts:ClaimType.name= "urn:tiani-spirit:bes:2013: claims:signed-document"	Wert={Base64 codiertes PDF Dokument} Elternknoten: ts:Claims Beinhaltet im ts:ClaimValue das vom Bürgerportal signierte Dokument. Die Größe des signierten Dokuments ist auf max. 20 MB limitiert.	R

Datenelemente: Eingangsdaten - Einbringen des Patientenwillen (urn:elga:pap:submit)

Consent Einbringen zweite RST Nachricht:

PAP SubmitConsent Rq.xml

Interface: Consent Einbringen zweite RST

Ausgangsdaten für Consent einbringen (urn:elga:pap:submit):

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert: xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert: "urn:elga:pap:create" Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
ts:ElgaToken	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestSecurityToken Response Beinhaltet die Elemente, die den Willen des Patienten widerspiegeln.	R
ts:StateID	Wert={String; Hashwert, der die eingebrauchten Policies eindeutig widerspiegelt} Elternknoten: ts:ElgaToken Für die eingebrachten Policies wird die generierte StateID übermittelt, welche diese eindeutig widerspiegelt.	R

Datenelemente: Ausgangsdaten - Einbringen des Patientenwillen (urn:elga:pap:submit)

Consent Einbringen RSTRC Antwort:

PAP SubmitConsent Rsp.xml

Interface: Consent Einbringen RSTRC Antwort

Abfragen des ELGA-Teilnahmestatus¶

Mit der Abfrage des ELGA-Teilnahmestatus kann ein GDA oder ELGA-Teilnehmer den Status der ELGA Teilnahme abfragen. Als Schnittstelle wird, wie beim PAP üblich, eine WS-Trust Abfrage verwendet. In der Anfrage kann angegeben werden, ob nur der generelle Teilnahmestatus (ElgaApp:100), nur der e-Befund Teilnehmerstatus (ElgaApp:101), nur der e-Medikation Teilnehmerstatus (ElgaApp:102) oder alle Status (ElgaApp:0) zurückgegeben werden sollen. Die Antwort liefert den Wert true bei einer Teilnahme und false wenn nicht teilgenommen wird.

Bei Abfragen eines GDA wird die Existenz und Gültigkeit einer Kontaktbestätigung ausgewertet. Zum Antwortverhalten siehe "Ausgangsdaten für ELGA-Teilnahmestatus abfragen" bzw. "Ablaufbeschreibung".

Ablaufbeschreibung:

es wird die empfangene SAML Assertion validiert
es wird geprüft, ob die ElgaApp der Anfrage den Wert 0 oder 100 oder 101 oder 102 beinhaltet. Wenn nicht, wird eine wst:InvalidRequest fault zurückgegeben.
es wird geprüft, ob die empfangene Assigning Authority der PatientID bekannt ist. Bei Abfragen als Bürger oder Vertreter (EBP, OBST, etc.) muss die bPK-GH verwendet werden. Bei einer GDA Abfrage kann eine bPK-GH, SVNR oder LPID verwendet werden. Im Fehlerfall wird eine wst:InvalidRequest fault zurückgegeben.
Bei einem GDA Zugriff wird geprüft, ob ein gültiger Kontakt vorhanden ist. Ist kein Kontakt vorhanden, wird eine wsse:FailedAuthentication fault zurückgeben. Ist der Kontakt zeitlich abgelaufen, wird eine AccessDenied fault zurückgegeben. Ist ein GDA gesperrt (Zugriffszeit:0), wird false zurückgegeben (identische Antwort wie bei einem generellen Opt-Out).
für die Ermittlung des Status werden die XACML Policies des Bürgers ausgewertet. Es wird geprüft, ob ein generelles Opt-Out vorliegt und ob der Teilnehmer der Applikation e-Befund oder e-Medikation mittels Service-Opt-Out oder Service-Restriction widersprochen hat.
Bei allen Abfragen wird ein Z-L-ARR Audit geschrieben. Bei GDA-Zugriffen wird auch ein A-ARR Audit (EventType 55) geschrieben.

Eingangsdaten für Consent abfragen (urn:elga:pap:query):

Element	Beschreibung	Opt
User I-/ Mandate I-/ HCP-Assertion	Elternknoten: Security Es muss eine User I-/ Mandate I-/ HCP-Assertion im WS-Security Header inkludiert sein	R
wst:RequestSecurityToken	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:query:opt:status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:RequestType	Fester Wert={"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Status"} Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
wst:ValidateTarget	Elternknoten: wst:RequestSecurityToken Details siehe (OASIS 2012)	R
ts:OptStatusQuery	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:ValidateTarget Beinhaltet die Werte, die für die Statusabfrage benötigt werden.	R
ts:PatientID	Wert={bPK-GH oder ein dem Z-PI bekannter Identifier in HL7 CX Format (siehe Patient ID Encoding), Data Type (im Falle einer EBP-Abfrage muss eine Assigning Authority ‘1.2.40.0.10.2.1.1.149’ sein; im Falle einer GDA-Abfrage ein dem Z-PI bekannter Identifier)} Elternknoten: ts:OptStatusQuery	R
ts:ElgaApp	Wertebereich={0, 100, 101, 102} Elternknoten: ts:OptStatusQuery 0=alle Status, 100: nur ELGA allgemein, 101: nur e-Befund, 102: nur e-Medikation	R2

Datenelemente: Eingangsdaten - Abfragen des ELGA-Teilnahmestatus

ELGA-Teilnahmestatus Abfrage:

PAP OptStatusQuery Rq.xml

Interface: ELGA-Teilnahmestatus Abfrage

Ausgangsdaten für ELGA-Teilnahmestatus abfragen (urn:elga:pap:query:opt:status):

Das Antwortverhalten ist im Generellen, wie folgt:

Bei GDA Zugriffen:
Wenn KEIN Kontakt vorhanden ist wird eine wsse:FailedAuthentication fault zurückgegeben.
Wenn der GDA gesperrt ist (0 Tage) wird StatusElga:false, StatusEbefund:false, StatusEmed:false zurückgegeben
Wenn der Kontakt "abgelaufen" ist, wird eine AccessDenied fault zurückgegeben.

Element	Beschreibung	Opt
wst:RequestSecurityTokenResponseCollection	Fester Wert={ xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"} Elternknoten: env:Body Details siehe (OASIS 2012)	R
wst:RequestSecurityTokenResponse	Elternknoten: wst:RequestSecurityToken ResponseCollection Details siehe (OASIS 2012)	R
wst:TokenType	Fester Wert={"urn:elga:pap:query:opt:status"} Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
wst:RequestedSecurityToken	Elternknoten: wst:RequestSecurityToken Response Details siehe (OASIS 2012)	R
ts:OptStatus	Fester Wert={xmlns:ts="urn:tiani-spirit:ts"} Elternknoten: wst:RequestSecurityToken Response Beinhaltet die Antwort des ELGA-Teilnahmestatus.	R
ts:StatusElga	Wertebereich={true, false} Elternknoten: ts:OptStatus False, wenn der ELGA-Teilnehmer ein generelles Opt-Out erklärt hat oder der abfragende GDA gesperrt ist.	O
ts:StatusEbefund	Wertebereich={true, false} Elternknoten: ts:OptStatus False, wenn ein Service-Opt-Out oder Service-Restriction für e-Befunde vorliegt.	O
ts:StatusEmed	Wertebereich={true, false} Elternknoten: ts:OptStatus False, wenn ein Service-Opt-Out oder Service-Restriction für e-Medikation vorliegt.	O

Datenelemente: Ausgangsdaten - Abfragen des ELGA-Teilnahmestatus

Consent Abfrage Antwort:

PAP OptStatusQuery Rsp.xml

Interface: ELGA-Teilnahmestatus Abfrage Antwort

OBST/eHS - Einbringen der individuellen Policies¶

Für den PAP gibt es keinen Unterschied in der Anforderung, ob eine OBST/eHS oder ein Bürger selbst mittels Bürgerportal die individuellen Policies verwaltet.

Dokumentenbezogene Zugriffe¶

Details bezüglich dokumentenbezogener Zugriffe mittels IHE XDS.b Profil sind dem Kapitel Dokumentenbezogene Transaktionen – Client zu entnehmen. In allen Kapiteln bezüglich dokumentenbezogener Zugriffe ersetzt das ELGA Bürgerportal die Rolle des GDA- bzw. ELGA Bereichs-Systems, außerdem ist vom EBP für alle Transaktionen anstelle der HCP Assertion eine ELGA User I- bzw. Mandate I-Assertion zu verwenden.

Optimistic Locking¶

Um das bisher umgesetzte "Last-Win" Konzept beim Einbringen der individuellen Berechtigungen abzulösen, wird die StateID in den PAP Transaktionen QueryConsent, CreateConsent und SubmitConsent eingeführt. Dadurch kann verhindert werden, dass eine individuelle Berechtigung überschrieben wird, die dem Bürger zuvor nicht angezeigt wurde, da diese zwischen der Abfrage und der Aktualisierung seines Patientenwillens im PAP eingestellt wurde durch seine Vertretung (OBST/eHS, WIST, Bevollmächtigung).

Das EBP erhält bei der Abfrage der Patienteneinwilligung für einen Bürger (QueryConsent) zusätzlich zum aktuellen Status der individuellen Berechtigungen nun eine StateID, die die Response und Request Policy zur Berechtigung eindeutig widerspiegeln.

Um nachfolgend den Patientenwillen zu aktualisieren, muss das EBP in den Transaktionen CreateConsent sowie SubmitConsent die im QueryConsent mitgelieferte StateID im RST Request setzen. Bei der Erstellung bzw. Speicherung der individuellen Berechtigung am PAP wird überprüft, ob der zuletzt gültige Patientenwille durch die mitgelieferte StateID repräsentiert wird. Dies ist nicht der Fall, wenn zwischen der Abfrage und der Aktualisierung des Patientenwillens eine Vertretung (OBST/eHS, WIST, Bevollmächtigung) eine Aktualisierung vorgenommen hat. In diesem Fall wird vom PAP der Fehler "ExpiredData" (siehe Fehlermeldungen) zurückgeliefert. Ist sowohl die Erstellung, als auch die Speicherung des neuen Patientenwillens erfolgreich, wird als RST Antwort in der SubmitConsent Transaktion die neue StateID für den soeben gespeicherten Patientenwillen mit übergeben.

Sonderfall WIST: Da die WIST keine Abfrage des Patientenwillens vornehmen kann und deshalb keine StateID zur Verfügung hat, muss für die Transaktionen CreateConsent und SubmitConsent keine StateID gesetzt werden. Der PAP überprüft lediglich, ob der zuletzt aktuelle Patientenwille mit der Berechtigung übereinstimmt, die für die Generierung des MergeConsent (Details hierzu siehe Kapitel PAP Merge Routine) herangezogen wurde. Der PAP persistiert deshalb zwischen den Transaktionen CreateConsent und SubmitConsent eine selbst ermittelte StateID.

Anbindung WIST¶

Für die WIST (Widerspruchsstelle) Anbindung steht ein eigenes WIST Pflichtenheft (ELGA GmbH, 2014) zur Verfügung.

Siehe: SAML Assertion Übersicht, Lokale WIST IDA, ELGA WIST Assertion, WIST Mandate Assertion

WIST - Einbringen der individuellen Policies¶

Die WIST ist ausschließlich befugt, eine OptOut bzw. eine Service OptOut (ELGA Anwendung) oder OptIn bzw. Service ReOptin Policy zu speichern. Der PAP prüft dies mittels der empfangenen Rolle bzw. den Permissions der WIST Mandate Assertion.

Die Schnittstelle zum Einbringen von individuellen Policies wird mittels eines von WS Trust abgeleiteten Protokolls RST/RSTR/RSTRC in zwei Schritten realisiert. Im ersten Schritt wird mittels WS Trust RST Transaktion die technische Repräsentation der Patienteneinwilligung von der WIST an den PAP übermittelt. Der PAP generiert daraus XACML Policies und retourniert diese mittels RSTR an die WIST. Die WIST generiert nun aus der erfassten Willenserklärung das Bestätigungsschreiben an den Bürger (PDF-Dokument). Im nächsten Schritt übermittelt die WIST das signierte Dokument und die XACML Policies erneut mittels WS Trust RST Transaktion an den PAP. Der PAP speichert nun die XACML Policies und das signierte Dokument im Policy Repository. Anschließend lädt der PAP den letzten aktuellen Consent des Patienten. Je nach Fall des initialen Consents und des Consents, der von der WIST zum Speichern empfangen wurde, wird der initiale Consent beibehalten, der WIST Consent gesetzt oder beide Consents zu einem zusammengeführt:

Der initiale Consent wird dann beibehalten, wenn er bereits vollständig den aktuellen Willen des Bürgers widerspiegelt

Beispiel: initialer Consent = generelles OptOut - aktueller Wille = ServiceA OptOut

Ein WIST Consent wird gesetzt:

bei einem generellen OptOut bzw OptIn durch die WIST
Beispiel: initialer Consent = ServiceA OptOut - aktueller Wille = generelles OptOut bzw generelles OptIn
bei einem Service Re-Opt-In auf ein bestehendes entsprechendes Service Opt-Out
Beispiel: initialer Consent = ServiceA OptOut - aktueller Wille = ServiceA OptIn

Beide Consents werden dann zusammengeführt, wenn der initiale Consent nicht den gesamten aktuellen Willen des Bürgers widerspiegelt und dieser die Erweiterung über die WIST einbringen will:

Beispiel 1: initialer Consent = generelles OptIn - aktueller Wille ServiceA OptOut
Beispiel 2: initialer Consent = ServiceA reOptIn, ServiceB reOptIn - aktueller Wille = ServiceA OptOut, ServiceB reOptin
Beispiel 3: initialer Consent = ServiceA OptOut - aktueller Wille = ServiceA reOptIn, ServiceB reOptIn

Details zu dieser Merge Routine finden sich auch im Kapitel PAP Merge Routine.

Es gibt zu jedem Zeitpunkt maximal ein aktuelles XACML PolicySet, welches den Willen des Bürgers widerspiegelt. Müssen jedoch zwei Consents zu einem zusammengeführt werden, kann mehr als ein signiertes Dokument den Willen des Bürgers darstellen.

Sequenzdiagramm: WIST - Einbringen der individuellen Policies

Die WIST übermittelt mittels WS Trust RST Issue Transaktion die technische Repräsentation der Patientenzustimmung an den PAP
Das bPK-GH des Patienten wird in der RST Anfrage übergeben. Im Security Header der SOAP Transaktion muss eine WIST Mandate Assertion mitgeführt werden
Der PAP validiert die WIST Mandate Assertion
Der PAP prüft, ob die bPK-GH der RST Anfrage mit der bPK-GH der Assertion übereinstimmt
Eine Überprüfung der StateID findet an dieser Stelle nicht statt, da die WIST kein QueryConsent absetzt. Der PAP generiert aus den Daten der RST Transaktion individuelle Request und Response XACML Policies
Es wird ein ATNA Protokolleintrag generiert
Der PAP retourniert die generierten XACML Policies mittels RSTR Nachricht an die WIST
Die WIST generiert aus der erfassten Willenserklärung das Bestätigungsschreiben an den Bürger (PDF-Dokument). Die WIST übermittelt das signierte PDF-Dokument und die XACML Policies mittels RST Transaktion an den PAP. Im Security Header der SOAP Transaktion muss eine WIST Mandate Assertion mitgeführt werden. Das Auslesen dieses PDF-Dokuments aus der BeS Datenbank heraus, kann mithilfe der Datenbank-Schemabeschreibung erfolgen (siehe auch DB-Schemabeschreibung (DXC, 2024)).
Im signierten PDF-Dokument muss ein Hashwert je XACML Policy eingebettet sein (siehe (ELGA GmbH, 2014)).
Der PAP validiert die WIST Mandate Assertion und den Hashwert
Eine Überprüfung der StateID findet an dieser Stelle nicht statt, da die WIST kein QueryConsent absetzt. Der alte Consent wird gemäß MergeRoutine aktualisiert. Der PAP speichert die XACML Policies, den Hashwert und das signierte Dokument im Policy Repository
Der PAP führt eine Merge Routine durch, die feststellt, ob der WIST Consent aktiv gesetzt werden kann, der initiale Consent aktiv bleiben soll oder der initiale Consent mit dem Consent der WIST zusammengeführt werden muss.
Löschaufträge werden an das CDM übermittelt (Details siehe Kapitel Content Delete Management). Hierunter fallen ein OptOut, sowie partielle OptOut für Services.
Es wird ein ATNA Protokolleintrag generiert
Der PAP retourniert eine RSTRC Nachricht an die WIST
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Details zur Schnittstelle finden sich im Kapitel Einbringen der individuellen Policies, sowie im WIST Pflichtenheft (ELGA GmbH, 2014).

Is-ReOpt-In¶

Für die WIST Schnittstelle steht für den Create Policy Request ein weiteres Attribut zur Verfügung, welches kennzeichnet, ob ein ELGA-Teilnehmer einer generellen Teilnahme (Opt-In) zugestimmt hat.

ts:ClaimType.name=

"urn:tiani-spirit:bes:2013:
claims:is-re-opt-in"

Wertebereich={true, false}

Elternknoten: wst:Claims

DataType=
"http://www.w3.org/2001/XMLSchema#boolean"

Wenn dieses Feld den Wert true beinhaltet, wird für den Bürger ein generelles ReOptIn gespeichert und für jedes Service ein reOptIn Datum gespeichert (in Form des aktuellen Zeitstempels).

Im Falle einer Zeit-Mitübergabe für ein Service ReOptIn wird stattdessen diese beibehalten und kein aktueller Zeitstempel herangezogen.

Wird (in Kombination mit einem generellen ReOptIn) für ein Service kein ReOptIn Datum angegeben, wird für das betreffende Service ein Service OptOut gespeichert.

O

Datenelemente: ReOptIn

PAP Merge Routine¶

Da die WIST nur schreibenden Zugriff hat, wird vom PAP eine Routine bereitgestellt, die dafür sorgt, dass der initiale Consent des Bürgers berücksichtigt wird und nicht überschrieben wird. Nachfolgend wird das Verhalten für die verschiedenen Fälle des initialen Consents und des Consents, der durch die WIST eingebracht wird, beschrieben.

Anmerkungen: Der "Zustand der Berechtigungsänderung" bezeichnet den Consent, der vor der Speicherung des Consents über die WIST im PAP für einen Bürger aktuell bzw. aktiv ist.

GDA-individuelle Zeiträume: bleiben außer bei Opt-Out immer bestehen

Dokumente versteckt oder gelöscht: wird beim betreffenden Opt-Out ersetzt durch das Opt-Out, bleiben ansonsten bestehen

ServiceDeletion: wird beim betreffenden Opt-Out ersetzt durch das Opt-Out, bleiben ansonsten bestehen

ServiceRestriction: Wird beim betreffenden Opt-Out ersetzt durch das Opt-Out, bleiben ansonsten bestehen.

Die WIST Zustände bzw. Merge Regeln sind dem angehängten Dokument zu entnehmen:

IST-Zustände_V2.6.xlsx

Bei den Berechtigungsänderungen "generelles OptOut" bzw. "generelles OptIn" durch die WIST, invalidiert der PAP alle vorher vorhandenen PDF-Erklärungen und ersetzt sie durch eine einzig aktive, valide PDF-Erklärung. Dieses Regelwerk wird beim EBP als Client immer angewendet.

Anbindung BRZ IdP¶

Diese Assertion ist deaktiviert, da sie derzeit nicht verwendet wird.

Der Identity Provider des Betriebsdienstleisters BRZ stellt eine SAML Assertion gemäß BRZ IdP SAML2 Identity Assertion aus und sendet diese mittels HTTP POST Binding als unsolicited <saml2p:Response> an das administrative Portal des BeS. Das administrative BeS Portal fordert nachfolgend mit der empfangenen BRZ IdP Assertion beim ETS mittels WS Trust eine ELGA Service Assertion an.

Siehe: SAML Assertion Übersicht, BRZ IdP SAML2 Identity Assertion, Service Assertion

Unsolicited saml2p:Response

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination="https://demo.egiz.gv.at/demoportal_demologin/securearea.action" InRe-sponseTo="_de163da621a05163e60ab88a6ac9ae36" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> Demo 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-sha256"/>
            <ds:Reference URI="">
                <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 PrefixList="xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
                <ds:DigestValue>btfG7Vbmb0wlKxFfRTx+dqE6Hps=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>TESTTESTTESTVWfW5+7KjWpNk5LJX4CiEEMpLyQaKwYm+mzYK+P5fm1kjkCpyvXHzPhSg881lsaH QFhv0epBi12KUI1MXaHkgw53kqhmPcAiiclMBAjyN/n+OBIXhNuQ0RX7thaEbIl6xVe/Quq5kThGT7q093UTyn/eANO9Fe/mGJ85woY-frsJOFhR0IKu0cCBEJFGsno2mg31BHhEeMo1SJ1Ku4i7twHOV+cE9a1cJeClc3nN8dIkn94G8mj2WHC0YGWoCsYR1IAAP8FYpLmr-SUMMve4dXdaqC2qpSwRPiGXccII9rycN264EfHK6H1htk4cYHoBwWuRbWoqSscA==</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:KeyValue>
                <ds:RSAKeyValue>
                    <ds:Modulus>TESTTESTTESToMeOHpizN3qU2cL2e3EkzAkowmG+OpsR3UpI0dvolRuzaxDPUeANfE913KPempsT 3cOKGS5IIBmxPgZM1H7EcEPVS2PYimMr1HztBMJMGAdFVFeVFsgdYP4cbwPUs03/E6kVmN7/C+vM yRPMD7i83YL8/IHChymZ5aJTsRXUpM0TjQQPBQbnnHVWzjcUJ9z9KataS/KpUUM8iSWk73u/gWOs3vbQLoro80xjLsSdXyJ9dVTCTwCpdP5UJPlsNLg1F7AU+OHwem76rezI0JJZhHUMg6v1xWzh8XycI6CizpD6RmkMXfICbFD8TR5zcNBieH/yNQeAEw==</ds:Modulus>
                    <ds:Exponent>AQAB</ds:Exponent>
                </ds:RSAKeyValue>
            </ds:KeyValue>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml2p:Status>
</saml2p:Response>

Interface: unsolicited samlp:Response

Service RST Issuer Anfrage¶

Das administrative Portal fragt mittels WS Trust RST Issue Transaktion beim ETS um eine ELGA Service Assertion an.

Datenelemente:

Element	Beschreibung
wst:RequestType	http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
wst:LifeTime	Die Lebensdauer der Assertion. Dieser Wert ist ein Vorschlag für das ETS
wst:TokenType	"urn:elga:bes:2013:service:assertion" wird verwendet, um die unterschiedlichen Token Typen unterscheiden zu können.

Datenelemente: Service RST Issuer Anfrage

ETS ServiceRSTR Rq.xml

Interface: unsolicited samlp:Response

Service RSTR Issuer Antwort¶

Die ELGA Service Assertion wird mittels RSTR an den Anfragenden zurückgeliefert.

Datenelemente RSTR Service:

Element	Beschreibung
RequestSecurityTokenResponseCollection
RequestSecurityTokenResponse	Body der Antwort
TokenType	urn:elga:bes:2013:service:assertion
RequestedSecurityToken	Beinhaltet die ELGA SAML2 Service Assertion

Datenelemente: Service RSTR Issuer Antwort

ETS ServiceRSTR Rsp.xml

Interface: Login Assertion Renew Anfrage

Um ELGA Login Assertions zu erneuern, wird von einem GDA, einem Bereichs Gateway oder dem EBP eine WS Trust RST reNew Transaktion über die AGW an das ETS geschickt.

Informationen welche Assertions erneuert werden können bzw. wie oft diese erneuert werden können, kann in Kapitel SAML Assertion Übersicht gefunden werden.

Das EBP, ein GDA oder ein Gateway eines ELGA Bereichs sendet eine RST Renew Transaktion an die ZGF. Im Security Header der SOAP Nachricht befindet sich die Assertion, die erneuert werden soll.
- Es muss der jeweilige <wst:TokenType>" der Login Assertion, die erneuert wird, gesetzt werden.
  - Siehe: Datenelemente: Übersicht ELGA AssertionsTypes, Login Assertions
Der Apache der lokalen AGW leitet die Nachricht zum zentralen ETS weiter.
ETS validiert die Login Assertion, die im Security Header empfangen wurde. Sollte die Assertion nicht valide sein, wird eine WSSE SOAP Fault zurückgeliefert.
wsse:InvalidSecurity
wsse:InvalidSecurityToken
wsse:SecurityTokenUnavailable
wsse:FailedCheck
wst:RequestFailed
ETS validiert, ob die Assertion im RST renewTarget auch im SOAP Security Header vorhanden ist. Sollte die Assertion vom RST renewTarget nicht im SOAP Security Header vorhanden sein, wird eine wst:InvalidRequest SOAP Fault zurückgeliefert.
Es muss eine SecurityTokenReference auf die im SOAP Security Header übertragene Assertion im RST renewTarget verwendet werden.
ETS prüft, ob die präsentierte Assertion bereits erneuert werden darf. Wenn nicht, wird eine wst:UnableToRenew SOAP Fault zurückgeliefert.
Eine Assertion ist nur dann erneuerbar, wenn sie nur noch einen bestimmten Zeitraum gültig ist (5 Minuten).
Alle erneuerbaren Assertions beinhalten eine ProxyRestriction. Das ETS prüft, ob diese ProxyRestriction vorhanden ist und das Count Attribute nicht null und größer 0 ist. Sollte die Prüfung fehlschlagen, wird eine wst:UnableToRenew SOAP Fault zurückgeliefert.
Das Count Attribute der ProxyRestriction kann auch vom Client verwendet werden, um herauszufinden, wie oft eine Assertion noch erneuert werden kann. Ist das Count Attribute 0 oder die ProxyRestriction nicht vorhanden, kann die Assertion nicht erneuert werden.
Die Assertion wird vom ETS mit gleichbleibendem Inhalt und Semantik neu ausgestellt, um die Gültigkeit zu verlängern. Der Count der ProxyRestriction wird bei jedem Erneuern verringert. Hat er 0, kann die Assertion nicht mehr erneuert werden. Werte wie die ID der Assertion, issueInstant, Created, etc. werden mit neuen bzw. aktuellen Werten befüllt.
Die Assertion aus dem SOAP Security Header, die für das Renew präesentiert wurde, wird als invalid (canceled) markiert und ist nicht mehr länger valide.
Die erneuerte Login Assertion wird in der RSTR zurückgeliefert.

Datenelemente Anfrage:

wst:RequestType

Muss den Wert "http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew" beinhalten. Siehe für Details: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html

wst:TokenType

Muss den TokenType der jeweiligen ELGA Login Assertion, die erneuert werden soll, beinhalten.

Siehe: Datenelemente: Übersicht ELGA AssertionsTypes

Siehe für Details: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html

wsse:Reference URI

Beinhaltet die ID der Login Assertion, die im Security Header mitgegeben wird und erneuert werden soll

Datenelemente: Login Assertion Renew Anfrage

Login Assertion Renew Anfrage Beispiel:

ETS RenewAssertion Rq.xml

Interface: Login Assertion Renew Anfrage Beispiel

Datenelemente Antwort

Element	Beschreibung
RequestSecurityTokenResponseCollection	RequestSecurityTokenResponseCollection (RSTRC) wird in der abschließenden Antwort an eine RST Anfrage verwendet werden, um ein Security Token zu retournieren
RequestSecurityTokenResponse	Body der Antwort
TokenType	Siehe: Datenelemente: Übersicht ELGA AssertionsTypes
RequestedSecurityToken	Beinhaltet die erneuerte SAML2 Assertion

Datenelemente: Login Assertion Renew Antwort

Login Assertion Renew Antwort Beispiel:

ETS RenewAssertion Rsp.xml

Interface: Login Assertion Renew Antwort Beispiel

Läuft eine Benutzersession ab oder wird sie invalidiert, müssen auch entsprechende ELGA Login Assertions invalidiert werden. Hierfür muss eine WS Trust RST Cancel Transaktion an das ETS geschickt werden, um die entsprechende Login Assertion zu invalidieren.

Ein GDA System oder ein Gateway eines ELGA Bereichs sendet eine WS Trust RST Cancel Transaktion an die ZGF des ELGA Bereichs, um eine ELGA Login Assertion zu invalidieren
- Im Security Header der SOAP Nachricht muss sich die noch gültige ELGA Login Assertion, die invalidiert werden soll, befinden
Der Apache der lokalen AGW leitet die RST Nachricht zum zentralen ETS weiter
Fehlerfälle werden gemäß Kapitel Security Header Fehlermeldungen bzw. Kapitel WS Trust Fehlermeldungen prozessiert.

Datenelemente:

Element	Beschreibung
wst:RequestType	Muss den Wert "http://docs.oasis-open.org/ws-sx/ws-trust/200512/Cancel" beinhalten.
wst:TokenType	Muss den Wert (WS Trust TokenType), der zu invalidierenden ELGA Login Assertions beinhalten. Datenelemente: Übersicht ELGA AssertionsTypes
wsse:Reference URI	Beinhaltet die ID der Login Assertions, die im Security Header mitgegeben wird und invalidiert werden soll
wst:RequestedTokenCancelled	Element in der WS Trust RSTR.

Datenelemente: ELGA Login Assertion invalidieren Anfrage

Assertion Cancel Anfrage Beispiel:

Es muss der jeweilige <wst:TokenType> der Login Assertion, die invalidiert wird, gesetzt werden.

Siehe: Datenelemente: Übersicht ELGA AssertionsTypes, Login Assertions

Es muss eine "wsse:SecurityTokenReference " im "wst:CancelTarget" der "wst:RequestSecurityToken" Nachricht verwendet werden. Die "wsse:Reference" muss auf die zu invalidierende Assertion im SOAP Security Header zeigen.

ETS CancelAssertion Rq.xml

Interface: Assertion Cancel Anfrage Beispiel

Datenelemente Antwort

Element	Beschreibung
RequestSecurityTokenResponseCollection	RequestSecurityTokenResponseCollection (RSTRC) wird in der abschließenden Antwort an eine RST Anfrage verwendet werden, um einen Security Token zu retournieren
RequestSecurityTokenResponse	Body der Antwort
TokenType	Siehe: Datenelemente: Übersicht ELGA AssertionsTypes
RequestedTokenCancelled	Leeres Element

Datenelemente: ELGA Login Assertion invalidieren Antwort

Assertion Cancel Antwort Beispiel:

ETS CancelAssertion Rsp.xml

Interface: Assertion Cancel Antwort Beispiel

Fehlermeldungen¶

In BeS gibt es interne und externe Fehlermeldungen. Interne Fehlermeldungen enthalten detaillierte Fehlertexte, um die Fehleranalyse zu erleichtern. Diese werden aber nur in Logdateien geschrieben. Externe Fehlermeldungen sind sehr allgemein gehalten, um keinen Rückschluss auf sensible Informationen des Systems oder gesetzten Policies der ELGA-Teilnehmer, von Clientsystemen zuzulassen. Ein Clientsystem bekommt ausschließlich externe Fehlermeldungen von den BeS Komponenten zurück.

In der nachstehenden Tabelle sind alle externen Fehlermeldungen angeführt.

Fault Type	Fault Subcode	Fault Text	Fault Beschreibung
Addressing SOAP Fault	addressing:ActionNotSupported	The ['action'] cannot be processed at the receiver	Die SOAP Aktion wird nicht unterstützt
WS Trust SOAP Fault	wst:InvalidRequest	The request was invalid or malformed	Die WS Trust Anfrage ist nicht valide. Z.B. durch fehlende bzw. nicht korrekte Werte.
WS Trust SOAP Fault	wst:RequestFailed	The specified request failed	Beim Prozessieren der Anfrage ist ein Fehler aufgetreten
WSSE SOAP Fault	wsse:InvalidSecurity	An error was discovered processing the 'wsse:Security' header	Beim Prozessieren des SOAP Security Headers sind Fehler aufgetreten.
WSSE SOAP Fault	wsse:UnsupportedSecurityToken	An unsupported token was provided	Es wurde eine Assertion präsentiert, die nicht unterstützt wird
WSSE SOAP Fault	wsse:InvalidSecurityToken	An invalid security token was provided	Es wurde eine nicht valide Assertion präsentiert
WSSE SOAP Fault	wsse:FailedCheck	The signature or decryption was invalid	Die Signatur der Assertion ist nicht valide bzw. fehlerhaft oder es konnte kein geeignetes Zertifikat im TrustStore gefunden werden, um die Signatur der Assertion zu prüfen.
WS Trust SOAP Fault	wst:InvalidTimeRange	The requested time range is invalid or unsupported	Die vorgeschlagene Lebensdauer der Assertion (WS Trust RST Created / Expires) ist nicht valide bzw. wird nicht unterstützt
WSSE SOAP Fault	wsse:FailedAuthentication	The security token could not be authenticated or authorized	Der GDA wurde nicht im GDA Index gefunden bzw. hat nicht die angeforderte Rolle Der ELGA Teilnehmer bzw. sein Vertreter wurde nicht im Z-PI gefunden. Es existiert kein aktiver Kontakt zwischen anfragendem GDA und dem ELGA Teilnehmer
WSSE SOAP Fault	wsse:SecurityTokenUnavailable	Referenced security token could not be retrieved	Eine SecurityTokenReference konnte nicht aufgelöst werden. z.B. ActAs oder Invalidieren bzw. Erneuern einer Assertion
WS Trust SOAP Fault	wst:UnableToRenew	The requested renewal failed	Die Assertion konnte nicht erneuert werden z.B weil die maximale Anzahl an Erneuerungen bereits erreicht ist.
XDS RegistryError	spirit:xds.004.3.00020	XDS request failed	Default XDS Fehlermeldung wenn keine andere zur Verfügung steht
XDS RegistryError	XDSUnavailableCommunity	A community which would have been contacted was not available	Ein ELGA Bereich konnte nicht erreicht werden. Bedeutet, dass die dortige AGW/ZGF nicht erreichbar ist. (Falls die AGW/ZGF erreichbar, aber die Komponenten des Bereichs nicht, wird spirit:xds.004.3.00020 retourniert.)
XDS RegistryError	XDSRegistryMetadataError	Error detected in metadata	Es wurden fehlerhafte Metadaten empfangen
XDS RegistryError	XDSRepositoryMetadataError	Error detected in metadata	Es wurden fehlerhafte Metadaten empfangen
XDS RegistryError	XDSMissingHomeCommunityId	A value for the homeCommunityId is required and has not been specified	Die home community ID wurde nicht gefunden, wird aber zwingend in der betroffenen Transaktion benötigt
XDS RegistryError	XDSPatientIdDoesNotMatch	This error is thrown when the patient Id is required to match and does not	Die Patientenidentifikation ist nicht korrekt. z.B hat ein ELGA Bereich eine Patientenidentifikation in Dokumentmetadaten zurückgeliefert, mit der nicht abgefragt wurde
XDS RegistryError	XDSMissingPatientContext	The patient context could not be resolved using an XDS UUID or uID	Eine Dokument ID wurde nicht im ZGF Cache gefunden. Es muss erneut eine XDS Query Transaktion durchgeführt werden, um den Cache zu aktualisieren
SOAP Fault	DocumentQueryDenied	The document query transaction is denied either by general or patient individual policy	Es dürfen keine Dokumentmetadaten abgefragt werden
SOAP Fault	DocumentSubmitDenied	The document submit transaction is denied either by general or patient individual policy	Es dürfen keine Dokumente eingebracht werden
SOAP Fault	DocumentRetrieveDenied	The document retrieve transaction is denied either by general or patient individual policy	Es dürfen keine Dokumente abgefragt werden
SOAP Fault	DocumentStatusUpdateDenied	The document update transaction to change the status is denied either by general or patient individual policy	Der Status des Dokuments darf nicht geändert werden
XDSRegistryError	XDSUnknownCommunity	A value for the homeCommunityId is not recognized	Die angefragte Community ist nicht verfügbar.
XDS RegistryError	XDSDocumentUniqueIdError	The document associated with the uniqueId is not available. This could be because the document is not available, the requestor is not authorized to access that document or the document is no longer available	Mit einem bestimmten Dokument ist ein Problem aufgetreten, z.B wurde es nicht in der XDS Registry gefunden
XDS RegistryError	MetadataHashMismatch	Metadata hash mismatch detected for document	Der berechnete ELGA Hash des Dokuments stimmt nicht mit dem Hashwert der Dokumentmetadaten überein. Dieser Fehler wird nicht retourniert, sondern im STL protokolliert. Dieser Fehler kann jedoch beim Schreiben von Dokumenten als Error zurückgeliefert werden
WS Trust SOAP Fault	wst:ExpiredData	The request data is out-of-date	Beim Einbringen der individuellen Policies ist ein optimistic-lock Problem aufgetreten
SOAP Fault	DocumentNonVersioningUpdateDenied	The document NonVersioning transaction to change is denied either by general or patient individual policy
SOAP Fault	AccessViolation	unexpected access violation - no policy in treatment-assertion
SOAP Fault	AccessDenied	general access denied errormessage
XDS RegistryError	spirit:xds.004.3.00020	XDS request failed []	Registry/Repository des Bereichs nicht verfügbar oder retournieren Fehler. Die Transaktion ist aus anderen Gründen abgebrochen worden. Z.B. weil das L-ARR nicht erreichbar ist.
XDS RegistryError	TooMuchData	Too much Data found for patient.	Es wurden mehr Dokumente als erlaubt gefunden.
SOAP Fault / RegistryError	RequestFailed	No bPK GH found in ZPI for patient	Es wurde im ZPI keine bPK GH für den Patienten gefunden. ETS & KBS geben eine SOAP Fault zurück. Die ZGF gibt bei XDS Transaktionen einen RegistryError zurück.
XDS RegistryError	spirit:xds.004.3.00052	Missing mandatory XDS attribute	erforderliche XDS Metadaten für Zugriffsautorisierung nicht im ZGF-Cache
XDS RegistryError	XDSIWrongRetLocUid	Wrong RepositoryUniqueId in retrieve imaging request	Wenn im KOS eine retrieveLocationUID verfügbar ist, die nicht der RAD-69 RepositoryUniqueId entspricht, wird dieser Fehler zurückgegeben. Wenn im KOS keine retrieveLocationUID verfügbar ist, wird nur ein Warning im Log ausgegeben (NO RetrieveLocationUID (0040,E011) found in RefSeriesSeq (0008,1115)) und kein Fehler geworfen.

Tabelle: Fehlermeldungen

Bei IHE XDS, XCA und PHARM1 Transaktionen können zusätzlich zu den in der Tabelle angeführten Fehlern, noch andere in IHE definierte bzw. beschriebene Fehlermeldungen auftreten.

Detaillierte Fehlermeldungen des KBS¶

Damit Fehler beim Einbringen von Kontakten besser vom Anwender differenziert werden können, werden bei folgenden Fehlerursachen detaillierte Fehlertexte (display) bei gleichbleibendem Fehlercode (key) zurückgegeben:

Kontakteinmeldung zu weit in der Vergangenheit (90 Tage)
Kontakteinmeldung zu weit in der Zukunft (24 Stunden)
Stationäre Aufnahme auf bereits erfolgte stationäre Aufnahme
Stationäre Entlassung auf ambulante Aufnahme
Stationäre Entlassung auf Internet Kontakt
Stationäre Entlassung auf stationäre Entlassung
Entlassung ohne Aufnahme
Storno eines Kontakts ohne vorherige Kontakteinbringung
Stationäre Entlassung auf delegierten Kontakt

Fehlermeldungen der e-Medikation¶

Die e-Medikation retourniert im Falle eines Fehlers bei IHE Transaktionen einen XDS Fehler (XDSRepositoryError, XDSRepositoryMetadataError, XDSDocumentUniqueIdError, XDSDuplicateUniqueIdInRegistry, XDSMetadataUpdateOperationError, XDSMissingDocument) welcher im Attribut "codeContext" eine XML-Struktur enthält (EmedReturn). Der Typ "EmedReturn" kapselt die fachlichen Fehlermeldungen der e-Medikation. Diese Fehlermeldungen werden unverändert weitergereicht.

Wenn ein Fehler bei einer EMEDAT-1 Transaktion (GenerateDocumentID, RequestSecurityToken) auftritt, wird eine EmedAtException zurückgeliefert.

Weitere Details zu den e-Medikationsfehlermeldungen, sowie eine Liste der Fehlercodes siehe "PH_014_EMEDAT_SS_eMedikation_V1.08.docx", Kap. 2.5.7 "e-Medikation-Fehlermeldungen" bzw. Kap. "2.5.7.2 Liste e-Medikation-Fehlermeldungen".

SOAP Fault Fehler, die von der e-Medikation zurückgeliefert werden, können im ErrorValueSets.xml eingetragen werden, um den Fehler auch an den aufrufenden Client zu retournieren.

Beispiel der Konfiguration

<ValueSet codeSystem="SpiritErrorCodes" display="Unknown extern errors" key="UNKNOWN">
    <ErrorCode action_display="Contact SVC" action_key="EMED-021013_action" display="Es existiert kein Rezept mit derübergebenen DokumentId" key="EMED-021013" externReturnable="true" severity="ERROR" returnDetailInProduction="true"/>
</ValueSet>

Beispiel SOAP Fault der EMED APP:

eMed App SoapFault.xml

Wird der Wert EMED-021013 als ‘**key’ in einem ErrorCode** Element im ErrorValueSets.xml gefunden und externReturnable ist true, wird die SOAP Fault neu zusammengebaut und an den Client retourniert. Da die Fault neu erstellt wird, kann sie von der von der EMED APP zurückgelieferten abweichen. Inhaltlich ist jedoch die gesamte Information vorhanden. Ist zusätzlich der Wert returnDetailInProduction im** ErrorCode** Element auf true gesetzt, wird der Inhalt des ‘soap:Detail’ Elements in die neu erstelle SOAP Fault übernommen. Mit dem Wert addSubCode true/false im ErrorCode **Element kann beeinflusst werden, ob ein **fault:Subcode zurückgeliefert wird oder nicht.

Beispiel der neu erstellten SOAP Fault, die an die Anfrage zurückgeliefert wird:

eMed ZGF SoapFault.xml

Transaktionsklammer¶

Alle Audit Nachrichten beinhalten eine eindeutige Identifikation, die für alle Subtransaktionen identisch ist. Es wird die SOAP MessageID der ersten initiierenden SOAP Nachricht einer gesamten Transaktionskette im SOAP Header an alle folgenden Transaktionsziele (Z-PI, GDA-I, ELGA-Bereiche etc.) mit übergeben. Diese Identifikation wird von allen Services in die Audit Nachrichten übernommen. Wird vom ELGA Berechtigungssystem bereits eine Transaktionsklammer empfangen (Interface 2: Transaktionsklammer), wird diese für alle weiteren SOAP Nachrichten weiterverwendet. Die Transaktionsklammer wird derzeit in allen Requests auch im http-Header geführt.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2002/06/soap-envelope">
    <soap:Header>
        <elga:context xmlns="http://docs.oasis-open.org/ws-caf/2005/10/wsctx" xmlns:elga="http://elga.at/context/" soap:mustUnderstand="1">
            <context-identifier> urn:1.3.6.1.2.1.27.47114711 </context-identifier>
        </elga:context>
    </soap:Header>
</soap:Envelope>

Interface: Transaktionsklammer

Schreiben von ATNA Auditlogs¶

Alle ATNA Protokolle, die von der ZGF generiert werden, werden mittels Syslog Messages over TLS (RFC 5425) an das ATNA Audit Record Repository des ELGA Bereichs gesendet.

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

3.20 Record Audit Event

Inhalte der Auditnachrichten sind den "Security Considerations" der jeweiligen IHE ITI Transaktion zu entnehmen. ELGA spezifische Audit Inhalte sind im Pflichtenheft des A-ARR enthalten.

WSDL Files¶

	Erlaubt
	Erlaubt (ignored)
	Verboten