Und jährlich grüßt das Audit. Erfahrungen einer benannten Stelle (des neuen Feinbildes)

Transkript

1 Und jährlich grüßt das Audit Erfahrungen einer benannten Stelle (des neuen Feinbildes) Folie 1

2 Rahmenbedingungen Innerhalb von 30 Minuten kann ich leider nicht alles erzählen. Sie bekommen einen bunten Strauß an häufigen Fehlern! Nehmen Sie 1-2 Fehler mit und vermeiden Sie sie! Folie 2

3 Inhalt Die Sache mit dem Risikomanagement In der Kürze liegt die Würze? Das FAQ-Papier eine bessere Welt? Vom Ändern und Testen Die Mission Folie 3

4 Sicherheitsklassifizierung Risikoanalyse des Herstellers: Schaden Ursache Gefährdung Schweregrad Kammerflimmern Falsche Dosierung Medikament Ungenügende Isolation Fehler in Berechnungsroutine XYZ Elektrischer Schlag Fehlerhaftes Ergebnis wird angezeigt Software-Sicherheitsklassifizierung des Systems: B Tod Schwere Verletzung Was wäre die richtige Klassifizierung? Risikoanalyse und Sicherheitsklassifizierung passen häufig nicht zusammen! TÜV SÜD Product Service GmbH Slide 4

5 Sicherheitsgerichtete Software Software implementiert risikomindernde Maßnahme gegen Software-Teil essential performance andere Funktionalitäten HW-Fehler SW-Fehler Software mit potentiellen Nebeneffekten Software ohne potentielle Nebeneffekte Anwendungsfehler sicherheitsgerichtete Software nicht sicherheitsgerichtete Software Folie 5 Quelle: AAMI TIR32

6 Wie direkt ist indirekt? IEC 62304: Schwere Verletzung: Verletzung oder Krankheit, die direkt oder indirekt Maß für Direktheit? z.b. Ergebnis eines Algorithmus kann nicht verifiziert werden, oder wird in der Praxis nicht verifiziert => Gefährdung sehr naheliegend (in der Praxis: höhere Sicherheitsklasse) z.b. Ergebnis eines Algorithmus kann gut verifiziert werden + in der klinischen Praxis geschieht dies auch stets => Gefährdung nicht naheliegend (in der Praxis: niedrigere Sicherheitsklasse) Eine sehr indirekte Gefährdung führt in der Praxis häufig zu einer niedrigeren Klasse! Folie 6

7 Der Aufreger des letzten Jahres: EN 14971:2012 haben wir noch nicht angeschaut! wir haben das ganze Risikomanagement umgestellt; alle Warnhinweise sind jetzt raus; das Produkt hat jetzt aber 50 unakzeptable Risiken nach Maßnahmen da machen wir nix, sind ja nur Änderungen am informativen Anhang wir haben es mit Verstand bewertet; unser Prozess passt weiter Die content deviations müssen von Ihnen inhaltlich bewertet werden! Folie 7

8 Das aufregendste Beispiel Content deviation: Accordingly, manufacturers shall not attribute any additional risk reduction to the information given to the users. Wirksamkeit Dieser Defi verursacht beim Einsatz ggf. Verbrennungen auf der Haut Publication of Residual risk Warnhinweis in der Software: Eine Dosis von x liegt über dem empfohlenen Wert für den Patienten. Sind Sie sicher? Hinweise wirken unterschiedlich effektiv (Prozess?) / Validierung fehlt oft! Folie 8

9 Kommerzielle Software (SOUP, COTS) IEC Kapitel IEC Kapitel In der Risikoanalyse müssen die risiken von kommerzieller Software berücksichtigt werden: Das könnte sein: Betriebssysteme (z.b.windows, VxWorks, Android) Bibliotheken (e.g. OpenGL, JPEG) Frameworks und virtuelle Maschinen (z.b..net, Java) In der Risikonalyse sind die Risiken oft nicht berücksichtigt! TÜV SÜD Product Service GmbH Slide 9

10 Ad-hoc-Einschub: Wege aus dem SOUP Problem Risikoanalyse über SOUP ergibt B/C Nachweis, dass SOUP die Anforderungen an B oder C erfüllt Mit risikomindernden Maßnahmen (funktionale Sicherheit) das Risiko beherrschen Folie 10

