{"id":5011,"date":"2021-02-25T06:00:00","date_gmt":"2021-02-25T05:00:00","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=5011"},"modified":"2024-05-24T11:26:21","modified_gmt":"2024-05-24T09:26:21","slug":"software-risikomanagement-iso14971","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/software-risikomanagement-iso14971\/","title":{"rendered":"Software-Risikomanagement f\u00fcr medizinische Software"},"content":{"rendered":"\n

Unter Software-Risikomanagement<\/strong> verstehen Hersteller von Medizinprodukten entweder das Risikomanagement, das sie f\u00fcr die Standalone-Software betreiben m\u00fcssen, oder den Teil des Risikomanagements, den eine embedded Software nach sich zieht.<\/p>\n\n\n\n

Regelm\u00e4\u00dfig werden Hersteller den regulatorischen Anforderungen an das Software-Risikomanagement nicht gerecht. Dieser Beitrag gibt Tipps f\u00fcr ein schlankes Software-Risikomanagement, mit dem Sie unn\u00f6tige Aufw\u00e4nde vermeiden und Konformit\u00e4t erreichen<\/strong> k\u00f6nnen. Er beschreibt auch das Konzept der „Software-FMEA“<\/strong>.<\/p>\n\n\n\n\n\n\n\n

1. Regulatorische Anforderungen<\/h2>\n\n\n\n

a) Gesetze<\/h3>\n\n\n\n

Die EU-Richtlinien bzw. die EU-Verordnungen f\u00fcr Medizinprodukte wie die MDR<\/a> und die nationalen Gesetze unterscheiden Produkte mit und ohne Software bez\u00fcglich des Risikomanagements nicht. <\/p>\n\n\n\n

b) Normen<\/h3>\n\n\n\n

ISO 14971<\/h4>\n\n\n\n

Auch die ISO 14971<\/a>, die f\u00fcr das Risikomanagement harmonisierte Norm<\/a>, kennt\u00a0kein explizites Software-Risikomanagement.\u00a0<\/p>\n\n\n\n

IEC 62304<\/h4>\n\n\n\n

Nur die (alte) IEC 62304 durchquert mit ihrer (scheinbaren) Philosophie, dass Fehler in Software mit 100 Prozent Wahrscheinlichkeit anzunehmen sind, das Prinzip der ISO 14971 und deren\u00a0Definition von Risiko, n\u00e4mlich die Kombination von Schweregrad und Wahrscheinlichkeit von Sch\u00e4den.<\/p>\n\n\n\n

<\/path><\/g><\/svg><\/div>Weiterf\u00fchrende Informationen<\/span><\/div>\n

Lesen Sie hier mehr zu Fehlerwahrscheinlichkeit bei Software<\/a>.<\/p>\n<\/div>\n\n\n\n

Die IEC 62304 stellt wenige f\u00fcr Software spezifische Anforderungen an das Risikomanagement bei medizinischer Software. Dazu z\u00e4hlt die \u00dcberwachung der SOUP<\/a>.<\/p>\n\n\n\n

2. Besonderheiten beim Software-Risikomanagement<\/h2>\n\n\n\n

a) Es gibt nur indirekte Sch\u00e4den<\/h3>\n\n\n\n

Software f\u00fchrt zu keinem direkten Schaden. Software kann direkt nicht verletzen oder gar t\u00f6ten. Die Sch\u00e4den erfolgen immer indirekt \u00fcber\u00a0physische Ger\u00e4te (z.B.\u00a0quetschender Tisch, \u00a0strahlendes Ger\u00e4t) oder \u00fcber Menschen, die Patienten beispielsweise falsch oder gar nicht behandeln. Das macht das Software-Risikomanagement besonders herausfordernd.<\/p>\n\n\n\n

Wenn Sie also ein Risikomanagement f\u00fcr Software betreiben wollen, dann m\u00fcssen Sie die Ursachenkette von der fehlerhaften Software bis zum Patienten (oder ggf. Anwender) verfolgen.<\/p>\n\n\n\n

b) Das Konzept der Gef\u00e4hrdungen unterscheidet sich<\/h3>\n\n\n\n

