In clinical trials, Electronic Data Capture (EDC) refers to the electronic collection, validation, and management of study-relevant data—typically via a web-based system in which investigative sites, monitors, data management, and sponsors work based on assigned roles. EDC replaces paper-based Case Report Forms and is now the standard for most interventional studies in the EU and internationally.
What is EDC and what data is collected?
The EDC system primarily documents CRF data: basic demographic data, inclusion/exclusion criteria, visit and examination data, laboratory values (manually or via interfaces), medication, adverse events, and endpoint-relevant parameters. EDC is not the “source” of medical reality, but rather a structured reflection of the study documentation that must match the source data at the site. Many systems additionally support the management of queries, data reviews, audit trails, and approval workflows.
Typical Workflow: From CRF to Database Lock
The standard process begins with setup (study configuration, user roles, edit checks, validation plan) and go-live following User Acceptance Testing. During the recruitment and follow-up phase, sites enter data, the system performs automated checks (range checks, consistency rules, visit windows), and queries are generated to be answered by site personnel. Data Management reviews data listings, performs medical coding (e.g., MedDRA/WHO-DD), and manages the cleaning process. Monitoring uses EDC to track open items and document data reviews. The process concludes with data freeze, data review by the sponsor and, if applicable, statistics, followed by the database lock as the formal conclusion of data collection.
Advantages and Risks in Practice
EDC improves data quality through early plausibility checks, reduces transcription errors, and enables near-real-time overviews of recruitment, visit compliance, and data status. At the same time, risks arise: insufficiently configured edit checks can overlook relevant inconsistencies or generate too many irrelevant queries (query fatigue). Common causes of delays include complex forms, unclear data definitions, lack of training, or overly restrictive role permissions. Interfaces (e.g., lab or ePRO integration) also require clean specifications; otherwise, reconciliation efforts arise shortly before the lock.
For sponsors and CROs, it is also relevant how EDC fits into risk-based quality management: critical data and processes (e.g., primary endpoint, SAE reporting, randomization data) should be designed in the system so that deviations become visible early. Dashboards and central data reviews support central monitoring approaches but do not replace clear governance (owners for forms, queries, change control). A common practical error is study teams working without coordinated naming and versioning rules; this makes subsequent changes to forms, visit structures, or code lists difficult to track.
User experience also has a direct impact on quality: if entry masks are not “site-friendly,” the number of missing data points and protocol deviations increases. Successful projects invest in short, role-specific training, clear completion guidelines, and a defined support process (ticketing, response times, escalation). This significantly reduces rework before data freeze and database lock.
Regulations, GCP, and Data Integrity Requirements
EDC systems must fulfill the principles of Good Clinical Practice and data integrity: traceable changes (audit trail), unique user identities, role-based permission assignment, data backup, validation, and documented SOPs. In EU studies, compliance with ICH E6(R2)/E6(R3) is the guiding principle in practice, supplemented by data protection requirements (e.g., GDPR) and, if applicable, 21 CFR Part 11 for studies with a US connection. For sponsors and CROs, it is crucial that system validation is documented using a risk-based approach and that responsibilities (vendor vs. sponsor) are clearly defined contractually and within the quality management system.
Distinction from Related Systems (CTMS, eTMF, ePRO)
EDC is focused on the structured collection of CRF data. A Clinical Trial Management System (CTMS) primarily manages operational processes such as site status, monitoring planning, and budget/payments. An eTMF manages essential documents. ePRO/eCOA systems capture patient-reported outcomes and often deliver data to the EDC via an interface. It is important to clearly define which system is the “system of record” for each data class and how reconciliation processes (e.g., SAE reconciliation between the PV system and EDC) are designed.
FAQ: What are the minimum requirements an EDC system should meet?
At a minimum, role-based user management, audit trail, definable edit checks, query management, export options for statistics (e.g., SDTM-oriented), as well as documented validation and data backup processes are required. Additionally, training records and SOPs for operation and change control are important.
FAQ: Who is responsible for EDC validation—the sponsor or the provider?
The provider typically supplies validation documents and evidence of system development, but the sponsor remains responsible for ensuring the system is appropriately validated for the specific study. In practice, a risk-based approach is used that combines vendor documentation, study-specific testing, and quality oversight.
FAQ: What are typical sources of error in EDC projects?
Common issues include unclear data definitions (e.g., missing units/normal ranges), overly complex forms, insufficiently coordinated edit checks, or training that is too brief. Furthermore, the time required for UAT, data migrations, and interface testing is often underestimated, leading to delayed data freeze and lock dates.
Regulatory References (Selection): ICH E6(R3) Good Clinical Practice (Draft/Final depending on region), EU Clinical Trials Regulation (EU) No. 536/2014, General Data Protection Regulation (EU) 2016/679; for US context: 21 CFR Part 11 (Electronic Records and Electronic Signatures).