QCast Episode 63: Audit Trail Review in Clinical Trials

Audit trail review is a practical part of clinical trial oversight, but the challenge is rarely the existence of the audit trail itself. In this QCast episode, co-hosts Jullia and Tom look at how teams decide what to review, how risk should shape scope and timing, and where clinical judgement is needed to interpret what the audit trail shows.

The discussion also addresses some of the operational pressure points that can make audit trail review difficult. These include distinguishing trial-level review from system-level activity, accessing metadata from external systems, deciding when review should happen, and avoiding the assumption that every unusual event represents a problem. Getting those decisions clear helps keep the process focused on information that can actually support action.

🎧 Listen to the Episode:

Key Takeaways

Audit trail review starts with a clear question

Review should be tied to a defined risk or purpose. Changes to critical eligibility or safety data, for example, may warrant more attention than routine corrections to low-risk administrative fields. This helps avoid large reviews that duplicate controls already covered through monitoring, data cleaning or system oversight.

Ownership and access need to be agreed early

Audit trail data may sit across EDC systems, laboratory platforms, devices and other external sources. Teams need to know what metadata is available, whether it can be accessed in a usable form and who is responsible for reviewing and following up on it. These decisions are easier to manage when they are addressed during vendor selection and study set-up.

A signal still needs context before it becomes a finding

Repeated edits, unusual timing or higher levels of activity at one site may justify a closer look, but they do not establish that something has gone wrong. Reviewers need to consider the surrounding clinical data, queries and study processes before assessing impact or deciding whether further action is needed. Visualisation and automated flags can help prioritise where to look, but they do not replace that interpretation.

Full Transcript

Jullia

Welcome to QCast, the show where biometric expertise meets data-driven dialogue. I’m Jullia.

Tom

I’m Tom, and in each episode, we dive into the methodologies, case studies, regulatory shifts, and industry trends shaping modern drug development.

Jullia

Whether you’re in biotech, pharma or life sciences, we’re here to bring you practical insights straight from a leading biometrics CRO. Let’s get started.

Tom

Today we’re looking at audit trails. They’re built into most clinical trial systems now, but that doesn’t necessarily mean the review side is straightforward. So, what does audit trail review actually involve?

Jullia

The audit trail itself is the electronic record of what happened in the system and it can show who changed something, what changed, when it happened and, where required, why.

The review is the part where you look at that information and decide whether anything needs a closer look. So, the record can be there, but someone still has to interpret what it actually means.

Tom

And because there can be so much activity in an audit trail, you’re not treating every change as suspicious?

Jullia

Precisely. A change can be completely expected. A site might correct an adverse event date after answering a query, for example, and there may be a perfectly clear reason for it.

So, what you’re really looking for are patterns, or individual events, that need some context. That might be repeated changes to critical data, data entered much later than expected, unusual user activity, or a reason for change that doesn’t really explain what happened. An unusual event is a reason to look further, but it isn’t automatically evidence of poor data quality or misconduct.

Tom

There’s another point that sometimes gets confused. When people talk about audit trail review, are they always talking about the clinical data itself?

Jullia

No. See, trial level review is focused on the clinical data and the metadata around it. So you might be looking at data entry, changes to important variables, query activity, or patterns across sites and users.

But system-level review is different. Now that can cover things like configuration changes, administrative activity, security events or user provisioning. Those things can still affect data integrity, but they’re often owned by different teams.

Tom

So for example, an unusual login might be handled differently from seeing the same critical data point changed several times?

Jullia

Potentially, yes. There can be overlap, but somebody needs to know which process is meant to pick up which type of activity. Otherwise, you can end up with a gap where everyone assumes someone else is looking at it, or the opposite, where two teams are reviewing the same thing.

Tom

I suppose this then raises the question of scope. Are you meant to identify every system with an audit trail and review all of it?

Jullia

Usually not. That can become a huge amount of work, and some of the same activity may already be covered through data cleaning, monitoring, system validation or security controls.

So really, the better starting point is the risk you’re trying to understand. Which data or processes matter most to participant safety or trial reliability? What can the audit trail tell you that you’re not already getting from another control? And if you do find something, can the team act on it?

Tom

Can you give a simple example of how that changes the review?

Jullia

Yes, so take an eligibility criterion that determines whether a participant should have entered the trial. Changes to that data could matter much more than repeated corrections to a low-risk administrative field.

Therefore, you might give more attention to changes in eligibility data, who made them, when they happened and what explanation was recorded. The review follows the risk rather than treating every field the same.

Tom

And external systems make that harder, don’t they? A sponsor might not control every platform generating trial data.

Jullia

Yes, see, you might have an EDC system, laboratory data, electronic clinical outcome assessments, devices and other external sources.

