Waters Empower validieren: vom Rohdatensatz zum nachvollziehbaren Ergebnis

1. Den GxP-Umfang und die genaue Systemversion festlegen

Beschreiben Sie zunächst, wofür das Labor Empower verwendet: etwa zur Gehaltsbestimmung, Reinheitsprüfung oder Stabilitätsanalytik. Halten Sie fest, welche Ergebnisse eine qualitätsrelevante Entscheidung unterstützen, wer sie verwendet und welche Übergaben folgen. Eine reine Methodenentwicklung kann einen anderen Daten- und Freigabeprozess haben als die Routineprüfung einer Charge.

Dieser Artikel betrachtet vor allem GMP-regulierte Arzneimittellabore. Annex 11 bezieht sich auf computergestützte Systeme in GMP-Tätigkeiten; die Anwendbarkeit weiterer GxP-Anforderungen ist gesondert einzuordnen. Das EU-Verzeichnis führt am Recherchetag Annex 11 mit Revision Januar 2011.

Dokumentieren Sie Empower-Release einschließlich Service Release, Betriebsform, Datenbank, Erfassungsrechner, Gerätetreiber und angebundene Instrumente. Die hier verwendeten Waters-Unterlagen betreffen Empower beziehungsweise Empower 3; einzelne Funktionen haben ausdrücklich benannte Versionsgrenzen. Prüfen Sie daher jede übernommene Einstellung gegen Ihre installierte Hilfe und Release-Dokumentation. Ein allgemeiner Produktname reicht als Systembeschreibung nicht aus.

Quellen: [7] [8] [1]

2. Rohdaten, Methoden und Ergebnisse auseinanderhalten

Für eine belastbare Anforderungsliste lohnt sich ein konkreter Datensatz: Wählen Sie eine Probe und verfolgen Sie ihren Weg durch Sample Set, Injektion, erfassten Kanal, Verarbeitung und Ergebnisbericht. Welche Probeninformationen stammen aus manueller Eingabe, welche aus einer Schnittstelle? Welche Version der Instrument Method wurde für die Erfassung genutzt, welche Processing Method für die Auswertung?

Waters beschreibt die Verknüpfung von Methodenständen mit Daten und Ergebnissen sowie eigene Historien für Methoden und Probeninformationen. Diese Zusammenhänge sollten im Nachweis sichtbar sein. Eine nachträglich korrigierte Einwaage und eine veränderte Integration sind unterschiedliche Eingriffe, auch wenn beide den berichteten Gehalt beeinflussen können.

Ein PDF kann das betrachtete Ergebnis gut darstellen. Es ersetzt aber nicht automatisch die dynamischen elektronischen Aufzeichnungen, die für eine erneute Prüfung benötigt werden. Legen Sie fest, welcher Datensatz maßgeblich ist und wie ein Prüfer Rohsignal, verwendete Parameter und Ergebniszusammenhang wiederfindet.

Quellen: [2] [9]

3. Berechtigungen anhand tatsächlicher Handlungen prüfen

Eine Rollenliste ist erst aussagekräftig, wenn klar ist, was ihre Benutzer im Alltag ausführen können. Erstellen Sie ein Testkonto je relevanter Rolle: Analyst, Methodenverantwortlicher, Prüfer und Administrator. Prüfen Sie erlaubte Aufgaben und ausdrücklich verbotene Handlungen. Verwenden Sie dabei auch ein Konto mit mehreren zulässigen Rollen, falls diese Kombination im Betrieb vorkommt.

Bei Empower wirken System Policies und User-Type-Privilegien zusammen. Die Berechtigung Save Processing Methods kann nach Waters untergeordnete Änderungsrechte übersteuern. Deshalb genügt es nicht, einen einzelnen Haken für Integrationsparameter zu entfernen und daraus eine wirksame Sperre abzuleiten.

Ein geeigneter Negativtest lautet: Der Routineanalyst soll eine freigegebene Methode verwenden, aber keine neue Auswertelogik speichern. Testen Sie die verfügbaren Wege in der konkreten Oberfläche. Erfassen Sie nicht nur die Fehlermeldung, sondern auch, ob ein anderer User Type oder ein erlaubtes Speichern unter anderem Namen das gewünschte Kontrollziel unterläuft.

Quellen: [1] [7]

4. Reprocessing und manuelle Integration richtig bewerten

