Audit Trail Review im CDS: Beispiele, Prioritäten und Entscheidungen

Der Audit-Trail-Bericht zeigt keine Auffälligkeiten, doch im CDS existiert eine abgebrochene Sequenz, die im Bericht fehlt. Sorgfältigeres Lesen der Zeilen allein reicht nicht: Der Review muss nachweislich die relevante Historie abdecken. Verfügbare Aufzeichnung, durchgeführter Review und abgeschlossene Untersuchung sind drei unterschiedliche Nachweise.

1. Vom Datensatz ausgehen und Aufzeichnungen unterscheiden

Definieren Sie die durch den Review unterstützte Entscheidung und die zugehörigen Proben, Sequenzen, Injektionen, Methoden und Ergebnisse. Identifizieren Sie anschließend die erforderlichen Aufzeichnungen: Erfassung, Auswertung, Konfiguration und Sicherheit können in verschiedenen Ansichten oder Ablagen liegen. Ein Zugriffslog allein erklärt keine Integrationsänderungen; der Ergebnisbericht dokumentiert nicht jedes Ereignis.

Verknüpfen Sie bei jedem relevanten Ereignis Objektkennung, Benutzer, Datum und Uhrzeit, Aktion, vorherige und nachfolgende Werte oder Versionen sowie die entsprechende Begründung. Zeitzone und Bedeutung des Zeitstempels müssen verstanden sein; ein nach Datum sortierter Export garantiert keine richtige Chronologie.

Die allgemeinen Audit-Trail-Grundlagen werden separat erläutert. Hier geht es um den Weg eines bestimmten chromatografischen Datensatzes, ohne jedes Systemereignis als vermutete analytische Auffälligkeit zu behandeln.

2. Umfang, Verantwortung und Häufigkeit festlegen

Identifizieren Sie zunächst die anwendbaren Anforderungen an den Record-Review. Die FDA-Guidance von 2018, Q7–8, verbindet die Prüfung von Änderungen mit dem Record-Review und verlangt die Einhaltung der in relevanten CGMP-Regeln festgelegten Häufigkeiten. Wo keine Häufigkeit festgelegt ist, berücksichtigt die Risikobewertung Kritikalität, Kontrollen und Produktauswirkung. Risiko erlaubt keinen Aufschub vorgeschriebener Prüfungen.

Setzen Sie in Methode und CDS geschulte Reviewer mit ausreichendem Zugriff auf Nachweise und angemessener Unabhängigkeit von Datenerzeugern beziehungsweise Bearbeitern ein. QA muss nicht den gesamten Review selbst durchführen: Legen Sie Abteilungsaufgaben und Aufsicht der Qualitätseinheit gemäß Qualitätssystem und anwendbaren Anforderungen fest.

Trennen Sie den operationsbezogenen Review von der periodischen Bewertung von Systemereignissen, Konfigurationen und Berechtigungen. Kann ein Systemereignis den geprüften Datensatz beeinflussen, gehört es in die aktuelle Bewertung; eine Zuordnung zu einer späteren Prüfung reicht nicht. Es gibt keine für jedes CDS geeignete einheitliche Frequenz.

3. Prüfen, ob Filter und Berichte Ereignisse ausblenden

Dokumentieren Sie abgefragte Quellen, Zeitintervall, Zeitzonen, Benutzer, Projekte, Status sowie eingeschlossene und ausgeschlossene Ereignistypen. Prüfen Sie, ob nur abgeschlossene Sequenzen, genehmigte Ergebnisse oder aktuelle Versionen erscheinen. Bewerten Sie auch Seitennavigation, Exportgrenzen und die Rückverfolgbarkeit zum ursprünglichen Ereignis und Datensatz.

Ein redaktionelles Testbeispiel verwendet fünf bekannte synthetische Ereignisse: abgeschlossene Erfassung, Unterbrechung, Neuauswertung, Methodenänderung und genehmigter Rollenwechsel. Legen Sie vor der Filteranwendung fest, welche Ereignisse im Bericht erscheinen müssen und welche über eine andere Aufzeichnung geprüft werden. Vergleichen Sie erwartete und beobachtete Abdeckung und dokumentieren Sie Unterschiede, nicht nur Zeilenzahlen.

