{"id":3821856,"date":"2020-11-10T09:00:00","date_gmt":"2020-11-10T08:00:00","guid":{"rendered":"https:\/\/www.johner-institut.de\/blog\/?p=3821856"},"modified":"2023-04-12T13:23:42","modified_gmt":"2023-04-12T11:23:42","slug":"safety-assurance-cases","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iso-14971-risikomanagement\/safety-assurance-cases\/","title":{"rendered":"Safety Assurance Cases: Leidvolle Diskussionen mit Auditoren abk\u00fcrzen"},"content":{"rendered":"\n

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\u00fchren Sie leicht und elegant den nachvollziehbaren Beweis.<\/p>\n\n\n\n

Mit einem Ansatz konform dem AAMI TIR 38<\/strong>, der ISO\/IEC 15026<\/strong> oder den Vorgaben der FDA haben Sie die Argumente auf ihrer Seite. Ihre Benannte Stelle wird nicht nur von der Konformit\u00e4t Ihrer Produkte \u00fcberzeugt, sondern auch von Ihrer Professionalit\u00e4t angetan sein. Die Zulassung wird damit fast zur Formsache.<\/p>\n\n\n\n\n\n\n\n

1. Was sind Safety Assurance Cases?<\/h2>\n\n\n\n

a) Definition #1<\/h3>\n\n\n\n
\n
\n <\/i> Definition: Safety Assurance Case<\/dfn>\n <\/div>\n
\u201eEin Safety Assurance Case ist eine strukturierte Argumentation, die von einer Reihe von Beweisen gest\u00fctzt wird, die wiederum in \u00fcberzeugender und vollst\u00e4ndiger Weise die valide Annahme erlauben, dass ein Produkt f\u00fcr eine bestimmte Nutzung in einer bestimmten Nutzungsumgebung sicher und wirksam ist.\u201c<\/dd>\n
angelehnt an ISO 15026 und andere Quellen<\/div>\n<\/div>\n\n\n\n

Diese Argumentation bedingt eine Reihe von bestimmten Aktivit\u00e4ten, weshalb manche die Safety Assurance Cases auch als Methode<\/strong> bezeichnen.<\/p>\n\n\n\n

b) Komponenten von Safety Assurance Cases<\/h3>\n\n\n\n

Die Beweisf\u00fchrung mit Hilfe von Safety Assurance Cases besteht aus mehreren Komponenten, wie sie die beispielsweise ISO 15026-2<\/a> benennt:<\/p>\n\n\n\n

Komponente<\/strong> <\/td>\n

Beispiele<\/strong><\/p>\n <\/td><\/tr>

\n

Schlussfolgerung (Conclusion)<\/strong>, zu der ein Pr\u00fcfer (z.B. einer Benannten Stelle<\/a> oder einer Beh\u00f6rde) kommen soll<\/p>\n <\/td>

\n

Das Medizinprodukt erf\u00fcllt die regulatorischen Anforderungen.<\/p>\n <\/td><\/tr>

\n

Behauptung (Claim)<\/strong>: Eine Aussage oder Zusicherung \u00fcber eine Eigenschaft eines Produkts, Systems oder Subsystems, die belegt werden soll<\/p>\n

Die Claims betreffen meist die Sicherheit oder Leistungsf\u00e4higkeit.<\/p>\n

Ein Safety Assurance Case hat laut ISO 15026-2 einen oder mehrere Top-Level-Claims. Die Claims sind oft hierarchisch strukturiert.<\/p>\n <\/td>

\n

Das Medizinprodukt ist sicher. (Top-Level-Claim)<\/p>\n

Die elektrischen Gef\u00e4hrdungen sind beherrscht. (Sub-Claim)<\/p>\n

Die Isolation ist ausreichend dimensioniert.<\/p>\n <\/td><\/tr>

\n

Kontext<\/strong>: Informationen z.B. \u00fcber das Produkt, dessen Nutzung und Nutzungsumgebung<\/p>\n <\/td>

\n

Zweckbestimmung, Ergebnisse der Risikoanalyse<\/p><\/td><\/tr>

\n

