EFA Policy Provider Service Functional Model

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
(→‎Policy Pull vs. Policy Push)
(→‎EFA Policy Provider)
Zeile 27: Zeile 27:
 
Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet.
 
Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet.
  
−
[[Datei:PIM_SEQ_Policy_Pull.png|640px]]  
+
[[Datei:PIM_SEQ_Policy_Pull.png|480px]]  
  
 
=== Client Policy Push ===
 
=== Client Policy Push ===
  
−
Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des [[cdaefa:EFA_Security_Informationsmodell#context|EFA-Nutzerkontextes]] im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer [[cdaefa:EFA_Policy_Assertion_SAML2_Binding|Policy Assertion]] mitgegeben.
+
Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des [[cdaefa:EFA_Security_Informationsmodell#context|EFA-Nutzerkontextes]] im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer [[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]] mitgegeben.
  
−
[[Datei:PIM_SEQ_Policy_Push.png|640px]]
+
[[Datei:PIM_SEQ_Policy_Push.png|480px]]
  
−
=== Operationen des EFA-Policy-Managements ===
+
=== requestPolicy ===
−
Die nachfolgende Tabelle listet die vom EFA Policy Provider bereit gestellten Operationen.
+
Zur Umsetzung des Policy Push Verfahrens muss der EFA Policy Provider eine Schnittstelle zum Abruf der für einen Nutzerkontext und eine zu verarbeitende Fallakte gültigen Policy bereitstellen.  
−
 
 
−
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
−
!Operation
 
−
!Beschreibung
 
−
|-
 
−
|registerPolicy
 
−
|Registriert eine neue Access Policy auf Basis eines [[cdaefa:EFA_Einwilligungsdokument|Einwilligungsdokuments]].
 
−
|-
 
−
|activatePolicy
 
−
|Aktiviert eine Access Policy auf Grundlage verschiedener Attribute bzw. Kennzeichen (Zweck, Patient, Rolle, Kontext etc.). Eine aktivierte Access Policy autorisiert eine Rolle für einen bestimmten Verarbeitungskontext. Die ''activatePolicy''-Operation wird implizit von der ''requestPolicy''-Operation aufgerufen.
 
−
|-
 
−
|requestPolicy
 
−
|Für die Evaluierung einer Autorisierungsentscheidung muss ein Authorization Decision Provider Zugriff auf entsprechende Policies haben. Dazu fragt dieser Policies mit zwei verschiedenen Semantiken an:
 
−
* Verweis ohne Semantik (PolicyID) auf eine Policy, welche die gültigen Berechtigungsregeln eines EFA-Teilnehmers enthält
 
−
* Verweis mit Semantik (z.B. gemäß IHE BPPC). ''Hinweis'': Für eine Zugriffskontrolle kann der Authorization Decision Provider bereits implizit im Programmcode des jeweiligen Anwendungsdienstes implementiert sein, welcher den Verweis entsprechend interpretiert. In diesem Fall kann auf den Akteur EFA Policy Provider verzichtet werden. Lediglich für ein Policy-Push-Szenario muss der Verweis mit Semantik unterstützt werden (siehe unten).
 
−
* Attribute, die einen Verarbeitungskontext beschreiben
 
−
|}
 
−
 
 
−
Die EFA-Spezifikation macht keine normativen Vorgaben wie diese Operationen implementiert werden. Einzige Ausnahme ist der Fall, dass der EFA-Kontext-Manager die Access Policy anfordert und diese beim Zugriff auf eine Fallakte mitsendet (Policy Push). Damit wird schließlich dem Authorization Decision Provider die Access Policy für die Zugriffskontrolle übergeben. Die Operation ''requestPolicy'' hat die folgende formale Schnittstelle:
 
  
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
Zeile 62: Zeile 43:
 
|-
 
|-
 
|Funktionalität
 
|Funktionalität
−
| colspan="2"| Gibt eine Autorisierung zum Zugriff auf eine Fallakte wieder.
+
| colspan="2"| Stellt eine für einen angegebenen Nutzer zum Zugriff auf eine benannte Fallakte gültige Policy in Form eines Berechtigungsregelwerks bereit.
 +
|-
 +
|rowspan="3" | Eingabe
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|Nutzerkontext, der eine [[cdaefa:EFA_Security_Informationsmodell#subjectIdentity|subjectIdentity] zur Identifizierung des Nutzers enthält, dessen Berechtigungen auf der angegebenen Fallakte abgerufen werden sollen.
 
|-
 
|-
−
|rowspan="4" | Eingabe
 
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
 
|[[cdaefa:EFA_Business_Informationsmodell#ecrRef|ecrRef]]
−
|Eindeutige Identifizierung der Fallakte, für die Berechtigungen abgefragt werden.
+
|Eindeutige Identifizierung der Fallakte, für die Berechtigungen abgefragt werden sollen.
−
|-
 
−
|HPIdentityAssertion
 
−
|Ein gültiger Authentifizierungsnachweis des EFA-Teilnehmers, dessen Berechtigungen für die benannte Fallakte abgefragt werden.
 
 
|-
 
|-
 
|consentInfo (optional)
 
|consentInfo (optional)
−
|Informationen zu der vom Patienten gegebenen Einwilligung
+
|Informationen zu einer vom Patienten gegebenen Einwilligung. ''Dieses Argument wird für Ad-Hoc-Berechtigungen und Additive Berechtigungen benötigt und näher ausspezifiziert, wenn die entsprechenden Verfahren im Detail definiert sind.''
 
|-
 
|-
 
|Rückgabe
 
|Rückgabe
−
|Access Policy Assertion
+
|[[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]]
−
|Autorisierungsnachweis, welcher entweder einen Verweis (mit oder ohne Semantik) auf eine Berechtigung oder eine explizite Access Policy enthält und somit die Autorisierung des aktuellen EFA-Teilnehmers bestätigt.
+
|Für den aktuellen Kontext und die angegebene Fallakte gültigen Berechtigungsregeln.
 
|-
 
|-
 
|Vorbedingungen
 
|Vorbedingungen
 
| colspan="2"|
 
| colspan="2"|
 
# Der EFA-Teilnehmer hat sich authentisiert und ein Nachweis liegt vor
 
# Der EFA-Teilnehmer hat sich authentisiert und ein Nachweis liegt vor
−
# Policies und/oder Verweise wurden registriert
+
# Policies für die angefragte Fallakte sind beim Policy Provider registriert
 
|-
 
|-
 
|Ablaufsequenz
 
|Ablaufsequenz
 
| colspan="2"|
 
| colspan="2"|
 
# Überprüfe die Authentizität des Authentisierungsnachweises
 
# Überprüfe die Authentizität des Authentisierungsnachweises
−
# Aktiviere die Access Policy anhand der Eingabedaten
+
# Ermittle die zu verwendende Access Policy anhand der Eingabedaten
−
# Returniere die Access Policy an den Aufrufer
+
# Liefere Access Policy an den Aufrufer zurück
 
|-
 
|-
 
|Mögliche Fehler
 
|Mögliche Fehler
 
|MissingAttributes
 
|MissingAttributes
−
|Autorisierung konnte nicht erfolgen, da Attribute für die Policy-Aktivierung nicht vorhanden waren.
+
|Für die Auswahl der zu verwendenden Policy erforderliche Angaben zum EFA-Teilnehmer fehlen.
 
|}
 
|}
  

Version vom 15. November 2013, 14:43 Uhr

Logo-hl720.jpg
EFA Policy Provider Service Functional Model
EFA Policy Provider Service Functional Model
Implementierungsleitfaden
vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch
Draft
Version: 0.9
Datum: March 2013
Status: xxx
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2012-2013: HL7 Deutschland


Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA Policy Provider

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocye.01}

Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zuständig. Berechtigungen sind an einen bestimmten Zweck gebunden und steuern den Zugriff von EFA-Teilnehmern auf eine Fallakte.

Policy Pull

Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet.

PIM SEQ Policy Pull.png

Client Policy Push

Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des EFA-Nutzerkontextes im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer subjectAccessPolicy mitgegeben.

PIM SEQ Policy Push.png

requestPolicy

Zur Umsetzung des Policy Push Verfahrens muss der EFA Policy Provider eine Schnittstelle zum Abruf der für einen Nutzerkontext und eine zu verarbeitende Fallakte gültigen Policy bereitstellen.

Operation requestPolicy
Funktionalität Stellt eine für einen angegebenen Nutzer zum Zugriff auf eine benannte Fallakte gültige Policy in Form eines Berechtigungsregelwerks bereit.
Eingabe context Nutzerkontext, der eine [[cdaefa:EFA_Security_Informationsmodell#subjectIdentity|subjectIdentity] zur Identifizierung des Nutzers enthält, dessen Berechtigungen auf der angegebenen Fallakte abgerufen werden sollen.
ecrRef Eindeutige Identifizierung der Fallakte, für die Berechtigungen abgefragt werden sollen.
consentInfo (optional) Informationen zu einer vom Patienten gegebenen Einwilligung. Dieses Argument wird für Ad-Hoc-Berechtigungen und Additive Berechtigungen benötigt und näher ausspezifiziert, wenn die entsprechenden Verfahren im Detail definiert sind.
Rückgabe subjectAccessPolicy Für den aktuellen Kontext und die angegebene Fallakte gültigen Berechtigungsregeln.
Vorbedingungen
  1. Der EFA-Teilnehmer hat sich authentisiert und ein Nachweis liegt vor
  2. Policies für die angefragte Fallakte sind beim Policy Provider registriert
Ablaufsequenz
  1. Überprüfe die Authentizität des Authentisierungsnachweises
  2. Ermittle die zu verwendende Access Policy anhand der Eingabedaten
  3. Liefere Access Policy an den Aufrufer zurück
Mögliche Fehler MissingAttributes Für die Auswahl der zu verwendenden Policy erforderliche Angaben zum EFA-Teilnehmer fehlen.

Querverweise und Referenzen

Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:EFA_Policy_Provider_SFM&oldid=16140“