Betriebssystem IEC 62304 und FDA konform?

Müssen Medizinproduktehersteller bei der Auswahl des Betriebssystems darauf achten, dass das Betriebssystem IEC 62304-konform ist? Dieser Artikel

• nennt Ihnen die regulatorischen Anforderungen (z.B. IEC 62304) an Betriebssysteme,
• gibt Ihnen Tipps zur Auswahl von Betriebssystemen,
• untersucht, ob es eine IEC 62304-Zertifizierung für Betriebssysteme geben kann und
• geht auf die Anforderungen der FDA ein.

Regulatorische Anforderungen an Betriebssysteme (Europa)

Die normativen Anforderungen an ein Betriebssystem hängen davon ab, ob es Teil des Produkts oder Teil der Laufzeitumgebung ist.

Das Betriebssystem ist Teil des Medizinprodukts

Bei Medizingeräten ist die ganze Software (eigene, Betriebssystem) Bestandteil des Medizinprodukts. In diesem Fall muss das Betriebssystem IEC 62304 („medical device software – software life cycle processes „) dokumentiert sein. Hier gilt es wieder zwei Fälle zu unterscheiden:

1. Der Medizinproduktehersteller hat das Betriebssystem selbst entwickelt: In diesem Fall muss der komplette Software-Lebenszyklus für das Betriebssystem dokumentiert sein. Insbesondere ist der Hersteller (abhängig von der Sicherheitsklasse) verpflichtet, die Software-Anforderungen, die Software-Architektur (einschließlich detailliertes Design), die Software-Tests und die Software-Freigabe zu dokumentieren und einen Entwicklungsprozess zu befolgen.
2. Der Medizinproduktehersteller nutzt ein (kommerziell) verfügbares Betriebssystem (z.B. Windows, Linux): In diesem Fall muss der Hersteller das Betriebssystem als SOUP behandeln und beispielsweise die Anforderungen an die SOUP und die Voraussetzungen für deren Verwendung beschreiben.
   Im Auditgarant erfahren Sie mehr dazu, wie Sie Ihre SOUPs IEC 62304-konform dokumentieren.

Das Betriebssystem ist NICHT Teil des Medizinprodukts

Bei standalone Software setzt der Hersteller eine Laufzeitumgebung aus Hardware (z.B. PC) und Betriebssystem voraus. Das Betriebssystem ist dann nicht Teil des Medizinprodukts, d.h. es gibt keine Forderung, dass das Betriebssystem IEC 62304-konform entwickelt wurde.

Risikomanagement für Betriebssysteme

In beiden Varianten ist der Hersteller verpflichtet, Risiken, die mit dem Betriebssystem verknüpft sind, zu analysieren und zu beherrschen. So sollten die Hersteller untersuchen, was passiert, wenn

• das Betriebssystem fehlerhaft ist
• nicht das vorgesehene Betriebssystem installiert ist
• das Betriebssystem nicht aktualisiert ist
• das Betriebssystem durch parallel installierte Software (z.B. Firewall, Antivirus-Software) in seiner normalen Funktion beeinträchtigt ist (z.B. Zugriff auf Ressourcen wie Netzwerk oder Speicher kann nicht zur Verfügung gestellt werden).

Betriebssystem: Regulatorische Anforderungen der FDA

Die FDA stellt sowohl an die Hersteller als auch an die Betreiber von Medizinprodukten und Healthcare-IT Anforderungen an Betriebssysteme. Beispielsweise müssen Hersteller und Betreiber die Anforderungen an die Cybersecurity erfüllen. Lesen Sie hier einen Artikel zum entsprechenden Cybersecurity Guidance Document.

Anforderungen an die Entwicklung

Die Hersteller sollten bei der Auswahl und Verwendung von Betriebssystemen folgende Anforderungen erfüllen:

1. Die Anforderungen an Betriebssysteme, die Teil des Medizinprodukts sind, sind festzulegen.
2. Die Mindestvoraussetzungen sind zu spezifizieren, von der eine Software (stand-alone Medizinprodukt) als Laufzeitumgebung ausgehen kann. Diese schließen das Betriebssystem ein. Oft drückt man diese Anforderungen durch Formulierungen wie die folgende aus: „Voraussetzung ist Windows XY mit Service Patch YZ oder höher.“
3. Die Software Requirements Specification (SRS) und die Software Design Specification (Fein-Architektur) muss das Betriebssystem beinhalten.
4. Die Integrationstests müssen das Zusammenspiel der Software mit dem Betriebssystem prüfen.
5. Die Systemtests müssen auch auf dem Ziel-Betriebssystem durchgeführt werden.

