12.1 Electronic Data Capture (EDC), eCRF Design & Clinical Data Management Systems (CDMS)

Electronic Data Capture (EDC), eCRF Design & Clinical Data Management Systems (CDMS)

Core Regulatory Standard: Clinical Data Management (CDM) is the critical discipline in clinical research that ensures trial data are complete, accurate, reliable, verifiable, and ready for statistical analysis and regulatory submission. Under ICH E6(R3) Annex 1 section 3.16 and the Good Clinical Data Management Practice (GCDMP) guidelines, sponsors and investigators must utilize validated electronic data systems with documented procedures to guarantee that trial data integrity is maintained throughout the entire study lifecycle.

Candidates preparing for the ACRP-CP (ACRP Certified Professional) examination must master the operational principles of Electronic Data Capture (EDC), the structural architecture of the Data Management Plan (DMP), the Clinical Data Interchange Standards Consortium (CDISC) data ecosystem, and the strict division between original source records and electronic Case Report Forms (eCRFs).

---

1. Evolution of Clinical Trial Data Management: Paper CRFs vs. Modern EDC

Historically, clinical trials captured data using multi-part carbonless paper Case Report Forms (CRFs). Paper-based trials suffered from protracted lag times (often weeks or months) between site patient visits, physical document shipping, manual double-data entry (DDE), and mail-based query resolution. Modern clinical research relies almost universally on Electronic Data Capture (EDC) systems operating within comprehensive Clinical Data Management Systems (CDMS).

┌───────────────────────────────────────────────────────────────────────────┐
│                     PAPER CRF vs. ELECTRONIC DATA CAPTURE                 │
├──────────────────────────┬────────────────────────────────────────────────┤
│  FEATURE                 │  ELECTRONIC DATA CAPTURE (EDC)                 │
├──────────────────────────┼────────────────────────────────────────────────┤
│  Data Entry Timing       │  Real-time or near real-time (3-5 days)        │
│  Validation / Checks     │  Instantaneous automated programmed checks     │
│  Query Lifecycle         │  Electronic generation, routing, and closure   │
│  Data Transparency       │  Immediate visibility for CRAs, CDMs, & Safety │
│  Audit Trail             │  Automated, computer-generated, indelible      │
│  Source Verification     │  Direct comparison during on-site/remote SDV   │
│  Submission Readiness    │  Direct mapping to standardized CDISC models   │
└──────────────────────────┴────────────────────────────────────────────────┘

Operational Advantages of EDC Platforms

1. Immediate Discrepancy Detection: Automated edit checks fire instantly upon data entry, alerting coordinators to out-of-range values, missing data, or format errors before a form is submitted.
2. Enhanced Subject Safety Surveillance: Medical monitors and pharmacovigilance teams have immediate, real-time access to adverse events, laboratory toxicities, and dosing modifications across all participating global sites.
3. Decentralized and Remote Monitoring: Clinical Research Associates (CRAs) and centralized monitors can perform continuous Source Data Review (SDR) and targeted Source Data Verification (SDV) without waiting for scheduled periodic on-site monitoring visits.
4. Indelible Traceability: Every keystroke, modification, deletion, and signature is captured in a compliant Part 11 audit trail.

---

2. The Data Management Plan (DMP) & Data Lifecycle Governance

The Data Management Plan (DMP) is the master operational blueprint that governs all data-related activities from study inception to database lock and archiving. Governed by ICH E6(R3) Annex 1 section 3.16 and the Society for Clinical Data Management (SCDM) GCDMP guidelines, the DMP defines the roles, responsibilities, systems, workflows, and quality control procedures for the trial.

┌───────────────────────────────────────────────────────────────────────────┐
│                     ESSENTIAL COMPONENTS OF A COMPLETE DMP                │
├───────────────────────────────────────────────────────────────────────────┤
│  1. Study Scope, Governance, & Key CDM Contact Information                │
│  2. System Architecture (EDC, RTSM/IWRS, ePRO/eCOA, Safety DB Interfaces) │
│  3. eCRF Design Specifications & Form Completion Guidelines (CCGs)        │
│  4. Data Validation Plan (DVP) / Data Validation Specifications (DVS)     │
│  5. External Data Transfer Agreements (DTA) for Central Labs & Core Labs │
│  6. Medical Dictionary Coding Conventions (MedDRA & WHO Drug Global)      │
│  7. Serious Adverse Event (SAE) Reconciliation Workflow                   │
│  8. Discrepancy & Query Management Rules, Categorization, & Site SLAs    │
│  9. Self-Evident Correction (SEC) Rules and Limitations                   │
│  10. Quality Control (QC) Audits, Interim Analysis Cuts, & Lock Criteria │
└───────────────────────────────────────────────────────────────────────────┘

Living Document Nature of the DMP

The DMP is a living document. Whenever a protocol amendment alters study visits, schedules of assessments, endpoints, or eligibility criteria, the Lead Clinical Data Manager must formally revise the DMP, update the Data Validation Specifications (DVS), execute user acceptance testing (UAT), and release version-controlled updates to the project team.

---

3. eCRF Design Principles & User Experience (UX)

The electronic Case Report Form (eCRF) is the primary instrument used to collect protocol-required data transcribed from source documents at investigational sites. Poor eCRF design is a leading cause of protocol deviations, site data entry delays, high query volumes, and data cleaning bottlenecks.

---

4. CDISC Data Standards Ecosystem: CDASH, SDTM, and ADaM

The Clinical Data Interchange Standards Consortium (CDISC) establishes global, vendor-neutral data standards that are mandated by regulatory agencies—including the US FDA and the Japan PMDA—for electronic clinical trial submissions.

┌───────────────────────────────────────────────────────────────────────────┐
│                     THE CDISC END-TO-END DATA CONTINUUM                   │
├───────────────────────────────────────────────────────────────────────────┤
│  1. CDASH (Clinical Data Acquisition Standards Harmonization)             │
│     • Standardizes DATA COLLECTION at the site/eCRF level                 │
│     • Defines standard question text, variable names, and prompts         │
├───────────────────────────────────────────────────────────────────────────┤
│  2. SDTM (Study Data Tabulation Model)                                    │
│     • Standardizes DATA TABULATION for regulatory submission datasets     │
│     • Organizes data into standard domains (DM, AE, CM, VS, LB, EX)       │
├───────────────────────────────────────────────────────────────────────────┤
│  3. ADaM (Analysis Data Model)                                            │
│     • Standardizes STATISTICAL ANALYSIS datasets                          │
│     • Structures data for direct generation of tables, listings, & figures│
│     • Core structures: ADSL (Subject-Level) and BDS (Basic Data Structure)│
└───────────────────────────────────────────────────────────────────────────┘

In-Depth Breakdown of CDISC Models

A. CDASH (Clinical Data Acquisition Standards Harmonization)

CDASH establishes basic standards for the collection of clinical trial data. It defines the recommended question text, prompt layouts, and variable naming conventions on eCRFs.

• Why CDASH Matters to Site Coordinators: Because CDASH standardizes questions across different sponsors and EDC systems, a Clinical Research Coordinator (CRC) sees the exact same standard prompts (e.g., "What is the Adverse Event term?", "Start Date", "Did this event cause hospitalization?") regardless of which pharmaceutical sponsor designed the study.
• Key CDASH Domains: DM (Demographics), AE (Adverse Events), CM (Concomitant Medications), MH (Medical History), VS (Vital Signs), LB (Laboratory Tests), EX (Exposure / Study Drug Dosing).

B. SDTM (Study Data Tabulation Model)

SDTM provides the standard structure for human clinical trial study data tabulations submitted to regulatory authorities. SDTM transforms raw eCRF data into standardized, normalized tables where each row represents a single observation.

• Standard Variables: Every SDTM domain contains required identifying variables, such as STUDYID (Study Identifier), USUBJID (Unique Subject Identifier), and DOMAIN (Two-character domain code).
• Topic and Descriptor Variables: AETERM (Reported AE Term), AEDECOD (Dictionary-Derived Term / MedDRA PT), AESTDTC (AE Start Date/Time in ISO 8601 format).

C. ADaM (Analysis Data Model)

ADaM defines datasets optimized for statistical analysis. While SDTM preserves original tabulations, ADaM creates derived analysis variables (e.g., change from baseline, time-to-event flags, treatment grouping variables).

• ADSL (Subject-Level Analysis Dataset): Mandatory single-record-per-subject dataset containing core demographic, stratification, and population flags (ITTFL, SAFFL, PPROTFL).
• BDS (Basic Data Structure): Multi-record-per-subject dataset containing one or more records per subject per parameter per time point (used for lab analyses, vital sign trajectories, and efficacy scores).

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                              CDISC DATA PIPELINE COMPARISON                             │
├───────────────────┬──────────────────────┬──────────────────────┬───────────────────────┤
│ FEATURE           │ CDASH                │ SDTM                 │ ADaM                  │
├───────────────────┼──────────────────────┼──────────────────────┼───────────────────────┤
│ Primary Purpose   │ Data Collection      │ Data Tabulation      │ Statistical Analysis  │
│ Target User       │ CRCs, PIs, Data Entry│ Data Managers, FDA   │ Biostatisticians, FDA │
│ Timing in Study   │ Study Conduct (Live) │ Post-Collection / DBL│ Pre-Submission Stats  │
│ Example Variable  │ `AETERM` (Prompt)    │ `AESTDTC` (Char ISO) │ `ASTDT` (Numeric Date)│
│ Regulatory Status │ Recommended Standard │ MANDATORY (FDA/PMDA) │ MANDATORY (FDA/PMDA)  │
└───────────────────┴──────────────────────┴──────────────────────┴───────────────────────┘

---

5. Role-Based Access Control (RBAC) & User Management in EDC

To ensure data integrity, patient confidentiality, and study blinding under ICH E6(R3) Annex 1 section 4.3 and 21 CFR Part 11, CDMS platforms enforce Role-Based Access Control (RBAC).

