Edit checks
Edit checks are automatic data-quality control right at the moment of entry. They catch missing required fields, out-of-range values and logical inconsistencies between fields and forms. Checks are part of the design version: they are created and edited in the Edit checks block of the Logic tab of the CRF Builder (and when a design is moved between systems they travel with the JSON import). A rule belongs to the open form and is edited in place — a ready check can be changed without deleting and re-creating it.
Rules come from two origins: system (the system creates them itself from field properties) and cross-field / cross-form (you write them).
System checks
Section titled “System checks”The platform generates system checks automatically from what you have already set in the field properties:
- a field is marked Required → a “the field must not be empty” check;
- a numeric field has a range (Min / Max) → a “the value must fall within the range” check.
These checks are not written by hand — the platform derives them from the field properties. On the Logic tab they are gathered in a separate “From field properties” block — read-only: you cannot delete or change such a check here. To change it, adjust the field property itself in the builder’s inspector (clear “Required” or change the range), and the check changes with it.
Cross-field and cross-form rules
Section titled “Cross-field and cross-form rules”These are rules that cannot be derived from a single field: “if A, then B is required”, “the end date is not earlier than the start date”, “pulse below 40 with the reason field empty”. Such rules are created with the Add check button in the Edit checks block of the Logic tab. The rule belongs to the open form (field names are resolved relative to it — there is no separate form to pick), and the builder assigns the stable OID itself. The editor sets:
- condition — at what value the check fires; true — the check has fired;
- message — the text the coordinator will see when the check fires;
- severity — “Info”, “Warning” or “Error”;
- action on firing — Open a query (
query) or Block the save (block) — see the next section.
The condition is assembled visually — as “field — operator — value” rows joined by an AND / OR
connective. For date fields the operators read as words: is before · is not after · is after · is
not before. The right-hand side can be compared not only with a constant but also with another
field of the form (number with number, date with date) — so “the end date is not before the
start date” is built with the mouse, without formulas. Whatever the visual builder cannot express
(arithmetic, ref() to other forms, parentheses) is set with a formula in advanced mode in the
expression language. The core functions:
is_empty(...)— the field is empty;num(...)— the numeric value of a field;days_between(...)— the number of days between two dates;round(..., n)— rounding tondigits;ref('FORM', 'FIELD')— a reference to a field of another form; the formref('VISIT', 'FORM', 'FIELD')additionally pins the visit — this is how cross-form checks are made.
Fields of the anchor form are addressed in the expression directly by their OID. An example expression:
num(HR) < 40 and is_empty(ref('F.DM', 'SEX'))The full language reference — comparisons, arithmetic, and how “true” in a check differs from “true” in a display condition — is in Skip logic & derivations.
Two behaviors: block and query
Section titled “Two behaviors: block and query”When a rule fires during data entry, it behaves in one of two ways. This is a fundamental fork, and it must be chosen deliberately.
| Type | What happens on entry | When to use |
|---|---|---|
| block (stop) | The value is not saved, the field is highlighted, the rule message is shown | Only for values that are impossible by definition: a date in the future, a value outside the physically possible range |
| query | The value is saved, but the system automatically opens a query on that field | For anything debatable: a suspicious but possible value that needs clarification from the site |
The platform’s philosophy: block stops only what cannot be true. Everything else is a query.
Data from the source is more important than immediate “cleanliness” of the screen: if a value is
strange but in principle possible, it should be accepted and a managed query opened, rather than
forcing the coordinator to “bend” the entry to fit the rule.
Checking against data
Section titled “Checking against data”The fastest way to make sure a rule catches what it should is to live the form in the preview: enter values, the checks that fire are listed right under the form, and nothing is saved.
Beyond that, rules can be evaluated against a real subject’s data — for example, to assess an amendment’s new rule on already-collected data. Such a trial run only reports how many rules and which fields would fire — it opens no queries and changes no data.
What happens during data entry
Section titled “What happens during data entry”Once the study is under way, the rules run on every value save:
- a block rule prevents the value from being saved — the field is highlighted, a message is shown;
- a query rule saves the value and opens an auto-query — it appears in the query panel immediately.
This builds quality control into the entry flow rather than deferring it to the cleaning stage.