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 (DIGA) 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 solche 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 von 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 noch etwas 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
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 Sicherheitsanforderungen an digitale Gesundheitsanwendungen Diese noch im Entwurf befindliche Richtlinie betrifft auch mobile digitale Gesundheitsanwendung im Sinne des § 33a SGB V. Muss (künftig) 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. Soll ein Ampelsystem werden wie der „Energieausweis“ von Elektrogeräten. Soll (künftig) 55
IEC 8001-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 noch in der Entwicklung, ist aber bereits zur Harmonisierung unter der MDR vorgesehen. Soll (künftig) 39
    Summe   645
Tabelle 1: Wichtige Regularien mit Bezug zur Datensicherheit und zum Datenschutz für DIGA (umfassen mehr als 600 Seiten)

 

Weiterführende Informationen

Es gibt noch viele weitere Anforderungen an den Datenschutz und die Datensicherheit. Lesen Sie dazu die Artikel zum Datenschutz im Gesundheitswesen und zur Datensicherheit im Gesundheitswesen.

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

Die 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 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.3 BSI TR-03161

Die Richtlinie BSI TR-03161 beschreibt Sicherheitsanforderungen an digitale Gesundheitsanwendungen. Sie benennt zuerst verschiedene Bedrohungen wie einen Angreifer, der ein Passwort errät. Dann listet die Richtlinie einige allgemeine „Sicherheitspolitiken“; gemeint sind wohl „Security Policies“.

Den Schwerpunkt der Richtlinie bilden die folgenden Prüfaspekte:

  1. Anwendungszweck
  2. Architektur
  3. Quellcodes
  4. Drittanbieter-Software
  5. Kryptographische Umsetzung
  6. Authentifizierung
  7. Datenspeicherung und Datenschutzes
  8. Kostenpflichtige Ressourcen
  9. Plattformspezifische Interaktionen
  10. Netzwerkkommunikation
  11. Resilienz

Zu jedem Prüfaspekt benennt die Richtlinie mehrere Prüfkriterien; Tabelle 2 nennt einige Beispiele.

Prüfaspekt Beispiel
Anwendungszweck „Der Hersteller muss den primären Zweck der Anwendung und die Verwendung von personenbezogenen Daten vor der Installation offenlegen.“
Architektur „Security MUSS ein fester Bestandteil des Softwareentwicklungs- und Lebenszyklus‘ für die gesamte Anwendung sein.“
Quellcode „Nutzereingaben MÜSSEN vor deren Verwendung geprüft werden, um potenziell bösartige Werte vor der Verarbeitung herauszufiltern.“
Tabelle 2: Beispiele für Prüfkriterien des BSI TR-03161

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.

1.4 BSI 200-2

