REDCap: Making Changes in Production
|Changing Labels||Deleting Fields||Adding Fields||Option List Changes||Changing Field Type|
When making changes to a project that is in Production via Draft Mode, there are some changes that will need to be reviewed and committed by a REDCap administrator. This is done to help ensure your data is not adversely affected by the changes you're making. These changes may include deleting data, changing the meaning of the data and not marking fields as identifiers. If a REDCap administrator believes your changes could affect your data adversely, they will contact you to confirm the changes before committing them.
Please use the 'View detailed summary of all drafted changes' link found within the Draft Mode screen to view the changes you are making to your project PRIOR to submitting your changes for review. Any changes noted in RED should be carefully reviewed.
Each field you create has a field label and a unique variable name. You will not be able to change a variable name once your project is in Production. You will be able to change a field label, but doing so could result in changing the meaning/intention of the data for that field.
In this example, the label was updated from 'days' to 'weeks'. This can be problematic since any data initially entered for days now means something completely different. Additionally, since you will not be able to update the variable name it will continue to indicate 'days' and this may cause confusion when exporting your data.
If your field contains data, you may want to instead create an entirely new field to capture the new data and then use the @HIDDEN action tag to hide the field you will no longer be using. This allows the field and data to remain in your project for reports & exports, but you will no longer see it on data entry pages.
If your field does not contain data and the variable name still makes sense, changing the field label can be acceptable.
When a field is no longer needed within your project, you have the option to delete that field. However, when data has already been entered into that field deleting it would result in data loss. The only way to retrieve it is to review the project logs and re-enter the data.
In this example, the field 'First Name' has been deleted. In reviewing the summary of all drafted changes, you can see that this will affect 6 records.
If your field contains data, you may want to instead use the @HIDDEN action tag to hide the field you will no longer be using. This allows the field and data to remain in your project for reports & exports, but you will no longer see it on data entry pages.
- To 'undo' the field deletion, you will need to re-create that field. Your project codebook (found under the Project Home and Design section) will list all fields in your project - including the one you had planned to delete. You can re-enter a new field and use the same variable name you previously had.
- The other option is to use the 'Remove all drafted changes' link found in the online designer - draft mode area (yellow section). This will remove ALL planned changes. There is no way to accept some changes, but not others.
If your field does not contain data, deleting the field can be acceptable.
Adding New Fields
In most cases, adding a new field will not require approval from a REDCap administrator. However, any field that the REDCap system believes could be an identifier will require REDCap administrator review before committing the change. For a refresher on what could be considered an identifier, visit our KB page: https://kb.wisc.edu/ictr/95449
To view potential identifiers in your project, there is a link within the Project Setup > Design your data collection instruments & enable your surveys sections.
Option List Changes
There are several changes that can be made to an option list (radio or checkbox fields), but changing a coded value or renaming an option can lead to data loss or data integrity issues.
Users can assign each option in a list a unique coded value (number or letter), similar to a variable name for the overall field. However, REDCap does allow users to change that coded value which can lead to data issues. When a coded value is changed, any previous data that selected that option is no longer correct.
In this example, the options have been changed so that they would appear alphabetical with "Other" as the last option. In doing this, several records would be adversely affected.
- 'Vanilla' (1) selections would now mean 'Chocolate' (1) & 'Chocolate' (2) selections would become 'Cookie Dough' (2), etc. since the coded value has changed.
- 'Mint' (3) & 'Other' (5) selections would be deleted.
The options will be listed in the order that they appear when building the field. The number or letter of the coded value doesn't affect the order. To change the order of an option list, just move the label AND option code to a new position. You can also add new options wherever you'd like - just assign it a new coded value. To remove an option that you no longer need, we recommend using the action tag @HIDECHOICE.
Changing Field Type
Changing a field type that already has data in it can be problematic. Some field types require data to be collected in a specific way - like an option list retains the coded value of an option (not the label), and a text field captures anything that is entered. It is recommended that field types only be changed in no data has been entered into them.
= Changes should not affect data = Changes will affect data = Change may affect data
|Checkboxes||Yes - No||True - False|
|Initial Field Type||Text|
(Radio or Dropdown)
|Yes - No
(coded 1, 0)
|True - False
(coded 1, 0)