Zertifizierung von Medizingeräten – Eine Hilfe auf dem Weg zur Konformität mit der IEC 62304 für Softwareentwickler

Zertifizierung von Medizingeräten – Eine Hilfe auf dem Weg zur Konformität mit der IEC 62304 für Softwareentwickler


Posted by yklopping on March 16, 2011

Medizingeräte werden immer komplizierter; jetzt sind softwaregesteuerte Anwendungen ein integraler Bestandteil von ihnen, deren Ausfall zu Todesfällen oder schweren Personenschäden führen könnte. Trotz dieser erhöhten Komplexität reflektieren die Normen für medizinische Software nur die Vorschriften für risikoarme Anwendungen.


Bemerkenswert ist, dass viele der Mängel der Medizingeräte sich von Produktaufrüstungen ableiten lassen. Eine Analyse von 3140 Rückrufaktionen von Medizingeräten, die zwischen 1992 und 1998 von der FDA vorgenommen wurden erwies, dass 242 von ihnen (7,7 %) auf Softwarefehler zurückzuführen sind. Von den Softwarerückrufen wurden 192 (bzw. 79 %) von Softwaredefekten ausgelöst, die sich nach einem Software-Upgrade einstellten.

Da es scheinbar unmöglich war Produkt-Upgrades zu bewerkstelligen, beschloss die FDA Strafmaßnahmen gegen Baxter Healthcare und ihre Infusionspumpen und forderte eine Rückrufaktion. Am 27. April 2010 hatte die FDA Benutzer vor fehlerhaften Komponenten in den von der Cardiac Science Corp. hergestellten Defibrillatoren gewarnt. Außerstande die Probleme mit Softwarekorrekturen zu lösen, wurde Cardiac Science gezwungen, 24.000 betroffene Defibrillatoren auszuwechseln. Als Resultat sank der Wert der Aktien von Cardiac Science rapide, und das Unternehmen zeigte einen Nettoverlust von $18,5 Millionen auf. Sie wurden schließlich von Opto Circuits aufgekauft. Diese Rückrufaktionen änderten die Einstellung vieler Anbieter medizinischer Gerätschaften. Eine große Zahl von Firmen haben nun ihre Methode, ihre Softwareprozesse zu verbessern, geändert, und gleichzeitig die IEC 62304 angenommen, eine Norm für die Entwicklung medizinischer Produkte, die kürzlich von der EU und den Vereinigten Staaten besonders befürwortet wurde. 

Die IEC 62304 führt eine Risiko-basierte Konformitätsstruktur ein (Sicherheitsklassen A bis C, wobei ein Ausfall von Klasse-C Software zum Tod oder schweren Verletzungen führen könnte), die sicherstellt, dass medizinische Anwendungen mit den Normen, die ihrer Risikovalidierung entsprechen, übereinstimmen. Diese Norm behandelt die Anforderungen für jedes Stadium des Development Lifecycle und definiert die Mindestaktivitäten und Aufgaben, die auszuführen sind, um sicher zu stellen, dass die Software nun so entwickelt ist, dass sie hoch zuverlässige und sichere Softwareprodukte erstellt. Die IEC 62304 konzentriert sich auf den Softwareentwicklungsprozess, indem sie die Mehrzahl der Softwareentwicklungs- und Verifizierungsaktivitäten definiert. Dieser Prozess schließt Aktivitäten wie Planung der Softwareentwicklung, Analyse der Anforderungen, Architektur, Softwaredesign, Implementierung und Verifizierung der Module, Software- integration und Integrationsprüfung, Systemprüfung und letztendlich Software-freigabe ein. Der IEC-6203-Software-Risikomanagementprozess soll zusätzliche Anforderungen für die Risikokontrolle für Software erstellen, einschließlich Software, die im Laufe der Risikoanalyse als potenziell gefährlich identifiziert oder Software, die für die Kontrolle der Risiken medizinischer Geräte benutzt wird.

