Empower Audit Trail Review: Umfang, Zuständigkeit und Nachweis

1. Reviewauftrag und Empower-Version eindeutig festlegen

Ein Empower Audit Trail Review sollte mit einer klaren Frage beginnen: Prüfen Sie die Entstehung eines bestimmten Analysenergebnisses oder den kontrollierten Betrieb des Systems über einen Zeitraum? Beide Aufgaben können zusammenhängen, haben aber unterschiedliche Datenmengen, Anlässe und Verantwortliche. Der allgemeine Empower-Systemleitfaden behandelt den Validierungsumfang; hier geht es um die laufende Bewertung konkreter Aufzeichnungen.

Der regulatorische Referenzeinsatz ist die Qualitätskontrolle von Humanarzneimitteln. Die GMP-Leitlinie Annex 11 nennt regelmäßige Audit-Trail-Prüfungen im risikobezogenen GMP-Kontext. Im US-Arzneimittelbereich sind zusätzlich die einschlägigen Laboraufzeichnungspflichten zu beachten. Part 11 betrifft elektronische Aufzeichnungen und Signaturen innerhalb seines Geltungsbereichs und ist keine pauschale Zulassung für ein Chromatographiedatensystem.

Halten Sie Ihre installierte Empower-Version, Projektart, Audit-Trail-Einstellungen und Benutzerrechte fest. Die folgenden Funktionsbelege beziehen sich unter anderem auf Empower 3.8.0 und 3.9.0. Das sind belegte Referenzstände, keine Behauptung zur neuesten verfügbaren Version oder zu jeder Kundeninstallation. Eine Arbeitsanweisung muss zu Ihrem tatsächlichen Stand passen.

Quellen: [10] [11] [12] [13] [7] [9]

2. Datenaufzeichnung und Änderungsnachweis auseinanderhalten

Die Datenaufzeichnung beschreibt die Untersuchung und ihr Ergebnis. Der Audit Trail liefert den Zusammenhang relevanter Aktionen und Änderungen. Er ersetzt weder Chromatogramm noch Methodenparameter, Berechnung oder fachliche Beurteilung. Umgekehrt zeigt ein plausibles Chromatogramm allein nicht, ob zuvor andere Ergebnisse erzeugt oder entscheidende Einstellungen verändert wurden.

Für den Review empfiehlt sich folgende eigene Arbeitsmatrix. Sie hilft, vorhandene Nachweise zuzuordnen und Lücken zu erkennen. Eine Zeile bedeutet nicht, dass alle Informationen aus einem einzigen Empower-Bericht stammen müssen. Entscheidend ist ihre nachvollziehbare Verbindung mit dem betrachteten Vorgang.

Quellen: [2] [3] [4] [1] [12]

3. Vom Result Set zur vollständigen Prüfpopulation gelangen

Beginnen Sie mit den Proben und Injektionen, die nach dem Prüfauftrag zu erwarten sind. Ordnen Sie das gewählte Result Set dieser Erwartung zu. Prüfen Sie auch, ob abgebrochene, wiederholte oder anders verarbeitete Vorgänge für die Bewertung relevant sind. Wer ausschließlich das vorgelegte Endergebnis betrachtet, kann die Vollständigkeit der Auswahl nicht aus diesem Endergebnis selbst ableiten.

Der Result Audit Viewer führt zu einem Result Set Informationen aus Projekt-, Methoden-, Proben- und Sample-Set-Historien zusammen. Waters zeigt darin den Vergleich früherer, ersetzter Ergebnisse und mehrerer Methodenversionen. Im dokumentierten Beispiel begrenzt ein Datumsfilter die zunächst angezeigte Historie auf drei Monate. Ein leerer Ausschnitt ist deshalb kein Beleg für eine ereignislose Vergangenheit.

Dokumentieren Sie Filter, Zeitraum und Auswahl so, dass ein zweiter Prüfer den Umfang reproduzieren kann. Gleichen Sie relevante Vorgänge mit dem Project Audit Trail ab, wenn die Frage über das einzelne Ergebnis hinausgeht. Besonders bei alten Datensätzen oder späterer Wiederverarbeitung muss der betrachtete Zeitraum zur Entstehungsgeschichte passen. Eine gespeicherte Ansicht ist hilfreich, ihre Eignung bleibt zu prüfen.

Quellen: [4] [2] [14]

4. Reintegration fachlich beurteilen, nicht nur zählen

Eine manuelle Reintegration kann fachlich begründet sein. Für ihre Bewertung benötigen Sie den Anlass, die geltende Integrationsregel, den Eingriff und dessen Auswirkung. Vergleichen Sie das Ausgangsergebnis mit dem späteren Ergebnis und prüfen Sie, ob dieselbe Begründung bei vergleichbaren Peaks konsistent angewendet wurde. Ein Kommentar wie „korrigiert“ erklärt die analytische Entscheidung meist nicht ausreichend.

