search

medizininformatik-initiative / kerndatensatzmodul-consent

Kerndatensatzmodul Consent
2 stars 0 forks source link

Verwendung Consent Ressource bei Vorliegen von (mehreren) Consent(s) bzw. Widerruf(en) #21

Open SebStaeubert opened 1 year ago

SebStaeubert commented 1 year ago

Frage 1: Umgang mit mehreren Consents -> eine Consent-Ressource mit der "letzten" Wahrheit erzeugen -> Beschreibung im IG Frage 2: Umgang mit mehreren Widerruf -> eine Consent-Ressource mit der "letzten" Wahrheit erzeugen, die mehrere periods zu einer Policy enthalten kann -> Beschreibung im IG

m-benamor commented 7 months ago

Alternative könnte man "Consent-Ressoucen", die auf dem gleichen Patient verweisen und gleichen Policies haben, als Duplikate betrachtet. Für eine saubere Datenintegrität würden Clients an diese Stelle Update (noch besser Conditional-Update ) verwenden, um neue Consent hinzuzufügen. Älteren Versionen werden ja versioniert und können abgefragt werden.

oeme-github commented 1 month ago

Die beste Analogie ist hier, meine ich, der Dokumentenstapel. Alle Dokument werden in zeitlicher Reihenfolge ihrer Entstehung übereinandergelegt und dann durchleuchtet. Ergebnis sind Policies, die den Einwilligungszustand beschreiben. Verschiedenartige Policies liegen nebeneinander und gleiche übereinander oder hintereinander (mit uns ohne Lücken). Diese "Summe" von Policies sollte sich als Consent-Ressource abbilden lassen, ist dann halt etwas komplexer. Geht die Frage in diese Richtung?

m-benamor commented 1 month ago

Die beste Analogie ist hier, meine ich, der Dokumentenstapel. Alle Dokument werden in zeitlicher Reihenfolge ihrer Entstehung übereinandergelegt und dann durchleuchtet. Ergebnis sind Policies, die den Einwilligungszustand beschreiben. Verschiedenartige Policies liegen nebeneinander und gleiche übereinander oder hintereinander (mit uns ohne Lücken). Diese "Summe" von Policies sollte sich als Consent-Ressource abbilden lassen, ist dann halt etwas komplexer. Geht die Frage in diese Richtung?

Coolen Beispiel ! Nach meinem Verständnis ist aber würde zB. ein Widerruf oder ein Teilwiderruf alle vorherige Einwilligungserklärungen vom gleichen Typ (Template) überschreiben. Selbst wenn nur ein Policy in der Consent-Ressource abgebildet wird, kann das Status von alle andere Policies aus dem Opt-In oder Opt-Out abgeleitet werden.

oeme-github commented 2 weeks ago

Haben wir es da tatsächlich mit einnem Updte zu tun? Es sind ja eigenständige Dokumente, die ja ein Erstellungsdatum haben und so weiter. Ich würde dem zustimmen, wenn wir den resultierenden Gesamtstatus betrachten, aber bei den einzelnen Consent-Ressouren sehe ich das eher nicht so. Konsequenz wäre ja, dass dan an einer Consent-Ressource mehrere Verewiese auf reale Dokumente vorhanden sind. Das kann ja dann schon ganz schön komplex werden, oder?

m-benamor commented 1 week ago

Haben wir es da tatsächlich mit einem Update zu tun? Es sind ja eigenständige Dokumente, die ja ein Erstellungsdatum haben und so weiter. Ich würde dem zustimmen, wenn wir den resultierenden Gesamtstatus betrachten, aber bei den einzelnen Consent-Ressouren sehe ich das eher nicht so.

Ja gut es hängt davon ab, wie man das ganze betrachten möchte. Jedes Dokument exakt auf eine Consent-Ressource abzubilden, würde die Nutzung von eine API möglicherweise komplizierter machen. Die Clients müssten dann mehrere Ressourcen abfragen und komplexen Aggregation durchführen, um am ende ein gesamten Status abbilden zu können.

Konsequenz wäre ja, dass dann an einer Consent-Ressource mehrere Verewiese auf reale Dokumente vorhanden sind. Das kann ja dann schon ganz schön komplex werden, oder?

Man könnte zb. auf eine konkrete Version einer Resource verweisen und Provenance ist ja dafür vorgesehen den realen Erstellungsdatum abzubilden.

Anmerkung: unter "Dokument" verstehe ich eine Einwilligungserklärung, Ein Widerruf oder Teilwiderruf