Gemäß der Norm muss der Hersteller die Softwarefaktoren, die zu einer Gefährdungssituation beitragen könnten, sowie ihre potenziellen Ursachen identifizieren. Diese potenziellen Ursachen sind dann in der Risikomanagementdatei zu dokumentieren, die die Reihenfolge der identifizierten Ereignisse enthält, die eine Gefährdungssituation zur Folge haben könnten. Für jede mögliche dokumentierte Ursache muss eine Risikokontrollmaßnahme definiert und dokumentiert werden. Die IEC 62304 fordert, dass diese Risikokontrollmaßnahme dann implementiert, verifiziert und dokumentiert wird. Rückverfolgbarkeit muss zwischen der Gefährdungssituation, den Softwaremodulen, der Ursache, den Risikokontrollmaßnahmen und der Verifizierung der Risikokontrollmaßnahmen nachgewiesen werden. Auf diese Weise spielt das Risikomanagement eine wichtige Rolle im Softwarewartungsprozess.

Natürlich beginnt die IEC 62034 mit der Softwareentwicklungsplanung des medizinischen Geräts. Hier stehen die erforderlichen Aufgaben direkt im Bezug zu der Sicherheitsklassifizierung des in der Entwicklung stehenden Geräts. Geräte, bei deren Ausfall Tod oder schwere Verletzung möglich sind (Sicherheitsklasse C), werden strengeren Prüfungen unterzogen und müssen zusätzliche Maßnahmen im Vergleich mit denen, die für andere Sicherheitsklassen erforderlich sind, mit einschließen. Die Gerätesicherheitsklassifizierung spielt eine wichtige Rolle bei der Bestimmung der Aktivitäten, die in der Softwareentwicklung eingeschlossen sind. Ein Gerät der Klasse A erfordert nur ein Mindestmaß an Auflagen, um die Software-Entwurfsvorgaben zu erfüllen, während Geräte der Klasse C im Stande sein müssen, alle Aktivitäten ausführen zu können.

Alle Software für Medizingeräte/ -produkte müssen einem Anforderungsmanagement und einer Rückverfolgbarkeitsanalyse während des gesamten Software Development Lifecycle unterzogen werden. Eine eingeführte verifizierbare Anforderung ist notwendig, um zu definieren, was zu bauen ist, festzustellen, dass die Medizingerätesoftware ein akzeptables Verhalten aufweist und zu demonstrieren, dass die fertige Medizingerätesoftware einsatzbereit ist.

Die IEC 63204 verlangt, dass alle Softwareanforderungen auf diese Weise identifiziert werden, da dies die Nachverfolgbarkeit zwischen der Anforderung und dem Testen des Softwaresystems zu beweisen ermöglicht. Dies gestattet den Softwareentwicklern auch, die Risikokontrollmaßnahmen zu den Softwareanforderungen zurückzuverfolgen.

 

Warum ist die Rückverfolgbarkeit für Anforderungen so wichtig?

Anforderungsverfolgung wird allgemein als optimales Verfahren akzeptiert, um sicherzustellen, dass alle Anforderungen implementiert wurden und alle Entwicklungsprodukte sich auf eine oder mehr Anforderungen zurückverfolgen lassen. Die herkömmliche Methode der Softwareentwicklung demonstriert, wie jede Phase in die nächste übergeht, eventuell mit Feedback zu früheren Phasen und innerhalb eines Rahmens von Konfigurationsmanagement und Prozess. Verfolgbarkeit wird als ein Teil des Verhältnisses zwischen den Phasen vorausgesetzt, allerdings wird der Mechanismus, mit dem Ablaufverbindungen aufgezeichnet werden, selten dargestellt.

Aber während jede einzelne Phase aufgrund der aktuellen Werkzeugtechnologie wirksam abgewickelt werden kann, tragen diese Werkzeuge in Wirklichkeit selten automatisch zu einer Verfolgbarkeit zwischen den Entwicklungsschichten bei. Als Resultat werden die Verknüpfungen zwischen ihnen im Laufe der Projektdauer immer schlechter instand gehalten. Das Nettoergebnis fehlt oder es ist eine oberflächliche Prüfung gegen seine Leistungsbeschreibung und Implementierung und daraus zu folgernden Schwächen des resultierenden Systems. Um eine wahre automatisierte Verfolgbarkeit zu erhalten, ist eine Anforderungsverfolgungsmatrix (requirements traceability matrix (RTM)) erforderlich, da die RTM das Zentrum eines jeden Projekts ist und ein Schlüsselarbeitsergebnis innerhalb vieler Entwicklungsnormen.

Entwickler können Anforderungen nachprüfen (und Testfälle, falls vorhanden, anwenden), während sie die Software entwickeln. Prüfer können eine Starthilfe beim Testen von Aktivitäten erhalten, indem sie Projektanforderungen direkt von ihrer Testmanagementumgebung aus ansehen. Sachbearbeiter können Anforderungen bei der Erstellung der Projektgrundlagen einschließen. Geschäftsführer können Ansichten des Projektstatus aus der Vogelperspektive erhalten, um so Informationen zum Ablauf auf einen Blick zu gewinnen.

