Edge vs a Connected CTMS: What NHS R&D Teams Should Know

Edge is a research management system that holds an organisation’s research portfolio. A clinical trial management system (CTMS) holds the conduct of the individual studies inside that portfolio. The two systems answer to different obligations, so most NHS R&D offices end up running both. The Edge vs CTMS question therefore resolves into a narrower one: which job belongs in which system.

Edge describes itself on its own about page as “a cloud-based clinical research management system”, developed by the Clinical Informatics Research Unit at the University of Southampton, which “provides research professionals with faster access to real-time data, allowing them to track and manage their studies from start to finish as well giving them complete oversight of their participant recruitment”. A CTMS occupies a narrower and deeper position: study set-up milestones, visit scheduling against protocol windows, delegated authority, essential documents, deviations and investigational product accountability, held against one study record.

This guide sets out what each system is in published terms and the two obligations that separate them. It then allocates the work an NHS R&D office actually does, job by job, prices the cost of letting two systems own one record, counts the systems an inspector can be asked to open, and closes with a decision rule a research office can apply this week.

What Is Edge and What Is a CTMS?

Accuracy matters more than positioning in a category comparison, so both descriptions below come from published material. Edge’s capabilities and origin are taken from its own features page and its about page. Two caveats apply equally to both columns. A features page is a marketing summary and not a capability inventory, so any team should confirm scope with the supplier directly. The CTMS column is a category description, and any individual product should be assessed against it rather than assumed to meet it.

The overlap is real and it is the source of the confusion. Both categories hold documents. Both hold study records. Both hold something called a delegation log. The categories separate on what each one is accountable for producing, and that accountability comes from outside the software.

The Two Obligations Behind the Two Systems

An NHS research office carries two distinct duties, and each one has a different auditor. The first duty is national delivery reporting. The UK clinical research delivery key performance indicators methodology states the mechanism plainly: “Study data in the CPMS is either entered directly into the system by sponsors or is recorded in a local portfolio management system (LPMS) by research staff.” A local portfolio management system carries the trust’s half of national reporting. Edge holds that role widely, and its UK page states “12 out of 15 LCRNs (Local Clinical Research Networks) utilising EDGE, resulting in over 80% of NHS trusts on board”, a figure that describes the network structure preceding the current NIHR Research Delivery Network.

The second duty is good clinical practice conduct. Compliance with the ICH E6 good clinical practice principles became a legal requirement in the UK on 28 April 2026 under the amended UK Clinical Trials Regulations. The MHRA guidance on ICH E6 compliance states that “Compliance with the ICH E6 GCP Principles (as amended from time to time) and not the entirety of the guideline becomes a legal requirement in the UK on 28 April 2026”, and adds the UK-specific principle that “The investigator and sponsor must have regard to all relevant guidance with respect to commencing and conducting a clinical trial.”

One obligation is measured in dates. The other is measured in evidence.

A system built for the first obligation performs well against it. The second obligation applies to the same studies at the same time, and it asks for a different shape of record. A research office that treats the two duties as one will satisfy whichever obligation its systems were arranged around, and meet the other for the first time during an inspection.

Also Read: CPMS and LPMS: What Sites Must Enter and When

Which System Owns Which Job?

The Edge vs CTMS comparison becomes useful at the point it allocates work instead of ranking products. An NHS R&D office performs fourteen recurring jobs across a study lifecycle. Each one has a natural owner, and the reason for that ownership is the obligation the job serves. The table below allocates each job and names the record that proves it was done.

Five jobs belong to the portfolio system because national reporting runs through it. Eight belong to the conduct record because an inspector reads them against one trial. The final row belongs to whichever system holds the record, which is exactly why the allocation has to be decided rather than left to emerge.

Two points of fairness apply to that table. The allocation describes where a job belongs, and it makes no claim about which products can perform it. Edge names electronic delegation logs and version-controlled document management on its features page, so a portfolio system may well hold those records capably. The rule at issue is single ownership rather than capability: the delegation log belongs with the record an inspector reads for trial conduct, and every other system should reference it instead of keeping a second copy.

