Summary

This article covers re-running edit checks.

Re-run edit checks screen allows a study builder to selectively run all conditional actions on specific forms or fields. This is helpful when new edit checks are added or existing ones are modified. It allows an Administrative user to centrally run the edit checks that are needed, without forcing all edit checks across the study as would normally be done through a version migration.

In a versioned study, version migration is still necessary. The function covered here makes version migrations much faster and allows the Study Administrator to selectively run only the conditional actions that are needed (i.e. New ones in the most recent version).

Re-run edit checks can be found within the form builder on the web by any user with form builder access:

Select which level to run edit checks (the Granularity). This could be all conditional actions on specific fields, forms, or entire visits. Anything more than that would be the entire subject, which can be done during version migration.

Validation Granularity Definitions

• All - Run validations for all fields in all forms in all visits.
• Form - Run validations for all fields in the selected forms for all visits.
• Visit - Run validations for all fields for the selected forms in the selected visits.
• Field - Run validations for selected fields in selected forms for all visits.

As an added specification, choose which records to run the checks on based on the visit date range. For example, if an edit check on a field was modified on the Demographics form, and they only need to be rerun for subjects that had their screening/demographics visit after January 15th, the date range can help with this. Otherwise, it can be left blank to simply rerun the checks on all records.

In the example below, a validation (edit check) was added on the Date field of the Physical Exam form because the site was entering future dates. The Study Manager would like to run that validation on existing data at the Clairemont site for records with dates between January and February.

Running this will cause the edit check fire system queries on that date field for any data that is a future date.

ALL conditional actions will be run for the field selected. Caution should be used when running checks on fields that also contain an email notification or computation. This would have the potential to send email notifications or update data on a computed field. It will also run the visit outside of window checks to compare the visit date to the scheduled visit window if the form is in a scheduled visit. Other types of conditional actions will not be run (hide, disable, populate).

Rerunning the validation will have the potential to create new queries on existing records. This can be verified through the Queries report. Some conditional actions will not apply because a form save is required by a user for other types of conditional actions to function.

Need more help?

Please visit the Datatrak Contact Information page.