Arbeitsentwurf · Version 0.1 · Stand: 10. Mai 2026

Datenschutz-Folgenabschätzung

Oase — Patienten-Co-Creation-Werkzeug für eine Suchtreha-Klinik

Strukturiert nach Art. 35 DSGVO, WP248 (Art-29-Gruppe), DSK Muss-Liste v1.1 (17.10.2018), und gesundheitsdatenschutz.org- Praxishilfe Gesundheitswesen.

Hinweis: Dieses Dokument ist ein interner Arbeitsentwurf des Solo-Verantwortlichen. Vor Produktivnahme muss eine externe Datenschutzbeauftragte (DSB) den Inhalt prüfen, mit der zuständigen Aufsichtsbehörde (Hessischer Landesdatenschutzbeauftragter) abgestimmt werden, und Stellungnahmen von Patient:innen und Klinikleitung müssen eingeholt werden.

§ 0Metadaten der DSFA

Name der Verarbeitung	Oase — Selbsthilfe-Werkzeug für Patient:innen einer Suchtreha-Klinik
Verantwortlicher (Art. 4 Nr. 7)	Gero Strauß (solo, natürliche Person, kein Beschäftigter)
Datenschutzbeauftragter	extern, noch zu beauftragen — TODO
Aufsichtsbehörde	Hessischer Landesdatenschutzbeauftragter (HLfD) — Prozio-Mitnutzung Brandenburg-LfDA möglich
Standort der Verarbeitung	EU (Frankfurt eu-central-1, EU-Cross-Region für KI)
Datum der Erstfassung	10.05.2026
Version	0.1 (Arbeitsentwurf)
Geplante Reviews	Vor Produktivnahme, nach Pilot-Phase 60 Patient:innen, danach jährlich + bei wesentlichen Änderungen

§ 1Systematische Beschreibung der Verarbeitungsvorgänge

1.1 Zweck der Verarbeitung

Oase ist ein freiwilliges Selbsthilfe-Werkzeug für Patient:innen einer Suchtreha-Klinik. Es ermöglicht:

Pseudonyme Reflexion (Spiegel-Modus, KI-gestützt)
Übersetzung in Leichte Sprache (KI-gestützt, für Klinik-Dokumente)
Triage-Hinweise (Smart-Triage, KI-gestützt)
1:1- und Gruppen-Chat (Ende-zu-Ende-verschlüsselt)
Voice-Notes (Ende-zu-Ende-verschlüsselt)
Geteiltes Skyline-Spiel (kollaborativ, ohne Punktsystem)
Lern-Anker (Curriculum + externe Verweise)
Körper-Erneuerungszyklen-Visualisierung
Lebenszeit-Visualisierung (opt-in)
Tagesimpuls-Wegweiser
Schreibkompass (eigenständiges Tool, lokal im Browser)

Oase ist kein medizinisches Werkzeug, keine Diagnose-Plattform, keine zertifizierte digitale Gesundheitsanwendung (DiGA) nach § 139e SGB V. Die Nutzung ist freiwillig, ergänzt klinische Behandlung, ersetzt sie nicht.

1.2 Betroffene Personen

Patient:innen einer Suchtreha-Klinik in Hessen (Hauptzielgruppe: ca. 60 Personen im Pilot, Erweiterung möglich). Die Zielgruppe ist als besonders schutzbedürftig im Sinne von Art. 9 DSGVO + WP248 einzustufen aufgrund:

Verarbeitung von Gesundheitsdaten (Suchtdiagnose impliziert)
Akute oder erst kürzlich überstandene Suchterkrankung
Mögliche akute psychische Krisen, Komorbiditäten
Häufig: kognitive Erholungsphase mit reduzierter Konzentration / Arbeitsgedächtnis (PLOS ONE 2024)
Häufig: prekäre Lebenslage (Bürgergeld, Schulden, Wohnsituation)

1.3 Verarbeitete Datenkategorien

Bewusst minimierte Datenerhebung, am unteren Ende des für die Funktion notwendigen Spektrums.

