Work Instruction: Reviewing a Chromatography Data System Run Audit Trail

This is a ready-to-use work instruction: the task-level steps a reviewer follows to read the run audit trail in a chromatography data system during a second-person review. It sits under the parent review SOP and exists to close the single most cited laboratory data-integrity finding, that the data review did not include the audit trail. Replace every <<FILL: ...>> placeholder. A filled specimen follows. Verify each cited regulation against the current source before you rely on it.

Parent procedure and scope

• Parent SOP: <<FILL: SOP-ID for second-person review of laboratory data>>. This work instruction details step 5.2 of that SOP, the audit trail portion of the review.
• Scope: every run whose result feeds a GxP decision, reviewed in the live data system, not from a PDF report.
• Prerequisite: the reviewer has read access to the audit trail and is trained on this data system.

What you need before you start

Steps

Step 1: Open the audit trail for the specific run

Open the run, sequence, or result set in the data system and display its audit trail for the full period from acquisition to the current reported result. Do not work from the printed report; the report shows the final state, the trail shows the history.

Acceptance: the trail is displayed for the correct run and covers the entire period with no truncation.

Step 2: Confirm the trail was enabled and complete

Confirm the audit trail was on for the whole period and shows no disabled interval or gap. A gap, a disabled period, or a clock change is itself a finding to raise.

Acceptance: continuous trail, no disabled period, no unexplained gap; any gap raised as an exception.

Step 3: Read the trail chronologically against the narrative

Read the entries in time order alongside the analyst’s account of what was done. The two should agree. Flag anything in the trail that the narrative does not explain.

Acceptance: every trail event maps to the analyst’s account or is flagged.

Step 4: Flag the high-risk event types

Flag and examine each of the following:

1. Reprocessing or re-integration of a result.
2. Manual integration (baseline or peak-boundary override).
3. Deletion of data, files, injections, or a sequence.
4. Changes to sample identity, sample type, or the sequence.
5. Aborted, repeated, or renamed runs, and any “test”, “trial”, or unnamed injection.
6. Changes to the system clock, time zone, or date format.
7. Changes to a method or processing parameter after acquisition.

Acceptance: every event of these types in the period is listed.

Step 5: Judge each flagged event

For each flagged event confirm three things: a reason is recorded, the reason is scientifically acceptable (not “improved integration” or a blank field), and the event is consistent with the method and the analyst’s account. Be most skeptical of any change that moved a result toward passing, especially across a specification limit.

Acceptance: every flagged event has an acceptable recorded reason and is consistent with the record; any that does not is raised as an exception.

Step 6: Confirm the reported result traces to a clean final step

Confirm the reported result corresponds to the last legitimate processing, with no later silent edit after the value was reported.

Acceptance: the reported result traces to the final legitimate processing step.

Step 7: Record what you reviewed

On the review record, state that the audit trail was reviewed, the period it covered, the count and type of events examined, and the outcome. “Audit trail reviewed” with no scope is not enough; name the period and what was found.

Acceptance: the review record names the audit trail period, the events examined, and the outcome.

Exception handling

If any flagged event lacks an acceptable reason, is inconsistent with the record, or is a gap in the trail: record it on the review record, notify the laboratory supervisor and QA the same working day, do not accept the result, and open a deviation per <<FILL: SOP-ID for deviations>> where the event could affect the result.

References

21 CFR 211.194(a)(8) (second-person review of laboratory records for accuracy, completeness, and compliance). 21 CFR Part 11 (electronic records; audit trail).

Describe rather than reproduce the copyrighted or third-party sources: EU GMP Annex 11 (computerised systems, audit trails); MHRA GXP Data Integrity Guidance and Definitions; PIC/S PI 041; and the FDA data integrity questions-and-answers guidance, which states that a complete data review includes the audit trail and other metadata, not only the human-readable result. Confirm the current version of each before issue.

Filled specimen

The following shows the outcome recorded for an illustrative assay run. Numbers are illustrative.

Contrast with the finding this prevents: a run where the trail shows the assay first read 94.1 percent, was reprocessed twice with manual baseline drags and a blank reason field until it read 99.4, and the reviewer signed only the printed 99.4 without opening the trail. Step 4 and step 5 catch exactly that pattern.

Common findings this work instruction prevents

• The review examined the printout but never opened the audit trail.
• A reprocessing or manual integration with a blank or vague reason accepted without challenge.
• A result reported after a later silent edit, not caught because the trail was never read.
• “Audit trail reviewed” recorded with no period or scope, so it cannot be verified later.

How to adapt this work instruction

1. Name your specific data system and where its audit trail is displayed in step 1.
2. Point the parent SOP and deviation references to your real procedures.
3. If you use a validated review-by-exception filter, name it and its validation record, and adjust step 4 to the filtered view while keeping the event types.
4. Confirm each regulation reference against the current published version before issue.