Safety Assurance Cases: Leidvolle Diskussionen mit Auditoren abkürzen

Sind Sie die Diskussionen mit Ihrer Benannten Stellen leid, ob Ihre Produkte ausreichend sicher sind? Dann wenden Sie Safety Assurance Cases an. Mit diesem Top-Down-Ansatz führen Sie leicht und elegant den nachvollziehbaren Beweis.

Mit einem Ansatz konform dem AAMI TIR 38, der ISO/IEC 15026 oder den Vorgaben der FDA haben Sie die Argumente auf ihrer Seite. Ihre Benannte Stelle wird nicht nur von der Konformität Ihrer Produkte überzeugt, sondern auch von Ihrer Professionalität angetan sein. Die Zulassung wird damit fast zur Formsache.

1. Was sind Safety Assurance Cases?

a) Definition #1

Diese Argumentation bedingt eine Reihe von bestimmten Aktivitäten, weshalb manche die Safety Assurance Cases auch als Methode bezeichnen.

b) Komponenten von Safety Assurance Cases

Die Beweisführung mit Hilfe von Safety Assurance Cases besteht aus mehreren Komponenten, wie sie die beispielsweise ISO 15026-2 benennt:

Komponente	Beispiele
Schlussfolgerung (Conclusion), zu der ein Prüfer (z.B. einer Benannten Stelle oder einer Behörde) kommen soll	Das Medizinprodukt erfüllt die regulatorischen Anforderungen.
Behauptung (Claim): Eine Aussage oder Zusicherung über eine Eigenschaft eines Produkts, Systems oder Subsystems, die belegt werden soll Die Claims betreffen meist die Sicherheit oder Leistungsfähigkeit. Ein Safety Assurance Case hat laut ISO 15026-2 einen oder mehrere Top-Level-Claims. Die Claims sind oft hierarchisch strukturiert.	Das Medizinprodukt ist sicher. (Top-Level-Claim) Die elektrischen Gefährdungen sind beherrscht. (Sub-Claim) Die Isolation ist ausreichend dimensioniert.
Kontext: Informationen z.B. über das Produkt, dessen Nutzung und Nutzungsumgebung	Zweckbestimmung, Ergebnisse der Risikoanalyse
Annahmen (Assumption): Voraussetzungen, die gegeben sein müssen, oder Sachverhalte, die üblicherweise auch ohne weitere Beweise akzeptiert werden bzw. unbestritten sind	Vorgesehene Anwender (z.B. mit Ausbildung und Erfahrungen) Ableitströme, die kleiner als von der IEC 60601-1 gefordert sind, stellen keine inakzeptablen Risiken dar.
Belege/Nachweise (Evidence): Daten, die für die Beweisführung bzw. Argumentation genutzt werden, die z.B. durch die Verifizierung und Validierung gewonnen.	Testergebnisse (z.B. von Sicherheitsmaßnahmen), Beobachtungen, Expertenmeinungen, wissenschaftliche Prinzipien, Forschungsergebnisse
Argumentation (Argument): Begründung dafür, dass die Nachweise (Evidence) geeignet sind, die Behauptung (Claim) zu untermauern
Manchmal formuliert man im Rahmen der Safety Assurance Cases zusätzlich eine Strategie für die Beweisführung.	Vollständige Induktion Auffinden und Beherrschen von Gefährdungen

Die ISO 15026-2 kennt zudem noch eine weitere Begründung, die Justification. Diese begründet aber nicht, weshalb ein Claim zutreffend ist, sondern weshalb man einen bestimmten Claim gewählt hat.

c) Definition #2

Entsprechend definiert die Norm Safety Assurance Cases wie folgt:

Die Regularien, insbesondere die grundlegenden Sicherheits- und Leistungsanforderungen geben viele Claims vor, die die Hersteller nachweisen müssen.

2. Struktur von Safety Assurance Cases

Ein Safety Assurance Case hat einen oder mehrere Top-Level-Claims, die das Ziel der Beweisführung sind. Deren Wahl benötigt eine „Justification“.

Claims können durch „Limitations“ eingeschränkt werden z.B. bezüglich der Dauer, der Sicherheit oder der Voraussetzungen.

Um einen Claim nachzuweisen, benötigt man entweder genau ein Argument oder einen oder mehrere (Sub-)Claims, Evidenzen oder Annahmen.

Argumente wiederum müssen durch einen oder mehrere Claims, Evidenzen oder Annahmen gestützt sein.

Die OMG (Object Management Group) hat ein genaueres Metamodell in ihrem Dokument Structured Assurance Case Metamodel (SACM) veröffentlicht, das allerdings nicht ganz deckungsgleich mit der ISO 15025-2 ist.

3. Grafische Darstellung von Safety Assurance Cases

a) Goal Structuring Notation

Die Goal Structuring Notation (GSN) hilft, die Safety Assurance Cases grafisch darzustellen. Das erleichtert den schnellen Überblick.

Auch der AAMI TIR 38 Medical device safety assurance case report guidance nutzt diese Notation.

