27.1 EDC Design and Fit-for-Purpose Systems

EDC Design and Fit-for-Purpose Systems

Electronic data capture must support reliable trial information while protecting participants. For CCRA preparation, use ICH E6(R3) Annex 1 section 4, together with the investigator and sponsor provisions. Country-specific electronic-record regulations can apply in practice, but FDA Part 11 and EU Annex 11 are not additional ACRP examination references, and EU Annex 11 is not a general clinical-trial counterpart to Part 11.

EDC Architecture vs. Paper Case Report Forms

In legacy paper trials, investigative sites completed three-part or four-part carbon-copy Case Report Forms. The CRA visited the site, hand-compared source records against paper forms, physically pulled the "sponsor copy," and mailed batches of paper to a central data management facility where double-data keying was performed. Query cycles routinely spanned two to four months.

EDC implementations vary; use appropriate security and documented controls for their intended trial use.

eCRF Structural Design and Standardization

EDC form design may use CDISC (Clinical Data Interchange Standards Consortium) standards, specifically the CDASH (Clinical Data Acquisition Standards Harmonization) model. Standard eCRF modules include:

• Demographics & Baseline Characteristics: Age, sex, race, ethnicity.
• Medical History & Physical Examination: Pre-existing conditions mapped chronologically.
• Inclusion / Exclusion Criteria: Binary confirmation of eligibility parameters.
• Study Intervention / Dosing Administration: Exact dose, lot number, infusion start/stop times.
• Concomitant Medications: Trade/generic name, indication, dose, frequency, route, dates of use.
• Adverse Events: Verbatim term, onset/resolution dates, severity, causality, action taken, outcome.
• Protocol Deviations & Study Completion: Termination reasons, completion milestones.

Automated Edit Checks (Programmed Validation Rules)

A transformative advantage of EDC systems is the execution of automated edit checks programmed into the software logic. Checks operate according to the system design:

• Range Checks: Flags physiologically impossible or statistically improbable values (e.g., entering a diastolic blood pressure of 450 mmHg or a human body temperature of 10°C triggers an immediate soft or hard warning).
• Required-Field Checks: Identify missing information according to the system design, while permitting appropriate documentation of genuinely unavailable data.
• Format Checks: Enforces uniform data syntax (e.g., an unambiguous date convention defined by the tool to prevent international confusion between month and day).
• Cross-Form / Cross-Panel Consistency Checks: Flags logical contradictions across different eCRF modules (e.g., if the Adverse Event log records an event of "Deep Vein Thrombosis" on October 14, but the Concomitant Medication log contains a new prescription for therapeutic Heparin beginning October 10 with an indication of "DVT," an automated cross-panel query fires).

Prompt Data Entry Guidelines

Sponsor contracts and Clinical Monitoring Plans (CMPs) enforce strict Service Level Agreements (SLAs) for data entry timelines. The trial may specify that investigative sites transcribe primary source data into eCRFs within its documented deadline following the participant's completed visit. Rapid data entry is not merely an administrative preference; it is a vital safety prerequisite enabling medical monitors and pharmacovigilance teams to detect emerging drug toxicity signals in real time.

Fit-for-purpose systems, access and validation

The responsible party should document how a system is used, who manages it, relevant interfaces and validation status. Validation should be proportionate to intended use, risks and the importance of the data. A vendor certificate alone does not demonstrate that trial-specific forms, calculations and transfers work correctly. Verify requirements, test critical functions and maintain control of changes.

Users need individual attributable access and permissions appropriate to their role. Investigator staff permissions should be consistent with delegation and visible to the investigator. Shared credentials compromise attribution and must be addressed. Notify the responsible system administrator when access should be changed or revoked; the CRA should facilitate the response, not assume unrestricted administrative authority.

A compromised investigator account requires prompt containment, review of affected records and an appropriate correction/endorsement process. Do not delete the audit trail or simply re-sign without reviewing what occurred. Preserve evidence, assess participant/data impact and track corrective actions. An unauthorised signature is a significant integrity concern; the monitor should not independently declare criminal intent from the fact alone.

Document security, backup, disaster recovery and contingency procedures, testing them as appropriate. The design determines backup frequency, recovery needs and other controls; ICH does not prescribe daily geo-redundant cloud backups or a universal 10-minute logout. During downtime, maintain safe trial conduct and reliable contemporaneous records under the approved contingency process, then reconcile restored data without disguising entry timing.

Computer-Generated, Time-Stamped Audit Trails

The computerized audit trail is the cornerstone of regulatory data integrity. E6(R3) data governance calls for appropriate secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.

Official sources

Checked October 18, 2026: ICH E6(R3), Principles and Annex 1, ICH E9(R1).