11 Ah-hoc-Einschub: Weg 1: Nachweis Auswahl an Möglichkeiten: Nachweis, dass SOUP die Anforderungen an B oder C erfüllt B : Tests für SOUP definieren und durchführen C Nachweis unter eigener Regie (z.b. bei open Source) Verifikation der kritischen SOUP-Teile Verifikation der Abgrenzungsmaßnahmen etc. Verwendung einer zertifizierten SOUP nach nach IEC SIL 2 oder besser OTS Special Documentation (FDA OTS Guide) Eignung Entwicklungsprozess V&V Ergebnisse Wartung Folie 11

12 Ad-hoc Einschub: Weg 2: Außen herum Mit risikomindernden Maßnahmen (funktionale Sicherheit) das Risiko beherrschen Risikomindernde Maßnahme für die Funktion = funktionale Sicherheit ISO : Die Umsetzung jeder Maßnahme zur Risikobeherrschung muss verifiziert werden Die Wirksamkeit der Maßnahme(n) zur Risikobeherrschung muss verifiziert werden Risikomindernde Maßnahmen müssen der eigenen Kontrolle unterliegen! Folie 12

13 Inhalt Die Sache mit dem Risikomanagement In der Kürze liegt die Würze? Das FAQ-Papier eine bessere Welt? Vom Ändern und Testen Die Mission Folie 13

14 Risikomanagement: spezifische Software-Ursache In dieser Kiste Äpfel könnte ein Wurm sein! In der Software könnte ein Fehler sein, der zu einer Verwechslung von Patienten führt! Für einen konformen Prozess: Komponente/Einheit identifizieren genaue Stelle identifizieren, die kritisch sein kann SW-Risikomanagement auch an kritischen Stellen oft zu oberflächlich! Folie 14

15 Bewertung von Vorkommnissen ein Beispiel Bekanntes Vorkommnis bei Firma x: Patientendaten vertauscht beim Anbinden eines zweiten Krankenhauses. Ursache: Fehler in Importfunktion an Stelle xyz. Frage des Auditors im Audit von Firma y: Haben sie dieses Vorkommnis im Rahmen der Marktbeobachtung für ihr Produkt bewertet? Antwort: Ja, aber das kann bei uns ja nicht vorkommen, wir haben ja eine unique patient ID! Frage des Auditors: Glauben sie, die Firma x hat keine unique patient ID? auch beim Bewerten von Vorkommnissen: Ursache beachten! Folie 15

16 Die Sache von den alten Hüten Unterschied zwischen einer normalen Anforderung und einer aus risikomindernder Maßnahme? Normal: Ankommende Daten werden mit einer CRC16 auf Konsistenz geprüft. Risiko: Daten werden mit CRC16 geprüft; fehlerhafte Daten werden zurückgewiesen. Nachweis: Code-Review ausreichend? Risikomanagement: Nachweis Wirksamkeit! ein Auswandern von Maßnahmen aus der Risikoanalyse ist zu vermeiden! Folie 16

17 Inhalt Die Sache mit dem Risikomanagement In der Kürze liegt die Würze? Das FAQ-Papier eine bessere Welt? Vom Ändern und Testen Die Mission Folie 17

18 Team-NB zum Thema IEC FAQ Folie 18

19 Ein Problem des Papiers Wie wir es bisher sahen: Inkubator Steuer System (C) Inkubator Steuer System (B) Das Papier schreibt: Reduktion T > 41 C HW + SW (C) basierend auf kontr. Risiko 2.5.6: Downgrading safety class is only allowed with subsequent and pure HW protection, so indeed the classification of the Control system remains class C Folie 19

20 Ein möglicher Ausweg Der unschöne Weg: Das ist nicht die Idee der Ich mache es wie vorher. Der bessere Weg: Zuerst war das System Die funktionale Sicherheit fordert ein zweikanaliges System Das Schutzsystem realisieren wir zufällig in HW+SW; Schutz ist kritisch => C Das Steuersystem realisieren wir zufällig in HW+SW; wir haben aber ein Schutzsystem => weniger kritisch, also B Kein Problem mit SOUP im Steuersystem das Team-NB FAQ Papier zur steht im Widerspruch zu vielen aktuellen Sicherheitsarchitekturen; es gibt aber Auswege Folie 20

21 Inhalt Die Sache mit dem Risikomanagement In der Kürze liegt die Würze? Das FAQ-Papier eine bessere Welt? Vom Ändern und Testen Die Mission Folie 21

