Clinical research software is the set of validated systems a study team uses to plan, run, document and evidence a clinical trial. The category covers study operations, participant data, sponsor and site documentation, pharmacy accountability, quality management and delegation. Each system holds one part of the study record.
Selection normally turns into a feature comparison between vendors. A narrower test decides more. Every system leaves a record behind, and an inspector reads those records together. This guide covers the systems that make up a research software stack, the 2026 rule changes that alter what each system has to produce, and a selection method that scores systems on the evidence they leave.
What Is Clinical Research Software?
Clinical research software is purpose-built for regulated study conduct. General business tools store information and move it between people. Clinical research software has to prove who did what, when, under whose authority, and against which version of the protocol. That evidential duty is the whole difference, and it sets four properties every system in the stack has to hold.
- An audit trail records every creation, change and deletion with the user, the timestamp and the reason, which lets a reviewer reconstruct a record without asking the person who made it.
- Access control ties each permission to a delegated role, which keeps activity inside the authority the delegation of authority log grants on that date.
- Validation evidence shows the system does what its specification says, which is the assurance an MHRA inspector asks for. The GAMP 5 approach to computerised system validation sets out the deliverables that evidence takes.
- Retention and export control keeps records readable and exportable for the full archive period, which protects the study record beyond the length of the vendor contract.
Those four properties are the reason a shared drive fails as clinical research software. The data integrity expectations behind them run under the label ALCOA+, and they apply to the system holding a record as much as to the record itself.
Which Systems Make Up a Clinical Research Software Stack?
A study rarely runs on one system. Fifteen categories cover the stack found across UK research, from the systems every trial touches to the specialist systems larger or more complex trials add. Each one owns a distinct part of the evidence. The useful question for each row is the last column: name the record that system has to produce on request.
| System | What it holds | Who works in it | The record it must produce |
| Clinical trial management system (CTMS) | Study set-up, sites, recruitment, the visit diary, milestones | Study coordinators, research managers | Visit and recruitment history against protocol windows |
| Electronic data capture (EDC) | Participant data entered against the case report form | Data entry staff, monitors, data managers | The clinical dataset with its query and correction trail |
| Electronic trial master file (eTMF) | Sponsor and CRO essential documents for the whole trial | Sponsor, CRO document teams | Completeness against the DIA TMF Reference Model |
| Electronic investigator site file (eISF) | Essential documents held at each participating site | Site teams, monitors | Current filed evidence at the trial location |
| Electronic pharmacy site file (ePSF) | IMP receipt, storage, dispensing, return and destruction | Research pharmacy | Unbroken accountability for every unit of study drug |
| Quality management system (QMS) | SOPs, controlled documents, training and competency records | QA leads, research governance | The SOP version in force and who was trained on it |
| CAPA system | Findings, root cause analysis, actions, effectiveness checks | QA leads | Closure evidence showing the fix held |
| Digital delegation of authority | Roles, qualifications, signatures and delegation dates | Principal investigators, coordinators | Who held authority on the day each task was performed |
| Interactive response technology (IRT) | Randomisation, allocation concealment, supply logistics | Sponsor, pharmacy, depot | Allocation and supply chain history per participant |
| ePRO and eCOA | Participant-reported outcomes and clinical outcome assessments | Participants, site staff | The participant entry with its original timestamp |
| eConsent | Electronic informed consent capture and version control | Site staff, participants | The consent version signed, by whom, and when it was withdrawn or re-consented |
| Safety and pharmacovigilance database | Adverse event and SAE case data, coding, expedited reporting | Safety officers, medical monitors | Case narratives and reporting timelines measured against regulatory deadlines |
| Regulatory information management (RIM) | Submission tracking, licence status, regulatory correspondence | Regulatory affairs | Current approval status per country and per amendment |
| Learning management system (LMS) | Protocol and GCP training modules, competency assessments | Site staff, sponsor teams | Completion records tied to the SOP or protocol version trained on |
| Site payments and study finance | Milestone invoicing, participant reimbursement, site payment schedules | Finance, research operations | Payment history reconciled against completed visits and milestones |
Statistical analysis packages, patient registries and risk-based monitoring tools sit alongside this list. Those tools read from the study record and hold no governed part of it, which puts them outside the set of systems an inspection normally opens first.
Also Read: The Ultimate Guide to Understanding What is a CTMS
What Does Each Role Actually Need From Clinical Research Software?
The “who works in it” column above names a role. It does not say what that role is trying to get done. A study coordinator and a QA lead can use the same CTMS and still need almost nothing in common from it, and a stack chosen against one role’s needs alone will under-serve the other six.
| Role | What the software has to give them | Where it usually sits |
| Principal investigator | Oversight sign-off across recruitment, delegation, deviations and CAPA, without collating separate exports first | CTMS, delegation record, CAPA |
| Study coordinator / CRC | A visit diary that applies the protocol window at the point of booking, current consent status, and their own delegated task list | CTMS, delegation record |
| CRA / monitor | Source-to-record match that is ready before a monitoring visit starts, not assembled the week before it | eISF, eTMF |
| Data manager | Query status against the live dataset and a full correction trail with the reason for each change | The study’s EDC, cross-checked against site records |
| QA / regulatory lead | SOP version history and training currency mapped to the findings raised against them, ready as inspection evidence | QMS, CAPA |
| Sponsor or CRO project manager | One oversight view across every site and system, instead of a status call per vendor per month | A connected platform spanning every module |
| Pharmacist / pharmacy technician | Unbroken IMP accountability from receipt through dispensing to destruction, traceable back to the delegation that authorised it | Pharmacy site file |
Read down the middle column and the pattern is the same for every role: each one needs a narrow, current slice of a record that other roles are also editing. Software chosen on features rarely tests that. Software chosen on records does, because the question “who owns this record, and who else touches it” forces the role-by-role need into the open before contracts are signed.
How Do Software Needs Differ By Research Institute Type?
Role explains what an individual needs from the software. Institute type explains what the organisation around them needs. A university department, an NHS trust, a CRO and a sponsor run the same categories of system under very different pressure, and a stack that fits one can be the wrong shape for another.
| Institute type | Where the pressure sits | What to prioritise in the software |
| Academic and university sites | Studies span multiple departments, investigators and study types, each running under its own funding and governance | One connected record across investigators and departments, with consistent access control rather than a separate spreadsheet per study |
| NHS trusts and hospital sites | Portfolio scale and R&D governance sign-off sit alongside frontline clinical duties, with the 90-day set-up target measured nationally | A visit diary and delegation record that remove manual chasing, plus assurance evidence such as DSPT and Cyber Essentials ready for trust governance |
| CROs | Multiple sponsors, multiple protocols and multiple site networks run in parallel, each with its own reporting line | Data segregation between sponsors inside one platform, and a single oversight view instead of a separate tool per study |
| Sponsors and pharma | Oversight of delegated execution across CROs, sites and vendors, without building enterprise-scale infrastructure on day one | Sponsor-visible status across every delegated party and one governed audit trail that spans vendors |
The differences are structural, not cosmetic. An academic site needs the same record type held consistently across investigators who each run their study slightly differently. A CRO needs the opposite: strict separation between sponsors inside one system, so oversight for one client never surfaces another client’s data. Read the institute-type column against the role table above and the software decision moves from “which vendor has the most features” to “which vendor’s record model matches how our organisation is actually structured.”
Also Read: Case studies from NHS, academic and CRO research teams
What Changed in 2026 That Affects the Software You Choose?
The UK regulatory position moved on 28 April 2026. The Medicines for Human Use (Clinical Trials) (Amendment) Regulations 2024 came into force on that date, and the Health Research Authority describes it as the largest change to UK clinical trials regulation in over twenty years. ICH-GCP E6(R3) came into force in the UK alongside it. Selection criteria written before 2026 miss both.
Six changes land directly on the systems a study runs on.
| What changed | What your systems now have to produce |
| Trial registration and publication of a summary of results became a legal requirement for the first time, with results due within 12 months of trial end | A reliable, retrievable trial end date and a results record that can be assembled inside the 12 month window |
| Amendments became modifications, classified as substantial, important detail, or minor | A version history showing which document version was live on which date at each trial location |
| A notification scheme created a faster route for the lowest-risk trials, and eligible modifications under Route B are approved automatically unless concerns are raised within 14 calendar days | Risk documentation held against the study record, with modification dates tracked to the day |
| ICH-GCP E6(R3) Principles and Annex 1 took effect on 23 July 2025 and now apply in the UK | Data governance across the full data life cycle, including systems operated by vendors and service providers |
| E6(R3) Annex 2 takes effect on 15 January 2027 and covers decentralised and pragmatic designs and real-world data sources | Records from decentralised activity captured in the same audit-trailed environment as site activity |
| An approved trial must recruit its first UK participant within two years or the approval lapses | Set-up milestone dates tracked from approval, per site, without a manual chase |
The published ICH E6 guideline and its annexes sit on the European Medicines Agency site, and the consolidated version was issued on 15 July 2026. Test any vendor claim about GCP alignment against that document.
The two year recruitment condition is where UK set-up performance stops being an internal metric. National reporting already tracks the same ground through the UK clinical research delivery KPIs, and most NHS sites still miss the 90-day set-up target. Systems that hold approval dates, contract dates and first participant dates in one place turn that condition into a tracked milestone.
Also Read: What is Inspection Readiness in Clinical Trials and How Does It Work Across a CRDC Network?
Where Does Disconnected Software Cost a Study?
The cost of a fragmented stack shows up at the seams. A worked example makes it concrete. Northgate General, a fictional NHS trust, runs an interventional study with a protocol visit window of 21 to 28 days after randomisation. One participant attends on day 29.
Five systems hold part of that single visit, and each holds it correctly.
- The CTMS diary shows the appointment booked for day 29, with no flag raised at the point of booking.
- The EDC record shows the visit data entered against the day 21 to 28 window, queried by a monitor five weeks later.
- The pharmacy file shows one IMP unit dispensed on day 29 against a prescription signed by a registrar.
- The delegation record shows that registrar’s delegation countersigned three days after the visit.
- The quality system holds a deviation raised for the out-of-window visit, with no link to the delegation record or the dispensing entry.
Each record is accurate. Reconstruction of the event takes a QA lead five separate exports and a spreadsheet. That reconstruction is the real cost, and it recurs at every monitoring visit, every audit and every inspection for the life of the study.
Every system leaves a record. An inspection reads them together.
Visit windows are the clearest example because the rule is numeric and the breach is provable. The same pattern runs through consent versions, training currency and IMP temperature excursions. A visit diary that applies the protocol window at the point of booking removes the deviation instead of documenting it.
How Should You Choose Clinical Research Software?
Two selection methods dominate. The first compares feature lists and scores vendors on coverage. The second starts from the records the study has to produce and asks which system owns each one. The second method predicts operational cost far better, because it prices the work that sits between systems.
| Aspect | Feature-led selection | Record-led selection |
| The opening question | Which system has the most functions? | Which records must this study produce, and who owns each? |
| What the demo shows | A generic feature tour on the vendor’s sample study | Your protocol, your site set-up, your documentation requirements |
| What decides the score | Coverage against a requirements matrix | The joins between systems and the evidence they leave |
| Integration treated as | A later project with its own budget line | A selection criterion tested during evaluation |
| What happens at inspection | Separate exports reconciled by hand | One retrieval path per record, traceable to its owner |
| Where the cost lands | Licences, then unplanned reconciliation effort | Licences, with reconciliation effort designed out |
Record-led selection runs as seven steps.
- List the records the study must produce. Start from the essential documents, the delegation log, the visit history, the IMP accountability chain and the deviation register. The list is the requirement specification.
- Assign one owning system to each record. Shared ownership creates reconciliation work, so a record with two owners is a design defect.
- Test the joins. Ask each vendor to show one event moving across two modules, which exposes whether the join is a live link or a nightly file transfer.
- Request the validation package. Read the specification, the test evidence and the change control process, which tells you what re-validation costs after every release.
- Check the access model against delegation. Permissions that follow the delegation log keep authority and activity aligned, which removes a common source of inspection findings.
- Price the reconciliation work. Licence cost is visible and staff time is not, so cost every manual export the design leaves in place. Guidance on the visible half sits in the CTMS cost breakdown.
- Read the exit and archive terms. Confirm the export format, the retention period and the cost of extraction at contract end, which protects the record after the relationship changes.
The system you choose sets how much reconciliation your team performs for the next five years.
Also Read: AQ vs Veeva, Florence, RealTime and SharePoint: Choosing Connected Clinical Trial Software
What Should a Software Demonstration Prove?
A demonstration built on a vendor sample study proves very little. Send your protocol synopsis and your site structure in advance, then ask the vendor to perform seven tasks in front of you.
- Book a visit outside the protocol window and show what the system does at the moment of booking.
- Add a new coordinator, delegate two activities, and show the audit trail entry that records the change.
- Produce the delegation position as it stood on a date three months ago.
- Supersede an SOP and show which open findings now reference the previous version.
- Dispense an IMP unit and trace it back to the shipment and forward to the destruction record.
- Export the essential document index for one site in the structure a monitor expects.
- Show the full audit trail for a single participant record, including deletions.
Failure on any of the seven is informative. A vendor who needs a follow-up call to answer the delegation question is telling you the join runs through a spreadsheet.
How Does AQ Connect Clinical Research Software Into One Record?
The AQ Platform connects seven modules in one controlled environment, so one study record covers operations, documentation, pharmacy and quality. Each module owns a defined part of the evidence, and the modules share one access model, one audit trail and one set of study data.
- AQ CTMS holds study set-up, site records, recruitment and the visit diary, which measures every booking against the protocol window at the point the booking is made.
- AQ eTMF is built on the DIA TMF Reference Model, which gives sponsor, CRO and site the same filing structure and one completeness figure to report against.
- AQ eISF and AQ ePSF hold site documentation and pharmacy accountability under that same access model, which puts the site file and the IMP chain in one place before a monitoring visit opens.
- AQ QMS and AQ CAPA link SOP versions and training records to the findings raised against them, which shows an inspector the version in force on the day of the event.
- AQ Digital DoA records delegated roles, qualifications and signatures with their dates, which ties each recorded activity to the authority that existed at the time.
AQ is aligned with Good Clinical Practice, UK GDPR and 21 CFR Part 11, and supplies validation, data security and governance evidence for NHS and sponsor procurement. Assurance covers G-Cloud, DSPT and Cyber Essentials.
Book a live demo and the walkthrough runs on your protocol structure, your site set-up and your documentation requirements. The session follows your operational priorities.
