Automated edit checks for clinical trials
AccuraTrials drafts edit checks from the protocol clauses that require them, proves each one on the same engine the live form runs, and enforces it as sites enter data once a data manager approves it. Every firing is logged with the clause and the rule version behind it.
The basics
What is an edit check?
- Edit check
- An automated rule in an electronic data capture (EDC) system that tests clinical trial data as it is entered: a value outside its allowed range, a required field left blank, two dates in the wrong order. When a check fails it can stop the value, warn the site or open a query, so errors are resolved at the site instead of months later in data cleaning.
A single study can need hundreds of edit checks. In a typical EDC build they are written into a specification spreadsheet, programmed by hand, tested, and then re-programmed and re-tested every time the protocol is amended.
Along the way the link between each check and the protocol sentence that required it is lost. When an inspector asks why a check exists, or why it changed, someone reconstructs the answer from old spreadsheets and email.
How it works
From a protocol clause to a check at the site.
Five steps, each one on the record. The model drafts, deterministic code enforces, and a person decides.
01
Found in the protocol
The protocol intelligence layer compiles the protocol into a study model and harvests the requirements a check should enforce: required fields, ranges, date order, allowed values and consistency between fields. Each proposed check carries the page, section and verbatim quote it came from.
02
Or described in plain English
A data manager can also type a rule the way they would say it, such as “systolic blood pressure between 60 and 250”, and the AI proposes the field, operator, value and message. Before anything reaches the model, the description is screened for patient identifiers and refused if one is found, and a deterministic guard refuses off-topic requests and injected instructions. Every request and refusal is logged.
03
Validated before approval
A proposal is not trusted because a model produced it. It must attach to a field that exists on the form. Any regular expression must compile in a linear-time RE2 sandbox, which rules out catastrophic backtracking on the patient form. Pattern and format checks are self-tested with examples that should pass and fail, on the same evaluator the live form uses. A check that fails a gate is rejected or sent back once with the reason; it is never shipped.
04
Approved by a person
Nothing goes live on the model’s authority. A data manager reviews the compiled logic, the source clause and the self-test, then approves it. The AI may only propose required, range, format, consistency, allowed-value, pattern and formula checks; business-logic and cross-form rules are written by people.
05
Enforced at entry, recorded for good
Approved checks run as versioned, deterministic code while sites enter data, so the same input always gives the same result. Every firing is written to the audit trail with the rule version, the clause it enforces and the moment it fired.
Check types
Nine kinds of check. Seven the AI may draft.
The engine runs nine rule types. The AI may propose the first seven; the two that execute richer logic are written by your data managers.
| Check type | What it tests | Example | Drafted by |
|---|---|---|---|
| Required | A field that must be answered | The informed consent date is recorded | AI or people |
| Range | A number or date inside bounds | Systolic blood pressure is 60 to 250 mmHg | AI or people |
| Format | A value in a registered format | The visit date is a valid calendar date | AI or people |
| Consistency | Two fields on the form agree | The visit date is on or after the consent date | AI or people |
| Allowed values | One of a fixed list | The dose level is 10, 20 or 40 mg | AI or people |
| Pattern | A value matching a safe regular expression | The subject ID looks like S-0000 | AI or people |
| Formula | A calculated condition | BMI from height and weight is between 12 and 70 | AI or people |
| Business logic | A multi-condition study rule | A pregnancy test is required when sex is female and age is under 55 | People only |
| Cross-form | Values on a subject’s other forms | Adverse event onset is on or after the first dose date | People only |
Checks on fields hidden by skip logic never run, never block a save and never raise a query.
When a check fires
Stop what is unsafe. Ask about the rest.
Severity decides what a site experiences. Only values that must never enter the record block a save; everything else keeps the site moving with the evidence attached.
What a coordinator sees
The right amount of friction for each finding, and never a silent pass.
- Errors stop unsafe values
- An error-level check blocks the save until the value is corrected.
- ERROR
- Warnings ask, not refuse
- The value saves and the site is asked to confirm it, so a plausible outlier never pushes data back onto paper.
- WARNING
- Queries open themselves
- A failing check can raise a query on the exact field automatically, carrying its message, so the site and the monitor start from the same evidence.
- AUTO-QUERY
- Skipped fields stay quiet
- A field hidden by skip logic never triggers a check or raises a spurious query.
- BRANCHING-AWARE
- No silent passes
- A check that cannot run, such as one waiting on a partial date or a missing baseline, is reported as not checked with a reason, never as passed.
- NOT CHECKED
Compared
Hand-programmed edit checks, and what changes here.
| Stage | In a typical EDC build | With AccuraTrials |
|---|---|---|
| Specification | A spreadsheet written from the protocol by hand | Drafted from the clause that requires it, with the quote attached |
| Implementation | Programmed by a study builder | Compiled from the approved rule into versioned, deterministic code |
| Testing | Test scripts written and run separately | Pattern and format checks self-test on the live evaluator; other checks receive applicable validation, followed by your study validation |
| Amendments | A change order, re-programming and re-testing | A reviewed change your team authorizes and deploys after validation |
| Traceability | The link to the protocol is usually lost | Every check and every firing names its clause and rule version |
| AI safeguards | Not applicable | Identifier screening, a scope guard, a regex sandbox and human approval |
A worked example
One Phase III protocol, compiled into a reviewable study build. Every rule is mapped to the protocol text that required it.
- 8visits
- 6forms
- 54fields
- 70validation rules
- 16branching rules
FAQ
Edit checks, answered plainly.
Updated September 2026
What is an edit check in a clinical trial?
An edit check is an automated rule in an electronic data capture (EDC) system that tests trial data as it is entered, such as a value outside its allowed range, a missing required field or two dates in the wrong order. When a check fails it can block the value, warn the site or open a query, so errors are resolved at the site rather than months later in data cleaning.
How does AccuraTrials generate edit checks automatically?
The protocol intelligence layer compiles the protocol into a study model and harvests the requirements a check should enforce, each with the page, section and quote it came from. It drafts a check for each requirement, proves the check against the form and the live evaluator, and hands it to a data manager, who approves it before it runs.
Can I write an edit check in plain English?
Yes. Type the rule the way you would say it, for example “age must be 18 or older”, and the AI proposes the field, operator, value and message for your review. The description is screened for patient identifiers first, and requests that are not about a validation rule, including attempts to inject instructions, are refused and logged.
Does AI decide which edit checks go live?
No. The AI only proposes. A data manager reviews the compiled logic, its source clause and its self-test, and approves it before it runs on live entry. The AI may propose required, range, format, consistency, allowed-value, pattern and formula checks; business-logic and cross-form rules are written by people.
How are AI-drafted edit checks tested?
Before anyone sees a proposal it must attach to a field that exists on the form, any regular expression must compile in a linear-time RE2 sandbox, and pattern and format checks are self-tested with examples that should pass and fail, on the same evaluator the live form uses. Failures are rejected or sent back once with the reason. Your own validation of the study build still applies.
What happens when an edit check fires?
It depends on severity. An error blocks the save until the value is corrected, a warning lets the value save and asks the site to confirm it, and a failing check can open a query on the exact field automatically. Checks on fields hidden by skip logic never run, and a check that cannot be evaluated is reported as not checked, never as passed.
What happens to edit checks when the protocol is amended?
The amendment is compiled like the original and compared with the running study, so changed checks appear as a reviewed diff alongside how much collected data sits behind each one. Your team reviews and authorizes deployment; timing depends on amendment scope and your validation process. Every change is recorded with its effective date, prior value and reason.
Does the AI see patient data when it drafts an edit check?
No. The rule compiler works from the rule description and the form’s field definitions, not subject records. Descriptions are screened for patient identifiers before they reach the model, and a request that contains one is refused. Your protocols and patient data are not used to train models.
Are edit checks part of the 21 CFR Part 11 audit trail?
Yes. AI requests, refusals and proposals are logged, approvals are attributed and time-stamped, and every automated evaluation on live data is written to the same audit trail as a human edit, naming the rule version and the clause it enforces. AccuraTrials is built to support Part 11; compliance itself is demonstrated by the sponsor for its own validated system.
Can we still write edit checks by hand?
Yes. Data managers can write and edit every check type in a visual rule builder, with no XML and no scripting, and business-logic and cross-form rules are always written by people. Hand-written and AI-drafted checks run on the same engine and land in the same audit trail.
Bring one protocol. Watch its checks drafted live.
Thirty minutes on the real platform with the team that built it.
Or email us: jgui@accuratrials.com