IEC Was bringt das Amendment 1. Matthias Hölzer-Klüpfel

Transkript

1 IEC Was bringt das Amendment 1 Matthias Hölzer-Klüpfel

2 Regulatorische Grundlagen Wann ist Software ein Medizinprodukt? für die Entwicklung medizinischer Software

3 Medizinprodukt, MDD Novelle 2007 Alle einzeln oder miteinander verbunden verwendeten Instrumente, Apparate, Vorrichtungen, Software, Stoffe oder anderen Gegenstände, einschließlich der vom Hersteller speziell zur Anwendung für diagnostische oder therapeutische Zwecke bestimmten und für ein einwandfreies Funktionieren des Medizinproduktes eingesetzten Software, die vom Hersteller zur Anwendung für Menschen bestimmt sind: Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen Untersuchung, Ersatz oder Veränderung des anatomischen Aufbaus oder eines physiologischen Vorgangs Empfängnisregelung und deren bestimmungsgemäße Hauptfunktion im oder am menschlichen Körper weder durch pharmakologische oder immunologische Mittel noch metabolisch erreicht wird, deren Wirkungsweise aber durch solche Mittel unterstützt werden kann.

4 Anwendbare Standards ISO ISO IEC IEC IEC Risikomanagement Qualitätsmanagement Software Lebenszyklus Programmierbare Medizinelektronik Gebrauchstauglichkeit

5 Prozesse der IEC Software-Entwicklung Software-Wartung Software-Risikomanagement Software-Problemlösung Software-Konfigurationsmanagement

6 IEC Kundenbedürfnisse Aktivitäten außerhalb des Geltungsbereichs dieser Norm Erfüllte Kundenbedürfnisse System-Entwicklungs-Aktivitäten (einschließlich Risikomanagement) Software-Risikomanagement-Prozess Planung der Software- Enwicklung Analyse der Software- Anforderung Design der Software- Architektur Software Entwicklung Detailliertes Software- Design Implement./ Verifizierung Software Integration u. -prüfung Prüfung des Software- Systems Software Freigabe Software-Konfigurationsmanagement-Prozess Problemlösungs-Prozess für Software

7 Problemfelder bei Wann ist Software ein Medizinprodukt? der Anwendung der IEC 62304

8 Problemfelder Standalone Software Software-Sicherheitsklassifizierung Umgang mit SOUP Software-Risikomanagement Legacy-Software Interpretationsspielräume

9 Problemfeld Standalone Software

10 PACS

11 Telemedizin

12 iphone applications

13 Was sagt die IEC 62304? MEDIZINPRODUKTE-SOFTWARE ein SOFTWARE-SYSTEM, das entwickelt wurde, um in das in der Entwicklung befindliche MEDIZINPRODUKT integriert zu werden, oder das für die Benutzung als selbständiges MEDIZINPRODUKT vorgesehen ist

14 IEC Kundenbedürfnisse Aktivitäten außerhalb des Geltungsbereichs dieser Norm Erfüllte Kundenbedürfnisse System-Entwicklungs-Aktivitäten (einschließlich Risikomanagement) Software-Risikomanagement-Prozess Planung der Software- Enwicklung Analyse der Software- Anforderung Design der Software- Architektur Software Entwicklung Detailliertes Software- Design Implement./ Verifizierung Software Integration u. -prüfung Prüfung des Software- Systems Software Freigabe Software-Konfigurationsmanagement-Prozess Problemlösungs-Prozess für Software

15 MEDDEV 2.1/6 Richtlinien zur Qualifikation und Klassifizierung von eigenständiger Software im Gesundheitswesen innerhalb der rechtlichen Rahmenbedingungen von Medizinprodukten

16 Problemfeld Sicherheitsklassifizierung Risiko Kombination der Wahrscheinlichkeit des Auftretens eines SCHADENS und des SCHWEREGRADES dieses SCHADENS

17 Auftretenswahrscheinlichkeit Wie bestimmen Sie die Wahrscheinlichkeit, dass ein bestimmter Software-Fehler auftritt? Annahme: Auftretenswahrscheinlichkeit = 100% Sicherheitsklasse in der IEC definiert sich anhand des potenziellen Schadens

18 Software-Sicherheitsklassen A keine Verletzung oder Schädigung der Gesundheit möglich B keine schweren Verletzungen möglich C Tod oder schwere Verletzungen möglich

19 Eine kleine Übung? Welche Sicherheitsklasse hat die Software in einem digitalen Fieberthermometer?

20 Sicherheitsklasse C SW-Anforderungen SW-System-Prüfung SW-Architektur SW-Integration / Integrationsprüfung Detailliertes Design Verifikation der Impl. Implementierung

21 Sicherheitsklasse B SW-Anforderungen SW-System-Prüfung SW-Architektur SW-Integration / Integrationsprüfung Implementierung

22 Sicherheitsklasse A SW-Anforderungen SW-System-Prüfung Implementierung

