# VulneraDoc – Datenschutz- und Datensicherheits-Dokumentation Stand: Datenschutz-Review QA-006 (Projektstand `dev-QA004` + Maßnahmen aus diesem Review) > **Hinweis:** Dieses Dokument beschreibt die *technische* Umsetzung des Datenschutzes in der App > (Datenflüsse, Speicherorte, Schutzmaßnahmen). Es ist keine Rechtsberatung. Die rechtliche > Bewertung (Rechtsgrundlage, Verzeichnis der Verarbeitungstätigkeiten, ggf. Datenschutz- > Folgenabschätzung, Auftragsverarbeitung, Einwilligungen) muss durch die verantwortliche Stelle > bzw. deren Datenschutzbeauftragte erfolgen. Die Abschnitte 9 und 10 liefern dafür die > technischen Eingangsdaten. --- ## 1. Zweck und Einordnung VulneraDoc ist eine **Offline-Android-App zur Wunddokumentation**. Pflegekräfte erfassen Patienten, dokumentieren Wunden (Checklisten, Freitext, Fotos, Unterschriften) und erzeugen daraus ein PDF, das sie öffnen oder teilen können. Verarbeitet werden **Gesundheitsdaten** (Wundbefunde, Wundfotos) und weitere personenbezogene Daten. Gesundheitsdaten zählen nach Art. 9 DSGVO zu den besonderen Kategorien personenbezogener Daten und verlangen ein erhöhtes Schutzniveau. **Grundprinzip der App:** Die Daten verlassen das Gerät **ausschließlich auf ausdrückliche Handlung des Nutzers** (PDF/Bilder öffnen oder teilen). Es gibt keinen Server, keine Cloud, kein Konto, keine Analyse- oder Absturzberichts-Dienste. --- ## 2. Verarbeitete Daten | Datenart | Felder / Inhalt | Speicherort (App-intern) | |---|---|---| | Patientenstammdaten | Vorname, Nachname, Geburtsdatum, Straße, PLZ, Ort, bis zu 3 Telefonnummern | Datenbank `wunddoku.db` | | Dokumentation | Erstelldatum, Checklisten-Zustände, Freitexte (Wundbefund, Maßnahmen) | Datenbank | | Wundfotos | Fotos aus Kamera bzw. Photo Picker | `files/photos//` | | Unterschriften | Name des Unterzeichners, Unterschrift als PNG | Datenbank + `files/signatures//` | | Wundversorger-Register | Name und Unterschrift der Pflegekraft (für Wiederverwendung) | Datenbank + `files/wound_carer_signatures/` | | PDF-Export | Vollständiger Bericht inkl. Stammdaten, Befund, Fotos, Unterschriften | `files/pdf//` | | Bildexport | Seiten des PDFs als JPEG (zum Teilen als Bilder) | `files/pdf_images//` | | Kameraaufnahme (temporär) | Foto bis zum Import in die Dokumentation | `cache/camera/` | Alle Speicherorte liegen im **privaten internen App-Speicher**. Es wird kein öffentlicher Speicher (Galerie, Downloads, SD-Karte) beschrieben. **Hinweis Dateiname:** Das PDF heißt `Erstelldatum_Vorname_Nachname_Geburtsdatum.pdf` und enthält damit personenbezogene Daten. Der Name wird beim Teilen/Öffnen an die gewählte Ziel-App übergeben (siehe Abschnitt 6, Restrisiko R4). --- ## 3. Berechtigungen Die App fordert **keine einzige Berechtigung** an. | Funktion | Technik | Berechtigung nötig? | |---|---|---| | Fotos auswählen | System-Photo-Picker | Nein | | Foto aufnehmen | System-Kamera-App über `ACTION_IMAGE_CAPTURE` (die App greift nicht selbst auf die Kamera zu) | Nein (`CAMERA` nicht deklariert) | | PDF speichern | Privater App-Speicher | Nein | | PDF öffnen/teilen | `FileProvider` + Android-Sharesheet | Nein | | Netzwerk | nicht vorhanden | `INTERNET` ist im Manifest **ausdrücklich entfernt** (`tools:node="remove"`) | Durchsetzung: Das Manifest entfernt `INTERNET` und `ACCESS_NETWORK_STATE` beim Zusammenführen mit Bibliotheks-Manifesten. Der Test `PrivacyConfigurationTest` prüft das fertig zusammengeführte Manifest auf dem Gerät. --- ## 4. Datenflüsse nach außen Daten verlassen das Gerät nur in diesen Fällen – jeweils durch eine bewusste Aktion des Nutzers: 1. **PDF öffnen** – Übergabe der PDF per `content://`-URI mit *Lese*recht an die gewählte PDF-App. 2. **PDF teilen / Bilder teilen** – Übergabe per Android-Sharesheet mit *Lese*recht, nur `EXTRA_STREAM` (die Datei). Es wird **kein** Text, Betreff oder Empfänger mit Patientendaten vorbelegt. 3. **Fotoimport** – Fotos werden *in* die App kopiert (Photo Picker / Kamera); die Originale verbleiben dort, wo sie der Nutzer gespeichert hat. Beim Import wird das Foto neu als JPEG kodiert; Metadaten des Originals (z. B. GPS-Position) werden dadurch **nicht** übernommen. Nicht vorhanden: Netzwerkzugriff, Cloud-Backup, Geräte-zu-Geräte-Transfer, Analyse/Tracking, Absturzberichte, Werbung, Zwischenablage, Weitergabe an Dritte durch die App selbst. **Verantwortung nach dem Teilen:** Sobald eine PDF an eine andere App übergeben wurde, liegt der weitere Umgang außerhalb der Kontrolle von VulneraDoc (z. B. E-Mail-Programm, Messenger, Cloud-Speicher). Das ist organisatorisch zu regeln (Abschnitt 9). --- ## 5. Technische und organisatorische Schutzmaßnahmen in der App ### 5.1 Speicherung - Ausschließlich privater interner Speicher (`filesDir`, `cacheDir`); kein `getExternalFilesDir`, keine `MediaStore`-Nutzung, keine `MODE_WORLD_*`-Dateien. - Dateien sind für andere Apps nicht lesbar (Android-App-Sandbox, Dateirechte). - **Pfadsicherheit:** Datei-/Ordnernamen werden über `SafePaths` aufgelöst (kein `../`, keine Pfadtrenner, keine Symlink-Ausbrüche). - **Atomares Schreiben der PDF:** Erst temporäre Datei, dann Umbenennen – kein halbfertiges PDF, eine vorhandene PDF geht bei einem Fehler nicht verloren. ### 5.2 Freigabe über FileProvider (Prinzip der minimalen Freigabe) Nur diese Ordner können nach außen gegeben werden: `files/pdf/`, `files/pdf_images/` (Exporte) und `cache/camera/` (Kameraaufnahme). **Nicht** freigegeben: Originalfotos (`photos/`), Unterschriften (`signatures/`), Datenbank, Wundversorger-Register. Der `FileProvider` ist nicht exportiert (`exported="false"`), Rechte werden nur pro Vorgang als Leserecht vergeben. ### 5.3 Backup - `android:allowBackup="false"` – kein Cloud-/Auto-Backup. - `data_extraction_rules.xml` schließt für `cloud-backup` **und** `device-transfer` die Bereiche `database`, `file` und `sharedpref` aus; es gibt kein ``. - Folge: Beim Gerätewechsel oder nach Deinstallation sind die Daten **nicht** automatisch wiederherstellbar. Das ist gewollt (Datenschutz), muss aber organisatorisch bekannt sein (z. B. PDFs als Archiv in der Einrichtungsdokumentation ablegen). ### 5.4 Oberfläche - `FLAG_SECURE` im Hauptfenster: keine Screenshots, keine Bildschirmaufnahme, keine Vorschau im App-Wechsler. ### 5.5 Protokollierung (Logs) - Es gibt keine Konsolenausgaben und keinen `printStackTrace`-Aufruf. - Es existiert genau ein Log-Aufruf (Fehler beim Fotoimport). Er schreibt **nur den Typ** der Exception, nie die Fehlermeldung (diese kann Dateipfade oder URIs enthalten), nie Namen oder Patientendaten. - Fehlermeldungen in der Oberfläche sind allgemein formuliert und enthalten keine Pfade oder Exception-Texte. ### 5.6 Löschkonzept | Auslöser | Was wird gelöscht | |---|---| | Dokumentation löschen | Datenbankzeilen (inkl. Checklisten, Foto- und Signatur-Einträge), Fotos, Signaturen **und** zugehörige PDF- und Bildexporte | | Einzelnes Foto / einzelne Signatur löschen | Datenbankzeile und Datei | | Patient löschen | Nur möglich, wenn keine Dokumentation mehr existiert | | Automatisch beim App-Start | PDF-/Bildexporte älter als **7 Tage**; liegengebliebene Kameraaufnahmen älter als **24 Stunden** | | Deinstallation der App | Alle App-Daten (Android entfernt den privaten Speicher) | Die automatisch gelöschten Exporte lassen sich jederzeit aus der Dokumentation neu erzeugen. Die Fristen stehen als Konstanten in `InternalExportedFilesCleaner` und können angepasst werden. ### 5.7 Fehlerbehandlung als Datenschutz-/Integritätsmaßnahme Fehlerfälle (Speicher voll, defekte Bilder, PDF-Fehler) führen nicht zu Datenverlust oder zu verwaisten Dateien (siehe Tests aus QA-004): fehlgeschlagene Importe hinterlassen keine Halbdateien, Datenbank und Dateien bleiben konsistent, Autosave-Fehler werden dem Nutzer gemeldet. --- ## 6. Bekannte Restrisiken und Empfehlungen | Nr. | Restrisiko | Bewertung | Empfehlung | |---|---|---|---| | R1 | **Datenbank und Dateien sind nicht zusätzlich verschlüsselt** (nur Android-Sandbox + Gerätespeicher-Verschlüsselung). Auf gerooteten Geräten oder bei kompromittiertem Gerät sind Daten lesbar. | mittel | Gerät mit Bildschirmsperre und aktivierter Speicherverschlüsselung betreiben (Standard seit Android 10). Bei erhöhtem Schutzbedarf Datenbankverschlüsselung (z. B. SQLCipher mit Schlüssel im Android Keystore) einplanen. | | R2 | **Keine App-eigene Sperre** (PIN/Biometrie). Wer das entsperrte Gerät hat, sieht die Daten. | mittel | Gerätesperre verbindlich vorschreiben; optional App-Sperre mit `BiometricPrompt` einführen. | | R3 | **Tastatur-Lernfunktion/Autofill:** Eingaben (Namen, Befund-Freitexte) können von der Bildschirmtastatur oder einem Autofill-Dienst mitgelernt werden. | gering–mittel | Geräte-Richtlinie: nur vertrauenswürdige Tastatur, Personalisierung/Cloud-Funktionen der Tastatur deaktivieren. | | R4 | **Dateiname des PDFs enthält Name und Geburtsdatum** und ist in Ziel-Apps (Mailanhang, Messenger) sichtbar. | gering–mittel | Fachliche Entscheidung: neutralen Dateinamen (z. B. nur Dokumentations-ID/Datum) anbieten. | | R5 | **Weitergabe über andere Apps** liegt nach dem Teilen außerhalb der App-Kontrolle. | organisatorisch | Zulässige Übertragungswege festlegen (z. B. nur dienstliches Postfach/Messenger); Mitarbeiter schulen. | | R6 | **Release-Build ohne Code-Verkleinerung/Obfuskation** (`isMinifyEnabled = false`). | gering | Für die Veröffentlichung R8 aktivieren (bessere Härtung gegen Reverse Engineering; kein Ersatz für Datenschutzmaßnahmen). | | R7 | **Kein automatischer Abgleich/Backup**: Geräteverlust oder Defekt = Datenverlust. | Verfügbarkeit | Organisatorisches Archiv (z. B. PDFs in die Patientenakte der Einrichtung). | | R8 | **Kamera-App des Herstellers** speichert Aufnahmen evtl. zusätzlich in der Galerie/Cloud (bei `ACTION_IMAGE_CAPTURE` mit Ziel-URI normalerweise nicht, herstellerabhängig). | gering | Auf Testgeräten prüfen, ob Aufnahmen zusätzlich in der Galerie erscheinen. | --- ## 7. Automatisierte Datenschutz-Tests | Test | Art | Prüft | |---|---|---| | `PrivacySourceScanTest` | JVM | Keine Netzwerk-/Tracking-Bibliotheken, keine `println`/`printStackTrace`, Log-Aufrufe ohne Nachricht/Pfad/Personendaten, kein externer Speicher, keine Zwischenablage, keine Texte in Share-Intents, Manifest ohne Berechtigungen, `allowBackup=false`, nur eine exportierte Komponente, Backup-Regeln, FileProvider-Freigaben | | `SafePathsTest` | JVM | Schutz vor Path-Traversal | | `ExportedFilesCleanerTest` | JVM | Löschen der Exporte, Aufbewahrungsfristen, kein Löschen außerhalb der Exportordner | | `PrivacyConfigurationTest` | Gerät/Emulator | Zusammengeführtes Manifest (Berechtigungen, exportierte Komponenten), Backup, FileProvider-Freigaben, private Dateirechte, `FLAG_SECURE` | | `DocumentationDeletionPrivacyTest` | Gerät/Emulator | Löschen einer Dokumentation entfernt auch die Exporte | Diese Tests dienen als Regressionsschutz: Sie schlagen an, wenn künftig z. B. eine Berechtigung, eine Netzwerkbibliothek oder eine zu weite Freigabe hinzukommt. --- ## 8. Checkliste für Releases - [ ] Alle Tests grün (insbesondere die Datenschutz-Tests aus Abschnitt 7) - [ ] Merged Manifest geprüft (Android Studio → `AndroidManifest.xml` → Tab *Merged Manifest*): keine neuen Berechtigungen/exportierten Komponenten - [ ] Neue Abhängigkeiten auf Netzwerk-/Tracking-Funktionen geprüft - [ ] Neue Log-Ausgaben enthalten keine Patientendaten, Pfade, URIs oder Exception-Nachrichten - [ ] Neue Speicherorte liegen im privaten Speicher; neue Freigaben sind in `file_paths.xml` minimal - [ ] Neue Datenfelder sind in Abschnitt 2 dieses Dokuments ergänzt und im Löschkonzept berücksichtigt - [ ] Release-Build signiert, nicht debuggable --- ## 9. Organisatorische Hinweise (für die verantwortliche Stelle) Diese Punkte kann die App nicht technisch lösen: - **Rechtsgrundlage** der Verarbeitung (Behandlungsvertrag / Dokumentationspflicht, Art. 9 Abs. 2 lit. h DSGVO) und **Verzeichnis der Verarbeitungstätigkeiten** durch die verantwortliche Stelle - Prüfung, ob eine **Datenschutz-Folgenabschätzung** (Art. 35 DSGVO) erforderlich ist (Gesundheitsdaten, ggf. in größerem Umfang) - **Geräterichtlinie:** Bildschirmsperre, Geräteverschlüsselung, Updates, ggf. MDM, Regelung privater vs. dienstlicher Geräte - **Übertragungswege** für das Teilen von PDFs, Aufbewahrungs- und Löschfristen im Archiv - **Betroffenenrechte** (Auskunft, Berichtigung, Löschung): Löschung ist je Dokumentation in der App möglich; Auskunft über den PDF-Export - Schulung der Anwender, Meldeweg bei Geräteverlust (Meldepflicht bei Datenpannen, Art. 33 DSGVO) ## 10. Technische Eckdaten für Datenschutzdokumente - Verarbeitung ausschließlich lokal auf dem Gerät; keine Empfänger durch die App - Keine Auftragsverarbeiter durch die App (kein Server, keine Cloud, keine Analyse-/Crash-Dienste) - Keine Datenübermittlung in Drittländer durch die App - Keine Cookies, kein Tracking, keine Werbe-ID - Speicherdauer: bis zur Löschung durch den Nutzer; Exporte automatisch nach 7 Tagen - Zugriffsschutz: Android-App-Sandbox, Gerätesperre; `FLAG_SECURE`