Entwicklung zwei mobiler Applikationen (Klasse A & B) nach IEC 62304 – ein Erfahrungsbericht

Ein Schweizer Startup im Medtech Bereich benötigte Unterstützung für die Entwicklung zweier mobiler Applikationen zur Überwachung und Steuerung einer Kontrolleinheit, welche selbst wiederum ein mechanisches Implantat antreibt. Die eine Applikation hilft den Patienten bei der Überwachung der Kontrolleinheit und ihrer Therapie, die andere Applikation ermöglicht den Ärzten, mit zusätzlichen Funktionen den Therapieverlauf zu analysieren und die Konfiguration der Kontrolleinheit anzupassen. Während der Projektlaufzeit befand sich die Kontrolleinheit noch in der Entwicklung und stand nicht zur Verfügung. Ebenso war ein übergeordnetes Cloud System des Kunden, welches für die Speicherung und die Weiterleitung von Informationen zwischen den einzelnen Applikationen zuständig sein sollte, erst für eine spätere Phase des Projekts angedacht. Dies hatte zur Folge, dass die zwei Applikationen losgelöst von der Kontrolleinheit und dem Cloud System entwickelt werden mussten. Die Architektur sollte aber bereits in der jetzigen Phase so ausgelegt werden, dass das System später möglichst kosteneffizient auf die noch fehlenden Komponenten erweitert werden kann.

Die Herausforderungen, die sich uns stellten, waren:

• Schnelles und effizientes Umsetzen des Auftrags, da durch Förderrichtlinien ein sehr kurzer Zeithorizont gesetzt wurde, der sich nicht verschieben liess.
• Über wenige Iterationen zusammen mit dem Kunden zwei mobile Applikationen mit anwenderfreundlichem UI Design zu erstellen, die in einer anschliessenden Usability Study getestet werden sollten, ohne dass zu Beginn schon ein abschliessendes Requirements Dokument vorlag.
• Die Kontrolleinheit musste simuliert werden, damit die Applikation in der Usability Study in unterschiedlichen Szenarien möglichst realistisch untersucht werden konnte.

Projektsetup & UI Design Phase

Aufgrund der limitierten Zeit und des iterativen Vorgehens entschieden wir uns für einen agilen Prozess in Anlehnung an Scrum mit zweiwöchentlichen Sprints.

Zu Beginn des Projekts wurde zusammen mit dem Kunden die Style Guides für das UI erarbeitet. Zeitgleich wurde mit der Erstellung des Projektplans und dem ersten Entwurf der Architektur begonnen. Da zu Zeiten von Corona und Home-Office-Pflicht gemeinsame Workshops nicht einfach durchzuführen waren, musste alles über Video-Meetings und Mailaustausch geschehen. Da das Projekt einen sehr kurzen Zeithorizont hatte, war es essenziell, möglichst rasch und früh ein gemeinsames Verständnis über die entstehende Applikation und deren User Flows zu erhalten, um zu verhindern, dass sich das Design des UI mehrere Iterationen hinweg schleppen würde.

Aufbauend auf diesen Style Guides wurden erste Wireframes skizziert, damit der Kunde einen Eindruck seiner Applikation erhielt. So konnte das «Look-and-feel» und die Wünsche an die Applikation besser besprochen werden.

Es war absehbar, dass die beiden Apps (Doktor + Patient) in unterschiedlichen Sicherheitsklassen (IEC 62304) zu klassifizieren waren. Die zusätzlichen Funktionen der Ärzte-Applikation, mit welcher die Kontrolleinheit des Implantats konfiguriert wird, wurde als Klasse B eingeordnet, während die Patienten-App nur der Klasse A unterliegt. Die Herausforderung der Software-Architektur lag somit darin, beide Applikationen sauber zu trennen und gleichzeitig Code-Ineffizienzen zu vermeiden. Die Architektur wurde auf zwei getrennte Codebasen aufgeteilt; gemeinsam genutzte Code-Bestandteile wurde über die sog. Assembly verlinkt, so dass keine Doppelarbeiten entstanden.

Dank der engen Zusammenarbeit mit unserem Kunden konnte rasch ein UI-Design mit benutzerzentrierten User Flows für die mobilen Applikationen erarbeitet werden.

