Startseite > Medizintechnik > Systeme & Anwendungen > Medizin wird agil

Systementwicklung

Medizin wird agil

18. Februar 2014, 15:31 Uhr | Marcel Consée

Für Anbieter medizinischer Systeme ist Scrum ein ungewohnter Entwicklungsansatz

Schneller, günstiger und dabei ausnahmslos regelkonform – so lässt sich die Herausforderung an die Medizintechnik zusammenfassen. Wie können Unternehmen in der Medizintechnik unter diesen Bedingungen ihre innovativen Produkte dennoch schneller auf den Markt bringen? Wie kann die Produktentwicklung anwenderorientiert und dennoch kosteneffizient gestaltet werden, um den Einsparungsdruck von außen abzufedern?

▶ Diesen Artikel anhören

Vor rund 20 Jahren stand die Softwareindustrie vor ähnlichen Problemen wie die Medizintechnik heute. Entwickelt wurde meistens nach der schwerfälligen, sequenziellen Wasserfallmethode. Als Prozessverbesserungen gedachte Vorgehensmodelle und Standards wie CMMI und ISO 9001 verlängerten die Entwicklungszyklen zusätzlich und machten sie immer kostspieliger. Trotzdem wurde oft weit an den tatsächlichen Bedürfnissen der Anwender vorbeientwickelt, noch dazu in nicht zwangsläufig besserer Qualität. Schließlich war es die Unzufriedenheit der Softwareentwickler mit dieser Situation, aus der Ende der 1990er-Jahre »agile« Softwareentwicklungsmethoden entstanden. Eigentlich war es aber die Wiederentdeckung einer Vorgehensweise, die seit den 1940er-Jahren vor allem für die Entwicklung hochkomplexer »Hardware« wie etwa Kampfjets, das Mercury-Programm der NASA und später auch des Space Shuttle eingesetzt wurde – also durchaus ein Modell für Industrien mit straffen Vorgaben und Reglementierungen.

Was damals als »Iterative and Incremental Development« (IID) begonnen hat, erlebt heute unter dem Namen »Scrum« ein Comeback. Festzuhalten ist also zunächst, dass Scrum nicht primär eine agile Softwareentwicklungsmethode ist, sondern ein Rahmen, der die Komplexität eines Produkts in überschaubare Zyklen zerlegt – ob es sich dabei um Hardware, Software oder die Kombination von beidem handelt, ist völlig unerheblich.

Agile Ansätze wie Scrum sind also besonders dort stark, wo es um echte Produktentwicklung geht – wo neue Lösungen für alte Probleme gefunden werden müssen. Scrum in der Medizintechnik einzusetzen, ist daher beinahe eine logische Schlussfolgerung, denn Neuentwicklungen stehen im Mittelpunkt. Besonders in frühen Phasen eines Produktentwicklungsprojekts gibt es viele Unbekannte. Die Informationslage über Machbarkeit und Risiken verändert sich von Tag zu Tag und erst im Entwicklungsprozess selbst erweisen sich Wege als weiterführend oder als Sackgassen. Scrum schafft mit seiner transparenten und hoch adaptiven Natur den kontinuierlichen Abgleich zwischen Soll und Ist, zwischen Plan und Lieferung. Was Unternehmen in der Medizintechnik
aber oft von Scrum abhält, sind zwei Fragen:

Ist Agilität ein unternehmerischer Laissez-faire-Stil, bei dem jeder einfach macht, was er will?
Ist agile Produktentwicklung mit den Regularien der Medizintechnik vereinbar?

Die bekannten Leitsätze des agilen Manifests lassen einigen Interpretationsspielraum, von daher sind solcherart Fragen verständlich. Tatsächlich erlaubt die Flexibilität des Ansatzes jedoch durchaus die in der Medizintechnik nötige restriktive Anwendung.

Medizintechnische Regularien

Bedeutet »Regulierung« per se, dass die Produktentwicklung unter agilen Vorzeichen nicht möglich oder vielleicht gar nicht erlaubt ist? Die Antwort ist ein eindeutiges Nein. Weder die FDA noch die europäischen Richtlinien und Normen für die Herstellung von Medizinprodukten schreiben vor, welche Entwicklungsmethoden eingesetzt werden müssen.