Reprocessing bezeichnet die erneute Verarbeitung bereits erfasster Daten. Manuelle Integration betrifft dagegen einen Eingriff in die Peak-Auswertung. Beides braucht einen definierten fachlichen Anlass und eine nachvollziehbare Entscheidung darüber, welches Ergebnis verwendet wird. Ein günstigerer Zahlenwert ist keine hinreichende Begründung.

Eine produktspezifische Falle beschreibt Waters zur Policy Prompt User to Save Manual Changes Made in Review: Auf diesem Weg gespeicherte Ergebnisse erhalten die Kennzeichnung Manual auch dann, wenn keine manuelle Integration stattgefunden hat. Prüfer sollten daher die konkreten Änderungen und den Entstehungsweg betrachten.

Als eigene Prüfübung können Sie denselben Rohdatensatz einmal unverändert und einmal mit einer begründeten Integrationsänderung auswerten. Halten Sie Ausgangsergebnis, veränderte Parameter, neues Ergebnis und Auswahlentscheidung fest. Ergänzen Sie einen zurückgewiesenen Bearbeitungsversuch. Die FDA erläutert, dass verworfene Daten nicht allein durch eine spätere erfolgreiche Auswertung aus dem vollständigen Datensatz verschwinden dürfen.

Quellen: [1] [9]

5. Die passenden Quellen für den Audit Trail Review auswählen

Der Result Audit Viewer bündelt nach Waters mehrere ergebnisbezogene Historien und ermöglicht den Vergleich früherer Ergebnisse und Methodenstände. Seine Anzeige ist dennoch eine Sicht auf Daten. Prüfen Sie den Zeitraum und die Filter: Der Hersteller-Tipp 373 beschreibt beispielsweise eine zeitlich eingeschränkte Anfangsansicht. Eine leere Trefferliste belegt daher noch keinen unveränderten Ablauf.

Die folgende Zuordnung ist eine Arbeitshilfe für die eigene Review-Anweisung. Sie sollte festlegen, welche Auffälligkeit welche weitere Prüfung auslöst und wer offene Punkte klärt. Ein Sammelvermerk wie „Audit Trail geprüft“ lässt diese Entscheidungskette häufig offen.

Quellen: [3] [4] [2]

6. Illustratives Testbeispiel: eine auffällige Probe erneut auswerten

Das folgende Beispiel verwendet einen vorbereiteten Testdatensatz mit einem überlagerten Peak. Vor Testbeginn definiert der Methodenverantwortliche, welche Anpassung fachlich zulässig ist und welche Vergleichsmerkmale betrachtet werden. Die konkreten Akzeptanzkriterien stammen aus Ihrem Verfahren; der Artikel setzt weder eine universelle Integrationsgrenze noch eine allgemeine Ergebnistoleranz.

Führen Sie die Prüfung in einer geeigneten Testumgebung aus. Dokumentieren Sie Objektbezüge, Benutzer und verwendete Methodenstände so, dass ein zweiter Prüfer den Ablauf ohne mündliche Erklärung rekonstruieren kann.

Quellen: [3] [7]

7. Sign-off und Sperren als eigenen Ablauf testen

Beschreiben Sie, was eine elektronische Bestätigung in Ihrem Prozess bedeutet: durchgeführt, geprüft oder freigegeben. Legen Sie fest, wer sie ausführen darf und welche Vorprüfungen abgeschlossen sein müssen. Eine vorhandene Signatur ersetzt keine inhaltliche Bewertung. Unter den jeweils anwendbaren Anforderungen muss ihr Zusammenhang mit dem bestätigten Datensatz erhalten bleiben.

Empower bietet unter anderem Sign-off-bezogene Policies und Channel-Sperren. Waters beschreibt, dass Lock Channels weitere Ergebnisgenerierung verhindern kann und ein eigenes Unlock-Privileg existiert. Daraus folgt eine konkrete Testfrage: Was passiert nach Ihrer Freigabe, wenn jemand erneut verarbeiten oder eine Sperre aufheben möchte?

Prüfen Sie zusätzlich den legitimen Korrekturfall. Ein ausschließlich gesperrter Ablauf ohne geregelte Wiederaufnahme hilft dem Labor nicht, wenn später ein fachlicher Fehler auffällt. Dokumentieren Sie Zuständigkeit, Begründung und erneute Prüfung für diesen Fall.

