erfahrungen aus der entwicklung einer klasse c medical app (medical apps 2014)
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 - DeploymentTRANSCRIPT
© Zühlke 2014
Erfahrungen aus der Entwicklungeiner Klasse C Medical AppErfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 1 von 40
Bild
qu
elle
:h
ttp
s://
pla
ceit.
net
/-
üb
erar
bei
tet
un
dan
gep
asst
© Zühlke 2014
Agenda
• Regulatorisches zu Medical Apps
• Vorstellung der App
• Was ist besonders bei der Entwicklung einerMedical App und wie geht man damit um?– Deployment– Plattformvalidierung– Design und Usability– Häufige Releases
• Fazit
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 2 von 40
© Zühlke 2014
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
• Senior Project Manager
• Schwerpunkte– Entwicklung sicherheitskritischer Systeme– Projektmanagement– Entwicklungsprozesse– Qualitätsmanagement
• 14 Jahre Berufserfahrung– Systementwicklung (Hard-, Software, Mechanik)– Projektmanagement
– In regulierten Projekten– In EU geförderten Projekten– In agilen Projekten– In großen und verteilten Projekten
– Medizintechnik, Energiewirtschaft
Dipl.-Ing. (FH) Elektrotechnik - Automatisierungstechnik
14. Oktober 2014 Folie 3 von 40
© Zühlke 2014Outsourcing - Modelle in der Übersicht | Jörg Sitte
Zühlke: Facts & Figures
• Mehr als 8'000 Projekte realisiert
• Entwicklung & Beratung fürSoftware, Elektronik, Sensorik,Konstruktion
• 85 Mio. € Umsatz (2013)
• 630 Mitarbeiterinnen & Mitarbeiter(Ende 2013)
• In Deutschland, Großbritannien,Österreich, Serbien und in derSchweiz
• Gegründet 1968,im Besitz von Partnern
• ISO 9001 und 13485 zertifiziert
16. Oktober 2014 Folie 4 von 40
© Zühlke 2014
Regulatorisches zu Medical Apps
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 5 von 40
© Zühlke 2014
Was sind Medical Apps?
• Mobile Apps, die aus einer mobile Plattform in ein reguliertesMedizinprodukt machen
• Mobile Apps, die sich mit einem existierenden Medizinproduktverbinden, um dieses zu bedienen (Zubehör zu einem Medizinprodukt)
• Mobile Apps, die mit einem Medizinprodukt verbunden sind undpatientenspezifische medizinische Daten anzeigen, übertragen,speichern oder konvertieren.
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Beispiele für Medical Apps
14. Oktober 2014 Folie 6 von 40
© Zühlke 2014
Was sind keine Medical Apps?
• Health Apps helfen dem Benutzer einen gesunden Lebenswandel zuführen oder bieten gesundheitsbezogene Services.
• Zielgruppe sind Endverbraucher und nicht medizinisches Fachpersonal
• Die populärsten Bereiche für Health Apps sind Sport/Aktivität, Stressund Diäten.
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Beispiele für Health Apps:
14. Oktober 2014 Folie 7 von 40
© Zühlke 2014
Welche Normen / Regularien gelten?
• Mobile Medical Apps sind Medizinprodukte, dementsprechend geltendie Regelungen für Medizinprodukte
• Mobile Medical Apps sind Softwareprodukte, also trifft insbesondere dieIEC 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
© Zühlke 2014
Vorstellung der App
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 9 von 40
© Zühlke 2014
Medical App für Diabetes Management
• Verwaltung (Eingabe, Modifikation, Anzeige, Speicherung und Export)von Blutzucker- und Insulinwerten, sowie zusätzlichen Informationen wiez.B. Ernährung
• Automatische Synchronisation mit einem Blutzuckermessgerät
• Graphische und textuelle Darstellung der Messwerthistorie
• Nur für die Apple Plattform (IPhone, IPad, IPod Touch)
• Risikoanalyse ergibt, dass der Tod eines Patienten möglich ist
Klasse C (nach IEC 62304)
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 10 von 40
© Zühlke 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
© Zühlke 2014
Deployment
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 12 von 40
© Zühlke 2014
Deployment von Apps für den Endbenutzer
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Upload in denApp Store
Download ausdem App Store
Statistiken
Meldung überneue Versionen
Inverkehrbringer Endbenutzer / Anwender
App Store (z.B. Apple)
14. Oktober 2014 Folie 13 von 40
© Zühlke 2014
Was ergeben sich für Herausforderungen dadurch?
• Keine direkte Kundenbeziehung / Keine Information über dieEndbenutzer / Anwendernur über spezifische Features machbar
• Nachgelagerter Phase des SW Lebenszyklus und des Risikomanage-ments müssen anders betrachtet werden
• Gewisse Einschränkungen werden erst durch den App Store möglichund können vorab nur sehr schwer getestet werden
• Im App Store ist die App für jede verfügbar, keine Einschränkung aufmedizinisches Fachpersonal möglich
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 14 von 40
© Zühlke 2014
Deployment von Apps während der Entwicklungoder für einen eingeschränkten Benutzerkreis
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Direkt über Kabel an den PC
spezifische Deploy App
Freischalten jedesMobiltelefons
Upload der App
Installation derDeploy App
Download derApp
14. Oktober 2014 Folie 15 von 40
© Zühlke 2014
Plattformvalidierung
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 16 von 40
© Zühlke 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
© Zühlke 2014
Validierungsansatz
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Betriebsbewährt Risikobasiert
Als Componente in dieFMEA aufnehmen
Risikobeurteilungund -akzeptanz
RisikominderndeMaßnahmen
14. Oktober 2014 Folie 18 von 40
Risikobasiert
Als Componente in dieFMEA aufnehmen
Risikobeurteilungund -akzeptanz
© Zühlke 2014
Beispiel einer FMEA
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Potentialfailure
Failureeffect
Failurecause
Risk ControlMeasure
P S D RPN
PlannedMeasure
P S D RPN
Cross devicecompatibility(iPadx;iPhonex, iPodx)
Usermisinterpretsdata, drawswrongconclusionsandmismedicatesinsulin
App is used ona device whichis not listed andtested forcompatibility
RI-1673 - NotifyUser if Running onUntested DeviceVersion
RI-1674 - DisableInstallation inAppStore
2 10 3 60
Interruptionof Appexecution
Userinconvenience
Incomingphone call
9 2 7 127 RI-2104 - App isplaced in thebackground when aphone call is incoming
1 2 2 4
14. Oktober 2014 Folie 19 von 40
© Zühlke 2014
Design und Usability
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 20 von 40
© Zühlke 2014
Usability und Design haben einezentrale Bedeutung
• Apps sind UI lastig
• Benutzer von Apps lassen sich nicht nur durch Funktionalität 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
© Zühlke 2014
Struktur der Dokumentation der Anforderungen
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
IntendedUse
IntendedUse
StakeholderNeeds
StakeholderNeeds
SRSSRS
SDSSDS
SW-ModuleSW-Module
Use Cases,Non-functionalRequirements,
Use Cases,Non-functionalRequirements,
UI-Specification(Mock-Up, Flows,
Content
UI-Specification(Mock-Up, Flows,
Content
User & Market Needs, UseCase Diagram,
Standards, Regulations
User & Market Needs, UseCase 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
© Zühlke 2014
Umsetzung eines Features
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Use
Cas
es
UI Spezifikation alsMock-Up
Design zu dem Feature
Umsetzung
Test
UI Spec alsMock-Up
Design zu demFeature
Umsetzung
Test
Feature Review
14. Oktober 2014 Folie 23 von 40
© Zühlke 2014
Scrum Vorgehen
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Sprint2 weeks
24 hours
Product BacklogItem priority set by Product Owner
Sprint Backlog
Team determinesnecessary work
Potentially ShippableProduct Increment
Daily ScrumMeetingEmbrace and
ManageComplexity!
14. Oktober 2014 Folie 24 von 40
© Zühlke 2014
AAMI TIR45
• Titel: „Guidance on the use of AGILE practices in the development ofmedical products“
• AAMI: Association for the Advancement of Medical Instrumentation
• TIR 45: Technical Information Report Nr. 45
• Veröffentlicht im August 2012
• Im Q1/2013 von der FDA in die Liste der Recognized Standardsaufgenommen
• Erhältlich über www.aami.org für $ 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
© Zühlke 2014
Design Input / Design Output
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
DesignInput Activities(Definitions)
DesignOutput 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
© Zühlke 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 InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
SynchronizeDesign Inputs
&Design Outputs
(Increments)
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
Design InputActivities
Design OutputActivities
Story
SynchronizeDesign Inputs
&Design Outputs
(Increments)
SynchronizeDesign Inputs
&Design Outputs
(Increments)
SynchronizeDesign Inputs
&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
© Zühlke 2014
Verification
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Begleitende Verifikation Final verification
Führe eine finale Verifikation gegen die Design Inputs durch.Die Ergebnisse der begleitenden Verifikation können dabei berücksichtigt werden.
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
SynchronizeDesign Inputs
&Design Outputs
(Increments)
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
SynchronizeDesign Inputs
&Design Outputs
(Increments)
SynchronizeDesign Inputs
&Design Outputs
(Release)
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
ActivitiesDesign Input
Activities
ActivitiesDesign Output
Activities
Story
SynchronizeDesign Inputs
&Design Outputs
(Increments)
Figure 11-Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries
14. Oktober 2014 Folie 28 von 40
© Zühlke 2014
Häufige Releases
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 29 von 40
© Zühlke 2014
Umgang mit Änderungen, Entwicklungstempo
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
2-3 neue Versionen derApp pro Jahr
Neue Geräte(Consumer)
Erwartungender Benutzer
Update OS
Neue Features
Bugfixes
Entwicklungs-vorgehen
14. Oktober 2014 Folie 30 von 40
APP
© Zühlke 2014
Konsequenzen von 2-3 Versionen pro Jahr
• Einsatz von agile Methoden
• Einsatz von Continuous Integration
• Einsatz von Testautomatisierung
• Einsatz eines ALM Tools
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 31 von 40
© Zühlke 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Continuous Integration
Ziele:
• Referenz-Build nach jedem Check-In-Vorgang
• Ausführung der automatisierten Tests
• Kontinuierliche Analyse und Auswertungen, Statische CodeAnalyse (z.B. Compiler Warnings, MISRA)– Test-Statistiken, -Abdeckung
Voraussetzungen:
• Zentrale Infrastruktur– Versionsmanagementsystem, Build Infrastruktur, Test Infrastruktur
• Entwicklungskultur
14. Oktober 2014 Folie 32 von 40
© Zühlke 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Continuous Integration am Beispiel
14. Oktober 2014 Folie 33 von 40
Referenz-System(Server)Vermeidung des„Bei-mir-geht‘s“-SyndromsAutomatischerHinweis an dasEntwicklungsteam beigebrochenemBuildSchnellesFeedback für dieEntwickler
AutomatischerHinweisandasE
© Zühlke 2014
Testautomatisierung - Cucumber
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 34 von 40
© Zühlke 2014
ALM Tools
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Application Lifecycle Management Tool - Eins für alles?
TraceabilityTraceability
Req.-Ing. Entwickler Tester QMPL
PlanungPlanung
ReportsReports
?
?
? ?
?
DokumenteDokumente
?
Reqs
Tasks
CRs
RisksTests
Bugs
Folie 35 von 40
© Zühlke 2014
ALM Tools
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
Architektur
TraceabilityTraceability
Req.-Ing. Entwickler Tester QMPL
PlanungPlanung
ReportsReports
?
?
? ?
?
DokumenteDokumente
?Reqs
Tasks
CRs
RisksTests
Bugs
Folie 36 von 40
© Zühlke 2014
Fazit
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 37 von 40
© Zühlke 2014
Externes Review der Entwicklung
„Ich habe bei der Firma Zühlke ein Projektreview während derEntwicklung einer Medical App der Sicherheitsklasse C nach EN 62304durchgeführt. Die Planung der Entwicklungsaktivitäten in der vorgelegtenDokumentation war bereits weit fortgeschritten und dieProzessergebnisse waren teilweise schon sichtbar.
Zusammenfassend kann auf Grund des Reviews in Bezug auf dasEntwicklungsstadium des geprüften Produktes und die geprüftenAnforderungen der EN 62304 eine sehr hohe Prozessreife derEntwicklungsaktivitäten bestätigt werden.“
(Sonja Stephan, BSI Group Deutschland)
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka
© The British Standards Institution 2013
14. Oktober 2014 Folie 38 von 40
© Zühlke 2014
Zusammenfassung
• Medical Apps sind nicht viel anders als z.B. PC basierte medizinischeSoftware
• Mit den gezeigten Herausforderungen und Lösungen hatten wir keinProblem eine Medical App nach den Anforderungen von Klasse C zuentwickeln
• Verteilung der Aufwände war in etwa– 1/3 Implementierung– 1/3 Testing– 1/3 Dokumentation
Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka 14. Oktober 2014 Folie 39 von 40
© Zühlke 2014
14. Oktober 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka Folie 40 von 40