🗂 Electronic Data Capture (EDC) Query Workflow

CRF Data Entry and the Real-Time Edit Check Engine

Modern Electronic Data Capture platforms replace paper case report forms with structured web forms that validate data the instant it is entered. The edit check engine is the first and cheapest line of defense against dirty data — catching a transcription error at the point of entry costs a fraction of catching it during database lock.

• 3: EDC market leaders (Medidata Rave, Veeva CDMS, Oracle Clinical One)
• 300–800: Typical edit checks per study (programmed per protocol)
• 150–400: Fields entered per subject visit (CRF pages × fields)
• <300 ms: Real-time check latency (on-save validation)

CRF design and CDASH-aligned data structures

Case report forms are built from a Data Management Plan (DMP) and an annotated CRF that maps every collected field to its downstream SDTM (Study Data Tabulation Model) domain. CDISC CDASH (Clinical Data Acquisition Standards Harmonization) defines standardized field-level conventions — controlled terminology, date formats (ISO 8601), and required/conditional field logic — so that data captured at hundreds of sites arrives structurally identical.

Form-level design decisions directly determine query burden downstream:

• Skip logic: conditional fields (e.g., "if AE ongoing = No, show stop date") suppress irrelevant fields, eliminating a large class of missing-data queries before they can occur • Controlled terminology dropdowns vs free text: free-text units or dose fields generate 3–5× more queries than constrained pick-lists • Auto-calculation: derived fields (BMI from height/weight, age from DOB and visit date) removed from manual entry entirely, eliminating an entire query category • Visit windowing: date fields validated against the protocol visit schedule (± allowed window) at entry time, not at database lock

A well-designed eCRF, benchmarked against poorly designed forms in the same therapeutic area, can reduce total query volume by 30–50% before a single edit check even fires.

The edit check specification and rule taxonomy

Every study runs on an Edit Check Specification (ECS) document, typically an Excel or structured JSON artifact reviewed and signed off by Data Management, Biostatistics, and the Medical Monitor before the database is released for first-patient-in. Rules fall into standard classes:

1. Range checks — single-field: value falls outside protocol-defined clinical plausibility (e.g., systolic BP <60 or >260 mmHg) 2. Format/completeness checks — required field left blank, or format mismatch (non-numeric entered in numeric field) 3. Cross-field checks — within-form logic (AE stop date < AE start date; concomitant medication dose unit inconsistent with route) 4. Cross-form checks — consistency across CRF pages (AE reported as ‘ongoing’ on the AE form but a resolution date exists on the Con Med form referencing the same AE) 5. Cross-visit checks — temporal logic across the visit schedule (lab draw date precedes randomization date) 6. Protocol deviation triggers — value combinations indicating inclusion/exclusion violations, dosing outside protocol-specified windows

Edit checks execute in two modes: real-time (fires on field save, blocking or soft-warning) and batch (nightly or on-demand SAS/SQL sweeps against the full database for checks too computationally expensive to run per-keystroke, such as multi-subject consistency or lab reference-range checks tied to central-lab certificates of analysis).

A frequently cited TransCelerate BioPharma benchmark places well-optimized Phase III studies at 5–15 queries per 100 CRF pages; studies with poorly tuned edit checks or free-text-heavy forms routinely exceed 30 queries per 100 pages, roughly tripling data management cost per subject.

System-Generated Queries — Turning Failed Edit Checks into Actionable Discrepancies

When an edit check fails, the EDC system does not merely flag the field — it instantiates a formal query object: a unique identifier, a discrepancy text, a target field reference, a priority level, and a routing destination. This auto-generation step converts a silent rule violation into a trackable workflow item with its own audit trail from the moment of creation.

• 55–70%: Share of queries that are system-generated (typical Phase II/III study)
• <1 sec: Auto-query creation time (from failed check to routed query)
• <8%: False-positive rate (well-tuned ECS) (queries later closed as “no action”)
• 7+: Query object required fields (ID, site, subject, form, field, text, priority)

Anatomy of a system query and its lifecycle states