Ein Ausschnitt eines Safety Assurance Cases, der mit der GSN modelliert wurde, kann dann wie in Abb. 3 dargestellt aussehen.

b) Weitere grafische Modellierungssprachen

Eine etwas einfachere Notation nennt sich Claim Argument Evidence (CAE). Auch für diese Sprache gibt es Modellierungswerkzeuge.

Auch SysML wird als Vielzweck-Modellierungssprache für die Darstellung von Safety Assurance Cases genutzt.

Mit allgemeinen Zeichenwerkzeugen wie draw.io lassen sich alle Notationen darstellen.

4. Vorgehen beim Erstellen von Safety Assurance Cases

a) Zweckbestimmung erstellen

Eine wichtige Voraussetzung, um Safety Assurance Cases zu erstellen, ist eine vollständige Zweckbestimmung einschließlich der vorgesehenen Nutzer und der vorgesehenen Nutzungsumgebung. Denn davon hängen der Kontext und einige Annahmen ab.

Die Checkliste in Anhang C der EN ISO 14971:20212 hilft, zum einen um die Zweckbestimmung und den Kontext zu bestimmen, und zum anderen um erste Risiken abzuleiten.

b) Top-Level-Claims formulieren

Die Hersteller müssen die Top-Level-Claims formulieren und dafür eine Strategie festlegen. Manche starten mit einer oder mehreren allgemeinen Behauptungen wie „Das Medizinprodukt ist sicher“. Andere leiten die Top-Level-Claims aus den Top-Level-Gefährdungen ab.

Beispiel Infusionspumpen

Für Infusionspumpen hat die FDA im Guidance-Dokument „Infusion Pumps Total Product Life Cycle“ diese Top-Level-Claims indirekt festgelegt. Denn die Claims müssen darin bestehen, dass die folgenden Probleme nicht auftreten:

• Fehler bei Verabreichung der Infusion, z.B. durch eine falsche Dosis, ein falsches Volumen, zum falschen Zeitpunkt oder Ort
• Inkorrekte Therapie durch ein falsch ausgewähltes oder verabreichtes Medikament
• Biologische oder chemische Verunreinigung, z.B. durch einen unbeabsichtigten Kontakt oder eine ungewollte biologische Reaktion von Menschen auf/mit einer Substanz
• Verletzung, z.B. Verbrennungen, Schnitte, Luftinfusionen, elektrischer Schock

Strategie

Eine der bewährten Strategien besteht in der Überlegung, dass die Sicherheit dann gewährleistet ist, wenn alle Gefährdungen bekannt und beherrscht sind.

Damit bieten sich für die Top-Level-Claims die Behauptungen an, dass genau diese Gefährdungen bzw. Gefährdungsklassen beherrscht sind.

c) Untergeordnete Claims formulieren

Die FDA gibt vor, dass Hersteller von Infusionspumpen die „Gefährdungsklassen“ in einzelne Gefährdungen zerlegen. Bei dieser Risikoanalyse müssen Sie verschiedene Ursachen (sources) betrachten:

• Operational Sources, z.B. eine Verstopfung der Leitung durch Ausfällung von Substanzen
• Environmental Sources, z.B. Fehlfunktionen durch EMV-Probleme
• Electrical Sources, z.B. Batterieversagen oder zu hohe Ableitströme
• Hardware Sources, z.B. Netzwerkfehler, Fehlalarme durch Sensorfehler
• Software Sources, z.B. Nullpointer-Exception, Memory Leak
• Mechanical Sources, z.B. Motorausfall oder Schädigung des Netzkabels
• Biological and Chemical Sources, z.B. nicht biokompatible Materialien oder Schädigung des Geräts durch Reinigungsmittel
• Use Sources, z.B. Fehlprogrammierung wegen mangelnder Gebrauchstauglichkeit

Die (Sub-)Claims, d.h. die Behauptungen des Herstellers, bestehen darin, dass genau diese Gefährdungen beherrscht bzw. die Ursachen beseitigt sind. Sub-Claims könnte somit lauten:

• Das System entdeckt Luftblasen und stoppt konsequent die Infusion.
• Die Risiken durch eine Überdosierung sind auf ein akzeptables Niveau verringert.

Die Strategie besteht somit auch auf dieser Ebene darin, alle relevanten Gefährdungen zu identifizieren und zu mitigieren.

d) Entscheiden, wie man Claims beweist

Die ISO 15026-2 nennt die Möglichkeiten, um Claims nachzuweisen. Hersteller können, wie oben dargestellt, zwei Wege beschreiten:

• Entweder begründet der Hersteller mit genau einem „Argument“, dass der Claim erfüllt ist. Dazu muss sich das Argument auf einen oder mehrere Claims, Evidenzen oder Annahmen stützen.
• Andernfalls muss er einen Claim durch einen oder mehrere (Sub-)Claims, Evidenz(en) oder Annahmen begründen.

Eine „Bibliothek“ bereits formulierter Argumente und Checklisten hilft Herstellern dabei, redundante Arbeit zu vermeiden und keine Argumente zu vergessen.

5. Fazit

