Tips zur Anwendung der Software Normen - asqf.de · endeten bei 10.000 Tonnen, etwa ¼ der Größe der Titanic, da man um 1894 nicht an größere Schiffe gedacht hat. •Die Titanic

Beim Strohhause 27

20097 Hamburg

phone + 49 40 47 10 36 19

web www.prosystem-ag.com

Prof. Dr. Jürgen Stettin

CEO Prosystem AG / Prosystem USA LLC

Tips zur Anwendung der Software Normen

3. Medical Device Day Franken,

Erlangen, 21.06.2012

Software Recalls in USA (Stand 06.03.2012)

Prof. Dr. Jürgen Stettin 2

Verhältnis Software Recalls zu Recalls aus anderen Gründen im Jahr 2008 etwa 16 %

Jahr

0

50

100

150

200

2004 2005 2006 20072008

20092010

2011

Jahr

Jahr


EN 60601-1 Kapitel 14

EN 62304

EN 14971 Risikomanagement

Probleme der EN 62304


• Software Safety Classification • Alles wird immer zu Klasse C • Software ist häufig riskoreicher eingestuft, als das Risko des Gesamtsystems

Derzeitiger Diskussionsstand zur Klassifizierung


If the clinical assessment of the likelihood of harm, given the occurrence of the hazardous situation, is acceptable, the software safety class is A.

If the clinical assessment of the likelihood of harm is unacceptable, and the harm is non-serious injury, the software safety class is B.

If the clinical assessment of the likelihood of harm is unacceptable, and the harm is death or serious injury, the software safety class is C.



• Software Safety Classification • Alles wird immer zu Klasse C • Software ist häufig riskoreicher eingestuft, als das Risko des Gesamtsystems • 100 % Auftretenswahrscheinlichkeit soll nur heißen, daß nichts über die

Auftretenswahrscheinlichkeit bekannt ist

• Fehlende Synchronisation mit FDA Guidance Dokument • Validierung • für Klasse A Software verlangt die FDA mehr, als die IEC 62304

• Definitionen (u.a.)

• Bessere Definition von “System” und “Produkt” • ein System kann aus mehreren Produkten bestehen

• Der Begriff “Release” ist nicht klar definiert • bessere Definition des Begriffs “Integrationsplanung”

• Die Norm gibt keine Hinweise, wie mit der Modifikation / Pflege von “alter” Software

(legacy software) umgegangen werden soll



• Die Norm berücksichtigt keine neueren Entwicklungsmethoden (wie z.B. agile Methoden)

• Die Norm gibt nicht vor, welche “artifacts” bei agilen Methoden erstellt werden sollen

• Die Vorgabe, daß jede Klasse C Einheit ein detailliertes Design haben muß, geht etwas zu weit

• Es gibt sehr viele bekannte Fehler in der Entwicklung medizinischer Software. Die Norm sollte hier eine Guidance geben

Typische Fehler im Entwicklungsprozess


Buffer Overrun Buffer Underrun Type Overrun Type Underrun Null Pointer Dereference Divide By Zero Double Free Use After Free Free Non-Heap Variable Uninitialized Variable Leak Dangerous Function Cast Delete[] Object Created by malloc Delete[] Object Created by new Delete Object Created by malloc Delete Object Created by new[] Free Object Created by new[] Free Object Created by new Missing Return Statement Redundant Condition

Runtime dead code Return Pointer To Local Return Pointer To Freed Unused Value Useless Assignment Varargs Function Cast Ignored Return Value Free Null Pointer Unreachable Code Null Test After Dereference Format String Double Close TOCTTOU Vulnerability Double Lock Double Unlock Try-lock that will never succeed Misuse of Memory Allocation Misuse of Memory Copying Misuse of Libraries

Für Klasse C Software wird vermutlich normativ der Nachweis der Berücksichtigung dieser Fehler gefordert



• Die Terminology muß mit der Terminologie der EN 14971 harmonisiert werden.

