Category

Nachdem im Februar 2015 die neue IEC 62366-1 Norm zur Usability erschienen ist, ist Ende Juni das Admendement1 der IEC 62304 erschienen. Auf diese will ich hier eingehen.

Es gibt einige Klarstellungen sowie neue Definitionen und viele Ergänzungen. Hier eine Auswahl der wichtigsten Änderungen:

• Es müssen verschiedene Tätigkeiten neu auch für Software Klasse A gemacht werden
• Es gibt eine neues Vorgehen wie man Legacy Software compliant machen kann
• Ergänzungen zu Software Safety Klassifikation
• Neue oder neu definierte Begriffe
• Allgemein bekannte Software Fehler
• Validation

Zusammengefasst kann man sagen, dass das IEC 62304 Amendment1 2015 neue Aufgaben mit sich bringt aber auch neue Möglichkeiten mit den bekannten Herausforderungen umzugehen.

Tätigkeiten die neu auch für Software Klasse A gemacht werden müssen

• Software System Tests erstellen und durchführen um alle Software Anforderungen zu prüfen
• Anwenden des Problemlösungsprozess
• Wiederholungstests nach Änderungen an der Software
• Dokumentieren von bekannten Fehlern
• Archivieren von Software
• Sicherstellen der zuverlässigen Auslieferung von freigegebener Software

Legacy Software

Anstelle der Anwendung der bekannten Kapitel, Klausel 5 – 9 ( Software-Entwicklungs-Prozess, Software-Wartungs-Prozess, Software-Risikomanagement-Prozess, Software-Konfigurationsmanagement-Prozess, Problemlösungs-Prozess für Software), kann der Hersteller das folgende alternative Verfahren anwenden um Compliance der Legacy Software zu demonstrieren.

• Ausführen von Risiko Management Aktivitäten im Zusammenhang mit dem weitergehenden Gebrauch der Medical Device Software
• Bewerten von Feedback inklusive Marktinformationen
• Ausführen eine Gap Analyse der vorhandenen Artefakte gegenüber den geforderten Artefakten
• Erstellen und Ausführen eines Planes um die identifizierten Artefakte zu erstellen
• Wo vorhanden kann ein objektiver Beweis benutzt werden, um die erforderlichen Artefakte zu erstellen, ohne die nötigen Aktivitäten von Klausel 5.2 (Analyse der Software-Anforderungen), 5.3 (Design einer Software-Architektur), 5.7 (Prüfung des Software-Systems) und Klausel 7 (Software-Risikomanagement-Prozess) retrospektiv für die Legacy Software auszuführen
• Der Plan soll den Gebrauch des Problem Lösungs-Prozess zum Umgang mit gefundenen Probleme der LEGACY SOFTWARE aufzeigen und zwar nach Klausel 9
• Änderungen an der LEGACY SOFTWARE sollen nach Klausel 6 ausgeführt werden
• Die Version und eine Begründung zum weiteren Gebrauch der LEGACY SOFTWARE sollen dokumentiert werden

Ergänzungen zu Software Safety Klassifikation

Das Prinzip der Software Klassifikation ist im Grunde noch dasselbe. Es wurden aber folgende Änderungen vorgenommen:

Die Zuweisung der Software Safety Klasse geschieht aufgrund des Schadenrisikos resultierend von einer Gefährdungssituation zu welcher das Software System in einem Worst-Case Szenario beitragen kann.

Für ein Software System welches initial als Software Safety Klasse B oder C klassifiziert wurde, kann der Hersteller zusätzliche Risiko-Kontroll Massnahmen ausserhalb des Software Systems implementieren und danach eine neue Safety Klasse zuweisen.

Da Software alleine keine Schäden verursacht, kann Software mit dem Gesamtsystem zusammen als eine Kette von Ereignissen angesehen werden um den Weg von der Software bis zu einem möglichen Schaden zu beschreiben.

Für Software Fehler soll weiterhin eine Ausfallwahrscheinlichkeit von 1 angenommen werden. Allerdings kann in einer Kette von Ereignissen welche auf die Software folgt möglicherweise die Wahrscheinlichkeit geschätzt werden. Diese Wahrscheinlichkeit kann als Wahrscheinlichkeit der Gefährdungssituation eingesetzt werden.

Weiter können subjektive Reihenfolgen von Wahrscheinlichkeiten aufgrund von klinischem Wissen ermittelt werden, um Ausfälle welche eine Klinische-Person wahrscheinlich erkennen würde, von solchen Ausfällen zu unterscheiden, welche nicht erkannt würden und damit eher einen Schaden bewirken.

Neue oder neu definierte Begriffe

• LEGACY SOFTWARE
  • Medical Device Software welche legal im Markt eingeführt wurde und immer noch eingeführt wird, für welche aber zu wenig objektive Beweise existieren, dass diese Software in Compliance mit der aktuellen Version dieses Standards entwickelt wurde
• HAZARDOUS SITUATION
  • Situationen in welchen Menschen, Material oder die Umgebung einer oder mehrere Gefährdungen ausgesetzt sind
• RESIDUAL RISK
  • Das übrigbleibende Risiko nachdem Risiko-Kontroll Massnahmen umgesetzt wurden
• RISK ESTIMATION
  • Ermitteln und Zuweisen von Wahrscheinlichkeitswerten bezüglich Schaden und der Schwere dieses Schadens
• RISK EVALUATION
  • Ein Prozess um das abgeschätzte Risiko mit den definierten Risikokriterien zu vergleichen, um zu bestimmen ob das Risiko akzeptierbar ist
• SECURITY
  • Schutz von Daten und Informationen vor unbefugten Personen oder Systemen derart, dass diese keinen Zugriff auf die Daten und Informationen haben und dass befugten Personen und System der Zugriff nicht verweigert wird

Allgemein bekannte Software Fehler

Ein Vorgehen soll definiert und ausgeführt werden um typische Software Fehler ausgehend von einer Technologie zu identifizieren und zu vermeiden (Klasse B,C).

• Identifikation von Fehlern welche auf die gewählte Programmier-Technologie zurückzuführen sind.
• Aufzeigen, dass diese Fehler nicht zu unakzeptablen Risiken führen können.

Validation 

Die IEC 62304 enthält keine Vorgaben bezüglich Validation. Es werden aber folgende Fälle unterschieden.

Falls die MEDICAL DEVICE SOFTWARE eine eigenständige Software ist, ist eine Validation dieser Software erforderlich. Es wird dabei neu auf die IEC 82304-1 (in Arbeit) verwiesen. Diese Norm existiert aktuell als Draft Version und ist in Arbeit.

Für Details zur IEC 82304-1 sehen Sie den Blog Neue Normen zur Software Entwicklung für Medizingeräte

Falls die MEDICAL DEVICE SOFTWARE Teil eines Systems ist, ist eine Validation des Gesamtsystems nach z.B. 60601-1 erforderlich.

Für die Entwicklung medizinischer Software oder bei Fragen steht Ihnen unser MedTech-Team zur Verfügung. Rufen Sie uns an.
Michael Eisenring, michael.eisenring@noser.com, 052 2345614
Ernst Pfister, ernst.pfister@noser.com, 052 2345684

Referenzen:
IEC 62304 AMD1 2015 – Medizingeräte Software – Softwarelebenszyklus Prozess

IEC 82304-1:2013-11 Gesundheitssoftware – Teil 1: Allgemeine Anforderungen für die Produktsicherheit