Quellen: [1] [7] [10]

8. Projektarchiv, System Audit Trail und Wiederherstellung trennen

Ein erfolgreiches Backup-Protokoll beantwortet noch nicht, ob ein alter Analysenvorgang später vollständig geprüft werden kann. Planen Sie einen Wiederherstellungstest mit einem bearbeiteten Datensatz: mehrere Methodenstände, ein begründeter Eingriff, eine Review-Entscheidung und gegebenenfalls eine Signatur. Prüfen Sie neben der Lesbarkeit auch die fachlichen Zusammenhänge.

Für Empower 3 unterscheidet Waters beim System Audit Trail das binäre .maa-Format von einem Textexport: Nur die binäre Variante lässt sich in die Offline System Audit Trails zurückspielen. Dieses Verfahren ist von einem Projekt-Backup und der Wiederherstellung der Betriebsumgebung zu unterscheiden.

Eine weitere Grenze betrifft restaurierte Projekte in Empower 3 Enterprise. Laut Waters bleiben bereits in der Ursprungsfassung vorhandene Audit-Trail-Einstellungen grundsätzlich die Einstellungen des gesicherten Projekts. Eine heutige System Policy repariert also nicht automatisch eine früher unzureichende Erfassung. Prüfen Sie ältere Projekte bewusst und dokumentieren Sie erkannte Nachweislücken.

Quellen: [6] [5] [7]

9. Gerätequalifizierung, Softwareprüfung und Upgrade abgrenzen

Die Qualifizierung eines chromatografischen Geräts, die Prüfung der Softwareinstallation und die Eignung Ihres Laborablaufs betreffen unterschiedliche Fragen. Ein nachgewiesener Pumpenfluss erklärt keine Berechtigung zur nachträglichen Ergebnisänderung. Ein erfolgreich getesteter Review-Workflow belegt umgekehrt keine Eignung des Detektors. Ordnen Sie vorhandene Lieferantennachweise den konkreten Anforderungen zu und ergänzen Sie die verbleibenden Lücken.

Vor einem Upgrade braucht das Team eine bewertete Änderungsliste: Welche verwendeten Funktionen, Treiber, Berechnungen, Reports und Datenbestände sind betroffen? Wählen Sie daraus repräsentative Regressionstests. Bei individuellen Berechnungen oder Schnittstellen sollten bekannte Eingaben und erwartete Ausgaben verfügbar sein.

Der Aufwand entsteht vor allem durch Varianten und fehlende Ausgangsnachweise: uneinheitliche Projektvorlagen, zahlreiche Methoden, Sonderrechte, individuelle Felder, Datenmigration und unklare Review-Regeln. Ein kleines, sauber beschriebenes System lässt sich anders planen als ein historisch gewachsener Laborverbund. Eine pauschale Dauer aus der Anzahl der Arbeitsplätze abzuleiten wäre deshalb wenig belastbar.

Quellen: [7]

10. Checkliste für die gemeinsame Vorbereitung

Laborleitung, Systemverantwortlicher, QA und IT sollten vor der Testplanung dasselbe Bild von Umfang und Verantwortlichkeiten haben. Lassen Sie fehlende Entscheidungen als Aufgaben sichtbar werden, statt sie im Testprotokoll stillschweigend zu ergänzen. Die folgende Liste ist eine Vorbereitungshilfe, kein universelles Pflichtpaket.

• Versions- und Geräteübersicht mit Betriebsform, Treibern und relevanten Schnittstellen erstellen.
• Eine repräsentative Analyse samt Originaldaten, Methodenständen und Ergebnisbericht bereitstellen.
• Rollen und tatsächlich mögliche Bearbeitungswege aufnehmen; administrative Aufgaben zuordnen.
• Gültige Integrations-, Reprocessing- und Review-Regeln mit dem Labor abstimmen.
• Projektvorlagen, Full-Audit-Trail-Einstellungen und verwendete View Filter erfassen.
• Freigabe-, Korrektur- und Eskalationsweg einschließlich Stellvertretung benennen.
• Archivumfang, Wiederherstellungsumgebung und Verantwortlichkeit für alte Projekte klären.
• Vorhandene Nachweise, offene Abweichungen und relevante Release-Hinweise gemeinsam bewerten.

Quellen: [7]