Electronic data capture in clinical trials is how sites, monitors, and data managers collect, check, and store study data in one controlled system instead of on paper. An electronic data capture (EDC) system holds the electronic case report forms (eCRFs) that record each participant's data, runs validation checks as data is entered, tracks every query and change, and prepares the database for lock and analysis. This guide explains how EDC works across the life of a trial, which features matter, how it connects to other clinical systems including imaging, and what to weigh when you choose one.
Electronic data capture is the software layer where a clinical trial's protocol-specified data is recorded in electronic form. Sites enter visit data, lab results, adverse events, and assessments into eCRFs, and the system stores them in a structured, auditable database. As Greenlight Guru describes it, an EDC system streamlines collecting, storing, and securing data from clinical studies, while the eCRF is the digital version of the case report form that researchers use to record data about each participant.
In a clinical trial, EDC does more than replace paper. It is the system of record for most of the data that will support the trial's primary and secondary endpoints. Its design decides how quickly errors are found, how confidently a sponsor can say data are complete, and how smoothly a study moves from the last participant visit to database lock. It is used most heavily by clinical data managers, clinical research associates, study coordinators at sites, and the biostatisticians who receive the clean data.
It helps to separate three terms that are often blurred. The eCRF is a single form. The EDC system is the platform that hosts the forms, the rules, and the audit trail. A clinical trial management system (CTMS) is a different tool that manages operations such as site activation, visits, and milestones. Each has its place in a trial, and they work best when connected.
Whatever the vendor, the EDC workflow follows the trial itself. It starts before the first participant is enrolled and ends when the database is locked and handed to analysis. The five steps below are the same regardless of therapeutic area, although the amount of work in each step varies with the phase of the study. If you want context on how trial stages differ, see our guide to clinical trial phases.
Study build begins with the protocol. Data managers translate the schedule of assessments into eCRFs, define which fields are required, set the allowed ranges and units, and write the edit checks that will run during data entry. Roles and permissions are configured, and the build is tested through user acceptance testing before any site goes live. A careful build matters because every later change to a live study needs documentation and often a version change. Teams that invest time in design, and that align with standards such as CDISC CDASH, tend to avoid rework downstream.
Site staff enter data directly into the eCRFs at or soon after each visit, ideally from source records. Increasingly, data also arrives from connected systems rather than manual entry: central laboratories, electronic patient-reported outcomes, wearable devices, randomization systems, and imaging platforms. Each source needs a defined transfer, a mapping to the study database, and a reconciliation step so that the EDC and the outside data agree.
Edit checks run as data is entered and flag values that are out of range, inconsistent with other fields, or missing. Further checks run in batch across the whole database. When a discrepancy needs a human answer, a data manager or monitor raises a query, the site responds or corrects the record, and the reviewer closes it. Every step is time-stamped in the audit trail. Well-designed checks reduce the volume of queries, and clear query rules keep sites from being flooded with low-value questions.
Monitors compare eCRF entries against source documents, and data managers review listings and trends to find patterns that automated checks miss. Risk-based monitoring approaches focus that effort on the data points and sites that matter most to participant safety and endpoint reliability. Coding of adverse events and medications, reconciliation of serious adverse event data, and medical review all happen in this phase, and open items are worked down as the study progresses rather than left until the end.
Database lock is the point at which the data are declared complete and clean, and further changes are blocked. Before that, teams confirm that queries are closed, external data are reconciled, coding is final, and required sign-offs are in place. After lock, the data is exported in analysis-ready form for biostatistics and regulatory reporting. A locked database with a complete audit trail is what allows a sponsor to stand behind its results.
Feature lists can look identical across vendors, so it is more useful to ask what each capability changes for a trial team. The table below links the core features to their practical value.
| Feature | What it does in a trial | Why it matters |
| eCRF design and versioning | Forms mirror the protocol schedule, and changes are versioned so every site collects the same data in the same way. | Protocol amendments do not break data already collected, and reviewers can see which form version applied to each visit. |
| Edit checks and validation | Range, logic, and cross-form checks fire at data entry and flag inconsistent or missing values. | Errors are caught while the site still has the participant record, which is cheaper than fixing them months later. |
| Query management | Data managers and monitors raise queries in the system, and sites answer them against the record. | Each discrepancy has an owner, a response, and a timestamp, which keeps cleaning traceable. |
| Audit trail and electronic signatures | Every entry, change, and sign-off is recorded with user, time, and reason. | Inspectors can reconstruct who did what, which is a core expectation of GCP and electronic records rules. |
| Role-based access | Sites, monitors, data managers, and sponsors see only what their role allows. | Blinding and data protection hold up across many sites and organizations. |
| Reporting and monitoring views | Dashboards show enrollment, missing data, open queries, and site performance. | Teams spot lagging sites early and can target monitoring instead of reviewing everything. |
| Data export and standards support | Clean data exports in structured formats aligned with standards such as CDISC. | Biostatistics can move from a locked database to analysis without rebuilding datasets by hand. |
Taken together, these features support the two outcomes sponsors care about most: data that can be trusted and a timeline that does not slip at the end. Better data quality and faster cleaning are the direct results of catching problems at entry and keeping every query visible.
An EDC system is one component in a larger set of tools. The CTMS tracks operations, the electronic trial master file (eTMF) holds essential documents, randomization and supply systems manage assignment and drug logistics, safety databases handle adverse event reporting, and specialist platforms handle data types that do not fit neatly into a form. Imaging is the clearest example.
Imaging trials produce large DICOM datasets that are managed, quality-controlled, and read in dedicated imaging systems. The results of those reads, such as a lesion measurement or a response category, are then transferred to the EDC so they can sit alongside clinical data for analysis. Getting that handoff right depends on agreed data specifications, consistent participant and visit identifiers, and reconciliation between the two systems. For more on how the pieces connect, see our guide to medical imaging workflow, and how an integrated imaging toolchain supports trial teams. Our article on medical imaging data explains what those datasets contain and why they need their own infrastructure.
For a broader view of how imaging and clinical data work together in modern studies, download our white paper, Modernizing Image-Driven Clinical Research.
Compliance is not a feature checklist. It is a set of expectations about how electronic records are created, changed, and kept, and an EDC system is one of the main places where those expectations are met or missed.
In the United States, 21 CFR Part 11 sets criteria under which the FDA considers electronic records and electronic signatures trustworthy and equivalent to paper. The FDA also provides guidance on the scope and application of Part 11. In Europe, EU Annex 11 covers computerized systems in regulated environments. Across regions, ICH GCP expects that trial data are attributable, legible, contemporaneous, original, and accurate, often summarized as ALCOA principles, and that systems used to handle them are validated.
In practice, this translates into several questions a sponsor or CRO should be able to answer for any EDC system:
For the imaging side of these expectations, read our guide to clinical trial imaging compliance, which covers how similar principles apply to image handling and review.
Choosing an EDC platform is easier when you begin with the trial rather than the product. The questions below help separate systems that look good in a demo from systems that hold up in a live study. Advarra offers a useful introduction to the topic for teams new to EDC.
Implementation succeeds when the data management plan, eCRF completion guidelines, and query rules are agreed before go-live, and when roles are clear between sponsor, CRO, and sites. Piloting the build with a small number of sites can surface problems while they are still cheap to fix.
EDC remains the core of clinical trial data management, but the trials it supports are changing. More data now originates outside the visit form, from imaging, devices, and remote assessments, and more decisions depend on seeing all of it together. The practical goal for trial teams is a data flow in which each system does its own job well and hands clean, traceable information to the next.
Teams that treat EDC as one part of a connected environment, with clear specifications, shared identifiers, and reconciliation built in, spend less time chasing discrepancies and more time on the science. If your trials depend on imaging endpoints, the imaging platform and the EDC need to be planned together. Talk to the Collective Minds team about how imaging data can fit cleanly into your trial data flow.
Electronic data capture is the use of a validated software system to collect, manage, and store trial data in electronic form. Sites enter participant data into eCRFs, the system checks it against rules, records every change in an audit trail, and prepares clean data for database lock and analysis. It replaces paper case report forms and is the main system of record for clinical data in most trials.
An EDC system is the platform that hosts the forms, validation rules, queries, user roles, and audit trail. An eCRF is a single electronic form within that platform, used to record the data required by the protocol for a participant at a given visit. A study typically has many eCRFs, all managed inside one EDC system.
No regulation requires EDC for every trial, but it has become the standard because it supports data quality, traceability, and timely cleaning. Regulators care that trial data are reliable and that electronic systems meet requirements such as those in 21 CFR Part 11 and ICH GCP. Small or simple studies sometimes use other approaches, but most sponsored and multi-site trials rely on EDC.
eSource refers to data that is captured electronically at the point of origin, such as an electronic health record entry or a device reading, and treated as the source record. EDC is the system where trial data is recorded and managed for the study. In some workflows, eSource data flows into EDC directly, which reduces transcription. In others, sites still transcribe from source into the eCRF and monitors verify it.
Reviewed by: Pilar Flores Gastellu on September 30, 2026