Die AAMI (Association for the Advancement of Medical Instrumentation) stellt in ihrem Technical Information Report TIR 45:2012 dezidiert fest, dass neben anderen Lebenszyklusmodellen auf jeden Fall auch agile Methoden dafür geeignet sind, medizintechnische Software zu entwickeln. Natürlich stellen die Regularien Ansprüche an die Qualitätssicherung während des gesamten Entwicklungsprozesses, denn es geht schlussendlich um das Wohl der Patienten. Es wird aber dem einzelnen Unternehmen überlassen, mit welchen Verfahren es die Ansprüche der Validierung erfüllt, je nachdem, womit die Produktentwicklung am besten bewältigt werden kann. Laut des AAMI TIR 45:2012 legt sich die FDA in dieser Hinsicht nicht fest. Einzige Voraussetzung ist, dass alle nötigen Qualitätssicherungsmaßnahmen erfüllt und eingehalten werden. In puncto Dokumentation geht es der FDA also in erster Linie um das Festhalten dessen, was man tut und wie man es tut. Sie schreibt aber nicht vor, was wie zu tun ist.

Die gleichen Freiheiten lässt auch die Prozess-Norm IEC 62304. Sie nennt unterschiedliche Lebenszyklusmodelle wie Wasserfall, inkrementell (für Produktweiterentwicklungen) und evolutionär (entspricht agilen Modellen) und weist auf ihre Vor- und Nachteile hin, schreibt aber kein Modell vor. Die wichtigste Feststellung lautet also: Aus Sicht der Regulatorien darf agil entwickelt werden. Wie kann das in der Praxis aussehen?

Auch in der Medizintechnik bedeutet Scrum als Management-Framework für die Produktentwicklung zunächst Zusammenarbeit in cross-funktionalen Teams. Diese Teams bekommen die vollständige Lösungsverantwortung. Voraussetzung dafür ist, dass sich diese Teams mit allen Constraints auskennen, in denen sich die Lösung bewegen muss – sie müssen also die fachlichen Anforderungen verstehen, die Technologie beherrschen und die Vorgaben des Qualitätsmanagements kennen. Dieses Team sollte möglichst gemeinsam in einem Raum sitzen und eine klare Vorgabe bekommen, was in einer Iteration zu erreichen ist. Ausgehend von einer Produktvision und klaren Rahmenbedingungen (zum Beispiel die Regularien der FDA, Technologie und Sicherheitsaspekte) erarbeitet das Entwicklungsteam gemeinsam mit dem Produktmanagement die ersten funktionalen Anforderungen an das Produkt, die in einem Product-Backlog gesammelt werden. Sind genügend funktionale Anforderungen gesammelt, startet die Arbeit am ersten Feature.

Während das Entwicklungsteam daran arbeitet, arbeitet ein weiterer Teil des Teams bereits an funktionalen Prototypen, die zeigen, wie die nächsten funktionalen Anforderungen in den weiteren Iterationen eingepasst werden könnten. Die Ergebnisse werden nach ein bis vier Wochen dem Kunden/Anwender präsentiert und die notwendigen Anpassungen vorgenommen. Die neu gewonnenen Erkenntnisse werden also wieder in die Entwicklung zurückgeführt.

Beispiel: Risikomanagement mit FMEA

Vor der Auslieferung medizintechnischer Produkte ist eine Reihe von Planungen und Analysen durchzuführen, die der Zuverlässigkeit und Sicherheit des Produktes dienen sollen. In diese Kategorie fällt die FMEA (Failure Mode and Effect Analysis), in der potenzielle Fehlfunktionen des Systems sowie Maßnahmen zur Risikoreduktion identifiziert und bewertet werden. Wer die gängigen Scrum-Handbücher durchliest, wird die klassischen Instrumente des Risikomanagements darin nicht finden. Trotzdem gibt es keinen Ansatz, mit dem das Aufspüren von Hindernissen und Risiken sowohl in der Entwicklung als auch in der Projektsteuerung so konsequent verfolgt werden kann wie mit Scrum.

