Privacy by Design in Gesundheits-Apps. Warum lokale Datenhaltung für Krebs-Companion-Apps zählt.

Die erste Designentscheidung in einer Gesundheits-App ist nicht, welche Screens zu zeichnen sind. Sie ist, wo die Daten leben. Diese eine Wahl zieht sich durch die rechtliche Architektur, den regulatorischen Pfad, die Vertrauensbeziehung mit den Nutzerinnen und letztlich die langfristige Überlebensfähigkeit des Produkts. Für eine Anwendung, die Krebs-Patientinnen während der Therapie unterstützen soll, ist diese Entscheidung keine Fußnote. Sie ist die ganze Geschichte.

Dieser Essay argumentiert aus der Perspektive einer praktisch arbeitenden Solo-Entwicklerin, dass lokale Datenhaltung der vertretbarste Ausgangspunkt für sensible Gesundheitsanwendungen ist. Nicht weil sie modisch ist, und nicht weil sie bequem wäre. Sie ist beides nicht. Sondern weil die Alternative eine deutlich schwerere Compliance- und Betriebslast erfordert, als die meisten kleinen Teams tragen können, während sie noch ein gutes Produkt liefern.

In welche Kategorie die Daten fallen

Nach der europäischen Datenschutz-Grundverordnung sind Gesundheitsdaten keine gewöhnlichen personenbezogenen Daten. Sie fallen unter Artikel 9 als besondere Kategorie personenbezogener Daten, neben biometrischen Daten, genetischen Daten und Informationen zur sexuellen Orientierung. Ihre Verarbeitung erfordert entweder ausdrückliche Einwilligung oder eine der wenigen spezifischen Rechtsgrundlagen. Selbst dann erwartet die Verordnung, dass Verantwortliche Schutzmaßnahmen proportional zur Sensibilität implementieren.

Für eine Brustkrebs-Companion-App fallen die betroffenen Daten eindeutig in diese Kategorie. Diagnosedaten, Therapieschemata, Nebenwirkungen, Medikationspläne, Marker zur seelischen Verfassung. Alles davon. Sobald eine solche Anwendung beginnt, das auf einem Server zu speichern, wird die Entwicklerin zur Verantwortlichen für Daten besonderer Kategorien, mit allem, was dazugehört: Datenschutz-Folgenabschätzung, technische und organisatorische Maßnahmen, Meldepflichten bei Verletzungen, und ein Verhältnis zu Aufsichtsbehörden, das nicht existiert, wenn die Daten das Gerät nie verlassen.

Die architektonische Entscheidung

Lokale Datenhaltung bedeutet praktisch, dass die Anwendung Patientendaten ausschließlich in den geschützten Speicher des Geräts schreibt und daraus liest. Es gibt keine Synchronisation mit einem Cloud-Account. Es gibt kein serverseitiges Backup. Die Daten werden an keine Drittpartei übertragen: nicht für Analytics, nicht für Crash-Reporting, nicht für KI-Verarbeitung.

Dieser Ansatz hat klare Kosten. Nutzerinnen, die ihr Gerät verlieren, verlieren ihre Daten. Nutzerinnen mit mehreren Geräten können denselben Datensatz nicht auf allen sehen. Wiederherstellungsoptionen beschränken sich auf das, was das Betriebssystem selbst bietet (iCloud Backup zum Beispiel, das verschlüsselt ist, aber auf einer Ebene außerhalb der Anwendungskontrolle stattfindet). Das sind echte Trade-offs, und die Nutzerin muss klar darüber informiert werden.

Was gewonnen wird, ist strukturell. Die Anwendung ist nicht mehr Verantwortliche für Daten besonderer Kategorien in dem Sinne, der die schwersten DSGVO-Pflichten auslöst. Es gibt keinen Server-Breach zu fürchten, weil es keinen Server gibt. Es gibt keine Frage, in welcher Jurisdiktion die Daten verarbeitet werden, weil sie an nur einem Ort verarbeitet werden: auf dem Telefon der Nutzerin selbst. Die Nutzerin ist im wörtlichen Sinne im physischen Besitz ihres Datensatzes.

Die regulatorische Dividende

Über die DSGVO hinaus zahlt sich dieselbe architektonische Entscheidung auf dem Pfad der Medizinprodukte-Verordnung aus. Nach der EU-Medizinprodukteverordnung hängt die Klassifizierung einer Anwendung, und die damit verbundene Last der Konformitätsbewertung, teilweise von den Risiken ab, die die Software einführt. Eine Anwendung, die nie überträgt, nie aggregiert und keine andere Form der Verarbeitung jenseits lokalen Protokollierens und Visualisierens betreibt, ist von Natur aus risikoärmer als eine, die das tut.

Das heißt nicht, dass eine solche Anwendung automatisch Klasse I wird. Die Klassifizierung hängt von der Zweckbestimmung ab. Aber es bedeutet, dass die Technische Dokumentation, die Risikoanalyse nach ISO 14971 und die klinische Bewertung nach MDR alle einfacher und ehrlicher werden, wenn weniger zu verteidigen ist. Wer tiefer in diese Frage einsteigen will, findet die praktische Seite in Der MDR-Pfad für Solo-Entwickler:innen.

