What Does PI Oversight Look Like in an eSource Audit Trail?

PI oversight in an eSource audit trail looks like three kinds of entry: the attribution behind every value, the review events showing that the investigator opened the record, and the endorsement events where the investigator signed it. An audit trail holding only the first of those three is a record of data entry. It evidences no oversight.

This guide sits in our series on eSource in clinical trials. It covers the entries that evidence oversight, what a principal investigator reviews and how often, what makes an endorsement defensible, how the trail proves delegation was in place on a given date, and the requests an inspector makes. The duties themselves come from ICH E6(R3) section 2.

Oversight is an entry, not an intention.

Which Entries in the Audit Trail Evidence Investigator Oversight?

Three entry types carry the evidence. Each one answers a different question an inspector puts to the record, and each one fails in a way the trail displays plainly.

Entry typeWhat the audit trail recordsHow its absence reads at inspection
AttributionThe account that created or changed each value, with date and timeA value nobody owns, or one owned by an account outside the delegation log
ReviewThe investigator account opening the record, with the date of accessA signature with no evidence that the data was ever read
EndorsementThe investigator signature, its meaning, its date and the data version it coversData reported to the sponsor that the investigator never adopted
Post-signature changeAny edit made after endorsement, with reason and re-signatureA signature that covers a version of the data no longer in the system

ICH E6(R3) places the duty behind these entries in two clauses. Section 2.3.1 keeps ultimate responsibility with the investigator and asks for oversight proportionate to the importance of the data. Section 2.12.5 asks the investigator to ensure the accuracy, completeness, legibility and timeliness of the data reported to the sponsor, and to review and endorse that data at important milestones.

PI oversight in an eSource audit trail for one clinical trial visit, showing the entry, correction, investigator review and endorsement events with their timestamps

Our guide to who uses eSource, from research nurse to sponsor sets out what each of the seven roles does with the record. This guide takes the investigator’s part of it and reads it from the trail. The endorsement itself covers reported data, and our guide to where source data ends and the CRF begins sets out which record that is.

What Does the Investigator Actually Review, and How Often?

The investigator reviews the data whose importance justifies the review, at a frequency the study’s risk assessment sets. ICH E6(R3) section 2.3.1 fixes that principle by making the level of oversight proportionate to the importance of the data. The MHRA applies the same logic to the audit trail itself.

The MHRA GXP data integrity guidance states at section 6.13 that routine data review should include a documented audit trail review where a risk assessment determines it. The MHRA’s GCP perspective on that guidance adds two practical points: the need for an audit trail review follows from the trial’s own risk assessment, and the guidance creates no requirement for a standalone audit trail review SOP.

  • The risk assessment names the critical data points at study set-up, which tells the investigator what to read rather than leaving it to judgement each week.
  • Eligibility, primary endpoint values and safety data carry a review at every occurrence, because a late error in any of them affects a participant or the analysis.
  • Administrative and non-critical fields carry a sampled review, which keeps the reviewing effort proportionate to what an error would cost.
  • Corrections made after a monitor query carry their own review, because the reason for change is the part an inspector tests.
  • The review cadence sits in the study risk assessment, so the record of the decision survives a change of investigator.
Risk proportionate investigator review of eSource data, showing review depth and frequency for critical, supporting and administrative data points under ICH E6(R3) section 2.3.1

Also Read: Does eSource Meet ALCOA+? The Attributes Inspectors Check

What Makes an Investigator Endorsement Defensible?

A defensible endorsement states what was signed, by whom, when, and what the signature means. The system supplies four of those elements and the site supplies the fifth.

  • The signature binds to a named account under sole user control, which keeps the endorsement attributable to one person.
  • The system applies its own date and time, which removes any argument about when the review happened.
  • The signature carries its meaning in words, such as review, approval or authorship, so the record states what the investigator adopted.
  • The signature attaches to a defined set of data, which allows an inspector to see the scope of the endorsement.
  • Any change made after signature invalidates it and requires a fresh one, which keeps the signed version and the live version the same.

Timing turns a valid signature into a weak one. ICH E6(R3) section 2.12.5 asks for endorsement at important milestones, and a study that defines those milestones in advance produces signatures spread across the trial. A study that leaves them undefined produces a run of signatures dated in the final week before database lock. Both patterns are visible in one query of the trail.

How Does the Audit Trail Prove Delegation Was in Place?

