Einwilligungs- und Berechtigungsmanagement¶

Die größte Komplexität und einhergehende Risiken befinden sich bei der Umsetzung des Einwilligungs- und Berechtigungsmanagements. Deshalb wird hier auf die Erweiterung bereits etablierter Verfahren, die einerseits in ELGA entwickelt und anderseits über die letzten Jahre in internationalen Projekten erweitert und verfeinert wurden, gesetzt.

Generell werden die bereits in ELGA entwickelten Verfahren auch für AC weiterverwendet. Es werden Treatment-Assertions für die Remote Kommunikation zwischen den AGWs verwendet.

Im Unterschied zum ELGA PAP, der auf WS-Trust Schnittstellen aufbaut, verwendet der AC PAP eine XDS-Schnittstelle und BPPC Dokumente.

Beim Ausstellen von Treatment-Assertions werden spezifische Prüfungen, abhängig davon wie der AC konfiguriert wurde bzw. welche Optionen aktiviert wurden, gemacht. Zusätzlich werden XACML Policies durchgesetzt, die entweder statischer Natur sein können (wie die heutigen generellen ELGA Policies) oder aber auch individuelle Berechtigungen für einen Patienten. Es werden also grundsätzlich weiter die gleichen Prinzipien angewendet, es werden jedoch neue bzw. andere Schnittstellen verwendet, um z.B. individuelle Berechtigung zu vergeben.

Die generelle Erlaubnis den zentralen AC PAP verwenden zu dürfen wird einer Rolle über die Permission urn:elga:bes:2019:permission:{{AppId}}:pap:noContact zugeordnet.

Wenn ein GDA / Patient keine Berechtigung für den AC PAP hat, wird die Nachricht mit einer AccessDenied SoapFault abgelehnt.

Im Kontext AC PAP werden keine Prüfungen auf Kontakte durchgeführt.

Generelle AC XACML Policy¶

Die generelle AC XACML Policy erfüllt prinzipiell denselben Zweck wie die generelle ELGA Policy - es wird ein statisches (zeitlich stabiles), generelles Regelset erarbeitet, welches als Template dienen kann, um gezielt Teilbereiche einer generellen AC Policy einfach zu aktivieren bzw. deaktivieren zu können. Auch ein Füllen der Werte in die vordefinierten Policy Templates ist möglich (Liste berechtigter Rollen, Liste teilnehmender GDA, etc.).

Statisch generelle AC XACML Policies werden wie bereits die ELGA generellen Policies im File System Store des BeS verwaltet.

Um die größtmögliche Flexibilität und Standardisierung zu gewährleisten, werden XACML Policies im XACML Format für einen AC bereitgestellt.

Beispiel AC-XACML Policy.xml

BPPC Einwilligungen an den zentralen PAP¶

Wenn individuelle Policies unvermeidbar sind und ein Patient das Recht hat zu widerrufen bzw. die Pflicht einzuwilligen, wird die Berechtigungssteuerung Richtung PAP mittels IHE ITI XDS ITI-41 Transaktion mit einem BPPC realisiert. Die gesamte semantische Steuerung der Berechtigungen wird durch die eventCode IDs im BPPC bzw. durch andere Metadaten wie den Autor realisiert. Das CDA hat dabei keine Relevanz, es müssen jedoch folgende Werte der BPPC Metadaten mit dem CDA übereinstimmen:

Die templateId des CDA/ServiceEvent muss den Wert 1.3.6.1.4.1.19376.1.5.3.1.2.6 enthalten.
Die Attribute code und codeSystem des serviceEvent/code müssen mit der EventCodeList der Metadaten übereinstimmen.

Das BPPC Dokument wird mit einer AC Kontext-Assertion an die AGW gesendet, die AGW leitet die Anfrage an den zentralen PAP weiter. Der PAP bietet eine XDS Schnittstelle, um die BPPC Dokumente empfangen zu können. Jedes BPPC entspricht faktisch einer Berechtigung, die durch einen eventCode entweder aktiviert oder deaktiviert wird. Berechtigte GDAs können mittels Autorenangabe im BPPC Dokument übermittelt werden.

Der sendende GDA bzw. Bürger muss in der SAML Assertion eine OrganizationID verwenden die einem Autor im BPPC (AuthorInstitution) entspricht. Bei CONSENT_SCOPE='org' wird der sendende GDA bzw. Bürger je nach eventCode immer automatisch berechtigt oder widerrufen. Weitere zu berechtigende GDA OIDs müssen in der AuthorInstitution des BPPC Dokumentes mitgegeben werden.

