Der Lebenszyklus medizinischer Software

Im Beitrag"Medizintechnik - im Dickicht der Normen" erwähnte ich, dass sich die regulatorischen Anforderungen der Medizintechnik erst seit einem knappen Jahrzehnt eigens mit Softwareentwicklung beschäftigen.Das hat einen einfachen Grund: Die Software spielte bei der Entwicklung medizintechnischer Produkte lange Zeit eine untergeordnete Rolle. Software war "das Programm", mit dem die Geräte bespielt werden mussten, "Hardware was king" (http://rtcmagazine.com/articles/print_article/102203). Heute kann man sich dieses Weltbild nicht mehr leisten. Je mehr Software in einem Produkt steckt, desto größer deren Bedeutung - und Komplexität. Es stellt sich die Frage, wie diese überhaupt in den Griff zu bekommen ist. Wie ist zu gewährleisten, dass die Software das (und zwar nur das!) tut, was sie tun soll? In einer Spiele-App kann noch verziehen werden, wenn die Applikation unvorhergesehenes Verhalten zeigt. Schlimmstenfalls ist dann ein Neustart erforderlich. In der Medizintechnik kann das gleiche Verhalten Leben kosten.Vor diesem Hintergrund wurde 2007 die EN IEC 62304 verabschiedet. Hierbei handelt es sich um eine mit den entsprechenden Richtlinien harmonisierte Norm, die sich mit dem so genannten "Lebenszyklus" (lifecycle) medizinischer Software beschäftigt. Mit "Lebenszyklus" ist der Lebenslauf der Software von der Planung bis zur Wartung gemeint. Die IEC 62304 nennt in diesem Zusammenhang fünf Prozessgebiete, die spezifisch für Software zutreffen:

• Entwicklung
• Wartung
• Risikomanagement
• Konfigurationsmanagement
• Problemlösung

Für jeden dieser Bereiche macht die EN 62304 Vorschläge zur Umsetzung. Die EN 62304 legt sich jedoch auf kein Entwicklungsmodell fest. Vielmehr erwähnt sie Wasserfall, iterativ-inkrementelle, und evolutionäre Vorgehensweisen als Beispiele, mit denen gearbeitet werden kann. Schauen wir uns die Umsetzungsvorschläge dieser Norm genauer an:

• Anforderungen an die Software: Diese sollten vollständig sein und alle Maßnahmen zur Risikobeherrschung enthalten. Sie dürfen sich nicht widersprechen, sollten verständlich und so formuliert sein, dass ihre Erfüllung überprüft werden kann. Ebenfalls müssen sich Testfälle, Änderungen im Code und Änderungen im Design auf Anforderungen zurückverfolgen lassen (traceability).
• Implementierung: Hier fordert die EN 62304, dass alle zuvor spezifizierten Software-Module oder -Einheiten implementiert werden. Dazu gehört die Festlegung von Akzeptanzkriterien und -tests, die die Umsetzung der Anforderungen durch den Code formulieren bzw. verifizieren.
• Tests: Hiermit sind System-, Integrations- und Regressionstests gemeint. Neben dem Testen der implementierten Funktionalitäten geht es auch um die Wirksamkeit von Maßnahmen zur Reduzierung von Risiken, um Performancetests sowie um die Funktion der Schnittstellen (insbesondere externe). Von der Planung über die Durchführung bis zur Ergebnissicherung fällt Dokumentationsaufwand an, der die Tests auch in Zukunft nachvollziehbar und reproduzierbar machen soll.
• Verifikation: Im Kontext der EN 62304 ist mit Verifikation der Nachweis gemeint, dass die Anforderungen im Sinne der Norm umgesetzt wurden.
• Validierung: Hier geht es um den Nachweis, dass das Produkt den intendierten Anwendungszweck erfüllt.

Die hier genannten Aktivitäten ziehen einen nicht geringen Dokumentationsaufwand nach sich. Dieser Aspekt führt häufig zur Meinung, dass agile Methoden für die Einhaltung solcher Normen nicht geeignet seien. Martin Bakal von IBM schlägt in dieselbe Kerbe, wenn er schreibt:"There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests. These requirements and others mean we need traceability and reporting we typically only see in heavy-weight processes like waterfall." (http://agile.dzone.com/articles/making-agile-development-work)Hier müssen wir unterscheiden zwischen den Möglichkeiten agiler Frameworks und ihrer aktuellen Nutzung. Natürlich werden Scrum und andere agile Frameworks u.a. in Projekten angewandt, die ein geringes Maß an Reporting und Traceability erfordern. Das heißt aber noch lange nicht, dass Scrum et al. zur Anwendung in hochregulierten Branchen ungeeignet sind.Eher im Gegenteil: Mit ihrem Anspruch, am Ende jedes Sprints potenziell auslieferbare Funktionalitäten fertigzustellen, sind agile Frameworks wie Scrum von Natur aus darauf ausgerichtet, Verifikation und Validation in die Sprints zu packen. Continuous Integration und Testautomatisierung führen dazu, dass Software permanent auf ihre Integrität getestet wird. Auch das Risikomanagement lässt sich mit Scrum hervorragend integrieren: In einem unserer derzeitigen Projekte prüft das Entwicklungsteam jede neue Story mit Hilfe eines Templates auf Produktrisiken. Diese Prüfung ist Teil der Definition of Done dieses Teams, so dass Stories nicht erledigt sind, solange die Risikoprüfung nicht stattgefunden hat. Auch gibt es mitterweile eine Reihe von Tools, die speziell dafür entwickelt wurden, den Lebenszyklus medizinischer Software für agile Produktentwicklung inklusive umfassender Traceability abzubilden.In der nächsten Folge: Qualitätsmanagement mit der Norm EN ISO 13485