TIR45: Agile Software-Entwicklung für Medizinprodukte

Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation.

Der 2012 veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und konform mit den FDA-Forderungen, speziell denen in den Guidance Documents, entwickeln können. Auch die IEC 62304 hat der Technical Report im Fokus.

Lesen Sie hier eine kompakte Zusammenfassung.

• Kernaussagen des TIR45
• Anwendungsbereiche und Zielgruppe
• Umsetzung der agilen Software-Entwicklung
• Mapping auf Design Inputs, Design Outputs und Design Reviews
• Unsere Bewertung

2023 hat die AAMI den TIR 45 aktualisiert.

Kernaussagen des TIR45

Der TIR45 sagt, dass eine agile Software-Entwicklung konform mit den regulatorischen Anforderungen für Medizinprodukte möglich ist.

Vorteile der agilen Entwicklung

Als Vorteile der agilen Entwicklung sieht der Report:

• Hoher Fokus auf Sicherheit und Kundenzufriedenheit dadurch, dass man das Backlog neu priorisieren und Kundenrückmeldungen einbeziehen kann.
• Gute Abschätzung der Qualität durch kontinuierliches Testen.
• Kontinuierliche Verbesserung des Entwicklungsprozesses durch Retrospektiven.
• QM-Anforderungen werden erfüllt, weil es eine klare Definition von „done“ gibt.

Interessanterweise nennt der TIR45 als Vorteil nicht die Möglichkeit, sich an ständig ändernde Kundenanforderungen anpassen zu können. Vor dem Missbrauch der Agilität zum iterativen Herausfinden von Stakeholder-Anforderungen haben wir an dieser Stelle schon mehrfach gewarnt.

Herausforderungen

Als Herausforderungen sieht der Report die Tatsache, vielleicht sogar Versuchung, Änderungen an der Software in einem agilen Modell schnell bewerkstelligen zu können.

Voraussetzungen

Der TIR45 nennt Voraussetzungen, die erfüllt sein müssen, um den regulatorischen Anforderungen zu genügen:

• Die Entwicklung muss unter dem Dach eines QM-Systems erfolgen. Das agile Vorgehen darf nicht zu einem Verstoß gegen die dort genannten Anforderungen führen.
• Ein Entwicklungslebenszyklus muss definiert sein. An einer Stelle heißt es auch „Augment the discipline of necessary robust processes and tools“, an einer anderen „Set the correct expectations by defining the software devleopment lifecycle model“.
• Ein wirksames Änderungsmanagement muss etabliert sein, weil die Versuchung, Änderungen an der Software schnell zu bewerkstelligen (Nutzenversprechen der agilen Entwicklung), nicht in schlechter Produktqualität und erhöhten Risiken resultieren darf.
• Die Dokumentation muss sowohl den Anforderungen des Entwicklungsteams als auch den Regularien gerecht werden.

Anwendungsbereich des TIR45

Berücksichtigte Regularien

Die Autoren des TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) haben beim Schreiben folgende Regularien berücksichtigt:

• ISO 13485:2003
• IEC 62304:2006
• ISO 14971:2007
• FDA 21 CFR 820
• FDA „Guidance for the content of premarket submissions for software contained in medical devices“
• FDA Guidance „General principles of software validation“

Zielgruppe

Der TIR45 wendet sich an

• Medizinproduktehersteller
• Software-Entwicklungsteams
• Personen, die Anforderungen an Software spezifizieren
• Projekt- und Qualitätsmanager
• Mitarbeiter in Regulatory Affairs
• Externe und interne Auditoren
• Benannte Stellen und Behörden

Umsetzung agile Entwicklung für Medizinprodukte gemäß TIR45

Die Layer

Der TIR unterscheidet verschiedene Iterationsschleifen „Layer“.

Layer und Aktivitäten

Für jeden Layer sieht der TIR45 gewissen Aktivitäten vor, bei denen er sich auf die Nummerierung gemäß IEC 62304 bezieht.

Design Inputs, Design Outputs, Design Reviews

Die Regularien verlangen dokumentierte Design Inputs und Design Outputs. Der TIR45 gibt Hinweise dazu, wie Artefakte auf diese beiden Gruppen aufgeteilt werden können. Er macht auch klar, dass in einem agilen Umfeld nicht ein initialer großer Satz an Design Inputs besteht, sondern kontinuierlich Design Inputs und Design Outputs generiert werden, die sich sogar gegenseitig beeinflussen.

Design Inputs und Outputs entstehen paarweise in großer Anzahl. Der TIR45 sieht die Story als Rahmen für je eines dieser Paare.

Weiter empfiehlt der TIR45 das Ende von Inkrementen und Releases als Zeitpunkte für Design Reviews.

Design Inputs

Zu den Design Inputs zählt der TIR45 die User Stories mit den zugehörigen Akzeptanzkriterien, die auch nicht-funktionale Aspekte umfassen müssen.

Design Outputs

Folglich müssten alle anderen Artefakte zu den Design Outputs zählen wie

• Architektur und detailliertes Design
• Code
• Testspezifikationen und Testergebnisse

Bewertung durch das Johner Institut

Das Johner Institut ist ein Verfechter der agilen Entwicklung – auch im regulierten Medizinproduktekontext. Aus vielen Beratungsprojekten haben wir folgende Erkenntnisse gewonnen:

Vorteile

• Eine frühe und stabile Architektur („Upfront“) wie vom TIR45 vorgeschlagen, ist absolut zu empfehlen.
• Die regelmäßigen Retrospectives führen zu einem kontinuierlichen Lernen und manchmal auch zu einem Verbessern des dokumentierten Prozesses.
• Das Time-Boxing und der höhere Automatisierungsgrad von Tests erhöht die Software-Qualität.
• Die „Definition of Done“ führt zu einer besseren und konformeren Entwicklungsdokumentation, wenn sie die Dokumentationsaspekte umfasst.

Nachteile

• Zu großes Gap zwischen Projekt und User Story: Das Herunterbrechen sowohl der Architektur als auch von High-Level-Requirements erst auf Story-Ebene führt häufig zu Problemen. Beide sollten zumindest auch auf Release-Ebene weiter detailliert werden.
• Viele Hersteller tun sich schwer, der Aufforderung eines Auditors oder Inspektor Folge zu leisten, die konsolidierten Software-Anforderungen zu zeigen. Der TIR45 gibt hierzu den (bedingt hilfreichen) Tipp: „Define how documentation is written, controlled, and approved as a sum-of-its-parts“.
• Die Freigaben von Änderungen, die auf der Ebene von Inkrementen oder Stories notwendig werden und das Software-System in Gänze betreffen (im V-Modell würde man von Rücksprüngen sprechen), sind nicht klar geregelt oder werden nicht eingehalten.
• Die Entwicklungsplanung wird je nachlässiger aktualisiert (und manchmal sogar befolgt), desto weiter man sich von Projektebene Richtung Story-Ebene bewegt.
• Die (zu) späte Festlegung der detaillierten Software-Anforderungen führt insbesondere bei „Nicht-Standalone-Software“ dazu, dass diese Anforderungen vom Entwicklungsteam und nicht in ausreichendem Maß von Usability und Requirements Engineers bestimmt werden und in suboptimalen Benutzerschnittstellen münden. Unnötige Iterationen sind die Folge.