EU vs. FDA Unterschiede und Gemeinsamkeiten. Bernhard Fischer

Transkript

1 EU vs. FDA Unterschiede und Gemeinsamkeiten Bernhard Fischer

2 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 2

3 Regulatorische Anforderungen Die Systeme im Vergleich EU-Richtlinie 93/42/EEC Umsetzung in nationales Recht (Deurschland: MPG) Benannte Stellen CE-Kennzeichung in Eigenverantwortung des Herstellers oder unter Einbeziehung einer Benannten Stelle Marktüberwachung & Meldesystem nationale Behörde Staatliche Gesundheitsbehörde Food and Drug Administration FDA Verantwortlich für Zulassung für Medizinprodukte: Center for Devices and Radiological Health CDRH Gesetzliche Grundlage Food, Drug & Cosmetic Act Medizinprodukte: Kapitel 21CFR Marktüberwachung & Meldeystem FDA 3

4 Regulatorische Anforderungen Hardmonized Standards vs. Recognized Standards EN ISO EN IEC EN IEC EN ISO EN IEC rd Edition IEC IEC ISO IEC 60601: FDA erkennt die 2 nd und 3 rd Edition (seit März 2010) an, aber Nationale Abweichungen für USA Aber für NRTL wird derzeit noch die 2 nd Edition benötig 4

5 Regulatorische Anforderungen Risikomanagement EN ISO 14971:2012 ISO TR ISO 14971:2007 ISO TR AAMI TIR 64 5

6 Regulatorische Anforderungen Gebrauchstauglichkeit EN IEC (EN IEC ) IEC ersetzt ANSI AAMI HE74 ANSI AAMI HE75:2009 Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management Do It By Design: An Introduction to Human Factors in Medical Devices 6

7 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 7

8 Der SW-Entwicklungsprozess Qualitätsmanagementsystem SW-Wartungs-/ Änderungsprozess SW-Sicherheitsklassifizierung IEC SW-Entwicklungsprozess SW-Problemlösungs prozess SW-Konfigurationsmanagement SW-Risikomanagementprozess 8

9 Aktivitäten des SW-Entwicklungsprozess Anforderungs- 5.1 Planung analyse 5.2 Funktionale SW-System anforderungen Spezifikation 5.3 Software- Architektur 5.4 Software- Design 5.8 Akzeptanztest Freigabe 5.7 SW- Systemtest Systemtest 5.6 Integrations Integrationstest Test 5.5 Verifikation Modulttest SW-Einheit 5.5 Implementierung 9

10 Dokumentationsmodell nach IEC Anforderungs- 5.1 Planung analyse 5.2 Funktionale SW-System anforderungen Spezifikation 5.3 Software- Architektur 5.4 Software- Design 5.8 Akzeptanztest Freigabe 5.7 SW- Systemtest Systemtest 5.6 Integrations Integrationstest Test 5.5 Verifikation Modulttest SW-Einheit 5.5 Implementierung 10

11 FDA on Software The vast majority of software problems are traceable to errors made during the design and development process. Software is complex. Even short programs can be very complex and difficult to fully understand. Testing alone cannot fully verify that software is complete and correct. Unlike some hardware failures, software failures occur without advanced warning. Because software can be changed very easily, software and non-software professionals tend to believe that software problems can be corrected easily. Insignificant changes in software code can create unexpected and very significant problems elsewhere in the software program.

12 Entwicklungsprozess nach FDA 12

13 Guidance-Dokumente der FDA Design Control Guidance for Medical Device Manufacturers General Principles of Software Validation - Final Guidance for Industry and FDA Staff Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices Guidance for Off-the-Shelf Software Use in Medical Devices

14 Principles of Software Validation Work within the environment of an established software life cycle Focus on preventing the introduction of defects into the software (not removing them during tests) Use a risk based approach to identify the necessary V&V coverage Whenever software is changed, a validation analysis shall be conducted to determine the extent and impact of that change on the entire software system 14

15 Entwicklungsprozess im Vergleich (1) Regulatorische Anforderungen QM-System nach ISO Erfordert ein Risikomanagement nach ISO Erfordert ein Usability-Prozess nach IEC Erfordert einen Software-Lebenszyklus nach ISO Umfang der notwendigen Aktivtäten und Dokumentation nach der Sicherheitsklasse QM-System nach 21 CFR 820. ISO ist ein recognized standard Usability ist Guidance-Dokumenten beschrieben, IEC ist ein recognized standard Softwareentwicklung ist in General Principles of SW Validation beschrieben 15 Umfang der einzureichenden Dokumentation nach dem Level of Concern

16 Entwicklungsprozess im Vergleich (2) Notwendige Aktivitäten Planung der Entwicklungsaktivitäten Ermittlung und Dokumentation der SW-Anforderungen Festlegung einer Architektur und einer Design in Abhängigkeit vo Implementierung und Verifikation der SW-Einheiten Integration und Verifizierung der Integration Verifizierung des SW-Systems Planung der Entwicklungsaktivitäten Ermittlung und Dokumentation der SW-Anforderungen Festlegung einer Architektur und einer Design Implementierung und Verifikation der SW-Einheiten Integration und Verifizierung der Integration Verifizierung des SW-Systems 16

17 Entwicklungsprozess im Vergleich (3) Planung der Entwicklungsaktivitäten Erstellung eines Plans für Softwareentwicklung Der Plan enthält Referenzen auf die Systementwicklung Den anzuwenden Entwicklungsprozess mit Eingaben und Ausgaben Der Plan enthält Angaben zu eingesetzten Standards, Verfahren und Werkzeugen Der Plan enthält Angaben zur Integration, Verifikation, zum Konfigurations- und Risikomanagement Erstellung eines Plans für die Softwareentwicklung Festlegung wichtiger Qualitätseigenschaften Den anzuwenden Entwicklungsprozess mit Eingaben und Ausgaben Rollen und Verantwortlichkeiten für jede Aufgabe Risikomanagement und Gebrauchstauglichkeit 17

18 Entwicklungsprozess im Vergleich (4) Softwareanforderungen Erstellung und Dokumentation von SW-Anforderungen, die von Systemanforderungen abgeleitet sind Einbeziehen von Risikokontroll-Maßnahmen in die Software-Anforderungen Die SW-Anforderungen beinhalten insbesondere funktionale und nicht-funktionale Anforderungen, Eingaben und Ausgaben sowie Gebrauchstuaglichkeitsanforderungen. Dokumentation der Anforderungen an die Software, einschliesslich funktionaler-, Leistungs-, Schnittstellen-, Design- und anderer Anforderungen an die Software. Einbeziehen von Sicherheitsanforderungen, die aus der Risikoanalyse herrühren Ein Verfahren, wie mit unvollständigen, unklaren und widersprüchlichen Anforderungen umgegangen wird. 18

19 Entwicklungsprozess im Vergleich (5) Architektur und (Detailed) Design Entwicklung einer Architektur das für die Schnittstellen zwischen den Software-Komponenten Spezifikation der SOUP-Komponenten Weitere Unterteilung der Komponentne in SW- Einheiten und Beschreibung der SW-Einheiten und deren Schnittstellen Verifizierung von Architektur und Design SW-Architektur, als detaillierte Zerlegung in funktionale Einheiten und SW-Moduel, einschliesslich einer Architektur-Übersicht, die die Beziehungen zwischen den wichtigen funktionalen Einheiten erläutert, Eine Beschreibung wie die Anforderungen implementiert werden ( Design ), die es erlaubt festzustellen, ob die Anforderungen angemessen umgesetz wurden (in terms of intended use, functionality, safety, and effectiveness) 19

20 Entwicklungsprozess im Vergleich (6) Implementierung und Verifizierung von SW-Einheiten Implementierung jeder Software-Einheit Festlegung eines Verifizierungsprozesses für die Software-Einheiten Festlegung von Akzeptanzkriterien für die Software- Einheiten Verifizieren der Software-Einheiten Implementierung aller im Design identifizierten Elemente Beschreibung der notwendigen Verifizierungsaktivitäten Spezifikation der auf Unit -Ebene durchzuführenden Tests einschliesslich pass/fail-kriterien, sowie Dokumentation der Ergebnisse durch 20

21 Entwicklungsprozess im Vergleich (7) Integration und Verifizierung der Integration und des Systems Integration des Systems und Verifizierung der korrekten Integration des Systems sowie des integrierten Systems Festlegung von Prüfungen für Software-Anforderungen Verifizierung der Software-System Durchführung von Regressionstests, soweit erforderlich Integration der Software-Elemente zu einem SW-Systems Beschreibung der notwendigen Verifizierungsaktivitäten Spezifikation der auf der Integrations- und Systgemebene durchzuführenden Tests einschliesslich pass/fail-kriterien, sowie Dokumentation der Ergebnisse Durchführung von Regressionstests, soweit erforderlich 21

22 Vorläufiges Ergebnis Obwohl die Vorgaben für die Softwareentwicklung durch die EU und die FDA aus anderen Quellen stammen, unterscheiden sie sich nicht grundsätzlich. Die Vorgaben für die verschiedene Aktivitäten unterschieden sich zwar im Detail, es scheint aber grundsätzlich kein Hindernis für einen gemeinsamen Entwicklungsprozess vorzuliegen. 22

23 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 23

24 Der SW-Entwicklungsprozess Qualitätsmanagementsystem SW-Wartungs-/ Änderungsprozess SW-Sicherheitsklassifizierung IEC Entwicklungsprozess SW-Problemlösungs prozess SW-Konfigurationsmanagement SW-Risikomanagementprozess 24

25 Sicherheitsklassen nach IEC 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. 25

26 Level of Concern (1) Minor: If failures or latent design flaws are unlikely to cause any injury to the patient or operator. Moderate: If a failure or latent flaw could directly or indirectly result minor injury to the patient or operator Major: If a failure or latent flaw could directly or indirectly result in death or serious injury to the patient or operator. 26

27 Level of Concern (2) Der Level of Concern betrifft nur den Umfang der 510(k)-Submission nicht den für die Compliance notwendige Dokumentation! Der Level of Concern soll vor jeder risikominimierende Maßnahme festgelgt werden. Der Level of Concern gilt für daß gesamte SW-System. Ein unterschiedliche Kategorisierung von Komponenten ist nicht möglich! 27

28 FDA The level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the device. Konsequenz: Man muss und soll - nicht alle SW- Funktionen bzw. SW-Komponenten gleich behandeln!

29 Was wird für Klasse A verlangt? Kapitel 5.1: Planung der Software-Entwicklung Kapitel 5.2: Analyse der Software-Anforderungen Kapitel 5.5: Implementierung und Verifizierung der Software-Einheiten Kapitel 5.8: Software-Freigabe Erinnerung: Es ist keine Verletzung oder Schädigung der Gesundheit möglich 29

30 Ist die Sicherheitsklasse A sinnvoll? Anforderungen der FDA in «Guidance for the Content of Premarket Submissions» überwiegend ignoriert Anforderungen der FDA in «General Principles of Software Validation» überwiegend ignoriert Keine Anforderungen aus , Kapitel 14 Aus der Sicht des Software-Engineering: Unsinn! 30

31 Sicherheitsklassifizierung (1) Vergleich Sicherheitsklasse A und Minor Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Dokumentation Software-Anforderungen Implementierung der Software-Einheiten Traceability zwischen Systemanforderungen und SW- Anforderungen Planung der Software-Entwicklung Level of Concern statement Übersicht über die Software-Anforderungen (Verifizierung der Software-Systems) Traceability zwischen Anforderungen, Architektur/Design, identifizierte Gefährdungen, Risikontrollmaßnahmen und V&V Aktivitäten 31

32 Sicherheitsklassifizierung (2) Vergleich Sicherheitsklasse B und Moderate Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Analyse der Software-Anforderungen Architektur und Design des Software-Systems Implementierung und Verifizierung der Software-Einheiten Verifizierung der Software auf Integrations- und Systembene Traceability Planung der Software-Entwicklung Level of Concern statement Vollständige Software-Anforderungen Architektur und Design des SW-Systems (Verifizierung der Software auf Unit-, Integrations- und Systembene) 32 Traceability

33 Sicherheitsklassifizierung (3) Vergleich Sicherheitsklasse C und Major Level of Concern Planung der Software-Entwicklung Dokumentation der Sicherheitsklasse Analyse der Software-Anforderungen Architektur und Design des Software-Systems ++ Implementierung und Verifizierung der Software-Einheiten ++ Verifizierung der Software auf Integrations- und Systembene Traceability Planung der Software-Entwicklung Level of Concern statement Vollständige Software-Anforderungen Architektur und Design des SW-Systems Verifizierung der Software auf Unit-, Integrations- und Systemebene 33 Traceability

34 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 34

35 Traceability Anforderungen der FDA (1) The Traceability Analysis links together product requirements, design specifications and testing requirements. The Traceability Analysis also ties together identified hazards with the implementation and the testing of the mitigations. Nach: Content of Premarket Submission for SW 35

36 Traceability Anforderungen der FDA (2) SW requirement shall be traceable to system requirements SW requirement shall be traceable to system requirements and risk analysis results A traceability analysis shall verify, that the sw design implements all sw requirements A source code traceability analysis is important to verify, that all code is linked test specifications and test procedures A tracebility analysis should be used to ensure, that (test) coverage is achieved between Unit Tests to Detailed Design Integration Test to High Level Design System Tests to SW Requirements Nach: General Principles of SW Validation 36

37 Anforderungen an die Traceability (1) Traceability zwischen Anforderungen und Verifikationen Zwischen Systemanforderungen zu SW-Anforderungen Zwischen SW-Anforderungen zu SW-System-Tests Zwischen Systemanforderungen zu SW-Anforderungen Zwischen SW-Anforderungen zu SW-System-Tests (Zwischen SW-Anforderungen zu Architektur, Design und Code) (Zwischen Architektur und Integrationstest) (Zwischen Detailed Design, Code und Unit-Tests) 37

38 Anforderungen an die Traceability (2) Traceability zwischen Gefährdungen und Risikokontrollmaßnahmen Zwischen der Gefährdungssituation, der spezifischen Ursache und der zugehörigen Risikokontrollmaßnahme Zwischen der Risikokontrollmaßnahme und den zugehörigen SW-Anforderungen und der SW- Komponente, die die Maßnahme implementiert Zwischen der Risikokontrollmaßnahme und der zugehörigen Verifizierung Zwischen der Gefährdung zu der zugehörigen Risikokontrollmaßnahme Zwischen der Risikokontrollmaßnahme und der Implementierung der Risikokontrollmaßnahme Zwischen der Risikontrollmaßnahme und zugehörigen Verifizierung Inhaltlich identisch zu den Anforderungen der EU 38

39 Agenda 1 Grundsätzliche Unterschiede Vergleich der Anforderungen an die SW-Entwicklung Sicherheitsklassifikation Traceability SOUP und OTS 39

40 Definition von SOUP und OTS Die IEC definiert Software of unknown provenance (SOUP als): Software-Komponente, die bereits entwickelt wurde, und allgemein verfügbar ist, und die nicht entwickelt wurde, um in das Medizinprodukt integriert zu werden, oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungsprozess nicht verfügbar sind. Die FDA definiert Off-The-Shelf-Software (OTS- Software) als A generally available software component, used by a medical device manufacturer, for which the manufacturer cannot claim complete software life cycle control. 40

41 Ähnlichkeiten und Unterschiede (1) OTS ist nicht auf den Einsatz in Medizinprodukten beschränkt. Und wenn dieser Software benutzt wird, to design, build and test the software und von anderen Herstellern vertrieben wird, dann fällt sie unter den Begriff OTS- Software. (s. Kapitel 6 der General Principles on Software Validation Das ist dann aber keine SOUP mehr. Ein typisches Beispiel ist jegliche Prozess-Software von anderen Herstellern. 41

42 Ähnlichkeiten und Unterschiede (2) SOUP muss nicht notwendig von einem anderen Hersteller stammen. Alle Software-Komponenten, die nicht allgemein verfügbar sind, etwa diejenigen, die der Medizinproduktehersteller selbst aber für einen anderen Zweck entwickelt hat und diese jetzt in das Medizingerät integrieren möchte, sind SOUP. Eine solche Komponente ist aber kein OTS. 42

43 Ähnlichkeiten und Unterschiede (3) Es gibt SOUP, die auch OTS ist, genauer: Alle allgemein verfügbaren Komponenten, die nicht dafür entwickelt wurden Teil des zu entwickelnden Medizingerätes zu werden, und über dessen Entwicklungsprozess der Hersteller daher auch keine Kontrolle hat sind sowohl SOUP als auch OTS, wenn der Hersteller des Medizingerätes sie in das Gerät integriert. 43

44 Thank you! Fischer Consulting GmbH Bernhard Fischer Waldstr. 106 D Bochum 44