Unter Software-Risikomanagement verstehen Hersteller von Medizinprodukten entweder das Risikomanagement, das sie für die Standalone-Software betreiben müssen, oder den Teil des Risikomanagements, den eine embedded Software nach sich zieht.
Regelmäßig werden Hersteller den regulatorischen Anforderungen an das Software-Risikomanagement nicht gerecht. Dieser Beitrag gibt Tipps für ein schlankes Software-Risikomanagement, mit dem Sie unnötige Aufwände vermeiden und Konformität erreichen können. Er beschreibt auch das Konzept der „Software-FMEA“.
1. Regulatorische Anforderungen
a) Gesetze
Die EU-Richtlinien bzw. die EU-Verordnungen für Medizinprodukte wie die MDR und die nationalen Gesetze unterscheiden Produkte mit und ohne Software bezüglich des Risikomanagements nicht.
b) Normen
ISO 14971
Auch die ISO 14971, die für das Risikomanagement harmonisierte Norm, kennt kein explizites Software-Risikomanagement.
IEC 62304
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 Definition von Risiko, nämlich die Kombination von Schweregrad und Wahrscheinlichkeit von Schäden.
Lesen Sie hier mehr zu Fehlerwahrscheinlichkeit bei Software.
Die IEC 62304 stellt wenige für Software spezifische Anforderungen an das Risikomanagement bei medizinischer Software. Dazu zählt die Überwachung der SOUP.
2. Besonderheiten beim Software-Risikomanagement
a) Es gibt nur indirekte Schäden
Software führt zu keinem direkten Schaden. Software kann direkt nicht verletzen oder gar töten. Die Schäden erfolgen immer indirekt über physische Geräte (z.B. quetschender Tisch, strahlendes Gerät) oder über Menschen, die Patienten beispielsweise falsch oder gar nicht behandeln. Das macht das Software-Risikomanagement besonders herausfordernd.
Wenn Sie also ein Risikomanagement für Software betreiben wollen, dann müssen Sie die Ursachenkette von der fehlerhaften Software bis zum Patienten (oder ggf. Anwender) verfolgen.
b) Das Konzept der Gefährdungen unterscheidet sich
Gefährdungen im Sinne der ISO 14971:2012
Bei physischen Geräten liegen die elektrische Energie, die mechanische Energie, die Strahlungsenergie oder die chemischen Materialien (all das sind Gefährdungen) an der „Außenkante“ des Medizinprodukts an.
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ährdung. So sprach auch die ISO 14971:2012 (unglücklicherweise) auch von informationellen Gefährdungen (s. Abb. 1).
Es empfiehlt sich aber, die Gefährdungen eher als letztes Element der Ursachenkette zu definieren. Damit wäre eine fehlerhafte Software ein (auslösendes) Element einer Ursachenkette, aber nicht die Gefährdung.
Das Johner Institut empfiehlt, die Präzisierung der Definition zumindest zu erwägen: Nicht mehr jedes Element der Ursachenkette ist eine Gefährdung, sondern nur noch das letzte Element vor der Gefährdungssituation.
Gefährdungen im Sinne der ISO 14971:2019 (und später)
Die neue Version der ISO 14971:2019 spricht von „leistungsbezogenen Gefährdungen“. und ist damit näher dran an der MDR Forderung nach einem Ausschluss/der Reduzierung von Risiken und Leistungsbeeinträchtigungen (Anhang I 17.1). Leistungsbezogene Gefährdungen beziehen sich z.B. auf die Verfügbarkeit von relevanten Daten, das Ausbleiben von Alarmen oder die fehlerhafte Aktualisierungsrate von Überwachungsdaten bei einem Monitoring System.
Wenn man sich auf die ergänzende Definition gemäß des Tipps oben einlässt, ist nicht mehr die falsche Anzeige, sondern das falsche Medikament die Gefährdung – eine chemische Gefährdung.
Diese ergänzende Definition hilft oft auch bei der Verwendung des Begriffs „Gefährdungssituation“, also den Umständen, unter denen Menschen, Güter oder die Umwelt einer oder mehreren Gefährdungen ausgesetzt sind: Ein Patient ist möglicherweise nie einer falschen Zweckbestimmung oder einer falschen Anzeige ausgesetzt, weil nur der Arzt bzw. die Ärztin diese sieht. Aber der Patient ist dem falschen Medikament ausgesetzt.
Achten Sie darauf, dass Sie beim Risikomanagement Ursachen, Gefährdungen, Gefährdungssituationen, Risiken und Schäden nicht verwechseln. Ihre Risikomanagement-Akte wird sonst im Audit zum Problem.
Lassen Sie uns wissen, wenn wir helfen können (Kontakt via Webformular).
3. Tipps zum Risikomanagement für Software
Tipp 1: Richtige Granularität
„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äufige Fragen im Micro-Consulting des Johner-Instituts.
Eine Regel, wie weit man „heruntergehen“ muss, kann und wird es nicht geben. Starten Sie mit einer Trennung zwischen nach außen sichtbarem Fehlverhalten eines Produkts sowie den resultierenden Gefährdungen und der Ursachenkette, die zu diesem nach außen sichtbaren Fehlverhalten führt. Dies entspricht einer FMEA ab „Gerätekante“.
Nur falls für ein bestimmtes, nach außen sichtbares Fehlverhalten ein Risiko folgt, müssen Sie die Ursachenkette „nach innen“, d.h. bis auf Komponentenebene hin, untersuchen. Dies entspricht einer FTA ab „Gerätekante“ (Richtung Komponenten).
Diese zweite Untersuchung hat folgende Ziele:
- Zum einen wollen Sie die Ursachen und ggf. Wahrscheinlichkeiten für dieses Fehlverhalten herausfinden.
Anmerkung: Diese Ursachen (z.B. fehlerhafte Komponenten) haben eine Wahrscheinlichkeit für ein Fehlverhalten, aber keinen Schweregrad. Dieser existiert nur in der äußeren Kette. - Zum anderen wollen Sie untersuchen, ob es Möglichkeiten im Sinne einer risikominimierenden Maßnahme gibt, um eben diese Ursachenkette zu unterbrechen.
Sie können die Analyse beenden, sobald Sie eine Maßnahme definiert haben, die den Fehlerbaum abschneidet. Je höher die Ebene ist, auf der Ihnen das gelingt (idealweise nicht innerhalb des gleichen Software-Systems), umso besser.
Auch wenn eine Antwort wie „das hängt davon ab“ nicht geschätzt wird, ist sie doch die einzig mögliche auf die Frage nach der Tiefe der Untersuchung. Die meisten Firmen untersuchen zu tief und zu wenig breit. Das führt zu übergroßen Risikotabellen, die viel Arbeit verursachen, aber keine wirklichen Erkenntnisse liefern. Viele Risiken bleiben unerkannt.
Tipp 2: Interdisziplinäre Team für das Software-Risikomanagement
Das Risikomanagement ist ein Teamsport, an dem Sie beteiligen sollten:
- Risikomanager: Experte für Regularien, Methoden, Dokumentation
- Software- oder System-Architekt: Kennen innere Ursachenkette und können (nur) Wahrscheinlichkeiten abschätzen, dass sich die Software bzw. das System nach außen falsch verhalten
- Kontext-Experte: Kann beurteilen, mit welcher Wahrscheinlichkeit ein äußeres Fehlverhalten des Systems zu eine Gefährdungssituation führt
- Arzt/Ärztin: Kann beurteilen, mit welcher Wahrscheinlichkeit eine Gefährdungssituation zu einem Schaden eines bestimmten Schweregrads führt
Sie können also das Software-Risikomanagement keinesfalls alleine den Software-Entwicklern überlassen. Damit meinen wir die Rollen (und nicht konkrete Personen, die mehrere Rollen innehaben können).
Tipp 3: Risikomanagement für Festlegung der Software-Sicherheitsklassen
Um die Software-Sicherheitsklasse nach IEC 62304 festzulegen, müssen Sie eine Risikoanalyse durchführen. Genau das sagt die IEC 62304 ab der Version 2015 auch aus. D.h. eine erste Risikoanalyse erfolgt vor der Sicherheitsklassifizierung
Beachten Sie auch diese Empfehlungen:
- Wenn Sie zum Ergebnis kommen, dass Ihre Software in die Sicherheitsklasse A fällt, dann prüfen Sie nochmals, ob die Software ein Medizinprodukt ist.
- Ist beides der Fall, dann stellen Sie sicher, dass Sie die Anforderungen der MDR erfüllen, welche eine Software-Dokumentation nach Anhang II fordert und keine Sicherheitsklassen kennt.
- Entwickeln Sie Software nach dem Stand der Technik. Eine Dokumentation, die nur der Sicherheitsklasse A genügt, erfüllt diese Anforderung nicht.
4. Software-FMEA
Eine FMEA ist eine Failure Mode and Effect Analysis, also ein Verfahren in der Risikoanalyse, das zu bekannten oder angenommen Fehlern unbekannte Folgen sucht.
Mehr zur FMEA finden Sie im verlinkten Beitrag.
Mit einer Software-FMEA möchten die Hersteller Folgen (nicht notwendigerweise Risiken) identifizieren, die durch Software-Fehler verursacht sind. D.h. sie untersuchen die Software — genauer gesagt die Software-Komponenten und Software-Einheiten — daraufhin, was passiert, wenn eben einer dieser Komponenten oder Einheiten fehlerhaft implementiert wird. Die Medizinprodukte-Hersteller versprechen sich davon eine Aufgabenteilung und eine modularere und damit besser „wartbare“ Risikomanagementakte.
a) Typische Fallen
Falle 1: Die falschen Personen
Die Software-FMEA wird häufig den Software-Entwicklern übertragen. Doch das Risikomanagement, insbesondere die Risikoanalyse bedarf entsprechender Kompetenzen. Software-Entwickler haben ihre Kompetenz in der Software-Entwicklung und nicht in der Risikoanalyse. Es geht um Rollen, nicht um Personen.
Besonders verfügen Software-Entwickler nicht
- über die Ausbildung, um eine FMEA überhaupt systematisch durchführen zu können
- über Kontextwissen, wie sich ein sich fehlerhaft verhaltendes Medizinprodukt bis zum Patienten auswirken kann
- das medizinische Wissen, mit welcher Wahrscheinlichkeit Gefährdungen zu Schäden eines bestimmten Schweregrads führen.
Es ist entscheidend, dass Sie festlegen, was das Ziel der Software-FMEA ist: Risiken im Sinne der Norm zu identifizieren oder Fehlverhalten der Software? Im ersten Fall sind die Hinweise zur Zusammensetzung des Teams besonders wichtig.
Falle 2: Falscher Granularitätsgrad
Die Software-FMEA — wie alle Bottom-Up-Verfahren — kann nicht entscheiden, auf welcher Granularitätsstufe die Risikoanalyse durchgeführt werden muss. Diese Entscheidung kann nur Top-Down z.B. mit einer FTA erfolgen.
Als Folge analysieren die Hersteller die Fehlerursachen viel zu granular, was sich rächt:
- Die Akte wird zu umfangreich, was die Effizienz senkt und die Kosten erhöht.
- Die Akte wird zu umfangreich, was den Überblick und damit die Wahrscheinlichkeit erhöht, die wirklichen Risiken zu übersehen.
- Die Software-Architektur muss bis auf diese Granularitätsstufe modelliert sein und zwar als präzises Komponentendiagramm, das nicht nur die Komponenten, sondern deren Interaktion und Abhängigkeiten erkennen lässt.
Falle 3: Unpräzises Zusammenspiel der Software-FMEA mit dem Rest der Risikomanagementakte
Die Ergebnisse der Software-FMEA müssen in die Gesamtrisikoanalyse mit einfließen. Doch häufig ist nicht einmal die Dokumentenstruktur dazu geeignet, die Ursachenketten sauber zusammenzuführen.
b) Tipps für eine Software-FMEA
Wenn Sie eine Software-FMEA erstellen möchten, empfehlen wir Ihnen:
- Machen Sie Ihren Software-Entwicklern klar, dass Sie nicht Risiken analysieren können und dürfen, sondern das Fehlverhalten des Software-Systems beschreiben müssen. Das bedingt, dass die externen Schnittstellen des Software-Systems präzise in den Software-Anforderungen spezifiziert wurden. Weiter ist es legitim, wenn gleich sehr schwer, dass die Softwerker die Wahrscheinlichkeit dieser Fehlverhalten abschätzen.
- Führen Sie eine detaillierte Software-FMEA zumindest für alle Software-Systeme durch, die SOUP-Komponenten enthalten.
- Modellieren Sie eine präzise Software-Architektur.
- Definieren Sie die „Schnittstelle der Dokumente“: Die Software-FMEA liefert die Fehlverhalten der Software und ggf. deren Wahrscheinlichkeiten. Diese Informationen fließen in die Risikoanalyse mit ein.
Dieses „Andocken“ der beiden Dokumente bedingt ein konsistentes Vorgehen oder/und Werkzeug-Unterstützung.
Das Johner Institut hilft!
Die Expertinnen und Experten des Johner Instituts helfen Ihnen,
- eine sichere und IEC 62304-konforme Software zu entwickeln und schlank zu dokumentieren,
- mögliche Risiken durch Software-Fehler zu finden und zu minimieren und
- eine ISO 14971-konforme Risikomanagementakte zu erstellen.
Melden Sie sich! Dann finden wir heraus, wie Sie mit einer soliden Software und einer kompakten Dokumentation schnell durch Audits und Zulassungen kommen und mit Ihrer Software erfolgreich im Markt sind.
Änderungshistorie
- 2023-04-01: Artikel überarbeitet (v.a. redaktionelle Änderungen, Abb. 3 ersetzt ) und Kapitel mit Software-FMEA integriert
- 2023-02: ISO 14971:2019 berücksichtigt.
- 2021-02: Kapitel 2b) überarbeitet und herausgearbeitet, dass es von der Definition des Begriffs abhängt, ob und wann eine falsche Anzeige eine Gefährdung darstellt.
Sehr gehrtes Team des Johner-Instituts,
herzlichen Dank für die Einführung der sehr hilfreichen Änderungshistorie zu Ihren Artikeln!
Sehr gerne Herr Vogtherr!
Ich freue mich über Ihre Wertschätzung! Dankeschön!
Das motiviert, nicht nur, aber auch diese Historie sorgsam zu pflegen.
Mit herzlichen Grüßen, Christian Johner
SW RM … „FMEA andersrum“: Nicht schauen, was passieren könnte, wenn SW Fehler und wie schlimm das ist, sondern „Preliminary Hazard Analysis“ per Design Input. „Was nicht passieren darf“. Und SW RM muss dann analysieren, ob/wie SW durch welche Fehler/Probleme… daran teilhaben könnte, dass was nicht passieren darf doch passiert. Dafür ausreichend Design Input, um auch die denkbaren Sequence of Events mitzuteilen, damit die SW Entwickler alle möglichen Zusammenhänge sehen können. So können sie optimal ihre Kompetenzen zum RM beitragen. Ohne – etwa für Software als Teil eines Medizinprodukts – den intended use verstehen zu müssen. Andersrum muss so nicht das Produkt-RM auch SW Details verstehen, um Risiken identifizieren und kontrollieren zu können. Gerade bei SW ist dieser „Team-Ansatz“ besonders wichtig.
Vielen Dank für diese sehr hilfreiche Ausführung, Herr Buttgereit. Ich gebe Ihnen uneingeschränkt recht. Nur um keine Verwirrung zu stiften: die SW-Risikoanalyse kann und soll sich trotzdem möglichst der FMEA-Methode bedienen. Die sagt ja nur etwas über die „Betrachtungsrichtung“, nämlich von unten nach oben. Die SW-Entwickler starten also bei möglichen Fehlern in den Komponenten und deren Schnittstellen zueinander und untersuchen die Auswirkung der Effekte nach oben, bis zu dem Punkt, den sie eben von oben vorgegeben bekommen (nicht bis zum Personenschaden). Meist ist das die Grenze der Softwarekomponente in Form von SW-Anforderungen oder Design-Spezifikationen, die unter anderem über die vorherige Preliminary Hazard Analysis ermittelt wurden. Dann bleiben die SW-Entwickler damit innerhalb ihrer Domäne und können trotzdem die Vorzüge der FMEA-Methode nutzen.
Sie haben damit auch die sehr wichtige Bedeutung der Preliminary Hazard Analyse unterstrichen, die bei vielen Herstellern noch zu kurz kommt.
Herzliche Grüße
Christian Rosenzweig