Die BPPC Metadaten und das CDA werden vom PAP in derselben Datenbankinstanz des existierenden ELGA PAP gespeichert.

Optional: mit der Konfiguration PAP_USE_PDF:true muss zusätzlich zum BPPC Dokument auch ein PDF Dokument eingebracht werden. Der Inhalt des Dokuments wird von BeS nicht überprüft.

Es wird jeweils ein Eintrag in der PAP-Tabelle erstellt für:

BPPC Metadaten
BPPC Binary (CDA)
PDF Metadaten
PDF Binary

Der AC PAP schreibt dabei folgende Werte in die existierende PAP Tabelle (siehe DB_Schemabeschreibung_BeSv5.0.xlsx):

PAP_PK: SHA256 von der UUID (Metadaten) bzw. der DocumentUniqueId (Binary)
PAP_ID: die bPK-GH des Patienten / Bürgers
PAP_APPID: die e-Health Anwendung-ID - z.B. 103 für e-Impfpass
PAP_TYPE: enthält abhängig vom Eintrag folgende Werte
- BPPC Metadaten: Wert 5 (AC_BPPC)
- BPPC Binary: Wert 6 (AC_BPPC_DOC)
- PDF Metadaten: Wert 7 (AC_PDF)
- PDF Binary: Wert 8 (AC_PDF_DOC)
PAP_CREATIONTIME: aktuelle Zeit zu der die Einwilligung in die Datenbank eingebracht wurde
PAP_INFOFLAG: Information zur getätigten Einwilligung - 2 für OPT-IN und 1 für OPT-OUT
PAP_DATA:
- die XDS Metadaten des BPPC bzw. PDF Dokumentes. Es wird das ExtrinsicObject der Anfrage übernommen. Siehe auch: BPPC_IN.xml, BPPC_PDF_IN.xml und BPPC_OUT.xml
- der Inhalt des Attachments (CDA bzw. PDF)
PAP_STATE: STATE_ACTIVE (0) für aktive Einwilligungen. Gibt es bereit Einträge für den Patienten für diesen AC werden die Einträge auf STATE_INACTIVE (1) gesetzt

Bis auf die Inhalte in PAP_APPID, PAP_DATA und der PAP_TYPE Spalte sind die verwendeten Inhalte grundsätzlich ident mit dem ELGA PAP.

Bei der Berechtigungsprüfung (Ausstellen einer AC Kontext-Assertion) werden die PAP Einträge mit PAP_STATE:ACTIVE für den jeweiligen Patienten (bPK-GH) abgefragt.

Wird keine Einwilligung gefunden, wird die vom AC OPT_MODE (in bzw. out) gewählte default Policy geladen und durchgesetzt.

Wird eine Einwilligung gefunden, wird entweder eine PERMIT oder DENY Policy geladen und durchgesetzt.

Die gefundene Einwilligung wird nur verwendet, wenn folgende Kriterien zutreffen:

existiert eine ServiceStartTime im BPPC muss diese größer als der aktuelle Zeitstempels (now) sein
existiert eine ServiceStopTime im BPPC muss diese kleiner der aktuelle Zeitstempels (now) sein
ist der AC CONSENT_SCOPE=org muss im BPPC eine AuthorInstitution Organization ID der des Anfragenden entsprechen (SAML XSPA Organization ID)

Kann die Einwilligung aus den angeführten Gründen nicht verwendet werden, wird wieder die vom AC OPT_MODE (in bzw. out) gewählte default Policy geladen und durchgesetzt.

Bürger und deren Vertreter können kein BPPC Dokument für einen anderen Bürger einbringen.

Alle Transaktionen an den zentralen AC PAP müssen an die AGW gesendet werden und werden von dieser an den zentralen AC PAP Endpunkt weitergeleitet.

XDS ITI-41 BPPC Einwilligung an den zentralen PAP¶

Die BPPC Dokumente werden vom Client an die AGW gesendet und von der AGW an den zentralen PAP weitergeleitet.

Bei CONSENT_SCOPE=org wird nur wenn ein Permit für den zugreifenden GDA existiert, auch eine Treatment-Assertion ausgestellt. Dieses Verhalten kann durch ein konfiguriertes default Verhalten umgekehrt werden (via OPT_MODE).

