EDCElectronic Data Capture

Electronic Data Capture (EDC) is the software system clinical trials use to capture, manage, lock and export the data that supports a regulatory submission. The data instrument inside the EDC is the electronic Case Report Form (eCRF) — the protocol-driven form a site coordinator (or, increasingly, the patient or a device) completes during a visit. The EDC stores those forms with the metadata regulators expect: audit trail, electronic signatures, query workflow, edit-check enforcement, role-based access control.

EDC replaced paper CRFs (pCRFs) in mainstream drug and device trials between roughly 2005 and 2015. Today the question is not paper vs electronic but how many additional electronic sources feed the same database — central labs via SDTM-LB datasets, imaging core labs via DICOM and read forms, ePRO platforms via patient-reported outcome instruments, wearable sensors via the FDA's DHT (digital health technology) framework, decentralised-trial home-visit apps, and direct EHR-to-EDC integration. The modern EDC is a data hub, not a form server.

EDC sits at the intersection of three regulatory regimes. ICH E6(R3) Good Clinical Practice (final 2025) sets the trial-conduct expectations: data should be reliable, attributable to the originator, accurate, contemporaneous, original, and complete. Section 4 of E6(R3) explicitly recognises electronic data and references the FDA's 2013 e-source guidance and EMA's Reflection Paper on the Use of Computerised Systems and Electronic Data in Clinical Investigations.

21 CFR Part 11 governs the US technical and procedural requirements for electronic records and signatures used to satisfy FDA predicate-rule recordkeeping. EDCs must implement validated systems, accurate record retrieval, audit trails recording who did what and when, role-based access, electronic signatures bound to the records they sign, and procedures preventing unauthorised access. EMA Annex 11 imposes parallel obligations in the EU with additional emphasis on supplier assessment, periodic review and lifecycle change control.

Validation is conducted under a risk-based CSV framework (ISPE GAMP 5 second edition, 2022) or under FDA's Computer Software Assurance (CSA) draft guidance for the critical-thinking-led alternative. Either approach: identify intended use, assess risk, scale validation effort to risk, document the lifecycle.

An eCRF is the electronic equivalent of a paper case report form: a per-visit, per-subject form that captures the protocol-required observations and measurements. A defensible eCRF starts with the protocol's schedule of assessments, maps every assessment to a CDISC-aligned data structure, and adds the edit checks that prevent the obvious data-entry errors (out-of-range values, missing mandatory fields, illogical date sequences).

Two principles underpin a good eCRF design. First, the CRF Completion Guidelines (CCG) should be unambiguous — every field has one correct interpretation. Second, source-data location should be specified in the protocol's data-handling plan: which fields are direct source (entered first in the EDC, with no paper equivalent), which are transcribed from source documents (paper or EHR), and which are imported from external data sources (lab, imaging, ePRO, sensor).

ALCOA+ is the data-integrity framework regulators apply to every electronic system in a regulated environment. Attributable: each entry tied to a unique identified user. Legible: human-readable and durable. Contemporaneous: entered at the time of the observation. Original: not a copy of another record. Accurate: correct in fact and method. Complete, Consistent, Enduring, Available — the four-letter expansion. EDC implementations are audited against ALCOA+ as a matter of routine inspection.

The audit trail is the principal evidence. Every create / read / update / delete event on a record, every electronic signature, every query workflow transition must be captured with user, timestamp, and reason for change (where applicable). The audit trail must be available to inspectors in human-readable form throughout the retention period — typically 25 years post-product-approval for FDA-regulated trials and varying by region elsewhere.

FDA requires regulatory submissions to use CDISC standards. The Study Data Tabulation Model (SDTM) defines how observation data is structured for submission; the Analysis Data Model (ADaM) defines how analysis datasets are derived from SDTM; Define-XML describes the metadata. EDC builds should specify CDISC-conformant data structures up front — retrofitting SDTM from a non-conformant eCRF design after database lock is expensive and routinely delays submissions.

FDA's Technical Conformance Guide (currently the September 2024 update) and PMDA's equivalent define the exact submission format and validation rules. Pinnacle 21 (formerly OpenCDISC) is the de facto validation tool used to confirm conformance before submission.

Modern trials feed the EDC from many sources. Electronic Patient-Reported Outcomes (ePRO) capture patient-completed instruments — sometimes via dedicated devices, increasingly via the patient's own smartphone under FDA's 2024 DCT guidance. Electronic Clinical Outcome Assessment (eCOA) is the umbrella term covering ePRO plus electronic clinician-reported outcomes (ClinRO), observer-reported outcomes (ObsRO) and performance-outcome (PerfO) instruments.

Digital Health Technologies (DHTs) — wearables, connected medical devices, ambient sensors — produce continuous-data streams that the EDC ingests via API. FDA's 2023 DHT guidance sets expectations for fit-for-purpose evaluation, validation in the relevant population, and source-data management. EHR-to-EDC integration via HL7 FHIR has been the slowest of the modern transitions, but FDA's 2018 guidance on EHR data in clinical investigations made the regulatory pathway clear: the EHR must be qualified for the trial's purpose, and data lineage from EHR to eCRF must be auditable.

1. Build — CRF design, edit-check library, randomisation/IRT integration, ePRO/lab/imaging connectors, role and permission matrix.
2. Validation — GAMP 5 risk-based or CSA critical-thinking lifecycle; URS → FS → DS → IQ/OQ/PQ; traceability matrix.
3. UAT and database go-live — sponsor + CRO sign-off; locked CRF; production deployment.
4. Subject screening and enrolment — eConsent feeds, screening data capture, enrolment tracking.
5. Treatment phase — visit data capture, query workflow, central monitoring per ICH E6(R3) risk-based-monitoring expectations.
6. Database soft lock — query closure, SAE reconciliation with safety database, external-data reconciliation.
7. Database hard lock and archive — final CDISC datasets, Define-XML, archive in retention-compliant repository.
8. Submission — SDTM/ADaM datasets, Define-XML, Reviewer's Guide, analysis programs.

• CRF designed without SDTM mapping. Retrofitting SDTM after database lock is the most common cause of submission delay.
• Edit checks designed as data-cleaning band-aids rather than protocol-derived rules. The protocol's data-handling plan should drive every check.
• Audit trail not periodically reviewed. ICH E6(R3) and FDA inspections increasingly expect documented audit-trail review at the trial level, not just at database lock.
• Source-data location ambiguous. A field that is sometimes paper-source and sometimes direct-source cannot be defended in inspection.
• User access not periodically reviewed. Inactive accounts and overly broad role permissions are recurring 483 findings.
• Lifecycle change control absent for production CRF revisions. Mid-study CRF amendments require validated, documented changes and version control.