Pseudonym	Patient-gewählt, 2–32 Zeichen, alphanumerisch
Auth-Email (synthetisch)	Pseudonym@patients.oase.local — kein realer Mailversand möglich
Passwort-Hash	Supabase-Standard (bcrypt-Variante)
Recovery-Email-Hash	SHA-256(email + salt), optional, Klartext nie gespeichert
Public Key	X25519 (libsodium crypto_box) für E2EE
Skyline-Block-Positionen	Patient legt Blöcke ab — pseudonyme Owner-ID + Pseudonym
Chat-Nachrichten (Text, Voice)	Ausschließlich verschlüsselt (libsodium crypto_box / crypto_secretbox), Klartext nie auf Server
Audit-Log-Einträge	Konto-Anlagen + Löschungen, ohne Inhaltsdaten

Nicht erhoben: Klarnamen, Geburtsdatum, Adressen, Diagnose-Codes (ICD-10), Versichertennummern, IP-Adressen (außer flüchtig in Server-Logs für Sicherheits- Zwecke, max. 7 Tage).

Lokal auf dem Gerät: Privatschlüssel (libsodium), Lebenszeit-Modul-Daten (falls aktiviert) — diese verlassen das Gerät nicht.

1.4 Verarbeitungsvorgänge im Detail

Folgende Verarbeitungsschritte finden serverseitig statt:

Anlegen Konto (Pseudonym + Passwort + optional Recovery-Email-Hash) bei Onboarding
Authentifizierung bei Login (Supabase Auth)
Speichern öffentlicher E2EE-Schlüssel im Profil
Speichern verschlüsselter Chat-Nachrichten (Server kennt nur ciphertext)
Speichern verschlüsselter Voice-Notes als Storage-Blobs
Skyline-Block-Persistierung mit Realtime-Broadcast
API-Aufruf an AWS Bedrock EU für Reflection / Leichte Sprache / Smart-Triage (Klartext-Eingabe wird übertragen, nicht persistiert serverseitig in Oase)
Audit-Log-Einträge bei Konto-Aktionen
Datenexport bei Anfrage nach Art. 15 / 20
Konto-Löschung bei Anfrage nach Art. 17 (Cascade Delete + 30-Tage-Backup-Vorhaltefrist)

§ 2Berechtigte Interessen + Rechtsgrundlage

Verarbeitung von Art-9-Daten (besondere Kategorien) erfolgt ausschließlich auf Grundlage einer ausdrücklichen Einwilligung nach Art. 9 Abs. 2 lit. a DSGVO.

Die Einwilligung wird beim Onboarding eingeholt, ist modulgranular (Patient kann z. B. Reflection nutzen, Chat aber nicht), und jederzeit widerrufbar (Art. 7 Abs. 3 DSGVO).

Berechtigtes Interesse (Art. 6 Abs. 1 lit. f) wird nicht als Rechtsgrundlage herangezogen — bei Art-9-Daten inakzeptabel.

Vertrag (Art. 6 Abs. 1 lit. b) wird ebenfalls nicht herangezogen — die App ist freiwillig, kein Pflichtbestandteil des Behandlungsvertrags.

§ 3Bewertung der Notwendigkeit und Verhältnismäßigkeit

3.1 Notwendigkeit der Datenverarbeitung

Jede Datenverarbeitung wurde auf das Minimum reduziert, das für die jeweilige Funktion erforderlich ist:

Pseudonym statt Klarname: Identifikation über Pseudonym reicht für Multi-User-Funktion. Klarname wäre identifizierender und damit risikoreicher.
E2EE statt Server-Klartext: Chat-Inhalte bleiben verschlüsselt; Server kann sie nicht lesen, kann nicht weitergeben werden, sind im Datenexport für Patient:in ohnehin verschlüsselt sichtbar.
Keine Reflection-Persistierung: Der sensibelste Inhaltstyp — freie Reflexion über das eigene Innere — wird nicht serverseitig gespeichert. Nur an Bedrock geschickt, dann verworfen. Anthropic Bedrock retentet nicht für Training.
Lokale-Modelle-Modul (Lebenszeit):Geburtsdatum als hochsensibles Datum bleibt im LocalStorage.

3.2 Verhältnismäßigkeit

Vorteile für die Patient:innen:

Niedrigschwellige Reflexionsmöglichkeit ohne Gespräch-Investment
Sprachzugang zu Klinik-Dokumenten via Leichte-Sprache-Modul
Peer-Verbindung über E2EE-Chat ohne Smartphone-Daten-Risiko
Sinnstiftende Lern-Anker (Asset-Aufbau für nach Reha)
Zellbiologisches Selbstverständnis (Körper-Modul)

