Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Transkript

1 Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

2 Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze)

3 Innovationen für den Maschinen-, Apparate- und Anlagenbau

4 macio GmbH Kurzvorstellung Kiel Bremen Düsseldorf Karlsruhe

5 Medical Apps PROBLEMSTELLUNG MEDIZINPRODUKT

6 Problemstellung Medizinprodukt Regulatorien müssen eingehalten werden u.a. sauberes Software-Engineering Risikomanagement muss durch ein interdisziplinäres, ausgebildetes Team durchgeführt werden Qualitätsmanagement-System notwendig (nicht nur testen) SOUP software of unknown provenance kritisch und erfordert Aufwand

7 Problemstellung Medizinprodukt Für Software relevante harmonisierte Normen EN 62304:2006 Medical device software - Software life-cycle processes EN Medical devices - Application of usability engineering to medical devices EN Edition Medical electrical equipment -- Part 1: General requirements for basic safety and essential performance EN 14971:2012 Medical devices - Application of risk management to medical devices EN 13485:2012 Medical devices - Quality management systems - Requirements for regulatory purposes Quelle: Michael Engler IT-Consulting 7

8 Problemstellung Medizinprodukt Anforderungen der har. Normen nach Themen Norm Konfigurations -management Qualitätsmanagement Risikomanagement Software- Entwicklung Software- Wartung EN X X X EN X X EN X X X X X EN X X X EN X X X Michael Engler IT-Consulting 8

9 IEEE IEEE Healthcare informatics mit diversen Teilnormen auch für Bluetooth koppelt bestimmte Gerätetypen miteinander Thermometer Waage

10 Medical Apps APP GRUNDLAGEN

11 App Grundlagen native Apps Clientside Web Apps Hybrid Apps Interpretierte Apps Cross-kompilierte Apps Store Problematik

12 native Apps Web-Server führt zentrale Applikationslogik aus Native App Dateien DB Device Backend

13 native Apps Plattform ios Android Windows Phone Technologie Mac, XCode, Objective-C Java C# / VB.net Infrastruktur der App Stores Bereitstellung, Verteilung, Updates, Abrechnung u.u. Freigabe durch Dritte erforderlich Vollständiger Zugriff auf Sensorik Beschleunigungssensoren, Kamera, GPS,

14 native Apps Native Apps sind optimal, wenn... das natürliche Look & Feel des Gerätes genutzt werden soll.... es auf Top-Performance ankommt.... die Applikation in App Stores der Anbieter verfügbar sein soll

15 Clientside Web Apps Web Browser App (Javascript) Web-Server führt zentrale Applikationslogik aus Dateien DB Dateien DB Device Backend

16 Clientside Web Apps Die Applikation läuft mit HTML5 und Javascript direkt im Webbrowser des Gerätes Performance ist stark abhängig vom Browser Bei der UI-Darstellung unterstützen diverse Frameworks (z.b. JQuerymobile, Sencha-Touch, Sencha-ExtJS,...) Zugriff auf Sensoren und andere Schnittstellen des Gerätes noch (lange) nicht vollständig Apps sind auf fast allen Geräten lauffähig (Browser Engine) Keine App Store Unterstützung

17 Clientside Web Apps Clientside Web Apps sind optimal, wenn ein Service mit einem Prototypen getestet werden soll.... es sich wie eine App anfühlen soll und kein Zugriff auf die Sensorik des Gerätes erfolgen soll.... Plattformunabhängigkeit wichtig ist

18 Hybrid Apps Native App Library (native) Web-Server führt zentrale Applikationslogik aus Bridge Native Code App (Javascript) Interpreter Dateien DB Device Backend

19 Hybrid Apps

20 Hybrid Apps Analog zu Clientside Web Apps Zugriff auf alle Features des Gerätes Verfügbar für fast alle vorhandenen Geräte App Store Unterstützung wie bei Nativen Apps

21

22 Hybrid Apps Hybrid Apps sind optimal, wenn... die Applikation auf Basis von HTML5 erstellt werden soll.... Zugriff auf die Hardware des Gerätes benötigt wird.... Plattformunabhängigkeit wichtig ist

