What an Inspector Does With an Audit Trail

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

Understanding how an audit trail is actually used changes what you do with it in advance.

An inspector does not read a trail linearly. They query it, looking for patterns that are difficult to produce by legitimate work, and the patterns they look for are well known and stable. Knowing them lets you look first.

The patterns they look for

Changes close to database lock. The period before lock is when the incentive to make data agree with expectations is highest and the opportunity for scrutiny is lowest. A concentration of changes there attracts attention regardless of their content.

Changes to endpoint data after anyone could know the trend. In an unblinded study this is any point at which results are visible. In a blinded study it is after an interim analysis or any partial unblinding. Changes to the variable the study is about, made by people who could know how it is going, are the highest-scrutiny category that exists.

Bulk changes. Many records altered in a short window by one user. Frequently legitimate and always examined, because it is the shape of a systematic alteration as well as of a systematic correction.

Reasons that are not reasons. A trail where 90 percent of changes carry the reason "data entry error" tells the inspector that the reason field is not being used meaningfully, which weakens every entry in it including the informative ones.

Deletions, and records that exist in one place and not another. Anything suggesting a record ceased to exist.

Changes by users who should not have been involved. A monitor changing data. A user changing data for a site they have no connection to. A change dated outside a person's period of involvement.

Timestamps that cannot be right. Entries recorded at times the site was closed, or several visits recorded within a few minutes, which indicates batch entry from an earlier record and therefore a contemporaneity question.

What they conclude, and from what

The inference is rarely "this value is wrong." It is usually one of:

"This value is not reliable", because its history shows it was changed without adequate reason.

"This process is not controlled", because a pattern appears that no controlled process would produce.

"This organization does not review its own trail", which is inferred when the inspector finds something obvious that nobody internally had noticed. This last inference is the most damaging, because it applies to everything else the organization says about its own quality.

The countermeasure

Run the inspector's queries yourself, periodically, and write down what you found and what it meant.

The value is not merely in the findings, though there will be findings. It is that when an inspector asks about a cluster of changes, the answer is a dated document produced before they arrived, which demonstrates the quality system working rather than the sponsor explaining after the fact.

Documenting legitimate bulk operations in advance is the specific habit worth building. A bulk correction with a written rationale, an approval, and a post-check confirming it did what was intended is a controlled activity. The identical technical operation without those three things is indistinguishable from an uncontrolled one.

In practice

A data manager institutes a quarterly trail review with five standing questions: changes to primary endpoint fields, bulk operations over 20 records, changes by users outside their site, reason codes with no detail, and changes within 30 days of any planned lock.

The first review takes two days and finds four things worth acting on. Each subsequent review takes half a day, because the process issues found in the first review stopped generating the patterns.

At inspection, the reviews are produced as a series of dated documents covering two years.

The inspector's own trail queries find nothing the reviews had not already identified and addressed. That outcome is not luck; the reviews asked the same questions.

The difference this makes is not that the study had fewer problems. It is that every problem was found internally first, which is the distinction between a quality system that works and one that exists.

What this looks like when it goes wrong

An inspector queries a study's trail and finds 1,900 changes made in the four days before database lock, across 30 sites, by six sponsor users.

Every change is legitimate. They are the resolution of the final query batch, entered by the data management team because the sites had answered by email rather than in the system, which is how this sponsor has always closed out a study.

The sponsor's explanation is true and cannot be evidenced. The email answers were not retained systematically, the audit trail reason on each change is "per query" with no query identifier, and no document describes the close-out process as a planned activity.

What the inspector sees is 1,900 changes to a study's data, in the four days before lock, made by the sponsor rather than the sites, with no supporting record. The finding is severe, the underlying conduct was honest, and there is no way to demonstrate it after the fact.

Key takeaways