Risiken (siehe Abschnitt 4 detaillierter):

Datenleck bei Server-Kompromittierung (gemildert durch E2EE)
Re-Identifikation aus Pseudonymen + Verhalten
Bildschirm-Abhängigkeit / KI-Parasozialität
Trigger-Risiko durch sichtbare Mortalitätsthematik (gemildert durch Lebenszeit-Opt-in)

Bewertung: Vorteile überwiegen, sofern die technischen und organisatorischen Maßnahmen aus Abschnitt 5 umgesetzt sind.

§ 4Risiken für Rechte und Freiheiten der Betroffenen

Risiko-Bewertung nach Eintrittswahrscheinlichkeit (gering / mittel / hoch) und Schadensschwere (gering / mittel / hoch / kritisch).

R1Datenleck durch Server-Kompromittierung

Wkt. gering · Schwere kritisch

Angreifer übernimmt Supabase-Backend oder AWS-Account und greift Daten ab.

MaßnahmeE2EE-Inhalte bleiben verschlüsselt. Pseudonyme + Pubkeys + Metadaten leaken. Service-Role-Schlüssel nur server-side. 2FA für Admin-Account. Audit-Logs.

R2Re-Identifikation aus Pseudonym + Verhalten

Wkt. mittel · Schwere hoch

Person aus Klinik-Kontext kennt Pseudonym oder kann es aus Verhalten/Schreibstil rekonstruieren.

MaßnahmePatient-Schulung beim Onboarding zu Pseudonym-Wahl (kein Klarname-Hinweis). Klare Kommunikation: keine sensiblen Identifikatoren in Pseudonym oder Skyline-Blöcken.

R3Schlüsselverlust bei Geräte-Wechsel

Wkt. hoch · Schwere mittel

Bei Geräte-Wechsel oder LocalStorage-Löschung verliert Patient:in Zugriff auf alte Chat-Nachrichten.

MaßnahmeKlare Kommunikation in der UI (Stufe-0-Hinweis). Migration auf Matrix/Megolm in Pass 9 geplant.

R4KI-Halluzination führt zu Fehlhandlung

Wkt. mittel · Schwere mittel

Patient verlässt sich auf Leichte-Sprache-Übersetzung oder Smart-Triage mit halluzinierten Inhalten.

MaßnahmeModul 3 KI-Führerschein (Halluzinationen erkennen) als Pflicht-Hinweis. Triage führt zu Module-Switch, nicht zu Diagnose. Leichte-Sprache-Disclaimer.

R5Parasoziale Bindung an KI

Wkt. mittel · Schwere hoch

Patient nutzt KI als Beziehungsersatz — Sucht-Pattern verlagert sich.

MaßnahmeModul 6 KI-Führerschein als Pflichtteil. Smart-Triage erkennt Krise und verweist auf Mensch (Klinik / Telefonseelsorge).

R6Trigger durch Mortalitäts-Visualisierung

Wkt. mittel · Schwere mittel

Lebenszeit-Modul löst depressive oder suizidale Gedanken aus.

MaßnahmeLebenszeit-Modul ist opt-in mit klarem Vor-Hinweis. Daten lokal (kein Server-Persist). Modul jederzeit ausschaltbar mit Daten-Löschung.

R7Drittlandtransfer durch AWS / Push-Provider

Wkt. gering · Schwere mittel

Daten gehen aus EU heraus durch FCM / APNs / oder verirrte AWS-Routings.

MaßnahmeBedrock ausschließlich über EU-Inference-Profile (eu.anthropic.*). Push aktuell nicht implementiert. Bei Implementierung: nur Trigger ohne Klartext.

R8Geräte-Diebstahl

Wkt. mittel · Schwere hoch

Smartphone/Laptop wird gestohlen, Privatschlüssel im LocalStorage zugänglich.

MaßnahmeStufe-0-Hinweis in UI. Nutzer:innen-Schulung: Geräte-Lock (PIN/FaceID) + selbständiges Logout vor Gerätewechsel. Pass-9-Migration auf passphrase-derived Keys.

R9Unbeabsichtigte Inhalts-Indizes (Sycophancy)

Wkt. mittel · Schwere mittel

Patient bittet KI um Bestätigung einer riskanten Entscheidung, KI bestätigt unkritisch.

MaßnahmeSonnet 4.5+ messbar bessere Sycophancy-Werte (Petri-Bench). System-Prompts erzwingen Crisis-Hinweise. Modul 6 erklärt Sycophancy.

