Audit Trail Review for Chromatography Data Systems

An audit-trail review of a chromatography data system checks that every change to data and processing was authorised, explained and visible: reintegrations, reprocessing, aborted and repeated injections, deletions, edits to methods and sequences, and changes to the system's own configuration. It is performed by the person who reviews the results, before the results are relied upon, and its frequency is set by the criticality of the data. FDA's 2018 data-integrity guidance defines the audit trail for an HPLC run as including the user name, date and time of the run, the integration parameters used and details of any reprocessing, with the justification 1.

The companion page on ALCOA+ sets out the principles and the page on system suitability covers the checks made on each run. This page is the review procedure. It is written for a laboratory working to good-practice expectations on its own research data, using the regulators' documents as the reference for what a sound review looks like.

What an audit trail records and what it does not

The MHRA describes the audit trail as metadata that records actions relating to the creation, modification or deletion of records, secured against overwriting, and sufficient to reconstruct the history of an event including who, what, when and why 4. FDA uses the same sense: a secure, computer-generated, time-stamped electronic record that allows reconstruction of the course of events 1. Two limits follow. The trail records what the system saw. Work done outside it, such as peaks integrated on a printout, injections discarded from a vial before the sequence was started, or samples prepared and thrown away, leaves no entry. And a trail that has been configured not to record a class of event shows nothing for it.

The MHRA also notes that the audit trail review does not need to include every system activity: user log-on and log-off or keystrokes are not usually relevant 4. The skill is in knowing which entries matter. PIC/S puts it as an assessment, done during qualification, of the different audit trails in the system, so that the relevant ones and the entries of significance within them are known and a review frequency is established 3.

Enabling and locking the audit trail before acquisition

Annex 11 asks that consideration be given, based on risk assessment, to building into the system a record of all GMP-relevant changes and deletions, with the reason documented for any change or deletion, available in a generally intelligible form, and regularly reviewed 2. PIC/S states the expectation more strongly: audit trail functionality should be enabled and locked at all times, and if an administrator can deactivate or modify it, an automatic entry should record that it happened 3. The MHRA expresses the same view: the trail is switched on, users cannot amend or switch it off, and an administrator's action on it is retained 4.

1. Verify before the system is used for any real data that the audit trail is enabled for every project, instrument and method type, and record the configuration screen.
2. Restrict the privilege to alter audit-trail settings to a named administrator role that does not run samples.
3. Confirm that every user has a unique login. FDA says shared accounts defeat attribution; a shared read-only account is acceptable for viewing but not for actions that must be attributable to a person.
4. Require a reason for each change to integration or processing, as a controlled text or a pick-list, and confirm that the system prompts for it.
5. Confirm the clock source and time-zone setting, and put a date and time check in the monthly system check.
6. Test that the trail captures a deliberate change: reintegrate a test chromatogram, delete a test injection, edit a test method. Keep the evidence with the validation record.

Review by exception versus reading every entry

PIC/S lists two reasonable focuses for a review: entries that relate to changes or modifications of data, and review by exception, which concentrates on anomalous or unauthorised activity 3. The MHRA defines an exception report as a validated search tool that identifies and documents predetermined abnormal data or actions requiring further attention by the data reviewer 4. The essential words are validated and predetermined. A report written for convenience and never tested against a known change is not evidence that nothing happened.

A small laboratory running a few sequences a week will often read the sequence-level trail in full, since it is short. A larger programme will define exceptions and read everything the exception report flags. PIC/S also notes that well-designed systems with permission settings that prevent changes to data or configuration may reduce the need for detailed examination of related trails 3. That relief is earned by demonstrating that the permissions work, not assumed from the vendor's brochure.

The checklist: integration, reprocessing, aborted runs, deletions

Who reviews: independence and competence

FDA says that audit-trail review is similar to assessing cross-outs on paper: the personnel responsible for record review under CGMP review the audit trails as they review the rest of the record, and the quality unit approves the whole, including the trail 1. PIC/S adds that the audit trail review should be part of the routine data review within the approval process 3. The MHRA expects reviewers to have enough knowledge and system access to review the relevant audit trails, raw data and metadata 4.

In a laboratory with few staff, the practical rules are: the reviewer is not the analyst who acquired or processed the data; the reviewer can open the original data, the processing history and the trail without asking the analyst to show them; and the reviewer has been trained on what a reintegration looks like in the software in use. Where only one person is qualified, a second person from another area, or the supervisor, reviews that person's data on a rota. Record the training.

Frequency by risk: per batch, periodic, annual

FDA's answer on frequency is that if the data review frequency is set in the regulations, the audit trail follows it, and otherwise the frequency is determined from knowledge of the process and a risk assessment that includes data criticality, control mechanisms and effect on product quality 1. PIC/S gives the example that where changes to electronic data can directly affect product quality, the trail is expected to be reviewed before the data are relied upon to make a critical decision, and it records the frequency of audit-trail review among the items a validation summary should state 3.

Documenting the review and escalating findings

PIC/S expects an SOP that describes in detail how to review audit trails, what to look for and how to search, and requires that the review activity be documented and recorded. Any significant variation from the expected outcome is to be fully investigated and recorded, and a procedure should say what happens when a review finds serious issues 3. The review has no value if it leaves nothing to inspect.

1. Identify the data set: study or batch, sequence name, instrument, date range, analyst.
2. Open the original data and the audit trail for the sequence and confirm both cover the full range of injections. Record the software version.
3. Work through the checklist in order and mark each line as no entry, entry reviewed and acceptable, or entry requiring action. Note the entry identifier for each action.
4. For each reintegration or reprocessing, compare the first and the final chromatogram and write one line on whether the final one is justified by the method.
5. Reconcile the injections in the trail with the sequence plan and the notebook. Account for every injection, including aborted ones.
6. Resolve every action line with the analyst in writing, or open a deviation. Do not sign until each line is closed or escalated.
7. Sign and date the review with name, role, date, time and the version of the SOP followed. File it with the data set.
8. Send findings that affect results, show an unexplained deletion or disabled trail, or suggest intent to the quality unit the same day.

A usable form has fields for the data set, reviewer, date, checklist outcome by line, entries requiring action, resolution, deviation number, second-person sign-off for anything escalated, and the SOP version. Keep it in the same system that holds the results where possible; a paper form that nobody can match to a data set is not a record.

Common inspection findings and how to avoid them

The Part 11 scope guidance from FDA, issued in 2003, gives enforcement discretion on some Part 11 audit-trail requirements but states that predicate rules on recording dates, times and sequence of events still apply and that audit trails or other controls should be decided on a documented risk assessment. It does not remove the expectation that a laboratory can show who changed what, and when 5. The review procedure above is the means of showing it.