Gef\u00e4hrdungen im Sinne der ISO 14971:2012<\/h4>\n\n\n\n

Bei physischen Ger\u00e4ten liegen die elektrische Energie, die mechanische Energie, die Strahlungsenergie oder die chemischen Materialien (all das sind Gef\u00e4hrdungen) an der „Au\u00dfenkante“ des Medizinprodukts an.<\/p>\n\n\n\n

Das ist bei Software nicht notwendigerweise der Fall. Eine fehlerhafte Anzeige (User Interface) oder ein Weiterleiten fehlerhafter Daten (Datenschnittstelle) ist zwar eine potenzielle Schadensquelle und damit Gef\u00e4hrdung. So sprach auch die ISO 14971:2012 (ungl\u00fccklicherweise) auch von informationellen Gef\u00e4hrdungen (s. Abb. 1). <\/p>\n\n\n\n

\"Gef\u00e4hrdungen
Abb. 1: Beispiele f\u00fcr Gef\u00e4hrdungen – Quelle: ISO 14971:2012, Tabelle E.1<\/figcaption><\/figure>\n\n\n\n

Es empfiehlt sich aber, die Gef\u00e4hrdungen eher als letztes Element der Ursachenkette zu definieren. Damit w\u00e4re eine fehlerhafte Software ein (ausl\u00f6sendes) Element einer Ursachenkette, aber nicht die Gef\u00e4hrdung.<\/p>\n\n\n\n

<\/path><\/path><\/g><\/svg><\/div>Tipp<\/span><\/div>\n

Das Johner Institut empfiehlt, die Pr\u00e4zisierung der Definition zumindest zu erw\u00e4gen: Nicht mehr jedes Element der Ursachenkette ist eine Gef\u00e4hrdung, sondern nur noch das letzte Element vor der Gef\u00e4hrdungssituation.<\/p>\n<\/div>\n\n\n\n

Gef\u00e4hrdungen im Sinne der ISO 14971:2019 (und sp\u00e4ter)<\/h4>\n\n\n\n

Die neue Version der ISO 14971:2019 spricht von „leistungsbezogenen Gef\u00e4hrdungen“. und ist damit n\u00e4her dran an der MDR Forderung nach einem Ausschluss\/der Reduzierung von Risiken und Leistungsbeeintr\u00e4chtigungen (Anhang I 17.1). Leistungsbezogene Gef\u00e4hrdungen beziehen sich z.B. auf die Verf\u00fcgbarkeit von relevanten Daten, das Ausbleiben von Alarmen oder die fehlerhafte Aktualisierungsrate von \u00dcberwachungsdaten bei einem Monitoring System.<\/p>\n\n\n\n

\"\"<\/a>
Abb. 2: Beispiele f\u00fcr Gef\u00e4hrdungen – Quelle: ISO 14971:2019, Tabelle C.1<\/figcaption><\/figure>\n\n\n\n

Wenn man sich auf die erg\u00e4nzende Definition gem\u00e4\u00df des Tipps oben einl\u00e4sst, ist nicht mehr die falsche Anzeige, sondern das falsche Medikament die Gef\u00e4hrdung – eine chemische Gef\u00e4hrdung. <\/p>\n\n\n\n

Diese erg\u00e4nzende Definition hilft oft auch bei der Verwendung des Begriffs „Gef\u00e4hrdungssituation“, also den Umst\u00e4nden, unter denen Menschen, G\u00fcter oder die Umwelt einer oder mehreren Gef\u00e4hrdungen ausgesetzt sind: Ein Patient ist m\u00f6glicherweise nie einer falschen Zweckbestimmung oder einer falschen Anzeige ausgesetzt, weil nur der Arzt bzw. die \u00c4rztin diese sieht. Aber der Patient ist dem falschen Medikament ausgesetzt.<\/p>\n\n\n\n

<\/path><\/path><\/g><\/svg><\/div>Tipp<\/span><\/div>\n

Achten Sie darauf, dass Sie beim Risikomanagement Ursachen,\u00a0Gef\u00e4hrdungen, Gef\u00e4hrdungssituationen, Risiken und\u00a0Sch\u00e4den nicht verwechseln. Ihre Risikomanagement-Akte wird sonst im Audit zum Problem. <\/p>\n\n\n\n

