What an Audit Trail Must Record

Part of Clinical Data Management and Integrity: Audit Trails and Electronic Records.

About 5 minutes. Free, in your language, no account needed.

Why this matters

An audit trail is what makes an electronic record trustworthy. Without one, a database is a set of current values with no history, and there is no way to distinguish a value that was entered correctly from one that was changed three times to reach its present state.

The distinction matters because the pattern of changes is frequently more informative than the values themselves. An inspector reviewing an audit trail is not usually checking whether values are right. They are looking at what the history of changes says about how the study was run.

What it must capture

The original value and the new value. A trail recording that a field changed, without recording what it changed from, cannot reconstruct the record and is of limited use.

Who made the change, identified as a person rather than a role or a shared account.

When, with a timestamp whose time zone and source are known. A trail using each user's local clock, unreconciled, cannot order events across sites reliably.

Why. A reason for change, and this is where trails most often fail in substance while passing in form. A system that requires a reason and offers a dropdown whose first option is "data entry error" will record "data entry error" for almost everything, including changes that were nothing of the kind.

What was created and deleted, not only what was modified. A record created and then removed must leave a trace, or deletion becomes a way of making things not have happened.

Properties it must have

It must be automatic. A trail that depends on a user choosing to record a change records only the changes people wanted recorded.

It must be secure. Not modifiable by the people whose actions it records, including system administrators acting in their ordinary capacity.

It must be retained as long as the record, which is where migrations quietly destroy trails while preserving data.

It must be reviewable. A trail that exists but can only be produced as an unfiltered export of several million rows is technically compliant and practically useless. Review requires the ability to ask focused questions of it.

Audit trail review, which is a real activity

Having a trail is not the obligation. Looking at it is.

Meaningful review asks questions the values alone cannot answer.

Changes made shortly before database lock, which deserve attention because the incentive structure around lock is unlike any other point in the study.

Changes to data feeding the primary endpoint, particularly any made after the point at which anyone could know how the study was trending.

Repeated changes to the same field, which usually indicate either a genuine uncertainty or a form that cannot express what the site is trying to record.

Changes by unexpected users: someone changing data for a site they are not associated with, or outside the period of their involvement.

Changes clustered in time, which can indicate a bulk operation that was not documented as one.

In practice

A data manager runs a routine trail review two months before lock, which is the first such review the study has done, and that is itself the finding.

She asks four questions of it. Changes to primary endpoint fields after entry: 31, of which 29 have documented query resolutions and 2 do not. Changes by users not associated with the site: 14, all by one data manager during a documented bulk correction, though the correction itself was not recorded anywhere the trail points to. Fields changed more than twice: 6, of which 4 are the same field at the same site, suggesting a form problem nobody reported. Changes with the reason "other" and no free text: 212.

None of these is misconduct. Each is a thread worth pulling, three of them lead to process improvements, and the two undocumented primary endpoint changes turn out to be a legitimate correction whose documentation was filed against the wrong participant.

Every one of these would have been an inspector's question. All of them are now answered, in a document, dated before the inspection.

What this looks like when it goes wrong

A study's electronic data capture system has a complete, secure, automatic audit trail. Every requirement is met.

Nobody ever looks at it.

At inspection, the inspector does look, and asks about a cluster of 340 changes made over two days, six weeks before database lock, to laboratory values across eleven participants at four sites, all by the same user.

The explanation is entirely innocent: a unit conversion error was discovered and corrected in bulk, which was the right thing to do.

The sponsor cannot demonstrate this. The bulk correction was not documented as a planned activity, no approval exists, the reason recorded on each change is "data entry error," which is not what happened, and nobody reviewed the trail afterwards to confirm the correction did what was intended.

A correct action, correctly executed, is indistinguishable in the record from the thing an inspector is most alert to: bulk changes to data shortly before lock. The trail existed and was never used, and the one time it mattered it was read first by the inspector.

Key takeaways