• Anpassung an die IEC 80001-1 • Guidance zum Thema “Safety Assurance Cases” • Eventuell eine Anpassung an die Norm ISO 12207 • Bessere Guidance für die Integration in ein QM System • Guidance für kleine Firmen

• Erster interner Entwurf der 2. Ausgabe im Mai 2012 • Release 2. Ausgabe im Jahr 2014

Risikomanagement und Software-Zulieferer

ACHTUNG

SOFTWARE!

Risikomanagement

EN 13485: 7 Produktrealisierung 7.1 Planung der Produktrealisierung . . Die Organisation muss dokumentierte Anforderungen für das Risikomanagement während der gesamten Produktrealisierung erarbeiten. Es müssen Aufzeichnungen geführt werden, die sich aus dem Risikomanagement ergeben (siehe 4.2.4).

Medizinprodukt Eingang

sgrößen

Output

Patient, Bediener, Andere

Umgebungseinflüsse

Störungen der Umgebung

Ansatz des Risikomanagements nach EN 14971

durch das Medizinproduktegesetz

geschützter Bereich

Eingang

sgrößen

Output

typische Risikoanalyse in anderen Industrien

Analyse des Fehlerzustands durch FMEA o.ä.

Risiko der

Ausgangsgrößen

Führt zur Analyse von tausenden von Fehlerzuständen sicheres Produkt

Medizinprodukt Eingang

sgrößen

Output

Patient, Bediener, Andere

Umgebungseinflüsse

Störungen der Umgebung

Ansatz des Risikomanagements nach EN 14971

durch das Medizinproduktegesetz

geschützter Bereich

Analyse der

Patientengefährdung

Analyse und Beseitigung der Fehlerquellen führt zu Patientensicherheit

Risikomanagement: Safety Assurance Cases


AAMI TIR38 Infusion devices - Assurance Case Report guidance Diese Richtlinie ist in USA in der Entwicklung und noch nicht veröffentlicht.



Konformität


• Die Anzahl der Rettungsboote wurde im “Merchant Shipping Act” von 1894 vorgegeben.

• Die Anzahl der Rettungsboote war proportional zur Tonnage. Die Tabellen dafür endeten bei 10.000 Tonnen, etwa ¼ der Größe der Titanic, da man um 1894 nicht an größere Schiffe gedacht hat.

• Die Titanic hatte doppelt soviel Rettungsboote, wie gefordert.

• Eis war eine bekannte Gafahr im Nordatlantik im Frühling. Die Vorgabe in den maritimen Publikationen dazu war, daß Eisberge nur nördlich von 43° N und westlich von 45° W vorkommen. Die Titanic fuhr etwa 100 Meilen südlich davon.

• Verifizierung & Validierung: Sämtliche damals üblichen Tests und Testfahrten wurden gemacht.

Die Titanic war normen- und gesetzkonform


The Principled Design of Computer System Safety Analyses David John Pumfrey Submitted for the degree of Doctor of Philosophy University of York, Department of Computer Science September 1999


FFA: Functional Failure Analysis FMEA: Failure Mode and Effect Analysis

herleitbar bekannt

unbekannt verallgemeinert

belegt

erforschend

unbekannt bekannt



PSSA: Preliminary System Safety Assessment PHI: Preliminary Hazard Identification

Was sagt die FDA ?


IEC 62304 Requirements for lifecycle processes in software development

But no requirements for the software itself

• These processes are not quality processes • They are in addition to them! • They are moderated by the quality processes • How do you determine compliance unless you are a developer? Needs deep

knowledge of the culture! • Hard for a corporate culture to assure itself of compliance!

Fazit der FDA: Anwendung der EN 62304 reicht nicht aus!





EN 62304


Medizinische Netze


Hamburger Abendblatt, 27.03.2012


Medizinische IT Netzwerke

29


http://www.secure-medicine.org/ Quelle: Qmed.com

Medizinische IT Netzwerke


Guidelines zur IEC 80001-1 (Application of risk management for IT-networks incorporating medical devices) • IEC TR 80001-2-1

• Step by Step Risk Management of Medical IT-NETWORKS; Practical Applications and • Examples

