Medizinische Software

Transkript

1 510(k) Software-Unit FDA Traceability Segregation Medizinische Software Software-Item SOUP Safety Classification Risikomanagement für So1ware: Die Kunst der Sicherheitsklassifizierung Bernhard Fischer

2 Agenda Defini&on und Grundlagen Klassifika&on Segrega&on Slide 2

3 Entwicklung nach IEC Qualitätsmanagementsystem Wartungs- / Änderungsprozess Sicherheitsklassifizierung KonfiguraOons- management IEC Problemlösungs prozess Entwicklungsprozess Risikomanagementprozess Slide 3

4 Was ist Sicherheitsklassifizierung? Die Sicherheitsklassifizierung beginnt mit der Zuordnung einer Sicherheitsklasse an das Software- System, basierend auf dem Beitrag, den das SW-System zu einer potentielne Gefährdung für Anwender, Patienten oder Dritte leistet. 3 Sicherheitsklassen: Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich. Klasse B: Keine schwere Verletzung ist möglich. Klasse C: Tod oder schwere Verletzung ist möglich. Slide 4

5 Was ist mit der Au1retenswahrscheinlichkeit? IEC 62304, Kapitel 4.3 Wenn die Gefährdung davon herrühren könnte, das das System sich nicht spezifikaoons- gemäß verhält, muss die Wahrscheinlichkeit einer solchen FehlfunkOon zu 100% angenommen werden. Slide 5

6 Warum ist die Au1retens- wahrscheinlichkeit irrelevant? Für So1ware ist es im Gegensatz zu Hardware - grundsätzlich schwierig Au1retenswahrscheinlichkeiten zu besommen. Fehler sind immer systemaosch unter den exakt gleichen Bedingungen wird der Fehler IMMER au1reten. Und die Wahscheinlichkeiten für solche Bedingungen zu besommen ist schwierig... Die IEC legt daher Aufgaben und AkOvitäten fest, basierend auf den Gefährdungen zu dem die betreffende So1warekomponenten möglicherweise beitragen kann. Slide 6

7 Muss ich dann in der RA für solchen Risiken auch immer 100% Au1retenswahrscheinlichkeit annehmen? Nein. Es handelt es sich um 2 unterschiedliche Normen. Die IEC stellt Anforderungen an den Lebenszyklus insbesondere die Entwicklung - von Medizinprodukte- So1ware mit dem Ziel sichere So1ware zu erstellen. Dazu werden überwiegend Prozessvorgaben gemacht, die bei der Entwicklung einzuhalten sind. Die ISO stellt legt einen Prozess fest zur IdenOfizierung der mit dem Medizinprodukt verbundenen Gefährdungen. Er dient zur Einschätzung und Bewertung der zugehörigen Risiken, zur Beherrschung dieser Risiken und zur Überwachung der Wirksamkeit von Maßnehmen zur Risikominimierung. Slide 7

8 FDA: Level of Concern Minor: If failures or latent design flaws are unlikely to cause any injury to the paoent or operator. Moderate: If a failure or latent flaw could directly or indirectly result minor injury to the paoent or operator Major: If a failure or latent flaw could directly or indirectly result in death or serious injury to the paoent or operator. Slide 8

9 Sicherheitsklassifizierung vs. Level Of Concern Der Level of Concern betrio nur den Umfang der 510(k)- Submission einzureichenden DokumentaOon nicht den für die Compliance notwendigen Umfang der DokumentaOon! Der Level of Concern wird vor jeder risiko- minimierenden Maßnahme festgelegt. Der Level of Concern gilt für das gesamte System. Ein unterschiedliche Kategorisierung von Komponenten ist nicht vorgesehen. Slide 9

10 Die Sicht der FDA The level of confidence, and therefore the level of so1ware validaoon, verificaoon, and tesong effort needed, will vary depending upon the safety risk (hazard) posed by the automated funcoons of the device. Konsequenz: Man muss und soll - nicht alle FunkOonen bzw. Komponenten gleich behandeln! Slide 10

11 Agenda Defini&on und Grundlagen Klassifika&on Segrega&on Slide 11

12 Sicherheitsklassifizierung (1) Zu Beginn wird dem gesamten System eine Sicherheitsklasse basierend auf dem GefährdungspotenOal des gesamten Systems zugewiesen. Die Architektur teilt das So1waresystem hierarchisch in kleinere Einheiten, die in der IEC Komponenten genannt werden Zu Beginn erbt jede Komponente die KlassifikaOon der Komponente, der sie zugehörig sind. Nicht vergessen: Die SicherheitsklassifikaOon wird in der Risikomanagementakte dokumenoert! Slide 12

13 Sicherheitsklassifizierung (2) System: Integrierte Sammlung von Komponenten, die einen spezifische FunkOon oder einen Satz von FunkOon ausführen. Komponente: Jeder idenofizierbare Teil eines Systems. Einheit: Komponente, die nicht weiter zerlegt wird. Der Hersteller definiert die Unterteilung des Systems in So1ware- Komponenten und So1ware- Einheiten! Slide 13

