Validierung von Computersystemen in Qualitätsmanagementsystemen für Medizingerätehersteller

Lesedauer: 5 min.

Insight in Brief

Die Validierung von Software ist von Normen und Gesetzgeber gefordert

  • Risikomanagement, Anforderung, Validierung sowie Bewertung und Freigabe sind essentielle Bestandteile
  • Die Rückverfolgbarkeit der Validierung zu Anforderungen und Risikokontrollmassnahmen stellen die Vollständigkeit sicher

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

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.

Abbildung 1: Softwareliste

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:

Testbericht

Verwendete Umgebung:

Name und Hersteller Software AG, ERP System
Version und Build V1.0.1, Build 1.0.1.00123
Betriebssystem Windows 10, 64 Bit

 

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

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.

 

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:

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.

 

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

Sind Sie an weiteren Beiträgen interessiert?

Hinterlassen Sie hier Ihre E-Mail-Adresse und wir informieren Sie, sobald wir neue Beiträge veröffentlichen.

Das könnte Sie auch interessieren

IMT Insight TDPM Valve
Lesedauer: 12 Min

Modellierung thermodynamischer Prozesse in Gassystemen

Modelle thermodynamischer Prozesse sind ein wichtiges Instrument in der Entwicklung von Regelkreisen...
IMT Teststände
Lesedauer: 6 Min

Entwicklung von (teil-)automatischen Testständen

Dieser Artikel befasst sich mit der Planung und Entwicklung von Produktionsprüfständen mit Fokus auf drei Aspekte...
IMT Embedded Bild
Lesedauer: 9 Min

Embedded Systeme – «von A bis Z»

Dieser Artikel erfasst die Grundlagen zum Thema Embedded Systeme, mit denen sich IMT seit 30 Jahren...
IMT CFD Simulation
Lesedauer: 5 Min

CFD-Simulation zur Verbesserung des Wärmemanagements

Das Wärmemanagement spielt im Hinblick auf die Robustheit, Sicherheit, Langlebigkeit und Leistungsfähigkeit von Geräten...
Mitarbeiter bei der Arbeit
Lesedauer: 5 Min

System- und Softwarearchitektur in Embedded Systems

Die Begriffe «System», «Design», «Architektur» sind bei der Entwicklung von eingebetteten Systemen oft nicht klar definiert...
Besprechung eines Projektes
Lesedauer: 4 Min

Modellbasierte Methoden in der Systementwicklung

Modellbasierte Methoden bieten reichlich Potential, um die Systementwicklung effektiv zu gestalten.