The data validation plan lists every automatic and manual check on your data, what each one does when it fires, and who acts on it. This page gives the sections, a specification table with worked example rows, and how to build the checks in Capture.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Purpose and scope
Check types and severity
Edit check specification
62 checks across 9 forms
Derived fields
Manual data review and listings
Testing and approval
Change control
Key points
What it is
ICH E6 expects sponsors to have systems that ensure data are accurate, complete and verifiable, and to be able to show how data were checked. The DVP is the document that makes that checkable: an inspector can pick any check from the specification, find it in the system, and see it fire on a bad value. Without it, "the data were validated" is an assertion and not a record.
The plan also protects the schedule. Writing checks before the build exposes protocol ambiguity early, such as an undefined unit or an eligibility rule that depends on a lab value nobody collects. Checks that are specified late tend to be added in bulk before lock and produce a flood of queries at the worst time. Treat the DVP as part of study setup, reviewed at the same time as the CRF design.
Automatic checks run while the site is still entering data, so the person who knows the answer corrects it in minutes. Capture's edit checks support range high, range low and custom value rules with a configurable priority, and a check that fails raises an auto-query without anyone intervening. Checks that need several records at once, for example a visit date later than a termination date on another form, are normally specified as data review listings, run by a data manager, and raised as manual queries. Put each check in the right category in the plan and the plan will match what the system does.
Give each check a priority so the site knows what to fix first. A typical scheme is: critical (eligibility, primary endpoint, safety), major (secondary endpoints, dates that drive windows) and minor (completeness of context fields). The action column states what the system or reviewer does: raise a query with defined text, show an informational flag, or list the record for review.
Systolic blood pressure
SYSBPAbove the range high of 260. Please confirm the value.
Template
| # | Section | What to include |
|---|---|---|
| 1 | Purpose, scope and references | Study, protocol version, link to the DMP and CRF completion guidelines, who approves the plan. |
| 2 | Check types and severity | Definitions of range, consistency, completeness and date checks, and the priority scheme. |
| 3 | Edit check specification | The table of checks (see below), one row per check, grouped by form. |
| 4 | Derived and calculated fields | Each derived value, its formula, inputs, units and rounding rule. |
| 5 | Manual data review | Listings to run, frequency, reviewer, and how findings become manual queries. |
| 6 | Query text standards | Standard wording so queries are neutral, specific and never leading. |
| 7 | Testing and approval | Test cases for passing and failing values, who tested, evidence kept, approval before go-live. |
| 8 | Change control | How checks are added or changed after go-live, impact on already-entered data, re-approval. |
| 9 | Appendices | Reference ranges, unit conversions, listing definitions. |
Edit check specification
One row per check. These rows use demo values, so replace the thresholds with those from your protocol and clinical team.
| Check ID | Form and field | Rule | Type and priority | Action |
|---|---|---|---|---|
| VS-001 | Vital signs, systolic BP | Value above 260 or below 60 mmHg | Range, major | Auto-query: confirm value and unit |
| VS-002 | Vital signs, heart rate | Value above 200 or below 30 bpm | Range, major | Auto-query: confirm value |
| DM-001 | Demographics, age | Calculated from date of birth and consent date; outside 18 to 75 | Calculated, critical | Query: eligibility review |
| AE-001 | Adverse event, severity | Value is "Severe" | Custom value, critical | Query: confirm seriousness assessment |
| LB-001 | Laboratory, ALT | Value above 3 times the upper limit of normal | Custom value, critical | Query: confirm value and flag for safety review |
| XF-001 | AE start date vs consent date | AE start before date of consent | Cross-form, major | Listing review, manual query |
| CM-001 | Concomitant medication | Medication entered with no start date | Completeness, minor | Listing review, manual query |
Range and custom-value rules fire as auto-queries in Capture. Rows marked cross-form are specified as listings for manual review.
Build it in Capture
Each automatic row in the specification maps to a setting on the form field. Enter the range high and range low values or a custom value rule, choose the priority, and save. During entry, a value that breaks the rule raises an auto-query for the site to answer, and derived values such as age from date of birth, BMI or QTc are shown read-only as calculated fields so they cannot be mistyped. Every query and every change is in the field-level audit trail with the reason for change.
Open queries
14
Auto-queries this week
31
Overdue over 7 days
2
Build the form, enter passing and failing values and watch the auto-queries fire. Free sandbox, no credit card.
How to use it
Start from the protocol: eligibility criteria, primary and key secondary endpoints, safety data. These get the strictest checks.
ID, form and field, exact rule with units and thresholds, type, priority and action. Remove vague wording such as "unusual".
Anything decided by one field goes to an automatic check. Anything comparing records goes to a listing.
State each formula and its inputs so the calculated field, the plan and the analysis agree.
Configure the checks on draft forms, then test each with a passing and a failing value. Record who tested and the result.
Approve the forms (approved forms are locked for live use) and sign the plan. Later changes go through change control with a reason.
Track query volume by check. A check that fires constantly is usually a rule that is too tight or a form that is unclear. Use query management data to tune it.
Before sign-off
Eligibility, primary endpoint and safety fields each have at least one check.
Thresholds, units and comparison direction are explicit.
Each cross-form rule names the listing, reviewer and frequency.
Standard wording that never suggests the answer.
Pass and fail results for each check, filed with the approved version.
Who approves new checks and how existing data are re-checked. See database lock for the end of the process.
A document that specifies every check applied to trial data: the rule, the field, the severity and what happens when the check fails. It also covers derived fields, manual data review, testing and change control.
The data management plan describes the whole data lifecycle, from CRF design to archiving. The data validation plan is the detailed specification of the checks, and the DMP normally references it.
The table at the core of the DVP, with one row per check: ID, form and field, rule, type, priority and action. It is the document a programmer or a no-code builder implements and a tester verifies.
Range high, range low and custom value rules on a field, with a configurable priority. A failed check raises an auto-query at entry. Checks that compare several records are handled through review listings and manual queries.
Usually the lead data manager drafts it with input from the biostatistician and clinical team, and the sponsor approves it. It should be approved before the first participant is entered.
Keep a test record per check with the values entered, the expected and actual result, who tested and when. The sandbox is a convenient place to run them before go-live.
Keep exploring
Build edit checks, trigger auto-queries and test them free. No credit card.