Slang: /* Obligations: reichen ja/nein-Angaben aus? */

2018-07-25T07:24:42Z

‎Obligations: reichen ja/nein-Angaben aus?

Slang: /* "Enforcable" vs. "Computable" */

2018-07-17T13:07:52Z

‎"Enforcable" vs. "Computable"

Slang: Die Seite wurde neu angelegt: „=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. =In…“

2018-07-17T12:27:34Z

Die Seite wurde neu angelegt: „=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. =In…“

Neue Seite

=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 differenzierte 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.<br>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) [https://chat.fhir.org/#narrow/stream/27-german-(d-a-ch)/topic/Einwilligungsmanagement.20-.20Workflows Chat]
** Datenstrukturen (Martin Bialke, Lars Geidel, Stefan Lang, Olaf Rode) [https://chat.fhir.org/#narrow/stream/27-german-(d-a-ch)/topic/Einwilligungsmanagement.20-.20Strukturen 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.

← Nächstältere Version		Version vom 17. Juli 2018, 13:07 Uhr
Zeile 22:		Zeile 22:

	Computable := die Maschine selbst verarbeitet die Regel und wendet sie an.		Computable := die Maschine selbst verarbeitet die Regel und wendet sie an.
−

	==Policy Decision Point, Policy Repository==		==Policy Decision Point, Policy Repository==

@@ Zeile 37: / Zeile 37: @@
 ==Obligations: reichen ja/nein-Angaben aus?==
-Sollten differenzierte Antwortmöglichkeiten als "ja" und "nein" berücksichtigt werden?
+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".

AG Einwilligungsmanagement Protokoll 2018-06-28 - Versionsgeschichte

Slang: /* Obligations: reichen ja/nein-Angaben aus? */

Slang: /* "Enforcable" vs. "Computable" */

Slang: Die Seite wurde neu angelegt: „=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. =In…“