14 Zerlegung des Systems System Input Item A1 Item AB Item A3 Item B2 Output UI Item C1 Item C2 Class A Class B Class C Slide 14

15 Klassifikation der SW-Komponenten Für jede Gefährdung die in der Risikoanalyse idenofiziert wurde: Finde heraus, ob und gegebenenfalls wie eine spezifische Komponenten zu dieser Gefährdung beitragen kann. 2 Vorgehensweisen: Top- Down und Bouon- Up Slide 15

16 Top- Down Wir betrachten zunächst in der Risikoanalyse, inweit FunkOonen zu Gefährdungen beitragen, wenn sie nicht spezifikaoonsgemäs funkoonieren. Dann betrachten die Zerlegung des System in Komponenten in rein funkoonaler Sicht, d.h wir welche Komponenten bei der Ausführung einer besommten FunkOon benöogt werden, und elgen danach die Sicherheitsklasse der jeweiligen Komponenten fest. Slide 16

17 Schriu 1: Auflistung der grobgranularen Requirements / Features / Use Cases... Func&onal Safety SW Items Requirements Faeture 1 Faeture 2 Faeture 3 Faeture 4 Faeture 5 Faeture 6 Faeture 7 Faeture 8 Faeture 9 Faeture 10 Overall safety class of sw item Slide 17

18 Schriu 2: Zuweisung einer Sicherheitsklasse basierend auf den Ergebnissen der RA Func&onal Safety A B B C A B B B C C SW Items Requirements Faeture 1 Faeture 2 Faeture 3 Faeture 4 Faeture 5 Faeture 6 Faeture 7 Faeture 8 Faeture 9 Faeture 10 Overall safety class of sw item Slide 18

19 Schriu 3: Zuordnung der Komponenten zu den Anforderungen, in den sie implemenoert werden Func&onal Safety A B B C A B B B C C Architecture Requirements Faeture 1 Faeture 2 Faeture 3 SW Item 1 A C SW Item 2 B B B SW Item 3 B C SW Item 4 C B B C SW Item 5 A B SW Item 6 SW Item 7 SW Item 8 SW Item 9 Faeture 4 Faeture 5 SW Item 10 A B B B B SW Item 11 A C C C SW Item 12 C Faeture 6 Faeture 7 Faeture 8 Faeture 9 C Faeture 10 Overall safety class of sw item Slide 19

20 Schriu 4: Ermiulung der erforderlichen Sicherheitsklasse der Komponente Func&onal Safety A B B C A B B B C C Architecture Requirements Faeture 1 Faeture 2 Faeture 3 SW Item 1 A C c SW Item 2 B B B B SW Item 3 B C C SW Item 4 C B B C C SW Item 5 A B B SW Item 6 B B SW Item 7 C C SW Item 8 B B SW Item 9 A A SW Item 10 A B B B SW Item 11 A C C C C SW Item 12 C C Faeture 4 Faeture 5 Faeture 6 Faeture 7 Faeture 8 Faeture 9 Faeture 10 Overall safety class of sw item Slide 20

21 Zerlegung des Systems: Istzustand Item ABC Input Item A1 Item AB Item A3 Item B2 Output UI Item C1 Item C2 Class A Class B Class C Slide 21

22 Was kann ich tun, wen ich die Sicherheits- klasse einer Komponente ändern will? Allgemeine Regel: Die Architektur geeignet anpassen! Wie? Geschickte Zerlegung der Komponenten Hinzufügen einer Hardware- Maßnahme Slide 22

23 Zerlegung des Systems: Neues Design Item ABC Item A1 Item A2 Item A3 Input Item B1 Item B2 Output UI Item C1 Item C2 Class A Class B Class C Slide 23

24 Zerlegung des Systems: Ergebnis Item ABC Item A1 Item A2 Item A3 Input Item B1 Item B2 Output UI Item C1 Item C2 Class A Class B Class C Slide 24

25 Regeln für die KlassifikaOon von Komponenten - Bouom Up Was passiert, wenn die Daten in der Komponente beschädigt werden? die empfangenen oder versendeten Daten beschädigt sind? die Daten zu früh zu zu spät versendet oder empfangen werden? die Daten nicht empfangen, verarbeitet oder versendet werden? Slide 25

26 Zusätzliche Regeln für Komponenten mit UI Was passiert, wenn der Benutzer... nicht auf eine Änderung in UI reagiert? in einer falschen Art und Weise auf die Änderung der UI reagiert? die dargestellten InformaOonen falsch interpreoert? Slide 26

27 Reduzierte Sicherheitsklasse einer Nicht vergessen: Komponente Wenn die Sicherheitsklasse einer Komponente von der Sicherheitsklasse abweicht, aus der sie durch Zerlegung entstanden ist, so muss eine Begründung für die abweichenden Sicherheitsklasse Bestandteil der Risikomanagementakte sein! Diese Begründung muss auch erläutern, wie die Komponente so abgegrenzt ist, das sie getrennt klassifiziert werden kann. (s. Teil 3: SegregaOon) Slide 27

