Edit checks that catch errors while the participant is still in the room
An edit check that fires at entry costs a coordinator ten seconds. The same error found at a monitoring visit costs a query cycle, and found at database lock it costs days. Build range and custom checks without code, with priorities and automatic queries.
- Range and custom-value rules
- Auto-queries with priority
- No programming
Free sandbox · No credit card · 21 CFR Part 11 aligned
Edit checks / auto-queries
2Type
Range High
Operator
Greater than
Value
180
Priority: High
Type
Range Low
Operator
Less than
Value
80
Priority: Normal
Query raised automatically
Value 192 violates limit (180). Please verify.
0
lines of code to write an edit check
3
query states: open, answered, closed
14
built-in calculators that remove typed derivations
1
audit trail covering values, queries and responses
Key points
- Edit checks are rules that validate data as it is entered or reviewed. When a value breaks a rule, the system raises a query for the site to confirm or correct.
- Most checks fall into a few types: required fields, ranges, allowed values, date logic, consistency between fields, and cross-form reconciliation.
- "Soft" checks warn and query; "hard" checks refuse the value. Use hard checks sparingly: an unusual value may be real.
- Write checks in an edit check specification, test them with deliberately wrong data, and target the fields that matter to safety and endpoints.
- In Capture, range and custom-value checks raise auto-queries with a priority, and a corrected value can close its own auto-query.
The basics
Types of edit checks, with examples
Every EDC implements edit checks slightly differently, but the underlying logic is the same. Knowing the types helps you decide what belongs in the eCRF itself, what belongs in data review, and what does not need checking at all.
Required and conditional required
A field must be completed, or must be completed when another answer makes it relevant (for example, seriousness criteria when an AE is serious). Skip logic handles most conditional cases by only showing the follow-up when it applies.
Range checks
A numeric value must fall between a low and a high limit. Wide ranges catch typos and unit errors (a weight of 814 kg); protocol-specific ranges catch eligibility or safety problems (systolic blood pressure above the protocol's threshold).
Custom-value checks
A specific answer needs attention: any non-zero answer on a suicidal ideation item, "Not met" on an inclusion criterion, or "Yes" to a question that should trigger follow-up. These are often the most clinically important checks in a study.
Date and window checks
Dates must be in a logical order (an AE cannot resolve before it starts) and visits should fall within their protocol windows. Capture keeps AE onset and resolution consistent, flags out-of-window visits, and can raise an automatic query when a visit date falls outside its window.
Cross-form and cross-visit review
Some consistency checks span forms or visits: an AE treated with a drug that is missing from the concomitant medications log, or a weight change too large to be plausible between visits. These are usually handled in data review listings and comparison grids across visits rather than as entry-time checks, so sites are not blocked by data that another form will complete later.
Open
38
Answered
21
Closed this week
112
Mostly unit and typing errors
High priority
Auto-queries
From broken rule to resolved query, in the casebook
When a value breaks a check, Capture raises an auto-query in the site's action list straight away. The site answers from the form itself, and when a corrected value satisfies the rule, its auto-query can close automatically. Monitors and data managers raise their own manual queries in the same workflow.
- Auto-queries from range and custom-value checks, with configurable priority.
- Open, answered and closed states, numbered, with priority.
- Answered in place from the casebook.
- Query list exportable to CSV for metrics.
Edit check specification
What goes in an edit check specification
An edit check specification (ECS) documents every check before it is built, so it can be reviewed, tested and traced. A simple table is enough for most studies.
| Column | Purpose | Example |
|---|---|---|
| Check ID | Unique reference used in testing and change control | VS-003 |
| Form and field | Where the check runs | Vital signs · Systolic BP |
| Rule | The logic in plain language | Value below 60 or above 250 |
| Type | Range, required, custom value, date, window | Range |
| Priority | How urgently sites should respond | Medium |
| Query text | Exactly what the site sees | Systolic BP outside 60 to 250 mmHg. Please confirm or correct. |
| Test cases | Values that should and should not fire | 59 fires, 60 passes, 250 passes, 251 fires |
| Rationale | Why the check exists | Catches unit errors and typos |
Write a check, then try to break it
Add range and custom-value checks to a form in the free sandbox and test them with sample data.
Strategy
More checks is not better data
It is tempting to add a check to every field. The result is query fatigue: sites answer dozens of low-value queries, response times slow down, and the important ones get lost. Risk-based approaches encouraged by ICH E6(R3) apply here too. Focus checks on the data that is critical to participant safety and to the primary and key secondary endpoints, and handle the rest through review.
Prefer prevention to detection
A calculated field cannot be mistyped, a date field cannot contain text, and skip logic cannot leave a follow-up blank. Many checks become unnecessary when the form design is right. See how to design an eCRF.
Write queries sites can act on
"Value out of range" tells a coordinator nothing. "Systolic BP outside 60 to 250 mmHg. Please confirm or correct" tells them what to look at and what to do.
Review check performance
After the first few weeks, look at which checks fire most often and how many of those queries led to a change. Checks that fire constantly and rarely change anything should be widened or removed.
What is an edit check in a clinical trial?
A rule that validates data as it is entered or reviewed in the EDC. When data breaks the rule, a query is raised for the site to confirm or correct the value.
What is the difference between soft and hard edit checks?
Soft checks accept the value and raise a query; hard checks refuse it. Most clinical checks should be soft, because unusual values can be real.
What is an edit check specification?
A document listing every check with its ID, form and field, rule, priority, query text, test cases and rationale, used for review, testing and change control.
Do I need a programmer to write edit checks in Capture?
No. Range and custom-value checks with priority are configured in the form builder.
What happens when a site corrects a value?
The correction is recorded in the audit trail with a reason, and when the corrected value satisfies the rule, its auto-query can close automatically.
How many edit checks should a study have?
Enough to protect safety data and key endpoints. Too many checks cause query fatigue; review check performance early and adjust.
Keep exploring
Related pages
Query management software
The workflow after a check fires.
How to design an eCRF
Prevent errors before checking for them.
Clinical data management software
Review, freeze, lock and export.
Vital signs eCRF template
Range checks in practice.
Risk-based monitoring and SDV
Focus effort on critical data.
What is database lock?
Where clean data ends up.
Catch errors at entry, not at lock
No-code edit checks with auto-queries. Free sandbox, no credit card.