Betriebssysteme als OTS

Betriebssysteme, die Teil eines Medizinprodukts sind, zählt die FDA auch zur Off-The-Shelf-Software (OTS). Sie sagt, dass OTS Betriebssysteme nicht als eigene Programme validiert werden müssen:

„Off-the-shelf operating systems need not be validated as a separate program. However, system-level validation testing of the application software should address all the operating system services used, including maximum loading conditions, file operations, handling of system error conditions, and memory constraints that may be applicable to the intended use of the application program.“ (Quelle: Software Validation Guidance)

Bei Treibern möchte die FDA aber den Datenfluss verifiziert sehen:

„[…] the validation process for the OTS driver software package should be part of the system interface validation process for higher levels of concern. This includes the verification of the data values in both directions for the data signals; various mode settings for the control signals in both directions (if applicable); and the input/output interrupt and timing functions of the driver with the CPU and operating system.“ (Quelle: OTS Guidance)

Generell müssen Hersteller die Anforderungen an die Verwendung von Off-The-Shelf-Software erfüllen. Beispielsweise müssen sie eine „Special Documentation“ beilegen, wenn die OTS nach den risikominimierenden Maßnahmen immer noch ein Major Level of Concern hat. Das kann ein Audit bei dem OTS-Hersteller bedeuten. Dass sich Microsoft (beispielsweise) so in die Karten schauen lässt, dürfte eher unwahrscheinlich sein.

Anforderungen an die Verwendung von Prozess-Software

Die Anforderungen der FDA betreffen nicht nur die (Software-)Entwicklung, sondern auch ggf. die Produktion. Nämlich immer dann, wenn Prozess-Software verwendet wird. Diese Prozess-Software ist zu validieren — auch auf dem tatsächlichen Betriebssystem.

Auswahlkriterien für (Real Time) Betriebssysteme

In unserem MicroConsulting hat uns folgende Frage erreicht: „Auf was soll ich achten, wenn ich mit (m)einem RTOS-Hersteller verhandle?“

Meistens beginnen die Medizinproduktehersteller den armen Vertreter der RTOS-Firma mit Forderungen zu überhäufen:

• Das RTOS muss wirklich real-time sein (und dann kommt eine absurde Forderung in µs)
• Das RTOS darf nur ganz wenig Speicher benötigen (und dann kommt eine absurde Forderung in kB)
• Das RTOS muss auf möglichst allen Prozessoren laufen (und dann kommt eine absurd lange Liste an Prozessoren)
• Das RTOS darf nichts kosten (und dann kommt ein absurd kleiner Betrag in EUR)
• Usw.

Solch Forderungen mögen in Preisverhandlungen hilfreich sein, für Ihr Produkt nützt das aber wenig. Fragen Sie sich doch erst einmal, was Sie wirklich benötigen:

• Wie schnell muss das System wirklich reagieren? Hängen sicherheitskritische Funktionen davon ab?
• Welche Schnittstellen soll das System bedienen? Welche benötigen Sie wirklich?
• Kommt das System mit den tatsächlichen Hardware-Ressourcen aus, die Sie zur Verfügung stellen?
• Benötigen Sie Zugriff auf den Quellcode?
• Welche Referenzen gibt es? Wie oft ist das System bereits verkauft?
• Gab es Probleme? Gibt es beispielsweise Meldungen beim BfArM?
• Gibt es Verifizierungsdokumente? Benötigen Sie die überhaupt?
• usw. usw.

Denken Sie daran: Das RTOS ist eine SOUP. Und die IEC 62304 fordert, dass Sie ebenso die Anforderungen an die SOUP formulieren als auch die Umgebung beschreiben müssen, welche die SOUP voraussetzen darf.

Üblicherweise versuchen Medizinproduktehersteller, den RTOS-Herstellern Forderungen zu stellen, ohne selbst zu wissen, was sie quantitativ und qualitativ wirklich benötigen. Solange man das nicht weiß, ist die Frage nach dem besten RTOS ähnlich müßig wie die Frage, ob Windows oder MacOS besser seien.

Zertifizierung, dass ein Betriebssystem IEC 62304-konform ist?

Zunehmend behaupten Betriebssystem-Hersteller, dass Ihre Produkte IEC 62304-zertifiziert seien. So übertitelt die Firma QNX-Software Ihre Pressemitteilung : „QNX Neutrino Echtzeitbetriebssystem für die Entwicklung medizinischer Geräte wird IEC 62304 konform“

Weshalb diese Zertifizierung nicht sinnvoll/möglich ist.

