REDCap vs CTMS: Where Data Capture Ends and Study Management Begins

REDCap and a clinical trial management system answer two different questions about the same trial. REDCap holds the values a study collects and the audit trail behind each of them. A clinical trial management system holds the conduct of the study around those values: study set-up milestones, delegation, visit scheduling against protocol windows, monitoring visits, protocol deviations and the corrective actions that close them. A team comparing the two is usually deciding which of those two questions it currently has no answer for.

REDCap describes itself on its software page as “a secure web application for building and managing online surveys and databases”. That sentence is exact about scope. Everything a study produces beyond the database sits on the other side of it, and an inspector asks for both halves. This guide covers what REDCap’s own materials state about its purpose and its licensing model, what a study management record holds that a database does not, a direct comparison across nine dimensions, where the gap appears during a monitoring visit, what ICH-GCP E6(R3) asks of each system, whether REDCap can be configured to cover study management, and how to decide which system a team actually needs.

Key Takeaways

• REDCap and a CTMS occupy different layers of the same study, so a like-for-like feature comparison measures them against one specification and neither performs fairly
• What the REDCap consortium publishes about purpose, eligibility, support and compliance responsibility
• The eight conduct artefacts a study produces outside any data capture system
• A nine-dimension comparison, drawn from published sources on both sides
• Two worked examples where the database holds a complete record and the study still has a gap
• The four ICH-GCP E6(R3) provisions that decide where each piece of evidence sits
• What a locally built REDCap study management project achieves, and what the institution owns afterwards

What Is REDCap Built to Do?

REDCap was created at Vanderbilt University in 2004, and the REDCap consortium launched in 2006. The project’s about page describes a “neutral data collection platform, able to capture any type of data, for any purpose”. The published feature set covers audit trails for tracking data manipulation and user activity, branching logic, calculated fields, file uploading, a scheduling module, ad hoc reporting, and automated exports to Excel, PDF and common statistical packages. The same page describes use across “thousands of non-profit and government organizations”, and for the job it names it is a strong piece of software.

The scope boundary matters more than the feature list when the comparison is against study management. The table below places each published capability against the evidence it produces and the conduct question that sits outside it.

Three published positions shape the last row. The consortium FAQ states that “Licenses are ONLY issued to non-profit organizations having sufficient internal IT infrastructure to self-host”. The same FAQ states that REDCap “is definitely capable of compliance with just about any standard”, and places the compliant environment with the institution running the instance. The licence terms state that “no training, support, hosting, or other services from Vanderbilt will be provided under this Agreement”. A research team asked at audit for validation documentation is being asked for documentation it wrote itself.

Also Read: What Is EDC in Clinical Trials?

What Does a CTMS Hold That a Database Does Not?

A clinical trial management system holds the operational record of the study: the plan, the people, the dates, the departures from the plan and the actions that resolved them. Eight artefacts make up that record, and each one exists in every regulated trial whatever database captures the data.

1. Study set-up milestones. The CTMS date-stamps each set-up step against one study record, which lets a research office answer a portfolio question without sweeping folders and inboxes.
2. Delegation of authority. The delegation log records who held which task from which date, which lets a monitor confirm that the person who performed a procedure was delegated to it on the day.
3. Visit scheduling against protocol windows. The system books each appointment against the window the protocol defines, which surfaces drift while the visit can still be moved. Our guide to visit diaries and scheduling inside a CTMS covers the mechanics.
4. Protocol deviations and their closure. Each deviation links to the corrective and preventive action that closed it, which turns an isolated event into a documented control with an owner and a date.
5. Monitoring visits and follow-up letters. Visit reports and their actions sit against the study, which evidences sponsor oversight in the gaps between visits.
6. The investigator site file. An electronic investigator site file holds the essential documents in their current version, which gives an inspector the approved protocol, the ethics approvals and the current CVs in one place.
7. Pharmacy and IMP accountability. The pharmacy site file stays under its own owner and links to the study, which preserves the separation MHRA inspection expects.
8. Training and qualification records. Training maps to the delegated tasks it authorises, which supports each delegation entry directly in place of a separate folder.

Those eight artefacts travel together. A study record that holds seven of them and points at a spreadsheet for the eighth still leaves a reconciliation to perform at every monitoring visit.

REDCap vs CTMS: What Is the Difference?

Nine dimensions separate the two systems in practice. The REDCap column is drawn from the consortium’s published materials, and the CTMS column describes the category rather than any single product.

The database proves the value. The study record proves the visit.

The category-level version of this comparison applies to every data capture platform, and our guide to CTMS versus EDC sets out where the line falls across the wider market.

Where Does the Gap Appear in a Real Study?

The gap rarely announces itself. It appears when a monitor or an inspector asks a question the database was never built to answer, and both of the following examples are hypothetical-but-routine.

The delegation gap. A research nurse performs a study assessment on 14 April and enters the result the same afternoon. The audit trail is complete: the user, the timestamp, the value. The signed delegation log shows that task delegated to the nurse from 2 May. The database recorded everything correctly and the study still has an eighteen-day authorisation gap, visible only where the delegation record and the activity record sit against the same study.

