Eine geeignete Gruppe zur Überprüfung dieses Themas wäre ein interdisziplinäres Team, bestehend aus:
IT-Sicherheitsexperten und Penetrationstestern: Für die technische Bewertung von Sicherheitsarchitekturen und Implementierungen.
Datenschutzbeauftragten und Juristen für IT- und Gesundheitsrecht: Zur Beurteilung der Einhaltung der DSGVO und anderer relevanter Datenschutzgesetze sowie der rechtlichen Rahmenbedingungen.
Regulierungsbehörden und Gesundheitspolitikern (z.B. BfArM, BSI, Gematik): Um die Wirksamkeit und Praktikabilität der bestehenden Richtlinien zu bewerten und zukünftige Anpassungen zu diskutieren.
Herstellern und Entwicklern digitaler Gesundheitsanwendungen: Um die Umsetzbarkeit der Anforderungen und die Auswirkungen auf Innovation und Benutzerfreundlichkeit zu beleuchten.
Medizinischen Fachkräften und Patientenvertretern: Zur Sicherstellung des medizinischen Nutzens, der Barrierefreiheit und der Akzeptanz der Anwendungen durch die Nutzer.
Sozialforschern und Ethikkommissionen: Um die sozialen Implikationen, Fragen der Teilhabe und mögliche Diskriminierungseffekte zu analysieren.
Abstract
Der Vortrag beleuchtet die Herausforderungen bei der Regulierung digitaler Gesundheitsanwendungen (DiGA) in Deutschland, insbesondere durch die Technische Richtlinie 161 (TR161) des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Es werden die Ziele der DiGA (Kompensation von Versorgungsdefiziten), die beteiligten Akteure (BfArM, BSI, BFDI, Krankenkassen) sowie die spezifischen Probleme der TR161 analysiert, darunter unklare Anforderungen, divergierende Auslegungen der Prüflabore, Widerstand der Hersteller und Konflikte zwischen Sicherheits- und Usability-Anforderungen. Kritische Punkte sind die faktische Abhängigkeit von großen Technologieanbietern (Google, Apple), die Problematik der Authentifizierung bei hohem Schutzbedarf von Gesundheitsdaten und die mangelnde Berücksichtigung sozialer Aspekte und Barrierefreiheit. Verbesserungsvorschläge umfassen klarere Richtlinien, Förderung von Webanwendungen, neutrale Distributionskanäle und Anti-Fingerprinting-Mechanismen.
Wichtigste Punkte & Zeitstempel
0:12 Einführung in DiGA-Regulierung: Vorstellung der digitalen Gesundheitsanwendungen (DiGA) und deren Regulierung durch die Technische Richtlinie 161 (TR161) des BSI, basierend auf dem Fünften Sozialgesetzbuch (SGB V) und dem Digitale Versorgung Gesetz (DVG).
1:22 Arten von DiGA: Beschreibt DiGA als verschreibbare Anwendungen für diverse Diagnosen (z.B. ADHS, Endometriose, Rückenschmerzen), die meist Informationen, Übungen oder Tagebuchfunktionen bieten; einige auch aktive Komponenten.
2:15 Motivation und Ersatzcharakter: Der Gesetzesentwurf sieht DiGA als Lösung für Herausforderungen im Gesundheitswesen wie alternde Gesellschaft, Fachkräftemangel und Unterversorgung, was eine potenzielle Ersatzfunktion für Leistungen andeutet, nicht nur eine Ergänzung.
3:22 Regulierungslandschaft: Das BfArM prüft die medizinische Perspektive und Verschreibbarkeit, das BSI ist für Privacy und Informationssicherheit (TR161) zuständig, im Einvernehmen mit dem BFDI für Datenschutz, und Krankenkassen übernehmen die Kosten.
4:30 Probleme der TR161: Die TR161 leidet unter unklaren Anforderungen, die fortlaufend durch BSI-FAQs ergänzt werden, und unterschiedlichen Bewertungen durch beauftragte Prüflabore sowie Meinungsverschiedenheiten innerhalb des BSI.
5:54 Externe Abhängigkeiten: Die TR161 verweist auf zahlreiche externe Dokumente (z.B. Gematik Gamsback, NIST AIS20), was zu widersprüchlichen Vorgaben und einer hohen Komplexität bei der Implementierung führt.
7:11 Herstellerwiderstand: Bisher nur 11 DiGA ohne Auflagen zugelassen; erheblicher Widerstand von Herstellern, die in einem Interessenverband argumentieren, dass strenge Anforderungen die Benutzbarkeit beeinträchtigen.
9:12 Struktur der TR161: Die TR161 ist in drei Teile für mobile Apps, Webanwendungen und Hintergrundsysteme gegliedert und behandelt Themen wie Datenverarbeitungszwecke, Architektur, Implementierungsmaßnahmen, Drittanbieter-Software, Kryptografie und Authentifizierung.
11:01 Interpretation von Anforderungen: Im BSI-Kontext bedeutet "soll" faktisch "muss" und "soll nicht" bedeutet "darf nicht", was zu harten Grenzwerten bei der Prüfung und strikter Ablehnung bei Überschreitung führt.
11:33 Positive Aspekte der TR161: Vorgaben zur Datenverarbeitung verbieten Datenerhebung jenseits des rechtmäßigen Zwecks (inkl. Forschungszwecken), fordern einfache Meldung von Schwachstellen und die Löschung von Daten nach Zweckerfüllung.
13:13 Kritik an Server-Verarbeitung (Odata 7): Die Anforderung, Daten primär im Hintergrundsystem zu verarbeiten, wird als nicht nachvollziehbar kritisiert, da sie für einfache Informations-Apps unnötig ist und Datenschutzrisiken birgt.
14:10 Probleme mit Drittanbieter-Software: Die Forderung nach stets neuesten oder vorhergehenden Versionen von Drittanbieter-Software ist aufgrund des Prüfungsaufwands (400€ pro Update) und der schnellen Entwicklung von Abhängigkeiten in der Praxis schwer umsetzbar und kann paradoxerweise zu unsichereren Anwendungen führen.
15:43 Spezialfall Opose 7: Die Anforderung, alle ungenutzten Funktionen von Abhängigkeiten zu deaktivieren, wird als unrealistisch und theoretisch (Ris' Theorem) kritisiert, da die genaue Bedeutung unklar ist und Klärungen nur langsam über FAQs erfolgen.
16:57 Kryptografie und Zufallsgeneratoren: Forderungen nach sicheren Zufallsgeneratoren und Verweise auf ältere BSI-TRs verbieten teilweise veraltete Praktiken (z.B. /dev/random), verursachen aber in modernen Systemen unnötigen Implementierungsaufwand.
18:12 Hardware Security Module (HSM) und Betriebssystem: Die Notwendigkeit von HSMs für Schlüssel und die Beschränkung auf unterstützte Betriebssysteme schließen Nutzer mit älteren oder kostengünstigeren Geräten sowie alternativen Betriebssystemen von der Nutzung von DiGA aus.
19:23 Daten im Arbeitsspeicher: Die Anforderung, Daten im Arbeitsspeicher zu verschlüsseln, ist technisch anspruchsvoll und ihre Notwendigkeit für einfache Gesundheits-Apps wird hinterfragt.
20:16 Betriebssystemintegrität und Anbieterbindung: Die Forderung nach unmanipulierten Betriebssystemen (Root-Detektion) führt dazu, dass faktisch auf proprietäre Attestierungsmechanismen von Google (Play Integrity) und Apple (App Attestation) zurückgegriffen werden muss, was der behaupteten Technologieneutralität widerspricht.
23:03 Authentifizierungsproblematik: DiGA erfordern aufgrund des hohen Schutzbedarfs von Gesundheitsdaten ein hohes Vertrauensniveau bei der Authentifizierung, was jedoch zu Usability-Problemen führt; Ausnahmeregelungen für ein "substanzielles" Vertrauensniveau sind umstritten. Die GesundheitsID wird als bevorzugter Standard wahrgenommen.
26:16 Konflikt mit DSGVO: Die Akzeptanz niedrigerer Vertrauensniveaus mittels Einwilligung wird als potenziell unvereinbar mit der DSGVO und Beschlüssen der Datenschutzkonferenz (DSK) angesehen, die betonen, dass Grundrechte nicht einfach per Einwilligung aufgegeben werden können.
29:08 Risikobetrachtung: Die Einigung auf eine Risikobetrachtung, die den Schaden nach der Anzahl der betroffenen Personen skaliert (dritte Interpretation), ermöglicht die Akzeptanz unsichererer Authentifizierungsverfahren, was aus Perspektive des Einzelnen zynisch erscheint.
32:09 Fehlende Aspekte der TR161: Es fehlen soziale Anforderungen (z.B. für Menschen mit geringem Einkommen), klare, implementierungsspezifische Anleitungen, Regelungen für den Einsatz von Künstlicher Intelligenz (KI) in Entwicklung und Inhaltserstellung sowie grundlegende Sicherheitsmaßnahmen (E-Mail, Serverkonfiguration, DNS).
36:09 Fehlende Anti-Fingerprinting-Mechanismen: Ein gravierendes Defizit ist das Fehlen von Anti-Fingerprinting-Maßnahmen; DiGA-API-Domains offenbaren häufig die jeweilige Diagnose, wodurch Gesundheitsinformationen indirekt an Dritte (Provider, App Stores) übermittelt werden.
38:00 Barrieren und Diskriminierung: Die derzeitige Regulierung schafft Barrieren und Diskriminierung für Menschen, die sich keine modernen Geräte leisten können oder alternative Betriebssysteme nutzen, was die Teilhabe am Gesundheitssystem einschränkt.
38:56 Verbesserungsvorschläge: Förderung von Webanwendungen statt Apps, neutrale Distributionskanäle ohne Bindung an Google/Apple Accounts und die Nutzung anonymer Authentifizierung per Token statt permanenter Accounts.
41:39 Fazit und Ausblick: DiGA sind grundsätzlich wichtig und hilfreich, aber die Regulierung muss dringend verbessert werden, um Datenschutz, Barrierefreiheit und Rechtssicherheit zu gewährleisten und eine positive Vorbildfunktion für zukünftige Regulierungen zu schaffen.
Glossar
Digitale Gesundheitsanwendung (DiGA): Eine digitale Anwendung, die medizinische Zwecke verfolgt und von Ärzten verschrieben werden kann, wobei die Kosten von Krankenkassen übernommen werden.
BSI (Bundesamt für Sicherheit in der Informationstechnik): Die nationale Cyber-Sicherheitsbehörde Deutschlands, die technische Richtlinien für die IT-Sicherheit entwickelt.
TR161 (Technische Richtlinie 161): Eine spezifische Richtlinie des BSI, die die technischen und organisatorischen Sicherheitsanforderungen für digitale Gesundheitsanwendungen definiert.
BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte): Eine deutsche Bundesoberbehörde, die für die Zulassung und Sicherheit von Arzneimitteln und Medizinprodukten, einschließlich DiGA, zuständig ist.
SGB V (Fünftes Sozialgesetzbuch): Teil des deutschen Sozialrechts, der die gesetzliche Krankenversicherung regelt und die Grundlage für die Erstattungsfähigkeit von DiGA bildet.
DVG (Digitale Versorgung Gesetz): Ein deutsches Gesetz, das die Rahmenbedingungen für die Digitalisierung im Gesundheitswesen schafft, einschließlich der Nutzung und Erstattung von DiGA.
BFDI (Bundesbeauftragter für den Datenschutz und die Informationsfreiheit): Die unabhängige Aufsichtsbehörde in Deutschland für den Schutz personenbezogener Daten und das Recht auf Informationsfreiheit.
Gematik: Die nationale Agentur für digitale Medizin in Deutschland, die die Telematikinfrastruktur und Standards für digitale Gesundheitsanwendungen entwickelt.
Gamsback: Spezifikationen der Gematik für die Telematikinfrastruktur, die technische und semantische Standards für den Datenaustausch im Gesundheitswesen festlegen.
NIST AIS20: Ein Standard des National Institute of Standards and Technology (USA) für Zufallszahlengeneratoren, der die Anforderungen an deren Sicherheit und Qualität festlegt.
RFC (Request for Comments): Eine Reihe von Dokumenten, die technische und organisatorische Themen im Internet beschreiben und oft als Standards dienen.
Entropiepool: Ein Speicher für Zufallswerte (Entropie), der von Betriebssystemen genutzt wird, um sichere Zufallszahlen für kryptografische Zwecke zu generieren.
Hardware Security Modul (HSM): Ein physisches Gerät, das kryptografische Schlüssel sicher speichert und kryptografische Operationen durchführt, um Daten vor unbefugtem Zugriff zu schützen.
Play Attestation / App Attestation: Von Google bzw. Apple bereitgestellte Dienste zur Verifizierung der Integrität eines Geräts und einer App, um Manipulationen zu erkennen.
GesundheitsID: Eine digitale Identität für Bürger im deutschen Gesundheitswesen, die den Zugang zu digitalen Gesundheitsdiensten ermöglichen soll.
DSGVO (Datenschutz-Grundverordnung): Eine Verordnung der Europäischen Union, die den Schutz personenbezogener Daten innerhalb der EU regelt und hohe Anforderungen an die Verarbeitung von Gesundheitsdaten stellt.
Datenschutzkonferenz (DSK): Ein Gremium in Deutschland, in dem sich die Datenschutzbehörden des Bundes und der Länder zur Koordinierung und Beschlussfassung treffen.
Vertrauensniveau hoch/substanziell: Klassifizierungen für die Stärke eines Authentifizierungsverfahrens, wobei "hoch" die höchsten Sicherheitsanforderungen erfüllt und "substanziell" ein geringeres, aber immer noch hohes Niveau darstellt.
Ris' Theorem: Ein Theorem aus der Berechenbarkeitstheorie, das besagt, dass es unmöglich ist, alle nicht-trivialen semantischen Eigenschaften von Programmen algorithmisch zu entscheiden. Im Kontext des Vortrags metaphorisch für die Komplexität der Deaktivierung ungenutzter Codefunktionen.
Penetration Testing (Pentesting): Ein simulierter Cyberangriff auf ein Computersystem, Netzwerk oder eine Webanwendung, um Sicherheitslücken und Schwachstellen zu identifizieren.
S Party Abhängigkeiten (Third-Party Dependencies): Softwarekomponenten oder Bibliotheken, die von externen Anbietern entwickelt und in eine Anwendung integriert werden.
API (Application Programming Interface): Eine Schnittstelle, die es verschiedenen Softwarekomponenten ermöglicht, miteinander zu kommunizieren und Daten auszutauschen.
RUTdetektion (Root Detection): Eine Funktion in Apps, die erkennt, ob ein mobiles Gerät manipuliert (gerootet oder jailbroken) wurde, um die Sicherheit der Anwendung zu gewährleisten.
Antifingerprintingmechanismen: Techniken und Maßnahmen, die darauf abzielen, die Identifizierung und Verfolgung von Nutzern anhand ihrer einzigartigen digitalen Fußabdrücke (Gerätekonfigurationen, Browsereinstellungen etc.) zu verhindern.