Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Löschfristen und Definition, was wann gelöscht werden soll #159

Open
mb010865 opened this issue Feb 8, 2023 · 5 comments
Open

Löschfristen und Definition, was wann gelöscht werden soll #159

mb010865 opened this issue Feb 8, 2023 · 5 comments

Comments

@mb010865
Copy link

mb010865 commented Feb 8, 2023

An dieser Stelle möchte ich die Diskussion über Löschfristen und der Ausprägung von zu löschenden Inhalten starten. In der letzten TIM Sprechstunde beschlossen, hier eine Diskussion zu beginnen, die Diskussion an dieser Stelle zu beginnen und zu klaren Vorgaben für die Umsetzung zu kommen, die auch für den Fall der Föderation keine Probleme darstellt.
Das Matrix-Protokoll macht hier keine Vorgaben.
Konkret betrifft es die automatische Löschung von Events, Räumen und Media. Andere Inhalte sind meiner Meinung nach nicht von Fristen betroffen.
Events: Zeit x nach dem Sicherstellen, dass alle Teilnehmer eines Raums die Nachricht erhalten haben. Wie würde jedoch der Timeout definiert, wenn die Nachricht von einem Teilnehmer nie abgeholt wird.
Räume: Werden Räume automatisch gelöscht, wenn keine Teilnehmer mehr im Raum sind? Wenn ja, zu welchem Zeitpunkt?
Wenn für Federation keine einheitlichen Vorgaben erstellt werden, ergeben sich Inkonsistenzen. Aus meiner Sicht sollte der Server nicht als Speicher von eigenen Sichten auf einen Raum herhalten.
Bei allen "grossen" Messenger-Produkten ist dies Sache des Clients mit entsprechenden Backup Mechanismen.
Media: Sollten analog der entsprechenden Events behandelt werden. Die Regeln haben hier nur noch mehr Auswirkungen auf die Ausgestaltung der Skalierbarkeit der Matrix-Server.

Die Diskussion ist eröffnet.

@benkuly
Copy link

benkuly commented Feb 8, 2023

Gemäß Fachdienst-spec A_22811 - Löschfristen für Matrix-Homeserver sollen Räume nach einer Inaktivität von 6 Monaten gelöscht werden. Dies ist konfigurierbar durch den Org-Admin. Mit Beachtung der Föderation lässt sich das umsetzen, indem der Nutzer der jeweiligen Organisation automatisch aus dem Raum entfernt wird. Wenn der homeserver nicht mehr Teilnehmer dieses Raumes ist, kann er diesen dann auch bedenkenlos automatisch löschen. Dieser Punkt ist aus meiner Sicht eindeutig.

Zusätzlich existiert für den Client A_22797 - Automatische Löschfunktion, welcher eine Client-seitige Löschung vorsieht und nicht die auf dem Server gespeicherten Daten betrifft. Das heißt, scrollt der Nutzer nach oben erhält er wieder die Daten vom Server (welche dann nach kurzer Zeit wieder auf dem Client gelöscht werden würden).

Komplexer sollte meiner Meinung nach aus Nutzersicht der Löschprozess nicht gestaltet werden. Im Gegenteil würde ich dafür plädieren von einer MUSS Löschung abzusehen. Es handelt sich hier um Ende-zu-Ende verschlüsselte Daten. Eine stetige Client-seitige Löschung ist aus meiner Sicht daher gar nicht notwendig und erhöht nur unnötig den Entwicklungsaufwand sowie Akku-Verbrauch (nicht unerheblich!). Die Server-seitige Löschung dagegen mag aus Ressourcen-Gründen sinnvoll sein. Aber da würde dann ein KANN ausreichen.

@mlangguth
Copy link

Auch diesen Punkt müssen (sollten) wir uns noch einmal genauer anschauen. Für mich sind hier noch Fragen ob der zu erreichenden Ziele und unnötiger Aufwände offen:

  • Warum Nachrichten lokal vom Device löschen, wenn ich sie mir durch Scrollen doch wieder direkt holen kann? Die Daten im lokalen Device müssen ohnehin geschützt sein. Die Menge der Daten sollte dann eine Nutzerentscheidung sein.
  • Wir sprechen doch von föderalen Strukturen, d.h. "ein" Raum liegt auf allen Homeservern alle beteiligten Mitglieder. Serverübergreifendes Purging ist (hoffentlich!) nicht angedacht. Was für einen Sinn macht es dann, wenn ein Gruppenchat von 4 Teilnehmern auf einem Homeserver gelöscht werden muss - und auf drei weiteren weiterhin vorliegt - und damit später über Föderation und Beitritt auch wieder eingesehen werden kann?

Ich glaube wir brauchen

  1. Ein konkrete Beschreibung der zwingend zu erreichenden Sicherheitsziele (mit einer Abwägung der damit verbundenen Nutzen-Nachteile und Betriebsaufwände)
  2. Eine Diskussion um Lösungsoptionen diese Ziele - so sie dann bestätigt sind - umgesetzt werden können.

@nikzen
Copy link

nikzen commented Apr 14, 2023

Aus unserer Perspektive und der DSGVO Perspektive heißt "Löschen" auch "Löschen". Das bedeutet es muss eine Anforderung geben, dass die Nachrichten nach max. 6 Monaten "serverseitig" gelöscht werden. Die clientseitige Anforderung kann aus unserer Sicht verschwinden, da es sich hier um keine "Löschung" im eigentlichen SInne handelt.

