Kategorien: Software & IEC 62304
Tags:

7 Kommentare

  1. Peter Knipp | Freitag, 30. Januar 2015 um 22:40 Uhr - Antworten

    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 | Freitag, 13. Februar 2015 um 10:17 Uhr - Antworten

    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 | Mittwoch, 1. April 2015 um 19:21 Uhr - Antworten

    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 | Mittwoch, 7. Dezember 2016 um 12:45 Uhr - Antworten

    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?


    • Prof. Dr. Christian Johner | Mittwoch, 7. Dezember 2016 um 22:24 Uhr - Antworten

      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.


  5. Andreas Feil | Mittwoch, 26. April 2017 um 09:07 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Mittwoch, 3. Mai 2017 um 21:07 Uhr - Antworten

      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


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.