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

blog-featureimage-people

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?

monitoring in operation room

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 –

Ähnliche Beiträge

NTT_DATA-Business-Solutions-690x180
Lesen Sie mehr
blog_featured image_simplification1
Lesen Sie mehr
Blogbild_Scrum
Lesen Sie mehr
Image_Gears-on-Digital-Background-690x180
Lesen Sie mehr
Blogbild_Alain-1
Lesen Sie mehr
Feature_Image-Experience-NewOpportunities-690x180
Lesen Sie mehr
Folgen Sie uns: