Gemeinsam mit dem TÜV SÜD, dem TÜV Nord und mit Unterstützung von Dr. Heidenreich (Siemens) hat das Johner Institut am 21.11. einen Leitfaden zur IT-Sicherheit speziell für Medizinproduktehersteller veröffentlicht.
An wen sich der Leitfaden zur IT-Sicherheit wendet
Der Leitfaden richtet sich an alle Hersteller von Medizinprodukten (Inverkehrbringer, Dienstleister). Er sollte v.a. gelesen werden von:
- System-/Software-Entwickler und Architekten
- (Software-)Tester
- Produktmanager
- Qualitätsmanager
- Regulatory Affairs Manager
Er wendet sich explizit auch an Auditoren, „Reviewer“ von technischen Dokumentationen und an Behörden.
Betreiber wie Krankenhäuser sollten den Leitfaden zur IT-Sicherheit zumindest dann berücksichtigen, wenn sie selbst Medizinprodukte konfigurieren oder gar herstellen.
Wo es den Leitfaden zur IT Security gibt
Der Leitfaden steht kostenfrei zum Download bereit:
- Die „offizielle“ Version findet sich als Markdown-Dokumente im Git-Repository „IT Security Guideline“ (deutsch und englisch)
- Auf den Seiten des Johner Instituts im Word und Excel-Format (zum schnelleren Sortieren und Weiterverarbeiten – ebenfalls auf Deutsch und Englisch)
Möchten Sie wissen, wie Sie Ihre IT-Systeme sicherer machen können? Die Expertinnen und Experten des Johner Instituts beraten Sie gern!
Was den Leitfaden auszeichnet
Die Autoren haben beim Schreiben folgende Ziele verfolgt:
- Die Anforderungen sind leicht verständlich.
- Die Überprüfung, ob diese Anforderungen erfüllt sind, gelingt unstrittig.
- Die Anforderungen sind erfüllbar und sinnvoll und damit der IT Sicherheit dienlich.
- Sie sind – soweit notwendig und möglich – spezifisch für Medizinprodukte.
- Die Anforderungen reflektieren den Stand der Technik.
- Herstellern gelingt es damit einfach, Verfahrens- und Arbeitsanweisungen ebenso abzuleiten wie Produktspezifikationen.
Aufbau und Struktur des Leitfadens
Der Leitfaden zur IT-Sicherheit umfasst ca. 150 Anforderungen. Diese sind nach Prioritäten und nach Lebenszyklusphasen sortiert.
Lebenszyklusphasen
Der Leitfaden zur IT Security ist wie folgt in Kapitel gegliedert:
- Anforderungen an die Prozesse
- Anforderungen an den Entwicklungsprozess
- Zweckbestimmung und Stakeholder-Anforderungen
- System- und Software-Anforderungen
- System- und Software-Architektur
- Implementierung und Erstellung der Software
- Bewertung von Software-Einheiten
- System- und Software-Tests
- Produktfreigabe
- Anforderungen an die der Entwicklung nachgelagerten Phase
- Produktion, Distribution, Installation
- Marktüberwachung
- Incident Response Plan
- Anforderungen an den Entwicklungsprozess
- Anforderungen an das Produkt
- Vorbemerkungen und allgemeine Anforderungen
- System-Anforderungen
- System- und Software-Architektur
- Begleitmaterialien
Die Anforderungen an die Prozesse sollten in entsprechenden Verfahrensanweisung Niederschlag finden, die Anforderungen an das Produkt in den Produktspezifikationen.
Prioritäts-Stufen
- Stufe 0 („Laien-Niveau“)
Selbst die meisten Laien würden diese Anforderung erfüllen. Wer nicht einmal die Anforderungen dieser Stufe erfüllt, sollte keine Medizinprodukte entwickeln. Diese Anforderungen darf und muss ein Auditor bereits im allerersten Audit als erfüllt erwarten. - Stufe 1 (Niveau „fortgeschrittener Anfänger“)
Der Hersteller hat sich des Themas IT-Sicherheit bereits angenommen. Bei unkritischeren Produkten und den ersten Audits kann dieses Niveau akzeptiert werden. In jedem Folgejahr wird jedoch eine Verbesserung erwartet, bis die Stufe 2 erreicht wird. - Stufe 2 („State-of-the-art“)
Das ist das Niveau, das Hersteller auf Dauer in der Regel erreichen müssen. Es entspricht aber noch nicht dem Stand der Wissenschaft. - Stufe 3 („Experten-Niveau“)
Dieses Niveau erreichen hauptberufliche IT-Security-Experten. Es geht über das hinaus, was ein Auditor in der Regel bei Medizinprodukten erwarten darf. Energieversorger, Geheimdienste und das Militär müssten auf diesem Niveau agieren.
Weshalb es eines Leitfadens zur IT-Sicherheit bedarf
Es gibt zahlreiche Gründe, die die Autoren dazu geführt haben, den Leitfaden zu erstellen:
- Die EU-Verordnungen (MDR, IVDR) fordern explizit die IT-Sicherheit. Im Gegensatz zu den meisten anderen grundlegenden Anforderungen sind keine Normen zum Thema IT-Sicherheit harmonisiert. Daher gibt es keinen kanonischen Katalog an Anforderungen, der anerkannt den geforderten Stand der Technik reflektiert.
- Aus diesem Grund haben Auditoren sehr heterogene Erwartungen, und Risiko steigt für Hersteller, im Audit oder bei der Einreichung von Unterlagen auf Probleme zu stoßen.
- Viele Normen sind kostenpflichtig (trotz teilweise fragwürdiger Qualität). Hersteller müssen nach Auffassung der Autoren kostenfrei Zugang zu regulatorischen Anforderungen haben.
- Hersteller entwickeln immer mehr vernetzte Medizinprodukte. Dadurch erhöhen sich die Risiken durch mangelnde IT-Sicherheit (z.B. gegen Cyberangriffe). Dem tragen viele Hersteller nur unzureichend Rechnung.
- Für die meisten Hersteller wäre es weder zeitlich noch finanziell umsetzbar, mit einem Schlag ein IT-Sicherheits-Niveau zu erreichen, wie es z.B. der UL 2900 fordert. Daher sollten die Hersteller schrittweise ein State-of-the-Art Niveau bezüglich der IT-Sicherheit anstreben und erreichen. Damit verfolgt dieser Leitfaden das Ziel, lieber schnell erste Verbesserungen umzusetzen, als wegen Überforderung nichts zu tun.
Es ist zu erwarten, dass Normen zur IT-Sicherheit von Medizinprodukten entwickelt und harmonisiert werden, was aber noch Jahre in Anspruch nehmen kann. Daher bedarf es eines Leitfadens (nur) in dieser Zwischenphase.
Eine vollständige Übersicht über die Erwägungsgründe finden sich am Ende des Dokuments.
Wie es weitergeht
Langfristig (3-5 Jahre?) hoffen die Autoren, dass harmonisierte Normen den IT-Security-Leitfaden überflüssig machen. Solange wird dieser weitergepflegt. Dazu ist jeder eingeladen. „Motzen“ hilft nichts, mitmachen ist gefragt. Wir freuen uns auf Ihre Unterstützung, melden Sie sich gerne z.B. bei den Autoren (z.B. beim Johner Institut).
Danke für den Leitfaden. In dem jetztigen Leitfaden sind einige kleiner Fehler oder Unklarheiten enthalten:
Was bedeutet z.B. „Stufe 1“ aber „Bei unkritischen Produkten ist die Stufe 2 vertretbar“
(C.2.a.4) „Der Hersteller hat Verfahren etabliert, die gewährleisten, dass er mit den Betreibern und Anwendern seiner Produkte zeitnah
kommunizieren kann“
Auch sind Kommentare wie „Ditto“ wenig hilfreich, wenn man mit einer gefilterten Liste arbeitet und ggf damit die vorhergende Zeile nicht mehr sieht.
Wird es in häherer Zukunft eine leicht überarbeitet Version geben oder ein Abgleich mit der Handlungsanweisung für benannten Stellen?
Sehr geehrter Herr Thiemann,
ich freue mich über Ihre Verbesserungsvorschläge!
Wäre es denkbar, dass Sie hier ein Issue erzeugen? Ich sehe gerade, dass es dort noch alte Issues gibt, die ich allerdings schon bearbeitet habe.
Damit wäre Ihr Input sauber dokumentiert und die Änderungen nachvollziehbar. Ginge das?
Beste Grüße, Christian Johner
Habe ich sehr gerne erledigt.
Vielen Dank für den Leitfaden Prof. Dr. Johner!
Wie Sie im Artikel bereits vermerken gibt es keine Einheitliche Lösung oder Harmonisierte Normen, geschweige denn eine Liste spezifischer Anforderungen um im Audit zu bestehen. Könnte man mit dieser – meiner Meinung nach schon sehr guten – Richtlinie im Audit (MDR) bestehen wenn man nachweislich state of the art und bspw. eine 27001 Zertifizierung anstrebt?
Oder würden Sie da eher auf einzelnen Normen zurückgreifen die Sie unter
„E.2.b) Standards and best practice guides“
genannt haben?
Beste Grüße!
Sehr geehrte/r T. Samartzidis,
danke für Ihre wichtige Frage!
Im Kontext der IT-Sicherheit ist die ISO 27001 nicht(!) die primäre Norm, um Konformität mit den Anforderungen er MDR nachzuweisen. Das liegt daran, dass die ISO 27001 eine Norm ist, die Vorgaben für Organisationen macht, nicht primär für Produkte. Die Konformität ISO 27001 wäre hingegen sehr hilfreich, wenn Sie IT-Systeme (z.B. Medizinprodukte) betreiben.
Für die Produkte empfehle ich Ihnen unseren Leitfaden, weil dieser zum einen den Produktfokus hat und zum anderen von den Benannten Stellen in leicht abgewandelter Norm als Checkliste für Audits und Prüfungen der technischen Dokumentation verwendet wird.
Mit herzlichen Grüßen, Christian Johner