TIR 45: 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 erstmalig 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.

1. Kernaussagen des TIR 45

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

a) 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 TIR 45 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.

b) Herausforderungen

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

c) Voraussetzungen

Der TIR 45 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.

d) Version 2023

2023 hat die AAMI den TIR 45 aktualisiert. Revolutionär sind die Änderungen nicht. Neben einer Reorganisation einiger Inhalte gibt es eine Aktualisierung der regulatorischen Referenzen und neue Kapitel zu agilen Praktiken. 

2. Anwendungsbereich des TIR 45

a) Berücksichtigte Regularien

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

• ISO 13485:2016
• IEC 62304:2006 + AMD1:2015
• ISO 14971:2019
• 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“

b) Zielgruppe

Der TIR 45 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

3. Umsetzung agile Entwicklung für Medizinprodukte gemäß TIR 45

a) Die Layer

Der TIR unterscheidet verschiedene Iterationsschleifen „Layer“.

Layer	Entwicklungsergebnis	Dauer
Projekt	Fertiges Produkt	Monate, Jahr oder mehr
Release	Fertiges Produkt oder Produkt(version) für interne Erprobung	Ein bis mehrere Monate
Inkrement	Satz an Funktionalität, nicht notwendigerweise komplettes Software-System	Ein bis vier Wochen
Story	Funktionalität oder Teilfunktionalität	Ein bis wenige Tage

b) 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.

Layer →   ↓ Aktivität	Projekt	Release	Inkrement	Story
5.1 Planung	X	X	X	X
5.2 Software-Anforderungen	X („High Level“)			X
5.3 Software-Architektur	X Grobarchitektur			X
5.4 Detailliertes Design				X
5.5 Implementierung				X
5.6 Integrationstest	bei Release	X	X	X
5.7 Systemtest	bei Release	X	X	X
5.8 Freigabe	X

4. 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 TIR 45 sieht die Story als Rahmen für je eines dieser Paare.

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

a) Design Inputs

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

b) Design Outputs

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

• Architektur und detailliertes Design
• Code
• Testspezifikationen und Testergebnisse

5. 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 TIR 45 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 TIR 45 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.

---

---

Änderungshistorie

• 2023-06-16: Hinweise auf Version 2023 ergänzt; redaktionelle Änderungen
• 2016-03-23: Erste Version publiziert