Software Risikomanagement nach IEC 62304 und ISO 14971 – SW FMEA / FMECA bei Medizinprodukt-Software?

(Gast) Carina Schmitz

16/06/2021

Referenzen:

Wenn im Folgenden von IEC 62304 oder ISO 14971 gesprochen wird, sind folgende Ausgaben gemeint: IEC 62304:2006 + A1:2015 und EN ISO 14971:2012

Problemstellung:

Wir entwickeln eine Software/Firmware, welche Bestandteil eines Medizinprodukts ist. Die Software (bzw. das Softwaresystem) wird der Software-Sicherheitsklasse B oder C zugeordnet. Diese Zuordnung hat u.a. zur Folge das gemäß IEC 62304 ein Software Risikomanagement Prozess (Kapitel 7) gefordert ist.

Anspruch dieses Artikels:

Der folgende Artikel soll einen praktischen Ansatz darstellen, wie ein Software Risikomanagement Prozess dokumentiert werden kann und welche Methoden geeignet sind, mögliche Software Fehler zu identifizieren.

Methoden zur Identifizierung

Wie (leider) in vielen Fällen gibt die IEC 62304 keine konkreten Vorgaben welche Methodik zur Identifikation möglicher Software Fehler verwendet werden soll. In einigen Unternehmen werden Methoden wie etwa die FMEA (dt. Fehlzustandsart- und -auswirkungsanalyse) angewendet, da diese in der ISO14971 zusammen mit dem Risikomanagement erwähnt werden. Doch inwiefern eignen sich diese Methoden für Software-Risikomanagement?

 

Exkurs: FMEA und FMECA

Die FMEA ist als Analysetechnik für die Funktionsfähigkeit von Systemen in der IEC 60812 beschrieben. Die Technik wird branchenübergreifend angewendet und ist nicht spezifisch für die Medizinprodukte-Industrie. Genauer hat die FMEA ihren Ursprung im amerikanischen Militär und ist heute v.a. in der Automobilindustrie weit verbreitet.

Wird die FMEA um die Ausfallbedeutungsanalyse ergänzt, dann spricht man von einer FMECA (engl. failure modes, effects and criticality analysis)

DIE EINE und WAHRE FMEA gibt es vermutlich nicht. Jeder Industriezweig oder Firma nutzt die FMEA auf die für sich geeignete Weise. Jedoch vielen ist gemein, eine Risikoprioritätszahl (RPZ) zu verwenden.

Die Risikoprioritätszahl setzt sich in der deutschsprachigen Literatur aus den drei folgenden Komponenten zusammen:

  • B: Schwere/Bedeutung
  • E: Entdeckungswahrscheinlichkeit
  • A: Auftretenswahrscheinlichkeit

Die IEC 60812 spricht weiter auch von einer Risikoakzeptanzbeurteilung. Das kommt uns bekannt vor und darauf werden wir später noch einmal genauer eingehen.

Im Anhang der IEC 60812 gibt es Beispiele für die Erstellung einer FMEA bzw. FMECA. Auch dieses Schema kommt uns aus der Welt der ISO 14971 bekannt vor.

Forderungen der IEC 62304 bzgl. Software Risiko Management

Kehren wir nun zurück zu den Medizinprodukten. Die IEC 62304 schreibt einleitend:

„Software ist oft ein integraler Bestandteil der MEDIZINPRODUKTE-Technik. Um die SICHERHEIT und Wirksamkeit eines MEDIZINPRODUKTS, das Software enthält, herzustellen, bedarf es der Kenntnis darüber, was die Software bewirken soll, und des Nachweises darüber, dass die Software diese Wirkung erzielt, ohne unvertretbare RISIKEN zu verursachen.“

Den auch in anderen Bereichen (Qualitätsmanagementsystem, Klassifizierung der Medizinprodukte) bekannten risikobasierten Ansatz folgt die IEC 62304 weiter. Die Methodik dahinter ist die Software Sicherheitsklassifizierung, welche die Produkte in drei Klassen teilt: A, B, C.

