Einleitung

Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances und die Europäische Medical Device Regulation (MDR) fordern, dass Software, welche im Qualitätsmanagement System der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR nicht weiter beschreiben, wie die Toolvalidierung auszusehen hat, hat die US FDA am 11. Januar 2002 eine Guidance veröffentlicht: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. Auch die Arbeitsgruppen von ISO und IEC haben sich Gedanken zu diesem Thema gemacht und 2017 den ISO/TR 80002-2 veröffentlicht: «Validation of software for medical device quality systems».

Ziel dieses Artikels ist es, einen einfachen Weg aufzuzeigen, wie eine solche Tool-Validierung aufgebaut werden kann.

Software Liste

Beide, die ISO 13485 (in Kapitel 4.1.6) und die FDA Guidance (in Kapitel 4.8) fordern, dass die Validierung der Software dem Risiko der Software entspricht, unabhängig von der Firmengrösse oder der zur Verfügung stehenden Ressourcen. Dementsprechend benötig ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihres Verwendungszwecks. Vorzugsweise wird in dieser Übersicht auch dokumentiert ob es sich um eine

• «Off the shelf» Software (also eine Software die als Massenprodukt im Handel erworben werden kann),
• eine angepasste Software
• oder sogar um eine explizit für den geplanten Einsatz entwickelte Software handelt.

Eine Standard-Software wie z.B. Word von Microsoft sind zu tausenden installiert, die Wahrscheinlichkeit, dass die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler findet, ist wohl um einiges höher, als meine Tool Validierung. Diesem Umstand darf in der Toolvalidierung Rechnung getragen werden. Der Prozess für Standard Software, welche nur für nicht-kritische Zwecke verwendet wird, kann unter Umständen bereits hier abgeschlossen werden.

Abbildung 1: Software Liste

Software Validierungsplan

Der Software-Validierungsplan bzw. Toolvalidierung sollte folgende Elemente enthalten:

1. Beschreibung der Software inklusive vorgesehenen Gebrauch, vorgesehene Nutzer und deren Umgebung
2. Anforderungen an die Software
3. Testspezifikation für die Softwareanforderungen
4. Risikomanagement Plan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapitel dokumentiert werden, oder aber in verschiedene Dokumente ausgelagert. Letzteres eignet sich vor allem bei umfangreicheren Anforderungsdokumenten.

Beschreibung der Software

Das Kapitel oder Dokument mit der Beschreibung der Software soll den vorgesehenen gebrauch, die vorgesehenen Nutzer und deren Umgebung beschreiben. Use Case Diagramme können hier von Vorteil sein um eine einfache, visuelle Übersicht zu geben:

Abbildung 2: Use Case Diagram – Benutzer Verwalten

Software Nutzer Anforderungen

Die Nutzer-Anforderungen sollten in einer testbaren Form erfasst und mit einer eindeutigen ID versehen werden. Wir bei IMT nutzen hier meist die folgende Syntax:

zum Beispiel könnte eine solche Anforderung heissen

oder

Beide Anforderungen haben eine eindeutige ID und können getestet werden. Anforderungen welche nicht getestet werden können sind zu vermeiden, so sollte «schnell» durch eine Zeitangabe wie «2 Sekunden» ersetzt werden, oder «hell» durch «unter einer Inspektionslampe mit 1500lx».

Testspezifikation für die Nutzer-Anforderungen

Jede Nutzer-Anforderung benötigt im Minimum einen Test. Zur Testspezifikation gehört neben einer eindeutigen ID, die Prüfanweisung sowie das Akzeptanzkriterium oder erwartete Resultat. So könnte ein Test für obiges UR-001 aussehen:

Risikomanagement Plan für diese Software

Da die Auswirkungen bei einem Fehler der Software im Qualitätsmanagementsystem anders sind, als bei einem Medizinprodukt, muss auch der Risikomanagementplan entsprechend angepasst sein. Insbesondere die Definitionen der Auswirkungskategorien benötigen eine differenzierte Betrachtung. Je nach Anwendungsbereich bekommen die selben Auswirkungskategorien eine völlig unterschiedliche Bedeutung. Die Auswirkungskategorie «kritisch» bedeutet bei einem Medizingerät möglicherweise den Tod eines Patienten, bei einer Software zur Rückverfolgung der Medizingeräte dagegen der Verlust von Daten.

Prüfen und Bewerten

