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

1. Regulatorische Anforderungen an Betriebssysteme

1.1 Allgemeines

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

1.2 Regulatorische Anforderungen in Europa

1.2.1 Das Betriebssystem ist Teil des Medizinprodukts

Bei Medizingeräten ist die ganze Software (eigene Software und Betriebssystem) Bestandteil des Medizinprodukts. In diesem Fall muss die komplette Software konform der Norm IEC 62304 („medical device software – software life cycle processes „) dokumentiert sein.

Hier gilt es 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.

1.2.2 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 besteht nicht die Forderung, dass das Betriebssystem IEC-62304-konform entwickelt wurde.

Der Hersteller ist allerdings verpflichtet, diese Voraussetzungen zu spezifizieren und den Betreibern/Anwendern mitzuteilen. Die Wahl des Betriebssystems wirkt sich direkt auf die Spezifikation der Software-Anforderungen (gemäß IEC 62304, Kapitel 5) aus.

1.2.3 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 sollte er untersuchen, was passiert, wenn beispielsweise

• das Betriebssystem fehlerhaft ist,
• nicht das vorgesehene Betriebssystem installiert ist,
• das Betriebssystem nicht aktualisiert wurde,
• 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).

1.3 Regulatorische Anforderungen der FDA

Die FDA formuliert sowohl für die Hersteller als auch die Betreiber von Medizinprodukten und Healthcare-IT Anforderungen an Betriebssysteme.

1.3.1 Anforderungen an Betriebssysteme als OTS

Betriebssysteme, die Teil eines Medizinprodukts sind, zählt die FDA 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.

1.3.2 Anforderungen an die Cybersecurity

Bei jeder Software (unabhängig davon, ob es Betriebssysteme sind) müssen Hersteller und Betreiber die Anforderungen an die Cybersecurity erfüllen.

1.3.3 Sonstige Anforderungen an die Entwicklung

Hersteller sollten bei der Auswahl von Betriebssystemen folgende Punkte beachten:

1. Die Anforderungen an Betriebssysteme, die Teil des Medizinprodukts sind, müssen festgelegt werden.
2. Die Mindestvoraussetzungen, von der eine Software (Standalone-Medizinprodukt) als Laufzeitumgebung ausgehen kann, müssen spezifiziert werden. 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.

1.3.4 Sonderfall: Anforderungen an Prozess-Software

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

2. 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?“

2.1 Anforderungen mancher Hersteller

Regelmäßig überhäufen Medizinproduktehersteller die RTOS-Hersteller mit Forderungen:

• Das RTOS muss wirklich real-time sein (und dann kommt eine absurde Forderung in µs).
• Das RTOS darf nur ganz wenig Speicher benötigen (dann folgt eine unrealistische Forderung in kB).
• Das RTOS muss auf möglichst allen Prozessoren laufen (inklusive einer beeindruckend langen Liste an Prozessoren).
• Das RTOS muss möglichst wenig kosten (am liebsten nichts).

Solch Forderungen mögen in Preisverhandlungen hilfreich sein, für die Produktauswahl sind sie weniger hilfreich.

2.2 Zielführende Anforderungen

Hersteller haben gute Erfahrungen damit gemacht festzulegen, was sie tatsächlich benötigen:

• Wie schnell muss das System reagieren? Hängen sicherheitskritische Funktionen davon ab? Die Antwort folgt aus dem Risikomanagement.
• Welche Schnittstellen soll das System bedienen? Welche benötigen Sie als Hersteller 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.

2.3 Fazit

Medizinproduktehersteller sollten den RTOS-Herstellern keine Forderungen stellen, solange nicht klar ist, was quantitativ und qualitativ wirklich benötigt wird. Denn sonst ist es ähnlich müßig, die Frage nach dem besten RTOS zu stellen wie die Frage, ob Windows oder Linux besser sei.

3. Zertifizierung von Betriebssystemen nach IEC 62304?

Zunehmend behaupten Hersteller von Betriebssystemen, dass ihre Produkte IEC-62304-zertifiziert seien. So übertitelte z. B. eine Firma eine Pressemitteilung mit „<Produktname> Echtzeitbetriebssystem für die Entwicklung medizinischer Geräte wird IEC 62304 konform“

3.1 Weshalb diese Zertifizierung nicht sinnvoll/möglich ist

Die IEC 62304 verlangt normativ ein Risikomanagement nach ISO 14971. Das ist für ein Betriebssystem in Unkenntnis des genauen Produkts und seiner Zweckbestimmung nicht möglich.

Ohne diese Kenntnis fällt auch die Sicherheitsklassifizierung schwer. Daher müsste alles als Klasse C eingestuft werden. Das hätte bemerkenswerte Auswirkungen auf den Umfang der Anforderungsspezifikation, des Architekturdokuments, der Unit-/Komponententests usw.

Die Behauptung, das Betriebssystem sei „IEC 62304-konform“, muss generell hinterfragt werden. Denn derzeit gibt es keine akkreditierten Stellen, die dieses Zertifikat erteilen. Zumal die IEC 62304 eine Prozessnorm ist.

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

