AG Einwilligungsmanagement Protokoll 2018-06-28: Unterschied zwischen den Versionen
Slang (Diskussion | Beiträge) (→"Enforcable" vs. "Computable") |
Slang (Diskussion | Beiträge) K (→Obligations: reichen ja/nein-Angaben aus?) |
||
Zeile 37: | Zeile 37: | ||
==Obligations: reichen ja/nein-Angaben aus?== | ==Obligations: reichen ja/nein-Angaben aus?== | ||
− | Sollten | + | Sollten differenziertere Antwortmöglichkeiten als "ja" und "nein" berücksichtigt werden? |
Beispiel: "Alle dürfen auf mein Daten zugreifen, aber ich möchte darüber informiert werden". | Beispiel: "Alle dürfen auf mein Daten zugreifen, aber ich möchte darüber informiert werden". |
Aktuelle Version vom 25. Juli 2018, 07:24 Uhr
Inhaltsverzeichnis
Scope und Ziele der AG
Dem Entwurfstext wird in der aktuellen Form zugestimmt. Der Text erscheint auf der noch zu erstellenden Projektseite im HL7-Wiki.
Inhaltliche Diskussionspunkte
Definition "Policy"
- eine Policy hat immer einen (Instanz-)Identifier
- eine Policy ist ein logisches Konstrukt
- eine Policy ist immer enforceable
- eine Policy KANN computable sein (das wäre dann XACML)
Noch unklar: ist eine Policy
A) Die kleinste zustimmbare Einheit
B) Der komplette Hierarchie-Baum einer Zustimmung
In der Implementierung kann es u.U. hinreichend sein, nur auf Identifier (von XACML-Policies oder anderen Arten von Policies) zu verweisen.
"Enforcable" vs. "Computable"
Beispiel: Aktionen in einer Biobank sind durchsetzbar (enforceable), aber nicht computable.
Computable := die Maschine selbst verarbeitet die Regel und wendet sie an.
Policy Decision Point, Policy Repository
Def: POLICY REPOSITORY: Inhalte (z.B. XACML) werden dort abgelegt
Def: POLICY DECISION POINT: Verarbeitet die Policies aus dem Repository (Priorisierung, Aggregierung) und "errechnet die Entscheidung"
Def: POLICY ENFORCEMENT POINT: Ist der Punkt, wo die Anfrage abgefangen wird. Er fragt den Policy Decision Point an und setzt die Antwort um.
Diskussion: Sind diese im Scope dieser AG?
Ergebnis: Consents landen üblicherweise im Policy Repository. Insofern wird dieses berücksichtigt (insbesondere, da auch Workflows im Scope sind, d.h. es ist als Aktor vorhanden). Für die Funktionsweisen im Detail reicht die Referenzierung aus (z.B. XACML-Funktionsmodell).
Obligations: reichen ja/nein-Angaben aus?
Sollten differenziertere Antwortmöglichkeiten als "ja" und "nein" berücksichtigt werden?
Beispiel: "Alle dürfen auf mein Daten zugreifen, aber ich möchte darüber informiert werden".
In GICS sind dies Properties, die Aktionen triggern können. Typisch: Benachrichtigung des Pat., zusätzliche Auditierung
Diskussionsergebnis (vorläufig): vertagt, bis Grundlagen und weitere Details geklärt sind.
Alternativen zu XACML
Diskussion: Ist XACML gesetzt oder sollen (auch) Alternativen gesucht werden, z.B. mittels "reinem FHIR"?
Diskussionsergebnis: Dies ist grundsätzlich offen, aber: XACML ist an vielen Stellen gesetzter Standard und eine echte Alternative existiert derzeit nicht.
Weiteres Vorgehen
- Die konkrete Analyse- und Spezifikations-Arbeit soll in Unter-Arbeitsgruppen erfolgen. Ergebnisse bzw. Zwischenstände werden dann in der AG vorgestellt und diskutiert.
Für die Unter-AGs haben sich jeweils Teilnehmer bereit erklärt, die Kern-Tätigkeiten wahrzunehmen. Die Teilnahme hieran steht jedoch jedem offen. Termine werden über den jeweiligen Zulip-Chat bekannt gegeben. - Für die weiteren Besprechungen der Gesamt-Arbeitsgruppe wird ein Jour-Fix Online-Meeting alle 4 Wochen als sinnvoll erachtet. Zur Terminfindung wird einmalig ein Doodle erstellt.
- Auf dem nächsten Meeting (Ende 07/2018) wird Sebastian Stäubert seine Workflow-Analyse präsentieren.
- Auf dem übernächsten Meeting (Ende 08/2018) wird Tarik Idris eine Kurzübersicht zu XACML geben.