Annahmen (Assumption): <\/strong>Voraussetzungen, die gegeben sein m\u00fcssen, oder Sachverhalte, die \u00fcblicherweise auch ohne weitere Beweise akzeptiert werden bzw. unbestritten sind<\/p>\n <\/td>

\n

Vorgesehene Anwender (z.B. mit Ausbildung und Erfahrungen)<\/p>Ableitstr\u00f6me, die kleiner als von der IEC 60601-1 gefordert sind, stellen keine inakzeptablen Risiken dar. <\/td><\/tr>

Belege\/Nachweise (Evidence): <\/strong>Daten, die f\u00fcr die Beweisf\u00fchrung bzw. Argumentation genutzt werden, die z.B. durch die Verifizierung und Validierung gewonnen.<\/p> <\/td>

\n

Testergebnisse (z.B. von Sicherheitsma\u00dfnahmen), Beobachtungen, Expertenmeinungen, wissenschaftliche Prinzipien, Forschungsergebnisse<\/p>\n <\/td><\/tr>

\n

Argumentation (Argument): <\/strong>Begr\u00fcndung daf\u00fcr, dass die Nachweise (Evidence) geeignet sind, die Behauptung (Claim) zu untermauern<\/p>\n <\/td>

\n

 <\/p>\n <\/td><\/tr>

\n

Manchmal formuliert man im Rahmen der Safety Assurance Cases zus\u00e4tzlich eine Strategie<\/strong> f\u00fcr die Beweisf\u00fchrung.<\/p>\n <\/td>

\n

Vollst\u00e4ndige Induktion<\/p>\n

Auffinden und Beherrschen von Gef\u00e4hrdungen<\/p>\n <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Die ISO 15026-2 kennt zudem noch eine weitere Begr\u00fcndung, die Justification<\/strong>. Diese begr\u00fcndet aber nicht, weshalb ein Claim zutreffend ist, sondern weshalb man einen bestimmten Claim gew\u00e4hlt hat.<\/p>\n\n\n\n

c) Definition #2<\/h3>\n\n\n\n

Entsprechend definiert die Norm Safety Assurance Cases wie folgt:<\/p>\n\n\n\n

\n
\n <\/i> Definition: Assurance Case<\/dfn>\n <\/div>\n
\u201eAn 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. \u201c<\/dd>\n
Quelle ISO 15026-1, Kapitel 6.2<\/div>\n<\/div>\n\n\n\n

Die Regularien, insbesondere die grundlegenden Sicherheits- und Leistungsanforderungen<\/a> geben viele Claims vor, die die Hersteller nachweisen m\u00fcssen.<\/p>\n\n\n\n

2. Struktur von Safety Assurance Cases<\/h2>\n\n\n\n

Ein Safety Assurance Case<\/strong> hat einen oder mehrere Top-Level-Claims<\/strong>, die das Ziel der Beweisf\u00fchrung sind. Deren Wahl ben\u00f6tigt eine \u201eJustification\u201c.<\/p>\n\n\n\n

Claims<\/strong> k\u00f6nnen durch \u201eLimitations\u201c eingeschr\u00e4nkt werden z.B. bez\u00fcglich der Dauer, der Sicherheit oder der Voraussetzungen.<\/p>\n\n\n\n

Um einen Claim nachzuweisen, ben\u00f6tigt man entweder genau ein Argument oder einen oder mehrere (Sub-)Claims, Evidenzen <\/strong>oder Annahmen<\/strong>.<\/p>\n\n\n\n

Argumente wiederum m\u00fcssen durch einen oder mehrere Claims, Evidenzen oder Annahmen gest\u00fctzt sein.<\/p>\n\n\n\n

\"Bild<\/a>
Abb. 1: Ein vereinfachtes Meta-Modell von Safety Assurance Cases, wie es sich aus der ISO 15026-2 ergibt. Die abstrakte Entit\u00e4t „Support“ kennt die Norm nicht.<\/figcaption><\/figure>\n\n\n\n