Der Unterabschnitt 5.1.1 in Abschnitt C der IEC 62304 fordert speziell Verfolgbarkeit zwischen den Systemanforderungen, Softwareanforderungen, Softwaresystemtest und den in der Software implementierten Risikokontrollmaßnahmen. Die RTM spielt hier eine wichtige Rolle, weil sie die verschiedenen Schichten des Software Development Lifeycle miteinander verknüpft. Die RTM bietet Rückverfolgbarkeit zwischen Anforderungen auf hoher und niedriger Stufe zur Bauweise der Software. Sie hilft auch zu verifizieren, ob es Abweichungen von der Anforderung gibt, einschließlich solcher, die sich auf die Risikokontrolle gemäß Unterabschnitt 5.3.6 der IEC 62304 beziehen. Die RTM bietet noch weitere Rückverfolgbarkeit zwischen der Softwarearchitektur und dem genauen Softwareentwurf, wobei die Softwarearchitektur in Softwaremodule zerlegt wird. Außerdem hilft die RTM zu verifizieren, dass die Softwaremodule mit der Softwarearchitektur übereinstimmen. Die Codierung beginnt während der Implementierung der Komponenten gemäß der Designanforderung.

Die RTM verfolgt die mit den Softwaremodulen implementierten Komponenten zusammen mit den verschiedenen statischen Verifizierungsaktivitäten, die während der Codeverifizierung ausgeführt wurden und zeichnet zudem den Verifizierungsplan mit der dynamischen Analyse auf (entweder auf dem Host- oder Zielsystem), die während der Modulprüfung, Integration und Systemprüfung durchgeführt wurde. Mit Hilfe der RTM können Projektmanager die Auswirkung der Anforderungsänderung berechnen (Auswirkungsanalyse), und schätzen, wie sie das System beeinflussen wird.

Die Integration des Anforderungsmanagements mit anderen Werkzeugen spart Zeit und vermeidet Nacharbeit. Zur Starthilfe für Aktivitäten und um jedem Teammitglied ein Fenster zu den Endbenutzeranforderungen zu öffnen, sind Defektverfolgung, visuelle Entwicklung und Prüfwerkzeuge in die Anforderungen eingebunden.

 

Die IEC 62304 und Wartbarkeit

Die Verantwortung des Herstellers endet nicht mit der Freigabe des Softwareprodukts. Ein weiterer Schwerpunkt, der in der IEC 62304 angesprochen wird, ist die Produktwartung. Da viele Vorfälle in der Medizingeräteindustrie mit der Pflege oder der Wartung medizinischer Gerätesysteme in Bezug stehen, einschließlich unsachgemäßer Softwareaktualisierungen und Upgrades, gilt das Softwarewartungsverfahren als genauso wichtig, wie das Softwareentwicklungsverfahren. Die IEC- 62304-Norm möchte den hohen Anteil der Softwaredefekte an Medizingeräten, die sich nach der Produktfreigabe (d.h. während der Softwarewartung) einstellen, einschränken.

Ein gesundes Softwarewartungsverfahren ist einem soliden Softwareentwicklungsprozess sehr ähnlich, doch schließt es außerdem eine Problem- und Änderungsanalyse und Änderungsimplementierungsaktivitäten mit ein. Das Wartungsverfahren erfordert, dass der Hersteller Kommentare zum freigegebenen Produkt von innerhalb der Organisation und vom Benutzer überwacht. Dieses Feedback ist zu dokumentieren und zu analysieren, um festzustellen, ob ein Problem vorhanden ist. Wird ein Problem erkannt, muss ein Problembericht erstellt werden.

Gemäß den IEC-62304-Risikomanagementrichtlinien werden Problemberichte bewertet, um festzustellen, wie die Angelegenheit die Sicherheit des freigegebenen Produkts beeinträchtigt und um zu entscheiden, ob ein Upgrade oder eine Korrektur erforderlich ist. Der Hersteller muss weiterhin verifizieren, dass das Upgrade bzw. die Korrektur keine Gefahr verursacht oder ein Risiko in der Software darstellt, das zuvor nicht vorhanden war.

