What MHRA Expects from Electronic Source Systems Under the 2026 UK Regulations

The MHRA expects an electronic source system to produce, on request, the original record of every trial observation together with the metadata that proves who entered it, when it was entered, and what has changed since. That expectation now rests on law. Regulation 28 of the amended UK Clinical Trials Regulations requires any person conducting or sponsoring a trial to comply with the conditions and principles of good clinical practice, and from 28 April 2026 those conditions and principles include the International Council for Harmonisation Guideline for Good Clinical Practice.

Two documents settle what an inspector asks an electronic source system to show. The Regulations create the duty. The MHRA GXP Data Integrity Guidance and Definitions supplies the vocabulary used to test it. A site that can describe its own system in the regulator’s terms answers from the record. A site that can only operate the system answers from memory.

What Changed for eSource on 28 April 2026?

Compliance with the ICH GCP principles became a legal requirement in the UK on 28 April 2026. The MHRA states the position plainly in its guidance on compliance with ICH E6 in the United Kingdom, which confirms that the principles apply “as amended from time to time”. Three consequences follow for a site running electronic source capture in clinical trials.

• The site’s definition of its source records carries statutory weight, which makes that definition inspectable in its own right.
• The MHRA assesses compliance “proportionately and pragmatically in relation to the risks” and uses the sponsor’s risk assessment, which allows a low-risk study to hold lighter system evidence than a high-risk one.
• Trials conducted to support a marketing authorisation are expected to meet the annexes as well as the principles, which raises the evidence bar on the computerised system holding the source record.

The individual ICH E6(R3) clauses that govern source records are covered in the guide to how ICH E6(R3) changes the rules for eSource.

Which MHRA Guidance Defines the Terms an Inspector Uses?

The MHRA GXP Data Integrity Guidance and Definitions was published in March 2018 and last updated in September 2021. It applies across all GxP sectors, good clinical practice included, and describes itself as “a useful resource on the core elements of a compliant data governance system”. Its definitions are the ones an inspector uses to test what a site’s electronic entry actually is.

The guidance treats the entry and its metadata as one record.

Also Read: Which record is the source when data sits in both the EPR and the trial system?

What Does the MHRA Expect Across the Life of a Source Record?

The guidance defines the data lifecycle at section 6.6 as “all phases in the life of the data from generation and recording through processing (including analysis, transformation or migration), use, data retention, archive/retrieval and destruction”. Data governance at section 6.5 is “the arrangements to ensure that data, irrespective of the format in which they are generated, are recorded, processed, retained and used to ensure the record throughout the data lifecycle”. The obligation runs the whole span, and three points along it account for most of the difficulty.

• Migration. The guidance warns that “the challenges of migrating data are often underestimated, particularly regarding maintaining the full meaning of the migrated records”, which makes a validated migration rationale part of the evidence.
• Archive against backup. Section 6.17.2 is explicit that “backups for recovery purposes do not replace the need for the long term, retention of data and metadata in its final form”, so a nightly backup answers a recovery question rather than an archiving one.
• Protection in the archive. Archived records “may be the original record or a ‘true copy'” and must be held so they cannot be altered or deleted without detection.

UK retention periods and the work of exporting an eSource record into a readable archive format sit outside this guide.

What Does the MHRA Expect of an eSource Audit Trail?

Section 6.13 defines an audit trail as “a form of metadata containing information associated with actions that relate to the creation, modification or deletion of GXP records”. The design requirement is stated as an absolute. System design “should always provide for the retention of audit trails to show all changes to, or deletion of data while retaining previous and original data”. Five separate duties follow from that sentence, and a system satisfies only the first two on its own.

• The audit trail exists and captures creation, modification and deletion, which gives the record its history.
• Previous and original values are retained alongside the change, which allows the original observation to be recovered after a correction.
• The trail is readable at system level, which shows a reviewer what changed across a dataset rather than one entry at a time.
• A risk-based review actually takes place, which converts a stored trail into an applied control.
• The review is documented with “a positive statement regarding whether issues were found or not, the date that review was performed and the signature of the reviewer”, which is the part an inspector reads.

The written procedure that governs who performs the audit trail review, and how often, belongs in the site’s quality management system. The mapping of each ALCOA+ attribute to the eSource control that evidences it is covered in the guide to whether eSource meets ALCOA+.

Who Must Be Able to Reach the Record, and Under What Controls?

Regulation 31A of the Clinical Trials Regulations requires sponsors and chief investigators to keep trial master file documents readily available to the licensing authority on request. The MHRA extends that duty to the systems themselves in its guidance on GCP inspections, which states that “where multiple electronic systems constitute the complete TMF direct access must be made available to each system”. Access runs in two directions, and the guidance sets rules for both.

• Outward access for the regulator. Contracts with IT service providers must ensure “timely access to data (including metadata and audit trails) to the data owner and national competent authorities upon request”, which places an inspection clause inside a commercial agreement.
• Inward access for the study team. Full use “should be made of access controls to ensure that people have access only to functionality that is appropriate for their job role, and that actions are attributable to a specific individual”.
• Named accounts only. For systems generating, amending or storing GXP data, “shared logins or generic user access should not be used”, which is what makes attribution survive a busy clinic.
• Separated administration. System administrator rights “should not be assigned to individuals with a direct interest in the data”, which separates the person who can delete a record from the person whose work it evidences.

Also Read: What is a source data location log and who signs it off?

Which Inspection Findings Come from Electronic Source Systems?

The MHRA grades findings at three levels. A critical finding is a “significant and unjustified departure” from the legislation where participant rights, safety or wellbeing have been jeopardised, or “the clinical trial data are unreliable”. A major finding is a significant departure with the potential to become critical. Other findings are neither. The MHRA’s most recent published GCP inspection metrics cover 1 April 2019 to 31 March 2020 and record 13 critical and 58 major findings across 36 inspections.

Three findings in that report describe electronic record problems directly, and each tests a different link in the chain.

The pattern across all three is consistent. The systems held their data. The sites and their suppliers could not produce it in a reviewable form when an inspector asked. An unreadable audit trail fails in the same way as a missing one.

Also Read: MHRA GCP inspections: what to expect and the most common findings

How Does a Site Evidence These Expectations Before an Inspection?

Each expectation above resolves to a document or a demonstration the site can prepare in advance. A rehearsal against six points converts the guidance into evidence that is already on file.

1. State in writing which records in the system are the original source, which allows the first question to be answered from a document rather than a conversation.
2. Walk one participant visit from entry to audit trail with a colleague, which surfaces any step where the metadata stops short of the entry.
3. Time a retrieval of one dated entry with its change history, which measures the “readily available” duty in minutes rather than in principle.
4. Read the supplier contract for the regulator access clause, which confirms the inspection route before an inspection needs it.
5. Reconcile the system user list against the delegation log, which exposes shared accounts and leavers who still hold access.
6. File one completed audit trail review carrying the reviewer, the date and a positive statement, which gives the control a readable output.

Validation evidence for the system itself, and the split of responsibility between vendor and site, is a separate piece of work with its own documentation.

AQ is launching eSource soon as part of the AQ platform. Research teams planning how electronic source capture will sit alongside the rest of their study record can book a live demo.