Vorher wissen, wo ein Fehler auftritt: Beim Testen von Software in der Medizintechnik geht nichts ohne eine detaillierte Risikoanalyse

Steven Weinberg, Physiknobelpreisträger von 1979, meinte einmal: „Wenn Architekten genauso bauen würden wie Softwareentwickler programmieren, würde der erste Vogel, der vorbeikommt, die Zivilisation zerstören.“ Klingt drastisch, bringt aber das Grundproblem von IT-Validierung in der Medizintechnik auf den Punkt. Fakt ist: In jeder Software stecken Fehler, daher ist die Frage nicht, ob, sondern wie man testen soll. Ohne eine detaillierte Risikoanalyse wird man da sicher nicht weit kommen. Letztlich geht es darum, vorzudenken, was der Anwender bei der Bedienung falsch machen könnte. Was, wenn eine falsche Serialnummer eingibt oder einem falschen Produkt zuordnet? Merkt die Software, wenn für einen GMP-relevanten Prozess eine falsche Funktion abgerufen wird? Was, wenn der für die verpflichtende UDI-Kennzeichnung notwendige Barcode nicht lesbar ist oder im Rahmen der Lieferkette beschädigt wird?

Ich empfehle daher Herstellern von Medizinprodukten auch immer, die Schwere des möglichen Fehlers einzuschätzen: Welche Abläufe sind am meisten betroffen? Wie wahrscheinlich ist es, dass er eintritt? Am besten klassifiziert und gewichtet man diese Parameter nach definierten Faktoren, beispielsweise niedriges, mittleres und hohes Risiko. Auf diese Weise lässt sich jeder softwaregestützte Prozess analysieren. Je mehr Risiken man im Vorfeld erkennt, desto mehr Fehler können vorab eliminiert werden.

Anhand dieser Risikofaktoren erstellt man dann einen detaillierten Testplan. Welche Prozesse müssen an welchen Stellen mit welcher Ausführlichkeit geprüft werden? Der Plan beschreibt exakt die Schritte und Eingaben, die der Anwender bei der Bedienung des Programms vornimmt. Natürlich hält man auch die zu erwartenden Testergebnisse fest. Bei der eigentlichen Prüfung geht es dann nur noch darum festzustellen, ob diese auch erzielt wurden. Sind die Abweichungen zwischen Prognose und tatsächlichem Ergebnis zu groß, sollte das System unbedingt einen entsprechenden Fehlerbericht erzeugt haben. Kurz: Der Testplan muss also die Reaktionen, wie sie die Software liefern muss, bereits enthalten, damit auch zielführend geprüft werden kann. Wer dann noch einen erfahrenen Dienstleister für Validierungsprojekte an seiner Seite hat, kann sich einer GMP-konformen IT so gut wie sicher sein.

Weitere Details habe ich aktuell in der Online-Ausgabe der Fachzeitung DeviceMed beschrieben. Natürlich entstehen bei diesem Thema eine ganze Reihe individueller Fragen. Schreiben Sie mir einen Kommentar und ich melde mich persönlich bei Ihnen.

– von Stephan Limberg, Leitung Branchenmanagement Prozessindustrie, itelligence AG –