Autorin: Birgit Stehlik, infoteam Software GmbH Was bedeutet Risikoanalyse in diesem Bereich? Das Medizinproduktegesetz (MPG) definiert, wann Software als Medizinprodukt bezeichnet werden kann, z.B. wenn der Hersteller eine medizinische Zweckbestimmung vorgibt. Hier ist Software ein integraler Bestandteil und kontrolliert die Geräteparameter. Nach § 3 des MPG ist Software auch ein Medizinprodukt, wenn es \“Zubehör\“ darstellt. Das Risiko selbst definiert sich aus der Wahrscheinlichkeit des Eintritts eines Schadens und dessen Ausmaß. Die Bedeutung und Tragweite der Risikoanalyse und des Risikomanagements wird bei einem komplexen Entwicklungsprojekt, wie z.B. eines Röntgengeräts offensichtlich. Umsetzung der IEC 60601-1-4 bei einem Röntgensystem infoteam Software kümmerte sich um die Planung, Erstellung, Test und Inbetriebnahme der Steuer- und Bediensoftware eines Röntgensystems. Die Entwickler setzten die IEC 60601-1-4 dabei unter Anwendung des nach ISO 9001 zertifizierten Softwareentwicklungsmodells um: die Anforderungen an die Software wurden aus einer systemübergreifenden Risikoanalyse abgeleitet. Hier werden alle möglichen Gefährdungen identifiziert und anhand einer Bewertungsmatrix eingeschätzt. Dazu sind in dem Projekt die Neuartigkeit des Röntgensystems und seine technischen Möglichkeiten genau zu beleuchten. Das System umfasst einen deckenmontierten U-Arm (Röntgenröhre und Detektor), die Detektoreinheit und die Röntgenröhre sind immer aufeinander zentriert, was eine schnellere Positionierung ermöglicht und dadurch höheren Bedien- und Patientenkomfort bietet. Der All-in-One-U-Arm bewegt sich \“um den Patienten herum\“, was die Positionierung des Patienten erleichtert und den Workflow für den Bediener, den untersuchenden Arzt oder MTRA verbessert. Der Patient kann sowohl liegend, als auch beispielsweise im Rollstuhl sitzend oder stehend geröntgt werden und muss bei Untersuchungen von zwei Seiten nicht neu positioniert werden. Um dieses kaufentscheidende Produktkriterium, den verbesserten Komfort für Patienten und Bediener, auch funktionsfähig zu halten, erfordert es eine umfassende Beurteilung der möglichen Risiken für das Entwicklungsteam im Vorfeld. Gefahrenpotentiale Im Falle des Röntgengeräts könnte eine Gefährdung des Bedieners durch Energie oder beitragende Faktoren bestehen: z.B. könnte sich der MTRA bei der Durchführung der Autopositionierung den Finger quetschen. Gibt es in der Software eine ungeeignete Schnittstelle mit dem Anwender, könnte also eine X-Y-Z-Achsenbewegung nur in zwei Geschwindigkeitsstufen und einer Richtung möglich sein. So würde das Gerät mit großer Wahrscheinlichkeit nicht richtig zur Untersuchung ausgerichtet. Es könnten auch Gefährdungen infolge von Funktionsfehlern auftreten. Würde sich eine motorgesteuerte Bewegung des Geräts aufgrund eines Kontaktfehlers im Schalter nicht mehr stoppen lassen, ist der Patient gefährdet, weil das Gerät mit ihm zusammenstoßen kann und nicht um ihn herum manövriert. Für jede festgestellte Gefährdungsmöglichkeit wird im Folgenden das Risiko mit einer Wahrscheinlichkeitsmatrix eingeschätzt nach Stufe der Wahrscheinlichkeit des Eintritts und nach dem Schweregrad der möglichen Gefährdung. Am obigen Praxisbeispiel lässt sich das verdeutlichen: Würde also die Autopositionierung gestartet und der Patient oder der Anwender könnte möglichweise eingequetscht werden, so stellt dies erst einmal eine nicht vertretbare mögliche Gefährdung dar. Als Gegenmaßnahme darf das Aktivieren der Autopositionierung und der damit verbundenen Motorbewegungen nur durch das aktive Betätigen eines Signals durch den Bediener starten. Alle Motoren müssen sofort gestoppt werden, wenn das Signal unterbrochen wird. Damit kann der Benutzer selbst steuern und aktiv in das System eingreifen, um Gefährdungssituationen zu verhindern. Der Schweregrad der Gefährdung ist in diesem Fall als kritisch einzustufen, die Wahrscheinlichkeit, dass dieses Risiko überhaupt eintritt, ist dagegen sehr gering. Nach der Matrix zur Risikobewertung nach ISO 14971 stellt dies insgesamt ein Risiko der Stufe 1, also niedrig, dar. Risiken betreffen den ganzen Produktlebenszyklus Eine wesentliche Anforderung aus der IEC 62304 ist die Nachverfolgbarkeit zwischen System Anforderungen, Software Anforderungen, Software System Test und der in der Software implementierten risikoreduzierenden Maßnahmen. Dies gilt für alle Software- Medizinprodukte unabhängig von ihrer Klassifizierung. Daraus folgt, dass in die vollständige Abbildung eines Entwicklungsprozesses für medizinische Software auch der Risikomanagementprozess mit einfließen muss. Damit diese Prozesse keine Papiertiger bleiben und den Softwareentwickler in seiner täglichen Arbeit geeignet unterstützen, ist infoteam an dieser Stelle einen neuen Weg gegangen. Mit dem Microsoft Team Foundation System (TFS) wurde ein Entwicklungsprozess nach den Vorgaben der IEC 62304 und der ISO 14971 realisiert. Das Team Foundation System stellt eine Sammlung von Tools und Technologien dar, die es erlauben die einzelnen Tätigkeiten und Ergebnisse so wie sie im Verlauf eines Projektes geplant und erarbeitet werden zentral zu verfolgen und zu koordinieren. Für die Entwicklung medizinischer Software heißt das, das nicht nur ein gemeinsames Arbeitsverzeichnis für alle Entwickler existiert sondern vielmehr eine komplette Softwareproduktionsumgebung inklusive Quellverwaltung, Versionsverwaltung und Testautomatisierung sowie eine Kooperationsumgebung mit Dokumentenmanagement, Kommunikationsplattform und Prozessleitfaden integriert verfügbar ist. Abbildung 3 zeigt die Einstiegseite der infoteam Team Foundation Plattform für die Entwicklung medizinischer Software. In einer gemeinsamen Datenbasis werden dabei auch die nicht Software spezifischen Aufgaben (Tasks) verwaltet, die der Koordination an den Schnittstellen zwischen Software, Hardware und Mechanik dienen. Der Vorteil eines solchen Systems kommt vor allem in Projekten mit mehreren verteilt arbeitenden Projektpartnern und in großen Teams zum Tragen. Der Zugriff auf die Projektdatenbasis erfolgt über das Netzwerk und über Web-Clients und erlaubt so ein weltweit verteiltes Zusammenarbeiten. Normkonforme Entwicklung mit Nachverfolgbarkeit Wie kann nun mit diesem System normkonforme Entwicklung erfolgen? Dazu hat infoteam einen Softwareentwicklungsprozess mit den durch die Normen geforderten Abhängigkeiten und der Forderung an die Nachverfolgbarkeit in das Team Foundation System (TFS) abgebildet. Die Anforderungen aus Spezifikations- und Architekturdokumenten, die von den Entwicklern geschrieben werden, können mit Hilfe eines Tools mit den Anforderungselementen (WorkItems) im TFS synchronisiert und dort verwaltet werden. Ebenso verhält es sich mit erkannten Risiken aus der Risikoanalyse. Die Ergebnisse der Risikoanalyse werden in einem Dokument festgehalten, mit Referenzen versehen und in den TFS übertragen (siehe Abbildung 4). Falls ein Risiko durch eine in die Software zu integrierende Maßnahme reduziert werden kann, dann wird zu diesem Risiko ein Workitem Anforderung angelegt, das mit einem Test Workitem verknüpft ist. Damit wird sichergestellt, dass einerseits alle notwendigen Maßnahmen aus der Risikoanalyse in die Softwareentwicklung einfließen und andererseits diese implementierten Maßnahmen auch getestet werden. Aus einem Workitem Anforderung lassen sich im TFS entsprechend Arbeitspakete (Tasks) ableiten, die an die einzelnen Entwickler eines Projekts zugewiesen werden können. In dem Workitem Risiko werden neben einer Kurzbeschreibung des Risikos auch der Schweregrad des Risikos festgehalten. Abbildung 5 zeigt den Aufbau des Workitems Risiko. Jedem Workitem ist ein Workflow hinterlegt, der unterschiedliche Zustände und Zustandsübergänge definiert. Jedem Zustand sind Pflichtfelder zugeordnet, die vom Bearbeiter vor dem Wechsel in den nächsten Zustand ausgefüllt oder gesetzt werden müssen. Beim Anlegen eines Workitems muss beispielweise eine Beschreibung angegeben werden. Beim Übergang von \“Open\“ zu \“Active\“ muss der Schweregrad des Risikos eingetragen und an ein Projektmitglied zugewiesen werden. Den vollständigen Workflow für das Workitem Risk zeigt Abbildung 6. Dem Projektmanager und dem Risikomanager stehen Tools und Datenbankabfragen für die Auswertung und das Projektcontrolling zur Verfügung. Damit ist es beispielsweise möglich Informationen über die Anzahl von gemeldeten oder gelösten Fehlern zu erhalten, oder eine Prüfung der Nachverfolgbarkeit durchzuführen. Hierbei werden die aktuellen Bearbeitungszustände der Abhängigkeiten eines Risikos abgefragt und angezeigt: Zu welchen Risiken ist eine Anforderung vorhanden. Gibt es eine Referenz in einem Dokument z.B. in einer Risikoanalyse zu diesem Risiko. Welche Tests von Softwarekomponenten verliefen erfolgreich, welche schlugen fehl und zu welchen Softwarekomponenten wurden noch keine Tests definiert. Diese Abbildung der Nachverfolgbarkeit wird mit Hilfe eines von infoteam entwickelten Tools iTrace abgeglichen, bewertet und in Form einer Trace-Matrix, wie sie Abbildung 7 dargestellt ist, angezeigt. Zukunftsorientierte, skalierbare medizinische Software
infoteam Software AG
