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

Definition: Safety Assurance Case
„Ein Safety Assurance Case ist eine strukturierte Argumentation, die von einer Reihe von Beweisen gestützt wird, die wiederum in überzeugender und vollständiger Weise die valide Annahme erlauben, dass ein Produkt für eine bestimmte Nutzung in einer bestimmten Nutzungsumgebung sicher und wirksam ist.“
angelehnt an ISO 15026 und andere Quellen

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:

Definition: Assurance Case
„An assurance case is defined to be a quadruple of a claim c, a justification j of c, a set es of evidence and an argument g which assures c using es. “
Quelle ISO 15026-1, Kapitel 6.2

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.

Bild zeigt UML Diagramm: Ein vereinfachtes Meta-Modell von Safety Assurance Cases, wie es sich aus der ISO 15026-2 ergibt
Abb. 1: Ein vereinfachtes Meta-Modell von Safety Assurance Cases, wie es sich aus der ISO 15026-2 ergibt. Die abstrakte Entität „Support“ kennt die Norm nicht.

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.

Weiterführende Informationen

Sie finden hier eine kurze Einführung in die GSN und hier ein „Cheat-Sheet“ mit den Notationselementen.

Übersicht über die Notationselemente der Goal Structuring Notation (GSN)
Abb. 2: Übersicht über die Notationselemente der Goal Structuring Notation (GSN)

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.

Bild zeigt Beispiel für einen Safety Assurance Case, der mit der Goal Structuring Notation GSN modelliert ist.
Abb. 3: Beispiel für einen Safety Assurance Case, der mit der Goal Structuring Notation (GSN) modelliert ist.
Tipp

Ob absichtlich oder nicht: Die AAMI hat eine hier kostenfrei die ältere Version des AAMI TIR 38 aus dem Jahr 2014 zum Download bereitgestellt.

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.

Weiterführende Informationen

Der Artikel zum Erstellen von Zweckbestimmungen nennt Ihnen die Aspekte, die dieses Dokument festlegen sollte, um die regulatorischen Anforderungen zu erfüllen.

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
Vorsicht!

Beachten Sie: Die FDA wirf leider die Begriffe Gefährdung (hazard), Schaden (harm) und Ursachen (cause) durcheinander. Eine Verbrennung ist keine Gefährdung, sondern ein Schaden. Wahrscheinlich meint sie auch biologische oder chemische Gefährdung und nicht Verunreinigung. Denn eine ungewollte Reaktion (Schaden) wird nicht nur durch Verunreinigungen verursacht.

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
Tipp

Bei anderen Geräten existieren diese Listen an Gefährdungen und Ursachen nicht. Leiten Sie diese mit Hilfe der Methoden zur Gefährdungsanalyse wie der PHA, der FMEA oder der FTA ab.

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.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 4.4 / 5. Anzahl Bewertungen: 8

Geben Sie die erste Bewertung!


Kategorien: Risikomanagement & ISO 14971
Tags: ,

2 Kommentare

  1. Johan Goris | Mittwoch, 11. November 2020 um 23:21 Uhr - Antworten

    Dear Mr. Johner,

    to convince product test and certification Accredited Labs and Notified Bodies, the Safety Assurance Case approach will indeed only make sense for MD manufacturers … if bridged with Risk Management.

    Therefor I would add ‚Risk Assessment outcome‘ besides ‚intended use‘ as „context“ under paragraph 1.b)
    and refer to annexes C.x of ISO 14971 as non exhaustive checklists under paragraphs 4.b) & 4.c)

    TMHO Examples for „evidence“ under paragraph 1.b) need validation to become evidence.

    The leakage current example for „assumptions“ under paragraph 1.b) should also be validated against risk assessed requirements (eg. leakage currents ifo. correct applied part classification for the intended use).

    Best regards,
    Johan Goris


    • Prof. Dr. Christian Johner | Donnerstag, 12. November 2020 um 16:24 Uhr - Antworten

      Thank you very much, Mr. Goris!

      I appreciate very much your thoughts and added them directly to the article.

      Thanks indeed!

      Best regards, Christian Johner


Hinterlassen Sie einen Kommentar

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