Wie Sie die Anforderungen an die Datensicherheit und den Datenschutz für DiGA erfüllen

Die Anforderungen an die Datensicherheit und den Datenschutz von DiGA (Digitalen Gesundheitsanwendungen) gehen weit über den Fragenkatalog der DiGAV hinaus. Unzählige weitere Vorschriften machen es den Herstellern (nicht nur) digitaler Gesundheitsanwendungen immer schwerer, den Überblick im regulatorischen Dschungel zu bewahren.

Dabei sollten Hersteller möglichst keine Anforderungen übersehen. Andernfalls drohen Probleme bei der Zulassung ihrer Produkte.

Doch ein Vorgehensmodell schafft Klarheit und hilft nicht nur, Probleme zu vermeiden, sondern auch die Forderungen von Hunderten Seiten an Regularien zu konsolidieren. Dieses Vorgehensmodell können alle Medizinproduktehersteller anwenden, auch jene von SaMD (Software as Medical Device).

1. Regulatorische Anforderungen an die Datensicherheit und den Datenschutz für DiGA

1.1 Überblick über Regularien und Anforderungen

Die Anzahl der Regularien mit Anforderungen an die Datensicherheit und den Datenschutz für digitale Gesundheitsanwendungen ist immens. Tabelle 1 benennt die wichtigsten. Die nachfolgen Abschnitte stellen diese Anforderungen detaillierter vor.

Kürzel	Titel	Kommentare, verpflichtend?	Verbindlichkeit	Seiten
MDR	Medizinprodukte-Verordnung 2017/745	Die EU-Verordnungen bilden den rechtlichen Rahmen für alle Medizinprodukte. Die Anforderungen an die IT-Sicherheit sind sehr allgemein gehalten.	Muss	175
DVG	Digitale-Versorgung-Gesetz	Nur allgemeine Forderung nach Datenschutz und Datensicherheit	Muss	23
DiGAV	Digitale-Gesundheitsanwendungen-Verordnung	Forderungen an Produkt und Organisation v.a. in § 4 und Anlage 1	Muss	31
Prüfkriterien BfArM	Von digitalen Gesundheitsanwendungen (DiGA) und digitalen Pflegeanwendungen (DiPA) nachzuweisende Anforderungen an den Datenschutz (BfArM)	Zentrales Dokument	Muss	80
BSI 200-1	BSI-Standard 200-1, Managementsysteme für die Informationssicherheit	Entspricht am ehesten der ISO 27001	Kann, ist aber Voraussetzung für BSI 200-2	48
BSI 200-2	BSI-Standard 200-2, IT-Grundschutz-Methodik	Die DiGAV verlangt ein Informationssicherheits-managementsystem (ITSM) gemäß BS 200-2 oder gemäß ISO 27001. Der BSI 200-2 beschreibt, wie man ein ITSM einführt.	Muss ab 02.01.2022, alternativ ISO 27001	180
BSI TR-03161 1-3	Sicherheitsanforderungen an digitale Gesundheitsanwendungen	Dieses technische Regelwerk betrifft mobile Anwendungen, Web-Anwendungen und Hintergrundsysteme. Die ersten Zertifizierungsstellen sind akkreditiert (Beispiel TÜVIT).	Muss ab Januar 2025. Hier ist der Ablauf der Zertifizierung etwas genauer beschrieben.	28
ISO 27001:2017	Informationstechnik – Sicherheitsverfahren – Informationssicherheitsmanagementsysteme – Anforderungen	Anforderungen an ein Managementsystem vergleichbar der ISO 9001 und ISO 13485, aber mit Fokus auf IT-Sicherheit	Muss ab 02.01.2022, alternativ: BSI 200-2	35
ISO/IEC 82304-1	Gesundheitssoftware – Teil 1: Allgemeine Anforderungen für die Produktsicherheit	Diese Norm ist zur Harmonisierung unter der MDR vorgesehen.	Soll (künftig)	31
ISO/IEC 82304-2	Health Software – Part 2: Health and wellness apps – Quality and reliability	Diese Norm ist noch in der Entwicklung, könnte aber Stand der Technik werden. Es soll ein Ampelsystem werden (wie beim „Energieausweis“ von Elektrogeräten).	Soll (künftig)	55
IEC 81001-5-1	Safety, security and effectiveness in the implementation and use of connected medical devices or connected health software – Part 5-1: Security – Activities in the product lifecycle	Diese Norm ist gültig und zur Harmonisierung unter der MDR vorgesehen.	Soll (künftig)	39
		Summe		725