Verwechseln Sie dabei einen Ereignisnamen nicht mit einem fertigen Befund. Waters erläutert für Empower 3, dass Created Manual Result beim individuellen Verarbeiten von Injektionen in Review erscheinen kann. Der Eintrag beweist daher für sich allein weder einen manuell verschobenen Peak noch eine unzulässige Ergebnisänderung. Die Bewertung muss am konkreten Datensatz erfolgen.

Im FDA-Arzneimittelkontext erläutert die Data-Integrity-Guidance, dass bei erneut verarbeiteter Chromatographie nicht nur das letzte Ergebnis aufbewahrt werden soll. Erhalten Sie die benötigte Ergebnisgeschichte über die maßgebliche Aufbewahrungsdauer und begründen Sie die Verwendung beziehungsweise Nichtverwendung von Resultaten. Eine nachträgliche Reintegration darf eine erforderliche Untersuchung eines ursprünglichen OOS-Ergebnisses nicht still ersetzen.

Quellen: [5] [14] [15]

5. Methodenstände und Zeitangaben richtig zuordnen

Ein Methodenname ist für den Review oft zu grob. Klären Sie, welcher konkrete Stand der Verarbeitung zugrunde lag und welche Änderungen gegenüber dem vorherigen Stand relevant sind. Waters beschreibt für Method Audit Trails die Versionsgeschichte sowie den Vergleich von Methodenparametern. Der Vergleich zeigt einen Unterschied; ob dieser fachlich angemessen und freigegeben war, beurteilen Sie anhand Ihres Methodenverfahrens.

Berücksichtigen Sie neben der Processing Method die für den Vorgang relevanten weiteren Methoden und Einstellungen. Eine geänderte Ausgabedarstellung kann Informationen verbergen, obwohl sich die Berechnung nicht ändert. Ebenso kann eine neue Berechnung andere Ergebnisse erzeugen, ohne dass sich die Rohdaten ändern. Halten Sie solche Unterschiede in der Befundbeschreibung auseinander.

Auch Zeitstempel benötigen ihren technischen Kontext. Waters dokumentiert für individuell in Review verarbeitete Empower-3-Ergebnisse eine Konstellation, in der der Ergebniszeitpunkt vor dem später gespeicherten Methodenstand liegt. Das kann durch Erzeugung und gemeinsames Speichern erklärbar sein. Prüfen Sie daher Ereignisbedeutung und Arbeitsfolge, bevor Sie aus einer ungewöhnlichen Reihenfolge einen Manipulationsvorwurf ableiten.

Quellen: [3] [6] [12]

6. Den System Audit Trail als eigenen Kontrollbereich planen

Der System Audit Trail erfasst systemweite Tätigkeiten, etwa An- und Abmeldungen sowie das Erstellen, Ändern oder Löschen von Benutzern, Projekten und Systemobjekten. Waters nennt dafür das Recht View System Audit Trails. Ein Laborprüfer mit Zugriff auf Projektdaten hat damit nicht automatisch den vollständigen Auftrag oder die erforderlichen Rechte für diesen Kontrollbereich.

Legen Sie fest, wer welche Ereignisse bewertet und welche Information das Labor bei einem möglichen Datenbezug erhält. Beispielsweise kann eine unerwartete Änderung an einem Benutzer oder ein wiederhergestelltes Projekt eine Rückfrage zum betroffenen Analysenzeitraum auslösen. Der Systemverantwortliche klärt den technischen Ablauf; der fachliche Prüfer bewertet mögliche Folgen für die konkreten Aufzeichnungen.

Wählen Sie Zeitraum und Ereignisfilter begründet. Ein monatlicher oder jährlicher Rhythmus ist keine universelle Vorgabe für alle Ereignisse. Datenbezogene Prüfungen gehören zum jeweiligen Aufzeichnungsreview; systemweite Auffälligkeiten können zusätzlich eine sofortige Bewertung verlangen. Halten Sie Routineumfang, ereignisbezogene Eskalation und Vertretung fest. Die periodische Bewertung des gesamten Systems ist wiederum ein eigener Prozess.

Quellen: [1] [10] [14]

7. Illustratives Reviewbeispiel: Eine nachträgliche Peakbewertung

Das folgende Beispiel ist konstruiert und dient als Arbeitshilfe. Es beschreibt weder einen Kundenfall noch einen ausgeführten Test. In einem Result Set mit Standards und Proben wurde ein Ergebnis nach der ersten Verarbeitung erneut gespeichert. Als Grund steht eine Anpassung der Peakgrenze. Der Prüfer muss entscheiden, ob die Änderung nachvollziehbar ist und welche Ergebnisse für die Auswertung maßgeblich sind.

Das Reviewprotokoll verweist auf Projekt, Sample Set, Result Set, betroffene Injektion sowie alte und neue Ergebniszuordnung. Die tatsächlichen Kennungen werden im Betrieb eingetragen. Für das Beispiel werden keine erfundenen Messergebnisse oder verbindlichen Akzeptanzgrenzen vorgegeben; diese stammen aus der eigenen analytischen Methode.