23 Interpretierte Apps Native App API API API API Web-Server führt zentrale Applikationslogik aus Abstraction Layer Native APIs App (Javascript) Interpreter Dateien DB Device Backend

24 Interpretierte Apps one language to build them all Laufen in einer Laufzeitumgebung Ermöglichen Zugriff auf Sensorik Semi natives Look & Feel Gute Performance Beispiel: Appcelerator

25 Cross-kompilierte Apps one language to build them all Laufen native auf dem Smartphone Ermöglichen Zugriff auf Sensorik Semi natives Look & Feel Gute Performance Beispiel: Qt

26 Store Problematik Anderer entscheidet über Freigabe Zeitliche Verzögerung Haftet Betreiber mit? Betreiber gibt mein Marktsegment auf Empfehlung: Besser möglichst unabhängig vom Store bleiben!

27 Medical Apps SZENARIEN (PROBLEMSTELLUNGEN UND LÖSUNGSANSÄTZE)

28 Szenario 1: Consumer-App (kein Medizinprodukt) Patient kauft App Zweck: interessant für Massenmarkt, vor allem informative Apps Architektur: BYOD, Diverse Plattformen, ideal: Code once run everywhere Kein Medizinprodukt Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

29 Szenario 2: Consumer-App als Medizinprodukt Patient kauft App Zweck: interessant für Massenmarkt, Disease-Management auch unkritische Alarme Architektur: BYOD, Diverse Plattformen, native oder ggf. interpretierte / cross-kompilierte Apps, nur empfohlene Geräte und OS Versionen Medizinprodukt Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

30 Szenario 3: Healthcare-Professional als Anwender Healthcare-Professional als Anwender Zweck: Termin-Management, grob was ist zu tun kein Alarm Architektur: BYOD, Diverse wenige Plattformen, ideal: Hybrid oder interpretierte/cross-compilierte Apps Kein Medizinprodukt Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

31 Szenario 4: Servicetechniker kein Zubehör für Medizinprodukt Servicetechniker als Anwender Zweck: Gerät/Gerätepark beobachten, Statistiken, Qualitätschecklisten (ggf. Risiko vorhanden) Architektur: ggf. BYOD, Diverse Plattformen, ideal: alles außer native kein Medizinprodukt und kein Zubehör Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

32 Szenario 5: Servicetechniker nutzt Zubehör zu Medizinprodukt Servicetechniker als Anwender Zweck: Geräte-Konfiguration, Wartung, etc. Architektur: Vorgeschriebenes Mobilgerät, ggf. mehrere Plattformen, ggf. sorgt zu konfigurierendes Gerät für Sicherheit, ggf. eigenes OS Medizinprodukt (Zubehör) Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

33 Szenario 6: Medizinprodukt für Healthcare-Professional Healthcare-Professional als Anwender Zweck: Diagnose bspw. PACS, Endoskopie-Bilder/Filme, etc. Architektur: Vorgeschriebenes Mobilgerät Medizinprodukt Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

34 Szenario 7: Kritisches Medizinprodukt Healthcare-Professional als Anwender Zweck: Fernbedienung (Herzschrittmacher, Insulinpumpen,...), Alarme,... Architektur: Eigenes Betriebssystem für Mobilgerät, Eigenes Gerät Medizinprodukt Risikomanagement gering mittel hoch Testaufwand Gesamtaufwand

35 Fazit Bei eingeschränkten Nutzergruppen und hohen Risiken: Flexibilität reduzieren Geräte genau vorgeben Anzahl an SOUP Komponenten beschränken (OS, Frameworks, etc.) Äußere Einflüsse minimieren

36 Andy Walter Niederlassungsleiter Karlsruhe Diplom-Informatiker Michael Engler IT Consulting Fon +49. (0) Fax +49. (0) Fon +49. (0) 1522 / Fax +49. (0) 201 / michael.engler@systemkontext.de VIELEN DANK FÜR IHRE AUFMERKSAMKEIT