1.2 MDR/IVDR

Im Gegensatz zu den EU-Richtlinien adressieren die EU-Verordnungen (die MDR und die IVDR) die Informationssicherheit explizit. Allerdings beschränken sie sich auf nur allgemeine Anforderungen:

• Die Informationssicherheit nach Stand der Technik muss gewährleistet sein.
• Anforderungen an das Produkt bezüglich IT-Sicherheit müssen erhoben sein.
• Gebrauchsanweisungen müssen Anforderungen der Anwender und Betreiber bezüglich Informationssicherheit benennen.

Weitere Anforderungen betreffen u. a. mobile Plattformen, das Risikomanagement und die Software-Entwicklung.

1.3 DiGAV

Anlage 1 der DiGAV nennt Anforderungen in Form von Checklisten. Diese Anforderungen betreffen auch die Datensicherheit und den Datenschutz für DiGA:

Datenschutz

• Konformität mit DSGVO, u. a. Einwilligung, Datenminimierung, Vertraulichkeit, Richtigkeit
• Verschwiegenheit
• Informationspflichten
• Datenschutzmanagement
• Datenschutzfolgeabschätzung
• und mehr

Datensicherheit

• Stand der Technik
• Informationsmanagementsystem gemäß ISO 27000-Reihe oder BSI-Standard 200-2
• Schutzbedarfsanalyse
• Software konform mit der MDR
• „Data Leakage Prevention“, u. a. Verschlüsselung
• Anforderungen an das Produkt, z. B. Authentisierung und Autorisierung, Protokollierung, Härtung
• Installation, Deinstallation, Update
• Dokumentation und Analyse von SOUP
• Penetrationstests
• Schutz vor DoS-Angriffen

1.4 BSI TR-03161

Die Richtlinie BSI TR-03161 beschreibt Sicherheitsanforderungen an digitale Gesundheitsanwendungen. Diese Richtlinie besteht aus drei Teilen:

1. BSI TR-03161 Anforderungen an Anwendungen im Gesundheitswesen – Teil 1: Mobile Anwendungen
2. BSI TR-03161 Anforderungen an Anwendungen im Gesundheitswesen – Teil 2: Web-Anwendungen
3. BSI TR-03161 Anforderungen an Anwendungen im Gesundheitswesen – Teil 3: Hintergrundsysteme

Die drei Richtlinien sind weitgehend identisch aufgebaut:

Kapitel	Teil 1 (Mobile Anwendungen)	Teil 2 (Web-Anwendungen)	Teil 3 (Hintergrundsysteme)	Kommentar
1	Einleitung	Einleitung	Einleitung	Fast identisch
2	Überblick der Sicherheits-anforderungen …	Überblick der Sicherheits-anforderungen …	Überblick der Sicherheits-anforderungen …	Identisch bis auf Kapitel 2.4
3	Prüfaspekte für Anwendungen im Gesundheitswesen	Prüfaspekte für Anwendungen im Gesundheitswesen	Prüfaspekte für Anwendungen im Gesundheitswesen	Weitgehend identisch (s. Tab. 3)
4	Prüfschritte für Anwendungen im Gesundheitswesen	Prüfschritte für Anwendungen im Gesundheitswesen	Prüfschritte für Anwendungen im Gesundheitswesen	Weitgehend identisch
5	Sicherheitsstufen und Risikoanalyse	Sicherheitsstufen und Risikoanalyse	Sicherheitsstufen und Risikoanalyse	Identisch
Anhänge	A: Schutzbedarf sensibler Datenelemente B: Begutachtungs-perspektive C: Anforderung an Authentifizierung und Verifizierung	A: Schutzbedarf sensibler Datenelemente B: Begutachtungs-perspektive	A: Schutzbedarf sensibler Datenelemente B: Begutachtungsperspektive

Alle Teile nennen zuerst verschiedene Bedrohungen, z. B. einen Angreifer, der ein Passwort errät. Dann listen die Richtlinien einige allgemeine „Sicherheitspolitiken“; gemeint sind wohl „Security Policies“.

