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 erreichen können.

1. Regulatorische Anforderungen an das Software-Risikomanagement

a) Gesetze

Die EU-Richtlinien bzw. die EU-Verordnungen für Medizinprodukte wie die MDR und die nationalen Gesetze unterscheiden Produkte mit und ohne Software bezüglich des Risikomanagements nicht.

b) Normen

Auch die ISO 14971, die für das Risikomanagement harmonisierte Norm, kennt kein explizites Software-Risikomanagement.

Nur die (alte) IEC 62304 durchquert mit ihrer (scheinbaren) Philosophie, dass Fehler in Software mit 100 Prozent Wahrscheinlichkeit anzunehmen sind, das Prinzip der ISO 14971 und deren Definition von Risiko, nämlich die Kombination von Schweregrad und Wahrscheinlichkeit von Schäden.

Weiterführende Informationen

Lesen Sie hier mehr zu Wahrscheinlichkeiten bei Software.

Die IEC 62304 stellt wenige für Software spezifische Anforderungen an das Risikomanagement bei medizinischer Software. Dazu zählt die Überwachung der SOUP.

2. Besonderheiten beim Software-Risikomanagement

a) Nur indirekte Schäden

Software führt erst einmal zu keinem Schaden. Software kann nicht verletzen oder gar töten. Zumindest nicht direkt. Die Schäden erfolgen immer indirekt über physische Geräte (z.B. quetschender Tisch,  strahlendes Gerät) oder über Menschen, die Patienten beispielsweise falsch oder gar nicht behandeln. Das macht das Software-Risikomanagement so herausfordernd.

Wenn Sie also ein Risikomanagement für Software betreiben wollen, dann müssen Sie die Ursachenkette von der fehlerhaften Software bis zum Patienten (oder ggf. Anwender) verfolgen.

b) Gefährdungen

Im Gegensatz zu physischen Geräten liegt bei Standalone-Software die Gefährdung nicht notwendigerweise an der Außenkante des Produkts (hier der Anzeige). Bei physischen Geräten liegen die elektrische Energie, die mechanische Energie, die Strahlungsenergie oder die chemischen Materialien (all das sind Gefährdungen) immer an der Außenkante des Medizinprodukts an.

Bei Software kann man eine falsche Anzeige auch als Gefährdung bezeichnen, denn sie ist eine potenzielle Schadensquelle. Die ISO 14971 spricht (unglücklicherweise) auch von informationellen Gefährdungen.

Gefährdungen ISO 14971
Quelle: ISO 14971, Tabelle E.1

Das Johner Institut empfiehlt, die Präzisierung der Definition zumindest zu erwägen: Nicht mehr jedes Element der Ursachenkette ist eine Gefährdung, sondern nur noch das letzte Element vor der Gefährdungssituation.

Wenn man sich auf diese ergänzende Definition einlässt, ist nicht mehr die falsche Anzeige, sondern das falsche Medikament die Gefährdung – eine chemische Gefährdung. Eine falsche Bedienungsanleitung oder eine unzureichende Spezifikation der Zweckbestimmung wären zwar weiterhin Elemente einer Ursachenkette, aber bei der eingeschränkten Definition keine Gefährdung mehr. Eine Ausnahme wäre eine Bedienungsanleitung, an der man sich schneidet oder die einem auf den Fuß fällt.

Diese ergänzende Definition hilft oft auch bei der Verwendung des Begriffs „Gefährdungssituation“, also den Umständen, unter denen Menschen, Güter oder die Umwelt einer oder mehreren Gefährdungen ausgesetzt sind: Ein Patient ist möglicherweise nie einer falschen Zweckbestimmung oder einer falschen Anzeige ausgesetzt, weil nur der Arzt bzw. die Ärztin diese sieht. Aber der Patient ist dem falschen Medikament ausgesetzt.

Achten Sie darauf, dass Sie beim Risikomanagement Ursachen, Gefährdungen, Gefährdungssituationen, Risiken und Schäden nicht verwechseln. Ihre Risikomanagement-Akte wird sonst im Audit zum Problem. Lassen Sie uns wissen, wenn wir helfen können (Kontakt via Webformular).

3. Tipps zum Risikomanagement für Software

a) Richtige Granularität

„Wie tief muss die Risikoanalyse der Software-Komponenten innerhalb der Architektur gehen? Muss man bis auf Klassenebene oder sogar bis auf die Methodenebene heruntergehen?“ So lauten häufige Fragen im Micro-Consulting des Johner-Instituts.

Eine Regel, wie weit man „heruntergehen“ muss, kann und wird es nicht geben. Starten Sie mit einer Trennung zwischen nach außen sichtbarem Fehlverhalten eines Produkts sowie den resultierenden Gefährdungen und der Ursachenkette, die zu diesem nach außen sichtbaren Fehlverhalten führt. Dies entspricht einer FMEA ab „Gerätekante“.

Software-Risikomanagement
Unterscheiden Sie beim Risikomanagement für (Standalone-) Software die innere und die äußere Ursachenkette

Nur falls für ein bestimmtes, nach außen sichtbares Fehlverhalten ein Risiko folgt, müssen Sie die Ursachenkette „nach innen“, d.h. bis auf Komponentenebene hin, untersuchen. Dies entspricht einer FTA ab „Gerätekante“ (Richtung Komponenten).