Basierend auf der Einteilung der Software-Sicherheitsklassifizierung erfolgt die Tiefe der Dokumentation und Verifikationstätigkeiten. Hinweis: Dies soll einen Überblick darstellen. Der Artikel geht an dieser Stelle nicht tiefer auf das Thema ein, dies würde ein ganz eigene Diskussion nach sich ziehen.

Für Sicherheitsklasse B und C wird gefordert, dass ein Software Risikomanagement geplant wird. Für beide Klassen wird weiter gefordert, dass die Identifizierung und Vermeidung gemeinsamer Software Fehler geplant wird, die sogenannten common software defects.

Abgrenzung der IEC 62304 und der ISO 14971

Weiter wichtig: Umgang mit Software Änderungen. Wird hier bewusst nicht betrachtet.

Es ist zu erkennen, dass die in der ISO 14971 geforderten Aspekte der Risikobewertung in der IEC 62304 nicht vorkommen / gefordert sind.

Um es an dieser Stelle bereits vorweg zu nehmen: Dies ist auch der entscheidende Grund warum wir den Einsatz einer FMEA bzw. FMECA für nicht sinnvoll erachten. Denn der Einsatz einer RPZ in der FMEA ist schwierig zu begründen. Fällt die RPZ heraus, bleibt unserer Einschätzung nicht mehr viel übrig was den Einsatz einer FMEA begründet. Daher sehen wir es als sinnvoll an, die Software Risikoanalyse mit in die Systemrisikoanalyse gemäß 14971 zu integrieren. Wie wir das praktisch umsetzen, zeigen wir gleich.

Die Schwierigkeit mit der RPZ:

Wie oben erwähnt ergibt sich die RPZ aus der Schwere und P1 und P2 (in manchen Fällen auch nur P, wenn die Wahrscheinlichkeit kombiniert betrachtet wird).

In einigen FMEAs kommt man dann auf Werte für RPZ im Bereich RPZ = 10 * 10 * 10 = 1000. Häufig angewendet wird eine Risikoakzeptanzbeurteilung von < 100 und >= 100. Doch wie ist dies zu begründen? In den meisten Fällen fehlt die Evidenz und die Einstufung wirkt willkürlich, oder die Einstufung wird benutzt, um zu entscheiden, bis zu welcher Zahl die Maßnahmen durchgeführt werden und passt nicht zum As Low As Possible Prinzip.

Mit der ISO 14971 dagegen hat man eine sehr gute Methode an der Hand mit der wir, wie gewohnt, eine Risikomatrix aufstellen können. Die darin aufgeteilte Einschätzung des Risikos anhand der Darstellung von Schwere und Auftretenswahrscheinlichkeit begründet sich auf den im Risikomanagement und der klinischen Bewertung verfügbaren Daten.

Diese Daten können sein:

  • Normen
  • wissenschaftlich-technischen Daten;
  • Marktdaten von ähnlichen, bereits in Anwendung befindlichen Medizinprodukten einschließlich veröffentlichter Berichte über Vorkommnisse
  • Gebrauchstauglichkeitsuntersuchungen mit typischen Anwendern
  • klinische Daten
  • Ergebnissen geeigneter Untersuchungen
  • Gutachten
  • externen Qualitätsbeurteilungsprogrammen

Unsere Einschätzung sehen wir auch durch die Erläuterung im Anhang der IEC 62304 bestärkt:

„Das RISIKOMANAGEMENT von Software ist ein Teil des RISIKOMANAGEMENTS des gesamten MEDIZINPRODUKTS und kann vernünftigerweise nicht isoliert betrachtet werden.“

Aus den vorangegangenen Punkten kommen wir zu dem Schluss, dass alle Einträge einer „FMEA“, sprich mögliche Fehler und dazugehörige Ursachen, unabhängig einer RPZ als wertvoll anzusehen sind. Daher dient die „FMEA“ nur der reinen Identifikation solcher Elemente und behandelt alle gleichwertig. Es erfolgt keine quantitative Bewertung.

