It is possible to make changes to the study forms after a study has been live, but the study status must be changed to "not live" before you can make adjustments to the study form.

It is important to remember that existing data may be affected by changing the study forms. To make sure that the changes you make will not affect existing data, please consider the following points:

Adding

1. Adding visits, forms, fields throughout the study can be done without concern. However, new fields may change the participant status and may affect signatures as described below:
   • Signed - Adding a field (required or optional) to a signed form will drop the signature for the form where the new field was added, with the following warning message before applying the change.
   • Locked - Adding a field (required or optional) to a locked form does not drop the lock. But for required fields, the status reverts to "in progress". Therefore, you must unlock the form in order to input data to the new field.
   • Signed and Locked - Adding an optional field to signed and locked form drops the signature, but the lock and participant status remain unchanged. On the other hand, adding a required field will drop the signature and revert the status "in progress" while leaving the form locked. Therefore, you must unlock the form in order to input data to the new field.
   • SDV - Adding a field can have the following implications on the form SDV, depending on the type of SDV applied and the type of field is added to the form. When a field is added to a form, the SDV (Source Data Verification) is removed from the form where the field is added, and the progress status of the form changes to "in progress".
2. Adding an option in an option group can be done without any consequences.
3. Adding a dependency works in the way that it shows the question if the condition is fulfilled. When the dependency is created, the fields where the condition is not fulfilled will be hidden. If the field value that triggers the dependency will be changed again, after the dependency has been added, the data might be deleted in case the setting 'Clear inapplicable child fields' is set to 'Yes'. To prevent the data loss, you would need to go to the Settings tab -> 'Other' -> In the 'Clear inapplicable child fields' select 'No' -> 'Save changes'.

Modifying

• Changing the text in a question (the field label) or the variable name can also be done.
• Changing the nameof any repeating data form, study or survey form, survey package or repeating data instance can be done safely. 
  • Automations using any of the study forms, repeating data, survey forms and survey packages that have their name altered will be automatically updated with the new name. The automation itself won't be affected by the changes and it will continue to work as it was set before. 
• Changing the name of sites/centers can be done without affecting existing data.
• Changing a validation message or message type can be done safely. 
• Changing validation conditions is also possible, but previously triggered validations will be removed if the previously defined conditions are no longer met.
• Modifying the configuration of the grid field leads to data loss, if the data has been collected for the grid field.
• Changing fields with dependencies could lead to data loss, so if you are changing a parent field, consider whether the dependent fields will be affected.
• Changing the field type is possible and limited only to the compatible field types to prevent data loss.
• Changing the name of the visits used in automations will have no effect on the automations, which are linked to visit/form and field IDs. The automations will continue working, even after changing the name of the form or visit, as well as any field labels.
• Moving a field to a different form is possible, even if the data contained for example signatures/queries (these will be moved along with the field).
• Changing the option group values will lead to data loss if data was already collected for the field using that option group.
• Replacing an option group can be done without any problems if the new option values correspond to the option values of the original option group. For example, if the original option groups contained options 'Yes' with the value 1, 'No' with the value 2, and 'Maybe' with the value 3 and it should be replaced with an option group 'A' with the value 1, 'B' with the value 2, and 'C' with the value 3, the data will be preserved, just the label will be changed.
• Replacing an option group where the new option values differ from the original option group values will lead to data loss.

Deleting

• Removing or adding lower and upper limits for numerical fields can be done without any concerns.
• Removing a visit, form or field will cause data loss if data has been collected for that variable. 
• Removing a survey from a survey package: If you remove a survey from a survey package that's already been sent out, then you will lose the data for that survey. Adding the survey back should restore the data.
• Deleting a field which is used for stratification will break the form and lead to errors when trying to open a participant.
• Deleting an automation to create queries will not have any consequences for the data and will not delete already created queries.
• Deleting an automation to hide a visit or form does not impact the data, but will make the visits and forms visible again. 
• Deleting an automation to create and send survey package will not lead to data loss, and will not delete the already scheduled survey invitations

We always recommend testing any potential changes in a test environment. Read the article on how to create a test environment here.

If you are not sure whether you can safely make a change, please contact the Castor Support team for advice at support@castoredc.com.