Gesetze und Normen (z. B. FDA, ISO 13485) fordern eine „objective evidence“, auf Deutsch einen „objektiven Nachweis“.
- Wie beweissicher muss dieser Nachweis sein, damit Behörden und Benannte Stellen zufrieden sind?
- Wie finden Hersteller die Balance zwischen einer Überdokumentation und Problemen im Audit?
Antworten auf diese Fragen gibt dieser Artikel.
1. Begriffsdefinitionen
Die FDA verwendet den Begriff objective evidence (objektiver Nachweis) im 21 CFR part 820 (den „Quality System Regulations“) bei den Definitionen von Verifizierung und Validierung. Auf eine Definition des Begriffes selbst verzichtet die FDA aber leider.
Auch die IEC 60601-1 verwendet den Begriff „objective evidence“. 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“.
ISO 9000 3.8.1
Diese Nachweise sollten somit durch Daten erbracht werden. Dies drückt auch die MDR in ihrer Definition des Begriffs „klinischer Nachweis“ (clinical evidence) aus.
die klinischen Daten und die Ergebnisse der klinischen Bewertung zu einem Produkt, die in quantitativer und qualitativer Hinsicht ausreichend sind, um qualifiziert beurteilen zu können, ob das Produkt sicher ist und den angestrebten klinischen Nutzen bei bestimmungsgemäßer Verwendung nach Angabe des Herstellers erreicht;
MDR Artikel 2 (51)
2. Regulatorische Anforderungen nach „Objective Evidence“
a) FDA
Die FDA fordert die Erbringung einer „objective evidence“ v. a. im Kontext des Design History Files und der Verifikations- und Validierungsaktivitäten, z. B. bei der Design Validation. Auch die Prozessvalidierung muss durch „objective evidence“ erfolgen.
b) MDR / IVDR
MDR und IVDR verlangen Nachweise unter anderem für die Konformität des Produkts, z. B. die Einhaltung der grundlegenden Sicherheits- und Leistungsanforderungen.
Den deutschen Begriff „Nachweis“ übersetzen die EU-Verordnungen jedoch nicht mit „evidence“, sondern mit „demonstration“. Von „evidence“ spricht die MDR v. a. im Kontext der „clinical evidence“.
Vorgaben über die Art dieser Nachweise machen die Verordnungen nicht.
c) ISO 13485
Die englische ISO 13485 arbeitet mit dem Begriff „evidence“, allerdings ohne den Zusatz „objective“. Diese Objektivität setzt sie wahrscheinlich voraus. Die Norm fordert Nachweise zur:
- Konformität des Produkts
- Wirksamkeit des QM-Systems
- Verpflichtung der obersten Leitung
Die Norm fordert also „evidence“, macht aber ebenfalls keine Vorgaben dazu, wie diese Evidenz zu erbringen ist.
Die „objective evidence“ ist nicht nur im Kontext von Produktprüfungen, dem Risikomanagement und der klinischen Bewertung gefordert, sondern auch bei Post-Market-Aktivitäten wie der Post-Market-Surveillance (z. B. bei dem Wirksamkeitsnachweis von CAPA).
3. Nachweis der „Objective Evidence“
a) Problemstellung
Viele Hersteller von Medizinprodukten sind unsicher, wie granular eine Dokumentation dieser Nachweise erfolgen muss.
- Level (sehr grob-granular)
Es gibt eine Testspezifikation, die die Testschritte und erwarteten Ergebnisse beschreibt. Der Tester bewertet die Testergebnisse nur mit „passed“ oder „nicht passed“. - Level
Der Tester notiert das Ist-Verhalten, z. B. „wie spezifiziert“ oder konkreter „die Warnmeldung ‚Ungültige Daten‘ erscheint“. - Level
Die Tests sind mit Screenshots dokumentiert, die beispielsweise die tatsächlich Warnmeldung zeigen. - Level (sehr detailiert)
Der gesamte Test wird als Video aufgezeichnet und das Video wird Teil der Testdokumentation.
Welches ist das richtige Level?
Das Ziel der „objective evidence“ muss darin bestehen, dass ein Auditor nur anhand der Dokumente (ein Video zählt hier auch als Dokument) überprüfen kann, ob im obigen Beispiel die Tests erfolgreich waren (oder eben nicht).
Dafür ist das erste Level nicht ausreichend. Denn alleine der Hinweis „passed“ erlaubt es nicht nachzuvollziehen, ob der Test tatsächlich durchgeführt wurde. Auch beim zweiten Level ist die Nachvollziehbarkeit nur eingeschränkt gegeben. Ab dem dritten Level dürften Auditoren und Reviewer genügend Evidenz haben.
b) Gedankenexperiment: Die richtige Granularität finden
Es gibt keine allgemeingültige Antwort auf die Frage, welche der genannten vier Levels die Anforderung nach „objective evidence“ erfüllen. Bei der Suche nach einer Antwort auf diese Frage hilft das folgende Gedankenexperiment:
Sie haben einen neuen Kollegen, frisch von der Uni. Eigentlich ein toller Typ, sonst hätten Sie ihn nicht eingestellt. Aber machmal wählt er den bequemsten Weg. 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 als Nachweis erwarteten um relativ sicher sein zu können, dass Ihr Kollege seine Arbeit richtig macht, dass er nicht schummelt oder dass ihm versehentlich Fehler unterlaufen? Die Dokumentation, die Sie sich für diesen Fall wünschen, erbringt „objective evidence“.
Es geht also nicht um eine vorsätzlich böswillig agierende Person, die Daten mit hoher krimineller Energie fälscht.
c) Konkrete Hinweise
Notwendigkeit von Screenshots
Es gibt keine gesetzliche Forderung nach Screenshots, auch nicht von Seiten der FDA. Inspektoren wollen nachvollziehen können, welche Verifizierungs- und Validierungsaktivitäten ein Hersteller mit welchen Ergebnissen durchgeführt hat. Ein simples „Pass/Fail“ wird daher regelmäßig nicht akzeptiert.
Die Screenshots sind eine Möglichkeit, diese Anforderungen zu erfüllen, also diesen Nachweis zu erbringen. Es geht nicht darum, jeden Mausklick (bitte nur als Metapher verstehen) zu dokumentieren.
Wenn sich Anwender in ein System einloggen müssen, um Daten einzugeben, reicht der Nachweis, dass die Dateneingabe funktioniert. Dass sich die Anwender zuvor eingeloggt haben, ergibt sich implizit. Das muss man nicht zusätzlich dokumentieren.
Falls jedoch der Hersteller überprüfen will, ob die Systemanforderungen im Kontext des Logins oder der IT-Security erfüllt sind, dann wären diese Ergebnisse und damit der Login-Vorgang zu dokumentieren.
Das Beispiel vom Login stammt aus einem Beitrag zum Thema „objective evidence“ einer ehemaligen FDA-Mitarbeiterin.
System-Log
Je nach Test kann auch ein System-Log hilfreich sein, um „objective evicende“ nachzuweisen.
Ein System-Log hilft beim Nachweis, dass Aktivitäten tatsächlich durchgeführt wurden. Wenn damit auch die Ausgaben des Systems dokumentiert werden sollen, müssen einige Voraussetzungen erbracht sein:
- Der Hersteller muss nachweisen, dass die Ausgaben (z. B. an der UI) und im System-Log identisch sind.
- Der Hersteller muss bewerten, ob die Ausgaben den Anforderungen genügen.
- Die Prozess-Software zur Automatisierung der Tests muss validiert sein (Computerized System Validation).
- Die Logs sind elektronische Aufzeichnungen und müssen daher die gesetzliche Anforderungen an die Dokumentenlenkung und der 21 CFR part 11 erfüllen.
Videos
Manchmal sind Videos hilfreich, z. B. wenn Sie eine Dynamik so dokumentieren wollen, dass „objective evidence“ gegeben ist. Dabei sind die Nachteile von Videos zu beachten:
- Ein Video dokumentiert nur die Durchführung und ggf. die Ergebnisse. Es bewertet aber nicht das Ergebnis, also ob die zu überprüfenden Produktanforderungen erfüllt sind. Die Nachbereitung von Videos kann aufwändig sein.
- Videos sind sehr speicherintensiv. Das ist zu bedenken, wenn Hersteller die Aufzeichnungen automatisiert in einem Versionsverwaltungssystem speichern wollen.
- Die Anforderungen an die Automatisierung von Videoaufzeichnungen sind hoch, was insbesondere bei Regressionstests hilfreich wäre.
Alternativen zu Screenshots und Videos
Die meisten Firmen wehren sich gegen Screenshots und Videos, weil beides mit viel Arbeit verbunden ist. Daher automatisieren professionell arbeitende Firmen die Verifizierung ihrer Produkte anderweitig:
- Die UI wird durch automatisierte UI-Tests geprüft. Damit stellt der Hersteller die Korrektheit von Ausgaben, von Positionen und dem Layout von Benutzerschnittstellen sicher.
- Ein Hersteller baut Testroboter, die die Benutzeraktionen simulieren und zusammen mit den Systemreaktionen auswerten und dokumentieren. KI hilft, diese Reaktionen zu bewerten.
4. Fazit und Zusammenfassung
Die Meinungen darüber, wie beweissicher die Nachweise (die „objective evidence“) sein müssen, gehen auseinander.
- Die Nachweise sollten so detailliert dokumentiert werden, dass eine unbeteiligte Person nachvollziehen kann, was gemacht wurde und wie der Hersteller begründet, dass sein Produkt die Anforderungen erfüllt.
- Die Granularität dieser Aufzeichnungen sollte „risk based“ erfolgen: Bei hohen regulatorischen Risiken oder bei Risiken für die Gesundheit von Patienten, Anwendern und Dritten sollte die Beweisführung vollständig sein. Es gibt aber keine gesetzliche Pflicht zu Screenshots oder Videos.
- Es ist hilfreich, die Nachweise automatisiert zu erbringen, genauso wie es hilfreich ist, die Tests zu automatisieren.
Das Johner Institut hilft Herstellern von Medizinprodukten und IVD dabei, bei diesen Nachweisen die richtige Balance zu finden und damit unnötige Dokumentationsaufwände genauso zu vermeiden wie regulatorische Risiken.
Änderungshistorie
- 2024-11-06: Artikel weitgehend überarbeitet, neu strukturiert
- 2016-02-10: Erste Version des Artikels publiziert
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