Bei CONSENT_SCOPE=app bezieht sich die Einwilligung oder der Widerspruch auf den gesamten AC und ist unabhängig der sendenden oder zugreifenden Organisation.

Element	Opt	Beschreibung
authorInstitution	R	Der ID Teil der authorInstitution muss mit dem Wert `organization-id` der SAML Assertion übereinstimmen
patientId	R	Wenn ein Bürger einen Consent einbringt muss die patientId mit dem Wert `resource-id` der SAML Assertion übereinstimmen

Tabelle: SubmissionSet Metadaten

Element	Opt	Beschreibung
id	R	Wird als UUID der XDS Metadaten (id Attribut des ExtrinsicObject) ein Wert verwendet der mit `urn:uuid:` beginnt, wird die UUID des Senders übernommen (Der UUID Wert muss in diesem Fall eindeutig sein). Beginnt der Wert nicht mit `urn:uuid:` wird vom BeS eine neue UUID erzeugt.
authorInstitution	R	Der ID Teil der authorInstitution muss mit dem Wert `organization-id` der SAML Assertion übereinstimmen
classCode	R	codingScheme: urn:oid:2.16.840.1.113883.6.1 nodeRepresentation: 57016-8
formatCode	R	codingScheme: urn:oid:1.2.40.0.34.5.37 nodeRepresentation: urn:elga:bppc:2024:cda
eventCodeList	R	codingScheme: urn:elga:bes:2019:{AC_HCID}.8.{AppId} nodeRepresentation: urn:elga:bes:2019:{AC_HCID}.8.{AppId}.1 AC_HCID ohne `urn:oid:`
patientId	R	Wenn ein Bürger einen Consent einbringt muss die patientId mit dem Wert `resource-id` der SAML Assertion übereinstimmen
uniqueId	R	Es muss eine eindeutige `XDSDocumentEntry.uniqueId` in den Metadaten vorhanden sein. Der Wert wird nachfolgend für die ITI-43 Transaktion verwendet um entsprechende Dokumente abzurufen
serviceStartTime	O	Ist eine serviceStartTime im BPPC vorhanden wird dieses nur verwendet, wenn es bereits gültig ist (serviceStartTime<now)
serviceStopTime	O	Ist eine serviceStopTime im BPPC vorhanden wird dieses nur verwendet, wenn es noch gültig ist (serviceStopTime>now)

Tabelle: BPPC Metadaten

Element	Opt	Beschreibung
id	R	Wird als UUID der XDS Metadaten (id Attribute des ExtrinsicObject) ein Wert verwendet der mit `urn:uuid:` beginnt, wird die UUID des Senders übernommen (Der UUID Wert muss in diesem Fall eindeutig sein). Beginnt der Wert nicht mit `urn:uuid:` wird vom BeS eine neue UUID erzeugt.
authorInstitution	R	Der ID Teil der authorInstitution muss mit dem Wert `organization-id` der SAML Assertion übereinstimmen
classCode	R	codingScheme: urn:oid:2.16.840.1.113883.6.1 nodeRepresentation: 57016-8
formatCode	R	codingScheme: urn:oid:1.2.40.0.34.5.37 nodeRepresentation: urn:elga:bppc:2024:pdf Wie bereits erwähnt, muss mit der Option `PAP_USE_PDF:true` zusätzlich zum BPPC Dokument auch ein PDF Dokument eingebracht werden (mit demselben Request - siehe Beispiel). Der formatCode des PDF muss sich von dem des BPPC unterscheiden.
patientId	R	Wenn ein Bürger einen Consent einbringt muss die patientId mit dem Wert `resource-id` der SAML Assertion übereinstimmen
uniqueId	R	Es muss eine eindeutige `XDSDocumentEntry.uniqueId` in den Metadaten vorhanden sein. Der Wert wird nachfolgend für die ITI-43 Transaktion verwendet um entsprechende Dokumente abzurufen.

Tabelle: PDF Metadaten

BPPC_IN.xml

BPPC_PDF_IN.xml

XDS ITI-41 BPPC Widerruf an den zentralen PAP¶

Auch die Widerrufsnachricht wird von der AGW an den zentralen PAP weitergeleitet. Bei CONSENT_SCOPE=org werden die Berechtigungen des sendenden GDA und optional zusätzlicher Autoren aus den BPPC Metadaten für den betroffenen Patienten und den AC widerrufen.

Bei CONSENT_SCOPE=app bezieht sich der Widerspruch auf den gesamten AC und ist unabhängig vom sendenden oder zugreifenden GDA.