Every EDC query, whether auto- or manually generated, moves through a defined state machine that the platform enforces and time-stamps for the audit trail:

Open → the discrepancy is created and visible to the site; a query text explains what is wrong and what is requested (e.g., "Value entered (410 mg) exceeds maximum protocol dose of 400 mg. Please confirm or correct.") Answered → the site has responded, either by correcting the source field or by entering a free-text clarification comment Closed → the data manager or CRA has reviewed the response, judged it adequate, and closed the query Reopened → if the response is inadequate, the query is reopened with an added comment explaining the deficiency, restarting the resolution clock Cancelled → the query is withdrawn as invalid, typically because the edit check itself misfired (a false positive) — closely monitored as an ECS quality metric

Each state transition is a discrete, attributable, timestamped audit trail record under 21 CFR Part 11 and ICH E6(R2) Section 5.5.3 — who changed what, when, and (for material changes) why. This audit trail is itself inspectable by FDA and EMA during a for-cause or routine GCP inspection.

Query priority tiering and routing logic

Not all discrepancies carry equal urgency. Mature EDC configurations tier queries by priority, which drives both the visual presentation to the site user and the escalation timeline:

• Critical/Safety — queries tied to serious adverse events, deaths, or eligibility-defining fields; typically require site response within 24–48 hours and trigger simultaneous notification to the CRA and, for SAE-linked items, the pharmacovigilance team • High — protocol deviations, dosing errors, missing efficacy endpoint data near a visit window closing • Standard — routine range and completeness queries; governed by the protocol’s standard SLA (commonly 5 business days) • Low — cosmetic or non-critical formatting queries, often batched and addressed at the next monitoring visit

Routing logic determines destination: most queries route to the site (data originator), but a subset — cross-form logic failures spanning data entered by different roles, or queries requiring central lab clarification — route instead to the CRA, medical monitor, or central lab liaison. Auto-routing rules are themselves part of the validated EDC build and subject to User Acceptance Testing (UAT) before go-live.

CDISC and TransCelerate data quality guidance recommends that safety-tier queries close within a median of 2 business days; a widely cited industry benchmark from multiple CRO quality reports shows the actual cross-industry median running closer to 3.5–4 days, driven largely by site staffing constraints rather than query complexity.

Manual Query Issuance — Data Clarification Forms and Medical Judgment

Programmed edit checks catch mechanical inconsistencies, but they cannot judge clinical plausibility, coding accuracy, or narrative coherence. Manual review by data managers, CRAs, and medical monitors — reading listings, patient profiles, and adverse event narratives — remains the layer that catches the discrepancies a rule engine was never written to detect.

• 30–45%: Share of queries manually issued (typical Phase II/III study)
• 20–60: Listings reviewed per DM cycle (SAS/CDISC listings per study)
• ~15%: MedDRA coding query share (of all manual queries)
• Monthly: Medical monitor review cadence (or triggered by SAE)

Listings review, medical review, and the Data Clarification Form

Manual review operates on periodic listings — SAS- or CDISC-standard tabular exports of the accumulating database — rather than the live EDC screen. Data managers scan for patterns edit checks structurally cannot see:

• Narrative-data mismatch: an AE narrative describing hospitalization, but the "Serious" flag left unchecked on the structured field • Coding discrepancies: verbatim adverse event terms that MedDRA auto-coding mapped to an implausible Preferred Term, requiring manual re-coding review • Concomitant medication plausibility: a WHO Drug Dictionary (WHO-DD) coded medication with a dose/route combination that is technically valid but clinically unusual for the indication • Protocol deviation patterns: subjects whose visit dates cluster suspiciously close to allowed-window boundaries across multiple sites, suggesting a site-level training gap • Outlier and trend detection: central statistical monitoring (CSM) flags a site with a mean lab value 3 standard deviations from the cross-site distribution — not wrong per protocol range, but statistically anomalous

