COMPUTER SOFTWARE ASSURANCE (CSA) – EVIDENCE OF ACCEPTANCE VS. EVIDENCE OF APPROVAL

Der lang erwartete Entwurf des Leitfadens für Computer Software Assurance (CSA) zur Verifizierung von Produktions- und Qualitätssicherungssoftware wurde letzten September veröffentlicht. Der jetzige Status lädt zu Kommentaren ein. Der unverbindliche endgültige Leitfaden wird die aktuellen Überlegungen der FDA (Food and Drug Administration) zu diesem Thema widerspiegeln. Doch was können wir bereits aus diesem Entwurf lernen?

Zunächst muss betont werden, dass es sich um einen Leitfaden für Produktions- und Qualitätssicherungssoftware gemäss 21 CFR Teil 820 handelt, der sich mit den Anforderungen an Hersteller von Medizinprodukten zur Validierung von Computersoftware befasst, die als Teil des Produktions- oder Qualitätssicherungssystems verwendet wird. Pharmazeutische Systeme sind daher ausgeschlossen, aber dieser Artikel wird sich sowohl auf Medizinprodukte als auch auf die pharmazeutische Herstellung konzentrieren. Parallel zum CSA Leitfaden wurde kürzlich auch die zweite Version Good Manufacturing Guide 5 (GAMP5) veröffentlicht. Dieses Dokument deckt sowohl die Herstellung von Arzneimitteln als auch von Medizinprodukten ab.

Evidence of Acceptance vs. Evidence of approval

Zwei Aussagen in den Leitliniendokumenten sind meiner Meinung nach sehr interessant:

Im FDA-Entwurf heisst es im Abschnitt «Establishing the Appropriate Record» (S.16): «Documentation of assurance activities need not include more evidence than necessary…». Übersetzt bedeutet dies, dass die Dokumentation der Assurance-Aktivitäten nicht mehr Nachweise als nötig enthalten muss.

Darüber hinaus spricht der GAMP5-Leitfaden (S. 250) die Rede von "evidence of acceptance vs. evidence of approval".

Was bedeutet nun diese scheinbare Abweichung vom bisherigen traditionellen Dokumentationsansatz?

Was in der Vergangenheit gemacht wurde und immer noch gemacht wird, ist, dass viele Beteiligte Aufzeichnungen zur Überprüfung und/oder Genehmigung unterschreiben müssen. Jeder, der mit dem Einholen der Unterschriften vertraut ist, wird bestätigen, dass dies sehr zeitaufwändig sein kann und zu Projektverzögerungen führen oder zumindest Druck auf die Beteiligten ausüben kann. Ausserdem besteht aufgrund des Zeitdrucks die Gefahr, dass das Dokument nicht so gründlich geprüft wird, wie es vielleicht notwendig wäre. Warum brauchen wir also fünf, sechs, sieben oder noch mehr Unterschriften auf einem Dokument, wenn dies eine vermeidbare Belastung darstellt und nichts dazu beiträgt, dass die Dokumentation den gesetzlichen Vorschriften besser entspricht?

Darüber hinaus erfordert der traditionelle Validierungsprozess des Computersystems in der Regel eine Reihe von Dokumentvorlagen, die ausgefüllt werden müssen. Dies erlaubt nicht zwingend die Flexibilität, bestimmte Vorlagen auszuschliessen oder zu kombinieren. So kann es vorkommen, dass Dokumentvorlagen ausgefüllt werden müssen, obwohl diese Dokumente bereits im elektronischen System, das als Quellsystem dient, bereits gespeichert sind. In diesem Fall könnten redundante Informationen leicht vermieden werden. Auch hier gilt, dass redundante Informationen an verschiedenen Stellen nicht die Konformität des Systems erhöhen, sondern meines Erachtens zu Inkonsistenzen führen kann.

Zudem sollte das Sammeln von Beweisen in Form von Screenshots bei fast allen Testschritten überdacht werden. Es kann sicherlich hilfreich sein, bei bestimmten Testschritten einen Screenshot als zusätzlichen Beweis aufzunehmen, aber es sollte angestrebt werden, die Gesamtzahl der Screenshots zu reduzieren. Dies könnte eine Interpretation des Satzes «Documentation of assurance activities need not include more evidence than necessary» sein.

Scripted testing vs. unscripted testing (skriptbasiertes Testen vs. nicht-skriptbasiertes Testen)

Beide Leitfäden führen einen weiteren Begriff ein: «unscripted testing».

