NHS Clinical Research Software and ICH-GCP E6(R3): What the New UK CTR Requires

The amended UK Clinical Trials Regulations took full effect on 28 April 2026, and ICH-GCP E6(R3) came into force in the UK on the same day. Between them they place four testable demands on the software an NHS organisation uses to run research: the system has to hold a registration date, produce a results record inside a fixed period, evidence that it is fit for purpose, and keep essential records readable for at least 25 years.

Published guidance describes these as duties for sponsors and investigators. Inside a trust, each duty resolves into a single record with a date on it, held in a system that either produces that record on request or leaves someone to reconstruct it. That is the practical question facing NHS hospital research teams in 2026: which of the new obligations does the current software estate actually evidence?

This guide covers:

• The four provisions that now bind research software in the UK, and what each one binds.
• The statutory clocks introduced on 28 April 2026, with the event that starts each one.
• What ICH-GCP E6(R3) Principle 9 and Annex 1 Section 4 require of a computerised system.
• Where the evidence chain breaks inside a typical NHS software estate.
• The 25-year retention duty under regulation 31A and the contract questions it raises.

What Changed for NHS Research Software on 28 April 2026?

The Medicines for Human Use (Clinical Trials) (Amendment) Regulations 2025 (SI 2025/538) took full effect on 28 April 2026. The MHRA applies them on a binary basis: applications submitted before that date run under the former requirements as “old rules” trials, and everything submitted from that date runs under the amended regulations. A trust therefore operates two regulatory populations at once, and the systems have to tell them apart.

Four provisions now sit behind a research software decision. They bind different things, and confusing them is what produces a specification that misses the point.

• SI 2025/538 makes registration of a trial and publication of summary results a legal requirement for the first time, and introduces the notification scheme for lower-risk trials.
• Regulation 28(1) of the 2004 Regulations states that no person shall conduct a clinical trial otherwise than in accordance with the conditions and principles of good clinical practice, and regulation 28(1A) confirms that those conditions and principles include the ICH Guideline for Good Clinical Practice as amended from time to time. The principles of ICH-GCP E6(R3) carry legal force through this route.
• Regulation 28(1B) states, for the avoidance of doubt, that the functions of the sponsor include functions in relation to the development and maintenance of trial specific computerised systems. Responsibility for the system sits with the sponsor by name.
• Regulation 31A sets the retention duty: essential records held for at least 25 years, readable and available to an inspector throughout.

The MHRA has been explicit that ICH-GCP E6(R3) came into force in the UK alongside the updated regulations, that all trials must adhere to the principles of GCP, and that trials supporting a marketing authorisation must comply with the full guideline. Organisations claiming ICH E6 compliance are held to the annexes as well. The full walk-through of what sites and sponsors must do sits in our guide to the new UK Clinical Trials Regulations. This guide takes the next step and asks what those duties require of the software.

The duty belongs to the sponsor. The proof belongs to a system.

Which Duties Now Carry a Statutory Clock?

Several obligations that used to rest on good practice now run against a published deadline, and a missed deadline is an offence rather than an observation. The MHRA has confirmed it may use infringement notices and prosecution where transparency duties are breached. Each clock below starts from an operational event, which means the system holding that event has become the system of record for a legal duty.

The lay summary duty applies to trials submitted from 28 April 2026. The HRA encourages sponsors of trials already underway on that date to offer one voluntarily. Every row otherwise reduces to a date and an owner. A trust that can produce both from one place has satisfied the evidential half of the duty. A trust that reconstructs either from correspondence has a gap that only appears when someone asks.

What Does ICH-GCP E6(R3) Require of a Computerised System?

E6(R3) replaced E6(R2) and restructured good clinical practice around 11 principles supported by annexes. Principle 9 is the one that reaches directly into software. It states that clinical trials should generate reliable results, and its six sub-principles describe the conditions under which a system can be relied on.

Principle 9: the six statements that bind a system

