Post on 30-Mar-2019
transcript
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
Probleme der EN 62304
Prof. Dr. Jürgen Stettin 4
• Software Safety Classification • Alles wird immer zu Klasse C • Software ist häufig riskoreicher eingestuft, als das Risko des Gesamtsystems
Derzeitiger Diskussionsstand zur Klassifizierung
Prof. Dr. Jürgen Stettin 5
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.
Probleme der EN 62304
Prof. Dr. Jürgen Stettin 6
• 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
Probleme der EN 62304
Prof. Dr. Jürgen Stettin 7
• 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
Prof. Dr. Jürgen Stettin 8
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
Probleme der EN 62304
Prof. Dr. Jürgen Stettin 9
• 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
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
Prof. Dr. Jürgen Stettin 15
AAMI TIR38 Infusion devices - Assurance Case Report guidance Diese Richtlinie ist in USA in der Entwicklung und noch nicht veröffentlicht.
Konformität
Prof. Dr. Jürgen Stettin 18
• 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
Prof. Dr. Jürgen Stettin 19
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
Prof. Dr. Jürgen Stettin 20
FFA: Functional Failure Analysis FMEA: Failure Mode and Effect Analysis
herleitbar bekannt
unbekannt verallgemeinert
belegt
erforschend
unbekannt bekannt
Prof. Dr. Jürgen Stettin 22
PSSA: Preliminary System Safety Assessment PHI: Preliminary Hazard Identification
Was sagt die FDA ?
Prof. Dr. Jürgen Stettin 23
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!
Medizinische IT Netzwerke
Prof. Dr. Jürgen Stettin 31
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
Prof. Dr. Jürgen Stettin 32
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
Prof. Dr. Jürgen Stettin 33
• 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.
Prof. Dr. Jürgen Stettin 34
EN 60601-1 Kapitel 14
EN 62304
EN 14971 Risikomanagement
IEC 80001-x Risk Management for IT-networks
AAMI SW 87 Med. Device Data
Systems
Prof. Dr. Jürgen Stettin 41
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
Prof. Dr. Jürgen Stettin 47
IEC 60601-1 Medical electrical equip
IEC 60601-1 Medical electrical equip
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
ISO NP 17522
Prof. Dr. Jürgen Stettin 49
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:
Prof. Dr. Jürgen Stettin 51
Ü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:
Prof. Dr. Jürgen Stettin 52
Ü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
Prof. Dr. Jürgen Stettin 54
EN 60601-1 Kapitel 14
EN 62304
EN 14971 Risikomanagement
IEC 82304 Stand-Alone
Software
Health Applications on Mobile/Smart
Devices
IEC 80001-x Risk
Management for IT-networks