a) Hilfreiche Methode

Safety Assurance Cases sind sinnvoll und helfen Herstellern, ihre Argumentation logisch strukturieren. Damit können sie sich, den Behörden und den Benannten Stellen plausibel machen, dass ihre Produkte den regulatorischen Anforderungen genügen.

Sie sind auch hilfreich, um bereits während der Entwicklung für identifizierte Risiken systematisch Maßnahmen zur Risikobeherrschung auf Vollständigkeit und Wirksamkeit zu bewerten. Hersteller sollten das Arbeiten mit den Safety Assurance Cases in den Entwicklungsprozess einweben, insbesondere beim Ableiten von Anforderungen und beim Erstellen von Systemarchitekturen.

Für Infusionspumpen schreibt die FDA diese Methode sogar vor.

b) Nützliche und weniger nützliche Literatur

Den Firmen, die Safety Assurance Cases nutzen wollen, stehen viele Quellen mit Vorgaben und Beispielen zur Verfügung, u.a..:

• Normen, z.B. die ISO-15025-Familie
• Technical Reports wie der AAMI TIR 38
• Das Guidance-Dokument der FDA zu den Infusionspumpen
• Spezifikationen mehrerer Modellierungssprachen wie der GSN
• Das Metamodell der OMG

Allerdings sind diese Dokumente nicht aufeinander abgestimmt. Unterschiedliche Notationen und Konzepte erschweren das Verständnis.

Das FDA-Dokument nutzt keine grafische Darstellung. Es ist nicht in sich konsistent und das Konzept der Strategie nutzt es nur implizit. Allerdings liefert dieses Guidance-Dokument für Hersteller von Infusionspumpen eine gute Checkliste − und außerdem ist es für diese Hersteller Pflicht.

Als interessant in diesem Kontext erscheint die IEC 60601-1: Sie definiert für viele Gefährdungen bereits Safety Assurance Cases, ohne dies explizit zu formulieren. Im Anhang A beschreibt die Norm die Strategien und Argumente.

c) Die Methode sinnvoll einsetzen

Entscheiden, ob man sie einsetzt

Hersteller sollten Safety Cases besonders dann einsetzen, wenn sie regulatorische gefordert sind oder wenn es keine Normen gibt, die ausreichend produktspezifisch sind.

Die Entscheidung für oder gegen diese Methode ist auch keine binäre. Es spricht nichts dagegen, einen ersten „Sicherheitsfall“ (wie es die deutsche ISO 15406-2 nennt) zu erstellen und dann über den Produktlebenszyklus hinweg weitere zu ergänzen. Diesen iterativen Ansatz kontinuierlicher Verbesserung schätzen Behörden und Benannte Stellen sehr.

Als Brücke zwischen Risikomanagement und Architektur nutzen

Falls Hersteller Safety Assurance Cases verwenden, können sie diese als Brücke zwischen Risikomanagement und Systemarchitektur nutzen:

• Die Claims entsprechen oft Aussagen, dass die Risiken beherrscht sind.
• Die Argumente entsprechen den Anforderungen, die das Produkt und damit dessen Architektur erfüllen müssen.

Der Top-Level-Claim entspricht oft einem der letzten Sätze des Risikomanagementberichts, mit dem der Hersteller bekräftigt, dass das Produkt sicher ist und dessen Nutzen die Restrisiken überwiegt.

Über den kompletten Produktlebenszyklus einsetzen

Genauso wie sich das Produkt weiterentwickelt und neue Erkenntnisse aus der Post-Market-Phase gewonnen werden, sollten die Hersteller auch die Safety Assurance Cases aktualisieren. Das bedeutet zwar zusätzlichen Aufwand. Aber damit sind die Grundlagen z.B. für den Post-Market Surveillance Update Report gelegt. Denn dieser Bericht soll schließlich bestätigen, dass das Produkt weiterhin sicher ist und der Nutzen die Risiken überwiegt.

d) Voraussetzungen müssen erfüllt sein

Safety Assurance Cases nehmen den Firmen das Denken nicht ab. Im Gegenteil: Diese Methode setzt voraus, in logischen Konzepten und dem MECE-Prinzip folgend denken zu können. Ohne solch ein präzises Denken verkommen die Safety Assurance Cases zu Grafiken, die nur die Illusion nähren, man habe die Beweise (für die Sicherheit der Produkte) geführt.

Auditoren, Behörden und Benannten Stellen werden solche Logikbrüche dort schneller finden als in einer Risikotabelle mit Tausenden von Einträgen.

Das gilt aber auch für das eigene Team: Es kann diese (eigenen) Fehler ebenso schnell erkennen und anschließend fundierte Argumentationsketten aufbauen. Und genau darin liegt die Stärke der Safety Assurance Cases.

---

Wünschen Sie Unterstützung beim Erstellen von Safety Assurance Cases? Wünschen Sie sich, dass jemand Ihre Argumente auf Vollständigkeit und Plausibilität prüft? Melden Sie sich z.B. über das Kontaktformular. Das Team des Johner Instituts freut sich auf Ihre Nachricht.