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!
Was die Risikoanalyse bei Software von anderen Medizinprodukten unterscheidet
Bei (standalone) Software können Schäden nur „indirekt“ entstehen, beispielsweise dadurch dass
- die Software etwas Falsches anzeigt und daher Anwender z.B. Ärzte Patienten falsch behandeln,
- die Software das richtige anzeigt, aber die Anwender die Information abliest (Wahrnehmung, Perception) und daher falsch handeln,
- der Anwender die Information richtig abliest aber falsch verstehen (Cognition) und daher falsch handeln oder
- die Anwender an der Software (z.B. wegen mangelnder Gebrauchstauglichkeit) etwas Falsches eingeben oder auswählen, was wiederum zu einer falschen Anzeige oder zu einem falschen sonstigen Output am Medizinprodukt führen kann.
Granularität beim Risikomanagement für Software
Risikoanalyse bei Software: Die richtige Granularität
Wie detailliert soll die Risikoanalyse bei Software sein?
- Nicht zu granular: Eine Risikoanalyse bis auf die einzelne Code-Zeile dürfte in den meisten Fällen zu granular sein, die Risikomanagementakte unnötig aufblähen und dazu führen, dass man nicht nur unnötig viel Zeit aufwendet, sondern auch den Wald vor lauter Bäumen nicht mehr sieht und Risiken übersieht.
- Nicht zu grob-granular: Auf der anderen Seiten ist eine Analyse nur des ganzen Software-System oft unzureichend, um die Forderungen der IEC 62304 zu erfüllen.
Die Empfehlung wäre, die Risiken durch eine fehlerhafte Software zumindest für die Software-Komponenten der ersten Baustein-Ebene zu analysieren. D.h. man sollte in der Software-Architektur alle Top-Level-Komponenten des Software-Systems daraufhin analysieren, was passieren kann, wenn
- die Komponente einen falschen Input bekommt
- die Komponente über ihre Schnittstellen etwas Falsches nach außen übermittelt. Das setzt voraus, dass man weiß, welche externe Schnittstellen die jeweilige Software-Komponente hat. Wie Sie diese Schnittstellen spezifizieren und auf Risiken analysieren, lesen Sie im Kapitel „Risikoanalyse bei Software und Software-Komponenten“.
Risikobeherrschung bei Software: Die richtige Granularität
Die Risikoanalyse bei Software wird möglicherweise Risiken zu Tage führen, die Sie als Hersteller so weit wie möglich minimieren müssen. Idealerweise gelingt es Ihnen, diese risikominimierenden Maßnahmen außerhalb des Software-Systems zu realisieren.
Doch genau das wird Ihnen nicht immer gelingen. D.h. Sie benötigen risikominimierenden Maßnahmen innerhalb des Software-Systems.
In diesen Fällen müssen Sie auf tieferer Ebene in Ihrer Software Risiken identifizieren und beherrschen. Beispielsweise werden ein oder mehrere Software-Komponenten mit einer Datenbank über eine „SQL-Schnittstelle“ verbunden sein. Doch wie wollen Sie sicherstellen, dass über diese Schnittstelle keine fehlerhaften Daten in der Datenbank gespeichert werden?
Sie werden also jede der mit der Datenbank verbundenen Komponenten daraufhin untersuchen, was die Folgen wären, wenn sie (die Komponente) falsche Daten aus der Datenbank erhält. Und in genau diesen Fällen wird sich die Risikoanalyse Ihrer Software nicht auf die erste Bausteinebene beschränken können.
Risikoanalyse bei Software und Software-Komponenten
Streng genommen können Sie für Software-Komponenten überhaupt keine Risikoanalyse durchführen. Sie können aber abschätzen, welches äußere Fehlverhalten eine Software-Komponente haben kann — zumindest, wenn Sie die Schnittstellen der Software präzise spezifiziert haben. Eine Software-Komponente kann nur über folgende Schnittstellentypen verfügen:
- Schnittstellen zu anderen Software-Systemen oder Software-Komponenten: Diese Schnittstellen können Sie beispielsweise als API, als WSDL oder als Bus-Spezifikation beschreiben. Mehr dazu finden Sie in den Artikeln zur Interoperabilität und den Software-Anforderungen.
- Schnittstelle zum Benutzer (UI): Hier sollten Sie im Rahmen der Risikoanalyse zwei Unterfälle unterscheiden:
- Die Schnittstelle verhält sich nicht wie spezifiziert und zeigt falsche Informationen an: Was kann jetzt passieren? Wie oft wird ein Anwender Patienten aufgrund dieses Fehlers einen Schaden zufügen?
- Die Schnittstelle verhält sich wie spezifiziert und zeigt die richtige Information an — aber die Benutzer lesen sie falsch ab, verstehen sie falsch oder handeln deshalb falsch. Jetzt sind wir im Reich der Gebrauchstauglichkeit und der IEC 62366 angekommen. Das sind die Risiken durch mangelnde Gebrauchstauglichkeit.
- Schnittstelle zum Betriebssystem: Betriebssysteme bieten Funktionalitäten an wie Speicherverwaltung, Dateizugriff, Verwaltung von Prozessen und Threads usw. Im Rahmen Ihrer Risikoanalyse bei Software-Komponenten sollten Sie daher untersuchen, was passiert, wenn sich die Komponente nicht wie spezifiziert verhält, zu viel Speicher allokiert, zugesagten Speicher nicht zugeteilt bekommt, auf das Dateisystem nicht zugreifen kann, andere Prozesse beeinflusst usw.
Risikoanalyse bei Software-Änderungen
Wenn Sie die (embedded) Software Ihres Medizinprodukts ändern, wird das das Innenleben Ihres Produkts in Form einer oder mehrerer Komponenten betreffen. Dann empfehle ich Ihnen, ganz im Sinne einer FMEA zu analysieren, was passieren würde, wenn eine dieser Komponenten nun einen Fehler hätte. Sie verfolgen die Ursachenkette von der Komponente über die „Gerätekante“ bis hin zum Patienten.
Dazu benötigen Sie für „die innere Ursachenkette“ die Software-Architektur bzw. System-Architektur. Änderungen an der Software-Architektur können dazu führen, dass Komponenten neu miteinander bzw. mit den Inputs und Outputs verknüpft werden. Bei neuen oder geänderten (System) Anforderungen kann es sogar neue nach außen sichtbare Verhalten geben.
Falls es neue „nach außen sichtbare Verhalten“ gibt, werden Sie auch die äußere Ursachenkette neu bewerten müssen. Das kann aufwendiger sein und wird möglicherweise bedürfen, dass Sie Kontextexperten und/oder Ärzte mit einbeziehen.
Wenn es keine neuen nach außen sichtbaren Verhalten gibt, müssen Sie überlegen, ob die Wahrscheinlichkeit, dass sich das System nach außen falsch verhält, sich durch die Änderung erhöht oder erniedrigt. Dann würden sich nämlich die Risiken ändern.
Nur wenn es keine neuen oder in der Wahrscheinlichkeit geänderten nach außen sichtbaren Verhalten gibt, wissen Sie, dass das Risiko unverändert ist. Genau diese Überlegungen sind übrigens Risikoanalyse.
Wie Sie die innere und äußere Kette auch werkzeuggestützt „aneinanderhängen“ können, beschreibe ich in einen der Videotrainings im Auditgarant.
Videotrainings zur Risikoanalyse ansehen
Wenn Sie das Gefühl bekommen, dass Software-Änderungen doch etwas Arbeit nach sich ziehen können, haben Sie diesen Beitrag richtig verstanden. Bedenken Sie auch, dass sowohl die ISO 14971 als auch die noch spezifischer IEC 62304 klare Forderungen an die Analyse von Folgen bei (Software-)Änderungen stellen.