The trail proves delegation by reconstruction on a past date. ICH E6(R3) section 2.3.3 asks the investigator to maintain a record of the persons to whom trial-related activities were delegated. The MHRA is direct about the investigator’s part in granting the access itself, stating in its guidance on electronic systems used at sites that the investigator should authorise the access of any person assigned editing rights and maintain oversight of it.

The test runs on a single date chosen by the inspector. Three questions decide whether the record holds.

  1. Which accounts held write access to this study on that date, according to the system’s own user history?
  2. Which people held a delegated task covering that activity on that date, according to the delegation of authority record?
  3. Which of those people had completed protocol and system training before that date, according to the training file?
Reconstructing eSource delegation evidence on a past date, comparing system access, delegation log effective dates and training completion for three site staff

Three answers that agree close the question in minutes. Any mismatch turns one date into a portfolio-wide request, because an inspector who finds a gap on one date tests the next study for the same condition.

Where Does PI Oversight Break in Practice?

Oversight fails in five recognisable ways, and each one is a process condition rather than a personal lapse. The audit trail shows each failure in a different shape.

FailureWhat the audit trail showsCondition behind it
Bulk sign-offHundreds of endorsements within a few minutes on one dateMilestones for endorsement were never defined in the protocol or study plan
Signature without reviewAn endorsement with no prior read event on the same recordThe system offers a sign action that does not require the record to be opened
Shared accountInvestigator entries made while the investigator was on leaveCover arrangements were handled by password sharing rather than by a second delegated account
Silent post-signature editA change dated after the endorsement, with the signature still showing as currentThe system does not invalidate a signature when the signed data changes
Retrospective delegationEntries by an account whose delegation log entry is dated laterAccess provisioning runs ahead of the delegation sign-off step

Consider a hypothetical respiratory study at an NHS trust. The principal investigator endorses 412 visit records on 14 August, all between 16:41 and 16:58, four days before database lock. The endorsements are valid signatures on valid data. The trail also shows that 38 of those records were corrected in July, that the investigator opened none of them, and that the protocol never named a milestone for endorsement. The finding here is the absence of a defined review point, and the fix sits in the study plan rather than in the investigator’s diary.

Also Read: What Is a Source Data Location Log and Who Signs It Off?

What Does an Inspector Ask to See?

An inspector works from the record outward. The sequence below follows the order the evidence is usually requested in, and each step depends on the one before it.

  1. The study risk assessment, to see which data points were designated critical and what review they attract.
  2. A full audit trail export for one participant, to follow every entry, correction and signature on one timeline.
  3. The user access history for the study, to establish which accounts held which permissions on the dates in question.
  4. The delegation log and training records, to place each account against an authorised person.
  5. The documented audit trail review, which the MHRA guidance expects to carry a positive statement of the findings and the reviewer’s signature.
  6. Evidence that the reviewer held sufficient knowledge and system access to perform the review, as section 6.13 of the same guidance requires.

The procedures behind steps five and six belong to the site’s quality management system, which holds the SOPs for data review, periodic access review and system validation. Monitoring of the same record follows a separate route through the site’s clinical trial management system.

An investigator can only oversee a record the system lets them read on their own terms. AQ is launching eSource soon as part of the AQ platform, so that the delegation record, the access it grants and the investigator’s review of the resulting entries sit on one footing. Book a live demo to see the AQ platform today.

Guide
By Ash Mahmud· · · Book a 30 min demo
In this guide
AM
Written by
Ash Mahmud
Co-founder, AQ Trials

Ash has spent over twenty years inside clinical research operations and technology, working alongside NHS Trusts, CROs, sponsors, and academic research organisations. He co-founded AQ Trials to give research teams one connected, inspection-ready operational record.

See the connected platform behind this guide

A 30-minute walkthrough built around your operational priorities — study execution, documentation, quality and pharmacy in one governed record.

Book a 30 min demo →
See the AQ Platform in action — a 30-minute walkthrough for teams like yoursBook a 30 min demo →
Free guides · PDF
Find the right guide for you

Pick a module, your organisation type, or both — we'll match the guides and email them to you.

Most popular guides
Explore
15+ guides

Free guides · PDF

Guides matched to you.

Written for first-in-human & Phase 1 sites

Inspection-ready checklists & templates

Aligned to MHRA, FDA & EU Annex 11