• 9.1 Fit for purpose information. The quality and amount of information generated should support confidence in the results, which sets the evidential bar the system has to clear.
• 9.2 Fit for purpose systems. Systems for data capture, management and analyses should capture the data the protocol requires and be implemented proportionately to risk, so the specification follows the protocol rather than the vendor feature list.
• 9.3 Risk-based validation. Computerised systems should be fit for purpose through risk-based validation where appropriate, which makes validation evidence a deliverable rather than an assurance.
• 9.4 Record integrity and traceability. Processes for managing records should maintain integrity and traceability and protect personal information, which is what allows accurate reporting and verification later.
• 9.5 Secure retention. Essential records should be retained securely by sponsors and investigators for the required period, which ties the guideline to regulation 31A and its 25 years.
• 9.6 Transparency. Transparency includes timely registration on recognised databases and public posting of results, which places the registry duties inside GCP as well as inside the regulations.

Annex 1 Section 4: data governance in practice

Annex 1 Section 4 covers data governance for the investigator and the sponsor, and it is the operational detail behind Principle 9. Section 4.2 walks the data life cycle. Section 4.3 addresses computerised systems directly. An NHS R&D office reading a vendor response should be able to point at each numbered item and find an answer.

• 4.2.2 Relevant metadata, including audit trails. The audit trail is part of the record, so an export that carries data without metadata does not carry the evidence.
• 4.2.3 Review of data and metadata. Someone reviews the audit trail, which requires the audit trail to be legible to a person rather than a database administrator.
• 4.2.4 Data corrections. Corrections carry a reason and an identity, which is the difference between a corrected record and an altered one.
• 4.2.5 Data transfer, exchange and migration. Migration is a validated activity with documentation, which becomes relevant every time a trust changes supplier.
• 4.2.7 Retention and access. Retention includes continuing access, so an archive that cannot be opened satisfies neither the annex nor regulation 31A.
• 4.3.3 Security and 4.3.8 user management. Access control is named at system level, which makes leaver and joiner processes part of GCP compliance.
• 4.3.4 Validation and 4.3.5 system release. Validation evidence and a controlled release path both belong to the sponsor’s file, not only to the vendor’s.
• 4.3.6 System failure and 4.3.7 technical support. A documented failure procedure decides what happens to trial conduct during an outage.

Validation deserves its own treatment, because the depth expected depends on what the system does and what it would cost to get it wrong. Our guide to GAMP 5 and computerised system validation sets out the software categories and the deliverables an inspector expects. The wider oversight changes introduced by the guideline sit in our guide to ICH-GCP E6(R3) and study oversight.

Also Read: MHRA GCP Inspections: What to Expect and the Most Common Findings

Where the Requirement Lands in an NHS Software Estate

A typical trust runs its research portfolio across several systems that were each adopted for a good local reason. The local portfolio system holds the study list. An electronic data capture tool holds participant data. Contracts sit in a finance folder. Approval letters arrive by email. Delegation logs live in the site file. All of that is ordinary, and all of it holds until a duty needs evidence from more than one place at once.

Consider a hypothetical trust with sixty open studies. A study receives approval on 4 May 2026. The registration duty runs from that approval, and the 90-day limit expires on 2 August. The approval letter reaches a research coordinator by email, and the coordinator adds a line to a set-up spreadsheet. The coordinator leaves in June. The spreadsheet survives, the mailbox does not, and the registration entry is made on 19 August after a sponsor query. The activity was completed. The evidence that it was completed on time was never held anywhere, and the breach is now a matter of record.

Failures of this shape share four characteristics, and each one is a property of the estate rather than the person:

• The trigger arrives outside the system. An approval letter in a mailbox starts a legal clock that the study record knows nothing about.
• The owner is implied. A task with no named owner in a system belongs to whoever remembers it, which lasts exactly as long as that person stays.
• The date is entered twice. One event recorded in two places produces two versions, and an inspector will ask which one governs.
• The proof is a document rather than a field. A scanned confirmation in a folder tells you what happened and leaves when it happened to be inferred.

Also Read: NHS R&D: Governing Site Files Across a Trust’s Studies

Effort or Design: Two Ways an Estate Meets the Same Duty

Two trusts can hold identical obligations and satisfy them by opposite means. One assembles the evidence when it is asked for. The other holds the evidence as a by-product of doing the work. Both can pass an inspection. Only one can pass it on a week’s notice while the people who set the study up are on leave.

The distinction matters most under inspection conditions. An estate that meets duties by design produces the same answer whoever is asked and whenever the question comes. Our 2026 buyer’s guide to clinical trial management software for NHS trusts takes this into procurement, covering the assurance stack and the questions to put to a supplier.

The 25-Year Duty Most Software Contracts Leave Open

Regulation 31A requires essential records to be retained for at least 25 years beginning the day after the conclusion of the trial, with a further two years after authorisation for trials supporting a marketing authorisation. Throughout that period the records must be readily available, complete and legible for inspection by the MHRA or another competent authority. MHRA archiving guidance adds that the sponsor appoints a named individual to be responsible for archiving the documents, and restricts access to archived records to the individuals it appoints.

Twenty-five years outruns almost every software contract, hosting arrangement and file format a trust holds today. MHRA guidance on archiving is specific about what an electronic archive has to sustain: audit trails and metadata preserved alongside the records, long-term readability, validated and documented migration to new formats, and access restricted to named individuals appointed by the sponsor. Five questions turn that into a procurement position.

1. What does a complete export contain, and does it include audit trails and metadata rather than data alone?
2. Who validates a migration when the format or the supplier changes, and where is that validation documented?
3. What access does the trust retain after the subscription ends, and in what form?
4. Which named individual holds oversight of the archive, and where is that name recorded today?
5. How is a record produced for an inspector in year 20, and has that route ever been tested?

Retention is a data integrity question as much as a storage one, because a record that survives without its metadata has lost the attributes that made it evidence. Our guide to ALCOA+ and the Trial Master File works through which attributes sit with the system rather than the page.

Also Read: The Investigator Site File Essential Documents Checklist (ICH-GCP Chapter 8)

A Readiness Checklist for an NHS Research Software Estate

The checks below take a morning against a single study and expose most of the gaps that matter. Each one asks the estate to produce evidence rather than asking a person to describe a process.

1. Pick one study approved after 28 April 2026 and produce its registration date, the deadline that applied, and the person who owned it.
2. Pick one study that ended in the last year and produce the results posting date against the 12-month limit.
3. Show which of your open studies run under the amended regulations and which remain old rules trials.
4. Produce the audit trail for one amended field, including who changed it, when, and why.
5. Show that a leaver from three months ago holds no active access to any research system.
6. Produce the validation and release records for the system holding your study data.
7. Name the individual with oversight of archived records and show where that name is recorded.
8. Export one study’s essential records and confirm the export carries metadata as well as content.

A check that takes several people and several days points at the estate rather than the team. That is a design result, and it responds to design changes.

AQ Under the Amended Regulations: Evidence Produced by the Work

The AQ Platform holds study operations, documentation, quality and delegation in one connected environment, so the records the regulations ask for are produced by the work rather than assembled after it. The mechanism matters more than the module count.

• CTMS holds approval dates, milestones and study status on one record, which lets a registration or results deadline be derived from the event that starts it rather than tracked separately.
• eTMF is built on the DIA TMF Reference Model, which gives essential records a defined structure and a completeness position that can be read at any point rather than at close-out.
• eISF and ePSF hold the site-held and pharmacy-held files under the same structure, which allows a trust to see the current position across every study without visiting each site.
• QMS and CAPA connect deviations to actions and effectiveness checks, which keeps the quality record traceable from detection through to verified closure.
• Digital delegation ties system access to the current delegation entry, which keeps user management aligned with who is authorised to perform each task today.

AQ is assured for NHS procurement through G-Cloud, the Data Security and Protection Toolkit and Cyber Essentials, and the platform is designed around ICH-GCP E6(R3), ALCOA+ and the UK Clinical Trials Regulations. Teams evaluating their position under the amended regulations can book a live demo and walk one study end to end.

Primary sources: MHRA guidance on compliance with ICH E6 GCP in the UK, MHRA archiving and retention of clinical trial records, Clinical trials regulations: transitional arrangements, and the HRA on research transparency and transitional arrangements.