Den Schwerpunkt der Richtlinie bilden die folgenden Prüfaspekte:

Prüfaspekt	Teil 1	Teil 2	Teil 3
Anwendungszweck	x	x	x
Architektur	x	x	x
Quellcode	x	x	x
Drittanbieter-Software	x	x	x
Kryptografische Umsetzung	x	x	x
Authentifizierung	x	x	x
Datenspeicherung und Datenschutz	x	x	x
Kostenpflichtige Ressourcen	x	x	x
Netzwerkkommunikation	x	x	x
Plattformspezifische Interaktionen	x	x
Resilienz	x	x
Organisatorische Sicherheit			x

Zu jedem Prüfaspekt benennen die Richtlinien mehrere Prüfkriterien; Tabelle 4 nennt einige Beispiele.

Prüfaspekt	Beispiel
Anwendungszweck	„Informationspflicht des Herstellers zum rechtmäßigen Zweck und Verwendung von personenbezogenen Daten“
Architektur	„„Security“ ist Bestandteil des Softwareentwicklungs- und Lebenszyklus.“
Quellcode	„Prüfung von Eingaben vor Verwendung“

Diese Prüfkriterien betreffen sowohl das Produkt als auch die Gestaltung der Prozesse. Die Überprüfung der Nutzereingaben ist eine Anforderung an das Produkt. Die Forderung, dass die Security Bestandteil des Software-Lebenszyklus sein muss, betrifft hingegen die Prozesse.

Die Anforderungen an das Produkt müssen in den Softwareanforderungsspezifikationen berücksichtigt werden. Die Anforderungen an Prozesse müssen in das Managementsystem integriert werden.

1.5 BSI 200-2

Der BSI Standard 200-2 beschreibt, wie Organisationen ein Informationssicherheitsmanagementsystem (ISMS) gemäß BS 200-1 (bzw. ISO 27001) einführen. Dazu enthält der Standard die folgenden Kapitel:

• Übersicht über die wichtigsten Schritte (Kapitel 2)
• Initiierung des „Informationssicherheitsprozesses“ (Kapitel 3)
• Organisationsstruktur (Kapitel 4)
• Notwendige Dokumente (Kapitel 5)
• Vorgehen bei „Basis-Absicherung“ und deren Überprüfung (Kapitel 6)
• Vorgehen bei „Kernabsicherung“ (Kapitel 7) und „Standardabsicherung“ (Kapitel 8)
• Umsetzung aller Maßnahmen (Kapitel 9)
• Aufrechterhaltung und Verbesserung des ISMS (Kapitel 10)
• Zertifizierung nach ISO 27001

Mehr dazu in unserem Artikel „ISO 27001: IT-Sicherheitsmanagement für alle Medizinproduktehersteller?“.

Das BSI beschreibt die drei Varianten der Absicherung (Basis-, Kern- und Standardabsicherung) auf seiner Webseite. Von dort stammt auch die in Abb. 1 gezeigte Darstellung.

1.6 ISO 27001

Die ISO 27001 ist mit 45 Seiten eine sehr kompakte Norm. Der Hauptteil umfasst nur neun Seiten und besteht aus fünf Kapiteln:

• Informationssicherheitsmanagementsystem
  • Allgemeine Anforderungen
  • Festlegung und Verwaltung des ISMS
  • Dokumentationsanforderungen
• Verantwortung des Managements
  • Verpflichtung des Managements
  • Management von Ressourcen
• Interne ISMS-Audits
• Managementbewertung des ISMS
  • Allgemeines
  • Eingaben für die Bewertung
  • Ergebnisse für die Bewertung
• Verbesserung des ISMS
  • Ständige Verbesserung
  • Korrekturmaßnahmen
  • Vorbeugemaßnahmen

Den Firmen, die bereits ein ISO-9001- oder ISO-13485-konformes QM-System etabliert haben, werden viele der Anforderungen bekannt vorkommen. Die größten Unterschiede im Vergleich zu den QM-Normen nennt Kapitel 4.2 (Festlegung und Verwaltung des ISMS). Dort fordert die Norm einen Risikomanagementprozess spezifisch für die IT-Sicherheit des Unternehmens.

