510(k) Software-Unit FDA Traceability Segregation Medizinische Software Software-Item SOUP Safety Classification Risikomanagement für So1ware: Die Kunst der Sicherheitsklassifizierung Bernhard Fischer
Agenda 1 2 3 Defini&on und Grundlagen Klassifika&on Segrega&on Slide 2
Entwicklung nach IEC 62304 Qualitätsmanagementsystem Wartungs- / Änderungsprozess Sicherheitsklassifizierung KonfiguraOons- management IEC 62304 Problemlösungs prozess Entwicklungsprozess Risikomanagementprozess Slide 3
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
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
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 62304 legt daher Aufgaben und AkOvitäten fest, basierend auf den Gefährdungen zu dem die betreffende So1warekomponenten möglicherweise beitragen kann. Slide 6
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 62304 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 14971 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
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
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
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
Agenda 1 2 3 Defini&on und Grundlagen Klassifika&on Segrega&on Slide 11
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 62304 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Die ursprüngliche Architektur System Output UI UI Control Motor Control Input Class A Class B Class C
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
Darf die HW- Maßnahme auch SW enthalten? Die IEC 62304 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
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
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
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
Agenda 1 2 3 Defini&on und Grundlagen Klassifika&on Segrega&on
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
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
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
Gibt es Beispiele? Die IEC 62304 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
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
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
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
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
Ergebnis Falls die SegregaOon zwischen den beiden unter- schiedlichen klassifizierten Komponenten nicht nachwiesen werden kann, muss beiden die höhere Sicherheitsklasse zugewiesen! Andernsfalls können sie unterschiedlich klassifiziert werden. Slide 44
Thank you! Fischer Consul&ng GmbH Bernhard Fischer Waldstr. 106 D- 44869 Bochum www.bfischer- consul&ng.de info@bfischer- consul&ng.de