Diese zweite Untersuchung hat folgende Ziele:

  1. Zum einen wollen Sie die Ursachen und ggf. Wahrscheinlichkeiten für dieses Fehlverhalten herausfinden.
    Anmerkung: Diese Ursachen (z.B. fehlerhafte Komponenten) haben eine Wahrscheinlichkeit für ein Fehlverhalten, aber keinen Schweregrad. Dieser existiert nur in der äußeren Kette.
  2. Zum anderen wollen Sie untersuchen, ob es Möglichkeiten im Sinne einer risikominimierenden Maßnahme gibt, um eben diese Ursachenkette zu unterbrechen.

Sie können die Analyse beenden, sobald Sie eine Maßnahme definiert haben, die den Fehlerbaum abschneidet. Je höher die Ebene ist, auf der Ihnen das gelingt (idealweise nicht innerhalb des gleichen Software-Systems), umso besser.

Risikomanagement: FTA

Auch wenn eine Antwort wie „das hängt davon ab“ nicht geschätzt wird, ist sie doch die einzig mögliche auf die Frage nach der Tiefe der Untersuchung. Die meisten Firmen untersuchen zu tief und zu wenig breit. Das führt zu übergroßen Risikotabellen, die viel Arbeit verursachen, aber keine wirklichen Erkenntnisse liefern. Viele Risiken bleiben unerkannt.

Werfen Sie doch einen Blick in den Auditgarant. Dort stellen wir Ihnen mehrere Videotrainings zum Risikomanagement nach ISO 14971 auch für Software zur Verfügung.

Videotrainings im Auditgarant ansehen

b) Zusammensetzung des Teams für das Software-Risikomanagement

Das Risikomanagement ist ein Teamsport, an dem Sie beteiligen sollten:

  • Risikomanager: Experte für Regularien, Methoden, Dokumentation
  • Software- oder System-Architekt: Kennen innere Ursachenkette und können (nur) Wahrscheinlichkeiten abschätzen, dass sich die Software bzw. das System nach außen falsch verhalten
  • Kontext-Experte: Kann beurteilen, mit welcher Wahrscheinlichkeit ein äußeres Fehlverhalten des Systems zu eine Gefährdungssituation führt
  • Arzt/Ärztin: Kann beurteilen, mit welcher Wahrscheinlichkeit eine Gefährdungssituation zu einem Schaden eines bestimmten Schweregrads führt

Sie können also das Software-Risikomanagement keinesfalls alleine den Software-Entwicklern überlassen. Damit meinen wir die Rollen (und nicht konkrete Personen, die mehrere Rollen innehaben können).

c) Risikomanagement für Software und Sicherheitsklassen

Wenn Sie eine Software, konkret ein Softwaresystem, sicherheitsklassifizieren, dann muss dem eine Risikoanalyse vorausgegangen sein. Es ist vielleicht nicht zwingend notwendig, die Wahrscheinlichkeiten genau zu betrachten, aber definitiv die Schweregrade möglicher Schäden. Wenn das Ergebnis dieser Analyse ergibt, dass durch die Software gar keine Schäden verursacht werden können, dann rechtfertigt das definitionsgemäß die Sicherheitsklasse A. Sie müssen dann weder aus Sicht der ISO 14971 noch der ISO 62304 die Software näher beleuchten, beispielsweise bis auf Komponentenebene.

Man hat somit das Risikomanagement vor der Sicherheitsklassifizierung begonnen (und auch beginnen müssen), es endet aber nicht damit. Beispielsweise müssen Sie im Rahmen einer Produktnachverfolgung im Feld überwachen, dass Ihre Abschätzungen, die beispielsweise die Sicherheitsklasse A begründen, korrekt waren.

In anderen Worten: Sie müssen die Normen ISO 14971 und IEC 62304 immer beide einhalten. Korrekter wäre die Aussage: Sie müssen immer alle grundlegenden Anforderungen der MDR (u.a.) bezüglich Risikomanagement und Software-Lebenszyklus einhalten.

Wenn man eine gänzlich unkritische (Standalone-) Software hat, dann reduziert sich der Dokumentationsaufwand automatisch auf ein Minimum. Letztlich muss nur der Nachweissauber geführt werden, dass die Software wirklich unkritisch ist.

Bei Standalone-Software der Sicherheitsklasse A stellt sich häufig die Frage, ob man sicher ist, dass es sich überhaupt um ein Medizinprodukt handelt …


Änderungshistorie

  • 2021-02: Kapitel 2b) überarbeitet und herausgearbeitet, dass es von der Definition des Begriffs abhängt, ob und wann eine falsche Anzeige eine Gefährdung darstellt.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 5 / 5. Anzahl Bewertungen: 7

Geben Sie die erste Bewertung!


Kategorien: Risikomanagement & ISO 14971, Software & IEC 62304
Tags: ,

2 Kommentare

  1. Robert Vogtherr | Freitag, 26. Februar 2021 um 09:35 Uhr - Antworten

    Sehr gehrtes Team des Johner-Instituts,

    herzlichen Dank für die Einführung der sehr hilfreichen Änderungshistorie zu Ihren Artikeln!


    • Prof. Dr. Christian Johner | Freitag, 26. Februar 2021 um 09:47 Uhr - Antworten

      Sehr gerne Herr Vogtherr!

      Ich freue mich über Ihre Wertschätzung! Dankeschön!

      Das motiviert, nicht nur, aber auch diese Historie sorgsam zu pflegen.

      Mit herzlichen Grüßen, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.