Dieser Prozess wiederum muss die im normativen(!) Anhang A genannten Ziele und Maßnahmen umfassen. Dieser Anhang ist mit 19 Seiten doppelt so umfangreich wie die Norm selbst.

1.7 ISO/IEC 82304-1

Die IEC 82304-1 stellt Anforderungen an die Informationssicherheit; diese gehen allerdings kaum über die Anforderungen anderer Regularien hinaus.

Zu den wenigen Ausnahmen zählen die Anforderungen an den Support, „rechtzeitige Patches und Updates bezügliche der Informationssicherheit“ zu gewährleisten. Die Anforderungen an diesbezügliche Informationen in den Begleitmaterialien sind granularer als z. B. in der MDR.

1.8 ISO/IEC 82304-2

Die ISO/IEC 82304-2 wendet sich an Hersteller und Anwender von „Health and Wellness Apps“. Die Norm möchte mit einem Gütesiegel aufwarten, wie man es für die Energieeffizienz von Elektrogeräten her kennt. Dieses Gütesiegel soll jeweils eine Bewertung ausgeben für:

• Medical Safety
• Usability
• Security of Personal Data
• Technical Quality

Die ISO/IEC 82304-2 umfasst im Wesentlichen Checklisten, die denen der DiGAV sehr vergleichbar sind, z. B. zu „Privacy and Security“. Wie bei der DiGAV betreffen die meisten Prüfkriterien das Produkt und die Begleitinformationen, nur einige den Hersteller.

Beispiele für Prüfkriterien an den Hersteller sind die Benennung eines Datenschutzbeauftragten und die Zertifizierung nach ISO 27001.

1.9 IEC 81001-5-1

Die IEC 81001-5-1 trägt den Titel „Safety, security and effectiveness in the implementation and use of connected medical devices or connected health software – Part 5-1: Security – Activities in the product lifecycle“.

Die Norm beschreibt einen Software-Lebenszyklusprozess, der zwar an die IEC 62304 angelehnt ist, allerdings den Fokus auf die IT-Sicherheit legt. Beispiele für spezifische Anforderungen sind:

• Statische Code-Analyse
• Attack Surface Analysis and Reduction
• Fuzz Testing
• Penetration Testing

Die Norm orientiert sich zudem an der IEC 62443-1 und ergänzt die Lebenszyklusprozesse gemäß IEC 62304 um Aspekte wie:

• Dokumentation
• Schutz der Entwicklungsinfrastruktur
• Zeitnahe Auslieferung von Sicherheits-Updates
• Veröffentlichung von IT-bezogenen Problemen
• Kontinuierliche Verbesserung des „Security Lifecycle Process“

1.10 Weitere Vorgaben

Es gibt weitere regulatorisch relevante Vorgaben, z. B. die IEC 62443-Familie und die DSGVO.

2. Vorgehensmodell für DiGA-Hersteller

2.1 Vorteile eines Vorgehensmodells

Ein strukturiertes Vorgehen kann sicherstellen, dass die Hersteller

1. sichere Medizinprodukte entwickeln und sicher betreiben,
2. die (oben vorgestellten) Anforderungen an die Datensicherheit und den Datenschutz für DiGA erfüllen,
3. die Zulassung ihrer Produkte plangemäß erhalten und dafür sorgen, dass diese in das Verzeichnis erstattungsfähiger DiIGAs aufgenommen werden,
4. Aufwände für die Einarbeitung, für das Gestalten von Prozessen und Vorgabedokumenten sowie für das Erstellen von Projektplänen minimieren.

2.2. Schritt 1: Rahmenbedingungen klären

Zuerst sollten die Hersteller die Zweckbestimmung ihres Produkts festlegen, denn daraus leiten sich viele Entscheidungen und Klassifizierungen ab:

• Medizinprodukt: ja/nein
• Klasse nach MDR/IVDR
• Software-Sicherheitsklasse
• Schutzbedarf gemäß DiGAV bzw. BSI 200-2

Der Schutzbedarf ergibt sich allerdings erst aus einer Risikoanalyse. Diese wiederum setzt voraus, dass die Hersteller bestimmt und bewertet haben:

• Schutzbedürftige Assets (Daten, Systeme)
• Prozesse
• Verarbeitungstätigkeiten
• Technische Infrastruktur, IT-Systeme, Netzpläne
• Cloud- bzw. Software-Architektur
• Aufteilung der Tätigkeiten auf die Firma und auf Lieferanten bzw. Auftragsverarbeiter

Eine Bestandsaufnahme dieser Elemente stellt eine zentrale Voraussetzung für die weiteren Schritte dar.

Ebenfalls in dieser frühen Phase sollten die Hersteller die Zielmärkte und damit die geltenden regulatorischen Anforderungen bestimmen.

2.3 Schritt 2: Integriertes Qualitäts- und Informationssicherheitsmanagementsystem etablieren

Sowohl ein QM-System als auch ein ISMS ist ein Managementsystem. Weil es viele Parallelen und Redundanzen bei den Anforderungen gibt, empfiehlt es sich, ein integriertes Managementsystem zu etablieren. Solch ein Managementsystem muss die Anforderungen der ISO 13485 ebenso erfüllen wie die der BSI-Standards bzw. der ISO 27001.

Wie bei jedem Managementsystem gilt es, die Aufbau- und Ablauforganisation zu beschreiben.

Die Aufbauorganisation legt beispielsweise fest:

• Verantwortliche für die Informationssicherheit (z. B. als Stabsstelle des obersten Managements, vergleichbar dem Qualitätsmanagementbeauftragten)
• Organisationseinheiten, Geschäftsbereiche, Zuständigkeiten

Die Ablauforganisation beschreibt die Prozesse innerhalb des Unternehmens. Hersteller erstellen dazu Vorgabedokumente, z. B.:

• Prozessbeschreibungen, Standard Operating Procedures (SOPs)
• Arbeitsanweisungen
• Formulare
• Checklisten

Es gibt zahlreiche Prozesse mit Bezug zur Informationssicherheit:

Prozess	Beispiele für Aktivitäten mit Bezug zur Informationssicherheit
Entwicklung	U. a. Secure Development Life Cycle (s. Hinweise zum Auditgarant) Umgang mit SOUP-Komponenten Beherrschung von IT-sicherheitsbezogenen Risiken Verfassen von Begleitmaterialien (z. B. Installations- und Gebrauchsanweisungen)
Produktion, Rechenzentrumsbetrieb	Feststellen des Schutzbedarfs, Modellierung Auswahl, Instandhaltung und Überwachung der Infrastruktur Installations- und Konfigurationsanleitungen Inventarisierung und Überwachung von Assets Festlegen von Sicherheitszonen und Zutrittskontrollen – Datensicherung, Recovery
Interner IT-Support	Inventarisierung und Überwachung von Assets Umgang mit Verlust Benutzerverwaltung, Vergabe von Berechtigungen und deren fortlaufende Überwachung
Computerized Systems Validation	Überprüfung der Systeme auf IT-Sicherheit Überprüfung der korrekten Konfiguration und Rollenvergabe
Human Ressource Management	Auswahl, Sicherstellung der Kompetenz Vertragsgestaltung Onboarding, Einarbeitung, Datenschutzbelehrungen (z. B. Internet-Nutzung, Verhalten bei Zwischenfällen) Weiterbildung, Überprüfung der Kompetenz Offboarding, Entzug von Berechtigungen, Rückgabe von Assets
Post-Market Surveillance	Überwachung von IT-Sicherheitsdatenbanken Monitoring der SOUP-Hersteller Überwachung der eigenen Infrastruktur
Einkauf	Anforderungen an Lieferanten Anforderungen an beschaffte Produkte Wareneingangsprüfung
Support, Umgang mit Kundenbeschwerden	Auskünfte gemäß DSGVO Umgang mit Anträgen (z. B. zum Ändern und Löschen von Daten)
CAPA und Vigilanz	Verhalten bei Sicherheitsvorfällen Meldungen an Datenschutzbehörden
Managementbewertung	Überprüfung der Wirksamkeit des Managementsystems Bewertung neuer regulatorischer Anforderungen Bewertung neuer Trends (Technologien, Sicherheitsprobleme) Entscheidung, ob weitere Ressourcen oder andere Maßnahmen wie die Überarbeitung des QM-Systems, Schulungen oder andere Technologien notwendig sind
Internes Audit	Überprüfung der eigenen Prozesse Interne Revision Ggf. Security-Audits von Lieferanten
Dokumentenlenkung	Ggf. Klassifikation des Schutzbedarfs Hinweise zur Lebensdauer und Vernichtung Vorgaben zum Schutz der Informationen