23 Modularisierung Softwaresystemkomponente Klasse C Softwarekomponente X Klasse A Softwarekomponente Y Klasse C Softwarekomponente V Klasse B Softwarekomponente Z Klasse C

24 Segregierung Aufteilung der Software-Komponenten auf verschiedene Rechner verschiedene Prozessoren (verschiedene Prozesse) Keine gemeinsame Nutzung von Ressourcen!

25 SOUP SOUP (Software of unknown provenance) Software-Komponente, die bereits entwickelt und allgemein verfügbar ist und die nicht entwickelt wurde, um in das Medizinprodukt integriert zu werden bereits fertig entwickelte Software, für die angemessene Aufzeichnungen des Entwicklungsprozesses nicht verfügbar sind

26 Beispiele für SOUP Zugekaufte Bibliotheken Open-Source Bibliotheken Betriebssysteme Firmware von Komponenten Undokumentierte Altsoftware?

27 Fragestellungen bei SOUP Wie wählt man die richtige SOUP aus? Wie weit muss man Anforderungen an die SOUP dokumentieren? Wie geht man mit Abhängigkeiten von SOUP zu anderer SOUP um? Was ist das Interface eines Betriebssystems? Was kann der SOUP-Hersteller tun, um uns das Leben zu erleichtern?

28 Aktivitäten Software-Risikomanagement Analyse der Softwareeinheiten, die zu Gefährdungen beitragen Risikokontrollmaßnahmen Verifizierung von Risikokontrollmaßnahmen Risikomanagement von Softwareänderungen

29 Mögliche Ursachen nach IEC fehlerhafte oder unvollständige Spezifikation der Funktionalität Software-Defekte in der Funktionalität der identifizierten Software- Komponente Ausfall oder unerwartete Ergebnisse einer SOUP Hardware-Ausfälle oder andere Software-Defekte, die zu einer unvorhersehbaren Software-Funktionsweise führen könnten vernünftigerweise vorhersehbarer Missbrauch

30 Fault-Tree-Analysis (FTA) Falsche Dosisanzeige oder Dosis falsch berechnet Anzeige falsch oder oder Rundungsfehler Überlauf Ausfall Displaytreiber Falsche Zahlendarstellung Algorithmus.c Displaytreiber (SOUP) Grafik-Bibliothek (SOUP)

31 Neuerungen im Wann ist Software Amendment 1 ein Medizinprodukt? der IEC 62304

32 Einführung This amendment is intended to add requirements to deal with LEGACY SOFTWARE, where the software design is prior to the existence of the current version, to assist manufacturers who must show compliance to the standard to meet European Directives. Software safety classification changes needed for this amendment include clarification of requirements and updating of the SOFTWARE SAFETY CLASSIFICATION to include a risk-based approach.

33 Altsoftware LEGACY SOFTWARE MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today but for which there is insufficient objective evidence that it was developed in compliance with the current version of this standard A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP

34 Was ist zu tun? Auswertung der Rückmeldungen (Software-)Risikoanalyse der Altsoftware Software-Sicherheitsklassifizierung Gap-Analyse (Dokumente & Aktivitäten) Prüfung der bestehenden Dokumente Bewertung der Risikoreduktion durch Aktivitäten und Nachdokumentation Schließen der festgestellten Lücken

35 Nachdokumentation A SW-Anforderungen SW-System-Prüfung B SW-Architektur SW-Integration / Integrationsprüfung C Detailliertes Design Verifikation der Impl.

36 Software-Sicherheitsklassen

37 Was sonst noch anders ist Begriffsklärungen ( Software Product ) Verschärfung der Anforderungen für Sicherheitsklasse A (z.b. Software-Systemtest) Security soll in den Software-Anforderungen berücksichtigt werden Verweis auf die IEC : Medical device software Part 1: Guidance on the application of ISO to medical device software Der Preis: 114 -> 650!

38 Was noch immer offen ist Konkrete Forderungen Unit-Test Code-Review Codeanalyse SOUP-Handling Betriebssysteme Massiver Einsatz von SOUP

39 Ausblick IEC/DIS Entwurf einer Norm für Health Software Deckt auch Standalone-Software ab Bezieht sich nicht nur auf Medizinprodukte!

40 Ausblick VDI Fachausschuss für Software-Qualität in der Medizintechnik Richtlinie 5702, Blatt 1: Medical SPICE Richtlinie 5702, Blatt 2: Best Practices

41 Fazit Das Amendment 1 der IEC bringt kleinere Korrekturen und Verbesserungen Der Umgang mit Altsoftware wird nach fast 10 Jahren geregelt Bei der Software-Sicherheitsklassifizierung kann die Wahrscheinlichkeit eines Schadens mit eingehen Wesentliche Hilfestellungen für Hersteller finden sich aber nicht

42 Kontakt MATTHIAS HÖLZER-KLÜPFEL DIPLOM-PHYSIKER, M.SC. post Zweite Felsengasse Würzburg tel fax mobil mail web matthias@hoelzer-kluepfel.de