Erfahrungen aus der Entwicklung einer Klasse C Medical App (Medical Apps 2014)

© 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

[email protected]

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


© 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.


Beispiele für Medical Apps


© 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.


Beispiele für Health Apps:


© 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


© Zühlke 2014

Vorstellung der App


© 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)


© Zühlke 2014

Entwicklung einer Medical App…und wie geht man damit um?


© Zühlke 2014

Deployment


© Zühlke 2014

Deployment von Apps für den Endbenutzer


Upload in denApp Store

Download ausdem App Store

Statistiken

Meldung überneue Versionen

Inverkehrbringer Endbenutzer / Anwender

App Store (z.B. Apple)


© 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


© Zühlke 2014

Deployment von Apps während der Entwicklungoder für einen eingeschränkten Benutzerkreis


Direkt über Kabel an den PC

spezifische Deploy App

Freischalten jedesMobiltelefons

Upload der App

Installation derDeploy App

Download derApp


© Zühlke 2014

Plattformvalidierung


© 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?


© Zühlke 2014

Validierungsansatz


Betriebsbewährt Risikobasiert

Als Componente in dieFMEA aufnehmen

Risikobeurteilungund -akzeptanz

RisikominderndeMaßnahmen


Risikobasiert

Als Componente in dieFMEA aufnehmen

Risikobeurteilungund -akzeptanz

© Zühlke 2014

Beispiel einer FMEA


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


© Zühlke 2014

Design und Usability


© 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


© Zühlke 2014

Struktur der Dokumentation der Anforderungen


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


© Zühlke 2014

Umsetzung eines Features


Use

Cas

es

UI Spezifikation alsMock-Up

Design zu dem Feature

Umsetzung

Test

UI Spec alsMock-Up

Design zu demFeature

Umsetzung

Test

Feature Review


© Zühlke 2014

Scrum Vorgehen


Sprint2 weeks

24 hours

Product BacklogItem priority set by Product Owner

Sprint Backlog

Team determinesnecessary work

Potentially ShippableProduct Increment

Daily ScrumMeetingEmbrace and

ManageComplexity!


© 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


http://www.aami.org/

© Zühlke 2014

Design Input / Design Output


DesignInput Activities(Definitions)

DesignOutput Activities

(Design)

Figure 5-DESIGN INPUT/OUTPUT relationship: Highest level of abstraction

Design Output:Activities






























Design Input:Activities






























Figure 6-DESIGN INPUT/OUTPUT relationship: WATERFALL development


© 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



Story



Story

SynchronizeDesign Inputs

&Design Outputs

(Increments)

Story



Story



Story



Story

Story



Story



Story



Story

Story



Story



Story



Story


&Design Outputs

(Increments)


&Design Outputs

(Increments)


&Design Outputs

(Release)

Figure 11-Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries


© Zühlke 2014

Verification


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


Activities


Activities

Story


Activities


Activities

Story


&Design Outputs

(Increments)

Story


Activities


Activities

Story


Activities


Activities

Story


Activities


Activities

Story

Story


Activities


Activities

Story


Activities


Activities

Story


Activities


Activities

Story


&Design Outputs

(Increments)


&Design Outputs

(Release)

Story


Activities


Activities

Story


Activities


Activities

Story


Activities


Activities

Story


&Design Outputs

(Increments)

Figure 11-Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries


© Zühlke 2014

Umgang mit Änderungen, Entwicklungstempo


2-3 neue Versionen derApp pro Jahr

Neue Geräte(Consumer)

Erwartungender Benutzer

Update OS

Neue Features

Bugfixes

Entwicklungs-vorgehen


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


© 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


© Zühlke 2014Erfahrungen aus der Entwicklung einer Klasse C Medical App | Matthias Wufka

Continuous Integration am Beispiel


Referenz-System(Server)Vermeidung des„Bei-mir-geht‘s“-SyndromsAutomatischerHinweis an dasEntwicklungsteam beigebrochenemBuildSchnellesFeedback für dieEntwickler

AutomatischerHinweisandasE

© 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

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)


© The British Standards Institution 2013


© 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 (Medical Apps 2014)

Software

Transcript of Erfahrungen aus der Entwicklung einer Klasse C Medical App (Medical Apps 2014)