Software-Risikomanagement für medizinische Software

Freitag 10. April 2015

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.

 

Regulatorische Anforderungen an das Software-Risikomanagement

Die EU-Richtlinien für Medizinprodukte und damit die nationalen Gesetze unterscheiden Produkte mit und ohne Software bezüglich des Risikomanagements nicht. Auch die ISO 14971, die fürs Risikomanagement harmonisierte Norm, kennt kein explizites Software-Risikomanagement. Nur die IEC 62304 durchquert mit Ihrer 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.

Lesen Sie hier mehr zu den Wahrscheinlichkeiten bei Software.

Besonderheiten beim Software-Risikomanagement

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.

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. Ich stimme der Norm uneingeschränkt zu, dass Viren, ionisierende Strahlung und sich bewegende Teile potentielle Schadensquellen sind. Aber eine Bedienungsanleitung? Eine unzureichende Spezifikation der Zweckbestimmung? Das sind Elemente einer Ursachenkette, an deren Ende eine Gefährdung, dann eine Gefährdungssituation und dann ein Schaden steht. Aber weder eine Bedienungsanleitung noch eine Spezifikation ist eine potentielle Schadensquelle. Es sei denn das Dokument fällt Ihnen auf den Fuss.

Die Gefährdung bei einer Software, die Medikamentendosen bestimmt, ist 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).

Tipps zum Risikomanagement für Software

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 in der kostenlosen Auditsprechstunde 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 ich Antworten der Art „das hängt davon ab“ nicht schätze, dann 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 stelle ich Ihnen mehrere Videotrainings zum Risikomanagement nach ISO 14971 auch bei Software zur Verfügung.

Videotrainings im Auditgarant ansehen

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 meine ich aber die Rollen, keine konkrete Personen, die mehrere Rollen innehaben können.

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 müsste ich schreiben: Sie müssen die grundlegenden Anforderungen der MDD (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 frage ich übrigens immer zurück, ob man sicher sei, dass es sich überhaupt um ein Medizinprodukt handelt…


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

Kommentar schreiben