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.
Die Prozess-FMEA (pFMEA) ist eine Methode zur systematischen Analyse von Risiken, die sich durch Fehler in Prozessen wie der Produktion und Reinigung von Produkten ergeben. Gesetze wie die MDR und Normen wie die ISO 13485 verpflichten die Medizinproduktehersteller dazu, solche Prozessrisiken zu identifizieren und zu beherrschen.
Weiterlesen
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…
Weiterlesen
Die dritte Ausgabe der ISO 14971 steht seit Dezember 2019 bereit. Die neue Version der ISO 14971 wurde als ISO 14971:2019 publiziert. Sie ist eine evolutionäre Weiterentwicklung der ISO 14971:2007 und bricht nicht mit den bisherigen Konzepten. Inhaltsübersicht 1. ISO 14971, dritte Ausgabe » 2. Änderungen im Überblick » 3. Rechtliche Verbindlichkeit » 4.…
Weiterlesen
Das Common Vulnerability Scoring System CVSS dient in der IT Security nicht nur der Klassifizierung des Schweregrads von Software-Schwachstellen. Dieses CVSS-Framework wird auch genutzt, um diese Schwachstellen zu charakterisieren und einheitlich zu einzuschätzen. Lernen Sie dieses Common Vulnerability Scoring System CVSS verstehen und damit die Meldungen der NIST. Diese Meldungen sollten Sie als Hersteller (z.B.…
Weiterlesen
Sind Sie die Diskussionen mit Ihrer Benannten Stellen leid, ob Ihre Produkte ausreichend sicher sind? Dann wenden Sie Safety Assurance Cases an. Mit diesem Top-Down-Ansatz führen Sie leicht und elegant den nachvollziehbaren Beweis. Mit einem Ansatz konform dem AAMI TIR 38, der ISO/IEC 15026 oder den Vorgaben der FDA haben Sie die Argumente auf ihrer…
Weiterlesen
Zunehmend finden autonome Systeme auch in der Medizin Verwendung. Zu diesen autonomen Systemen zählen einzelne Medizinprodukte wie OP-Roboter. Aber auch Kombinationen einzelner (Medizin-)Produkte bilden autonome Systeme. Vielen Medizinprodukteherstellern und Krankenhäusern ist nicht klar, welche Chancen ihnen diese autonomen Systeme bieten, welche regulatorischen Anforderungen sie dabei beachten müssen, welche Risiken sie beherrschen müssen, die bei vielen…
Weiterlesen
Die FMEA, die Failure Mode and Effect Analysis (auf Deutsch „Fehlermöglichkeits- und -einflussanalyse“) ist ein Verfahren, um zu bekannten Ursachen unbekannte Auswirkungen zu untersuchen. Bei Medizinprodukten nutzt man die FMEA beispielsweise bei der Risikoanalyse, um die Folgen einer fehlerhaften Komponente zu analysieren, insbesondere die sich daraus ergebende Gefährdungen.
Weiterlesen
Die Fehlerwahrscheinlichkeit bei Software lässt sich schwer abschätzen. So schwer, dass die „alte“ DIN EN IEC 62304:2006 schrieb: „Es gibt jedoch keine Übereinstimmung, wie die Wahrscheinlichkeit des Auftretens von Software-Ausfällen unter Verwendung von traditionellen statistischen Methoden bestimmt werden kann.“ Die Norm schlussfolgerte, dass „die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden muss“. Die hochproblematische…
Weiterlesen
Seit vielen Jahren nutzen Banken das Machine Learning. Von diesen Erfahrungen können andere Branchen profitieren: die Medizinproduktehersteller, aber auch prüfende Organisationen wie Behörden und Benannte Stellen. Aus den Parallelen beider Branchen lassen sich fünf Best Practices sowie Empfehlungen ableiten und damit Kosten und unnötiger Ärger mit Prüfern vermeiden. Inhaltsübersicht 1. Gemeinsamkeiten » 2. Wo die…
Weiterlesen
Die DIN EN ISO 17664:2018 trägt den Titel „Aufbereitung von Produkten für die Gesundheitsfürsorge – Vom Medizinprodukt-Hersteller bereitzustellende Informationen für die Aufbereitung von Medizinprodukten“. Allerdings geht es nicht nur um die „bereitzustellenden Informationen“. Vielmehr betrifft die Norm auch die Tätigkeiten und Prozesse im Kontext der Aufbereitung. Was die MDR im Gegensatz zur MDD fordert, was jeder…
Weiterlesen