Validierung von Computersystemen in Qualitätsmanagement-systemen für Medtech

Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances, die Europäische Medical Device Regulation (MDR) und die Europäische In vitro Diagnositc Regulation (IVDR) fordern, dass Software, welche im Qualitätsmanagementsystem der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485, die EU MDR und die EU IVDR nicht weiter beschreiben, wie die Validierung 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 Toolvalidierung 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 den zur Verfügung stehenden Ressourcen. Dementsprechend benötigt ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihren Verwendungszweck. 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.

 

Für eine Standard-Software wie z.B. Word von Microsoft, die zu tausenden installiert ist, ist die Wahrscheinlichkeit, dass durch die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler gefunden wird, wohl um einiges höher, als durch eine Toolvalidierung. 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.

Software-Validierungsplan

Der Software-Validierungsplan sollte folgende Elemente enthalten:

• Beschreibung der Software inklusive vorgesehenem Gebrauch, vorgesehenen Nutzern und deren Umgebung
• Anforderungen an die Software
• Testspezifikation für die Softwareanforderungen
• Risikomanagementplan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapiteln dokumentiert oder aber in verschiedene Dokumente ausgelagert werden. 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:

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:

ID	Anforderung
UR-[ID]	[Rolle] möchte [Funktion] für [Zweck]

 

zum Beispiel könnte eine solche Anforderung heissen

ID	Anforderung
UR-001	Der Serveradministrator möchte Passwörter zurücksetzen können, um Nutzern, die Ihr Passwort vergessen haben, erneut Zugriff zu gewähren.

oder

UR-002

Der Nutzer möchte das erst teilweise ausgefüllte Formular speichern, um nach einem Unterbruch weiterarbeiten zu können.

 

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 1500 lx».

 

Testspezifikation für die Nutzer-Anforderungen

Jede Nutzeranforderung benötigt im mindestens 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:

ID	Prüfschritte	Erwartetes Resultat
1	Admin-Tool starten und mit einem Benutzernamen und Passwort mit Administratorrechten anmelden	Admin-Tool ist gestartet und ein Admin ist eingeloggt
2	Wähle den User «Vergesslich, Hans» aus und wähle «Passwort zurücksetzen»	Passwort-zurücksetzen-Fenster erscheint
3	Setze ein neues Passwort und speichere es	Neues Passwort ist gesetzt.
4	Logge dich in die Applikation mit dem User «Vergesslich, Hans» und dem soeben gesetzten Passwort ein	Login war erfolgreich.

 

Risikomanagement Plan für diese Software

Da die Auswirkungen eines der Softwarefehlers 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 dieselben 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 den 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 müssen 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ören dazu: Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:

Risikoanalyse

In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei einer 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 an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.

 

Software Validierungsbericht

Der Software-Validierungsbericht sollte folgende Elemente enthalten:

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

Hinweis: Für «kleinere» Applikationen, können möglicherweise Testbericht, 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. Wenn das der Fall ist, sollte diese im Validierungsbericht entsprechend abgebildet werden:

Software Version	Windows 10, 32 bit	Windows 10, 64 bit
V1.0.1, Build 1.0.1.00123	n/a	Bericht 1.pdf
V1.0.1, Build 1.0.2.00254	Bericht 2.pdf	Bericht 3.pdf

 

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 gilt, 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:

 

1. Vorwärts-Verlinkung der Anforderungen zu den Tests

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

ID	Anforderung	Getestet in
UR-001	Der Serveradministrator möchte Passwörter zurücksetzen können, um Nutzern, die Ihr Passwort vergessen haben, erneut Zugriff zu gewähren.	TC 1-4
UR-002	Der Benutzer möchte das erst teilweise ausgefüllte Formular speichern, um nach einem Unterbruch weiterarbeiten zu können.	TC 5-8

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

 

2. Traceability-Matrix

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

Anforderung	Testspezifikation	Testbericht
UR-001	TC-1	TR-12
	TC-2	TR-13
	TC-3	TR-14
	TC-4	TR-15
UR-002	TC-5	TR-17
	TC-6	TR-18
	TC-7	TR-19
	TC-8	TR-20

Sollten 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.

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 Nutzeranforderungen
• Bewerten der Risiken
• Bewerten der Gesamtvalidierung und Freigabe der Software für den vorgesehenen Nutzen.