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.


Software-Risikomanagement für medizinische Software

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

CVSS Common Vulnerability Scoring System

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

Risikoprioritätszahl (RPZ): Definition und Berechnung

Firmen, die beispielsweise einen Bezug zur Pharmaindustrie haben, verwenden die Risikoprioritätszahl (RPZ). Es gibt jedoch Branchen, in denen das Risiko nicht über eine RPZ bewertet werden darf. Beispielsweise in der Medizintechnik ist die Definition der Risikoprioritätszahl nicht konform mit der Definition des Begriffs Risiko gemäß der ISO 14971. Das kann im Audit und bei Produktzulassungen zu Beanstandungen führen.

Weiterlesen

Machine Learning bei Banken: 5 Learnings

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
HAZOP - Leitworte

HAZOP – Risikoanalyse konform IEC 61882

Die HAZOP (Hazard and Operability) ist ein Gefährdungsanalyseverfahren, das die ISO 14971 neben der FMEA, FTA und PHA empfiehlt. Das deutsche Akronym für HAZOP (Hazard and Operability) lautet PAAG. Das steht für Prognose, Auffinden der Ursache, Abschätzen der Auswirkungen, Gegenmaßnahmen. Die Norm IEC 61882 beschreibt dieses Verfahren.  Inhaltsübersicht HAZOP im Überblick » Vorgehen nach IEC…

Weiterlesen

User Interface of Unknown Provenance UOUP

Definition des Begriffs UOUP (gemäß IEC 62366) Die IEC 62366-1:2015 (die Norm zur „Anwendung der Gebrauchstauglichkeit auf Medizinprodukte“) führt den Begriff UOUP ein und definiert ihn wie folgt: Eine UOUP (User Interface of Unknown Provenance) zu deutsch „Benutzerschnittstelle unbekannter Herkunft“ ist eine Benutzerschnittstelle oder Teile einer Benutzerschnittstelle mit unbekanntem Entwicklungsprozess, für die geeignete Aufzeichnungen eines gebrauchstauglichkeitsorientierten Entwicklungsprozesses gemäß IEC 62366-1 nicht…

Weiterlesen