During vendor selection and study set-up, you want to know what metadata those systems generate, whether you can actually get it out in a usable form and who is responsible for providing it. If you can’t access that information later, there’s a limit to what review you can do. So, this should be clear in the contract, procedure or study documentation as well.

Tom

Now once you know what matters, how much detail needs to go into the review plan?

Jullia

Enough that the scope and the reasoning are clear. And that includes exclusions. A system shouldn’t be included just because an audit trail exists, but if you leave one out, there should be a clear reason for that too.

Tom

So what sort of use cases would you usually see?

Jullia

Well, things like unexpected user access, repeated changes to critical data, unusually delayed data entry, incomplete reasons for change or odd patterns across sites.

You can also have more targeted reviews. Say a data manager notices something unusual in query turnaround at one site. The audit trail might then help show when records were entered, when they were changed and whether there’s a pattern worth following up. It really comes back to what question the review is trying to answer.

Tom

There’s a tendency to think of audit trail review as something you do before database lock. Is that leaving it too late?

Jullia

It can be, if that’s the first meaningful review. Database lock is obviously an important point because you want the required reviews completed and relevant findings addressed before the database is finalised.

But some findings are much more useful while the study is still running. If you pick up delayed data entry or repeated corrections during conduct, there’s still time to investigate, speak with the site or change a process. If you find the same thing near the end, your options are more limited.

Tom

So does that mean reviews should happen on a fixed timetable?

Jullia

Not necessarily. See, frequency should reflect the risk, the amount of data, where you are in the study and what previous reviews have shown.

Some reviews might be planned in advance and happen at defined intervals. Others are more targeted because something specific has come up. A review triggered by a monitoring observation, for example, has a different purpose from a routine review of selected critical-data changes.

Tom

Who actually does the review? Is that usually data management?

Jullia

Well data management may lead the trial-level review, but the reviewer needs to understand the data and the study context. Being able to run an audit trail report isn’t enough on its own.

If you’re looking at a dosing change, for example, you need enough understanding of the study to decide whether that change makes sense.

Tom

And if some of that work sits with a CRO or a technology vendor, the sponsor still needs visibility?

Jullia

Yes. The activity can be delegated, but the sponsor still needs oversight. It should be clear who provides the audit trail data, who performs the review, who investigates findings and who documents closure.

Quality assurance may also check that the process exists and is being followed, but that doesn’t mean every individual review needs to be repeated by a second person.

Tom

Let’s discuss an example scenario. Say a reviewer sees that the same safety field has been edited several times. What would you expect them to do next?

Jullia

First, work out what actually happened. Maybe each change followed a legitimate query, and the final value is well supported. Or maybe the changes don’t line up with the source information and there’s no good explanation.

Then you look at the potential impact. Does it affect participant safety, data reliability or compliance with the study process? From there, you can decide whether it just needs to be documented or whether there’s a need for further investigation, site follow-up, training or corrective action.

So spotting the anomaly is really only the start because the reasoning afterwards is the important bit. The record should show what was reviewed, what was found, how it was assessed, what action was taken, if any, and why the issue was closed. That way, someone coming back to the review later can understand the decision rather than just seeing a list of flags.

Tom

With that much metadata, it’s easy to see why teams use visualisation and automated flags. How much can you rely on those?

Jullia

Well, they can make the review much easier to manage. Filters and visualisations can help you compare activity across sites or users and focus attention on patterns that look unusual. But the flag still needs interpretation. If one site has made more data changes than the others, there could be several reasons for that.

And even then, the metadata itself can limit the review too. You might have inconsistent formats across systems, unclear timestamps, missing reasons for change or external metadata that’s difficult to access. Sometimes the harder part is linking the audit trail event back to the clinical records you need to understand it properly.

Tom

So, if someone is looking at their audit trail approach now, what are the main things you’d want them to keep in mind?

Jullia

I’d keep it fairly simple. Be clear about the risk or question each review is meant to address, rather than trying to review everything that’s available. And when something unusual comes up, look at it in the context of the clinical data and the study process before deciding what it means.

With that, we’ve come to the end of today’s episode on audit trail review in clinical trials. If you found this discussion useful, don’t forget to subscribe to QCast so you never miss an episode and share it with a colleague. And if you’d like to learn more about how Quanticate supports data-driven solutions in clinical trials, head to our website or get in touch.

Tom

Thanks for tuning in, and we’ll see you in the next episode.

About QCast

QCast by Quanticate is the podcast for biotech, pharma, and life science leaders looking to deepen their understanding of biometrics and modern drug development. Join co-hosts Tom and Jullia as they explore methodologies, case studies, regulatory shifts, and industry trends shaping the future of clinical research. Where biometric expertise meets data-driven dialogue, QCast delivers practical insights and thought leadership to inform your next breakthrough.

Subscribe to QCast on Apple Podcasts or Spotify to never miss an episode.