Simulation der fehlenden Hardware

Wie erwähnt war zu dem Zeitpunkt die Kontrolleinheit, die es zu steuern galt, noch nicht verfügbar. Die fehlenden Hard- und Softwareelemente mussten daher in geeigneter Weise simuliert werden, um die Applikationen und ihre Prozesse in der Studie beurteilen zu können. Zusammen mit dem Kunden entschieden wir uns für eine .NET Core Web API, die die Kontrolleinheit simuliert und über welche die mobile Applikation von aussen stimuliert, respektive überwacht werden konnte.

Teile der Applikation, die später mit der Cloud Umgebung kommunizieren werden, kommen somit dem finalen Endprodukt schon sehr nahe. Die REST Schnittstelle wurde dabei so ausgelegt, dass diese in der finalen Applikation übernommen und erweitert werden kann. Für die fehlende Kontrolleinheit, welche später über Bluetooth Low Energy mit der Applikation kommunizieren würde, erstellten wir ebenfalls eine «Simulation Web API» in der Cloud. Konkret gestalteten wir dies folgendermassen:

• Anstatt über ein BLE Interface zu kommunizieren, wurde der ganze Datenaustausch auf dem Kommunikations-Layer mit http-request an die REST Schnittstelle der Web API umgeleitet.
• Übergeordnete Schichten bleiben von dieser Anpassung unberührt und müssen in der finalen Applikation nicht zwingend geändert werden, was eine effiziente Weiterverwendung des Codes in späteren Phasen

Um es dem Kunden zu ermöglichen, verschiedene Szenarien in der Usability Study flexibel durchzuführen, wurde eine API-Steuerung via Swagger Interface bereitgestellt. Nach kurzer Schulung war der Kunde in der Lage – auch ohne vertiefte Software Skills – selbständig unterschiedlichste Szenarien durchzuspielen.

Lessons Learned

Durch die engen zeitlichen Rahmenbedingungen des Projekts und die fehlende Ausgestaltung der User Requirements, musste ein sehr agiler und pragmatischer Ansatz gewählt werden.

Obschon wir den Fokus auf ein gutes Verständnis des User Flow und UI Design am Anfang legten, bemerkten wir nachfolgend dennoch Unklarheiten, die zu Änderungen in der Softwarearchitektur führten, so dass wir von einer gemeinsamen Repository auf getrennte Codebasen umstellten. Auch Abstimmungen und Anpassungen rund ums User Interface dauerten dadurch z.T. länger als ursprünglich vorgesehen.

Beim nächsten Mal empfehlen wir, mehr Zeit für die Definition des User Flows zu investieren, vor allem dann, wenn Kundenanforderungen zu vage definiert sind.

Schlussendlich lief das Projekt aber auch aus Kundensicht effizient und mit sehr guten Ergebnissen:

• Dank des agilen Vorgehens und des regelmässigen Kundenfeedbacks konnte effizient entwickelt werden und es herrschte ein partnerschaftliches Verhältnis, in welchem Informationen zeitnah ausgetauscht wurden.
• Die Simulation der zum Projektablauf noch nicht vorhandenen Hardware mittels einer «Simulations» Web API in der Cloud bot dem Kunden optimale Flexibilität und war ein voller Erfolg.
• Darüber hinaus ist es möglich, die «Simulations-API» für die nächsten Phasen des Projekts weiterzuentwickeln – ohne grosse Mehraufwände durch den Zwischenschritt der Erstellung der «Usability Study» App.

Nach neun Wochen intensiver Entwicklungszeit konnten wir dem Kunden zwei nach IEC 62304 entwickelte Mobile Applikationen übergeben, welche er abschliessend mit einer Usability Study erfolgreich testen konnte und die sich ohne grosse Overheads unmittelbar weiterentwickeln lassen.

______________________________________________________________________________

Autoren:

Daniel Süpke, Business Unit Leiter Software & Quality Engineering, Telefon: +41 41 799 30 10,

Philippe Suter, Senior Software Engineer, Telefon: +41 41 799 30 10,

gemeinsames entwickeln! Wir setzen Ihre Ideen in die Tat um und begleiten Ihre Vorhaben bis zur Marktreife. Nehmen Sie jetzt Kontakt mit unseren Experten auf.