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.
Um die Risiken zu identifizieren, müssen Hersteller die folgenden Voraussetzungen erfüllen:
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.
Das Ziel der Risikoanalyse ist es, Risiken zu identifizieren.
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:
Risiken sind Kombinationen aus der Wahrscheinlichkeit des Auftretens und des Schweregrads von Schäden. Daher müssen beide in diesem Schritt abgeschätzt werden.
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.
Unsere Tipps zur Risikoanalyse bei Software sind so umfangreich geworden, dass wir ihnen einen eigenen Artikel gewidmet haben.
Eine Gefährdung kann zu mehreren Risiken führen, wie das folgende Beispiel zeigt.
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.
Die ISO 14971 verlangt, dass das für das Risikomanagement verantwortliche Personal über die notwendigen Qualifikationen verfügt.
Nachdem die Risiken identifiziert und bewertet worden sind, müssen sie minimiert werden. Lesen Sie hierzu diesen Artikel.
Die Begriffe ‚vernünftigerweise vorhersehbarer Missbrauch‘ (‚reasonable foreseeable misuse‘), ‚anormaler Gebrauch‘ (‚abnormal use‘), ‚korrekter Gebrauch‘ (‚correct use‘) und ‚bestimmungsgemäßer Gebrauch‘ (’normal use‘) stammen aus den Normen ISO 14971 und IEC 62366-1. Leider erscheinen die Definitionen nicht gut aufeinander abgestimmt zu sein. Allerdings sind sie substantiell für das Verständnis, wie die Normen, in denen diese Begriffe erwähnt werden,…
WeiterlesenDie FDA hat das Guidance Dokument ‚Interoperable Medical Devices‘ am 6. September 2017 veröffentlicht. Die US-Behörde möchte damit der Tatsache Rechnung tragen, dass einerseits die Interoperabilität von Medizinprodukten immer wichtiger für die Gesundheitsversorgung wird. Andererseits führen Probleme mit mangelnder Interoperabilität immer häufiger zu Risiken. Dieser Beitrag verschafft Ihnen einen schnellen Überblick über die Anforderungen der FDA…
WeiterlesenDer Begriff „kritische Bauteile“ wird häufig im Kontext der IEC 60601-1 verwendet. Beispielsweise sei eine „Liste kritischer Bauteile“ zu erstellen. Auch wenn die Norm den Begriff „kritisches Bauteil“ weder verwendet noch definiert, gibt es Gründe, eine solche Liste an Bauteilen zu führen. Inhaltsübersicht Begriff und Beispiele » Regulatorische Anforderungen » Wann ist eine Komponente kritisch?…
WeiterlesenDer AAMI TIR 36 ist ein Best Pratice Guide, der den Titel “Validation of software for regulated processes“ trägt. Die AAMI möchte mit diesem „Technical Information Report“ Medizinprodukteherstellern Hilfestellung dabei geben, computerisierte Systeme zu validieren. Inhaltsübersicht Wer den TIR 36 lesen sollte » Übersicht über die Anforderungen » Verbindlichkeit, Ziel, Bezugsquelle » Stärken und Schwächen…
WeiterlesenNach dem Artikel zum Design Input geht es in diesem Beitrag um den Design Output, einen Begriff, den Sie wahrscheinlich am ehesten aus dem FDA Umfeld kennen. Inhaltsübersicht Begriffsdefinitionen » Regulatorische Anforderungen » Inhalt des Design Outputs »
WeiterlesenUnter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt. Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt. Inhaltsübersicht Definition „Design Input“ » Regulatorische Anorderungen » Inhalte des Design Inputs » Risikoanalyse als Design Input »
WeiterlesenAnormaler Gebrauch: Eine von vielen möglichen Fehlhandlungen Irrtum, Benutzungsfehler, anormaler Gebrauch, Aufmerksamkeitsfehler, vernünftigerweise vorhersehbarer Erinnerungsfehler, vorhersehbarer Missbrauch. Die Liste möglicher (Fehl-) Handlungen ist lang, die die Normen betrachtet haben möchten. Doch Vorsicht: Die Normen zur Gebrauchstauglichkeit (IEC 62366:2007 und IEC 62366-1:2015) und die Norm zum Risikomanagement (ISO 14971) verwenden unterschiedliche Begriffe. Dieser Artikel bringt Licht ins…
WeiterlesenDie ISO 31000 ist eine Basisnorm für das Risikomanagement. Sie soll nicht als Grundlage für Zertifizierungen dienen, sondern Handlungsleitung für ein effektives und effizientes Risikomanagement geben – unabhängig von der Domäne einer Organisation. Dieser Artikel möchte Ihnen als Medizinprodukte-Hersteller eine Übersicht über die ISO 31000 verschaffen, damit Sie schnell entscheiden können, ob Sie deren Prinzipien…
Weiterlesen
CIRS sind seit Jahren im Gesundheitswesen und der Luftfahrt gesetzlich vorgeschrieben, um Meldungen über kritische Vorkommnisse anonym sammeln, auswerten und daraus Schlüsse für ein sichereres Arbeiten ziehen zu können. Bei Medizinprodukteherstellern sind CIRS keine Pflicht. Ein Fehler? Lesen Sie, wie Sie als Medizinproduktehersteller von CIRS profitieren können.
Die Risikoanalyse bei Software unterscheidet sich: Software selbst kann keine Schäden verursachen. Dies geschieht immer via Hardware oder Menschen. Doch das heißt nicht, dass es keiner Risikoanalyse bei Software bedarf. Im Gegenteil!