Anmerkung: Dies ist eine subjektive Einschätzung aus den Entwicklungsprojekten und erhebt nicht den Anspruch generell den Einsatz einer FMEA in Frage zu stellen. In einigen anderen Bereichen wie beispielsweise Produktion, gibt es eine ganz andere Sichtweise auf die Dinge. Wer in seinem Projekt und Audits gute Erfahrungen damit gemacht hat, sollte an seiner Strategie festhalten. Wir freuen uns aber, wenn der Artikel an dieser Stelle zum Nachdenken anregt und die ein oder andere Diskussion anstößt.

 

Beispiel einer möglichen Dokumentation eines Software Risiko Management Prozesses

Die Art und Weise wie dokumentiert wird, hängt im Wesentlichen vom zugrundeliegenden Qualitätsmanagementsystem, Entwicklungs- und Softwareentwicklungsprozess sowie dem Risikomanagement-Prozess ab.

 

1. Überblick über die notwendige Dokumentation in Zusammenhang mit SW Risk Management

2. Risiko Management Akte / Risikoanalyse Tabelle

Stellt sich noch die Frage wie oft wir das oben genannte Schema anwenden. Sollte man die Gefährdungen für jede SW Einheit betrachten oder nur einmal für das SW System? Die Antwort hierauf ergibt sich durch die SW Architektur. Läuft mein System auf lediglich einer Hardware und ist die Architektur entsprechend übersichtlich, würden wir nicht empfehlen das SW Risikomanagement auf mehrere Komponenten aufzuteilen. Schließlich sind die Maßnahmen, vorausgesetzt die SW Sicherheitsklassen sind gleich, in der Regel identisch.

Erstreckt sich das SW System aber auf mehrere, komplexere SW Systeme, auf unterschiedlicher Hardware, empfiehlt es sich diese Komponenten getrennt zu betrachten. Schließlich können sich bei so einer Architektur, verschiedene Effekte aus den gleichen SW Fehlern ergeben.


Geschrieben von (Gast) Carina Schmitz

Carina Schmitz ist Ingenieurin der Medizintechnik und Consultant bei be-on-Quality GmbH. Ihre Aufgaben umfassen dabei die Betreuung von Kunden rund um Qualitätsmanagementsysteme (ISO 13485, 21CFR820) und Zulassungsstrategien von Medizinprodukten. Durch langjährige Erfahrung im Bereich Verifikation und Validierung, besteht ein großes Verständnis von Entwicklungsaufgaben und deren Prozesssteuerung. Die kontinuierliche Verbesserung von Unternehmensabläufen durch die qualifizierte Durchführung von internen Audits und Inspektionen rundet das Profil ab.


Weitere Beiträge

  • 12/11/2024
  • Allgemein, Software, Testen, Tools

In sicherheitskritischen Softwareprojekten steht die Qualität der Software an erster Stelle. Besonders bei Klasse-C-Software, die nach strengen Normen wie IEC 62304 (Medizintechnik) zertifiziert werden muss, ist es essenziell, dass ...

Weiterlesen
  • 08/08/2024
  • Allgemein, Elektrostimulation, Software, Testen

Heutzutage sind Apps im Gesundheitsbereich sehr wichtig. Besonders Apps, die Daten von medizinischen Sensoren lesen und verarbeiten können, sind nützlich. Flutter ist ein Open-Source-Framework von Google, das sich hervorragend ...

Weiterlesen
  • 30/06/2024
  • Allgemein, Hardware, Software, Technik, Tools, Usability

KI – Was ist das denn überhaupt? Künstliche Intelligenz ist zurzeit in aller Munde, doch die wenigsten Menschen beschäftigen sich mit der Funktionsweise von künstlicher Intelligenz oder damit, was ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies