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. An example is shown below.
This simple example shows the checking of a numeric range on a number field.
When making checks on partial dates, the system will assume 01 for a blank day, January for a blank month, and 0001 for a blank year.
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.
For example:
Form B has a date field in a normalized table that checks to make sure the date is not prior to the 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 the 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 validations 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 been fired on the form. This is because ePRO forms in error remain in the participant's 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.
Re-Running Edit Checks
Sometimes it is necessary to force the system to run edit checks on targeted fields or forms. For example, if a field is now being required that wasn't before and the study Manager wants the system to query any fields that have the data missing. Read more here about how to run targeted edit checks.