Mit die MPBetreibV von Februar 2025 werden Gesundheitseinrichtungen in Bezug auf Software als Medizinprodukt und Software als In-vitro-Diagnostikum mit neuen Pflichten konfrontiert: §17 fordert die Prüfung einer ordnungsgemäßen Installation und eine IT-Sicherheitsüberprüfung. Weitere Punkte wie Nutzereinweisung waren schon zuvor präsent – ergänzend werden nun Einweisung nach jeder Installation von Softwareaktualisierungen gefordert. Außerdem wird der Umfang der Einweisung der „vom Betreiber beauftragten Person“ in einigen Punkten konkretisiert. Die Anforderungen gehen weit über reine Technik hinaus und beeinflussen künftig Schulungen, Prozesse und Verantwortlichkeiten in jeder Gesundheitseinrichtung.
IT-Sicherheitsüberprüfung
Für Software als Medizinprodukt der Klassen IIb und III und Software als In-vitro-Diagnostikum der Klassen C und D müssen „angemessene IT-Sicherheitsüberprüfung nach den allgemein anerkannten Regeln der Technik“ durchgeführt werden. Dabei sollen Risiken und Leistungsbeeinträchtigungen frühzeitig erkannt und „soweit wie möglich“ verringert werden. In der Praxis werden identifizierte risikomindernde Maßnahmen bewerten und vor Umsetzung sorgfältig abgewogen, wie erfolgversprechend und sinnvoll sie sind. Dabei werden neben der Zweckmäßigkeit auch wirtschaftliche Überlegungen einbezogen.
Eine weitere Herausforderung ist die Aufgabenkoordination zwischen Medizintechnik, IT und den Anwendern der Produkte sowie die Identifikation aller in Betrieb befindlichen Software, bei der es sich um ein Medizinprodukt oder In-vitro-Diagnostikum der genannten Klasse handelt. Während Systeme wie PDMS und Medikation der IT und Medizintechnik sehr präsent sind, gibt es in Fachabteilungen weitere, teils auch lokal installierte Produkte: beispielsweise Software im Zusammengang von kardiologischen Implantaten.
Der genaue Umfang der IT-Sicherheitsüberprüfung ist gesetzlich nicht spezifiziert, soll sich aber an den anerkannten Regeln der Technik orientieren. Es ist daher naheliegend, den BSI IT-Grundschutz und/oder den MDS2 („Manufacturer Disclosure Statement for Medical Device Security“) heranzuziehen. Das MDS2-Formular dürfte bei vielen Medizinprodukteherstellern bekannt sein, ist er doch ein anerkanntes Verfahren, mit dem die Hersteller die Eigenschaften der IT-Sicherheit ihrer Produkte dokumentieren können bzw. in den USA häufig im Rahmen von Beschaffungsprozessen sogar müssen. Hier aber genau liegt das Problem: der MDS2 ist nicht dafür konzipiert, ein Audit einer bestehenden Softwareinstallation durchzuführen, sondern mit ihm werden die grundsätzlichen Eigenschaften eines Medizinprodukts in Bezug auf die IT-Sicherheit dokumentiert. Er kann als Leitfaden herangezogen werden, um die tatsächlichen Eigenschaften der IT-Sicherheit der bestehenden Installation zu überprüfen. Wird beispielsweise im MDS2 dokumentiert, dass es kein Rollen-Rechte-Konzept gibt (Nutzern keine Rollen zugewiesen werden können), braucht dieses in der konkreten Installation auch nicht überprüft werden. Wird hingegen umgekehrt im MDS2 die Möglichkeit der Konfiguration eines Rollen-Rechte-Konzepts oder sogar der AD-Anbindung angegeben, so würde bei der IT-Sicherheitsüberprüfung im Themenfeld der Nutzerauthentifizierung die konkrete Ausgestaltung geprüft werden.
Trotz seines Umfangs (240 einzelner Items in 23 verschiedenen Themenfeldern) deckt der MDS2 nicht alle Anforderungen des BSI IT-Grundschutzes ab. Auch wenn der Informationsverbund das Krankenhaus ist, so gibt es doch noch eine Vielzahl an Anforderungen aus dem IT-Grundschutz, die durch Medizinprodukte erfüllt werden müssen bzw. sollten. Da die Krankenhäuser verpflichtet sind, ein Informationssicherheitsmanagement (ISMS) nach §391 SGB V einzuführen, spielen in Deutschland der B3S und IT-Grundschutz eine zentrale Rolle. Allerdings umfasst der IT-Grundschutz mehr als 2.000 Items, viele davon sind gar nicht auf das Medizinprodukt sondern auf den Informationsverbund Krankenhaus anzuwenden.
Angesichts der Tatsache, dass es bereits jetzt mehr als genügend Aufgaben für die IT und Medizintechnik gibt, wird aber nicht ein Vorgehen mit noch mehr zu prüfenden Items benötigt, sondern ein möglichst schlankes Verfahren. Aufgrund einer Vielzahl an Projekten im Bereich des Risikomanagements nach DIN EN ISO 80001-1 haben wir bei Synagon aus dem IT-Grundschutz heraus alle auf Medizinprodukte anwendbaren Items extrahiert und diese Liste mit dem MDS2 abgeglichen bzw. ergänzt. Regelmäßig nutzen wir diese Liste, um die Eigenschaften bezüglich IT-Sicherheit bei Medizinprodukten abzufragen. Das Ergebnis wird in Form einer Risikoanalyse ausgewertet. Dabei werden Maßnahmen zur Risikoreduktion identifiziert, falls einzelne Anforderung an die IT Sicherheit nicht durch das Produkt selbst erfüllt werden, und sich daraus ein Risiko in der konkreten Betriebsumgebung ergibt. Aufgrund der Vielzahl an Projekten haben sich daraus 5 immer wiederkehrende Themenfelder herauskristallisiert.
Bei der Risikobetrachtung muss zwingend die Betriebsumgebung und der Kontext der Anwendungsfälle betrachtet werden. Wie schon bei Risikoanalysen für MIT-Systemen zeigt sich: Während Maßnahmen rein aus Sicht der IT- und Informationssicherheit als selbstverständlich und entsprechen den „best practices“ erscheinen, können aus Sicht der medizinischen Anwender triftige Gründe gegen die Umsetzung möglicher risikominimierender Maßnahmen sprechen. Beispielsweise kann eine Bildschirmsperre oder ein Auto LogOff aus Sicht der IT-Sicherheit und aus Datenschutz-Sicht hilfreich sein. Wenn das notwendige Gerät allerdings für Notfälle kurzfristig verfügbar sein muss, kann eine Bildschirmsperre oder ein Auto LogOff als Sicherheitsmechanismus in einzelnen Nutzungsbereichen aus medizinischer Sicht für den Patienten kritisch sein.
Unterstützende Dokumentation und Stand der Technik
Bereits existierende Risikomanagement-Akten nach DIN EN ISO 80001-1 können die Durchführung von IT- Sicherheitsüberprüfung deutlich beschleunigen. Auf die darin enthaltene Systemdokumentation, Eigenschaften der Komponenten und die konkrete Systemkonfiguration kann aufgesetzt werden. Auch berücksichtigt eine Risikoanalyse und -bewertung nach DIN EN ISO 80001-1 insgesamt drei Schutzziele, darunter auch die Security:
- „Sicherheit“ (Safety)
(Freiheit von unvertretbaren Risiken der physischen Verletzung oder der Schädigung der Gesundheit von Menschen oder der Schädigung von Eigentum oder der Umwelt“. Gilt für „Patienten, Bediener und Dritte“.
- „Effektivität“ (Effectiveness)
Wirksamkeit eines medizinischen IT-Netzwerkes im Hinblick darauf gemeint, dass die Daten im Netzwerk unverfälscht und rückwirkungsfrei zur rechten Zeit am Zielort sind, um die angestrebten Abläufe zu erreichen“. Das schließt die Qualitätsziele des Krankenhauses mit ein, bezogen auf den vernetzten Betrieb von Medizinprodukten. - „Daten- und Systemsicherheit“ (Security).
Potenziell wurden bei Durchführung einer Risikoanalyse und -bewertung auch die Beiträge von Herstellern zum IT-Grundschutz nach BSI bewertet.
Herstellerangaben nach MDS2 (Manufacturer Disclosure Statement for Medical Device Security, standardisiertes Formular) unterstützen auch bei der IT-Sicherheitsüberprüfung. Die Angaben stellen allerdings stets nur die theoretischen Möglichkeiten des Produktes dar – das konkret installierte Produkt kann je nach realisierten Features davon abweichen! Entsprechend müssen Details für das realisierte und zu betrachtende Produkt genauer hinterfragt werden.
Generell ist der Umfang der vom Hersteller zur Verfügung gestellten Begleitdokumentation & Services sehr unterschiedlich. Einige Hersteller stellen neben Angaben nach MDS2 und der Gebrauchsanweisung bereits umfassende Hinweise zur Cybersecurity und eine Software Bill of Materials (SBOM) bereit. Auch Dienstleistungen zum Thema Updates & Patches gehören inzwischen zum Standard. Und Meldungen, welche die Safety betreffen, müssen gemäß gesetzlichen Regelungen an Betreiber kommuniziert werden. Hinweise in Bezug auf Cybersecurity und über mögliche Updates etc. werden oftmals allerdings nur an Gesundheitseinrichtungen kommuniziert, wenn ein Servicevertrag besteht.
Weitere relevante Punkte zur Durchführung und Dokumentation einer IT-Sicherheitsprüfung liefert die DIN EN IEC 81001-5-1 (DIN EN IEC 81001-5-1 Gesundheitssoftware und Gesundheits-IT-Systeme Sicherheit, Effektivität und Security – Teil 5-1: Security – Aktivitäten im Produktlebenszyklus). Zwar ist die Norm noch nicht harmonisiert unter MDR und somit nicht verpflichtend, kann aber als „Stand der Technik“ angesehen werden und liefert gute Ansätze zur Security im den gesamten Produktlebenszyklus. (Die ursprünglich geplante Harmonisierung 2024 wurde verschoben auf Mai 2028.) Folgende Aspekte werden unter anderem genannt, sollten intern vom Hersteller berücksichtigt werden und sich zukünftig teils auch in der Begleitdokumentation wiederfinden:
- Leitlinien sicherer Betrieb
- Leitlinien Kontenverwaltung
- Leitlinien für die Härtung des Produktes
- Informationen zu Restrisiken für die IT-Sicherheit
- Software-Stückliste (software bill of material, SBOM). Die SBOM ist bereits heute verpflichtend durch die Hersteller zu erstellen und ermöglicht es Betreibern, die Umgebung des IT-Sicherheitsrisikos zu überwachen.
- Dokumentation des Sicherheitsumfeldes des Produktes
(Die Dokumentation dieser externen IT-Sicherheitseigenschaften für das Produkt ermöglicht es Prüfern, die IT-Sicherheit eines Produkts in einer Umgebung zu validieren und zu verifizieren, die derjenigen ähnelt, in der es bereitgestellt werden soll. Potenziell handelt es sich bei der Dokumentation des Sicherheitsumfeldes des Produktes teilweise um Herstellerinterne Informationen und sollte bereits bei der „ordnungsgemäßen Installation“ durch den Hersteller geprüft werden.) - Mechanismus oder Technik, die es Anwendern ermöglicht, die Authentizität von Patches zu verifizieren
- Dokumentation über Produktsicherheitsupdates
- Verifizierung der Integrität von IT-Sicherheits-Updates (diesbezügliche Aktivitäten des Herstellers, anwendbare Update in einer Weise zur Verfügung zu stellen, dass eine Verifizierung der Integrität des IT-Sicherheits-Updates ermöglicht wird)
- Verifizierung der Integrität von Skripten, ausführbaren Dateien und anderer für die IT-Sicherheit relevanten Dateien
Ordnungsgemäße Installation
Nach MPBetreibV §17 Abs. 1 wird auch die Prüfung einer ordnungsgemäßen Installation für Software als Medizinprodukt der Klassen IIb und III und Software als In-vitro-Diagnostikum der Klassen C und D gefordert. Üblicherweise kann dies mit Unterstützung des Herstellers/Dienstleisters durchgeführt und dokumentiert werden. Dafür ist nicht zwingend ein Vor-Ort-Termin nötig. Die Prüfung der ordnungsmäßen Installation kann auch mittels Fernzugriff erfolgen.
Synagon empfiehlt Betreibern, die zugehörige Dokumentation der Prüfung einer ordnungsgemäßen Installation nach MPBetreibV §17 Abs. 1 beim Hersteller/Dienstleister einzufordern und nötigenfalls ein Formular zur Dokumentation und Bestätigung der Durchführung bereitzuhalten.