• IEC TR 80001-2-2

• Guidance for the communication of medical device security needs, risks and controls

• IEC TR 80001-2-3 • Guidance for wireless networks

• IEC TR 80001-2-4

• General implementation guidance for Healthcare Delivery Organizations

• Diese Guidelines sind noch nicht veröffentlicht.

• Dazu kommt dann später noch eine Richtlinie zum Thema Alarme. AAMI SW87 • Application of the Quality System to Medical Device Data Systems (MDDS).

Medical Device Data Systems


Medical Device Data Systems (MDDS) are hardware or software products that transfer, store, convert formats, and display medical device data. An MDDS does not modify the data or modify the display of the data, and it does not by itself control the functions or parameters of any other medical device. MDDS are not intended to be used for active patient monitoring. Examples of MDDS include: • software that stores patient data such as blood pressure readings for review at a later time; • software that converts digital data generated by a pulse oximeter into a format that can be

printed • software that displays a previously stored electrocardiogram for a particular patient. Quelle: http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/MedicalDeviceDataSystems/default.htm

Medical Device Data Systems


• seit 18.05.2011: Hersteller von MDDS müssen sich bei der FDA registrieren

• seit 18.04.2012: Hersteller müssen ein passendes Qualitätsmanagement System haben und Zwischenfälle an die FDA berichten.



EN 62304


IEC 80001-x Risk Management for IT-networks

AAMI SW 87 Med. Device Data

Systems


IEC 82304-1 Healthcare Software Systems







Was sagt der Hersteller: Der Rechner wird nicht "am" Patienten im Sinne des MPG verwendet und ist daher kein Medizinprodukt. Dazu kommt, dass ich keinerlei Verantwortung für die Korrektheit einer Dosierung übernehme, nachdem eben erheblich mehr Faktoren als nur Alter und Gewicht für die letztendlich Dosierungsentscheidung eine Rolle spielen.






Stand der Diskussion zur Positionierung der IEC 82304


IEC 60601-1 Medical electrical equip



IEC 82304-1 Healthcare Software Systems

IEC 62304 Medical device software life cycle processes

IEC 60601-1 Medical electrical equip.

ISO 14708 Active implantables

FDA Mobile Medical Applications Draft


ISO NP 17522


Provisions for Health Applications on Mobile/Smart Devices This is a proposed new technical report that describes the status and requirements of health applications and services on smart devices platforms and suggests the reference architecture for these.

… was sonst noch so in USA los ist:


Übersicht kürzlich veröffentlichter FDA Dokumente und AAMI Guidelines: • FDA Quality Manual Software Validation • FDA Infusion Pump Software Safety Research • Manufacturer remote access to medical devices • FDA Pacemaker Pulse Generator Draft Guidance • FDA Regulatory Science for Medical Devices Safety Assurance Case

Update • AAMI Medical Device Data Systems (MDDS) • AAMI TIR SW 1 Guidance on the use of agile practices in the

development of medical device software

… was sonst noch so in USA los ist:


Übersicht kürzlich veröffentlichter FDA Dokumente und AAMI Guidelines: • FDA Quality Manual Software Validation • FDA Infusion Pump Software Safety Research • Manufacturer remote access to medical devices • FDA Pacemaker Pulse Generator Draft Guidance • FDA Regulatory Science for Medical Devices Safety Assurance Case

Update • AAMI Medical Device Data Systems (MDDS) • AAMI TIR SW 1 Guidance on the use of agile practices in the

development of medical device software



EN 62304




EN 62304


IEC 82304 Stand-Alone

Software

Health Applications on Mobile/Smart

Devices

IEC 80001-x Risk

Management for IT-networks

55

Vielen Dank für Ihre Aufmerksamkeit!

Gibt es noch Fragen?

Documents

Tips zur Anwendung der Software Normen - asqf.de · endeten bei 10.000 Tonnen, etwa ¼ der Größe der Titanic, da man um 1894 nicht an größere Schiffe gedacht hat. •Die Titanic