Quellen: [4] [3] [15] [12]

8. Was Reviewkennzeichen und Sign-off tatsächlich aussagen

Empower 3.8.0 führte eine Systemrichtlinie für die Bestätigung geprüfter Audit-Trail-Aufzeichnungen beim Sign Off 2 ein. Laut Release Notes ist sie zunächst deaktiviert und gilt für Standardprojekte mit Full Audit Trail. Für die Auswahl benötigt der Unterzeichner außerdem die genannten Rechte für Project Audit Trail und Sign Off Level 2. Ein dokumentierter Funktionsname bedeutet deshalb noch keine aktive Kontrolle in Ihrer Installation.

Die Ergebnisanzeige beschreibt eine mindestens einmal abgegebene Bestätigung. Sie prüft nicht selbst, ob der Mitarbeiter die richtigen Daten ausgewählt, relevante Ereignisse verstanden und offene Fragen bearbeitet hat. Legen Sie fest, wo Reviewumfang und Befunde dokumentiert sind und wie sie zum bestätigten Ergebnisstand gehören. Prüfen Sie insbesondere die Bedeutung der Anzeige bei späterer Verarbeitung oder einem zusätzlichen Sign-off.

Waters beschreibt Ergebnis-Sign-off über Report Publisher und dessen Bedingungen. Auch die nach Sign Off 2 mögliche Kanalsperre hängt von Einstellungen und Auswahl ab. Leiten Sie aus einer Unterschrift daher keine universelle Unveränderlichkeit sämtlicher Projektdaten ab. Für FDA-relevante elektronische Signaturen bleiben Identität, Bedeutung und Verbindung zum Aufzeichnungsstand eigenständig zu betrachten.

Quellen: [7] [8] [13]

9. Befunde, Zuständigkeiten und Aufwand steuerbar machen

Beschreiben Sie eine Auffälligkeit zunächst neutral: betroffener Datensatz, beobachtete Aktion, Zeitpunkt, erklärter Grund und noch offene Frage. Eine ungewöhnliche Änderung ist weder automatisch Betrug noch OOS. OOS bezeichnet Ergebnisse außerhalb festgelegter Spezifikationen oder Akzeptanzkriterien. Ein Berechtigungsfehler, eine fehlende Begründung und ein OOS-Ergebnis können miteinander zusammenhängen, benötigen aber eine sachlich passende Bearbeitung.

Der Prüfer braucht analytische Fachkenntnis, Zugang zu den relevanten Aufzeichnungen und Kenntnis der verwendeten Empower-Funktionen. Der Administrator unterstützt bei technischen Fragen und Berechtigungen. QA definiert mit dem Labor die erforderliche Kontrolle und Eskalation. Im Anwendungsbereich von 21 CFR 211.194 ist der Review der Originalaufzeichnungen durch eine zweite Person ausdrücklich vorgesehen; daraus folgt keine pauschale Gleichsetzung dieser Person mit dem Systemadministrator.

Der Aufwand hängt von Datenmenge, Wiederverarbeitungen, Methodenvielfalt, Filterqualität und offenen Fragen ab. Erproben Sie Ihren vorgesehenen Ablauf deshalb mit einem repräsentativen Datenpaket. Empower 3.9.0 verändert die Sichtbarkeit bestimmter quantitativer Informationen bei eingeschränkten Rechten abhängig davon, ob ein Ergebnis gespeichert ist. Prüfen Sie solche Versionsunterschiede bei Rollenwechseln, Schulungen und Updates gezielt, statt unveränderte Bedienbarkeit anzunehmen.

Quellen: [15] [12] [9]

10. Checkliste für einen nachvollziehbaren Reviewabschluss

Die folgende eigene Checkliste hilft beim Einrichten und Erproben des Verfahrens. Sie ergänzt Ihre analytischen und qualitätsbezogenen Anforderungen; sie ist keine vollständige SOP für jedes Labor.

• Projekt, Probenumfang, Result Sets und betrachteter Zeitraum sind eindeutig benannt.
• Die installierte Version, Audit-Trail-Einstellungen und erforderlichen Rechte sind bekannt.
• Rohdaten, Methodenstände, Berechnungen und Ergebnisgeschichte sind fachlich zugeordnet.
• Verwendete Filter schließen relevante frühere Vorgänge nicht unbeabsichtigt aus.
• Reintegration und andere Ergebnisänderungen besitzen eine prüfbare Begründung.
• Systemweite Ereignisse mit Datenbezug werden an die zuständigen Prüfer übergeben.
• Auffälligkeiten werden neutral beschrieben und passend untersucht.
• Offene Fragen besitzen Verantwortliche und eine Entscheidung über die weitere Verwendung der Daten.
• Reviewnachweis und Sign-off beziehen sich auf einen eindeutig bestimmten Stand.
• Das Verfahren wird bei relevanten Versions-, Rollen- oder Prozessänderungen überprüft.

Quellen: [10] [12] [4] [8]