Planen Sie diesen Test in einer isolierten, genehmigten Umgebung; weder Datenlöschung noch Abschalten des Audit Trails sind erforderlich. Wiederholen Sie ihn bei Änderungen an Abfrage, Konfiguration oder Version mit Einfluss auf die Abdeckung. Review nach Ausnahmen erfordert begründete Kriterien und nachgewiesene Zuverlässigkeit: „Keine Ausnahme“ ist nur aussagekräftig, wenn die Auswahl funktioniert.

4. Jedes Ereignis mit einer Frage und Maßnahme verbinden

Diese eigenständige Matrix unterstützt den Review, ersetzt aber weder das Verfahren noch bestimmt sie das Ergebnis vorab. Ein Ereignis kann plausibel erklärt sein, weitere Informationen erfordern oder eine Untersuchung auslösen; die Softwarebezeichnung entscheidet das nicht allein.

Bei einer Neuauswertung von Peaks ist das Log zusammen mit Signal und Methode zu prüfen. Wiederholungen, Ausschlüsse und Änderungen nach dem Review brauchen Kontext. Ein fehlgeschlagener Login belegt dagegen nicht automatisch Datenmanipulation: Identität, Folgeaktivitäten und Kontrollen sind zu bewerten.

5. Simulierter Fall und Dokumentation der Schlussfolgerung

Eine Zusammenfassung zeigt eine abgeschlossene Sequenz. Der Vergleich mit der Erfassungsliste zeigt eine frühere abgebrochene Sequenz derselben Proben. Der Reviewer prüft den Filter: Er wählte nur den Status „abgeschlossen“. Beide Sequenzen bleiben erhalten; ausgeführte Injektionen, Abbruchgrund, Wiederaufnahme und verwendete Ergebnisse werden rekonstruiert.

Bei vollständiger Rekonstruktion wird die analytische Schlussfolgerung dokumentiert und der Berichtsprozess kontrolliert korrigiert. Auch möglicherweise betroffene frühere Reviews sind zu bewerten. Fehlen Daten oder Gründe, bleibt die Auffälligkeit offen und die vorgesehene Eskalation wird ausgelöst. Ein konformes Ergebnis der letzten Sequenz macht den Review nicht vollständig.

Dokumentieren Sie Umfang, Quellen, Berichtsversion oder Suchkriterien, Reviewer, Datum, geprüfte Nachweise, Fragen, Antworten, Schlussfolgerung und Untersuchungsverweise. Eine Unterschrift ohne Prüfumfang macht die Kontrolle nicht reproduzierbar. Das Schließen einer Reviewfrage beendet nicht automatisch eine Untersuchung und gibt keine Charge frei.

Bewerten Sie den Prozess periodisch neu: geänderte Filter, unbekannte Ereignisse, Schulung und wiederkehrende Probleme können Anpassungen erfordern. Bewerten Sie Qualität der Schlussfolgerungen und Abdeckung, statt Wirksamkeit nur anhand gelesener Zeilen zu messen.

6. Quellen und Anwendbarkeit

Quellenprüfung: 1.–2. Oktober 2026. GMP-Laborkontext für Humanarzneimittel; simulierte Beispiele, keine Aktivitäten an realen Systemen. Operative Details hängen vom CDS und genehmigten Verfahren ab.

• FDA — Data Integrity and Compliance With Drug CGMP, endgültige Fassung Dezember 2018, Q1c und Q7–8: Definition, Verantwortlichkeiten und Häufigkeit. Nicht bindende Guidance, zusammen mit anwendbaren CGMP-Regeln zu lesen.
• Europäische Kommission — Annex 11, Revision Januar 2011, anwendbar seit 30. Juni 2011, §§9, 12–13: Audit Trails, Sicherheit und Vorfälle. Der Vorschlag von 2025 bleibt vom verabschiedeten Text getrennt.
• PIC/S — PI 041-1, endgültige Fassung 1. Juli 2021, §9.6: Konfiguration, Verständnis und Review von Audit Trails. GMP/GDP-Inspektionsleitlinie; die obige Matrix ist eigenständig und übernimmt nicht die PIC/S-Matrix.