„Objective Evidence“ bzw. Objektiver Nachweis bei FDA und ISO 13485
Begriffsdefinitionen
Die FDA benutzt den Begriff „objective evidence“ definiert im 21 CFR part 820 (den „Quality System Regulations“) bei der Definition von Verifizierung und Validierung. Auf eine Definition von „objective evidence selbst verzichtet die FDA aber leider.
Update: Müssen Sie Screenshots anfertigen oder gar Videos drehen, ob eine „objective evidence“ zu erbringen? Welche Alternativen dazu gibt es?
V.a. die IEC 60601-1 verwendet den Begriff „objective Evidence“, zu deutsch „objektiver Nachweis“. Dabei verweist sie auf die Begriffsdefinition 2.10 in der ISO 14971:2007. Diese Norm verweist weiter auf die Definition der ISO 9000.
„Daten, die die Existenz oder Wahrheit von Etwas bestätigen“ Die Norm ergänzt, dass „objektive Nachweise durch Beobachtung, Messung, Tests oder mit anderen Mitteln erbracht werden können“.
Forderungen nach „Objective Evidence“
Die FDA fordert die Erbringung einer „objective evidence“ v.a im Kontext des Design History Files, bei dem verschiedene Verifikations- und Validierungsaktivitäten gefordert sind wie z.B. bei der „Design Validation“. Aber auch die Prozessvalidierung muss durch „objective evidence“ erfolgen.
Wie man „Objective Evidence“ nachweisen kann
Alternativen
Viele Medizinprodukte-Hersteller sind unsicher, wie granular eine Dokumentation zu erfolgen hat:
- Variante: Es gibt eine Testspezifikation, die die Testschritte und erwarteten Ergebnisse beschreibt. Der Tester bewertet die Testergebnisse nur mit „passed“ oder „not passed“.
- Variante: Der Tester notiert das Ist-Verhalten z.B. mit „wie spezifiziert“ oder noch konkreter „die Warnmeldung ‚Ungültige Daten‘ erscheint“.
- Variante: Die Tests sind so dokumentiert, dass ein beim Test nicht anwesender die Ergebnisse nachvollziehen kann, beispielsweise dokumentiert ein Screenshot, dass tatsächlich die Warnmeldung erscheint.
- Variante: Der gesamte Test wird als Video aufgezeichnet, das Video wird Teil der Testdokumentation.
Das Ziel der „objective evidence“ besteht darin, einem Auditor zu ermöglichen, alleine anhand der Dokumente zu überprüfen, ob die Tests (in diesem Fall) erfolgreich waren (oder eben nicht). Wenn jemand schreibt „passed“, dann kann ein Auditor das nicht, ohne den Test wiederholen zu lassen.
Ein Gedankenkonstrukt, um die richtige Granularität zu finden
Es gibt keine allgemeingültige Antwort auf die Frage, welche der genannten vier Varianten, die „objective evidence“ erfüllen. Die Antwort auf die Frage zu finden, können Sie sich folgendes Szenario vorstellen:
Sie haben einen neuen Kollegen. Frisch von der Uni. Eigentlich ein toller Typ, sonst hätten Sie ihn sich nicht ausgesucht. Jetzt will er „Home Office machen“ und dort die Tests durchführen. Sie sind sich nicht ganz sicher, ob er das richtig macht. Und ob er überhaupt alles macht.
Was würden Sie erwarteten, dass Sie sich relativ sicher sein können, dass Ihr Kollege seine Arbeit richtig macht, dass er nicht schummelt oder dass ihm versehentlich Fehler unterlaufen? Diese Dokumentation, die Sie sich für diesen Fall wünschen, ist Objective Evidence.
Sind Screenshots notwendig?
Es gibt keine gesetzliche Forderung nach Screenshots. Auch nicht von der FDA. Inspektoren wollen nachvollziehen können, welche Verifizierungs- und Validierungsaktivitäten Sie mit welchen Ergebnissen durchgeführt haben. Ein simples „Pass/Fail“ wird daher regelmäßig nicht akzeptiert.
Die Screenshots sind eine Möglichkeit, diese Anforderungen zu erfüllen, d.h. diesen Nachweis zu erbringen. Es geht auch nicht darum, jeden Mausklick (bitte nur als Metapher verstehen) zu dokumentieren. Wenn Sie sich beispielsweise erst an einem System einloggen müssen, um Daten einzugeben, dann reicht es, dass die nachweisen, dass die Dateneingabe funktioniert. Dass Sie sich eingeloggt haben, dokumentieren Sie nicht nochmals mit. Das würden Sie im Rahmen einer Prüfung einer anderen Systemanforderung tun, die etwas mit dem Einloggen zu tun hat.
Das Beispiel von dem Login stammt aus einem Beitrag zum Thema „objective evidence“ einer ehemalige FDA-Mitarbeiterin.
Gibt es Alternativen?
Je nach Test kann auch ein System-Log hilfreich sein, mit dem Sie beweisen, dass sich ein System wie spezifiziert verhält. Möglicherweise benötigen Sie noch eine Validierung, in der Sie zeigen, dass das Auditlog wirklich deas beobachtete Systemverhalten wiedergibt. Im FDA Kontext sollten Sie die Thema 21 CFR part 11 im Hinterkopf haben.
Manchmal sind Videos hilfreich, z.B. wenn Sie eine Dynamik so dokumentieren wollen, dass „objective evidence“ gegeben ist.
Best Practices
Die meisten Firmen wehren sich gegen Screenshots und Videos, weil beides viel Arbeit bedeutet. Ich möchte ergänzen: Meist stupide und repetitive Arbeit. Aber muss das sein? Professionelle Firmen automatisieren die Verifizierung ihrer Produkte:
- Die UI wird durch automatisierte UI-Tests geprüft. Damit stellen Sie die Korrektheit von Ausgaben, von Positionen und dem Layout von Benutzerschnittstellen sicher.
- Bei Medizingeräten werden die Teststände etwas aufwendiger. Innovative Firmen haben sich kleine Testroboter gebaut, die die Benutzeraktionen simulieren und zusammen mit den Systemreaktionen auswerten und dokumentieren. Sparsame Firmen schreiben das Erstellen von Testständen als Bachelor- oder Masterarbeiten aus. Wäre doch ein Tipp, oder?
Gibt es Erfahrungswerte oder Einschätzungen darüber, ob und wenn ja in welcher Form die FDA Objective Evidence auch für automatisierte Tests erwartet? Hier stehen sich folgende Aussagen diametral gegenüber: Einerseits fordert sie Objective Evidence für Verifizierungsaktivitäten, andererseits sind die Ergebnisse von automatisierten Tests deterministisch und können jederzeit unter den selben Voraussetzungen wiederholt werden.
Was also tun? Kann man auf OE verzichten? Reichen vom Test generierte und archivierte Logfiles aus? Oder müssen automatisierte Tests OE generieren, die den selben Anforderungen wie denen von manuell durchgeführten Tests genügen?
Sehr geehrte Frau Henke,
danke für Ihre spannende Frage!
Ich sehe den Widerspruch noch nicht ganz. Ein automatisierter Test ist in der Tat (i.d.R.) deterministisch. Man weiß also genau, was gemacht wurde. Man weiß aber nicht, ob der Test wirklich durchgeführt wurde und was die tatsächlichen Ergebnisse (und ggf. deren Bewertungen) waren. Wenn man diese Informationen hat, liegt OE vor. Ob diese Informationen in Log-Files, in Datenbankeinträgen, in generierten PDFs oder Screenshots zu finden sind, bleibt dem Hersteller überlassen.
Beste Grüße, Christian Johner