Written and maintained by CASRAI Editorial Board
Last updated
An edit check is an automated rule that tests a value, or a combination of values, at the moment data are entered into a study database and raises a data query when the test fails. In clinical and other regulated research, edit checks sit inside the data capture system, for example an electronic data capture (EDC) system, and they are the first line of defence against typing errors, impossible values and missing entries. ICH E6(R3) does not use the words “edit check” but it does require this activity: automated data validation checks that raise queries, applied according to risk and controlled and documented.
What is an edit check?
An edit check pairs a condition with an action. The condition is a statement about the data (a value must be present, must fall in a range, must not precede another date). The action is what the system does when the condition is false: block the entry, show a warning, or open a query that someone must answer. Edit checks are written against the fields of a case report form (CRF) and are part of how a study’s data validation is implemented, as distinct from the manual review and statistical screening described in data cleaning steps.
The same idea appears in research outside trials (survey platforms, registries, REDCap projects), where it is usually called field validation or a data quality rule. The tools differ; the logic is the same.
Types of edit checks
The following groups describe how checks are commonly organised in practice. They are a working vocabulary, not a classification defined by ICH, the FDA or any standards body, and teams name them differently.
| Type | What it tests | Example rule |
|---|---|---|
| Required field | A value is present | Systolic blood pressure may not be blank at a visit marked as completed |
| Range | A value falls between set limits | Systolic blood pressure between 60 and 260 mmHg |
| Format or type | A value has the right form | Visit date entered as a valid calendar date, weight entered as a number |
| Date logic | Dates are in a possible order | Visit date may not be earlier than the consent date |
| Cross-field (consistency) | Two or more fields agree | If “pregnancy test done” is Yes, the sex field may not be Male |
Hard checks and soft checks
This page uses “hard” for a rule that rejects the entry or always opens a query, and “soft” for a rule that flags an unusual but possible value for confirmation. Which rules are hard and which are soft is a design decision recorded in the study’s data validation specification; it is not set by a guideline.
Worked example: a range, required-field and date check
The study defines three rules for the systolic blood pressure form. The limits below are chosen for this illustration; a real study sets its own limits from the protocol and clinical advice.
- R1 Required: systolic blood pressure must not be blank.
- R2 Hard range: systolic blood pressure below 60 or above 260 mmHg opens a query.
- R3 Soft range: systolic blood pressure from 60 to 89 or from 181 to 260 mmHg shows a confirmation warning.
- R4 Date logic: visit date minus consent date must be 0 days or more.
Five illustrative records (invented for this example) are tested in order, and the first rule that fires is reported.
| Subject | Consent | Visit | Systolic (mmHg) | Visit minus consent | Result |
|---|---|---|---|---|---|
| 101 | 2026-03-02 | 2026-03-09 | 128 | 7 days | Pass: 128 is within 90 to 180 and the date gap is not negative |
| 102 | 2026-03-04 | 2026-03-02 | 134 | 2 March minus 4 March = -2 days | R4 fires: visit precedes consent |
| 103 | 2026-03-05 | 2026-03-12 | 1420 | 7 days | R2 fires: 1420 is above 260 (likely 142 mistyped) |
| 104 | 2026-03-06 | 2026-03-13 | 85 | 7 days | R3 fires: 85 is within 60 to 260 but below 90, so a warning |
| 105 | 2026-03-09 | 2026-03-16 | blank | 7 days | R1 fires: required value missing |
The arithmetic: 1 of 5 records passes cleanly, 3 open hard queries (102, 103, 105) and 1 shows a soft warning (104). Record 103 shows why range checks earn their place: a single extra keystroke turns a plausible 142 into 1420, a value no one could have measured, and the check catches it before it enters analysis.
Interpretation: how to read a fired check
| Outcome | What it means | Typical response |
|---|---|---|
| Required-field fires | A value is absent, which may be an omission or a true “not done” | Site supplies the value or records a reason it is not available |
| Hard range fires | The value is outside what the rule treats as possible | Site corrects a transcription error or confirms the value against the source record |
| Soft range fires | The value is unusual but possible | Entrant confirms; no correction is forced |
| Date logic fires | Two dates cannot both be right | Site checks which date is wrong against source |
A fired check is a question, not a verdict. Only the source record can say whether the entered value is wrong.
What the guidelines say
ICH E6(R3) Good Clinical Practice
ICH E6(R3), the final guideline adopted on 6 January 2025 (checked 29 October 2026 at database.ich.org), contains three provisions that govern edit checks. Section 4.2.1(c) on data capture states: “At the point of data capture, automated data validation checks to raise data queries should be considered as required based on risk, and their implementation should be controlled and documented.” Section 4.3.4(e) on validation states that “both standard system functionality and protocol-specific configurations and customisations, including automated data entry checks and calculations, should be validated.” Section 4.2.1(a) adds that where data are transcribed manually into a computerised system, “the need for and the extent of data verification should take the criticality of the data into account.” The practical reading: which checks you build is a risk-based decision, and the checks themselves are part of the system that has to be validated. See what changed in ICH E6(R3) for the wider revision.
21 CFR 11.10 and system checks
The US rule on electronic records, 21 CFR 11.10 (eCFR, checked 29 October 2026 at ecfr.gov), lists controls for closed systems. It does not mention edit checks, but two items concern checks of a different kind: 11.10(f), “use of operational system checks to enforce permitted sequencing of steps and events, as appropriate,” and 11.10(h), “use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.” These govern workflow order and the source of an input; an edit check tests the content of a value. Keeping the two apart avoids citing Part 11 for something it does not say. For the rule as a whole see 21 CFR Part 11.
Data management good practice
The Society for Clinical Data Management’s Good Clinical Data Management Practices (GCDMP) page names “Edit Check Design” as an upcoming chapter listed for public review (scdm.org/gcdmp, checked 29 October 2026). The chapter text was not yet part of that page, so this guide does not rely on it for any definition. See also the dictionary entry for data validator.
Specifying, testing and documenting edit checks
- Specify. For each rule record the field, the condition, the action (reject, warn or query), the message text and the reason the rule exists. ICH E6(R3) 4.2.1(c) asks that implementation be controlled and documented, so this specification is the document.
- Test. Build test records that should pass and test records that should fail each rule, as in the five-record table above, and keep the results. This is the evidence that the configured check works, which 4.3.4(e) calls for.
- Control change. If a limit changes mid-study, change the specification and re-test before release.
Assumptions and common mistakes
- Treating a range as a fact. A limit encodes a judgement. Set it too tight and valid values fire constantly; set it too loose and typos pass.
- Over-firing. Rules that open queries on every plausible value train staff to dismiss queries. Prefer a soft check where a value is unusual but possible.
- Silent auto-correction. A rule that quietly changes a value hides the error and the history of it. The check should raise a query and leave the correction traceable.
- Checking only at entry. Cross-form logic and later-arriving data need checks that run after saving, not only on the field.
- Not testing the check. An untested rule may never fire, or may fire on blank cells you meant to allow.
How to build a simple check in Excel, R or Python
All three snippets apply the order from the worked example (required, hard range, soft range, then date) and return the same results for the five records.
Excel
With subject in column A, consent date in B, visit date in C and systolic in D, enter this in E2 and fill down:
=IF(D2="","Required",IF(OR(D2<60,D2>260),"Hard range",IF(OR(D2<90,D2>180),"Soft range",IF(C2<B2,"Date","Pass"))))R
df <- data.frame(
id = 101:105,
consent = as.Date(c("2026-03-02","2026-03-04","2026-03-05","2026-03-06","2026-03-09")),
visit = as.Date(c("2026-03-09","2026-03-02","2026-03-12","2026-03-13","2026-03-16")),
sbp = c(128, 134, 1420, 85, NA)
)
df$result <- ifelse(is.na(df$sbp), "Required",
ifelse(df$sbp < 60 | df$sbp > 260, "Hard range",
ifelse(df$sbp < 90 | df$sbp > 180, "Soft range",
ifelse(df$visit < df$consent, "Date", "Pass"))))Python
def check(consent, visit, sbp):
if sbp is None:
return "Required"
if sbp < 60 or sbp > 260:
return "Hard range"
if sbp < 90 or sbp > 180:
return "Soft range"
if visit < consent:
return "Date"
return "Pass"Here consent and visit are datetime.date objects. These snippets illustrate the logic only; a regulated study configures the same rules inside its validated data capture system rather than in a spreadsheet.
FAQ
Are edit checks required?
ICH E6(R3) 4.2.1(c) says automated data validation checks to raise data queries “should be considered as required based on risk,” so the need is judged against the risk to the data, and any checks implemented must be controlled and documented.
Does ICH E6(R3) use the term “edit check”?
No. It uses “automated data validation checks” in 4.2.1(c) and “automated data entry checks” in 4.3.4(e). “Edit check” is the data management industry’s term for the same activity.
Do 21 CFR 11.10(f) and (h) require edit checks?
No. Those paragraphs concern system checks on the sequencing of steps and the validity of an input source. They do not describe range, required-field or consistency tests on values.
Sources
- ICH. E6(R3) Guideline for Good Clinical Practice, Step 4, 6 January 2025. https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf. Date checked: 29 October 2026.
- US Code of Federal Regulations. 21 CFR 11.10, Controls for closed systems. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11/subpart-B/section-11.10. Date checked: 29 October 2026.
- Society for Clinical Data Management. Good Clinical Data Management Practices (GCDMP), landing page listing the upcoming Edit Check Design chapter. https://scdm.org/gcdmp/. Date checked: 29 October 2026.