22 Softwareänderungen Bug-release bug release 1.01 bug #1 bug #2 bug #n formal release Freigabe + Bewertung restlicher Anomalien Welche Bugfixes sind Teil von 1.01? Für alle Bugs: Beschreibung Risikobewertung Verifikation Impact Analyse so notwendig: Regressionstests Verifikation, Auswirkung und Regression egtl. einfach es fehlt aber oft ein Teil Folie 22

23 Software-Änderungen Feature-Release feature release 1.1 bug #1 feature #1 Verifikation / Validierung Freigabe feature #n Ein Feature-Release verlangt ggf.: Validierung, neue Gebrauchsanweisung, Update technische Akte etc. TÜV SÜD Product Service GmbH 11-Nov-13 Slide 23

24 Lost in validation Teil I Frage des Auditors: Was sind denn so die neuen Features in Release 1.1? Darf ich bitte die Usability- Validierung sehen! Wir haben eine Reihe von tollen neuen Messfunktionen eingebaut, die Kunden wollten das so Wir haben eine Funktion geändert, weil sich ein Kunde beschwert hat, dass er sie falsch angewandt hat Haben wir nicht gemacht, waren ja nur kleine Änderungen! Trotz offensichtlich Usability-relevanter Änderungen fehlt oft eine Validierung! Folie 24

25 Lost in validation Teil II Bewerten Sie die neue Messfunktion krummes Lineal Aus Sicht des Auditors: Thema verfehlt; setzen, 6! Aus regulatorischer Sicht muss bewertet werden: ist die neue Funktion ausreichend sicher? ; dies fehlt oft! Folie 25

26 Änderungsanträge Änderungsantrag SW Version 1 SW Version 2 alle Änderungen testen + ggf. Regression Woraus ergibt sich der Unterschied auf Source-Code- Ebene? Oft finden sich Änderungen in der SW die nicht durch den Antrag abgedeckt sind! Folie 26

27 Tests auf Einheiten-Ebene IEC Kapitel 5.5.2, 5.6.5, IEC Kapitel Verifikation muss geplant werden Verifikationsmethoden müssen auf Korrektheit und Angemessenheit hin überprüft werden (Stand der Technik) : Abdeckung muss definiert werden Was ist die Strategie? Auf Einheiten-Ebene kann erwartet werden: Codereview: kompletter Code, kritische Teile? Tests: mit welcher Abdeckung (Pfade, kritische Pfade etc.) Die Teststrategie ist oft unzureichend definiert oder entspricht nicht dem Stand der Technik! TÜV SÜD Product Service GmbH Slide 27

28 Nochmal Validierung diesmal Tool-Validation muss ich ein R&D-Tool nach der ISO formal validieren (IQ, OQ, PQ)? Eignung feststellen: ja FDA: volles Programm ISO 13485: 7.3/7.5 Problem (Validierung steht in 7.5 gilt sie dann auch für 7.3?) Im Rahmen ISO 13485/MDD ist nicht ganz klar, ob R&D-Tools vollumfänglich validiert werden müssen. Folie 28

29 Tool-Validierung Aber folgende Auditsituation: Software-Freigabe positiv, weil alle Tests Pass Beim weiteren Stöbern in Mantis viele Tests aber Fail Was war passiert? Gesamtschau die zur Freigabe verwendet wurde, enthielt nicht alle Tests! Tool-Validierung auch bei R&D Tools aber: Augenmaß, risikoorientierter Ansatz Folie 29

30 Inhalt Die Sache mit dem Risikomanagement In der Kürze liegt die Würze? Das FAQ-Papier eine bessere Welt? Vom Ändern und Testen Die schwierigen Findings Folie 30

31 Reviews warum denn eigentlich? Soll allgemein: bekommen wir das, was wir wollen? z.b. Wartbarkeit z.b. Eignung der Architektur z.b. Inhalt der bisherigen Dokumentation Ist die Existenz von Dokumenten wir machen ein Review damit wir eines gemacht haben! Folie 31

32 Dokumentation und ihre Ziele Was dokumentiert werden sollte: Leistungsrelevant Risikobezogen Komplexe Details Kern-Wissen des Unternehmes Was dokumentiert wird: Dinge, die leicht zu dokumentieren sind Das Ziel der Dokumentation scheint oft unklar zu sein! TÜV SÜD Product Service GmbH Slide 32

33 Nimm zwei (oder mehr) Vielen Dank für die Aufmerksamkeit! Behalten Sie mindestens zwei Fehler und vermeiden Sie sie. Folie 33