Each finding is documented on a Data Clarification Form (DCF) — historically a literal paper form faxed to sites, now a structured query object created directly inside the EDC by the reviewer, carrying the same audit-trail obligations as a system query but authored by a named human reviewer rather than a rule engine.

Medical monitor review and safety-triggered queries

The medical monitor — typically a physician — performs a distinct review layer focused on clinical coherence rather than data-entry mechanics: does the reported adverse event sequence make pharmacological sense given the dosing history? Is a laboratory abnormality consistent with the AE term selected? Should an unreported but implied AE (e.g., a lab value crossing a Grade 3 CTCAE threshold with no corresponding AE entry) be queried?

SAE-specific review is the highest-scrutiny category. Every Serious Adverse Event triggers a parallel reconciliation workflow: the SAE as captured in the EDC must match, field for field, the case as reported to the safety database (Argus Safety, ArisGlobal LifeSphere) and, where regulatorily required, the ICH E2B(R3)-formatted expedited report filed with FDA FAERS or EMA EudraVigilance. Any mismatch — a discrepant onset date, a causality assessment recorded differently in the two systems — generates a reconciliation query that must close before database lock, since an unreconciled SAE is a critical finding in any GCP inspection.

ICH E6(R2) Section 5.5.3 explicitly requires that any correction to a trial database be documented, explained if significant, and dated — a requirement operationalized in EDC systems as the immutable, cryptographically-linked audit trail entry generated automatically on every query state change.

Site Response, SLA Management, and Escalation

A query sitting unanswered is a database that cannot lock. The site response phase is where workflow design meets human bandwidth — investigators and coordinators, often managing dozens of open queries across multiple concurrent trials, must triage and respond within a protocol-defined service level while the sponsor’s monitoring team tracks aging in real time.

• 5 business days: Standard site SLA (non-safety queries)
• 24–48 hours: Safety-tier SLA (SAE-linked queries)
• 4.2 days: Cross-industry median response (multi-CRO benchmark)
• 150% of SLA: Overdue query escalation threshold (triggers CRA follow-up)

The site’s resolution path — correction vs clarification

When a coordinator opens a query, two resolution paths are available depending on the nature of the discrepancy:

1. Data correction: the underlying CRF value was genuinely wrong (transcription error, unit mismatch, mis-selected dropdown option). The site edits the source field directly; the EDC captures the old value, new value, timestamp, user, and — for any field already locked/frozen or previously signed — a mandatory reason-for-change free-text entry, satisfying 21 CFR Part 11 audit requirements.

2. Clarification comment: the underlying data is correct as entered, but requires explanation for reviewer context (e.g., "Value confirmed against source document; subject has pre-existing condition explaining the abnormal lab result"). No field value changes; the query response is the comment itself, and the reviewer must judge whether the explanation is adequate to close.

Sites resolve the large majority of standard-tier queries within SLA using the EDC’s own task list / to-do queue, which surfaces open queries ranked by age and priority. Some EDC platforms integrate directly with eSource or EHR systems, allowing coordinators to re-verify against the medical record without leaving the query resolution screen — reducing round-trip time for source-verifiable corrections.

Aging, escalation, and the CRA monitoring loop

Query aging is tracked continuously against SLA in the EDC’s metrics dashboard, typically visualized as a traffic-light distribution: green (within SLA), amber (approaching SLA), red (overdue). Standard escalation cascades:

• Automated reminder emails to the site at 50% and 90% of SLA elapsed • CRA notification when a query crosses 100% of SLA, added to the agenda for the next monitoring contact (remote or on-site visit) • Sponsor/CRO Data Management Lead escalation for sites with chronic overdue-query patterns, often surfaced through Risk-Based Monitoring (RBM) dashboards tracking site-level Quality Tolerance Limits (QTLs) as defined by TransCelerate’s RBM framework and referenced in ICH E6(R2) • For persistently unresponsive sites, escalation to the Sponsor’s clinical operations lead, occasionally culminating in a for-cause monitoring visit or, in severe cases, site data-entry privileges review