Der BSI Standard 200-2 beschreibt, wie Organisationen ein Informationssicherheits-Managementsystem (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“; 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

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

Basis Kernabsicherung
Abb. 1: Die Basis-Absicherung dient der schnellen Absicherung aller relevanten Geschäftsprozesse. Die Kern-Absicherung fokussiert auf die kritischen „‘Kronjuwelen‘ einer Institution“. Die umfassende Standardabsicherung entspricht dem Niveau des BSI-IT-Grundschutzes.

1.5 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:

  • Informationssicherheits-Managementsystem
    • 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

Firmen, die bereits ein ISO 9001- oder ISO 13485-konformes QM-System etabliert haben, kommen viele Anforderungen sehr bekannt vor. Die größten Unterschiede im Vergleich zu den QM-Normen nennt das 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 Maßnahmenziele und Maßnahmen umfassen. Dieser Anhang ist mit 19 Seiten doppelt so umfangreich wie die Norm selbst.

Vorsicht!

Die ISO 27001 beschreibt die Anforderungen an das ISMS einer Organisation und nicht an ein Produkt wie eine DIGA. Daher kann nur eine Firma, aber keine DIGA nach ISO 27001 zertifiziert sein.

1.6 ISO/IEC 82304-1

Die IEC 82304-1 stellt zwar Anforderungen an die Informationssicherheit; diese gehen aber 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 Informationssicherzeit“ zu gewährleisten. Auch die Anforderungen an die diesbezüglichen Informationen in den Begleitmaterialien sind granularer als z.B. in der MDR.

Weiterführende Informationen

Lesen Sie hier mehr zur IEC 82304.

1.7 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 82304-2 möchte Anwendern mit diesem Siegel eine schnelle Übersicht über die Qualität von „Health and Wellness Apps“ geben.
Abb. 2: Die 82304-2 möchte Anwendern mit diesem Siegel eine schnelle Übersicht über die Qualität von „Health and Wellness Apps“ geben. (Quelle)

Die Norm umfasst im Wesentlichen Checklisten, die denen der DiGAV sehr vergleichbar sind. Eine betrifft „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.8 IEC 80001-5-1

Die IEC 80001-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.9 Weitere Vorgaben

Es gibt noch viele weitere regulatorisch relevante Vorgaben wie die IEC 62443-Familie und die DSGVO.

Vorsicht!

Die Datenschutzbeauftragten der Länder erwägen, die Anforderungen der DSGVO nicht nur von den Organisationen einzufordern, die personenbezogene Daten verarbeiten, sondern auch von den Herstellern, die die dazu notwendigen Systeme entwickeln! Lesen Sie hierzu das Schwerpunkt-Thema 4 ab Seite 15 im Erfahrungsbericht der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder.

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 dass diese in das Verzeichnis erstattungsfähiger DIGAs 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 Produktes 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 somit 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:

  • Verantwortlicher für die Informationssicherheit (z.B. als Stabsstelle des obersten Managements, vergleichbarem 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

 

Tipp

Der Auditgarant enthält eine Serie von Videotrainings, die den Secure Development Life Cycle beschreiben, und Templates für Prozesse, Formulare und Checklisten.

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 Prozess abgedeckt sind
Tipp

Es bedarf jedoch eines Prozesses, der sicherstellt, dass genau diese Integration in bestehende Prozesse stattfindet. Hier bietet sich das Vorgehen gemäß BS 200-2 an.

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 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. Diese Informationen nach Kritikalität klassifizieren.
  • Informationsflüsse und Verarbeitungstätigkeiten beschreiben (Liste der Verarbeitungstätigkeiten gemäß DSGVO)
  • Bestandaufnahme der IT-Systeme ergänzen/aktualisieren
  • Risikoanalyse durchführen. Dabei sollten die Verantwortlichen alle Gefährdungen gemäß BSI-Grundschutzkatalog aufnehmen und Bausteine gemäß diesem Katalog berücksichtigen.
  • Maßnahmen festlegen. Diese Maßnahmen liefert ebenfalls der Grundschutzkatalog pro Baustein, und zwar getrennt für die Basis- und Standard-Anforderungen.
  • Die Vollständigkeit der Maßnahmen anhand der Grundschutzkatalogs überprüfen
  • Maßnahmen umsetzen, u.a. interne Richtlinien festlegen (siehe unten)
Tipp

Der Grundschutz-Katalog schlägt eine Reihenfolge vor, in der die Maßnahmen/Bausteine angegangen werden können.

Ü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)

Solange die DiGAV die ISO 27001 bzw. den BSI-Standard 200-2 nicht zwingend voraussetzt (erst ab 01.01.2021), können die Hersteller mit einer „Dünnbrettbohrer-Variante“ starten:

  1. Kopieren Sie die Anforderungen des Anhangs I in eine Excel-Liste
  2. Klassifizieren Sie diese Anforderungen nach „Produkt-Bezug“, „Prozess-Bezug“ und „Dokumentations- und Informationspflichten“.
  3. Übernehmen Sie alle Anforderungen mit „Produkt-Bezug“ in eine „Software Requirements Checkliste“.
  4. Ergänzen Sie alle Prozesse um die prozessbezogenen Anforderungen.
Weiterführende Informationen

Melden Sie sich (z.B. über unser Webformular), wenn Sie eine Übersicht wünschen, die jeder Anforderung der DiGAV bezüglich Datensicherheit und Datenschutz die zugehörigen Prozesse, die ergänzt werden müssten, bzw. die Checklisten für die Lebenszyklusphasen zuordnet.

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 den 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.

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 noch gar 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.

DIGA-Hersteller müssen sowohl die Anforderungen an ihre Organisation und Prozesse erfüllen als auch die Anforderungen an die Produkte selbst, die DIGA.
Abb. 3: DIGA-Hersteller müssen sowohl die Anforderungen an ihre Organisation und Prozesse erfüllen als auch die Anforderungen an die Produkte selbst, die DIGA.

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 sind 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 den Datenschutz und die IT-Sicherheit, kostet es allerdings auch Geld. Man weiß nur nicht wann und wie viel. 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 klar machen:

„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.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 4.2 / 5. Anzahl Bewertungen: 5

Geben Sie die erste Bewertung!


Kategorien: Regulatory Affairs, Software & IEC 62304

Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.