Die am besten verteidigbare Gesundheits-App ist diejenige, die am wenigsten mit den Daten macht. Und ehrlich darüber ist.

Die Vertrauens-Dividende

Es gibt auch einen leiseren Vorteil, schwerer zu messen, aber leicht zu spüren: Vertrauen. Patientinnen in aktiver Behandlung sind erschöpft, verängstigt und skeptisch gegenüber wieder einer Firma, die nach ihren Daten fragt. Eine klare Aussage, dass die Daten nur auf ihrem Telefon liegen und nirgendwo anders eine Kopie existiert, kommt deutlich anders an als ein Absatz darüber, wie Daten „verschlüsselt in Transit und at Rest mit branchenüblichen Schutzmaßnahmen” abgesichert sind.

Die erste Aussage ist etwas, das eine Nutzerin verifizieren kann, indem sie ihr Telefon ausschaltet. Die zweite ist etwas, das sie auf Vertrauen hinnehmen muss. Für Anwendungen während einer schweren Erkrankung ist dieser Unterschied entscheidend.

Was das in der Praxis bedeutet

Für ein kleines Studio, das eine solche Anwendung baut, prägt lokale Datenhaltung den gesamten technischen Stack. Auf iOS bedeutet das sorgfältige Nutzung des plattformeigenen sicheren Speichers, Aufmerksamkeit dafür, welche Backup-Mechanismen die Daten einschließen, und ausdrückliche Wahl der Nutzerin, ob sie an einer optionalen Export-Funktion teilnimmt. Es bedeutet keine Drittanbieter-Analytics-SDKs. Es bedeutet keinen Crash-Reporting-Dienst, der Nutzerdaten ingestiert. Es bedeutet, die Anwendung so zu schreiben, als würde die Entwicklerin die Daten nie sehen. Denn sie wird es nicht.

Das ist ein eingeschränkterer Weg, Software zu bauen. Er schließt viele der Bequemlichkeiten aus, auf die kleine Teams normalerweise für Produkt-Analytics, Feature-Flag-Tests und Remote-Debugging zurückgreifen. Der Tausch lohnt sich für eine Klasse von Anwendungen: solche, in denen die Daten so sensibel sind, dass der sicherste Ort für sie die Hosentasche der Nutzerin selbst ist.

Eine kurze Anmerkung, was das nicht ist

Lokale Datenhaltung ist für sich genommen keine Datenschutz-Garantie. Eine Anwendung kann immer noch Telemetrie senden, unnötige Berechtigungen anfordern oder Daten durch schlecht gestaltete Sharing-Funktionen lecken. Die Architektur ist ein Fundament, kein Finish. Aber sie ist ein Fundament, das alles, was darauf gebaut wird, einfacher verteidigen, einfacher verifizieren und einfacher vertrauen lässt.

Für eine Krebs-Companion-App ist dieses Fundament der Ausgangspunkt, nicht die Optimierung.

Häufige Fragen

Was bedeutet „Privacy by Design" konkret für eine Gesundheits-App?

Privacy by Design bedeutet, dass Datenschutz in der Architektur einer Anwendung verankert ist, nicht in nachträglich hinzugefügten Erklärungen. Für eine Gesundheits-App heißt das konkret: Patientendaten werden ausschließlich auf dem Gerät der Nutzerin gespeichert, nie auf einem Server. Keine Synchronisation, kein Cloud-Backup, keine Übertragung an Dritte für Analytics, Crash-Reporting oder KI-Verarbeitung.

Welche DSGVO-Regelungen sind für Gesundheits-Apps besonders relevant?

Gesundheitsdaten fallen unter Art. 9 DSGVO als besondere Kategorie personenbezogener Daten. Ihre Verarbeitung erfordert ausdrückliche Einwilligung oder eine andere enge Rechtsgrundlage. Verantwortliche müssen Schutzmaßnahmen proportional zur Sensibilität implementieren, eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO durchführen und die Meldepflichten bei Verletzungen nach Art. 33 erfüllen.

Welche Trade-offs hat lokale Datenhaltung in Gesundheits-Apps?

Drei zentrale Kosten: Nutzerinnen verlieren bei Geräteverlust ihre Daten, Mehrgeräte-Nutzung ist eingeschränkt, und Wiederherstellung hängt vom Betriebssystem ab (iCloud Backup auf iOS). Gewonnen wird strukturelle Entlastung: keine Server-Breach-Risiken, keine Jurisdiktions-Fragen, und der Status als Verantwortliche für Daten besonderer Kategorien wird in vielen Punkten entschärft.

Wie wirkt sich lokale Datenhaltung auf den EU-MDR-Pfad aus?

Eine Anwendung, die nie überträgt, nie aggregiert und keine Verarbeitung jenseits lokaler Protokollierung betreibt, ist intrinsisch risikoärmer. Das beeinflusst die Risikoanalyse nach ISO 14971 und die klinische Bewertung positiv, garantiert aber nicht automatisch Klasse I. Die endgültige Klassifizierung hängt von der Zweckbestimmung ab.