Das ist ja interessant. Als Leser meines Blogs wissen Sie, dass die IEC 62304 normativ ein Risikomanagement nach ISO 14971 verlangt. Nun fragen Sie sich möglicherweise genauso wie ich, wie das für ein Betriebssystem geschehen soll. Das halte ich schlicht für unmöglich.

Genauso schwierig ohne Kenntnis des Gesamtsystems (Medizinprodukt) ist auch die Sicherheitsklassifizierung. Man kann also alles nur als Klasse C einstufen. Dann bin ich an dem Architekturdokument wirklich interessiert. An den Komponententests übrigens auch. Das muss eine Monster-Testsuite sein…

Als dubios empfinde ich auch die Behauptung, das Betriebssystem sei „IEC 62304-konform“. Wer hat diese Konformität geprüft? Es gibt derzeit keine akkreditierten Stellen, die dieses Zertifikat erteilen.

Vielleicht liege ich falsch, aber in einem anderen Kontext würde die Firma meines Erachtens wegen irreführender Aussagen abgemahnt.

Welchen Nutzen es hätte, wenn das Betriebssystem IEC 62304-zertifiziert wäre

Aber lassen Sie uns die gute Seite sehen: Man hat erkannt, dass Software-Qualitätssicherung einen Marktwert hat. Möge das allen Medizinprodukteherstellern ein gutes Vorbild sein.

Wenn man die Unterlagen im Sinne von Testberichten und Architektur von Hersteller dieser RTOS ausgehändigt bekäme – was ich aber nicht glaube – könnte man im Risikomanagement noch genauere Aussagen machen. Für die Zertifizierung der Medizinprodukte sind diese „Selbst-Zertifizierungen“ meist nicht hilfreich:

Letztlich hat man ja keine andere Chance, als dem Hersteller zu vertrauen – oder (und das finde ich das wichtigere) die Statistik sprechen lassen. Insofern tendiere ich eher zu häufig eingesetzten Betriebssystemen als zu angeblich zertifizierten: Je häufiger ein Betriebssystem eingesetzt wird, desto wahrscheinlicher werden Fehler gefunden und bekannt, sodass man darauf reagieren kann.

In anderen Worten: Letztlich ist die Wahrscheinlichkeit entscheidend, mit der ein Betriebssystem einen für das eigene Produkt relevanten Fehler hat. Dass sich diese Wahrscheinlichkeiten zwischen zertifizierten und häufig eingesetzten Produkten um Größenordnungen unterscheiden, glaube ich nicht. Und genauer als auf Größenordnungen kann man im Risikomanagement eh nicht schätzen.

Solange man nicht die komplette Dokumentation einschließlich Code des OS hat, ist und bleibt das RTOS eine SOUP.

Windows 8 als Betriebssystem für Medizinprodukte

Manche Medizinprodukte wie neulich eine Herz-Lungen-Maschine lassen mich schaudern: Sie laufen auf völlig veralteten Betriebssystemen wie Windows 2000. Betriebssysteme, die nicht mehr gepatched werden.

Matthias Wiesenauer, der mit mir neulich einen Artikel veröffentlicht hat (s. Blog-Beitrag), stellt sich die Frage, wie man mit ganz neuen Betriebssystemen umgehen sollte. Betriebssysteme wie Windows 8, zu denen zum einen noch wenig Erfahrungen vorliegen und die zum anderen ihre eigene Antivirus-Software mitbringen, d.h. sich selbst kontinuierlich aktualisieren.

Wenn das Betriebssystem (hier Windows 8) Teil des Medizinprodukts ist, dann liegt es in der Verantwortung des Herstellers, die Risiken abzuschätzen und zu beherrschen, die sich daraus ergeben, dass Windows 8 sich selbständig aktualisiert, z.B. was Virenschutz angeht. Der Hersteller kann sogar verlangen, dass das System in der Lage sein muss, selbstständig diese Komponenten zu aktualisieren bzw. dass dies von der Klinik erledigt werden muss.

Wenn ein Hersteller hingegen fordert, dass sein eigener Virenschutz genutzt werden muss – auch oder weil ihm das zusätzliche Einnahmen beschert -, dann ist das sein Recht und muss vom Betreiber so umgesetzt werden. Wenn er das nicht tut, betreibt er das Produkt nicht gemäß der Zweckbestimmung.

Dem Betreiber hingegen bleibt es unbenommen, sich einen Hersteller auszusuchen, der ihn nicht mit (ggf. unnötigen) Zusatzprodukten zur Kasse bittet.