Work Instruction: Live Lot Trace of a Chromatography Data System During an Inspection

This is a ready-to-use work instruction for the single exercise an inspector runs most often against a laboratory system: name a released lot and trace it end to end through the chromatography data system (CDS), at the keyboard, watching the analyst. It is written to be rehearsed in a mock and then performed live. Replace every <<FILL: ...>> placeholder with your own specifics and route it through your normal document control. A worked filled specimen follows. This is a task-level instruction under a parent inspection-management procedure; verify each cited regulation against the current source before you rely on it. The concept behind the exercise is in inspection readiness and chromatography data system integrity.

Document control header

1. Purpose and when to use

Use this instruction when an investigator selects a released lot and asks to see how a result was generated, reviewed, and controlled in the CDS, or when rehearsing that scenario in a mock inspection. The objective is to demonstrate, not describe: the analyst shows the data live, and the record supports every claim without hunting. A trace that can only be narrated, not shown, reads to an inspector as a control that is not actually operating.

2. Before you touch the keyboard

• The analyst performing the trace uses their own unique login, never a shared or generic account.
• Read-only navigation is preferred; do not create, edit, reprocess, or delete anything during the demonstration.
• Have the paper or electronic batch record for the lot open in parallel, so the CDS and the record can be reconciled in front of the inspector.
• If a question requires an action you are not authorized to perform (for example changing a configuration), say so and route it to the system owner rather than improvising.
• Never alter, complete, or “tidy” a record because the trace exposed a gap. A gap found honestly is a deficiency; a gap edited during an inspection is a potential data integrity finding.

3. The trace, step by step

Perform the steps in order. Each has an acceptance line (“good looks like”) and the finding pattern it guards against.

Step 1: Open the sequence for the named lot

1. Log in with your own credentials and navigate to the project, instrument, and sequence for the lot the inspector named.
2. Show the sequence on screen and confirm it matches the lot and the method stated in the batch record.

Good looks like: the analyst reaches the sequence without hunting, and the sequence, method, and lot agree with the batch record. Finding pattern: the analyst cannot locate the data, or the sequence does not match the record.

Step 2: Account for every injection

1. Display the full injection list for the sequence, including standards, samples, blanks, and any aborted, repeated, renamed, or “trial” injections.
2. For each non-standard injection (a re-injection, an abort), show the documented reason linked to the batch record, a deviation, or a notebook entry.

Good looks like: every injection is accounted for, and each re-injection or abort has a documented, pre-approved reason. Finding pattern: injections that exist in the system but not in the record, aborted runs with no explanation, or “test” injections of real samples.

Step 3: Show the integration and its audit trail

1. Open the result and the audit trail for the integration.
2. Show the original integration, any reprocessing or manual integration, who performed each, when, and the prior values retained.
3. For any manual integration, show the approved, documented scientific justification.

Good looks like: the audit trail captures who, what, when, and the prior value for every change, and no manual integration exists without an approved reason. Finding pattern: manual integration with no justification, reprocessing with no reason recorded, or an audit trail that does not retain prior values.

Step 4: Show the review of the result and of the audit trail

1. Show the second-person review record for the result: who reviewed, when, and against which procedure.
2. Show the evidence that the audit trail itself was reviewed, not just the result.

Good looks like: both the result review and the audit trail review are evidenced with attributable, dated records. Finding pattern: review claimed by procedure but with no record that critical entries were examined, or the same person generating and reviewing with no independent check.

Step 5: Show that permissions match the role

1. Show the role-based access setting for the analyst account: that create, reprocess, and delete privileges are restricted to what the role requires.
2. Confirm no shared or generic accounts are in use on the system.

Good looks like: the analyst does not hold privileges they should not have, and every action on the system is attributable to a named person. Finding pattern: shared logins, or ordinary users able to delete data or change the system clock.

Step 6: Reconcile and close the trace

1. Confirm the reported result in LIMS or on the certificate matches the CDS result and the batch record.
2. If the trace surfaced anything unexplained, note it honestly for follow-up; do not resolve it by editing the record.

Good looks like: the number on the certificate traces cleanly back to the raw data with no unreconciled step. Finding pattern: a reported value that cannot be tied to the underlying data, or an unexplained difference between systems.

4. Acceptance criteria

The trace is acceptable when all of the following hold:

• Every injection in the sequence is accounted for and every re-injection or abort has a documented, approved reason.
• Every audit-trail change retains its prior value and carries an attributable, dated identity and reason.
• The result review and the audit-trail review are both evidenced, by someone other than the person who generated the data.
• Access privileges match the role, with no shared accounts and no unauthorized delete or clock-change rights.
• The reported result reconciles end to end with the raw data and the batch record.
• Nothing was created, edited, reprocessed, or deleted during the demonstration.

5. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic equipment) and 211.194 (laboratory records). EU GMP Annex 11 (computerised systems), including audit trail expectations. FDA guidance, Data Integrity and Compliance With Drug CGMP (2018). MHRA GXP Data Integrity Guidance and Definitions (2018); PIC/S PI 041 (2021).

Confirm the current version and clause numbers of each reference before issue.

6. Filled specimen

The following shows the trace performed for an example lot, so you can see the level of detail expected. The company, system, and numbers are illustrative; replace them with your own.

In this example the analyst reached every screen without searching, every injection was accounted for, the one manual integration carried an approved reason, and the reported number tied back to the raw data. That fluency, at the keyboard, on a real lot, is what the mock rehearsal is meant to build.

7. Common inspection findings this instruction prevents

• The analyst cannot navigate their own system to the data an inspector named.
• Injections exist in the CDS that never appear in the batch record, with no reconciliation.
• A manual integration or reprocessing has no recorded, approved reason.
• Audit trail review is required by procedure but there is no evidence critical entries were examined.
• Shared or generic logins break attributability at the root.
• A record is edited or completed during the inspection to close a gap the trace exposed.

8. How to adapt this instruction

1. Set your document number, parent SOP, and owner in the header.
2. Replace the CDS-specific navigation language with your actual system’s terms and screens.
3. Point the cross-references to your real deviation, review, and access-management procedures.
4. Rehearse it on genuine released lots in a mock inspection; the exercise only builds fluency if the data is real.
5. Confirm every regulation in section 5 against the current published version before issue.