Software unbekannter Herkunft nutzen Softwareentwicklung in der Medizintechnik: Das Haar in der »SOUP« finden

Medizingeräte werden immer komplexer. Daher nutzen Entwickler auch Software unbekannter Herkunft (Software Of Unknown Pedigree, kurz SOUP), um sich auf die Kernfunktionen ihres Geräts konzentrieren und die Entwicklungszeit verkürzen zu können. Allerdings hat SOUP ihre Nachteile, vor allem, weil sie von verschiedenen Anbietern erstellt wird, die nicht irgendein bestimmtes Softwareentwicklungsverfahren befolgen.

Neue, anspruchsvolle Medizingeräte helfen Ärzten mehr denn je, leichter und genauer Krankheiten zu diagnostizieren. Durch diese große Abhängigkeit von solchen Geräten erhöht sich jedoch auch die Besorgnis, wie sicher und genau die gestellten Diagnosen tatsächlich sind. Daher hat die FDA, die für den Schutz der öffentlichen Gesundheit in den USA zuständig ist, 3140 Rückrufe medizinischer Geräte in der Zeit von 1992 bis 1998 analysiert. Diese Untersuchung ergab, dass 242 dieser Rückrufe auf Softwarefehler zurückzuführen sind. Für über drei Viertel davon, genauer gesagt 192, waren Softwaredefekte verantwortlich, die nach einem Software-Upgrade auftraten.

Damit ist klar, dass viele der Fehler in Medizingeräten von Produktaktualisierungen stammen. Dieser Umstand bewog Gutachter und Genehmigungsbehörden für Medizingeräte dazu, sich nicht nur auf die Entwicklung von Software zu konzentrieren, sondern auch auf die nachfolgende Pflege und die Auswirkungen, die eine Softwareänderung auf das vorhandene System haben könnte. Deshalb ändern viele Firmen ihre Methoden zur Verbesserung ihrer Softwareverfahren und übernehmen zusätzlich die IEC 62304, eine Norm für das Design von Medizinprodukten, die kürzlich von der Europäischen Union und den Vereinigten Staaten gebilligt wurde.

Diese Norm führt eine auf Risiko basierte Konformitätsstruktur der Gefahrenklassen A bis C ein, gemäß der ein Fehler einer unter Gefahrenklasse C eingetragenen Software zum Tod oder schweren Verletzungen führen könnte. Dies soll sicherstellen, dass medizinische Anwendungen mit den Normen, die ihrer Risikobewertung entsprechen, übereinstimmen. Dieser Artikel befasst sich damit, wie Altsysteme (Legacy Products) dazu gebracht werden können, die IEC 62304 einzuhalten und wie Altsysteme zu aktualisieren sind, ohne dass sich Fehler einschleichen, welche die Sicherheit des Medizingeräts nachteilig beeinflussen.

Die IEC 62304 befasst sich mit dem Softwareentwicklungsprozess, indem sie die Mehrheit der Softwareentwicklungs- und Verifikationsaktivitäten definiert. Dieser Prozess schließt Aktivitäten wie Softwareentwicklungsplanung, Anforderungsanalyse, Architektur- und Softwaredesign, Implementation und Verifizierung der Einheiten (Unit Implementation and Verification), Softwareintegration und Integrationstests, Systemtests und schließlich Softwarefreigabe ein (siehe auch Kasten »Die IEC 62304 konzentriert sich auf fünf Prozesse«).

Diese Norm legt nicht nur Anforderungen für jede Phase des Entwicklungslebenszyklus‘ fest, sondern kümmert sich auch um den Wartungsprozess, die Kontrolle des Einflusses der Softwareänderung auf das bereits vorhandene System sowie das Risiko, das aufgrund der Implementation der Softwareänderung entsteht. Weiter behandelt diese Norm en détail die Auswirkung der SOUP-Elemente von der Planung bis hin zu Anforderungsanalyse, Architekturdesign, Wartung und Risikomanagementphasen.

Funktionstests reichen nicht aus

Altsysteme und Software unbekannter Herkunft (SOUP) werden bei der Entwicklung neuer Geräte immer öfter wiederverwendet, zumal Medizingeräte auch immer häufiger auf eingebetteter Universalhardware basieren. Der Einsatz von SOUP hat den Vorteil, dass der Hersteller sich auf die Anwendungssoftware konzentrieren kann, welche die gerätespezifischen Funktionen betreibt. SOUP wird oft für Universalanwendungen entwickelt, ihr Einsatz in Medizingeräten bringt jedoch neue Herausforderungen mit sich.

Die meisten dieser Softwaremodule werden von Dritten erstellt, die keinerlei Softwareverfahren oder -normen beachten, geschweige denn, dass sie den Programmiercode dokumentieren. Die europäische System- und Software-Initative »Performance of Errors through experience-driven Test« (PET) untersuchte dieses Phänomen und kam zu dem Schluss, dass der eingesetzte Code oft viele Fehler enthält. Die Befunde zeigten, dass die Anzahl Bugs, die neuere Testmethoden finden (z.B. statistische und dynamische Analysen), groß sei, selbst wenn dieser Code Funktionstests unterzogen und danach freigegeben wurde. Legacy-Software, die schon zuvor Funktionstests unterzogen wurde, muss dann weitere Tests absolvieren. Selbst wenn sie gut funktionierte, kann es sein, dass ein Teil des Codes nie ausgeführt worden ist, sogar wenn das Produkt im Einsatz (infield) ist.

Wird dieser alte Code für Neuentwicklungen oder spätere Bereinigungen hervorgekramt oder werden auf diesen alten Code Updates aufgespielt, kann es gut sein, dass bislang völlig unbekannte Datenkombinationen bislang nie ausgeführte Codepfade erreichen - unter Umständen mit ganz unerwarteten Folgen (Bild 1). Um dieser potenziellen Schwachstelle entgegenzuwirken, ist eine genaue strukturelle Abdeckungsanalyse durchzuführen. So ist gewährleistet, dass kein unausgeführter Code in der SOUP vorhanden ist.

Die IEC 62304 schreibt zum einen eine Funktionsabdeckung (functional coverage) vor, um sicherzustellen, dass die Software jede Designanforderung abdeckt. Zum anderen ist eine strukturelle Abdeckung (structural coverage) zu analysieren. Dazu werden alle Codeabschnitte ausgeführt, um festzustellen, ob sie korrekt funktionieren. Zusätzlich ist noch das Risiko, das durch Hinzufügen einer solchen Software verursacht werden könnte, detailliert zu analysieren.

Die IEC 62304 adressiert SOUP-Elemente während der Softwareplanung, dem Anforderungsmanagement, dem Architekturdesign, der Integrations- und Systemprüfung, dem Risikomanagement, der Wartung sowie dem Änderungsmanagement. Softwareplanung fordert einen detaillierten Plan im Hinblick auf die zu benutzenden SOUP-Elemente. Diese Details definieren, wie diese Elemente in das vorhandene System zu integrieren sind, wie das mit Software unbekannter Herkunft verbundene Risiko zu managen ist und wie Softwarekonfiguration und Änderungsmanagement das System beeinflussen.

Anforderungen verfolgen

Die Anforderungsverfolgungsmatrix (Requirement Traceability Matrix, RTM) - eine allgemein akzeptierte Methode, um Anforderungen zu verwalten und zu verfolgen - spielt eine führende Rolle im Management von Softwareanforderungen. Das gilt ebenso für die im System benutzten Elemente von Software unbekannter Herkunft. In der RTM gibt der Hersteller Folgendes an:

  • Funktions- und Leistungsanforderungen der für die geplante Anwendung erforderlichen SOUP-Elemente.
  • Herstellerspezifikationen für die erforderliche Systemhardware und -software, die für die Unterstützung des korrekten Betriebs des SOUP-Elements erforderlich ist.
  • Details, um zu verifizieren, dass die Architektur des Medizingeräts den korrekten Betrieb aller SOUP-Elemente unterstützt.

In den meisten Fällen werden SOUP-Elemente im Quellcode, aber ohne Designdokumente geliefert, sodass es schwierig ist, sie zu analysieren. Moderne Testwerkzeuge helfen, den Legacy-Code zu visualisieren; das kann auf Aussageblöcke, Verfahren (oder Klassen), Anwendungen und/oder auf das gesamte System angewendet werden. Statistische Aufrufdiagramme erstellen eine hierarchische Darstellung der Anwendung und Systemeinheiten, die statischen Flussgraphen zeigen den Kontrollfluss quer über die Programmblöcke auf. Entwickler können durch diese farbcodierten Diagramme SOUP-Elemente erheblich besser verstehen (Bild 2).

Solche Aufruf- und Kontrollflussdiagramme sind nur einer der Vorteile, die eine umfassenden Analyse aller Parameter und Datenobjekte mit sich bringt. Anforderungsmanagement und Rückverfolgbarkeit mithilfe der RTM gewährleisten, dass alle Anforderungen implementiert und alle Entwicklungsartefakte zu einer oder mehreren Anforderungen zurückverfolgt werden können. Gleichweise stellen sie sicher, dass die SOUP-Elemente auf Systemanforderungen basiert hinzugefügt und implementiert werden.

Da diese Elemente im Quellcode geliefert werden, obliegt es der Verantwortung des System-integrators, diesen Code zu verifizieren und sicherzustellen, dass die Konformität mit spezifischen Codiernormen gewahrt ist (Bild 3).

Bekanntermaßen werden SOUP-Elemente häufig unter Zeitdruck produziert. Das bedeutet, dass der Systemintegrator umso mehr und länger mit der Verifikation der Codierrichtlinien und Risikoanalyse für diesen Legacy-Code beschäftigt ist. Deshalb befassen sich Entwickler gewöhnlich mit einer Untermenge von Codiernormen und akzeptieren nur langsam zusätzliche Vorschriften. Erwähnenswert ist, dass Testwerkzeuge die Verstöße gegen Codierrichtlinien und unterschwellige Fehler (latent errors) im Altcode nur identifizieren können, nicht aber den Code selbstständig korrigieren.

Sie ermöglichen es Entwicklern lediglich, den Code entsprechend den Codiernormen so effizient wie möglich zu berichtigen. Nach der IEC 162304 muss der Hersteller die vom Lieferanten des SOUP-Elements veröffentlichte Liste von Unregelmäßigkeiten (anomalies) auswerten, um festzustellen, ob eine dieser zu einer Gefährdungssituation führen könnte. Die RTM hilft sicherzustellen, dass die dynamische Analyse - einschließlich System-, Integrations- und Unit-Test - vorgenommen wird, um die Funktions- und Strukturabdeckung des SOUP-Elements zu verifizieren. Dadurch entsteht eine Rückverfolgbarkeit zwischen den verschiedenen Tests und Analysen, die an SOUP-Elementen im Vergleich zu dem zuvor eingerichteten Testplan vorgenommen wurden.

Dieser Testplan enthält Testfälle, die auszuführen sind und ihre voraussichtlichen Ergebnisse basieren auf den System-anforderungen. Mithilfe der RTM können Projektmanager den Einfluss der eingesetzten SOUP-Elemente und ihre Auswirkung auf die Sicherheit des Systems beurteilen.

Wartung von SOUP-Elementen

Viele Störungen bei Medizingeräten haben mit dem Kundendienst oder der Wartung zu tun, einschließlich unsachgemäßer Software-Updates und -Upgrades. Daher ist der Wartungsprozess der Software als genauso wichtig anzusehen wie der Entwicklungsprozess.

Die IEC 162304 soll den hohen Anteil von Defekten in der Gerätesoftware nach der Produktfreigabe, also während der Softwarewartung, einschränken helfen. Beim Wartungsprozess muss der Hersteller das Feedback der freigegebenen Produkte sowohl vonseiten der eigenen Organisation als auch vom Benutzer überwachen. Dieses Feedback muss dokumentiert und analysiert werden, um festzustellen, ob ein Problem vorhanden ist. Wird ein Problem gefunden, ist ein Problembericht zu erstellen und zu analysieren, um festzustellen, ob SOUP-Elemente zum Problem beigetragen haben.

Liegt das Problem bei einem solchen Baustein, ist diese Angelegenheit dem entsprechenden Anbieter mitzuteilen, damit er das Problem mit Upgrades oder Korrekturen beheben kann. Die IEC 62304 erfordert, dass der Hersteller Verfahren einrichtet, um Upgrades, Fehlerbehebungsprogramme und Obsoleszenzen von SOUP-Elementen zu bewerten und zu implementieren. Jedes Upgrade oder jede Fehlerbehebung (bug fix, patch) ist zu analysieren und zu verifizieren, um festzustellen, ob dadurch zusätzliche potenzielle Ursachen eingeschleust wurden, die zu Gefährdungssituationen beitragen.

Wie immer ist es notwendig festzustellen, ob zusätzliche Maßnahmen erforderlich sind, um das Risiko zu kontrollieren. Während der Wartung muss der Hersteller die Änderungen bei den SOUP-Elementen analysieren, um festzustellen, ob die Änderung die vorhandenen Risikokontrollmaßnahmen beeinträchtigen könnten.

Der Hersteller muss ein Programm für die einmalige Identifizierung der Konfigurationselemente und ihre Version einrichten. Für jede benutzte SOUP-Konfiguration muss der Hersteller den Titel, den SOUP-Herstellernamen und die einmalige SOUP-Bezeichnung dokumentieren. Diese Festlegung identifiziert die Softwarekonfigurationselemente und die Versionen, die in der Medizingerätsoftware eingebunden sind.

Die IEC 62304 konzentriert sich auf fünf Prozesse

Die IEC 62304 erstellt einen Rahmen des Softwareentwickungszyklus´mit Aktivitäten und Aufgaben, die für das sichere Design und die Wartung von Software für Medizingeräte erforderlich sind. Diese Norm stellt grundsätzlich fünf Hauptprozesse heraus:

Der Entwicklungsprozess definiert die meisten Aktivitäten rund um die Softwareentwicklung und deren Verifizierung.

Der Wartungsprozess überwacht die Beobachtung der freigegebenen Produkte auf zukünftige Probleme, um solche zu korrigieren und zu untersuchen, ob die Korrekturen eine Gefährdung verursachen oder ein Risiko für das vorhandene System darstellen.

Der Risikomanagement identifiziert solche Softwareelemente, die zu Gefahrensituationen beitragen. Ihre Ursachen werden identifiziert, dokumentiert, entsprechende Risikokontrollmaßnahmen werden implementiert und verifiziert.

Der Softwarekonfigurationsmanagementprozess identifiziert und dokumentiert den Werdegang der Änderungen, die am Softwaresystem vorgenommen wurden.

Der Problemlösungsprozess anaylsiert und löst alle Probleme, ganz gleich welcher Art oder woher sie stammen, die wärhend der Entwicklung, Wartung oder anderen Prozessen erkannt wurden.