Leistungserbringer reichen die 6 Monate übrigens nicht und fordern bspw. 90 Tage. Das heißt es muss auch möglich sein die Daten früher zu löschen.

@mlangguth
Copy link

Ich schlage vor einen Blick auf die fachlichen Bedarfe und Möglichkeiten von TIM zu legen und davon ausgehend die nächsten Schritte zu gehen. Meine Sicht dazu:

  • Wir schaffen ein Werkzeug zum professionellen Austausch, explizit mit Fallbezug
  • Wir regulieren nicht, in welchem konkreten medizinischen Kontext und Setting das Werkzeug eingesetzt werden soll
  • TIM ist damit ein sehr flexibles Fall-Kommunikationstool
  • Für mich bin ich da gedanklich schnell bei einer niederschwelligen Fallakte. Nicht für onkologische Fälle mit hunderten Dokumenten, aber für weniger komplexe aber dennoch einrichtungsübergreifende Fälle sehr wohl. (Reminder: Ein aktuelles Ziel im Gesundheitswesen ist es, die patientenzentrierte, einrichtungsübergreifende (!!) Versorgung zu fördern).
  • Ein Beispiele für einen solchen "einfachen" Fall ist eine (Risiko)Schwangerschaft. Hier sind Hausarzt, Gynäkologe, Hebamme, Klinikarzt und potentiell Kardiologe etc. beteiligt. Der Austausch zwischen Gyn und Hebamme in diesem Patienten-Raum wird in jedem Fall aber mehr als 6 Monate betragen. Schwangerschaft und Nachsorge zusammen eher 9-24 Monate, bei schwierigen Fällen auch länger.
  • Bei patientenzentrierter, einrichtungsübergreifender Behandlung gibt es nicht "den Owner" des Falls, lediglich einen Initiator (und vielleicht einen primär Behandelnden). Dadurch, dass mehrere Einrichtungen den gleichen Patienten behandeln und darüber in Rooms kommunizieren, haben alle Einrichtungen die gleichen Rechte am Raum (bzw. ihren Räumen in ihren Accounts) und den darin enthaltenen Nachrichten (& Dokumenten)
  • Es gilt: Datenhaltung ist dem Arzt für die Dauer der Behandlung gestattet (unabhängig davon wie lange diese dauert - auch Jahre!) plus zusätzlich 10 Jahre Vorhaltezeit
  • Es gilt ferner: Es gibt keine Vorgaben, in welchen Tools der Arzt diese Dokumentation halten muss. Selbstverständlich ist das PVS als führendes System naheliegend - es ist aber eben nicht verboten für Ärzte & Praxen auch andere Systeme parallel zu nutzen. Der Einsatz von TIM zu Dokumentationszwecken ist weder durch DSGVO noch durch Berufsordnung verboten! Ob eine Einrichtung TIM dafür nutzen will - bzw. für wie lange sie TIM dafür nutzen will, bevor sie Räume in die Archivierung überführt - muss der Einrichtung überlassen sein. Nur sie kennt das für sie perfekte Prozesssetup.

Für mich heißt das:

  • Wir entwickeln ein sehr flexibel nutzbares Werkzeug zur einrichtungsübergreifenden Versorgung
  • Es gibt keine gesetzlichen Pflichten die uns dazu zwingen, das Tool künstlich in der Nutzung zu beschränken
  • Es wird Einrichtungen geben (und vielleicht sogar viele), die die Verweildauer von Nachrichten in Räumen zeitlich begrenzen wollen. Für diese Einrichtungen müssen wir ein technisches Angebot zum zeitlich gesteuerten Löschen machen.
  • Es wird Einrichtungen geben, die für sich und ihre Versorgungsprozesse die Vorteile von TIM für länger- und langfristige Fallbearbeiten nutzen wollen (Gynäkologen, Hebammen, Diabetologen, Pflege etc.).

Da es keine gesetzlichen Vorgaben gibt, den zweiten Einrichtungen Knüppel zwischen die Beine werfen zu müssen, sollten wird es auch nicht tun!
Wir beschneiden ansonsten TIM in völlig unnötiger Weise.
Dies wird um so deutlicher, wenn wir an Nutzungsszenarien ab TIM 2.0 denken, wenn die patientenbeteiligte Kommunikation dazu kommt und für den Patienten TIM-Chat dann potentiell lebenslang gehalten werden müssen (z.B. für seine Diabetes). Weil er das will und weil es für ihn die einzige praktikable Option ist (bitte keine Diskussion über "nach ePA archivieren" starten, damit lässt sich als Patienten nicht arbeiten!).

Daher ist meine Sicht klar:

  • Löschoptionen anbieten, auch zeitgesteuerte
  • Löschverpflichtung: Keine!

Oder ist meine Argumentation fehlerhaft? Übersehe ich etwas?
Freue mich auf den weiteren Diskurs.🙃

@benkuly
Copy link

benkuly commented Apr 14, 2023

Ich kann hier @mlangguth nur 100% zustimmen. Wir vertreten zwar schon lange diese Meinung, der Beitrag fasst es aber nochmal wunderbar zusammen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants