This is a ready-to-use edit check specification (ECS). It defines every automated data-validation rule for an EDC study build so the rule is programmed, tested, and traceable, and so an auditor can reconcile what the spec says to what the database enforces. Replace every <<FILL: ...>> placeholder, set your document numbers, and route through your normal review. A filled specimen follows. Confirm each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Edit Check Specification, Study <<FILL: protocol number>> |
| Document number | <<FILL: ECS-ID, e.g. ECS-ABC201-01>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: date>> |
| Governing DMP | <<FILL: DMP-ID>> |
| EDC system / version | <<FILL>> |
1. Purpose and severity model
Edit checks are automated rules that flag data that is missing, out of range, internally inconsistent, or implausible, at entry (online) or in batch. They operationalize the GCP obligation to assure data accuracy and consistency. Severity model used in this study:
- Hard (blocks save): reserved for format and required-field errors. Over-using hard stops pushes sites to enter placeholder values, which is worse than a query.
- Query (raises a data query): the default for consistency and plausibility issues; the site reviews the source and responds, and any correction is captured in the audit trail.
- Soft warning (informs, no required resolution): used sparingly for non-critical prompts.
Firing point: online for single-form checks; batch for cross-form and external-data checks where the comparator may not exist at entry time.
2. Edit check table
Each check has a unique ID, the form and fields, the logic in plain language, the severity, the firing point, and the exact query text the site sees. Query text must be clear and specific and must not lead the site to a particular answer.
| Check ID | Form | Field(s) | Logic | Severity | Firing | Query text |
|---|---|---|---|---|---|---|
<<FILL: VS001>> | <<FILL: Vital Signs>> | <<FILL>> | <<FILL: condition that flags>> | <<FILL: Hard/Query/Soft>> | <<FILL: Online/Batch>> | <<FILL: site-facing text>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Check types to cover across the build: missing/required, range, format/valid-value, cross-field consistency, cross-form consistency, cross-visit/longitudinal, protocol logic, and date logic.
3. Test cases (for UAT)
Every check needs at least one case that should fire (positive) and one that should not (negative), plus boundary values for range checks. This table is the evidence UAT reconciles against.
| Check ID | Test case | Input | Expected result | Actual | Pass/Fail | Tester / Date |
|---|---|---|---|---|---|---|
<<FILL: VS002>> | Below lower bound | <<FILL: PULSE = 29>> | <<FILL: fires>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: VS002>> | At lower boundary | <<FILL: PULSE = 30>> | <<FILL: does not fire>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: VS002>> | Above upper bound | <<FILL: PULSE = 201>> | <<FILL: fires>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Acceptance criteria
- Every check in the table is programmed and traceable to its check ID in the EDC.
- Each check has a documented positive and negative test result; range checks are tested at the boundary.
- Query text is clear, specific, and non-leading.
- The programmed behavior matches the spec exactly; any difference is a defect resolved before go-live.
- No check generates so many false positives that sites learn to ignore it (tuned in UAT and early conduct).
5. References
ICH E6(R2)/E6(R3), Good Clinical Practice (data accuracy and consistency, computerized systems). 21 CFR Part 11; EudraLex Volume 4, Annex 11 (validation, audit trail).
Confirm the current version of each reference before issue.
6. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows three checks and one check’s test cases completed for an illustrative build. Values are illustrative.
Edit check table (excerpt):
| Check ID | Form | Field(s) | Logic | Severity | Firing | Query text |
|---|---|---|---|---|---|---|
| VS001 | Vital Signs | SYSBP, DIABP | If SYSBP <= DIABP | Query | Online | ”Systolic BP is not greater than diastolic BP. Please verify and correct.” |
| VS002 | Vital Signs | PULSE | If PULSE < 30 or PULSE > 200 | Query | Online | ”Pulse value is outside the expected range (30-200). Please verify.” |
| AE003 | Adverse Events, Informed Consent | AESTDAT, ICDAT | If AESTDAT < ICDAT | Query | Batch | ”Adverse event start date is before informed consent date. Please verify dates.” |
Test cases for VS002:
| Check ID | Test case | Input | Expected result | Actual | Pass/Fail | Tester / Date |
|---|---|---|---|---|---|---|
| VS002 | Below lower bound | PULSE = 29 | fires | fires | Pass | S. Lin, 18-Jul-2026 |
| VS002 | At lower boundary | PULSE = 30 | does not fire | does not fire | Pass | S. Lin, 18-Jul-2026 |
| VS002 | Above upper bound | PULSE = 201 | fires | fires | Pass | S. Lin, 18-Jul-2026 |
The boundary case is the important one: a check written as ”> 200” must not fire at exactly 200 and must fire at 201. Testing only the obvious out-of-range value misses the off-by-one that lets bad data through at the edge.
Common inspection findings this specification prevents
- Edit checks specified but never programmed, or programmed differently from the spec, with no UAT evidence reconciling the two.
- Range checks that fire at the wrong boundary, so edge values pass silently.
- Leading query text that tells the site what to answer.
- Over-use of hard stops, so sites enter placeholder data to get past the block.
- No traceability from the spec to the programmed check to the test result.
How to adapt this specification
- Build the check table from the protocol logic, the CRF, and the safety and endpoint requirements; cover every check type listed in section 2.
- Classify severity deliberately; keep hard stops to format/required only.
- Write one positive, one negative, and boundary test cases for every check, and use this table as the UAT evidence.
- Tune noisy checks in early conduct using query metrics, and version the spec when checks change.
- Confirm the references in section 5 against the current published version before issue.