R10Solo-Builder-Ausfall

Wkt. mittel · Schwere mittel

Verantwortlicher fällt durch Krankheit / Rückfall aus, App ohne Wartung.

MaßnahmeBus-Faktor-Plan in Vorbereitung: 2 Co-Maintainer-Patient:innen mit Repo-Read. Automatische Backups. Notabschaltprozedur dokumentiert. App ist explizit als jederzeit-abschaltbares Werkzeug positioniert, nicht als Dauerinfrastruktur.

§ 5Geplante Abhilfemaßnahmen (TOMs nach Art. 32)

5.1 Technische Maßnahmen

End-to-End-Verschlüsselung für Chat (libsodium crypto_box, X25519+XSalsa20-Poly1305)
Audio-Voice-Notes symmetrisch verschlüsselt (crypto_secretbox), Schlüssel per Empfänger asymmetrisch gewrappt
TLS 1.3 in transit (Vercel / Supabase / AWS Default)
Row-Level Security auf allen Patiententabellen (Supabase RLS)
Storage RLS für Voice-Note-Blobs (path-based, room-membership-bound)
Pseudonyme statt Klarnamen, salt-basiertes Email-Hashing
Bedrock nur über EU-Inference-Profile
Service-Role-Key nur server-side, niemals im Browser-Bundle
Audit-Log für Konto-Aktionen (ohne Inhalte)
Backups verschlüsselt at rest (Supabase Default + AWS S3 SSE)

5.2 Organisatorische Maßnahmen

2-Faktor-Authentifizierung für Verantwortlichen-Account (Supabase + AWS-IAM)
Verzeichnis von Verarbeitungstätigkeiten (ROPA, separat)
AVV mit allen Auftragsverarbeitern (Supabase Standard-DPA, AWS-DPA + EU-SCCs, Vercel-DPA)
Externe DSB-Beauftragung geplant (TODO vor Produktivnahme)
Datenschutz-Schulung für Klinikmitarbeiter, falls Joint-Controllership später aktiviert wird
Inzident-Response-Plan (TODO)
Bus-Faktor-Plan mit 2 Co-Maintainern
Patient-Onboarding mit Datenschutz-Erklärung in Leichter Sprache (Pass 9)

5.3 Patient-Rechte (Art. 13–22 Umsetzung)

Auskunft (Art. 15) + Datenübertragbarkeit (Art. 20): JSON-Export unter /einstellungen/export
Berichtigung (Art. 16): Pseudonym + Recovery-Email änderbar (Pass 9 — derzeit über Re-Onboarding)
Löschung (Art. 17): /einstellungen/loeschen mit Bestätigungsphrase + Cascade Delete
Einschränkung (Art. 18): über modulgranulare Einwilligungs-Toggles (Pass 9)
Widerspruch (Art. 21): durch Konto-Löschung umsetzbar; bei Art-9-Einwilligung Widerruf jederzeit
Beschwerderecht: Hessischer Landesdatenschutzbeauftragter (Adresse in Datenschutzerklärung)

§ 6Stellungnahme der/des Datenschutzbeauftragten

TODO: Externe DSB ist noch zu beauftragen (z. B. exkulpa, datenschutzexperte.de, datenschutz-kanzlei.info — Empfehlung ~30–80 EUR/Monat). Die DSB-Stellungnahme wird hier nach Beauftragung und Review eingefügt.

Aufsichtsbehörden-Vorab-Konsultation nach Art. 36 DSGVO ist NICHT geplant, weil das Restrisiko nach Maßnahmen aus Abschnitt 5 als „nicht hoch" eingeschätzt wird. Sollte die DSB zu einer anderen Bewertung kommen, ist Vorab-Konsultation Pflicht.

§ 7Stellungnahme der Betroffenen (Art. 35 Abs. 9)

TODO: Vor Produktivnahme werden Patient-Vertretungen (Patientenrat der Klinik bzw. Selbsthilfegruppen-Sprecher:innen) konsultiert. Die Stellungnahme wird hier dokumentiert.

Vorab-Mitwirkung bereits im Konzept: Verantwortlicher ist selbst Patient der adressierten Zielgruppe. Co-Creation-Prinzip ist architektonisch verankert. Dies ersetzt jedoch die formale Stellungnahme nicht.