Eine gute Anforderungsmatrix mit automatisierter Rückverfolgbarkeit ermöglicht dem Hersteller, den vorhandenen Softwareentwicklungsprozess zum Implementieren von Änderungen anzuwenden. Eine gründliche Regressionsanalyse stellt sicher, dass Änderungen keine neuen Gefahren mit sich bringen, um die im vorhandenen Gerät eingebauten Risikokontrollmaßnamen negativ zu beeinflussen.

Als Bestandteil des Medizingerätelieferumfangs muss der Softwarewartungsprozess sicherstellen, dass sicherheitsbezogene Problemberichte an die entsprechenden Behörden und betroffenen Benutzer vermittelt werden. Die Softwareprodukte müssen nach jeder Änderung, die die Lösung des Problems und das Vermeiden von weiteren Problemen gewährleisten, gemäß offizieller Vorschriften neu validiert und wieder freigegeben werden.

Im Einklang mit IEC 62304 ist das Risikomanagement ein in den gesamten Software Development Lifecycle für Medizinprodukte eingebundener Faktor. Da die vorherrschenden Probleme mit Software-Updates direkt zu den Sicherheitsrisiken beitragen, verweisen die meisten beteiligten Verfahren und Aktivitäten auf Risikomanagement, gleich von der Softwareentwicklungsplanung an, über Anforderungsmanagement, Architekturentwurf, Codierung und Verifizierung bis hin zur Wartung. Dieses Regelwerk erfordert die Anwendung des Risikomanagementverfahrens im Einklang mit ISO 14971. Gemäß der ISO-14971-Definition, befasst sich das Risikomanagement speziell mit einem Framework für das effektive Management von Risiken, die mit der Anwendung von Medizingeräten/-produkten verbunden sind.

Fazit:

Die Einführung der IEC 62304 bindet Firmen, die mit Systemen und Softwareentwicklung für die medizinische Industrie zu tun haben, in das gleiche Verfahren ein, wie ihre Kollegen in Industrien wie Luftfahrt und Bahn. Alle müssen nun die gleichen Bemühungen anstellen, um eine anspruchsvolle Norm zu erfüllen. Die Notwendigkeit für eine solche Konformität hat eine Geschäftsentwicklung erforderlich gemacht, in deren Rahmen Verfahren und Projektpläne dokumentiert, Anforderungen erfasst, Implementationen und Verifikationen in Bezug auf die Anforderungen ausgeführt und alle Produktartefakte vollständig im Rahmen eines Konfigurationsmanagementsystems kontrolliert werden.

Die Anwendung der IEC 62304 als ein Verfahren für die Medizinproduktsoftwareentwicklung erfordert die Konformität mit den von der Norm definierten Prozessen, Aktivitäten und Aufgaben. Die vom Hersteller zugeordnete Produktsicherheitsklassifizierung spielt eine führende Rolle in der Festlegung des Aufwands, der für die Entwicklung der Software erforderlich ist. Grundsätzlich fordert die IEC 62304, dass Anforderungsrückverfolgung in allen Stadien des Softwareentwicklungsprozesses beachtet wird, so wie auch Nachweisbarkeit der Risikokontrollmaßnahmen.

Geprüfte, gut integrierte Werkzeuge gewährleisten, dass Entwickler den Prozess leichter und effizienter automatisieren können. Während dies Kosten im Voraus und mögliche Änderungen aktueller Methoden mit sich zieht, produziert die Konformität mit der IEC-162304-Norm eine bessere Qualität. Ein sicheres Produkt macht kostspielige Rückrufe unnötig und stellt sicher, dass das gleiche Entwicklungsverfahren die Wartungs- und Upgrade-Prozesse unterstützt. Der ROI des Herstellers steigt rapide, während gleichzeitig die Glaubwürdigkeit und der Ruf des Hauses verbessert werden.

 

Anil Kumar ist ein technischer Berater bei der LDRA in Indien. Er spezialisiert sich auf die Entwicklung, Integration und Zertifizierung von betriebsnotwendigen und sicherheitskritischen Systemen. Mit einem soliden Fachwissen und langjähriger Erfahrung in Programmierwerkzeugen und Echtzeitbetriebssystemen berät Kumar Organisationen bei der Wahl, Integration und Unterstützung ihrer eingebetteten Systeme mit Echtzeitanforderungen, von der Entwicklung bis hin zur Zertifizierung.



Find more content on:
Your rating: None Average: 3 (1 vote)


Login or register to post comments