The window gap. A protocol defines a follow-up visit at day 90 with a window of plus or minus 7 days. The visit happens on day 101. The database holds the visit date as entered, and the window itself lives in the protocol. The deviation is identified during monitoring six weeks later, at which point the corrective action addresses a pattern rather than a single visit.

Both examples share one structural feature. The database performed exactly as designed, and the missing evidence was operational rather than numerical. The person changed. The system did not.

What Does ICH-GCP E6(R3) Ask of Each System?

The regulatory position in the UK moved on 28 April 2026, when The Medicines for Human Use (Clinical Trials) (Amendment) Regulations 2025 came into force. The MHRA sets out the effect in its guidance on compliance with ICH E6, and our guide to the 2026 UK Clinical Trials Regulations covers the wider change. Four provisions decide where each piece of evidence has to sit.

The 2025 amendment also changed retention. Regulation 22 amends the trial master file provisions so that trial documentation is retained for 25 years after the conclusion of the trial. A locally hosted instance carries that obligation for its data along with everything else the institution already owns, and a trial master file carries it for the trial documentation. Retention is a system selection question as much as an archiving one.

Also Read: ICH-GCP E6(R3) and CTMS: What Changes for Study Oversight

Can REDCap Be Configured to Do Study Management?

Teams do build study management projects in REDCap, and the approach works up to a point. A project can hold instruments for a delegation log, a deviation register, a monitoring visit form and a milestone tracker, with branching logic and calendar entries behind them. For a single academic study run by a stable team, that configuration answers most day-to-day questions at a cost of a few days’ build.

The obligations that follow the build are the part to price honestly, and every one of them traces to a position the consortium publishes rather than to an opinion about the software.

• The instrument becomes a trial system. A locally built delegation log is a computerised system used in a clinical trial, so E6(R3) Section 9.3 applies to it, and the institution produces the fit-for-purpose evidence.
• Every change enters the local quality system. A field added to a live deviation register is a change to a validated system, which requires change control, testing and a training record inside the institution’s own quality management system.
• Support has an internal ceiling. The licence provides no support from Vanderbilt, so the institution’s IT capacity sets the response time for every study on the instance.
• Cross-study reporting stays a manual exercise. REDCap reporting works within a project, so a portfolio question spanning twelve studies is answered by twelve exports and a spreadsheet.
• Retention runs to 25 years. The 2025 amendment applies to the trial documentation whatever holds it, and a locally hosted instance carries that horizon on institutional infrastructure.
• Commercial sponsorship changes the terms. The consortium FAQ directs commercially sponsored studies led by a for-profit organisation that need a Part 11 maintained system towards REDCap Cloud, which is a separate commercial platform.

A configuration decision made for one study becomes a portfolio commitment by the fourth. The honest test is whether the institution wants to own a validated study management application alongside its database, with the documentation set that goes with it.

Also Read: Clinical Research Audits: Types, Process, Checklist and Audit Readiness Guide

Which System Does Your Team Need?

Two questions settle it in most cases. Does the data collection itself cause problems? Does the record of how the study ran exist anywhere outside a spreadsheet? The first question points at the data layer. The second points at the study management layer, and it produces most of the searches.

• Keep REDCap and add a CTMS where the forms work well and the delegation log, deviation register and milestone dates live in documents. The database stays exactly where it is.
• Replace the data layer where a commercial sponsor requires a vendor-maintained Part 11 environment, or where submission-grade exports and query management are the constraint.
• Do both, in sequence where a growing portfolio has outgrown institutional IT capacity. Add the study management record first, because it leaves historic studies untouched.
• Change nothing where a single investigator-initiated study runs with a stable team, a current paper delegation log and a clean audit history.

A shortlist drawn across the boundary is the common error. A CTMS evaluated on form design and a database evaluated on delegation tracking will each score badly against a specification written for the other. Our guide to REDCap alternatives sets out the products in each category on their own published terms.

How Does AQ Sit Alongside REDCap?

AQ holds the study management layer and leaves data capture where it is. AQ CTMS carries study set-up, milestones, recruitment and visit scheduling as one operational record, so a date is entered once and read wherever it is needed. REDCap keeps the trial data, and the record of how the study ran becomes the thing a monitor, a sponsor and an inspector all read.

• AQ Digital DoA records delegation with effective dates mapped to training evidence, which closes the authorisation gap described earlier before it forms.
• AQ eISF holds essential site documents in a controlled electronic investigator site file, which lets a monitor review between visits.
• AQ ePSF keeps pharmacy accountability in a separately owned file linked to the study, which preserves the separation inspection expects.
• AQ CAPA links each deviation to the action that closed it, with an owner and a due date against the study.
• AQ eTMF is built on the DIA TMF Reference Model, which gives sponsor and site a shared structure to reconcile against.

The fit is common in academic research units and NHS and hospital research teams that keep an established database and need the operational record alongside it. AQ is available through G-Cloud, submits the Data Security and Protection Toolkit, holds Cyber Essentials, and releases validation, data protection and governance evidence to institutional teams as an assurance pack. The connected platform holds all of it against one study record.

See the delegation log, the visit window check and the deviation trail behave against a study you already run in REDCap. Book a live demo and bring the artefact list from this guide.