Wie umgehen mit abgelaufener Zustimmung Broad-Consent?

[pcvolkmer]

Fraglich war, ob abgelaufene Consents/Zustimmungen (z.B. MDAT) dazu führen, das weiterhin von einer Consent-Permission ausgegangen wird (die eigentliche Problematik hinter #14).

Dazu wurde ein bestehender Test durch einen weiteren Test ergänzt, der jedoch von einer am 01.08.2024 erstellten FHIR-Consent-Ressource ausgeht, deren Gültigkeit sich in allen Fällen auf den 01.08.2025 beschränkt: pcvolkmer/service-base@fbd4685

Wie soll damit umgegangen werden:

• Die Consent-Informationen ggf veraltet sind, weil nicht neu bei Nutzung der ETL-Strecke erstellt, sondern z.B. einmalig in Onkostar abgelegt?
• Bereits bestehende Patienten-Daten basierend auf dieser (ggf. mittlerweile) veralteten Consent-Information im DNPM-DIP vorgehalten werden?
• Wie können/müssen oder sollen aktiv Patienteninformationen aus DNPM:DIP entfernt werden, wenn die Gültigkeit Consent-Zustimmung abgelaufen ist? Gibt es da ein regelmäßiges Cleanup?

[lucienclin]

Im Grunde könnte man zwar in die DIP-seitige Verarbeitung des research consent noch die Prüfung auf zeitliche Gültigkeit einbauen, aber eigentlich gebietet das Prinzip "Vertrauen ist gut, Kontrolle ist besser", diese Aspekte des Consent-Management beim Client, der einen Datensatz nach DIP exportiert, anzusiedeln:

Falls der research consent zum Export-Zeitpunkt schon abgelaufen ist, sollte er im Falle eines MVH-Datensatzes m.E. eben nicht mehr angehängt werden, damit der Datensatz gar nicht erst ins Query-Modul übernommen wird, und im Falle eines DNPM-only Daten-Export dürfte der Export ohne gültigen Consent eben gar nicht erst stattfinden.

Und bzgl Clean-up innerhalb DIP: natürlich wäre es möglich, noch eine periodische Prüfung mit ggf. Löschung der Datensätze nach Ablauf des Consents einzubauen, aber unabhängig davon, dass hierfür grundlegende Umänderungen nötig wären (weil bislang im QueryService nur die MDAT-Datensätze, ohne die Consent-Objekte, gespeichert werden), muss nach obigen Kontroll-Prinzip ein (ETL-)Client, der einen Datensatz nach DIP (oder wohin auch immer) exportiert, m.E. auch periodisch prüfen, ob die Consent-Grundlage immer noch besteht, und falls irgendwann nicht mehr, muss er auch in DIP aktiv die Löschung der Daten veranlassen, statt passiv darauf zu vertrauen, dass das in DIP schon korrekt gehandhabt wird.

Im Zweifel würde ich für diesen Punkt aber an die Projekt-Leitung verweisen, das kann ich als Entwickler nicht alleine entscheiden.

[pcvolkmer]

Im Grunde könnte man zwar in die DIP-seitige Verarbeitung des research consent noch die Prüfung auf zeitliche Gültigkeit einbauen, aber eigentlich gebietet das Prinzip "Vertrauen ist gut, Kontrolle ist besser", diese Aspekte des Consent-Management beim Client, der einen Datensatz nach DIP exportiert, anzusiedeln:
Falls der research consent zum Export-Zeitpunkt schon abgelaufen ist, sollte er im Falle eines MVH-Datensatzes m.E. eben nicht mehr angehängt werden, damit der Datensatz gar nicht erst ins Query-Modul übernommen wird, und im Falle eines DNPM-only Daten-Export dürfte der Export ohne gültigen Consent eben gar nicht erst stattfinden.

Das wird z.B. vom ETL-Prozessor auch so gemacht werden, wenn entsprechende Consent-Informationen aktuell von einer gICS-Installation abrufbar sind. Ansonsten müssen wir uns auf das verlassen, was im DNPM-Datensatz ahinterlegt ist.

Und bzgl Clean-up innerhalb DIP: natürlich wäre es möglich, noch eine periodische Prüfung mit ggf. Löschung der Datensätze nach Ablauf des Consents einzubauen, aber unabhängig davon, dass hierfür grundlegende Umänderungen nötig wären (weil bislang im QueryService nur die MDAT-Datensätze, ohne die Consent-Objekte, gespeichert werden), muss nach obigen Kontroll-Prinzip ein (ETL-)Client, der einen Datensatz nach DIP (oder wohin auch immer) exportiert, m.E. auch periodisch prüfen, ob die Consent-Grundlage immer noch besteht, und falls irgendwann nicht mehr, muss er auch in DIP aktiv die Löschung der Daten veranlassen, statt passiv darauf zu vertrauen, dass das in DIP schon korrekt gehandhabt wird.
Im Zweifel würde ich für diesen Punkt aber an die Projekt-Leitung verweisen, das kann ich als Entwickler nicht alleine entscheiden.

Das ist soweit richtig. Änderungen am Consent müssen an das DNPM:DIP weiter gereicht werden. Fraglich ist aber, ob dies regelmäßig von außen angestoßen werden kann und soll, um Patienteninformationen nach Ablauf der Consent-Zustimmung zu entfernen. Denkbar wäre hier ein Job, der alle Patienteninformationen trackt und von sich aus regelmäßig Informationen aus gICS (sofern verfügbar) abruft und den Broad-Consent aktualisiert und auch den bisher bekannten Ablauf der Zustimmung "im Auge" behält und bei Ablauf die Informationen aus DNPM:DIP entfernt, sofern nicht automatisch neuere Informationen mit Zustimmung abgerufen werden können.