Die OMG<\/a> (Object Management Group) hat ein genaueres Metamodell in ihrem Dokument Structured Assurance Case Metamodel (SACM)<\/a> ver\u00f6ffentlicht, das allerdings nicht ganz deckungsgleich mit der ISO 15025-2 ist.<\/p>\n\n\n\n

3. Grafische Darstellung von Safety Assurance Cases<\/h2>\n\n\n\n

a) Goal Structuring Notation<\/h3>\n\n\n\n

Die Goal Structuring Notation (GSN)<\/a> hilft, die Safety Assurance Cases grafisch darzustellen. Das erleichtert den schnellen \u00dcberblick. <\/p>\n\n\n\n

\n
\n <\/i> Weiterf\u00fchrende Informationen\n <\/div>\n

Sie finden hier eine kurze Einf\u00fchrung in die GSN<\/a> und hier ein \u201eCheat-Sheet\u201c mit den Notationselementen<\/a>.<\/p>\n<\/div>\n\n\n\n

\"\u00dcbersicht<\/a>
Abb. 2: \u00dcbersicht \u00fcber die Notationselemente der Goal Structuring Notation (GSN)<\/figcaption><\/figure>\n\n\n\n

Auch der AAMI TIR 38 Medical device safety assurance case report guidance<\/a> nutzt diese Notation.<\/p>\n\n\n\n

Ein Ausschnitt eines Safety Assurance Cases, der mit der GSN modelliert wurde, kann dann wie in Abb. 3 dargestellt aussehen.<\/p>\n\n\n\n

\"Bild<\/a>
Abb. 3: Beispiel f\u00fcr einen Safety Assurance Case, der mit der Goal Structuring Notation (GSN) modelliert ist.<\/figcaption><\/figure>\n\n\n\n

b) Weitere grafische Modellierungssprachen<\/h3>\n\n\n\n

Eine etwas einfachere Notation nennt sich Claim Argument Evidence (CAE)<\/a>. Auch f\u00fcr diese Sprache gibt es Modellierungswerkzeuge<\/a>.<\/p>\n\n\n\n

Auch SysML wird als Vielzweck-Modellierungssprache f\u00fcr die Darstellung von Safety Assurance Cases genutzt.<\/p>\n\n\n\n

Mit allgemeinen Zeichenwerkzeugen wie draw.io lassen sich alle Notationen darstellen.<\/p>\n\n\n\n

4. Vorgehen beim Erstellen von Safety Assurance Cases<\/h2>\n\n\n\n

a) Zweckbestimmung erstellen<\/h3>\n\n\n\n

Eine wichtige Voraussetzung, um Safety Assurance Cases zu erstellen, ist eine vollst\u00e4ndige Zweckbestimmung einschlie\u00dflich der vorgesehenen Nutzer und der vorgesehenen Nutzungsumgebung. Denn davon h\u00e4ngen der Kontext und einige Annahmen ab.<\/p>\n\n\n\n

\n
\n <\/i> Weiterf\u00fchrende Informationen\n <\/div>\n

Der Artikel zum Erstellen von Zweckbestimmungen<\/a> nennt Ihnen die Aspekte, die dieses Dokument festlegen sollte, um die regulatorischen Anforderungen zu erf\u00fcllen.<\/p>\n<\/div>\n\n\n\n

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.<\/p>\n\n\n\n

b) Top-Level-Claims formulieren<\/h3>\n\n\n\n

Die Hersteller m\u00fcssen die Top-Level-Claims formulieren und daf\u00fcr eine Strategie festlegen. Manche starten mit einer oder mehreren allgemeinen Behauptungen wie \u201eDas Medizinprodukt ist sicher\u201c. Andere leiten die Top-Level-Claims aus den Top-Level-Gef\u00e4hrdungen ab.<\/p>\n\n\n\n

Beispiel Infusionspumpen<\/h4>\n\n\n\n

F\u00fcr Infusionspumpen hat die FDA im Guidance-Dokument \u201eInfusion Pumps Total Product Life Cycle\u201c<\/a> diese Top-Level-Claims indirekt festgelegt. Denn die Claims m\u00fcssen darin bestehen, dass die folgenden Probleme nicht auftreten:<\/p>\n\n\n\n