Im Gegensatz zum «scripted testing» (skriptbasiertes Testen; schriftliche und vorab genehmigte Testskripte) erhält der Tester oder die Testerin beim «unscripted testing» (nicht-skriptbasiertes Testen) keine genehmigten Anweisungen. Dies könnte zum Beispiel eine Person sein, die sich mit den zugrunde liegenden Geschäftsprozessen und Arbeitsabläufen des Systems sehr gut auskennt. In diesem Fall wird das System auf explorative Weise getestet, ohne einem vorab genehmigten Testfall zu folgen.

Wie kann also der Aufwand für skriptbasiertes Testen reduziert werden? Zunächst muss innerhalb des Projekts definiert werden, was skriptbasierte Tests und nicht-skriptbasierte Tests sind. In der Regel richtet sich die Definition nach dem Risikoniveau des Systems, und der Anforderungen und Spezifikationen. Bei einer GMP-Anwendung ("Good Manufacturing Practice") mit einem hohen Risikoprofil kann es berechtigte Bedenken gegenüber nicht-skriptbasierten Tests geben. Bei Systemen mit geringem oder mittlerem Risiko kann es jedoch ausreichen, nur die risikoreichen Anforderungen und Spezifikationen formal zu testen. Bei Anforderungen/Spezifikationen mit niedrigem und mittlerem Risiko können nicht-skriptbasierte Tests in unterschiedlichem Masse eingesetzt werden, je nach dem angegebenen Risikoniveau. Um ein einfaches Beispiel zu nennen: Es macht absolut keinen Sinn, ein Feature wie ein Freitext-Kommentarfeld mit einer 256-Zeichen-Limit in einem formalen Funktionstest durch einen User (erneut) zu testen, um zu verifizieren, dass wirklich jedes Zeichen bis zu diesem Limit in dieses Feld geschrieben werden kann. Es ist ausreichend, wenn ein Engineer überprüft, ob dies entsprechend den Spezifikationen gebaut wurde und dann dokumentiert, dass die Überprüfung stattgefunden hat.

Es ist auch wichtiger, kritisch darüber nachzudenken, was passieren könnte, wenn ein sequenzieller Schritt eines Arbeitsablaufs umgangen wird und dadurch ein verfälschtes Ergebnis entsteht. Dies kann viel besser überprüft werden, indem man mit dem Workflow "spielt" und verschiedene Kombinationen von Dateneingaben ausprobiert, anstatt einen formalen Testfall zu schreiben, der nur überprüft, ob die lineare Abfolge korrekt ist.

Die beschriebene Änderung des traditionellen Ansatzes ähnelt einem agilen Ansatz. Der agile Ansatz befähigt das Projektteam, mehr Verantwortung zu übernehmen und eigenständiger an den Aufgaben zu arbeiten. Nur mit dieser Einstellung wird ein agiles Projekt erfolgreich sein. Das Gleiche gilt auch für einen ungeschriebenen Testansatz. Beim skriptbasierten Testen werden die Testskripte von einem Testdesigner entworfen und geschrieben und in der Regel formal und inhaltlich von verschiedenen Beteiligten überprüft. Anschliessend werden die endgültigen Testskripte einem Testlauf unterzogen, um die Anzahl potenzieller Testfehler noch weiter zu reduzieren und dann formell genehmigt, bevor die formalen Tests in der Qualitätsumgebung beginnen. Bei diesem Ansatz wird nicht viel dem Zufall überlassen, aber es bleibt auch nicht viel Raum für kritisches Denken. Beim ungeschriebenen Testansatz, ähnlich wie beim agilen Ansatz, müssen die Leute mit dem richtigen Know-how die Tests durchführen und die Geschäftsprozesse hinter dem System kennen. Sie müssen aber auch kreativ denken und versuchen, das System zu knacken und müssen in jedem Fall aufmerksam sein, wenn Fehler auftreten.

Fazit

Beide Leitlinien versuchen, die übermässige Dokumentation zu reduzieren, indem sie das Konzept des Nachweises der Akzeptanz von eher informellen Aktivitäten gegenüber dem Nachweis der Genehmigung von fast allen Aktivitäten einführen. Die Herausforderung besteht darin, das Gleichgewicht zwischen der Dokumentation von Aktivitäten (wie z. B. formellen Tests) und informellen Aktivitäten zu halten, die zwar verfolgt, aber nicht durch Unterschrift genehmigt werden müssen. Dies hängt in hohem Masse von der Art des Projekts, dem Risikoniveau des Systems und seiner Anforderungen sowie von der Reife und Bereitschaft der Organisation ab, sich auf einen solchen Ansatz einzulassen.