Bei einem Widerruf werden keine weiteren Aktionen wie Löschen von Dokumenten durchgeführt.

Verwendeter eventCode:

codingScheme

urn:elga:bes:2019:{AC_HCID}.8.{AppId}
- AC_HCID ohne urn:oid:

nodeRepresentation

urn:elga:bes:2019:{AC_HCID}.8.{AppId}.0
- AC_HCID ohne urn:oid:

Der Rest der Metadaten ist auch bei einem Widerruf ident wie im vorigen Kapitel XDS ITI-41 BPPC Einwilligung an den zentralen PAP beschrieben zu verwenden.

BPPC_OUT.xml

Individuelle AC Berechtigungen¶

Es werden vom AC PAP keine XACML Policies generiert, sondern eine JA (Einwilligung) bzw. NEIN (Widerruf) Berechtigung für den jeweiligen AC in der PAP Datenbank gespeichert. Zusätzlich werden die XDS Metadaten gespeichert um die Information der Autoren/Organisation zur Verfügung zu haben, wenn der CONSENT_SCOPE='org' in Verwendung ist.

Das CDA Dokument selbst hat keine Relevanz für das Einwilligungsmanagement und wird deshalb aus Datensparsamkeitsgründen nicht gespeichert. Etwaige zukünftige Signaturen für den AC Consent sind gesondert zu diskutieren und eher an einem PDF anzubringen als am CDA.

Die gespeicherten Berechtigungen werden nachfolgend vom ETS beim Ausstellen einer Treatment-Assertion durchgesetzt.

Zusätzliche Prüfungen der Metadaten des BPPC die vom ETS durchgeführt werden:

AuthorInstitution
- bei CONSENT_SCOPE='org' werden nur die jeweiligen Organisationen (AuthorInstitution) berechtigt bzw. unterbunden. Für andere Organisationen wird der default Consent herangezogen.
serviceStartTime (optional)
- ist eine serviceStartTime im BPPC vorhanden wird dieses nur verwendet, wenn es bereits gültig ist (serviceStartTime<now).
serviceStopTime (optional)
- ist eine serviceStopTime im BPPC vorhanden wird dieses nur verwendet, wenn es noch gültig ist (serviceStopTime>now)

Berechtigungsprüfung¶

Wie schon in der Einleitung von diesem Kapitel erwähnt, ist der generelle Ansatz zum Durchsetzen der Berechtigungen von denen in ELGA bereits verwendeten Methoden abgeleitet – es werden jedoch keine individuellen XACML Policies erzeugt.

Zusätzlich zu der Prüfung von statischen generellen Policies, die zentral XACML exekutiert werden und den individuellen Berechtigungen, die durch BPPC Metadaten vom PAP erstellt werden, ist einer der Hauptaufgaben der dezentralen ZGF SAML-Assertions zu prüfen.

Die statische generelle Policy für den AC wird am ETS beim Anfordern einer Treatment Assertion für den AC durchgesetzt. Muss der Patient zu einem AC nicht zustimmen bzw. kann er nicht widersprechen, sind keine zusätzlichen BPPC Dokumente notwendig. Bei diesem Ansatz wird von einem No-Opt Mode gesprochen - der e-Impfpass ist hierfür ein gutes Beispiel. In diesem Fall können kein BPPC Dokumente eingebracht werden – beim Versuch wird ein wsse:UnsupportedSecurityToken Fehler zurückgegeben.

Für den Opt-In bzw. Opt-Out Mode werden, wie bereits erwähnt, BPPC Metadaten verwendet, um eine Zustimmung bzw. einen Widerruf des Patienten einzuholen. Die BPPC Metadaten werden dann zusätzlich zu den statischen AC Policies beim Ausstellen der Treatment-Assertion angewendet und durchgesetzt.

Die gesamte Berechtigungsprüfung wird zentral beim Ausstellen der AC Treatment-Assertion durchgeführt. Hierbei wird auch ein Pre-Enforcement vor der XACML Prüfung durchgeführt und geprüft, ob zumindest eine Permission für den jeweiligen XACML Action (read, write, update) in der Assertion vorhanden ist. Wenn nicht wird vom ETS eine AccessDenied SOAP Fault zurückgegeben – die ZGF übersetzt diesen Fehler nachfolgend auf einen transaktionsspezifischen (wie z.B: DocumentSubmitDenied) der an den Client zurückgeliefert wird.

Die ZGF prüft ausschließlich die Treatment-Assertion und führt kein weiteres Enforcement durch.

BPPC/PDF Einwilligungen im zentralen PAP suchen¶

Es können mittels ITI-18 FindDocuments Transaktion die aktiven und inaktiven BPPC bzw. PDF Metadaten vom zentralen XDS AC PAP für einen AC und einen Patienten abgefragt werden.

Verpflichtende Suchparameter sind:

AdhocQueryRequest/ResponseOption@returnComposedObjects muss den Wert true enthalten
AdhocQueryRequest/ResponseOption@returnType muss den Wert LeafClass enthalten
AdhocQueryRequest/AdhocQuery@id muss den Wert urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d enthalten
$XDSDocumentEntryPatientId
- wird keine bPK-GH verwendet wird die Patienten-ID mittels Z-PI Query übersetzt
$XDSDocumentEntryStatus
- Es können folgende Status Werte für die Abfrage verwendet werden:
  - urn:oasis:namesebxml-regrep:StatusType:Approved
    - es werden aktuelle Dokumente zurückgegeben
  - urn:oasis:namesebxml-regrep:StatusType:Deprecated
    - es werden nicht mehr aktive Dokumente zurückgegeben
- Die Statuswerte können auch kombiniert werden um in einer Anfrage Approved und Deprecated Dokumente abzufragen

Optionale Suchparameter sind:

$XDSDocumentEntryFormatCode
mittels formatCode Parameter kann auf BPPC bzw. PDF Dokumente eingeschränkt werden
im Kontrast zu IHE XDS ist das Schema nicht verpflichtend - es kann auch mit dem Code alleine abgefragt werden
mit mehreren Value Elementen in der ValueList können mehrere formatCodes angegeben werden

Alle weiteren Suchparameter werden ignoriert.

Wie bereits beim Einbringen von BPPC Dokumenten ist die gesamte Semantik in den Metadaten enthalten.

DocumentEntry.eventCodeList in der Antwort:

OPT-OUT:
- urn:elga:bes:2019:{AC_HCID}.8.{AppId}.0
OPT-IN:
- urn:elga:bes:2019:{AC_HCID}.8.{AppId}.1

Wie bereits beim Einbringen von Einwilligungen wird auch beim Abfragen eine AC Kontext-Assertion erwartet. Die Antwort enthält die DocumentEntries (ExtrinsicObject) für den angefragten AC (AC Kontext-Assertion) für jeweils einen Patienten ($XDSDocumentEntryPatientId).

Bei der Suche von Metadaten ist folgendes Antwortverhalten in Bezug auf externe Fehler zu erwarten:

generelle Fehler bei der Nachrichtenverarbeitung verhalten sich gleich wie bei anderen BeS Services (z.B: prüfen der SAML Assertion)
wenn der PAP bei diesem AC nicht aktiviert ist wird ein AccessDenied SOAP Fault zurückgegeben
bei allen anderen Fehlern wird ein XDSRequestFailed Registry Error zurückgeliefert

papQuery.xml

papQueryRsp.xml

BPPC/PDF Inhalte vom zentralen PAP abrufen¶

Es können mittels ITI-43 Retrieve Document Set Transaktion die aktiven und inaktiven BPPC bzw. PDF Inhalte vom zentralen XDS AC PAP für einen AC abgerufen werden. Wie bei allen anderen Transaktionen muss auch hierfür eine AC Kontext-Assertion verwendet werden.

Verpflichtende Parameter für die Abfrage:

pro Dokument muss ein RetrieveDocumentSetRequest/DocumentRequest Element angegeben werden in dem folgende Werte enthalten sind:
DocumentUniqueId muss den Wert aus XDSDocumentEntry.uniqueId der Metadaten beinhalten
RepositoryUniqueId das Element muss vorhanden sein und einen Wert beinhalten. Der Wert selbst wird von BeS nicht überprüft jedoch in der Antwort zurückgeliefert. Die zu verwendende OID ist 1.2.40.0.34.6.110.1.4.
es können mehrere DocumentRequest Elemente in einer Anfrage existieren

Beim Abruf von Dokumenten ist folgendes Antwortverhalten in Bezug auf externe Fehler zu erwarten:

siehe auch: BPPC/PDF Einwilligungen im zentralen PAP suchen
ist eine DocumentUniqueId nicht bekannt wird die gesamte Transaktion mit einem XDSDocumentUniqueIdError abgelehnt

papRetrieve.xml

papRetrieveRsp.xml