Validating Data Entered on a Form
The Conditional Action type “Validation” or "Edit Check" allows users to validate a field’s value based on data entered or system-known variables. Edit checks will cause an automatic query to be generated when the defined condition(s) are met.
When the validation is triggered during data entry, a query is generated with the pre-defined “error message” on the form. Here's an example:
This simple example shows the checking of a numeric range on a number field.
Cross-form Edit Checks
If an edit check references a field on another form in order to validate the data, changing the data on that other form will run the edit check at the target when the user is not active on the form.
Form B has a date field in a normalized table that checks to make sure the date is not prior to date on Form A. If the user has already entered both forms A and B to evaluate the edit check as false, but then goes and updates Form A date field to be after the date entered in Form B, a query will automatically open in Form B’s normalized table row even though the user did not have that form open.
Validation Using the Min/Max Property
This field property is only available on Number fields, as a quick alternative to writing a custom edit check. The advantage a custom edit check has is the ability to define the error message.
The Min and Max fields represent the acceptable range of values that can be entered into a field. For example, if the Min is set at 50 the field will display an error message stating, “Value violates low range (50)” when the value entered is less than 50.
If the field is enabled and required based on another field’s answer or multiple validation conditional actions based on different range values, manual edit checks will need to be written for each of those messages.
If an acceptable value range is set and the field is required, the edit check will always fire when the field is left blank. If this behavior is not desired, write a manual edit check instead to include a condition for "Not blank".
Override Query Deployment
A unique function with Validations is the ability to override default query distribution. By default, queries are deployed to specific roles as defined in the study configuration. However, each validation can be designed so when the edit check is triggered (e.g. a number is out of range), the resulting query is deployed to a more limited set of users than what might be normal.
In the example below, a validation (edit check) is set up on a field to only send a query to the Data Manager if the validation is triggered. This will override the normal query distribution which might be normally set to go to all roles in the study.
If the form is an ePRO form, query override rules are ignored. Participant users will see any edit checks that have fired on the form. This is because ePRO forms in error remain in the participants action items until the form is completed, so the errors must be visible to the user.
An alternative to firing an edit check on ePRO forms would be to send an email notification for data that other parties need to act upon.