Home >Software >Erfahrungen aus der Entwicklung einer Klasse C Medical App (Medical Apps 2014)
Erfahrungen aus der Entwicklung einer Klasse C Medical App (Medical Apps 2014)
Date post:29-Nov-2014
Category:Software
View:174 times
Download:0 times
Share this document with a friend
Description:
Was haben die Entwicklung von Medizinsoftware und die einer App gemeinsam? Vieles! Das ist die Erkenntnis aus unseren Erfahrungen nachdem wir eine Klasse C Medical App erfolgreich entwickelt hatten. Die wenigen Unterschiede sollte man jedoch von Anfang an mit bedenken. Der Vortrag beleuchtet die Erfahrungen aus der Entwicklung der App, insbesondere folgende Bereiche: - Zusammenarbeit mit einer Design Agentur - nderungsgeschwindigkeit (Mobilplattform, Erwartungen der App Benutzer) - Einsatz eines ALM Tools - Plattform- / Infrastrukturvalidierung - Deployment
Transcript:
<ul><li> 1. Zhlke 2014 Erfahrungen aus der Entwicklung einer Klasse C Medical App Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 1 von 40 Bildquelle:https://placeit.net/-berarbeitetundangepasst </li></ul><p> 2. Zhlke 2014 Agenda Regulatorisches zu Medical Apps Vorstellung der App Was ist besonders bei der Entwicklung einer Medical App und wie geht man damit um? Deployment Plattformvalidierung Design und Usability Hufige Releases Fazit Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 2 von 40 3. Zhlke 2014 Matthias.Wufka@zuehlke.com Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Senior Project Manager Schwerpunkte Entwicklung sicherheitskritischer Systeme Projektmanagement Entwicklungsprozesse Qualittsmanagement 14 Jahre Berufserfahrung Systementwicklung (Hard-, Software, Mechanik) Projektmanagement In regulierten Projekten In EU gefrderten Projekten In agilen Projekten In groen und verteilten Projekten Medizintechnik, Energiewirtschaft Dipl.-Ing. (FH) Elektrotechnik - Automatisierungstechnik 14. Oktober 2014 Folie 3 von 40 4. Zhlke 2014Outsourcing - Modelle in der bersicht | Jrg Sitte Zhlke: Facts &amp; Figures Mehr als 8'000 Projekte realisiert Entwicklung &amp; Beratung fr Software, Elektronik, Sensorik, Konstruktion 85 Mio. Umsatz (2013) 630 Mitarbeiterinnen &amp; Mitarbeiter (Ende 2013) In Deutschland, Grobritannien, sterreich, Serbien und in der Schweiz Gegrndet 1968, im Besitz von Partnern ISO 9001 und 13485 zertifiziert 16. Oktober 2014 Folie 4 von 40 5. Zhlke 2014 Regulatorisches zu Medical Apps 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 5 von 40 6. Zhlke 2014 Was sind Medical Apps? Mobile Apps, die aus einer mobile Plattform in ein reguliertes Medizinprodukt machen Mobile Apps, die sich mit einem existierenden Medizinprodukt verbinden, um dieses zu bedienen (Zubehr zu einem Medizinprodukt) Mobile Apps, die mit einem Medizinprodukt verbunden sind und patientenspezifische medizinische Daten anzeigen, bertragen, speichern oder konvertieren. Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Beispiele fr Medical Apps 14. Oktober 2014 Folie 6 von 40 7. Zhlke 2014 Was sind keine Medical Apps? Health Apps helfen dem Benutzer einen gesunden Lebenswandel zu fhren oder bieten gesundheitsbezogene Services. Zielgruppe sind Endverbraucher und nicht medizinisches Fachpersonal Die populrsten Bereiche fr Health Apps sind Sport/Aktivitt, Stress und Diten. Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Beispiele fr Health Apps: 14. Oktober 2014 Folie 7 von 40 8. Zhlke 2014 Welche Normen / Regularien gelten? Mobile Medical Apps sind Medizinprodukte, dementsprechend gelten die Regelungen fr Medizinprodukte Mobile Medical Apps sind Softwareprodukte, also trifft insbesondere die IEC 62304 zu Spezifische Regelungen: FDA Guidance on Mobile Medical Applications Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 8 von 40 9. Zhlke 2014 Vorstellung der App 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 9 von 40 10. Zhlke 2014 Medical App fr Diabetes Management Verwaltung (Eingabe, Modifikation, Anzeige, Speicherung und Export) von Blutzucker- und Insulinwerten, sowie zustzlichen Informationen wie z.B. Ernhrung Automatische Synchronisation mit einem Blutzuckermessgert Graphische und textuelle Darstellung der Messwerthistorie Nur fr die Apple Plattform (IPhone, IPad, IPod Touch) Risikoanalyse ergibt, dass der Tod eines Patienten mglich ist Klasse C (nach IEC 62304) Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 10 von 40 11. Zhlke 2014 Entwicklung einer Medical App und wie geht man damit um? 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 11 von 40 12. Zhlke 2014 Deployment 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 12 von 40 13. Zhlke 2014 Deployment von Apps fr den Endbenutzer Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Upload in den App Store Download aus dem App Store Statistiken Meldung ber neue Versionen Inverkehrbringer Endbenutzer / Anwender App Store (z.B. Apple) 14. Oktober 2014 Folie 13 von 40 14. Zhlke 2014 Was ergeben sich fr Herausforderungen dadurch? Keine direkte Kundenbeziehung / Keine Information ber die Endbenutzer / Anwender nur ber spezifische Features machbar Nachgelagerter Phase des SW Lebenszyklus und des Risikomanage- ments mssen anders betrachtet werden Gewisse Einschrnkungen werden erst durch den App Store mglich und knnen vorab nur sehr schwer getestet werden Im App Store ist die App fr jede verfgbar, keine Einschrnkung auf medizinisches Fachpersonal mglich Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 14 von 40 15. Zhlke 2014 Deployment von Apps whrend der Entwicklung oder fr einen eingeschrnkten Benutzerkreis Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Direkt ber Kabel an den PC spezifische Deploy App Freischalten jedes Mobiltelefons Upload der App Installation der Deploy App Download der App 14. Oktober 2014 Folie 15 von 40 16. Zhlke 2014 Plattformvalidierung 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 16 von 40 17. Zhlke 2014 Herausforderungen bei der Plattformvalidierung Wie validiere ich eine Mobile Plattform? Wie gehe ich mit dem OS und Bibliotheken um? Wie gehe ich mit nderungen an der Plattform um? Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 17 von 40 18. Zhlke 2014 Validierungsansatz Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Betriebsbewhrt Risikobasiert Als Componente in die FMEA aufnehmen Risikobeurteilung und -akzeptanz Risikomindernde Manahmen 14. Oktober 2014 Folie 18 von 40 Risikobasiert Als Componente in die FMEA aufnehmen Risikobeurteilung und -akzeptanz 19. Zhlke 2014 Beispiel einer FMEA Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Potential failure Failure effect Failure cause Risk Control Measure P S D R P N Planned Measure P S D R P N Cross device compatibility (iPadx;iPhon ex, iPodx) User misinterprets data, draws wrong conclusions and mismedicates insulin App is used on a device which is not listed and tested for compatibility RI-1673 - Notify User if Running on Untested Device Version RI-1674 - Disable Installation in AppStore 2 10 3 60 Interruption of App execution User inconvenience Incoming phone call 9 2 7 127 RI-2104 - App is placed in the background when a phone call is incoming 1 2 2 4 14. Oktober 2014 Folie 19 von 40 20. Zhlke 2014 Design und Usability 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 20 von 40 21. Zhlke 2014 Usability und Design haben eine zentrale Bedeutung Apps sind UI lastig Benutzer von Apps lassen sich nicht nur durch Funktionalitt begeistern Ein gutes Design und gute Usability sind sehr wichtig Einbindung ein UI Agentur (meist mit wenig regulierter Erfahrung) Passende Strukturierung der Anforderungsdokumente Einsatz von agilen Methoden Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 21 von 40 22. Zhlke 2014 Struktur der Dokumentation der Anforderungen Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Intended Use Intended Use Stakeholder Needs Stakeholder Needs SRSSRS SDSSDS SW-ModuleSW-Module Use Cases, Non-functional Requirements, Use Cases, Non-functional Requirements, UI-Specification (Mock-Up, Flows, Content UI-Specification (Mock-Up, Flows, Content User &amp; Market Needs, Use Case Diagram, Standards, Regulations User &amp; Market Needs, Use Case Diagram, Standards, Regulations Intended Use, Patient Population, User Profile, Conditions of Use Intended Use, Patient Population, User Profile, Conditions of Use DesignDesign 14. Oktober 2014 Folie 22 von 40 23. Zhlke 2014 Umsetzung eines Features Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka UseCases UI Spezifikation als Mock-Up Design zu dem Feature Umsetzung Test UI Spec als Mock-Up Design zu dem Feature Umsetzung Test Feature Review 14. Oktober 2014 Folie 23 von 40 24. Zhlke 2014 Scrum Vorgehen Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Sprint 2 weeks 24 hours Product Backlog Item priority set by Product Owner Sprint Backlog Team determines necessary work Potentially Shippable Product Increment Daily Scrum Meeting Embrace and Manage Complexity! 14. Oktober 2014 Folie 24 von 40 25. Zhlke 2014 AAMI TIR45 Titel: Guidance on the use of AGILE practices in the development of medical products AAMI: Association for the Advancement of Medical Instrumentation TIR 45: Technical Information Report Nr. 45 Verffentlicht im August 2012 Im Q1/2013 von der FDA in die Liste der Recognized Standards aufgenommen Erhltlich ber www.aami.org fr $ 130 Terms and definitions Standard Medical Glossar Agiles Glossar sehr hnlich SCRUM Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 25 von 40 26. Zhlke 2014 Design Input / Design Output Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Design Input Activities (Definitions) Design Output Activities (Design) Figure 5-DESIGN INPUT/OUTPUT relationship: Highest level of abstraction Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Output: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Design Input: Activities Figure 6-DESIGN INPUT/OUTPUT relationship: WATERFALL development 14. Oktober 2014 Folie 26 von 40 27. Zhlke 2014 Design Input / Design Output Gesamtbild Agile Projekte sollten Synchronisationspunkte definieren, an denen Reviews stattfinden sollten und dabei den Level of Control festlegen. Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Synchronize Design Inputs &amp; Design Outputs (Increments) Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Design Input Activities Design Output Activities Story Synchronize Design Inputs &amp; Design Outputs (Increments) Synchronize Design Inputs &amp; Design Outputs (Increments) Synchronize Design Inputs &amp; Design Outputs (Release) Figure 11-Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 27 von 40 28. Zhlke 2014 Verification Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Begleitende Verifikation Final verification Fhre eine finale Verifikation gegen die Design Inputs durch. Die Ergebnisse der begleitenden Verifikation knnen dabei bercksichtigt werden. St or y Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Synchronize Design Inputs &amp; Design Outputs (Increments) St or y Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story St or y Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Synchronize Design Inputs &amp; Design Outputs (Increments) Synchronize Design Inputs &amp; Design Outputs (Release) St or y Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Activities Design Input Activities Activities Design Output Activities Story Synchronize Design Inputs &amp; Design Outputs (Increments) Figure 11-Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries 14. Oktober 2014 Folie 28 von 40 29. Zhlke 2014 Hufige Releases 14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 29 von 40 30. Zhlke 2014 Umgang mit nderungen, Entwicklungstempo Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 2-3 neue Versionen der App pro Jahr Neue Gerte (Consumer) Erwartungen der Benutzer Update OS Neue Features Bugfixes Entwicklungs- vorgehen 14. Oktober 2014 Folie 30 von 40 APP 31. Zhlke 2014 Konsequenzen von 2-3 Versionen pro Jahr Einsatz von agile Methoden Einsatz von Continuous Integration Einsatz von Testautomatisierung Einsatz eines ALM Tools Erfahrun...</p>
Embed Size (px)
Recommended