Nehmen wir als Beispiel die »Definition of Done (DoD)«: Dieses Artefakt legt verbindlich die Qualitätsanforderungen und den Fertigstellungsgrad entwickelter Funktionen fest. Die Definition of Done ist ein K.-o.-Kriterium am Ende jedes Sprints: Nur die Storys, welche die Vorgaben erfüllen, können als fertig gekennzeichnet und abgenommen werden. Das Einhalten der DoD verhindert zum Beispiel den Aufbau von technischer Schuld: Wer erst zum Schluss die ersten Integrationstests durchführt, wird nach der Entwicklung noch jede Menge zu tun haben. Eine FMEA (Auswerteanalyse) lässt sich hervorragend in den Rahmen der Definition of Done integrieren. In einem aktuellen Projekt von Boris Gloger Consulting werden Geräte für die Laborautomatisierung entwickelt. Das Entwicklungsteam hat in seiner DoD festgelegt, dass jede konstruktive Änderung erst mit einer Dokumentation der potenziellen Risiken sowie der zu ergreifenden Gegenmaßnahmen abgeschlossen ist.

Da das Team in zweiwöchigen Iterationen arbeitet, in denen Konstruktionsänderungen in kleinen Schritten abgeschlossen werden, ist es für die Mitglieder dieses Scrum-Teams zur Routine geworden, jede signifikante Entwicklungsstufe mit einer Risikobewertung und -steuerung abzuschließen. In herkömmlichen Projekten wurde das Risikomanagement erst angegangen, als die Entwicklung bereits abgeschlossen war. Dadurch konnten Risiken nur noch marginal eingedämmt werden. Jetzt ist es möglich, die »Risikobrille« von Beginn des Projekts mitten in der Entwicklung zu tragen. Mit Abschluss der Entwicklung ist das Risikomanagement bereits erledigt: Das Scrum-Team hat sich schließlich die ganze Zeit damit befasst.

Und die Qualitätskontrolle? Wenn sich das Team selbst eine Definition of Done gibt und sich selbst kontrolliert: Wo ist in diesem Szenario Platz für die Qualitätsmanagement-Abteilungen? Ganz einfach: Ein/-e Mitarbeiter/-in der Qualitätssicherung wird in das Scrum-Team integriert. Er oder sie sorgt dafür, dass die gesetzlichen Anforderungen als Teil des Entwicklungsprozesses implementiert werden. Allerdings nicht mit dem erhobenen Zeigefinger links und der Checkliste rechts, sondern durch aktives Mitmachen, Anpacken und Vorzeigen, wie Risikomanagement funktioniert. Das ist eine Umstellung, aber mit der Zeit werden Kontrollinstanzen und ständiges Nacharbeiten überflüssig. Das Aufspüren der Risiken passiert in Echtzeit, von Sprint zu Sprint.

Drei gute Gründe für Scrum in der medizintechnischen Produktentwicklung

1. Ständige Überprüfung der Regelkonformität:

Scrum ist im Grunde ein Validierungsinstrument (Diagnosetool). Es fördert durch das Review nicht nur laufend Erkenntnisse über das Produkt selbst zutage, sondern stellt dabei gleichzeitig laufend die Frage, ob die Qualitätsvorschriften eingehalten wurden. Als Produkt- und Ergebnisverantwortlicher erkennen Sie sofort, ob Ihr Projektteam in die falsche Richtung gelaufen ist, und können gegensteuern. Sie erkennen umgehend, ob Anforderungen geklärt sind, ob das Entwicklungsteam diese Anforderungen umsetzt, ob die notwendige Dokumentation geschrieben wurde und ob das Gerät erfüllt, was es laut den Anforderungen tun soll. Scrum erzeugt für Sie die Sicherheit, ständig zu wissen, wo Sie stehen.

2. Schnelle Lieferung:

Nur mit agilen Entwicklungsmethoden sind die Forderungen nach schneller Lieferung bei gleichzeitiger Einhaltung von Normen und Standards heute erfüllbar. Das Projekt wird für alle Beteiligten, das Entwicklungsteam, aber auch für das Management vollkommen transparent in seinen Lieferungen. Änderungen können während der Laufzeit des Projektes leicht eingefügt werden.

3. Motivierte Mitarbeiter:

Cross-funktionale Teams – alle an der Produktentwicklung beteiligten Mitarbeiter arbeiten Hand in Hand. Elektronik und Elektrik, Mechanik und Konstruktion, Softwareentwicklung und Mediziner, sie alle sind in einem Team und wollen gemeinsam erfolgreich sein. Das gemeinsame Ziel eint das Team und fördert die Zusammenarbeit, Handovers werden reduziert und viel Zeit gespart.

NB: Bei diesem Text handelt es sich um eine Kurzfassung eines Artikels, der in der MEDIZIN+elektronik 02/2014 erscheinen wird. Er basiert auf einem Whitepaper von Boris Gloger Consulting.