How do I complete the MHRA computerised systems inspection dossier? You list every computerised system used in the conduct of your trials, state its version, its validation status and who validated it, name the person responsible for it, and say where the data is hosted. The dossier reports an inventory you already hold.
The request arrives inside a pre-inspection pack. The MHRA publishes the template on gov.uk as the GCP inspection dossier template, version 7.0, December 2025, and it states that the information “should be provided within 30 days of the advance notice email date”. The stages either side of that deadline are set out in our guide to MHRA GCP inspections and the most common findings.
The notification email fixes the scope. A systems inspection puts all trial activities in scope. A trial specific inspection narrows it to the selected trials only.
How Do I Complete the MHRA Computerised Systems Inspection Dossier?
You answer the same inventory five times, in five shapes. Version 7.0 asks about computerised systems in Section 1 and again in Section 2, and the answers must agree. An inventory listing eleven systems beside a narrative describing nine is the contradiction an inspector opens first.
| Dossier location | What it asks for | Format |
| Section 1, Item 2 | Policies, SOPs and work instructions covering trial conduct, with references, titles and issue dates | Narrative list |
| Section 1, Item 3 | Every computer system used in trial conduct and in the collection and analysis of trial data, with version history, reason for change, validation status and who validated it | Excel, on the sheet named “Section 1.3 Computerised Systems” |
| Section 2, Item 12 | Who owns those systems, where the servers sit, what data is held where, and the backup and disaster recovery plans | Narrative, one page |
| Section 2, Item 13 | Each artificial intelligence or machine learning tool, and the documented processes covering its validation, training and human oversight | Narrative, one page |
| Section 2, Item 14 | Which systems make up the electronic parts of the Trial Master File | Narrative, one page |
The submission goes to the MHRA GCP inspection dossier mailbox, capped at 100 pages, ideally as a bookmarked PDF with an electronic contents list. Section 1 items 3 and 5 and Section 2 item 3 go as spreadsheets.
Five questions, one answer. The dossier reads cleanly only when a single inventory feeds all of them.
Which Dossier Will Your Organisation Receive?
Two dossiers now exist. The gov.uk guidance on good clinical practice for clinical trials was updated on 22 September 2026 with “the introduction of a specific dossier for organisations providing computerised systems in support of clinical trials”. Sites and sponsors still complete the standard dossier. The new one belongs to the companies that build and host systems.
| Aspect | Standard dossier | Computerised Systems dossier |
| Who completes it | Sponsors, NHS organisations, CROs and sites running trials of an investigational medicinal product (IMP) | Organisations that develop, configure, host or maintain trial specific systems |
| Published version | Version 7.0, December 2025 | September 2026 files |
| Systems content | One inventory item plus three narrative items | Six spreadsheet items and four narrative items |
| Stated purpose | To give the inspector an overview and help define scope | To support a risk-based assessment of whether an inspection is required at all |
The second dossier reaches further into engineering practice than most sites expect of a supplier. It asks for source code management, software development lifecycle tooling, change control, defect and ticketing systems, test management, and release and deployment.
What Happens in the 30 Days?
Two sites receive the same email and spend the month very differently. The first circulates a request to every department and waits. Pharmacy names a temperature monitoring system nobody in the research office had listed. The site file vendor is asked for a validation pack and sends a brochure. The inventory submitted on day 30 is the first version that has ever existed.
The second site opens a register it already maintains, confirms the versions against the live systems, and spends the month on the narrative items. Both sites work for thirty days. Only one works on the dossier.
| Aspect | Site discovering its systems | Site maintaining an inventory |
| Source of the list | Recollection, email replies and a scan of invoices | A register updated as each system is adopted |
| Version numbers | Whatever the screen shows that day | Version history with a reason recorded for each change |
| Validation status | Asserted, with evidence sought afterwards | Stated against a filed report and a named release |
| Named owner | Decided while drafting the dossier | Recorded when the system went live |
| What the inspector sees | A document written for the inspection | A document extracted from how the site runs |
What Goes in the System Inventory?
Section 1 Item 3 is the heart of the exercise. The template asks for all computer systems used in trial conduct and in the collection and analysis of trial data, excluding Microsoft Office type applications. Hardware and operating systems stay out. The entry goes on the supplied spreadsheet tab, which carries six columns.
| Column | What it asks | What the inspector reads from it |
| eSystem Name | The product as your staff refer to it | Whether the name matches the SOPs and training records |
| Software supplier | The organisation behind the product | Who holds the validation evidence |
| What does it do? | The function, with eTMF, eISF, eCRF, IRT, ePRO, eConsent, eSource, CTMS and QMS given as examples | Which regulatory record it holds, and how closely it is examined |
| Off the Shelf or In House Developed? | One of two values | Where lifecycle responsibility sits |
| eSystem Validation status | Validated, Not validated, or Retrospectively validated | Whether a report exists, and whether it predates go-live |
| Trials with a trial specific release | Trials where you built, configured or validated a release | How much configuration the site owns rather than the supplier |
- Record the version at each upgrade, which turns the column into a change trail rather than a number.
- Write the reason beside the version, which turns an upgrade log into change control evidence.
- Name who performed each validation activity, which answers the “who validated it” column without a contract search.
Also Read: CTMS vs eTMF vs EDC vs eISF: Which System Do You Actually Need?
Worked Inventory Rows for Four Systems a UK Site Runs
Published guidance is written for sponsors and service providers, so worked examples feature electronic data capture and randomisation. A UK site holds a different set.
| eSystem | What it does | Validation status and who holds the evidence |
| Electronic investigator site file | Essential records for each trial, with the delegation log and training certificates | Validated. Supplier pack plus site user acceptance testing, recorded by the R&D quality lead |
| Clinical trial pharmacy system | Receipt, quarantine, dispensing and accountability for each unit of IMP | Validated. Supplier pack, with dispensing workflow testing signed by the trials pharmacist |
| Training record platform | Training completion for delegated staff | Validated. Supplier summary held by workforce development, research office is record owner |
| Hospital electronic patient record | Source clinical data, accessed read only by the research team and by monitors | Validated. Evidence held by the trust digital team and referenced, not reproduced |
Two rows behave differently. The training platform and the hospital electronic patient record were bought for the whole organisation, and the research office is a tenant rather than an owner. Three things follow:
- Name the department holding the validation evidence, which stops the dossier asserting a status the research office cannot produce.
- Record the research specific configuration separately, because a read only research role is a site decision even where the system is not.
- Keep a copy of the supplier summary in the research quality system, so the clock never waits on another department.
Vendor Validation and Site Validation: the Split the Dossier Exposes
“The vendor validated it” answers half the column. ICH E6(R3), adopted at Step 4 on 6 January 2025, states at 3.16.1(d) that computerised systems “should be validated and ready for use prior to their required use in the trial”. At 3.16.1(x)(vi) it expects the sponsor to assess whether systems deployed by the investigator are fit for purpose, and to document that assessment. The MHRA GXP Data Integrity Guidance and Definitions, Revision 1, March 2018, puts it plainly at 3.1: “The organisation needs to take responsibility for the systems used and the data they generate.”
- The supplier proves the software meets its specification, which gives the site a qualification pack to reference rather than repeat.
- The site proves its own configuration meets its own requirements, the part a supplier pack can never cover.
- The site records who may do what, which is what makes the access list match the delegation log.
The method behind each half sits elsewhere: GAMP 5 computerised system validation for the risk based approach, and how to validate an eSource system before first patient in for the site side.
What Validation Evidence Should a Clinical Trial Software Vendor Provide for MHRA?
A vendor should provide the evidence that lets you complete a dossier cell without writing it yourself. Each document below answers a specific question in the template. A compliance statement with no test evidence answers none.
| Ask the vendor for | Dossier question it answers |
| Validation summary or report for the released product | Section 1 Item 3, validation status and who validated it |
| Release notes covering your current version | Section 1 Item 3, version history and reason for change |
| Hosting and data location statement | Section 2 Item 12, server location and what data sits where |
| Audit trail specification | Section 2 Item 12, and the data integrity expectations behind it |
| Change control and notification terms | Section 1 Item 3, future version history entries |
AQ is validated to GxP standards with every release, with installation, operational and performance qualification documentation and a 21 CFR Part 11 and EU Annex 11 assessment, so a site can name in its inventory the specific release it validated against.
Also Read: eSource Software for UK Research Sites: What to Compare Before You Buy
How Do You Complete the Artificial Intelligence and Machine Learning Section?
Version 7.0 carries a dedicated artificial intelligence and machine learning item at Section 2 Item 13. It asks six things of every tool used in the delivery or management of clinical trials:
- The names of the systems or tools used.
- What those tools are used for.
- How long they have been in use.
- Whether they were built in house or purchased.
- How your organisation trains or validates them.
- The documented processes covering revalidation, user training and human oversight.
The September 2026 dossier adds a note on using these tools to prepare the submission itself. The MHRA states that such use is acceptable where appropriate human oversight is maintained, and that organisations remain responsible for ensuring everything submitted is accurate, complete, attributable and a reflection of their actual processes. Two companion guides cover this ground: is it safe to use AI in GxP clinical trial systems? and how AI finds documentation gaps in an investigator site file.
Audit Trail, Access and Oversight of Software-as-a-Service Suppliers
Section 2 Item 12 asks short questions with long answers behind them. The primary sources set the standard each answer is measured against.
| Dossier question | The expectation behind it | Source |
| Who is responsible? | A record of the important computerised systems used in a trial, with an owner | ICH E6(R3) 3.16.1(x)(i) |
| Who may use them? | A record of authorised users, with access granted in accordance with delegations | ICH E6(R3) 3.16.1(x)(iii) and (iv) |
| Are changes traceable? | Audit trails switched on, and users unable to amend or switch them off | MHRA GXP Data Integrity Guidance, 6.13 |
| Where do servers sit? | Cloud systems and providers described, with what data is stored where | Dossier template v7.0, Section 2 Item 12 |
| How is the supplier overseen? | Responsibilities set in a technical agreement, and the provider’s controls evaluated | MHRA GXP Data Integrity Guidance, 6.20 and 6.15 |
| What happens on failure? | A route for providers and investigators to report defects to the sponsor | ICH E6(R3) 3.16.1(x)(v) |
Access is the question most often answered loosely. ICH E6(R3) places a duty on the investigator at 2.12.10 to notify the sponsor when access permissions need to be changed or revoked, which makes the user list a live record. AQ is UK-hosted, which lets a site answer the server location question in one line.
Also Read: UK GDPR for Clinical Trial Sites: What Your Systems Must Do
Reconciling the Dossier Against Your Evidence
A completed dossier is a set of claims. The last task is checking each one against something a person can open during the inspection. Five reconciliations catch most findings:
- Match the inventory against the SOP list at Section 1 Item 2, so every system has a procedure.
- Match the inventory against Section 2 Item 12, so the system count and the ownership story agree.
- Match each stated version against production on the day you submit, and record the date of that check.
- Match each access list against the current delegation log, which is where inspectors find leavers who still hold accounts.
- Match the Section 2 Item 14 answer against the systems that hold those records, because the template warns that failure to provide the file adequately could result in a critical finding.
Every line in the dossier promises that a record exists. Check the record, not the sentence.
Declaring a system that carries an AI feature is a different exercise from choosing one. What to ask a supplier, how to score two shortlisted platforms and what to require in the contract are set out in AI for Compliance and Inspection Readiness: What a UK Site Should Look For in a Platform.
AQ was built by Phase 1 trial doctors for UK research sites and has been in continuous daily NHS use for six years. The platform is designed so the answers a dossier asks for come out of the system rather than a drafting exercise.
- AQ is validated to GxP standards with every release, with installation, operational and performance qualification documentation and a 21 CFR Part 11 and EU Annex 11 assessment, giving a site a named release to cite in the validation status column.
- The platform is UK-hosted, which answers the server location question at Section 2 Item 12 in a single line.
- AQ eISF holds the essential records and AQ Pharmacy holds receipt, dispensing and accountability for each IMP unit, which keeps two inventory rows on one connected record.
- AQ Digital DoA keeps the delegation log live, which is the record the access list is reconciled against.
- AQ QMS holds the procedures governing each system, which is the list Section 1 Item 2 asks for.
- AQ carries NHS DSPT Standards Met (2026), Cyber Essentials certification and ISO 27001-aligned controls.
AQ runs across 13 sites on one connected record and has supported 150+ studies, including at University Hospitals of Liverpool Group, Royal Free London and Liverpool School of Tropical Medicine. To see it in one platform, book a live demo.
Frequently Asked Questions
How do I complete the MHRA computerised systems inspection dossier?
List every computer system used in your trials on the supplied “Section 1.3 Computerised Systems” spreadsheet, giving the name, supplier, function, whether it is off the shelf or in house, its validation status and its version history. Then answer the Section 2 narrative items on ownership, server location, backup, artificial intelligence and the Trial Master File. Reconcile the two before submission.
What validation evidence should a clinical trial software vendor provide for MHRA?
A validation summary or report for the released product, release notes for the version you run, a hosting and data location statement, an audit trail specification, and the change control and notification terms. Those five documents let a site complete the inventory and the Section 2 narrative without inventing an answer.
How long do we have to return the dossier?
Thirty days. The template states the information should be provided within 30 days of the advance notice email date, so the clock runs from that email rather than from the inspection. That email also sets the scope, so read it before assembling anything.
Which systems go in the inventory?
Every computer system used in trial conduct and in the collection and analysis of trial data, with databases, electronic data capture and interactive response technology given as examples. Microsoft Office type applications, hardware and operating systems stay out. A site should still list what it uses daily: the electronic investigator site file, the clinical trial pharmacy system and the training record platform.
Is vendor validation enough?
Vendor validation covers the released software. The site remains responsible for proving the configuration it runs meets its own requirements, and the MHRA data integrity guidance states at 3.1 that the organisation needs to take responsibility for the systems used and the data they generate.
Do spreadsheets count as computerised systems?
The inventory excludes Microsoft Office type applications, so a general spreadsheet stays off the Section 1 Item 3 list. Data integrity expectations are separate: the MHRA guidance states at 6.8 that electronic worksheets used in automation should be version controlled like paper documentation. A spreadsheet running a trial calculation needs that control either way.
