Lessons learned Software Engineering für die Gesundheitstechnologie

Transkript

1 Lessons learned Software Engineering für die Gesundheitstechnologie Andreas Oyrer, GF CDE GmbH CDE - Communications Data Engineering GmbH A-4232 Hagenberg Softwarepark 37/

2 Agenda Kurzvorstellung CDE Software-Entwicklung für die Medizintechnik Medical Apps Best practice & Lessons learned 2

3 Vorstellung CDE 3

4 Über CDE GmbH Gründung Mitarbeiter Softwarepark Hagenberg QM-System ISO Software und Elektronik Entwicklung 4

5 Leistungen und Kompetenzen Wir entwickeln Lösungen mit Leidenschaft, um unsere Kunden zu begeistern. Hardware & Firmware Apps & Web NFC & Wireless Konzept, Schaltplan, Layout Embedded Software Prototypen & Kleinserien Android & ios Webportale mit Datenbank Sicherheit & Datenschutz NFC Technologie Bluetooth Low Energy (BT 4.0) UMTS, WLAN, 5

6 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. Auftraggeber: Otto Bock Healthcare Products GmbH 6

7 moveguard mobile Gesundheits App Medizintechnik App Webportal Telemedizin Die App moveguard mobile bietet einen Gesundheits-Check auf Basis der aktuellen Vitalparameter und liefert einen individuell abgestimmten Trainingsplan. Auftraggeber: IQ mobile GmbH 7

8 Software-Entwicklung für die Medizintechnik 8

9 Medizinprodukt vs. normales Embedded System Definiert durch seine Zweckbestimmung 9

10 Software für ein Medizinprodukt 26% der Fehler sind Software bedingt Programmierfehler, zu wenig Tests,... Unzureichende Gebrauchstauglichkeit Entwicklung der Komplexität (Lines of Code) Anforderungen falsch aufgefasst Zahlenformate (z.b. Trennzeichen) Qualitätskontrolle bei der Entwicklung Dafür ist ein Regelwerk notwendig: Quelle: BfArM

11 Überblick relevante Normen IEC 62304: Software Lebenszyklus Prozess ISO 13485: Qualitätsmanagement System ISO 14971: Risikomanagement IEC 82304: Gesundheitssoftware (Entwurf) IEC 62366: Gebrauchstauglichkeit / Usability IEC : Programmierbare Medizinelektronik 11

12 IEC 62304: Software Lebenszyklus Prozess Prozess für Entwicklung von Software für ein Medizinprodukt Software als Komponente des Medizinprodukts Standalone-Software, z.b. Medical Apps Mögliches Risiko bestimmt Umfang von Doku und Test Keine Verletzung (Klasse A) Anforderungen, Grob-Design Leichte Verletzung (Klasse B) Genauere Anforderungen und Design Tod oder schwere Verletzung (Klasse C) Detail-Design, Design-Review, Code-Reviews, Unit-Tests, Schnittstellen-Architektur,... 12

13 IEC Prozessübersicht und Begleitprozesse 13

14 IEC 82304: Gesundheitssoftware (derzeit nur als Entwurf) Reguliert den Entwicklungsprozess für Gesundheitssoftware Standalone-Software, Medical 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 14

15 Medical Apps 15

16 Medical Apps Ca Gesundheits-Apps Der Doktor in der Hosentasche Ist die App ein Medizinprodukt? Chancen von Medical Apps Rasche Analyse, Vortests Zeitersparnis Kommunikation mit Experten Risiken von Medical Apps Qualität der Diagnose Datenschutz Vielzahl an Plattformen 16

17 Medical App Entwicklung Medical App ist ein Medizinprodukt Klassifizierung und Behandlung wie Medizinprodukte Zweckbestimmung Dokumentation, Kennzeichnungspflicht, Meldepflicht QM-System, Entwicklung nach IEC 62304, Risikomanagement Usability immer wichtiger (IEC 62366) Fehlervermeidung durch logische Menüführung Größe der Buttons Kontrast / Lesbarkeit bei Lichteinfall Bedienung evtl. mit Handschuhen 17

18 Medical App Entwicklung Medical Apps werden oft unterschätzt IEC und QM-System nach ISO Keine allgemein gültige Klassifizierung möglich Muss im Einzelfall mit Experten analysiert werden Keywords für Kennzeichnung als Medizinprodukt (MHRA Guideline) Analysieren, Berechnen, Verstärken, Detektieren, Überwachen, Steuern, Alarmieren, Umrechnen, Messen, Datenschutzbestimmungen beachten (bei Server-Anbindung) Guidelines Medical Apps

19 Best Practice & Lessons learned 19

20 Best Practice & Lessons learned Requirements Management Klare Erfassung der Anforderungen viel Zeit reservieren Zuordnung von Anforderungen zu den Testfällen (Traceability) Risko und Zielgruppe bestimmen Unit Tests Auf Testability achten, Automatisierte Tests Selbsttest-Mechanismen einbauen z.b. CRC-Check, Watchdog Modularität & Wiederverwendbarkeit Model-Based Design 20

21 Requirements Management mit Polarion 21

22 Unit Testing Ziele und Anforderungen Ziele: Automatisiertes Testing & Regression Tests 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 22

23 Anforderungen an Unit Tests 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 23

24 Unit Tests mit Tessy Code und Interfacedefinition 24

25 Zusammenfassung 25

26 Zusammenfassung Ziel: sicheres Medizinprodukt Medical Apps sind Medizinprodukte Entwicklung von Software für Medizinprodukt ist aufwändig Zweckbestimmung und Klassifizierung entscheidend über Aufwand QM-System und Einhaltung der Normen und Gesetze notwendig 26

27 Herzlichen Dank! DI (FH) Andreas Oyrer Geschäftsführung Tel