Die Behauptung, das eigene Betriebssystem sei zertifiziert, zeugt zumindest von einem Verständnis, dass Software-Qualitätssicherung einen Marktwert hat. Möge das allen Medizinprodukteherstellern ein gutes Vorbild sein.

Wenn man vom RTOS-Hersteller Untelagen zu Testberichten und Architektur ausgehändigt bekäme – was ich aber nicht glaube –, könnte man im Risikomanagement 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 ist vielleicht das Wichtigere) die Statistik sprechen zu lassen. Insofern sollte man eher den häufig eingesetzten Betriebssystemen vertrauen als den angeblich zertifizierten: Denn je häufiger ein Betriebssystem eingesetzt wird, desto wahrscheinlicher ist es, dass Fehler bekannt werden, auf die man reagieren kann.

In anderen Worten: Letztlich ist die Wahrscheinlichkeit entscheidend, mit der ein Betriebssystem Fehler aufweist oder eben nicht aufweist, die für das eigene Produkt relevant sind. Dass sich diese Wahrscheinlichkeiten zwischen zertifizierten und häufig eingesetzten Produkten um Größenordnungen unterscheiden, ist zu beweisen.

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

4. Updates von Betriebssystemen: Ein Dilemma

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

4.1 Dilemma der Hersteller?

Für Hersteller bedeutet es einen hohen Aufwand, für bereits im Markt befindliche Produkte das Betriebssystem zu aktualisieren:

• Software-Anforderungen überarbeiten
• Software-Architektur und SOUP-Liste anpassen
• Software-Tests (teilweise) mit neuem Betriebssystem wiederholen
• Update-Prozess definieren und validieren
• SOUP-Liste und SBOM aktualisieren
• Software erneut freigeben
• ggf. Begleitinformationen aktualisieren
• Post-Market-Aktivitäten adaptieren (z. B. neue SOUP in Nachverfolgung aufnehmen)
• Update durchführen und dessen Erfolg prüfen

Für all diese Aufwände sind die Kunden (z. B. Krankenhäuser) selten bereit zu bezahlen.

Es hilft aber nichts: Hersteller sind verpflichtet, im Rahmen der Post-Market Surveillance fortlaufend und proaktiv zu bewerten, ob das Nutzen-Risiko-Verhältnis noch gegeben ist und alle Risiken beherrscht sind. Dazu zählen auch Risiken, die sich durch unsichere Betriebssysteme ergeben.

4.2 Dilemma für Betreiber

Die Betreiber sind genauso wie die Hersteller verpflichtet, die IT-Sicherheit zu gewährleisten. Diese Forderung findet sich unter anderem in der Medizinprodukte-Betreiberverordnung.

Falls ein Betreiber realisiert, dass ein Medizinprodukt ein veraltetes oder unsicheres Betriebssystem beinhaltet, hat er mehrere Möglichkeiten:

• Das Betriebssystem aktualisieren (falls er Zugriff darauf hat)
  Das ist oft durch den Hersteller nicht vorgesehen und daher nicht Teil des bestimmungsgemäßen Gebrauchs. Dann darf der Betreiber das Betriebssystem nicht aktualisieren, ohne selbst zum (Eigen-)Hersteller zu werden.
• Das Betriebssystem nicht aktualisieren
  Falls der Betreiber nicht-sichere Produkte betreibt, verstößt er gegen die gesetzliche Vorgaben und gefährdet möglicherweise die Patienten. Daher entfällt diese Option.
• Den Hersteller bitten, das Betriebssystem zu aktualisieren
  Daher bleibt dem Betreiber nur, den Hersteller zur Aktualisierung zu verpflichten. Das setzt voraus, dass es diesen Hersteller noch gibt und dass er bereit ist, dieses Update zu vertretbaren Kosten durchzuführen.
• Produkt außer Betrieb nehmen.
  Wenn diese Voraussetzung nicht gegeben ist, kann der Betreiber zur Schlussfolgerung kommen, dass ein sicherer Betrieb nicht mehr möglich ist. Dann muss er das Produkt außer Betrieb setzen.

5. Fazit und Zusammenfassung

Medizinproduktehersteller sind in vielen Fällen gut beraten, kommerziell verfügbare Betriebssysteme zu verwenden und keine eigenen zu entwickeln.

Sie haben bei physischen Medizinprodukten allerdings nicht die Wahl, ob sie das Betriebssystem als SOUP und damit Teil des Medizinprodukts deklarieren oder als Teil der Laufzeitumgebung. Bei diesen Medizingeräten sind von Dritten bezogene Betriebssysteme immer SOUP. Die Anforderungen an Betriebssysteme, die nur Teil der Laufzeitumgebung sind, sind niedriger.

Der Fokus sollte immer darauf liegen, sehr präzise und sehr spezifisch für das Produkt und seine Zweckbestimmung die Anforderungen an das Betriebssystem zu spezifizieren und bei der Verifizierung des Betriebssystems sicherzustellen, dass diese Anforderungen erfüllt sind. Das gilt völlig unabhängig davon, ob das Betriebssystem eine SOUP oder selbstentwickelt ist.

Änderungshistorie

• 2024-10-23: Artikel grundlegende überarbeitet, neu strukturiert und aktualisiert
• 2016-10-26: Erste Version des Artikels veröffentlicht

Ähnliche Beiträge