§ 8Erklärung über die Eignung der Maßnahmen

Auf Basis der Risikoanalyse in Abschnitt 4 und der Maßnahmen in Abschnitt 5 wird das Restrisiko für die Rechte und Freiheiten der Betroffenen wie folgt bewertet:

R1, R7: gering — durch E2EE und EU-Inferenz weitgehend mitigiert
R2, R3, R4, R5, R8: mittel — gemildert durch UI-Hinweise, Schulung, Modul 6
R6, R9, R10: gering bis mittel — Opt-in / messbar verbesserte Modelle / Bus-Faktor-Plan

Restrisiko in Summe: nicht hoch im Sinne von Art. 35 Abs. 1 DSGVO. Eine Aufsichtsbehörden-Vorab-Konsultation nach Art. 36 wird nach derzeitigem Stand als nicht erforderlich eingeschätzt — vorbehaltlich abweichender DSB-Bewertung.

Die Verhältnismäßigkeit ist gegeben: Die Vorteile der App für die Zielgruppe (niedrigschwellige Reflexion, Peer-Verbindung, Asset-Aufbau, Selbstverständnis durch Körper-Modul) überwiegen gegenüber dem mit angemessenen Maßnahmen kontrollierten Risiko.

§ 9Anhänge

A.1 AVV-Liste (Auftragsverarbeiter)

Supabase	Datenbank, Auth, Storage. Standard-DPA + EU-SCCs. Konzernmutter US, EU-Region Frankfurt.
Amazon Web Services	Bedrock-EU für Claude-Inferenz. AWS-DPA + EU-SCCs. EU-Cross-Region (Frankfurt/Irland/Paris).
Vercel	Hosting der Web-App. Vercel-DPA + EU-SCCs. EU-Region wählbar.
GitHub (Microsoft)	Source-Code-Hosting. Bewertung: keine Patientendaten in Repo.
Anthropic	Modellbetrieb. Aufgabe primär an AWS gebunden, Anthropic-Privacy-Center sekundär. Keine Patient-Daten-Persistierung.
Wikipedia (Wikimedia Foundation)	Bilder-Lookup für Körper-Modul. Anonyme Anfragen, keine Patient-Identifizierung möglich.
Sketchfab (Epic Games)	3D-Anatomie-Embed. iframe-Lasten anonym.

A.2 ROPA-Auszug (Verzeichnis Verarbeitungstätigkeiten)

Vollständig in separater ROPA-Mappe (Format nach Art. 30 DSGVO).

Auszug:

Verantwortlicher: Gero Strauß, Anschrift im Impressum
DSB: extern (TODO)
Zwecke: siehe Abschnitt 1.1 dieser DSFA
Datenkategorien: siehe Abschnitt 1.3
Empfänger: AVV-Auftragsverarbeiter (siehe A.1) — keine Übermittlung an Dritte ohne Einwilligung
Drittlandtransfers: AWS-EU-Cross-Region (innerhalb EU-Geo); Anthropic-Provider durch AWS-DPA geregelt; keine direkten Transfers nach US oder Drittländern
Speicherdauer: Patientendaten bis Konto-Löschung; Audit-Logs max. 12 Monate; verschlüsselte Chat-Inhalte solange das Konto besteht
TOMs: siehe Abschnitt 5

A.3 Risikomatrix

Visuell in separater Datei (Heatmap Likelihood × Severity). Zusammenfassung der zehn Risiken siehe Abschnitt 4.

A.4 DSK-Muss-Liste-Mapping

DSK-Muss-Liste v1.1 (17.10.2018), relevante Punkte für Oase:

Punkt 1.1 (Telemedizin / digitale Gesundheitsanwendungen): erfüllt durch Reflection / Triage-Funktionen
Punkt 1.2 (besondere Kategorien personenbezogener Daten / Art-9-Daten): erfüllt durch Suchterkrankungs-Kontext
Punkt 1.6 (Verarbeitung mit neuen Technologien wie KI): erfüllt durch Bedrock-Claude-Integration
Punkt 1.10 (besonders schutzbedürftige Personen): erfüllt durch Suchtreha-Patient:innen-Status

≥2 Punkte erfüllt → DSFA-Pflicht nach DSK-Muss-Liste eindeutig. Damit auch nach WP248-Schwellwertanalyse erfüllt (sensible Daten + vulnerable Personen + neue Technologie).