Data validation is the part of clinical data management that checks the data itself is complete, consistent, and plausible — and resolves the problems it finds. It is the engine of data cleaning: the combination of automated checks, queries, and human review that turns raw entered data into data fit for analysis. Of all the conduct-stage activities, this is where data managers spend most of their time.
One clarification matters before anything else. In clinical trials, “validation” is used in two completely different senses. This guide is about data validation — checking that the data is correct. That is distinct from computer system validation, which proves that the EDC system itself works as intended; for that subject, see our guide to EDC validation requirements. Here, the focus is the data.
What are edit checks in clinical data management?
Edit checks are rules, most of them programmed into the EDC system or clinical database, that test trial data as it is entered. When a value is missing, out of range, in the wrong format or inconsistent with other data, the check fires and raises a query to the site, which then confirms or corrects the value. They are the main automated tool of data validation.
Typical examples of edit checks:
- A visit date earlier than the date the participant signed informed consent.
- A systolic blood pressure outside the plausible range set for the study, such as 1200 mmHg where 120 was meant.
- “Yes” to “Any adverse events?” with no adverse event form completed.
- An age that does not match the date of birth and the visit date.
- A required field, such as the date of a study drug dose, left blank.
- A pregnancy test result recorded for a male participant.
Each check carries query text that tells the site what to look at, for example “Visit date is before the informed consent date. Please verify.” The full set of checks for a trial is defined in the data validation plan, described below.
What is data validation in clinical data management?
Data validation is the process of confirming that collected data meets defined quality rules — that values are present where expected, fall within plausible ranges, agree with related data points, and are logically consistent. Where data fails a rule, the discrepancy is identified, queried, and resolved. Validation runs continuously through the conduct stage rather than as a single step, and its purpose is a clearly defined level of data quality: data fit for the decisions that depend on it.
Because not all data carries the same weight, cleaning is risk-based: effort concentrates on the critical data — safety and the primary endpoints — and once the data is fit for purpose, some residual issues in lower-impact fields are acceptable rather than chased to perfection.
It is worth repeating the distinction: data validation cleans the data, while computer system validation qualifies the system. A trial needs both, but they are different activities performed by different people for different reasons. The rest of this guide concerns data validation only.
Types of edit checks in clinical data management
Edit checks are the programmed and manual rules that test data against expectations. They are specified during set-up and run throughout conduct, flagging values that need attention. The common types are:
- Missing data checks — flag required fields that have been left blank.
- Range checks — flag values outside a plausible or permitted range, such as an impossible age or an out-of-range laboratory result.
- Format checks: flag values in the wrong format, such as a date that is not a valid calendar date or text entered in a numeric field.
- Consistency or cross-field checks — flag values that contradict each other, such as a stop date earlier than a start date, or a finding inconsistent with a recorded condition.
- Logical checks — flag combinations that should not occur given the protocol, such as a visit recorded out of sequence.
- Cross-form and cross-visit checks: compare data across forms or visits, such as a concomitant medication given for an adverse event that does not appear on the adverse event form, or a body weight that changes implausibly between visits.
- Protocol-specific checks: test rules written into the protocol, such as the inclusion and exclusion criteria, visit windows or the dosing schedule.
Real-time and offline edit checks
Most edit checks are automated and run in real time as data is entered, which is why their design during set-up matters so much. Not every automated check can run at the point of entry, though: some — spanning multiple visits, a patient's full set of adverse-event records, or data drawn from different systems — run as back-end (offline) checks in batch against submitted or consolidated data, with their findings then evaluated manually. The mechanics of how these checks are built and configured in an EDC system are covered in our complete guide to EDC systems; here the focus is what they are for and how they fit the cleaning process.
Hard and soft edit checks
Edit checks also differ in how they respond. A hard edit check stops a value from being saved until it is corrected, so it is kept for values that can never be right, such as an invalid date. A soft edit check lets the value be saved but raises a query, and the site either corrects the value or confirms that it is right. Hard checks are used sparingly, because an unusual value may still be the true one and the site must be able to record what the source document says.
The data validation plan and edit check specification
The edit checks are not improvised — they are specified in a data validation plan (sometimes called a data validation specification). This document lists every check, what it tests, the message it raises, and how a flagged record should be handled. It is written and tested during set-up so that, when data starts to arrive, the cleaning rules are already defined, agreed, and validated. A clear data validation plan is what makes cleaning consistent and auditable rather than ad hoc.
In some organisations the plan is a short document that describes the approach, and the detailed list of checks sits in a separate edit check specification. Either way, it sits alongside the trial’s data management plan, which refers to it.
What a data validation plan contains
For each edit check, the plan or specification typically records:
- Check ID: a unique number, so every query can be traced back to the rule that raised it.
- Form and fields: the eCRF page or pages and the data points involved.
- Description: what the check tests, in plain language.
- Logic: the exact condition that fires the check, written precisely enough to program and test.
- Query text: the message the site sees when the check fires.
- Check type: programmed in the EDC or run offline, and hard or soft.
Many plans also describe the manual reviews: which data listings are reviewed, by whom and how often.
Who writes and approves the data validation plan
The data manager usually drafts the plan from the protocol and the eCRF design. People who depend on the data, such as the clinical team, the medical monitor and the biostatistician, review the draft, and it is approved before the checks are programmed. When a CRO runs data management, the sponsor normally reviews and approves it as part of its oversight. The checks themselves are built by a database programmer or EDC build team; see clinical data management roles and responsibilities.
Testing edit checks before go-live
Every programmed check is tested before the database goes live. Test data is entered to show that each check fires when it should, stays silent when it should not and shows the right query text. Testing follows the specify-build-test cycle of study set-up: technical testing by the build team, then user acceptance testing (UAT), in which data managers and other users confirm that the study works as specified. The results are documented, and checks added or changed later, for example after a protocol amendment, go through the same cycle. TriTiCon’s Clinical Data Management Set-up Process course covers the specify-build-test cycle and the difference between technical testing and UAT.
Query management
When a check flags a value — or a reviewer spots a problem — a query is raised to the site to clarify or correct the data. Query management is the controlled workflow of raising, routing, answering, and closing these queries, with every step recorded in the audit trail. The aim is to resolve discrepancies at source, so the correction comes from the people who hold the original record rather than from an assumption. This reflects a core GCP principle: the investigator owns the trial data, and only the site can change it — a data manager or monitor cannot correct even an obvious error directly, but instead raises a query for the site to resolve. Tracking open and ageing queries is a core part of monitoring a trial's data-cleaning progress.
Discrepancy management and manual review
A discrepancy is any data point that does not meet expectations, whether flagged automatically or found by a person. Discrepancy management is the disciplined handling of these from identification to resolution. Not everything can be caught by a programmed rule, which is why automated checks are paired with manual data review — data managers and medical reviewers examining listings and patterns to find issues that no edit check anticipated. Source data review and source data verification complement both: in source data review (SDR) a monitor examines the site’s source records for completeness and consistency, while in source data verification (SDV) the source is compared directly against what was entered in the eCRF. Together, automated checks, manual review, and source review and verification form the layered approach that produces a genuinely clean dataset.
Where data validation fits in the lifecycle
Data validation is a continuous conduct-stage activity. It begins as soon as data is entered and continues until cleaning is complete, working in parallel with reconciliation and medical coding. It feeds directly into the declaration of a clean file: a database cannot be declared clean while validation queries remain open. Completing data validation is therefore one of the prerequisites for database lock.
Frequently asked questions
What is data validation in clinical data management?
Data validation is the process of checking that collected trial data meets defined quality rules — complete, within range, consistent, and logical — and resolving any discrepancies found. It combines automated edit checks, query management, and manual review, and runs continuously through the conduct stage. Its goal is data of a defined quality, fit for analysis, and it must be complete before database lock.
What are edit checks in clinical data management?
Edit checks are programmed or manual rules that test data against expectations. Common types include missing-data checks, range checks for implausible values, consistency or cross-field checks for contradictory values, and logical checks for combinations that should not occur. Most are automated and run as data is entered, raising queries to the site when a value needs attention. Typical examples are a visit date before the informed consent date and a “Yes” to adverse events with no adverse event form completed.
What is the difference between data validation and computer system validation?
Data validation checks that the data is correct — complete, consistent, and plausible — through edit checks and review. Computer system validation proves that the EDC system itself works as intended, through documented testing. They share the word “validation” but are different activities: one qualifies the data, the other qualifies the system. A trial needs both.
What is query management?
Query management is the controlled workflow of raising, routing, answering, and closing queries when data is flagged by a check or a reviewer. Every step is recorded in the audit trail, and the aim is to resolve discrepancies at source so corrections come from the holders of the original record. Tracking open and ageing queries is a key measure of cleaning progress.
What is a data validation plan?
A data validation plan, sometimes called a data validation specification, lists every edit check for a trial: what it tests, the message it raises, and how a flagged record should be handled. It is written and tested during set-up so that the cleaning rules are defined and agreed before data arrives, making the cleaning process consistent, complete, and auditable.
What are the types of edit checks in clinical data management?
The main types are missing-data checks, range checks, format checks, consistency checks within a form, cross-form and cross-visit checks, and protocol-specific checks such as eligibility criteria and visit windows. Checks are also described by how they run, in real time in the EDC system or offline in batch, and by how they respond: hard checks block a value, soft checks raise a query.
What is the difference between hard and soft edit checks?
A hard edit check stops a value from being saved until it is corrected, so it is used for values that can never be right, such as an invalid date. A soft edit check lets the value be saved but raises a query, which the site answers by correcting or confirming the value. Hard checks are used sparingly, because an unusual value may still be the true one.
What is an edit check specification?
An edit check specification is the detailed list of edit checks for a trial, either part of the data validation plan or a separate document. For each check it gives a check ID, the form and fields involved, a description, the programming logic and the query text. It is approved before the checks are built and is the reference used to test them, including in user acceptance testing.
Learn data validation in context with TriTiCon
Data validation is the core of the conduct stage. TriTiCon's training covers it — edit checks, query management, and data cleaning — within the wider conduct process in The Clinical Data Management Conduct Process. You can explore the full TriTiCon course platform to see how data cleaning connects to the rest of the lifecycle.
