Best Practices Software Engineering für Smart Solutions in der Gesundheitstechnologie Andreas Oyrer, GF CDE GmbH 04.12.2014 CDE - Communications Data Engineering GmbH A-4232 Hagenberg Softwarepark 37/1 07236 3351-43501
Agenda Kurzvorstellung CDE Software-Entwicklung für die Medizintechnik Relevante Normen Best practice 2
Vorstellung CDE 3
Über CDE GmbH Gründung 2001 12 Mitarbeiter Softwarepark Hagenberg QM-System ISO 13485 Software und Hardware Entwicklung 4
Leistungen und Kompetenzen Wir entwickeln Lösungen mit Leidenschaft, um unsere Kunden zu begeistern. Hardware & Firmware Apps & Web NFC & Wireless Konzept, Schaltplan, Layout Low-Power Design Cloud- und NFC-Integration Prototypen & Kleinserien Android & ios Webportale mit Datenbank User-Interface-Design Sicherheit & Datenschutz NFC Technologie Bluetooth Low Energy GPRS, UMTS, WLAN, Embedded Entwicklung 5
Software für ActiGait-System Medizintechnik Embedded Wireless CDE entwickelt Software für das ActiGait- System von Ottobock das bei Patienten mit chronischer Fußheber-Schwäche zum Einsatz kommt. 6
Muskel & Nervenstimulation Medizintechnik Embedded CDE entwickelt Software für ein Muskelund Nervenstimulationsgerät, das im medizinischen Bereich und zur Elektrostimulation eingesetzt wird. 7
moveguard mobile Gesundheits App Medizintechnik App Webportal Die App moveguard mobile bietet einen Gesundheits-Check auf Basis der aktuellen Vitalparameter und liefert einen individuell abgestimmten Trainingsplan. 8
Software-Entwicklung für die Medizintechnik 9
Medizinprodukt vs. normales Embedded System Definiert durch seine Zweckbestimmung 10
Software für ein Medizinprodukt 21% der Fehler sind Software bedingt Entwicklung der Komplexität (Lines of Code) Anforderungen falsch aufgefasst Programmierfehler Zu wenig Tests,... Qualitätskontrolle bei der Entwicklung Dafür ist ein Regelwerk notwendig: sonstige Fehler Softwarefehler 21% Quelle: BfArM 2010 11
Anforderungen an Softwareentwicklung für Medizinprodukte QM-System nach ISO 13485 Prüfung der Normanforderungen Software Lifecycle Prozess (IEC 62304) Entwicklungsplanung Software-Sicherheitsklassifizierung Risikomanagement (ISO 14971) Anforderungsmanagement Validierung der Software-Tools Traceability... 12
Relevante Normen 13
Überblick relevante Normen ISO 13485: Qualitätsmanagement System ISO 14971: Risikomanagement IEC 62304: Software Lebenszyklus Prozess IEC 82304: Gesundheitssoftware (Entwurf) IEC 62366: Gebrauchstauglichkeit / Usability IEC 60601-1: Programmierbare Medizinelektronik 14
IEC 62304: Software Lebenszyklus Prozess Prozess für Entwicklung von Software für ein Medizinprodukt Software als Komponente des Medizinprodukts Standalone-Software Validierung des Gesamtsystems nicht Teil von IEC 62304 Schweregrad der Verletzung bestimmt Umfang von Doku und Test Keine Verletzung (Klasse A) Anforderungen, Grob-Design Leichte Verletzung (Klasse B) Tod oder schwere Verletzung (Klasse C) Detail-Design, Design-Review, Code-Reviews, Unit-Tests, Schnittstellen-Architektur,... 15
IEC 62304 Sicherheitsklassifizierung Herabstufung durch Hardware-Risikokontrollmaßnahme möglich 16
IEC 62304 Übersicht und Begleitprozesse 17
Missing Link: Standalone-Software 18
IEC 82304: Gesundheitssoftware (derzeit nur als Entwurf) Reguliert den Entwicklungsprozess für Gesundheitssoftware Standalone-Software, Apps (Medizinprodukt) Health Software, Apps (kein Medizinprodukt) Prozessanforderungen Risikomanagement (ISO 14971) Software-Lifecycle Prozess (IEC 62304) Gebrauchstauglichkeit (IEC 62366) Beinhaltet zusätzlich Validierung des Software-Gesamtsystems Kennzeichnung Dokumentation 19
Smartphone-App Entwicklung App ist eine Standalone-Software IEC 82304 Datenschutzrichtlinien beachten Keywords für Kennzeichnung als Medizinprodukt (MHRA Guideline) Verstärken, Berechnen, Detektieren, Überwachen, Steuern, Alarmieren, Umrechnen, Analysieren, Messen, Guidelines Medical Apps http://www.mhra.gov.uk/howweregulate/devices/software/index.htm http://www.fda.gov/medicaldevices/productsandmedicalprocedures/connected Health/MobileMedicalApplications/ucm255978.htm 20
Best Practice Softwareentwicklung 21
Anforderungen und Best Practice Requirements Management Erfassung der Anforderungen Zuordnung von Testfällen zu den Anforderungen (Traceability) Unit Tests Auf Testability achten Automatisierte Tests Modularität & Wiederverwendbarkeit sehr wichtig Selbsttest-Mechanismen einbauen (z.b. CRC-Check, Watchdog) Model-Based Design 22
Toolvorstellung Polarion 23
Übersicht Anforderungsdokumente 24
Lastenheft Anforderung CLG-456 definiert eine Anforderung für Service Zugehörige Lastenheft- Testspezifikation 25
Pflichtenheft Testspezifikation PH Testanforderung CLG-414 verifiziert PH-Anforderung CLG-375 26
Unit-Testing für Embedded Software 27
Unit Testing Ziele und Anforderungen Ziel: Automatisiertes Testing Reproduzierbarkeit Jeder Testlauf muss die gleichen Ergebnisse liefern Testabdeckung (Code Coverage) Stimulieren der Inputs (Parameter, globale Variablen und Puffer, ) Überwachen der Outputs (Parameter, globale Variablen und Puffer, ) Simulation lokaler Funktionen zur Reduktion der Testfälle und der Komplexität der Tests 28
Anforderungen an Unit Tests für Embedded Software Der Test-Code muss mit dem Zielcompiler übersetzt werden Der Test-Code muss auf Zielhardware bzw. Simulator laufen Hardware-abhängigen Code kapseln (HAL) HAL wird für Tests gegen Stubs ausgetauscht gewünschtes (Fehl-)verhalten kann simuliert werden Ist eine Abstraktion nicht möglich können die Hardwareregister als Sammlung globaler Variablen definiert werden. Beim Test können die Variablen stimuliert bzw. überwacht werden. 29
Unit Tests mit Tessy Code und Interfacedefinition checkdiv() ist eine externe Funktion und prüft ob der Divisor 0 ist. 30
Unit Tests mit Tessy Testdefinition Null-Pointer übergeben Division durch 0 Korrekte Parameter 31
Unit Tests mit Tessy Testdefinition Mittels Call-Trace kann der Aufruf lokaler Funktionsaufrufe geprüft werden (Aufrufreihenfolge bzw. Aufrufanzahl muss angegeben werden) Null-Pointer, daher kein Trace 32
Unit Tests mit Tessy Erfolgreicher Testlauf Erwarteter Wert = tatsächlicher Wert Code-Coverage-Arten & Codeabdeckung vollständig Calltrace korrekt 33
Zusammenfassung 34
Zusammenfassung Ziel: Risiko durch Software-Fehler minimieren Entwicklung von Software für Medizinprodukt ist aufwändig Dokumentation, Testing, Normen prüfen und einhalten Zweckbestimmung und Klassifizierung entscheidend für Aufwand QM-System und Einhaltung der Normen und Gesetze ist erforderlich 35
Herzlichen Dank! www.cde.at DI (FH) Andreas Oyrer Geschäftsführung Tel. +43 7236 3351-4380 andreas.oyrer@cde.at 36