AG Einwilligungsmanagement Protokoll 2018-06-28

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.
  • Workflows (Danny Ammon, Tarik Idris, Sebastian Stäubert) Chat
  • Datenstrukturen (Martin Bialke, Lars Geidel, Stefan Lang, Olaf Rode) Chat
  • Glossar (Patrick Werner)
• 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.