12.3 Data Validation, Edit Checks, Discrepancy / Query Management & Resolution
Key Takeaways
- Data Validation Specifications (DVS) define all programmed automated logic checks and manual review procedures required to ensure trial data is complete, consistent, and scientifically plausible.
- Programmed automated edit checks operate in real time or via batch validation, identifying out-of-range values, invalid date sequences, cross-form inconsistencies, and missing mandatory protocol data.
- Clinical Data Managers (CDMs) and Clinical Research Associates (CRAs) perform complementary manual reviews: CDMs focus on cross-subject data trends and coding, while CRAs focus on on-site source data verification (SDV) and source data review (SDR).
- The electronic query lifecycle follows a strict regulatory workflow: generation (system or manual), site investigation, coordinator/investigator response with source corroboration, and formal data manager closure.
- Self-Evident Corrections (SECs) are strictly limited, prospectively documented administrative corrections that data management can apply without issuing site queries, whereas all clinical, diagnostic, or ambiguous discrepancies require documented site justification.
Data Validation, Edit Checks, Discrepancy / Query Management & Resolution
Core Regulatory Standard: Clinical data validation is the systematic process of verifying that clinical trial data are complete, valid, internally consistent, and compliant with protocol specifications. Governed by ICH E6(R3) Annex 1 section 4.3, sponsors must implement written procedures and automated validation routines to ensure that data discrepancies are identified, investigated, documented, and resolved in a timely and transparent manner.
On the ACRP-CP exam, data validation questions evaluate your understanding of Data Validation Specifications (DVS), programmed edit checks, query generation and resolution workflows, and the strict rules governing Self-Evident Corrections (SECs) versus discrepancies that require site-level clinical justification.
1. The Data Validation Framework & Data Validation Specifications (DVS)
Data validation is not a one-time activity performed at the end of a study; it is an ongoing, continuous quality control process executed throughout the active trial lifecycle.
┌───────────────────────────────────────────────────────────────────────────┐
│ THE DATA VALIDATION SPECIFICATION (DVS) │
├───────────────────────────────────────────────────────────────────────────┤
│ The DVS (or Data Validation Plan - DVP) is the master technical document │
│ that details every programmed check and manual review rule for a trial. │
├───────────────────────────────────────────────────────────────────────────┤
│ CORE DVS ELEMENTS: │
│ • Form & Field Identifier: Exact eCRF domain and variable name │
│ • Check Description: Clear clinical and logical intent of the validation │
│ • Validation Logic: Mathematical / boolean rule (e.g., If A > B then...) │
│ • Error Message Text: Standardized text displayed to site coordinator │
│ • Execution Timing: Real-Time (on entry) vs. Batch Run (nightly/weekly) │
│ • Query Severity: Hard Stop (prevents save), Soft Query, or Internal Flag│
└───────────────────────────────────────────────────────────────────────────┘
2. Programmed Automated Edit Checks
Programmed edit checks are automated algorithms embedded within the EDC system that instantaneously evaluate entered data against predefined logical rules.
| Edit Check Category | Logical Rule / Mechanism | Clinical Trial Example |
|---|---|---|
| Range / Limit Checks | Verifies that numeric values fall within biologically plausible or protocol-defined boundaries. | Flagging a Systolic Blood Pressure entry of 24 mmHg (biologically implausible) or 320 mmHg. |
| Date Logic & Chronology | Enforces temporal sequence rules across protocol milestones. | Flagging an Adverse Event Start Date (2026-08-10) that occurs before the Informed Consent Date (2026-08-14). |
| Format & Character Checks | Verifies that text strings, codes, and numerical values adhere to standard formats. | Ensuring a date field is formatted strictly as YYYY-MM-DD (ISO 8601) or rejecting alphabetic letters in a numeric lab field. |
| Mandatory / Required Checks | Prevents form submission or flags omission of critical protocol variables. | Firing a query if the "Primary Efficacy Score" or "Investigational Product Dose Administered" is left blank. |
| Cross-Form / Cross-Domain Checks | Bivariate or multivariate checks that compare data across multiple distinct eCRFs. | If "Study Drug Discontinued?" = Yes on the Dosing Form, verifying that "Reason for Early Discontinuation" is populated on the Study Completion Form. |
| Future Date Checks | Prohibits recording dates that are in the future relative to system server time. | Flagging a vital signs assessment date entered as tomorrow's date. |
┌───────────────────────────────────────────────────────────────────────────┐
│ REAL-TIME vs. BATCH EDIT CHECKS │
├──────────────────────────────────┬────────────────────────────────────────┤
│ REAL-TIME EDIT CHECKS │ BATCH EDIT CHECKS │
├──────────────────────────────────┼────────────────────────────────────────┤
│ • Fire INSTANTLY when the site │ • Execute periodically (e.g., nightly │
│ coordinator enters data or │ or weekly) via server routines │
│ clicks 'Save Page' │ • Analyze complex cross-subject data, │
│ • Prompts immediate correction │ external lab imports, longitudinal │
│ of obvious typing errors │ trajectories, and safety trends │
│ • Minimizes query backlog │ • Generate automated system queries │
│ • Examples: Format checks, range│ • Examples: Population outliers, │
│ checks, simple date logic │ unreconciled central lab records │
└──────────────────────────────────┴────────────────────────────────────────┘
3. Manual Data Review: Clinical Data Managers vs. CRAs
While automated edit checks catch objective syntactic and range errors, they cannot evaluate nuanced clinical plausibility, contextual medical narratives, or physical source documents. Manual data review is therefore divided between Clinical Data Managers (CDMs) and Clinical Research Associates (CRAs).
┌───────────────────────────────────────────────────────────────────────────┐
│ MANUAL DATA REVIEW RESPONSIBILITIES │
├──────────────────────────────────┬────────────────────────────────────────┤
│ CLINICAL DATA MANAGER (CDM) │ CLINICAL RESEARCH ASSOCIATE (CRA) │
├──────────────────────────────────┼────────────────────────────────────────┤
│ • Remote, trial-wide focus │ • Site-level, patient-specific focus │
│ • Reviews free-text AE and │ • Performs 100% or targeted Source │
│ Medical History descriptions │ Data Verification (SDV) against EHR │
│ • Evaluates cross-form medical │ • Performs Source Data Review (SDR) │
│ plausibility across visits │ for GCP and protocol compliance │
│ • Reconciles external lab data │ • Verifies informed consent execution │
│ • Manages medical coding queues │ • Issues site-specific CRA queries │
│ • Issues CDM data queries in EDC│ during on-site or remote visits │
└──────────────────────────────────┴────────────────────────────────────────┘
4. The Clinical Discrepancy / Query Lifecycle
A Data Query is a formal electronic request for clarification or correction issued to an investigative site when clinical data is missing, inconsistent, out of range, or uninterpretable.
┌───────────────────────────────────────────────────────────────────────────┐
│ THE 4-STAGE QUERY LIFECYCLE │
├───────────────────────────────────────────────────────────────────────────┤
│ STAGE 1: QUERY GENERATION │
│ • System fires automated edit check OR CDM/CRA posts manual query. │
│ • Query text MUST be objective, neutral, and NON-LEADING. │
├───────────────────────────────────────────────────────────────────────────┤
│ STAGE 2: SITE INVESTIGATION & REVIEW │
│ • Study Coordinator / PI reviews query against original source records. │
├───────────────────────────────────────────────────────────────────────────┤
│ STAGE 3: SITE RESPONSE & DATA CORRECTION │
│ • Scenario A (Data Error): Site corrects eCRF field, provides Part 11 │
│ reason for change, and submits response to query. │
│ • Scenario B (Data Correct as Entered): Site confirms value matches │
│ source and provides clinical justification (e.g., 'Value verified in │
│ source records; patient has chronic baseline bradycardia'). │
├───────────────────────────────────────────────────────────────────────────┤
│ STAGE 4: QUERY REVIEW & CLOSURE │
│ • CDM or CRA reviews response. │
│ • If satisfactory: Query is CLOSED. │
│ • If unsatisfactory/incomplete: Query is RE-ISSUED with clarification. │
└───────────────────────────────────────────────────────────────────────────┘
The Non-Leading Query Mandate
A foundational ethical and regulatory rule on the ACRP-CP exam is that queries must never be leading. A leading query suggests the desired answer or encourages the site to alter data to fit protocol criteria.
- Leading Query (PROHIBITED): "Subject's baseline ALT is 48 U/L, which exceeds the protocol inclusion limit of 45 U/L. Did you mean to enter 38 U/L so the subject remains eligible?"
- Non-Leading Query (COMPLIANT): "Baseline ALT is recorded as 48 U/L. Please verify this value against original laboratory source records and clarify or correct as appropriate."
5. Self-Evident Corrections (SECs) vs. Queries Requiring Site Justification
To prevent unnecessary query burden for minor administrative typos, sponsors may establish Self-Evident Correction (SEC) conventions within the approved Data Management Plan.
┌───────────────────────────────────────────────────────────────────────────┐
│ SELF-EVIDENT CORRECTIONS (SEC) RULES │
├───────────────────────────────────────────────────────────────────────────┤
│ PERMISSIBLE SELF-EVIDENT CORRECTIONS (No Site Query Required): │
│ • Standardizing state/country abbreviations (e.g., 'California' -> 'CA') │
│ • Correcting obvious capitalization errors in text fields │
│ • Standardizing unit labels when unambiguous (e.g., 'lbs' -> 'lb') │
│ • Trimming accidental leading or trailing white spaces │
├───────────────────────────────────────────────────────────────────────────┤
│ PROHIBITED AS SECs (Mandatory Site Query & Clinical Justification): │
│ • ANY modification to clinical measurements (lab values, vital signs) │
│ • ANY modification to dates or times (visit dates, AE onset/stop dates) │
│ • ANY modification to drug dosing, batch numbers, or administration route│
│ • ANY modification to medical terms, diagnoses, or causality assessments │
│ • ANY alteration that changes the clinical meaning of recorded data │
└───────────────────────────────────────────────────────────────────────────┘
Exam Watchout: A Clinical Data Manager who alters a subject's recorded adverse event start date or adjusts a lab value based on personal medical interpretation without issuing a formal site query has committed a critical GCP compliance violation.
6. Realistic Clinical Scenario: Resolving Complex Data Discrepancies
Clinical Scenario: David Kim is a Lead Clinical Data Manager reviewing data for a Phase III trial evaluating an oral anticoagulant. During batch validation, David notes a discrepancy on Subject 204:
- The
VS(Vital Signs) eCRF records a resting Heart Rate of32 bpmat the Week 12 visit.- The
AE(Adverse Events) log contains no reported adverse events for bradycardia or cardiovascular symptoms.- The
CM(Concomitant Medications) log shows no antiarrhythmic medications.Operational & Query Resolution Workflow:
- Query Generation: David generates an electronic query in EDC stating: "A resting heart rate of 32 bpm is recorded at the Week 12 visit (2026-08-10). Please verify this value against original source records. If correct, please confirm if any clinical symptoms occurred or if an adverse event should be recorded."
- Site Investigation: The study coordinator, Marcus, pulls the source chart and original vital signs printout from the clinic visit. He discovers that the nurse wrote
82 bpmin the paper clinic chart, but Marcus mistyped32 bpmduring eCRF transcription.- Data Correction & Audit Trail: Marcus updates the eCRF field from
32to82, selects the audit trail reason "Transcription Error", and enters the query response: "Source record reviewed; value was mistyped as 32 bpm. Correct source value is 82 bpm."- Closure: David reviews the audit trail entry and Marcus's explanation. Because the response is complete, verifiable, and accompanied by an audit trail reason, David formally closes the query.
CDM Analysis: This workflow illustrates perfect compliance with GCP data discrepancy standards: the data manager generated an objective, non-leading query; the site investigated original source documents; the correction was made by site personnel with an indelible Part 11 audit trail reason; and the query was formally closed by data management.
A Clinical Data Manager notices that a subject's recorded serum creatinine is 8.5 mg/dL (normal range 0.6–1.2 mg/dL), but no Adverse Event is recorded on the AE log. How should the Data Manager formulate the query to the investigative site?
Which of the following data modifications is permissible as a Self-Evident Correction (SEC) executed directly by clinical data management without issuing a site query?
During a monitoring visit, what is the key difference between Source Data Verification (SDV) and Source Data Review (SDR) performed by a Clinical Research Associate?