\n| Forschungsdatenbank<\/td>\n | Pseudonymisierte klinische Studiendaten<\/td>\n | Re-Identifizierung von Studienteilnehmern<\/td>\n | Robuste Pseudonymisierungsverfahren, strenge Zugriffskontrollen, Aggregation von Daten vor Ver\u00f6ffentlichung<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nData Flow Mapping: Wie man Verarbeitungen technisch dokumentiert<\/h2>\nUm den Datenschutz bei Gesundheitsdaten<\/strong> systematisch zu gew\u00e4hrleisten, m\u00fcssen Sie genau wissen, welche Daten wo flie\u00dfen. Ein Data Flow Map oder Diagramm ist daf\u00fcr das zentrale Werkzeug. Es sollte mindestens folgende Informationen enthalten:<\/p>\n\n- Datenquelle:<\/strong> Woher stammen die Daten (z. B. Nutzereingabe in der App, Sensor, Schnittstelle zu einem Praxisverwaltungssystem)?<\/li>\n
- Datenkategorien:<\/strong> Welche Art von Gesundheitsdaten wird verarbeitet (z. B. Diagnosedaten, Vitalparameter, genetische Daten)?<\/li>\n
- Verarbeitungsschritte:<\/strong> Was passiert mit den Daten (z. B. Speicherung, Analyse, Weitergabe)?<\/li>\n
- Systeme und Speicherorte:<\/strong> In welchen Systemen (z. B. App-Backend, Cloud-Datenbank, Analysetool) und an welchem geografischen Ort werden die Daten gespeichert?<\/li>\n
- Drittanbieter:<\/strong> Welche externen Dienstleister sind involviert (z. B. Cloud-Hoster, E-Mail-Provider)?<\/li>\n
- Rechtsgrundlage:<\/strong> Auf welcher Basis erfolgt jeder Verarbeitungsschritt (z. B. Einwilligung, gesetzliche Pflicht)?<\/li>\n
- L\u00f6schfristen:<\/strong> Wann werden die Daten gel\u00f6scht?<\/li>\n<\/ul>\n
Diese Dokumentation ist nicht nur f\u00fcr die interne \u00dcbersicht essenziell, sondern auch eine Kernanforderung f\u00fcr das Verzeichnis von Verarbeitungst\u00e4tigkeiten (VVT) nach Art. 30 DSGVO und die DSFA.<\/p>\n Datenminimierung und Zweckbindung in der Praxis<\/h2>\nDie Grunds\u00e4tze der Datenminimierung<\/strong> (Art. 5 Abs. 1 lit. c DSGVO) und der Zweckbindung<\/strong> (Art. 5 Abs. 1 lit. b DSGVO) sind entscheidend f\u00fcr den Schutz von Gesundheitsdaten.<\/p>\nPraktische Umsetzung der Datenminimierung<\/h3>\n\n- Frontend:<\/strong> Fragen Sie in Formularen nur die Informationen ab, die f\u00fcr die jeweilige Funktion zwingend erforderlich sind.<\/li>\n
- Backend:<\/strong> Speichern Sie nur die Daten, die f\u00fcr den definierten Zweck notwendig sind. Leiten Sie keine unn\u00f6tigen Daten in Logfiles oder Analysetools weiter.<\/li>\n
- Berechtigungen:<\/strong> Stellen Sie sicher, dass Mitarbeiter nur auf die Daten zugreifen k\u00f6nnen, die sie f\u00fcr ihre spezifische Aufgabe ben\u00f6tigen (Need-to-know-Prinzip).<\/li>\n<\/ul>\n
Praktische Umsetzung der Zweckbindung<\/h3>\n\n- Transparenz:<\/strong> Kommunizieren Sie klar und verst\u00e4ndlich in der Datenschutzerkl\u00e4rung, f\u00fcr welche Zwecke die Daten verarbeitet werden.<\/li>\n
- Keine Zweck\u00e4nderung:<\/strong> Verwenden Sie erhobene Gesundheitsdaten nicht f\u00fcr andere Zwecke (z. B. Marketing), ohne eine neue, separate Einwilligung einzuholen.<\/li>\n
- Technische Trennung:<\/strong> Wenn Daten f\u00fcr unterschiedliche Zwecke (z. B. Abrechnung und Forschung) verarbeitet werden, sollten diese logisch oder physisch getrennt gespeichert werden.<\/li>\n<\/ul>\n
Technische Mindestanforderungen: Verschl\u00fcsselung, Zugriffskontrolle, IAM und Logging<\/h2>\nDie DSGVO fordert \u201egeeignete technische und organisatorische Ma\u00dfnahmen\u201c (TOMs). F\u00fcr Gesundheitsdaten bedeutet dies ein sehr hohes Schutzniveau.<\/p>\n Verschl\u00fcsselung<\/h3>\n\n- In-Transit:<\/strong> Jegliche Daten\u00fcbertragung \u00fcber \u00f6ffentliche Netze muss mittels starker, aktueller Protokolle wie TLS 1.3<\/strong> erfolgen. Konfigurieren Sie Ihre Server so, dass unsichere, veraltete Protokolle und Cipher Suites abgelehnt werden.<\/li>\n
- At-Rest:<\/strong> Alle Datenbanken, Backups und Festplatten, auf denen Gesundheitsdaten gespeichert sind, m\u00fcssen verschl\u00fcsselt werden (z. B. mittels TDE f\u00fcr Datenbanken oder Volume Encryption f\u00fcr Server).<\/li>\n
- Ende-zu-Ende-Verschl\u00fcsselung (E2EE):<\/strong> F\u00fcr besonders sensible Kommunikationsinhalte (z. B. Arzt-Patienten-Chats) ist E2EE der Goldstandard, da hierbei selbst der Plattformbetreiber keinen Zugriff auf die Inhalte hat.<\/li>\n
- Schl\u00fcsselmanagement:<\/strong> Die kryptografischen Schl\u00fcssel m\u00fcssen sicher verwahrt und verwaltet werden, idealerweise in einem Hardware Security Module (HSM) oder einem dedizierten Key Management Service (KMS).<\/li>\n<\/ul>\n
Zugriffskontrolle und IAM<\/h3>\n\n- Multi-Faktor-Authentifizierung (MFA):<\/strong> Der Zugriff auf Systeme mit Gesundheitsdaten (sowohl f\u00fcr Nutzer als auch f\u00fcr Administratoren) muss durch MFA gesch\u00fctzt werden.<\/li>\n
- Rollenbasiertes Zugriffskontrollsystem (RBAC):<\/strong> Definieren Sie klare Rollen (z. B. Arzt, Patient, Admin) mit minimalen Berechtigungen (Principle of Least Privilege).<\/li>\n
- Starke Passwortrichtlinien:<\/strong> Erzwingen Sie komplexe Passw\u00f6rter und regelm\u00e4\u00dfige \u00dcberpr\u00fcfungen.<\/li>\n<\/ul>\n
Logging und Monitoring<\/h3>\n\n- L\u00fcckenlose Protokollierung:<\/strong> Jeder Zugriff auf Gesundheitsdaten muss protokolliert werden (Wer, wann, was, warum?).<\/li>\n
- Manipulationssicherheit:<\/strong> Log-Daten m\u00fcssen vor Ver\u00e4nderung und unbefugtem L\u00f6schen gesch\u00fctzt werden (z. B. durch Write-Once-Read-Many (WORM) Speicher oder Weiterleitung an ein separates SIEM-System).<\/li>\n
- Regelm\u00e4\u00dfige \u00dcberpr\u00fcfung:<\/strong> Die Logs m\u00fcssen regelm\u00e4\u00dfig auf verd\u00e4chtige Aktivit\u00e4ten \u00fcberpr\u00fcft werden.<\/li>\n<\/ul>\n
DSFA Schritt f\u00fcr Schritt mit Entscheidungsbaum<\/h2>\nEine Datenschutz-Folgenabsch\u00e4tzung (DSFA)<\/strong>, auch Data Protection Impact Assessment (DPIA) genannt, ist gem\u00e4\u00df Art. 35 DSGVO bei der Verarbeitung von Gesundheitsdaten in der Regel verpflichtend.<\/p>\nEntscheidungsbaum: Ist eine DSFA erforderlich?<\/h3>\n\n- Verarbeiten Sie Gesundheitsdaten (Art. 9 DSGVO)? (Ja\/Nein)<\/li>\n
- Erfolgt die Verarbeitung in gro\u00dfem Umfang oder unter Einsatz neuer Technologien (z. B. KI, Cloud-Plattform)? (Ja\/Nein)<\/li>\n<\/ol>\n
Wenn Sie mindestens eine Frage mit \u201eJa\u201c beantworten, ist eine DSFA dringend anzuraten bzw. meistens gesetzlich vorgeschrieben.<\/p>\n Schritte zur Durchf\u00fchrung einer DSFA:<\/h3>\n\n- Systematische Beschreibung der Verarbeitung:<\/strong> Dokumentieren Sie die Datenfl\u00fcsse, Zwecke, Rechtsgrundlagen und beteiligten Akteure.<\/li>\n
- Bewertung der Notwendigkeit und Verh\u00e4ltnism\u00e4\u00dfigkeit:<\/strong> Begr\u00fcnden Sie, warum die Verarbeitung zur Erreichung des Zwecks erforderlich ist.<\/li>\n
- Risikoanalyse:<\/strong> Identifizieren und bewerten Sie die Risiken f\u00fcr die Rechte und Freiheiten der betroffenen Personen (z. B. Risiko von Datenlecks, Diskriminierung, Re-Identifizierung). Nutzen Sie eine Metrik (z. B. Eintrittswahrscheinlichkeit x Schadensh\u00f6he).<\/li>\n
- Abhilfema\u00dfnahmen definieren:<\/strong> Planen Sie konkrete technische und organisatorische Ma\u00dfnahmen (TOMs), um die identifizierten Risiken zu minimieren. Dies k\u00f6nnen Verschl\u00fcsselung, Pseudonymisierung oder verbesserte Zugriffskontrollen sein.<\/li>\n
- Dokumentation und Freigabe:<\/strong> Halten Sie den gesamten Prozess schriftlich fest und holen Sie gegebenenfalls die Stellungnahme Ihres Datenschutzbeauftragten ein.<\/li>\n<\/ol>\n
Drittanbieter und Cloud: Vertragsklauseln und Pr\u00fcfpunkte<\/h2>\nKaum ein digitales Gesundheitsprodukt kommt ohne Drittanbieter aus. Der Einsatz von Cloud-Providern oder anderen Dienstleistern ist eine Auftragsverarbeitung.<\/p>\n Wichtige Pr\u00fcfpunkte:<\/h3>\n\n- Auftragsverarbeitungsvertrag (AVV):<\/strong> Ein schriftlicher Vertrag nach Art. 28 DSGVO ist zwingend erforderlich. Er muss die Rechte und Pflichten beider Seiten klar regeln.<\/li>\n
- Standort der Datenverarbeitung:<\/strong> Bevorzugen Sie Anbieter mit Serverstandorten ausschlie\u00dflich innerhalb der EU\/des EWR.<\/li>\n
- Zertifizierungen:<\/strong> Pr\u00fcfen Sie, ob der Anbieter relevante Zertifizierungen vorweisen kann, z. B. ISO 27001, ISO 27701 oder branchenspezifische Standards wie den Kriterienkatalog C5 des BSI.<\/li>\n
- Technische und organisatorische Ma\u00dfnahmen (TOMs):<\/strong> Lassen Sie sich die TOMs des Anbieters vorlegen und pr\u00fcfen Sie, ob diese Ihrem eigenen Schutzniveau entsprechen.<\/li>\n
- Weisungsgebundenheit:<\/strong> Der Anbieter darf die Daten nur nach Ihrer dokumentierten Weisung verarbeiten.<\/li>\n<\/ul>\n
Grenz\u00fcberschreitende \u00dcbermittlungen: Konkrete Handlungsschritte<\/h2>\nDie \u00dcbermittlung von Gesundheitsdaten in L\u00e4nder au\u00dferhalb der EU\/des EWR (Drittl\u00e4nder) ist eine besondere Herausforderung. Seit dem \u201eSchrems II\u201c-Urteil des EuGH sind die Anforderungen hierf\u00fcr sehr hoch.<\/p>\n Handlungsschritte f\u00fcr 2025:<\/h3>\n\n- Pr\u00fcfen, ob ein Angemessenheitsbeschluss existiert:<\/strong> F\u00fcr einige L\u00e4nder (z. B. Schweiz, Kanada) hat die EU-Kommission ein angemessenes Datenschutzniveau festgestellt. \u00dcbermittlungen sind dann einfacher m\u00f6glich.<\/li>\n
- Standardvertragsklauseln (SVK) verwenden:<\/strong> F\u00fcr \u00dcbermittlungen in andere L\u00e4nder (insbesondere die USA) sind Standardvertragsklauseln (SCC auf Englisch) das g\u00e4ngigste Instrument.<\/li>\n
- Transfer Impact Assessment (TIA) durchf\u00fchren:<\/strong> Zus\u00e4tzlich zu den SVK m\u00fcssen Sie dokumentieren, ob die Gesetze und Praktiken im Zielland (z. B. \u00dcberwachungsgesetze) den Schutz der Klauseln untergraben. Dies ist eine komplexe Einzelfallpr\u00fcfung.<\/li>\n
- Zus\u00e4tzliche Schutzma\u00dfnahmen ergreifen:<\/strong> Falls das TIA Risiken aufzeigt, m\u00fcssen Sie zus\u00e4tzliche Ma\u00dfnahmen ergreifen, z. B. eine starke Verschl\u00fcsselung, bei der der Drittanbieter im Drittland keinen Zugriff auf die Schl\u00fcssel hat.<\/li>\n<\/ol>\n
Sicherheitsvorf\u00e4lle: Meldepflichten und Vorbereitung<\/h2>\nTrotz bester Vorkehrungen kann es zu einem Sicherheitsvorfall kommen. Ein strukturierter Notfallplan ist entscheidend.<\/p>\n \n- Meldepflicht an die Aufsichtsbeh\u00f6rde:<\/strong> Eine Verletzung des Schutzes personenbezogener Daten muss gem\u00e4\u00df Art. 33 DSGVO unverz\u00fcglich und m\u00f6glichst binnen 72 Stunden<\/strong> nach Bekanntwerden an die zust\u00e4ndige Datenschutz-Aufsichtsbeh\u00f6rde gemeldet werden, es sei denn, sie f\u00fchrt voraussichtlich nicht zu einem Risiko f\u00fcr die Betroffenen. Bei Gesundheitsdaten ist ein Risiko fast immer anzunehmen.<\/li>\n
- Benachrichtigungspflicht an Betroffene:<\/strong> Besteht ein hohes Risiko<\/strong> f\u00fcr die pers\u00f6nlichen Rechte und Freiheiten, m\u00fcssen auch die betroffenen Personen unverz\u00fcglich informiert werden (Art. 34 DSGVO).<\/li>\n
- Vorbereitung:<\/strong> Erstellen Sie einen Incident-Response-Plan, der klare Zust\u00e4ndigkeiten, Kommunikationswege (intern und extern) und technische Schritte zur forensischen Analyse und Eind\u00e4mmung des Vorfalls festlegt.<\/li>\n<\/ul>\n
Spezialthemen: Pseudonymisierung versus Anonymisierung<\/h2>\nDie Begriffe werden oft verwechselt, haben aber fundamental unterschiedliche rechtliche Konsequenzen.<\/p>\n \n- Pseudonymisierung:<\/strong> Personenbezogene Daten werden so ver\u00e4ndert, dass sie ohne Hinzuziehung zus\u00e4tzlicher Informationen nicht mehr einer spezifischen Person zugeordnet werden k\u00f6nnen (z. B. Ersetzen des Namens durch eine ID). Diese zus\u00e4tzlichen Informationen m\u00fcssen separat und sicher aufbewahrt werden. Wichtig: Pseudonymisierte Daten sind weiterhin personenbezogene Daten und fallen vollst\u00e4ndig unter die DSGVO.<\/strong><\/li>\n
- Anonymisierung:<\/strong> Die Daten werden so ver\u00e4ndert, dass eine Re-Identifizierung der Person nicht oder nur mit einem unverh\u00e4ltnism\u00e4\u00dfig gro\u00dfen Aufwand m\u00f6glich ist. Echte anonyme Daten fallen nicht mehr in den Anwendungsbereich der DSGVO.<\/strong> Die Anforderungen an eine wirksame Anonymisierung sind jedoch sehr hoch (z. B. k-Anonymit\u00e4t, Differential Privacy).<\/li>\n<\/ul>\n
Implementierungsfahrplan f\u00fcr Startups und KMU (30\/60\/90 Tage\u2011Plan)<\/h2>\nEin strukturierter Ansatz hilft, den Datenschutz bei Gesundheitsdaten<\/strong> von Anfang an richtig aufzusetzen.<\/p>\nErste 30 Tage: Analyse und Planung<\/h3>\n\n- Datenschutzbeauftragten benennen (intern oder extern).<\/li>\n
- Alle geplanten Datenverarbeitungen identifizieren und Data Flow Mappings erstellen.<\/li>\n
- Verzeichnis von Verarbeitungst\u00e4tigkeiten (VVT) anlegen.<\/li>\n
- Notwendigkeit einer DSFA f\u00fcr Kernprozesse bewerten.<\/li>\n<\/ul>\n
Tage 31-60: Rechtliche und konzeptionelle Umsetzung<\/h3>\n\n- DSFA durchf\u00fchren.<\/li>\n
- Einwilligungstexte und Datenschutzerkl\u00e4rung entwerfen.<\/li>\n
- Auftragsverarbeitungsvertr\u00e4ge (AVV) mit allen Dienstleistern pr\u00fcfen und abschlie\u00dfen.<\/li>\n
- Technisches Sicherheitskonzept (TOMs) finalisieren.<\/li>\n<\/ul>\n
Tage 61-90: Technische Implementierung und Schulung<\/h3>\n\n- Definierte TOMs (Verschl\u00fcsselung, IAM etc.) implementieren.<\/li>\n
- L\u00f6schkonzept technisch umsetzen.<\/li>\n
- Incident-Response-Plan erstellen und testen.<\/li>\n
- Alle Mitarbeiter zum Thema Datenschutz bei Gesundheitsdaten schulen.<\/li>\n<\/ul>\n
Zwei kurze Fallbeispiele mit L\u00f6sungspfaden<\/h2>\nFallbeispiel 1: Fitness-App mit Datensynchronisation<\/h3>\nProblem:<\/strong> Eine neue App soll Vitaldaten aus einem Fitness-Tracker importieren und dem Nutzer personalisierte Gesundheitstipps geben. Die Daten sollen in einer Cloud-Datenbank analysiert werden.<\/p>\nL\u00f6sungspfad:<\/strong><\/p>\n\n- Granulare Einwilligung:<\/strong> Der Nutzer muss explizit und getrennt einwilligen: a) in den Import der Daten vom Tracker und b) in die Analyse der Daten zur Erstellung von Tipps.<\/li>\n
- Verschl\u00fcsselung:<\/strong> Die Daten m\u00fcssen vom Tracker zur App und von der App zum Backend durchg\u00e4ngig transportverschl\u00fcsselt (TLS 1.3) sein. Die Datenbank selbst muss at-rest verschl\u00fcsselt sein.<\/li>\n
- DSFA:<\/strong> Eine DSFA ist zwingend erforderlich, da Gesundheitsdaten in gro\u00dfem Umfang mit einer neuen Technologie verarbeitet werden.<\/li>\n
- AVV:<\/strong> Mit dem Cloud-Hoster ist ein AVV abzuschlie\u00dfen, der den Standort auf die EU beschr\u00e4nkt.<\/li>\n<\/ol>\n
Fallbeispiel 2: Cloud-Insourcing einer Arztpraxis-Software<\/h3>\nProblem:<\/strong> Eine Praxisverwaltungssoftware (PVS) soll von einem lokalen Server zu einem Cloud-Anbieter migriert werden, um die Verf\u00fcgbarkeit zu erh\u00f6hen.<\/p>\nL\u00f6sungspfad:<\/strong><\/p>\n\n- Anbieterauswahl:<\/strong> Auswahl eines Cloud-Providers mit Standort in Deutschland oder der EU und entsprechenden Zertifizierungen (z. B. C5).<\/li>\n
- Strikter AVV:<\/strong> Der AVV muss detailliert die TOMs, die Weisungsgebundenheit und die Kontrollrechte der Praxis regeln.<\/li>\n
- Client-Side-Encryption:<\/strong> Idealerweise werden die Patientendaten bereits vor dem Upload in die Cloud verschl\u00fcsselt (Client-Side-Encryption), sodass der Cloud-Anbieter selbst keinen Zugriff auf die Klartextdaten hat. Die Schl\u00fcssel verbleiben unter alleiniger Kontrolle der Praxis.<\/li>\n
- Zugriffskontrolle:<\/strong> Der Zugriff auf die Cloud-Umgebung muss \u00fcber MFA f\u00fcr alle Mitarbeiter der Praxis abgesichert werden.<\/li>\n<\/ol>\n
Vorlagen und Checklisten zur direkten Anwendung<\/h2>\nObwohl individuelle Anpassungen unerl\u00e4sslich sind, k\u00f6nnen standardisierte Vorlagen den Prozess beschleunigen. Ihre Dokumentation sollte folgende Elemente umfassen:<\/p>\n Checkliste f\u00fcr eine DSFA-Matrix<\/h3>\n\n- Beschreibung der Verarbeitungst\u00e4tigkeit<\/li>\n
- Rechtsgrundlage und Zweck<\/li>\n
- Identifizierte Risiken (Vertraulichkeit, Integrit\u00e4t, Verf\u00fcgbarkeit)<\/li>\n
- Eintrittswahrscheinlichkeit (niedrig, mittel, hoch)<\/li>\n
- M\u00f6gliche Schadensh\u00f6he (gering, erheblich, gro\u00df)<\/li>\n
- Bestehende Abhilfema\u00dfnahmen<\/li>\n
- Geplante zus\u00e4tzliche Abhilfema\u00dfnahmen<\/li>\n
- Restrisikobewertung nach Umsetzung der Ma\u00dfnahmen<\/li>\n<\/ul>\n
Struktur eines Verzeichnisses von Verarbeitungst\u00e4tigkeiten (VVT)<\/h3>\n\n- Name und Kontaktdaten des Verantwortlichen und ggf. des Datenschutzbeauftragten<\/li>\n
- Zwecke der Verarbeitung<\/li>\n
- Beschreibung der Kategorien betroffener Personen (z. B. Patienten, Nutzer)<\/li>\n
- Beschreibung der Kategorien personenbezogener Daten (z. B. Kontaktdaten, Diagnosen)<\/li>\n
- Kategorien von Empf\u00e4ngern (z. B. Cloud-Hoster, Abrechnungsstelle)<\/li>\n
- Informationen zu Drittland\u00fcbermittlungen<\/li>\n
- Vorgesehene Fristen f\u00fcr die L\u00f6schung<\/li>\n
- Allgemeine Beschreibung der technischen und organisatorischen Ma\u00dfnahmen (TOMs)<\/li>\n<\/ul>\n
Versionierung und Wartungsplan dieses Leitfadens<\/h2>\nDieser Leitfaden wird regelm\u00e4\u00dfig, mindestens jedoch j\u00e4hrlich, \u00fcberpr\u00fcft und an die aktuelle Rechtslage und technische Entwicklungen angepasst. Die Verantwortung f\u00fcr die Pflege liegt bei der Compliance-Abteilung in Zusammenarbeit mit der technischen Leitung. Die aktuelle Version ist stets auf dieser Webseite verf\u00fcgbar.<\/p>\n Glossar wichtiger Begriffe<\/h2>\nHier finden Sie eine Auswahl an weiterf\u00fchrenden Informationen und offiziellen Quellen:<\/p>\n |