How to write edit checks for an eCRF

An edit check is a rule the EDC runs when a site saves a value. When the value breaks the rule, the site sees a message and fixes the entry before it turns into a query from your data manager. You write good edit checks by listing them in a specification first, then building and testing each one against the protocol.

What an edit check covers

Most checks fall into five families. Range checks compare a value with the limits you expect, such as a body temperature between 35.0 and 42.0 °C. Required checks stop a key field from staying empty. Date checks keep events in order, such as a visit after the consent date. Cross-field checks compare two answers, such as a pregnancy test on a participant recorded as male. Calculation checks compare a derived value, like BMI, with the fields it comes from.

How to write edit checks in 6 steps

1. List the critical data. Start from the endpoints, the eligibility criteria and the safety data. Put your first checks there, since those fields decide whether the results hold.
2. Write a specification row per check. Record the form, the field, the rule in plain words, the message, and the action: warning, query or blocking.
3. Pick the action with care. Use a warning for values that are rare but possible. Keep blocking checks for values that cannot exist, such as a visit date in the future.
4. Word the message for the site. Say what is wrong and what to check: "Temperature is above 42.0 °C. Check the unit and the source record." Leave codes and data manager jargon out.
5. Build and test. For each check, enter a value that should pass and one that should fail. Record the result in your test log.
6. Version the checks. When the protocol changes, update the specification, rerun the affected tests and keep the previous version in the audit trail.

Mistakes that flood sites with queries

• Too many checks. A check on every field trains sites to click through warnings. Check what the analysis needs.
• Vague messages. "Invalid value" sends the coordinator hunting. Name the limit and the source to check.
• Blocking plausible values. A hard stop on a real but unusual result pushes the site to enter a false one.
• Checks added after go-live. Each late check raises queries on data the site entered weeks ago.

Edit checks in Datacapt

In Datacapt you set ranges and consistency rules on the field, and the form flags an out-of-range value as the site types it. When a value breaks a rule, the site sees your message and Datacapt raises a query on that data point. You choose how the message looks: information, warning or exclusion. None of the three blocks entry. Before a change reaches your sites, the build check shows what it would break. Derived fields such as BMI or scores come from an expression you write on the form.

Keep reading

• How to design a case report form (CRF)
• Three ways to improve data quality in clinical trials
• Every EDC feature in Datacapt