28 Risikominimierende Maßnahme durch Hardware Wenn das Risiko, das von einer Komponente herrührt, auf eine HW- Risikomaßnahme auf ein vertretbares Maß reduziert wird... so kann die die Sicherheitsklasse von C auf B bzw. von B auf A herabgesetzt werden. Slide 28

29 Die ursprüngliche Architektur System Output UI UI Control Motor Control Input Class A Class B Class C

30 Mit geänderter Architektur durch HW- Massnahme System Output UI UI Control Motor Control HW- Maßnahme zur Risikoreduzierung Input Class A Class B Class C

31 Darf die HW- Maßnahme auch SW enthalten? Die IEC sagt nichts zu diesem Thema. Das FAQ der benannten Stellen sagt: Nein. Aber: ist das wirklich ein Thema, wenn die Sicherheitsklasse der Komponente nach dem Beitrag festgelegt wird, den diese zu einer Gefährdung leistet? Slide 31

32 Mit geänderter Architektur + HW- Maßnahme Input System Output UI UI Control Motor Control Safety System mit separater HW + SW In der vorhandenen Architektur kann ein Fehler in der Komponente MotorControl nicht zu einer Gefährdung führen à Daher Klasse A Class A Class B Class C

33 Was ist mit Risikokontrollmaßnahmen in SW? Komponenten, die eine Risikokontroll- maßnahme implemenoeren wird eine Sicherheitsklasse zugewiesen, die nach der Gefährdung bemessen wird, die durch diese Maßnahme kontrolliert wird. Solche Komponenten haben daher die Sicherheitsklasse B oder C Slide 33

34 Müssen alle Risikokontrollmaßnahmen in HW sein? Nein. Es ist eine beliebige Anzahl von risikomindernden Maßnahmen in SW möglich und diese Maßnahmen reduzieren das Schadensausmaß oder die Au1retenswahrscheinlichkeit einer Gefährdung in der Risikoanalyse Aber diese mindern nicht Sicherheitsklasse der der Komponenten von der das ursprüngliche Risiko ausgeht Slide 34

35 Agenda Defini&on und Grundlagen Klassifika&on Segrega&on

36 Was ist SegregaOon? Durch die SegregaOon wird sichergestellt dass sich Komponenten mit unterschiedlicher Sicherheitsklassifizierung nicht in unbeabsichogter Weise beeinflussen können, etwa durch Kontrollfluss Datenfluss und gemeinsam benutzte Ressourcen Slide 36

37 DecomposiOon of a SW item: Example Item ABC Item A1 Item A2 Item A3 Input Item B1 Item B2 Output Item C1 Item C2 Class A Class B Class C

38 DecomposiOon of a SW item: Example Item ABC Item A1 Item A2 Item A3 Input Item B1 Item B2 Output Item C1 Item C2 Class A Class B Class C Slide 38

39 Gibt es Beispiele? Die IEC gibt nur ein Beispiel: Die unterschiedlich klassifizierten Komponenten werden auf unterschiedlichen Prozessoren mit unterschiedlicher Speichern ausgeführt. Daher gibt es gar keine gemeinsam benutzten Ressourcen. Slide 39

40 Muss ich nachweisen, das es keinen unbeabsichogten Einfluss gibt? Falls das möglich, gut. Falls nicht, so reicht es aus, wenn nachgewiesen werden kann, das es keinen unbeabsichogten Einfluss zwischen Komponenten mit unterschiedlicher Sicherheitsklassifizierung gibt, die zu einer Gefährdung führt. Slide 40

41 Wie weise ich die SegregaOon nach? (1) Spezifizieren Sie die erforderliche SegregaOon basierend auf risikobeha1eten FunkOonalität der höherklassifizierten Komponente. Spezifizieren Sie die SegregaOon so, das sie tatsächliche verifizierbar ist. Verifizieren Sie die SegregaOon dann auch tatsächlich und stellen Sie Nachweise bereit! Slide 41

42 Wie weise ich die SegregaOon nach? (2) Spezifizieren Sie, wie Datenfluss, Kontrollfluss oder gemeinsame Ressourcen (Laufzeitumgebung) Einfluss auf die SegregaOon nehmen können - aber nur wenn das relevant ist d.h. wenn eine Verletzung der SegregaOon tatsächlich zu einer Gefährdung führen kann. Slide 42

43 Beispiel: Eine Komponente führt eine komplexe Berechnung durch (etwa eine Therapieplanung). Daher wird diese Komponente die Sicherheitsklasse C. Andere Komponenten, die mit diese Komponenten nicht direkt interagieren, sind funkoonal als A klassifiziert haben aber keine Schniustellen mit dieser Komponente. Sind gemeinsame Ressourcen relevant? Slide 43

44 Ergebnis Falls die SegregaOon zwischen den beiden unterschiedlichen klassifizierten Komponenten nicht nachwiesen werden kann, muss beiden die höhere Sicherheitsklasse zugewiesen! Andernsfalls können sie unterschiedlich klassifiziert werden. Slide 44

45 Thank you! Fischer Consul&ng GmbH Bernhard Fischer Waldstr. 106 D Bochum consul&ng.de consul&ng.de