Lassen Sie uns wissen, wenn wir helfen k\u00f6nnen (Kontakt via Webformular<\/a>).<\/p>\n<\/div>\n\n\n\n

3. Tipps zum Risikomanagement f\u00fcr Software<\/h2>\n\n\n\n

Tipp 1: Richtige Granularit\u00e4t<\/h3>\n\n\n\n

„Wie tief muss die Risikoanalyse der Software-Komponenten innerhalb der Architektur gehen? Muss man bis auf Klassenebene oder sogar bis auf die Methodenebene heruntergehen?“ So lauten h\u00e4ufige Fragen im Micro-Consulting des Johner-Instituts<\/a>.<\/p>\n\n\n\n

Eine Regel, wie weit man „heruntergehen“ muss, kann und wird es nicht geben. Starten Sie mit einer Trennung zwischen nach au\u00dfen sichtbarem Fehlverhalten eines Produkts sowie den resultierenden Gef\u00e4hrdungen und der Ursachenkette, die zu diesem nach au\u00dfen sichtbaren Fehlverhalten f\u00fchrt. Dies entspricht einer FMEA<\/a> ab „Ger\u00e4tekante“.<\/p>\n\n\n\n

\"Innere<\/a>
Abb. 3: Unterscheiden Sie beim Risikomanagement f\u00fcr (Standalone-) Software die innere und die \u00e4u\u00dfere Ursachenkette (zum Vergr\u00f6\u00dfern klicken)<\/figcaption><\/figure>\n\n\n\n

Nur falls f\u00fcr ein bestimmtes, nach au\u00dfen sichtbares Fehlverhalten ein Risiko folgt, m\u00fcssen Sie die Ursachenkette „nach innen“, d.h. bis auf Komponentenebene hin, untersuchen. Dies entspricht einer FTA<\/a> ab „Ger\u00e4tekante“ (Richtung Komponenten).<\/p>\n\n\n\n

Diese zweite Untersuchung hat folgende Ziele:<\/p>\n\n\n\n

    \n
  1. Zum einen wollen Sie die Ursachen und ggf. Wahrscheinlichkeiten f\u00fcr dieses Fehlverhalten herausfinden.
    Anmerkung: Diese Ursachen (z.B. fehlerhafte Komponenten) haben eine Wahrscheinlichkeit f\u00fcr ein Fehlverhalten, aber keinen Schweregrad. Dieser existiert nur in der \u00e4u\u00dferen Kette.<\/li>\n\n\n\n
  2. Zum anderen wollen Sie untersuchen, ob es M\u00f6glichkeiten im Sinne einer risikominimierenden Ma\u00dfnahme gibt, um eben diese Ursachenkette zu unterbrechen.<\/li>\n<\/ol>\n\n\n\n

    Sie k\u00f6nnen die Analyse beenden, sobald Sie eine Ma\u00dfnahme definiert haben, die den Fehlerbaum abschneidet. Je h\u00f6her die Ebene ist, auf der Ihnen das gelingt (idealweise nicht innerhalb des gleichen Software-Systems), umso besser.<\/p>\n\n\n\n

    \"Risikomanagement:<\/a>
    Abb. 4: Ursachenbaum bei der Fehleranalyse (zum Vergr\u00f6\u00dfern klicken)<\/figcaption><\/figure>\n\n\n\n

    Auch wenn eine Antwort wie „das h\u00e4ngt davon ab“ nicht gesch\u00e4tzt wird, ist sie doch die einzig m\u00f6gliche auf die Frage nach der Tiefe der Untersuchung. Die meisten Firmen untersuchen zu tief und zu wenig breit. Das f\u00fchrt zu \u00fcbergro\u00dfen Risikotabellen, die viel Arbeit verursachen, aber keine wirklichen Erkenntnisse liefern. Viele Risiken bleiben unerkannt.<\/p>\n\n\n\n

    Tipp 2: Interdisziplin\u00e4re Team f\u00fcr das Software-Risikomanagement<\/h3>\n\n\n\n

    Das Risikomanagement ist ein Teamsport, an dem Sie beteiligen sollten:<\/p>\n\n\n\n