What Happens When Two Systems Hold the Same Record?

One rule governs every boundary between a portfolio system and a conduct record. Any record that two systems both claim to own will eventually disagree, and the disagreement surfaces in front of a monitor. The delegation of authority record is where this happens most often, because both categories have a legitimate reason to hold one.

Consider a hypothetical but routine sequence at Northgate General NHS Foundation Trust, on study NG-2026-041 at SITE 01. Every entry below is correct inside the system that holds it.

• 2 March. Research nurse J. Okafor is added to the delegation log in the portfolio system, with informed consent among the listed tasks.
• 6 March. The principal investigator signs the delegation log held in the site file. The consent task is left unsigned pending a good clinical practice refresher.
• 12 March. Participant 014 is consented by J. Okafor at the screening visit.
• 19 March. The refresher is completed and recorded in the trust learning management system.
• 24 March. The site file delegation log is countersigned, the consent task is signed, and the start date is entered as 2 March to match the portfolio system.
• 11 June. A monitor compares the two logs and finds one consent visit supported by three different dates.

The 24 March entry is the one that will draw the finding, and it is also the most understandable act in the sequence. A coordinator tidying a log to agree with the system next to it is doing what the absence of a single owner asks of them. The portfolio entry recorded an operational decision on the day it was taken. The site file entry recorded a signature on the day it was given. The learning management system recorded a completion on the day it happened. Three accurate records produced one contradiction, because no system was accountable for holding them in agreement.

The dates were all true. The record had two owners.

ICH E6(R3) Annex 1 places the expectation on the investigator directly. Section 2.3.2 states that “The investigator should ensure that persons or parties to whom the investigator has delegated trial-related activities are appropriately qualified and are adequately informed about relevant aspects of the protocol”, as set out in the MHRA UK-specific annotations to ICH E6(R3). A delegation record held in two systems gives the investigator two answers to that question and no way to choose between them.

How Many Systems Must an Inspector Be Given Access To?

This is the question most system comparisons leave out, and it is the one with a published answer. MHRA guidance on good clinical practice inspections states that “The complete TMF is the basis for inspection and all the records in it must be made available to the inspectors”, and that “Failure to provide the TMF will affect the results of your inspection”. The operative sentence for a multi-system estate follows: “Where multiple electronic systems constitute the complete TMF direct access must be made available to each system.” The guidance also states that “You’ll need to provide any equipment and software needed to access any electronic records.”

Every additional system in the evidence path becomes an access obligation on the day an inspection is announced. The obligation is practical rather than theoretical, and it lands on the R&D office.

• An account per system, provisioned in time. Each system needs a read-only inspector role created and tested before the visit, which turns system count into lead time.
• Validation evidence per system. ICH E6(R3) Principle 9.3 states that “Computerised systems used in clinical trials should be fit for purpose (e.g., through risk-based validation, if appropriate)”, quoted in the MHRA compliance guidance, so each system in the path carries its own computerised system validation evidence.
• An audit trail per system. Each system must show who changed a record and what it previously said, which means the weakest audit trail in the chain sets the standard for the whole answer.
• A mapping document across systems. An inspector navigating several systems needs an index that states which record lives where, and that index becomes a maintained artefact in its own right.
• A reconciliation before every visit. Records duplicated across systems have to agree on the day, which converts a standing state into a recurring project.

System count is therefore a compliance variable rather than an IT preference. A trust choosing between one connected conduct record and five capable but separate systems is choosing between one access obligation and five.

Also Read: CTMS for NHS R&D: Choosing an Inspection-Ready Platform

Which Records Fall Between the Two Systems?

Some records belong to neither obligation by default, so they settle wherever a team put them first. These are the records that generate the mapping document, and they are worth locating explicitly before an inspection forces the exercise.

• Pharmacy accountability. Receipt, storage temperature, dispensing, return and destruction records for investigational product frequently sit in a pharmacy department file, which puts a second department and a second retrieval route into the inspection path.
• Training certificates. Certificates usually live in a trust learning management system with no link to the delegated role, so an expiry passes without changing anyone’s authority to perform the task.
• Deviations before they become findings. A local deviation log in a spreadsheet records the event and stops there, which leaves root cause, action and effectiveness check outside any controlled system.
• The expected document list. A repository reports what it holds, and completeness requires a statement of what the trial should hold at its current stage, which is a different function from storage.
• The site file index itself. A local folder structure follows local habit rather than the DIA TMF Reference Model, so a sponsor monitor reconciles two differently shaped files by hand at every visit.

ICH E6(R3) Annex 1 sets the retention expectation on all of it. Section 3.16.3(a) states that “Essential records should be retained securely by sponsors and investigators for the required period in accordance with applicable regulatory requirements”, which the MHRA annotations tie to regulation 31A of the Clinical Trials Regulations. Records that fall between systems still carry that duty, and no system has accepted it.

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

How Should an NHS R&D Team Decide?

The decision resolves through six tests rather than a feature comparison. Run each one against the systems already in place, with a real study open on screen, and record the answer.

1. Name the single owner of the delegation record. One system holds it and every other system references it. Two owners is the finding waiting to happen.
2. Ask for one trial’s expected document list with absences shown. A list of what is held answers a storage question. A list of what is missing answers the readiness question.
3. Count the systems in the evidence path for one participant visit. The count is the number of direct-access obligations the trust carries at inspection.
4. Trace one deviation from detection to verified effectiveness check. The closure evidence and the check that confirmed the fix held should sit in the same record as the event.
5. Test one delegated task against its training expiry. The two records should resolve together on one screen, at the date of the task rather than today’s date.
6. Check where national reporting is entered. Milestone and recruitment fields stay with the LPMS, because the exchange with CPMS runs from it and replacing that pathway adds risk with no benefit.

Put those tests to every candidate on the same terms, the incumbent included. A trust that passes tests one to five in its current estate has no gap to close. A trust that reaches for a spreadsheet or a shared drive on test two or four has found the boundary, and the answer is an addition to the estate rather than a replacement of the portfolio system. Teams weighing that decision more broadly can work through Edge alternatives for NHS research, and academic teams starting from a data capture system face the equivalent question in REDCap vs CTMS. The wider category question is covered in our guide to what a CTMS is.

Where Does AQ Fit Alongside Edge?

AQ is a connected platform for NHS hospital research that holds the conduct obligation while the portfolio system keeps the reporting obligation. The modules share one study record, so an answer given in one module holds in the others without a reconciliation step.

• The CTMS holds study set-up, capacity and visit scheduling against the protocol windows, which keeps operational activity and the evidence of it in the same record.
• The eISF holds the site file in the DIA TMF Reference Model structure and reports expected documents that are absent, which gives the R&D office a completeness position on any day rather than the week before a visit.
• Digital DoA ties each delegated task to a named individual, a date range and a signature, and reads training expiry against the role, which surfaces a lapse before it becomes a finding.
• The ePSF holds pharmacy receipt, storage, dispensing and destruction against the same study record, which removes the separate pharmacy retrieval route from the inspection path.
• CAPA carries a quality event from detection through root cause and actions to a verified effectiveness check, which produces closure evidence a monitor reads in one place.

AQ is designed to sit alongside a local portfolio management system. National reporting continues through the existing pathway, and the evidence layer gains a single governed structure with one audit trail. AQ is Cyber Essentials certified, maintains an NHS Data Security and Protection Toolkit submission, and is available through G-Cloud, so most NHS teams can procure through a framework they already use.

See how one inspection question resolves across the site file, the delegation record and the pharmacy file in a single study record. Book a live demo with our team.