Bevor der Validierungsbericht erstellt werden kann, muss die Software getestet und die Risiken müssen bewertet werden.

Testbericht

Die Software ist gemäss der Prüfspezifikation zu prüfen. Dabei ist zu jedem Prüfschritt nicht nur ein «Pass/Fail» zu protokollieren, sondern auch das tatsächlich beobachtete Verhalten, so dass die Prüfung nachgestellt werden kann. Daher muss auch die Software und ihre Umgebungsbedingungen protokolliert werden. Dazu gehören:

• Name und Hersteller der Software
• Version, Build Nummer
• Betriebssystem
• 32/64 Bit Umgebung
• Verwendete Peripherie
• ….

Aber auch Datum, Prüfer sowie eine Bewertung im 4-Augen-Prinzip gehört dazu:

Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:

Risikoanalyse

In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei Software, welche mit dem Zweck des Einsatzes in regulierter Umgebung vertrieben wird, wird oft auch eine entsprechende Liste der bekannten Anomalien veröffentlicht. Hier lohnt es sich auf der Support-Webseite vom Hersteller nachzusehen oder den Support zu kontaktieren. Neben den Problemen die dem Hersteller bekannt sind, sind auch Unzulänglichkeiten wie fehlende Features zu bewerten. Ist ein Risiko nicht akzeptabel, müssen Kontrollmassnahmen definiert werden, um das Risiko zu reduzieren. Als Medizingerätehersteller, welche sich an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.

Software Validierungsbericht

Der Software Validierungsreport sollte folgende Elemente enthalten:

1. Identifikation der Software und Umgebung
2. Testbericht(e) oder Verweis(e) darauf
3. Risikomanagementbericht über die bekannten Anomalien der Software
4. Nachweis, dass alle Anforderungen geprüft wurden. Dies lässt sich am einfachsten über eine Traceability Matrix abbilden.
5. Formelle Bewertung und Freigabe der Software zur Nutzung

Hinweis: Für «kleinere» Applikationen, kann möglicherweise Testreport, Risikoanalyse und Validierungsbericht auch in einem Dokument erstellt werden.

Identifikation der Software und Umgebung, Testbericht

Oft gibt es für die Software eine Matrix der validierten Versionen und Umgebungen, dann sollte diese im Validierungsbericht entsprechend abgebildet werden:

Risikomanagementbericht über die bekannten Anomalien der Software

Der Validierungsbericht soll weiter das Restrisiko welche durch die Nutzung dieser Software entsteht bewerten. Insbesondere liegt hier der Fokus auf der Akzeptabilität der bekannten Anomalien und/oder fehlenden Funktionen.

Traceability

Ein weiterer Aspekt den es abzudecken gibt, ist nachzuweisen dass alle Anforderungen an die Software getestet wurden. Je nach Umfang der Anforderungen und der Dokumentation der Tests haben sich zwei Möglichkeiten herausgeschält dies zu dokumentieren:

Vorwärts-Verlinkung der Anforderungen zu den Tests

Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:

Diese Variante eignet sich vor allem bei kleinem Umfang an Anforderungen und wenn die gesamte Validierung in einem Dokument erstellt wird.

Traceability-Matrix

Bei umfangreichen Anforderungsdokumenten oder wenn die Testdurchführung ihre eigenen ID’s besitzt, empfiehlt es sich eine Traceability Matrix zu erstellen, welche die Anforderungen der Testspezifikation und eventuell dem Testbericht gegenüberstellt:

Sollen mehrere Berichte für verschiedene Laufzeitumgebungen und Softwareversionen abgebildet werden müssen, so kann dies in einer Traceability Matrix sehr einfach durch zusätzliche Spalten abgebildet werden.

Formelle Bewertung und Freigabe

Zu guter Letzt soll das Gesamtpaket der Dokumentation bewertet und mit einem Entscheid der Freigabe dokumentiert werden.

Zusammenfassung

Bildlich dargestellt, ist die Validierung der Software im Qualitätsmanagementsystem nichts anderes, als die Systematische, dokumentierte Durchführung der linken und rechten, oberen Ecken des in der Softwareentwicklung weit verbreiteten V-Modells:

Dazu gehören:

• Vorgesehener Nutzen sowie Anforderungen
• Risikomanagement
• Validierung der Nutzeranforderung
• Bewerten der Risiken
• Bewerten der Gesamtvalidieurng und Freigabe der Software für den vorgesehenen Nutzen.