Software-Risikomanagement für medizinische Software

Freitag 13. Dezember 2019

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 die Herstellern 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ürs Risikomanagement harmonisierte Norm, kennt kein explizites Software-Risikomanagement. 

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

Weiterführende Informationen

Lesen Sie hier mehr zudem 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 an der Außenkante des Produkts (hier der Anzeige). Während bei physischen Geräten die elektrische Energie, die mechanische Energie, die Strahlungsenergie oder die chemischen Materialien (all das sind Gefährdungen) immer an der Außenkante des Medizinprodukts anliegen, ist die falsche Anzeige keine Gefährdung, auch wenn die ISO 14971 unglücklicherweise von informationellen Gefährdungen spricht.

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

Gefährdungen sind definitionsgemäß potentielle Schadensquellen. Das Johner Institut stimmt der Norm uneingeschränkt zu, dass Viren, ionisierende Strahlung und sich bewegende Teile potentielle Schadensquellen sind.

Aber eine Bedienungsanleitung? Eine unzureichende Spezifikation der Zweckbestimmung? Die Antwort auf diese Frage hängt von der spezifischen Festlegung / Einschränkung der Definition des Begriffs Gefährdung ab.

Wenn man festlegt, dass eine Gefährdung das letzte Element einer Ursachenkette vor der Gefährdungssituation ist, dann ist eine fehlerhafte Bedingungsanleitung ein Element einer Ursachenkette, an deren Ende eine Gefährdung, dann eine Gefährdungssituation und dann ein Schaden steht. Dann wären weder eine Bedienungsanleitung noch eine Spezifikation eine (direkte) potentielle Schadensquelle. Es sei denn das Dokument fällt Ihnen auf den Fuss.

Die Gefährdung bei einer Software, die Medikamentendosen bestimmt, wäre nicht die falsche Anzeige, sondern das falsche Medikament — eine chemische Gefährdung.

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 „herunter gehen“ muss, kann und wird es nicht geben. Starten Sie mit einer Trennung zwischen nach außen sichtbarem Fehlverhalten eines Produkts und den resultierenden Gefährdungen einerseits 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 mit der Analyse enden, 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 Antworten der Art „das hängt davon ab“ nicht geschätzt werden, 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 bei 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 welche Wahrscheinlichkeit eine Gefährdungssituation zu einem Schaden eines bestimmten Schweregrads führt.

Sie können also das Software-Risikomanagement also keinesfalls alleine den Software-Entwicklern überlassen. Damit meinen wir die Rollen, keine 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 gar keine Schäden durch die Software verursacht werden können, dann rechtfertigt das definitionsgemäß die Sicherheitsklasse A. Sie müssen dann weder aus Sicht einer 14971 noch einer 62304 die Software näher zu 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 muss man im Rahmen einer Produktnachverfolgung im Feld überwachen, dass die eigenen 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 die grundlegenden Anforderungen der MDR (u.a.) bezüglich Risikomanagement und Software-Lebenszyklus immer alle einhalten.

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

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

War dieser Artikel hilfreich? Bitte berwerten Sie:
1 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 51 vote, average: 5,00 out of 5

Autor des Beitrags " Software-Risikomanagement für medizinische Software

Johner Institut Gmbh

Logo Johner Institut klein

Bewertung 5 von 5 bei 1 Bewertungen


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

Kommentar schreiben