Hersteller sollten beide Ansätze wählen, um ihre Prozesse zu gestalten:

1. Bestehende Prozesse daraufhin prüfen, ob sie Tätigkeiten enthalten, die einen Bezug zur IT-Sicherheit und zum Datenschutz aufweisen
2. Gesetze und Normen durchgehen und prüfen, ob Tätigkeiten vorgeschrieben sind, die noch durch keinen der bestehenden Prozesse abgedeckt sind

Der Hersteller muss im Handbuch des integrierten Managementsystems dessen Anwendungsbereich erweitern und darin alle Prozesse referenzieren. Darin sollten auch der Schutzbedarf und die Sicherheits-/Schutzziele formuliert sein.

Typische Aktivitäten beim Aufbau eines ISMS sind:

• Festlegen des Beauftragten für die Informationssicherheit und Beschreibung dessen Rolle mit Aufgaben, Rechten und Verantwortlichkeiten. Diese Rolle kann in kleinen Firmen von der Person übernommen werden, die auch die Rolle des Datenschutzbeauftragen übernimmt. Die Rolle kann aber nicht durch den IT-Leiter oder den internen Auditor besetzt werden. Ggf. muss der Hersteller auf externe Ressourcen zugreifen.
• Übersicht über Informationen/Daten erstellen und diese Informationen nach Kritikalität klassifizieren
• Informationsflüsse und Verarbeitungstätigkeiten beschreiben (Liste der Verarbeitungstätigkeiten gemäß DSGVO)
• Bestandsaufnahme der IT-Systeme ergänzen/aktualisieren
• Risikoanalyse durchführen. Dabei sollten die Verantwortlichen alle Gefährdungen gemäß BSI-Grundschutz-Kompendium aufnehmen und Bausteine gemäß diesem Katalog berücksichtigen.
• Maßnahmen festlegen. Diese Maßnahmen liefert ebenfalls das Grundschutz-Kompendium pro Baustein, und zwar getrennt für die Basis- und Standard-Anforderungen.
• Die Vollständigkeit der Maßnahmen anhand des Grundschutz-Kompendiums überprüfen
• Maßnahmen umsetzen, u. a. interne Richtlinien festlegen (siehe unten)

Übliche Richtlinien sind meist Vorgabedokumente wie Prozess- und Arbeitsanweisungen, z. B.:

• Richtlinien zur Nutzung des Internets
• Vorgaben zum Verhalten bei Sicherheitsvorfällen (Katastrophenplan, einzelne Arbeitsanweisungen, interne Informations- und Eskalationskaskade, Behördenmeldungen)
• Installationsanweisungen, Konfigurationsanweisungen
• Test- und Freigabeverfahren (auch bei Änderungen)
• Vorgaben zur Klassifizierung und zum Zugriff auf Dokumente und Daten
• Vorschriften zum Backup und Datensicherung
• Auditpläne
• Schulungsunterlagen
• Software-Entwicklungsprozess (siehe Baustein CON)

2.4 Schritt 3: Produkt gemäß diesem QM-/ISMS entwickeln und Betriebsinfrastruktur etablieren

Wenn das integrierte Managementsystem steht, wird es gelingen, die Anforderungen an die Datensicherheit und den Datenschutz für DiGA systematisch zu erfüllen.

Hersteller, die den Vorgaben des eigenen QM-/ISMS folgen, erzeugen automatisch die von Regularien wie der MDR und der DiGAV geforderten Nachweisdokumente.

2.5 Schritt 4: Produkt als Medizinprodukte „zulassen“

Für DiGA der Klasse I dürfen die Hersteller die Konformität ohne Einbeziehung einer Benannten Stelle selbst erklären. Bei DiGA der Klasse IIa müssen sie eine Benannte Stelle beteiligen, die sowohl das QM-System zertifiziert als auch die technische Dokumentation für das Produkt prüft.

Derzeit erlaubt das Digitale-Versorgung-Gesetz keine DiGA der Klassen IIb und III.

Unabhängig von der Klasse müssen die Hersteller ihre Medizinprodukte registrieren, derzeit bei den Mitgliedstaaten, künftig in der EUDAMED.

2.6 Schritt 5: Antrag auf Aufnahme in das DiGA-Verzeichnis stellen

Wenn die DiGA als Medizinprodukte registriert sind, können die Hersteller die Aufnahme in das DiGA-Verzeichnis beantragen. Welche Schritte Sie dazu gehen müssen, zeigen wir Ihnen in unserem Artikel „In 7 Schritten ins DiGA-Verzeichnis“.

3. Fazit, Zusammenfassung

3.1 (Zu) viele Anforderungen

„Es reicht! Bitte keine weiteren Vorgaben!“, ist man versucht zu rufen. Hersteller stehen vor einem Berg von über 600 Seiten an Vorgaben nur zum Datenschutz und zur Datensicherheit. Viele Normen und Standards wie die Normenfamilie ISO 20000 (IT Service-Management) und IEC 62443 sind dabei noch nicht eingerechnet.

Neben den Anforderungen an die Datensicherheit und den Datenschutz für DiGA müssen deren Hersteller auch weitere Anforderungen erfüllen und die entsprechenden Hürden überwinden.

3.2 Konsolidierung tut Not

Hersteller benötigen keine weiteren Vorgaben, denn diese schaffen keine zusätzliche Sicherheit. Vielmehr ist eine Konsolidierung dieser Anforderungen notwendig. Das Johner Institut empfiehlt, diese Anforderungen zu unterteilen in:

• Produktbezogene Anforderungen auf Ebene der
  • Zweckbestimmung und Stakeholder-Anforderungen
  • Produkt-/Software-Anforderungen
  • Anforderungen an die Architektur und Wahl von Technologien
• Prozessbezogene Anforderungen, z. B. an die Software-Entwicklung und den Rechenzentrumsbetrieb
• Anforderungen an die Informationen, die die Hersteller den Anwendern, Betreibern und Dritten bereitstellen müssen

Allerdings ist diese Konsolidierung und die Einteilung der Anforderungen in die Klassen nicht einfach. Denn die regulatorischen Vorgaben unterscheiden sich in ihrem Anwendungsbereich:

• Spezifisch vs. unspezifisch für das Gesundheitswesen
• Anwendbar für DiGA, Medizinprodukte oder „Health and Wellness Applications“
• Anforderungen an Produkte vs. Prozesse bzw. Managementsysteme
• Fokus auf IT-Security und Datenschutz oder auch auf Safety

3.3 Der Fisch stinkt vom Kopf

Selbst wer den Leidensweg durch 600 Seiten Anforderungen auf sich nimmt, wird ohne die Unterstützung des Managements scheitern. Datenschutz und IT-Sicherheit kosten Zeit und Geld. Ignoriert man beides, kostet das allerdings auch Geld. Die Strafen und der mögliche Imageverlust sind immens.

Daher bleibt der Leitungsebene nichts anderes übrig, als diese Ressourcen bereitzustellen.

Das Management darf auch nicht dem Irrtum unterliegen, es könne das Thema an den Datenschutzbeauftragten auslagern. Denn die Anforderungen an die Datensicherheit und den Datenschutz für DiGA betreffen die ganze Organisation und deren Lieferanten.

Trotz aller Regularien sollte man sich immer klarmachen:

„Die umfangreichen Informationen rund um IT-Grundschutz ersetzen nicht den gesunden Menschenverstand.“

BSI 200-2

---

Das Johner Institut unterstützt Hersteller von DiGA dabei, die regulatorischen Anforderungen zu erfüllen und ihre Produkte konform und sicher durch die Zulassung und in das DiGA-Verzeichnis zu bringen und so im Markt erfolgreich zu sein.

Änderungshistorie

• 2023-03-13: Das Kapitel 1.4 zum BSI TR 03161 komplett überarbeitet, um die Aufteilung in drei Richtlinien darzustellen.
• 2023-02-06: Ergänzung der BSI TR-03161 1-3 bei den regulatorischen Anforderungen
• 2023-01-27: Artikel aktualisiert
• 2021-02: Zahlreiche Links auf BSI-Webseite nach deren Umbau aktualisiert