Betriebssystem IEC 62304 und FDA konform?

Mittwoch 26. Oktober 2016

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

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.

Betriebssystem IEC 62304 konform?

Welchen Anforderungen (z.B. IEC 62304) ein Betriebssystem genügen muss, hängt davon ab, ob es Teil des Medizinprodukts 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.

War dieser Artikel hilfreich? Bitte berwerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " Betriebssystem IEC 62304 und FDA konform?

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: Software & IEC 62304
Tags:

7 Kommentare über “Betriebssystem IEC 62304 und FDA konform?”

  1. Peter Knipp schrieb:

    Guten Abend,
    vielen Dank für die klare Stellungnahme zum Thema Zertifizierung nach 62304 (für Betriebssysteme). Insbesondere ist es ja kein Produktstandard, sondern ein Prozessstandard.

    Ich möchte aber einen Hinweis geben, was auch an anderer Stelle schon besprochen worden ist: Auch Betriebssysteme wie Windows 2000 oder Windows XP können, wenn die Medizinprodukte initial damit und dafür entwickelt und geprüft worden sind, auch heute noch mit genau demselben (tragbaren) Risiko betrieben werden wie zum Zeitpunkt der „Zulassung“, wenn diese Geräte NICHT am Netzwerk hängen!!
    Ich lese aber aus dem Schaudern oben, dass das wie selbstverständlich bei der HLM der Fall gewesen sein könnte. Dann ist das ggf. grob fahrlässig.

    Viele Grüße, Peter Knipp

  2. Malte Mundt schrieb:

    Wie hat QNX die Konformität gemäß IEC 62304 erreicht? Es wurde in der Tat ein hypothetisches Medizingerät Klasse C angenommen. QNX hat dann die Firma Orion Canada (http://www.orioncanada.com/) beauftragt, zu überprüfen, ob die Prozesse bei QNX konform sind zu IEC 62304. Die Erklärung der Konformität gilt dabei für den Microkernel sowie die Standard C-Library, das sind insgesamt etwa 100.000 Codezeilen. Nicht eingeschlossen sind Treiber oder Dateisysteme. Diese sind bei QNX auch nicht Teil des Kernels, im Gegensatz zu Linux oder Windows. Dennoch kann diese Konformitätserklärung enorm nutzbringend sein, da das Funktionieren des Schedulers und anderen wesentlichen Kernel-Aufgaben wesentlich für die (funktionale) Sicherheit des Medizingerätes sein kann. Kunden von QNX haben übrigens tatsächlich die Möglichkeit, zusätzlich zum IEC 62304 konform entwickelten QNX-Kernel die Testberichte und Architekturdokumente vom Hersteller zu bekommen. Wenn Sie weitere Fragen haben – oder „Glauben“ in „Wissen“ wandeln möchten, anstatt Abmahnungen vorzuschlagen – empfehle ich Ihnen die Kontaktaufnahme mit dem Chef unsere Sicherheits-Teams, Chris Hobbs: chobbs@qnx.com. Auch interessant ist ggf. einer seiner Vorträge zum Thema COTS und SOUP, der hier online anzusehen ist: https://www.youtube.com/watch?v=rz-7PJnvagU

    Mit freundlichen Grüßen

    Malte Mundt
    Field Application Engineer, QNX Deutschland

  3. Chris Hobbs schrieb:

    Malte Mundt hat mich im obenstehenden Kommentar vorgestellt—ich heiße Chris Hobbs und arbeite als Mitglied der Sicherheitsgruppe bei QNX.

    Wie Malte geschrieben hat, haben wir selbst-zertifiziert, dass unser Betriebssystem durch ein IEC62304-konformes Prozess entwickelt wurde. 2012 haben wir eine externe Firma eingeladen, unsere Selbst-Zertifizierung zu bestätigen. Diese Zertifizierung haben wir 2014 erneut.

    Der Blogeintrag selbst bringt zwei interessante Fragen auf: (1) Weil das Betriebssystem sowieso als SOUP behandelt werden muss, warum ist die IEC62304-Konformität dem Medizinproduktehersteller trotzdem nützlich? (2) Wie kann man eine Gefahren- und Risikobewertung für ein Betriebsystem durchführen und wie ist sie nützlich? Um beide Fragen zu beantworten, könnte ich ein Buch schreiben, aber ich antworte hier in Kürze.

    IEC62304 definiert die Analysen, die ein Medizinproduktehersteller durchführen muss, um SOUP in ein Medizingerät integrieren zu können. Benutzt man ein IEC62304-konformes Betriebssystem, stehen die Ergebnisse dieser Analysen schon zur Verfügung—sie sollten mit dem Betriebssystem geliefert werden. Dadurch werden die Kosten und Risiken der Enwicklung reduziert.

    Die zweite Frage ist interessanter. Ein Betriebssystem ist ein kompliziertes Program, das verschiedene Fehlermöglichkeiten enthält. Es ist wichtig, dass der Medizinproduktehersteller diese Möglichkeiten versteht und sie in seine Fehleranalyse integriert. Insbesondere spezifiziert IEC62304 (Absatz 4.3): wenn eine gefährliche Situation auftreten kann
    “from a failure of the software system to behave as
    specified, the probability of such failure shall be assumed to be 100
    percent.”
    So geschrieben ist diese Anforderung nutzlos: wie oft, mit welchem statistischen Verteilung, usw.? Die Fehleranalyse eines konformen Betriebssystems (gemäß ISO14971, IEC61508 und ISO26262) muss diese Fragen beantwortet haben. Diese Information steht dem Medizinproduktehersteller zur Verfügung. Im Falle vom QNX-Betriebssystem ist diese Fehleranalyse von TÜV Rheinland als Teil der verwandten IEC61508-Zertifikation überprüft worden.

    Ich möchte auch sagen, dass mir die Liste von Fragen gefällt, die man einem Betriebsystemhersteller stellen sollte. Es ist viel wichtiger zu wissen, ob ein Betriebsystem die Performance-Anforderungen des Medizingeräts erfüllt, als zu wissen, ob das Betriebssytem gegen verschiedene unerhebliche Performance-Benchmarks geprüft worden ist.

    Für mein Deutsch, bitte ich um Endschuldigung—ich habe Deutsch vor vielen Jahren in der Schule studiert und die Zeit hat vieles ausgelöscht!

  4. Kai Just schrieb:

    Sehr geehrter Herr Prof. Johner,
    bezüglich der Betriebssysteme würde ich gerne eine allgemeine Frage stellen: wie kann ich als Medizinprodukte-Hersteller mit den automatischen Patches von W8/W10, den automatisierten Treiber-Updates von z.B. Graphikkarten usw.… normenkonform umgehen?

    Eine Standalone-SW als Medizinprodukt wird ja für eine bestimmte (weil darauf getestete) Umgebung freigegeben. Hätte man vorab eine Möglichkeit der Kontrolle über Patches von Betriebssystem/Treibern, usw… ließe sich dies über entsprechende Tests abfangen.

    Hat man jedoch keinerlei Kontrolle über den Zeitpunkt und somit einer „Freigabe“ der Patches für die jeweilige Betriebssystemumgebung, ist man immer im Hintertreffen, und kann nur im Nachhinein letztendlich Aussagen über die Funktionalität und Sicherheit des eigenen Produktes treffen.

    Wie wäre hier Ihre Vorgehensweise? Welche möglichen Lösungsansätze würden Sie hier sehen?

    Herzlichen Dank und mit freundlichen Grüßen

    Kai Just

    PS: In dem Artikel hier wird auf ein Blog Beitrag von Herrn Matthias Wiesenauer verwiesen, der sich wohl genau mit dem Thema befasst, den ich jedoch nicht gefunden habe. Könnten Sie da vielleicht den Link schicken/anpassen?

  5. Prof. Dr. Christian Johner schrieb:

    Wenn Sie in Ihrer „Zweckbestimmung“ keine konkrete Betriebssystemversion vorgeben (z.B. nur „ab Windows 8.1“) dann ist implizit klar, dass es verschiedene Versionen und damit auch Treiber gibt. Die Auswirkungen solch unterschiedlicher Laufzeitumgebungen müssen Sie im Risikomanagement betrachten.

    Wenn Sie hingegen eine ganz konkrete Betriebssystemversion festlegen, dann müssen Sie zumindest den vorhersagbaren Missbrauch untersuchen, dass es auf einem anderen System installiert wird.

  6. Andreas Feil schrieb:

    Sehr geehrter Herr Prof. Johner,

    ich habe gerade den Artikel und die Kommentare gelesen und dazu noch eine Rückfrage: Ich kann ein Medizingerät auf Basis von Windows 10 betreiben, dieses mit dem Internet verbinden und z. B. Updates im Feld erlauben, ohne diese vorher getestet zu haben? Im Risikomanagement muss dann die Bedrohungen aus dem Internet sowie Fehler durch Updates betrachtet werden. Ist das so richtig?

    Was macht man dann aber mit dem Konfigurationsmanagement. Hier behandelt man Windows doch als SOUP und muss genau die getestete und freigegebene Version dokumentieren. Das wäre doch hier nicht mehr möglich?

    Zweite Frage: Man handelt sich hier doch evtl. ein Qualitätsproblem ein, wenn das Medizingerät durch ein fehlerhaftes Update im Feld nicht mehr funktioniert?

    Vielen Dank für eine Antwort und schöne Grüße

    Andreas Feil

  7. Prof. Dr. Christian Johner schrieb:

    Sehr geehrter Herr Feil, danke für die spannenden Fragen, die Sie sich zum Teil schon selbst beantwortet haben:

    Das Risikomanagement ist in der Tat entscheidend, ob Sie ein Medizinprodukt auf Windows 10 betreiben und dieses mit dem Internet verbinden können.

    Windows ist nur dann eine SOUP, wenn es Teil des Produkts ist. Bei einer stand-alone Software wäre Windows eher die Laufzeitumgebung und daher keine SOUP.

    Jede risikominimierende Maßnahme (wie z.B. ein Update) kann zu neuen Risiken führen. Diese zu analysieren, verlangt die ISO 14971 explizit von Ihnen.

    Bei weiteren Fragen gerne nachhaken.

    Viele Grüße, Christian Johner

Kommentar schreiben