Decentralized and hybrid trial designs add a further wrinkle: when source data originates from an eCOA/ePRO device or a connected home-health visit rather than a site visit, the "site" resolving the query may be a central coordinating team rather than local staff, generally shortening response times but requiring its own query-routing configuration in the eClinical ecosystem.

A widely cited TransCelerate industry analysis found that overdue-query burden, not query volume itself, is the single strongest predictor of database lock timeline slippage — studies with disciplined sub-5-day median response times locked a median of 3–4 weeks faster than matched studies with 8+ day median response times.

Query Closure, SDV/SDR, and Reconciliation Before Database Lock

Closing a query is not a rubber stamp — it is a documented judgment that the discrepancy has been fully and correctly resolved. This final stage aggregates every open thread across the study: outstanding queries, source data verification sampling, safety-database reconciliation, and coding review, all of which must clear before the database can be declared locked and released to biostatistics for analysis.

• ≥95% closed: Database lock readiness threshold (of all non-cancelled queries)
• 20–100%: SDV sampling (risk-based) (source data verification, by risk tier)
• Every 2–4 weeks: SAE reconciliation cycle (EDC vs safety database)
• 1–3 weeks: Typical lock-to-database-freeze gap (soft lock → hard lock)

Query closure criteria and reviewer judgment

Closing a query requires the reviewer to confirm the response actually resolves the discrepancy — not merely that the site replied. A data manager’s closure checklist typically verifies:

• The corrected value now passes the original edit check that fired • Any clarification comment provides a clinically or procedurally adequate explanation, not just an acknowledgment • Dependent/derived fields recalculate correctly after the correction (e.g., a corrected dose does not silently break a downstream cumulative-dose calculation) • For safety-linked queries, the correction is reflected consistently in both the EDC and the pharmacovigilance safety database

Inadequate responses are reopened rather than closed, with the reviewer’s reason for reopening itself becoming a permanent audit-trail entry — this reopen/close cycle is one of the most closely inspected artifacts during FDA BIMO (Bioresearch Monitoring) or EMA GCP inspections, since it directly demonstrates data integrity oversight.

Query closure metrics feed the study’s ongoing data quality dashboard: closure rate by site, by query category, and by reviewer, allowing the DM lead to identify sites with a pattern of inadequate first responses (a training signal) versus sites that simply take longer to respond (a bandwidth signal) — these require very different interventions.

Reconciliation, soft lock, hard lock, and downstream SDTM readiness

Before a database can be declared clean, several parallel reconciliation streams must independently confirm consistency:

• Safety reconciliation: every SAE case in the EDC is matched line-by-line against the pharmacovigilance safety database (Argus, ArisGlobal) and any ICH E2B(R3)-formatted expedited reports already filed with FDA FAERS / EMA EudraVigilance; discrepancies here are treated as critical findings requiring immediate closure • Coding reconciliation: MedDRA-coded adverse events and WHO-DD-coded concomitant medications are reviewed by a medical coder for auto-coding errors, ambiguous verbatim terms, and version-consistency (MedDRA versions update biannually; mid-study version changes require a documented re-coding exercise) • External data reconciliation: central lab, ECG core lab, imaging core lab, and IRT/RTSM randomization data are merged and cross-checked against EDC-captured values for the same visit • SDTM conformance: the accumulating dataset is mapped to CDISC SDTM domains (DM, AE, CM, LB, VS, etc.) and run through Pinnacle 21 (OpenCDISC) validation to catch structural and controlled-terminology conformance issues before submission-ready datasets are generated

"Soft lock" freezes the database pending a final quality review pass; "hard lock" — after which no further changes are permitted without a formal unlock procedure requiring sponsor sign-off — triggers dataset finalization and handoff to biostatistics for the analysis defined in the Statistical Analysis Plan (SAP).

A 2021 Tufts CSDD analysis of large multi-site Phase III trials found that studies achieving a 95%+ query closure rate two weeks before target lock date locked on schedule 3.4× more often than studies still below 85% closure at the same checkpoint — making the query closure curve one of the most predictive leading indicators of lock-date risk available to clinical operations teams.