┌───────────────────────────────────────────────────────────────────────────┐
│                        EDC USER ROLES & PERMISSION MATRIX                 │
├──────────────────────────┬───────┬───────┬────────┬────────┬──────┬───────┤
│ ROLE                     │ VIEW  │ ENTER │ EDIT   │ SIGN   │ QUERY│ SDV   │
├──────────────────────────┼───────┼───────┼────────┼────────┼──────┼───────┤
│ Principal Investigator   │ Yes   │ Yes   │ Yes    │ YES    │ Answ │ No    │
│ Sub-Investigator         │ Yes   │ Yes   │ Yes    │ YES*   │ Answ │ No    │
│ Study Coordinator (CRC)  │ Yes   │ Yes   │ Yes    │ NO     │ Answ │ No    │
│ CRA / Clinical Monitor   │ Yes   │ No    │ No     │ NO     │ Open │ YES   │
│ Clinical Data Manager    │ Yes   │ No    │ No     │ NO     │ Open │ No    │
│ Medical Monitor (Safety) │ Yes   │ No    │ No     │ NO     │ Open │ No    │
│ Unblinded Pharmacist     │ IP-Only│ IP-Only│ IP-Only│ IP-Only│ Answ │ No    │
└──────────────────────────┴───────┴───────┴────────┴────────┴──────┴───────┘
* If formally delegated by PI on the Delegation of Authority Log (DOAL).

The Blinding Firewall in EDC

In double-blind randomized trials, unblinded data—such as investigational product kit codes, randomization schedules, and treatment arm assignments—must be strictly partitioned within the EDC architecture.

• Unblinded Access Groups: Restricted exclusively to unblinded pharmacists and dedicated unblinded CRAs.
• Blinded Access Groups: PIs, CRCs, blinded CRAs, and clinical data managers must never be granted permissions to view unblinded forms or kit descriptions. Accidental unblinding in EDC constitutes a major protocol violation requiring immediate reporting to the IRB and sponsor.

6. Data Entry Timelines & Source Data vs. eCRF Data

A fundamental tenet of Good Clinical Practice is the clear distinction between Source Data and eCRF Data.

A. Source Data vs. eCRF Transcriptions

• Source Data (the ICH E6(R3) Glossary): All information in original records and certified copies of original records of clinical findings, observations, or other activities in a clinical trial necessary for the reconstruction and evaluation of the trial. Examples include Electronic Health Records (EHR), physician progress notes, paper worksheets, laboratory printouts, and automated ECG tracings.
• eCRF Data: An electronic transcription of the source data into the clinical trial database for transmission to the sponsor.
• Direct eCRF Entry (eSource): In specific prospectively planned scenarios, data may be entered directly into the EDC system without a prior written or electronic record (e.g., a quality-of-life questionnaire completed directly on an EDC tablet or real-time clinical scores recorded during an exam). In all such cases, the Data Management Plan and protocol must explicitly state that the eCRF serves as the source document for those specific data elements.

B. Data Entry Timelines & Industry SLAs

Sponsors define explicit Service Level Agreements (SLAs) in the Clinical Trial Agreement (CTA) and DMP regarding data entry timeliness:

• Routine Study Visits: Site staff must complete initial eCRF data entry within 3 to 5 business days following the completion of the subject visit.
• Serious Adverse Events (SAEs): Initial SAE data must be entered into the EDC and reported to the sponsor within 24 hours of site awareness.
• Query Responses: Site personnel must investigate and respond to data queries within 5 to 7 business days of issuance.

---

7. Realistic Clinical Scenario: eCRF Design & CDASH Standards in Practice

Clinical Scenario: Elena Rodriguez is the Lead Study Coordinator on a Phase III oncology trial evaluating an investigational immunotherapy (MK-902) for metastatic melanoma. Subject 108 presents for the Cycle 2 Day 1 visit. The subject reports experiencing moderate nausea and fatigue over the past 3 days and states they took over-the-counter ondansetron 8 mg twice daily for relief.

Elena enters the data into the EDC system:

1. On the AE (Adverse Events) form, she creates two distinct log entries: "Nausea" (Grade 2, started 3 days prior, ongoing) and "Fatigue" (Grade 2, started 3 days prior, ongoing). She enters the onset dates using the standardized ISO 8601 format (2026-08-12).
2. On the CM (Concomitant Medications) form, she enters "Ondansetron", dose "8 mg", route "Oral", frequency "BID", indication "Nausea", and start date 2026-08-12.
3. The EDC system's dynamic edit check immediately cross-references the CM indication against the AE and MH forms. Because "Nausea" exists on the active AE log, the cross-form edit check passes cleanly without triggering an unlinked medication query.

GCP and CDM Analysis: Elena demonstrated flawless execution of CDASH data capture principles by: (a) separating distinct clinical signs and symptoms into individual AE records rather than combining them into a single compound entry, (b) adhering strictly to ISO 8601 date formatting, and (c) aligning the concomitant medication indication with the recorded adverse event term to maintain cross-domain consistency.