Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03249.jsonl.gz/1030

Die Validierung von Software ist von Normen und Gesetzgeber gefordert
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ätsmanagementsystem der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR 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.
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
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.
Der Software-Validierungsplan sollte folgende Elemente enthalten:
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.
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:
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:
|Testbericht

Verwendete Umgebung:
Der Gesamttest ist:
☒ Bestanden
☐ Fehlgeschlagen
Datum der Prüfung: 1. Januar 2000
Prüfer: Max Muster Beurteilung: Maximilia Meier
[Unterschrift] [Unterschrift]
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.
Der Software-Validierungsbericht sollte folgende Elemente enthalten:
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 <ip-pii>23||n/a||Bericht 1.pdf|
|V1.0.1, Build <ip-pii>54||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:
Vorwärts-Verlinkung der Anforderungen zu den Tests
Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:
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.
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:
Hinterlassen Sie hier Ihre E-Mail-Adresse und wir informieren Sie, sobald wir neue Beiträge veröffentlichen.