Unter einer Risikoanalyse versteht man das Suchen von Gefährdungen und die Abschätzung der Wahrscheinlichkeiten sowie Schweregrade resultierender Schäden.

Wenn von Risikoanalyse gesprochen wird, ist oft ist eine Gefährdungsanalyse gemeint.

1. Voraussetzung für die Gefährdungs-/Risikoanalyse

Um die Risiken zu identifizieren, müssen Hersteller die folgenden Voraussetzungen erfüllen:

Hinweis

Die Übersichtsseite zum Risikomanagement und zur ISO 14971 verschafft einen Überblick über alle Aktivitäten im Risikomanagementprozess sowie die gesetzlichen Anforderungen daran. Für Krankenhäuser ist auch die ISO 80001-1 relevant.

2. Methoden der Gefährdungs-/Risikoanalyse

Das Ziel der Risikoanalyse ist es, Risiken zu identifizieren.

Schritt 1: Gefährdungen identifizieren (Gefährdungsanalyse)

Der erste Schritt besteht darin, basierend auf der Zweckbestimmung, den sicherheitsrelevanten Merkmalen des Produkts sowie ggf. dessen Designs die Gefährdungen zu suchen.

Dazu empfehlen sich die Verfahren zur Gefährdungsanalyse:

  1. PHA (Preliminary Hazard Analysis)
  2. FMEA (Failure Mode and Effect Analysis)
  3. FTA (Fault Tree Analysis)
  4. HAZOP (Hazard Operability)

Schritt 2: Wahrscheinlichkeiten und Schweregrade resultierender Schäden abschätzen

Risiken sind Kombinationen aus der Wahrscheinlichkeit des Auftretens und des Schweregrads von Schäden. Daher müssen beide in diesem Schritt abgeschätzt werden.

Schritt 3: Über die Vertretbarkeit der Risiken entscheiden

Anhand der Risikoakzeptanz entscheiden die Hersteller über die Vertretbarkeit der Einzelrisiken, später über die Vertretbarkeit aller (Rest-)Risiken.

Streng genommen zählt dieser Schritt nicht mehr zu Risikoanalyse.

3. Tipps zur Risikoanalyse

a) Besonderheiten der Risikoanalyse bei Software berücksichtigen

Unsere Tipps zur Risikoanalyse bei Software sind so umfangreich geworden, dass wir ihnen einen eigenen Artikel gewidmet haben.

b) Beachten, dass eine Gefährdung zu mehreren Risiken führen kann

Eine Gefährdung kann zu mehreren Risiken führen, wie das folgende Beispiel zeigt.

Beispiel

Wenn ein Krankenhaus-Informationssystem einen Laborwert fälschlicherweise als negativ statt als positiv gespeichert hat und die Ärztin deshalb ein falsches Medikament verabreicht, kann ein Patient zu Schaden kommen. Der Patient kann 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. Beide Schäden haben jedoch eine unterschiedliche Wahrscheinlichkeit.

c) Qualifikation der beteiligten Personen sicherstellen

Die ISO 14971 verlangt, dass das für das Risikomanagement verantwortliche Personal über die notwendigen Qualifikationen verfügt.

  • Risikomanager
    • Methoden der Gefährdungsanalyse und Risikoanalyse
    • Regulatorische Anforderungen an das Risikomanagement
    • Moderationsfähigkeit, Projektleitungskompetenz
    • Fähigkeit, das Risikomanagement zu dokumentieren (Dokumente, Werkzeuge)
  • Technische Experten
    • Genaues Verständnis der System- und Software-Architekturen
    • Kenntnisse der internen und externen Schnittstellen
    • Kenntnisse der Bauteile und Technologien sowie deren Fehlermöglichkeiten
  • Kontextexpertinnen und -experten
    • Genaue Kenntnis des Nutzungskontextes
    • Fähigkeit, Gefährdungssituationen abzuschätzen, die aus Nutzungsfehlern und aus System-Fehlverhalten resultieren
  • Ärztinnen und Ärzte
    • Kenntnis des Gesundheitszustands der vorgesehenen Patienten
    • Fähigkeit, die Schweregrade und Wahrscheinlichkeiten abzuschätzen, die sich aus den Gefährdungssituationen ergeben
Weiterführende Informationen

Nachdem die Risiken identifiziert und bewertet worden sind, müssen sie minimiert werden. Lesen Sie hierzu diesen Artikel.


Fehlerbaumanalyse | FTA: Fault Tree Analysis

Die Fault Tree Analysis, auf deutsch Fehlerbaumanalyse, ist ein Verfahren, um zu bekannten Wirkungen (bei Medizinprodukten Schäden oder Gefährdungen) unbekannte Ursachen zu suchen. Daher zählt sie bei der Risikoanalyse als Top-Down-Verfahren Fault Tree Analysis: Notation Bereits der Name Fault Tree Analysis macht klar, wie man sie grafisch repräsentiert: Als Baum. Sowohl Mindmaps als auch Ishikawa (Fischgräten-Diagramme) sind solche Baumstrukturen. Allerdings erlauben…

Weiterlesen

Wahrscheinlichkeit bei Software: IEC 62304 verwirrt

Der Satz in der IEC 62304, der wahrscheinlich zu den meisten Diskussionen führt, ist der zur Wahrscheinlichkeit bei Software: „Wenn die GEFÄHRDUNG davon herrühren könnte, dass das SOFTWARE-SYSTEM sich nicht entsprechend seiner Spezifikation verhält, muss die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden.“ Solange die zweite Ausgabe der IEC 62304 diese missverständlich Aussage nicht…

Weiterlesen