Schlagwort: Risikoanalyse | z.B. Beispiel für Projekte & Software
Unter einer Risikoanalyse versteht man das Suchen von Gefährdungen und der Abschätzung der Wahrscheinlichkeiten und Schweregrade resultierender Schäden.
Typisches Vorgehen bei der Risikoanalyse
Das Ziel der Risikoanalyse besteht darin, Risiken zu identifizieren. Üblicherweise gehen Medizinproduktehersteller bei der Risikoanalyse wie folgt vor:
- Gefährdungen suchen. Dazu wenden Sie meist folgende Verfahren zur Gefährdungsanalyse an:
- PHA (Preliminary Hazard Analysis)
- FMEA (Failure Mode and Effect Analysis)
- FTA (Fault Tree Analysis)
- HAZOP (Hazard Operability)
- Wahrscheinlichkeiten und Schweregrade resultierender Schäden (und damit die Risiken) abschätzen.
- Über die Vertretbarkeit dieser Risiken entscheiden (siehe Risikoakzeptanz)
Besonderheiten der Risikoanalyse bei Software
Unsere Tipps zur Risikoanalyse bei Software sind so umfangreich geworden, dass wir sie in einen eigenen Artikel ausgelagert haben. Lesen Sie diesen hier.
Typische Fehler bei der Risikoanalyse bei Medizinprodukten
Die folgenden Fehler bei der Risikoanalyse führen im Audit oder der Einreichung der technischen Dokumentation immer wieder zu Problemen:
- Die Risiken, die aus technischen Problemen wie Softwarefehlern rühren, sind völlig überbewertet. Probleme durch mangelnde Gebrauchstauglichkeit sind unzureichend analysiert. Die Ursachenkette von der „Gerätekante“ bis zum Schaden ist nicht genau genug bekannt.
- Das liegt darin, dass nicht alle notwendigen Rollen vertreten sind: Um Risiken systematisch zu erfassen, bedarf es eines Teams aus Ärzten, Entwicklern, Experten für Risikoanalyseverfahren und Kennern des klinischen Kontext, beispielsweise Pflegekräfte (siehe unten).
- Die Wahrscheinlichkeiten, mit denen diese Probleme wirklich zu einem Schaden führen, sind in Unkenntnis des klinischen Kontexts entweder falsch oder völlig willkürlich gewählt.
- Ursachen und Gefährdungen sind verwechselt. So werden Softwarefehler oder der Ausfall eines Hardware-Bauteils als Gefährdung bezeichnet.
- Als einziges Gefährdungsanalyseverfahren wird – wenn überhaupt – die FMEA angewendet. Meist nennt sich die Risikoanalyse nur FMEA.
Eine Gefährdung, mehrere Risiken?
Die Norm ISO 14971 zum Risikomanagement definiert ein Risiko als eine Kombination aus Wahrscheinlichkeit und Schweregrad eines Schadens. Ein Schaden ist in unserem Kontext eine physische Verletzung eines Patienten. Üblicherweise beschreiben Unternehmen in einer Risikobewertungsmatrix, welche Risiken sie akzeptieren und welche nicht.
Kann es sein, dass eine Gefährdung zu mehreren Risiken führt? Falls ja, wie wären diese zu dokumentieren?
Beispiel
Beispielsweise kann ein Patient zu Schaden kommen, weil das KIS einen Laborwert fälschlicherweise als negativ statt als positiv gespeichert hat (ist schon öfters vorgekommen) und in Folge dessen ein falsches Medikament verabreicht wird. Als Folge kann ein Patient zu Tode kommen oder „nur“ unter Übelkeit leiden.
Abhängig von Ihrer Definition der Schadensklassen könnte der erste Schaden (Tod) als katastrophal, der zweite (Übelkeit) als geringfügig definiert werden. Welchen Schaden trägt man nun ein?
Die Antwort lautet: beide. Sie hätten also zwei Einträge in der Risikomatrix, einen katastrophalen Schaden (typischerweise mit einer geringeren Wahrscheinlichkeit) und einen geringfügigen Schaden (typischerweise mit einer höheren Wahrscheinlichkeit).
Risikoanalyse: Die richtige Ausbildung/Qualifikation
Die ISO 14971 verlangt, dass das für das Risikomanagement verantwortliche Personal über die notwendigen Qualifikationen verfügt.
Nur welche sind das? Die IEC 80002 gibt uns dazu ein paar Hinweise:
- Zuerst sollte man etwas vom Risikomanagement selbst verstehen. Dazu zählen die Verfahren zur Risikoanalyse und die Fähigkeit, die Dokumente für eine Risikomanagementakte zu erstellen.
- Software Ingenieure und Mitarbeiter des Test-Teams sollten involviert sein.
- Der Risikomanager sollte selbst etwas von Software verstehen.
- Es müssen Domänenexperten eingebunden werden, die beispielsweise abschätzen können, wie das Produkt tatsächlich genutzt/missbraucht wird. Hier sehe ich Vertreter des medizinischen Personals als notwendig.
- Weiter sollte jemand dabei sein, der die direkten und indirekten klinischen Folgen einer Gefährdungssituation abschätzen kann. Meines Erachtens sollte das ein Arzt sein.
- Man sollte nicht – wie das häufig zu beobachten ist – für die Wartung (nur) die unerfahrenen Entwickler einsetzen. Denen sind häufig die möglichen Folgen einer Änderung für die Software selbst, v.a. aber für einen Patienten nicht bewusst.
- Weiter schlagen die Autoren der IEC 80002 Experten für die Software-Entwicklung, SOUPs, Werkzeuge usw. vor.
Ich kann diesen Einschätzungen nur zustimmen. Ich möchte aber einen Schritt weiter gehen: Das Risikomanagement gehört NICHT in die Hand der Entwicklungsabteilung. Der Risikomanager muss eine unabhängig Person sein, die die Verfahren beherrscht und Ärzte, Anwender und die Entwickler beim Erstellen der Risikomanagementakte „orchestriert“
Mit dem Auditgarant können Sie die geforderten Kompetenzen und auf Wunsch auch ein Zertifikat erwerben.
