REDCap operations for production changes are focused on supporting a project team making changes that affect what data is being collected in their project and/or how data is being collected in their project after their project has been moved to production and real data collection has started.

There are three mechanisms for making production changes that impact data collection:

1. Modifying existing data collection forms or surveys.
2. Adding new data collection forms or surveys.
3. Modifying how the project is set up for collecting data and/or sending out surveys and collecting responses.

How the REDCap Team and REDCap itself supports and facilitates the project builder/point person making these types of changes depends on how the project is set up and what kinds of forms or features are involved in the change(s). For instance, there are special guidelines for changes that involve e-consent. 

To understand how to move forward with making your changes, please first review the section on Change Considerations before you review the section(s) that applies to the types of changes you need to make.

Production Change Topics

Change Considerations

REDCap was created to put researchers in control of their work, end to end, from project creation to clean up and analysis of the data that's been collected. This applies to making production changes, as well, even when the REDCap Team's help is required to implement a modification. 

General Guidelines

A project team should both try to minimize making production changes and plan ahead for managing the changes they might need to make by developing a change management plan that outlines the roles, requirements, and responsibilities involved in making changes.

When a project is moved to production, the expectation is the project's data collection plan has been finalized. This means that how data will be collected in the project (i.e. the data collection workflow), and what data will be collected in the project (i.e. forms  and/or surveys), has been vetted, tested and validated to meet the requirements of the data collection plan.

Once a team has started collecting real data in their project, minimizing change is important for both the reliability and dependability of the data, and the reliability and dependability of the how the project is set up to meet the requirements of the data management plan. 

A project's tolerance for change depends on several factors, specifically, the team's change management practices, the complexity of the project's setup, and the kinds of changes being implemented. Although it's largely the responsibility of the project team to determine if their change activities jeopardize the dependability and reliability of the data and/or the set up of the project, there are warning signs  REDCap Team takes note of that indicate project stability could become an issue, and these typically involve extensive, recurrent, and/or high impact production changes. Additionally, there are charges ($) for these types of changes. See the call out box on the right for more details.

As an example, adding Data Access Groups (DAG's) to a production project is considered high impact, particularly for projects utilizing surveys or alerts & notifications, because of the added complexity those features introduce. However, potential roadblocks for adding DAG's would include projects utilizing e-consent or REDCap's randomization feature, because of the foundational effect on the pre-existing data collection plan.

Project Team Responsibilities, Requirements & Recommendations

The personnel managing production changes will need to have a good understanding of how REDCap works, a firm grasp on how their project is set up, and a clear picture of how institutional governance for data collection and data storage impacts their project.

The project team is responsible for managing production changes. This means the builder/point person will need to conceptualize the changes they need to make, understand what activities will be involved in making the changes, validate that their changes were implemented correctly, and evaluate that the outcome of the changes had the intended effect.

Regulatory & Security Related Responsibilities

• For research projects, the study team is responsible for ensuring that their changes are within the scope of the data collection plan they described in their protocol, and consulting with the IRB to determine if additional regulatory approval is needed before the changes can be implemented.
• For non-research projects, the project team is responsible for ensuring their changes are within the scope of the data collection plan described in their RFD (request for determination from the IRB) and/or agreed to as a condition for using REDCap, and reviewing OHSU's Information Security Policies and Information Privacy Policies to determine if there are any compliance issues that need to addressed before their changes can be implemented.

User Related Requirements

• The project user making changes should be the point person for the project.
• The project user making changes should have completed Basics training, and for survey projects, should have also completed completed Survey training.
• The project user making changes will need Project Design and Setup user permissions.
• The project user making changes will need an in-depth understanding of how the project is set-up to collect data and manage the data collection workflow.

Change Management Recommendations

• Apply the principle of least privilege to assigning User Rights to limit which users can make changes.
• Maintain a change log, outside of REDCap, to record the details of the changes that were made to the project.
• Routinize change activity by setting aside regular time on a monthly or quarterly basis to review with your team any issues with the project or changes to requirements that will necessitate making modifications to your project.

REDCap Functionality: What kinds of production changes does REDCap allow?

Many aspects of how a project is set up to collect data are locked down or restricted when the project is moved to production, and a  review process is imposed on modifications to forms and surveys. The REDCap software was designed this way as a guardrail to try to prevent users from making changes to their project that would have a detrimental impact by creating a data loss or data corruption issue, invalidating functionality critical for data collection, and/or causing components of peripheral features the project team relies on for managing data collection to fail. 

OHSU's REDCap is configured so that 1) only a REDCap administrator can make changes to the main project settings, event configurations, and almost all of the optional modules, and 2) when a user a user submits form or survey changes with critical issues that could result in data loss or data corruption, the changes are routed a REDCap Administrator for review and approval.

Help & Support: How is the REDCap Team involved in production changes?

In general, the REDCap Team's role regarding production changes is to act as as a guardrail and/or a sounding board for the project builder/point person making the changes. This is similar to the REDCap Team's role with regard to project building, and consistent with how the REDCap Team supports personnel to build and manage their own projects.

In practice, this means the builder/point person conceptualizes the changes they need to make, evaluates the effect of the changes on the both the data that's already been collected and the setup of the project, plans for how the changes will get implemented, and assesses the outcome of the change activity. The REDCap Team addresses gaps as they arise, which typically involves either directing the builder/point person to learning resources and answering their follow up questions, and/or performing oversight activities required by the system, such as reviewing form changes with critical issues or working with the project builder to implement changes to the setup of their project.

Recurrent, extensive, high impact, and support-intensive production changes require additional help for which there are charges ($). This also applies to adding a new e-consent form to a project in production. Review the call out box on the right, When Charges Apply ($), for more information about these types of changes.

Change Risk Assessments 

For project setup changes, and some changes to survey tools, like Automated Survey Invitations or the Survey Queue, the REDCap Team also conducts a change risk assessment, with the goals of 1) trying to understand the potential for the changes proposed by the builder/point person to have a negative impact on the data or the ability to collect data in their project, and 2) to make a pre-determination if additional help, above and beyond basic drop-in and email support, is needed to effectively test or implement the changes or evaluate their outcome. The assessment not only takes into consideration details about the changes and the big picture of how the project is set up to collect data, but also what the REDCap Team knows about the both the rate and type changes that have already been implemented in the project, and the building skills and experience of the builder/point person. See the callout box on the right, Change Risk Categories, for additional details.

Design Consultations

These are strategy sessions, where the REDCap Team works with the project builder/point person, and sometimes other project stakeholders, to plan for the changes the team wants or needs to make to their project. Design consultations can be particularly helpful when a team feels stuck knowing they need to make changes to their project, because their protocol has changed or their funder has new requirements, but unsure what a design solution looks like in terms of making modifications to their project. Or when the scope, complexity and risk of the changes is significant in terms of data loss, data quality, and/or project functionality, and/or represents a significant departure from the tested and vetted set up of the project and cannot be accommodated in production production. There are charges ($) for design consultations. Contact the REDCap Team for more information.

Test Projects

The best practice for testing many kinds of production changes is for the project builder/point person to first test their changes in an up-to-date copy of their production project. Testing changes in a test copy of the project is required for making changes to the main project settings, event configurations and optional modules. In the sections below, we call out when test projects are required, optional or recommended, depending on the types of changes the project builder/point person is planning to make. Test projects are not available for projects in the Self-Service support track.

Test Project Details

The test project, itself, is a is snapshot of the production project at a particular time point (i.e. the date and time the test project gets created). The test project can get out of sync with the production project, if, after the test project is created, there continues to be change activity* in the production project. Even when the changes don't involve how the production project is set up to collect data, making changes to components of peripheral functionality designed to help manage data collection, such as creating new reports or data quality rules, can undermine the builder/point person's efforts to use the test project to assess the impact of their changes. This is why it's highly recommended that the project team self-impose a change freeze** period in the production project while the builder/point person is testing their changes in the test project. This is also the main reason why we enforce a limited lifespan of 60 days on test projects - to promote change management practices that lead to meaningful testing.

Contact the REDCap Team

Before making a copy of the your project for testing, please first please first email the REDCap Team and include in your email: 1) the exact title of your project, and 2) detailed description of the kinds of changes you are planning on testing.

We need to review your plans and look at your project to determine the level of effort and support that will be needed from the REDCap Team, if charges ($) will be involved, and if there are any barriers to making the changes you've proposed, as well as provide you with some instructions for creating a test project specific to the kinds of changes you plan on testing.

_{*Change activity refers to making changes to forms, surveys, project settings, and components of peripheral functionality, such as reports, data quality rules, project dashboards, etc.. Change activity DOES NOT refer to adding or editing records or sending out surveys and collecting responses.}

_{**Change freeze DOES NOT apply to adding or editing records or sending out surveys and collecting responses.}

Modifying Existing Forms or Surveys

REDCap Functionality

REDCap allows users to make changes to existing forms or surveys. The process for making these types of changes is well documented in Making Production Changes section of the REDCap FAQ, and is also demonstrated in the video linked to the in the call out box at the top of the page. In short, the project builder/point person enters Draft Mode, which does not take the project offline, and makes their changes, but the changes are not made in real time. The changes are held in draft, and the builder/point person can view a detailed summary of their changes before they submit them for review. 

• Form or survey changes that don't include critical issues will be automatically approved. 
• Form or survey changes with critical issues that could result in data loss or data corruption are held up for a REDCap Administrator to review and approve.
• Learning how to determine if your changes will be automatically approved or held up for review is covered in our video. Making Production Changes

For information about making modifications to survey settings, skip to the section on Modifying Anything about Automated Survey Invitations, the Survey Queue, or Survey Settings.

Help & Support

When a project builder/point person submits any changes with a critical issue that could result in data loss or data corruption, the REDCap Team will assess the impact of the changes and follow up with builder/point person about how to modify the changes to eliminate the issue(s), or to how to move forward, confirming that the data loss or data corruption is acceptable.

Other than that, the REDCap Team is not involved in form or survey changes unless: 1) the builder/point person has follow up questions after reviewing the video and guidance on this page, and the tips covered in the FAQ in REDCap, or 2) the builder/point person is seeking feedback on a specific change that they have already conceived of and for which they've already made an initial determination about the impact.

It is the responsibility of the builder/point person to evaluate the impact of their form or survey changes on: 1) the data that's already been collected, 2) the data collection workflow and the functionality that facilitates it, and 3) the components of peripheral features the project team relies on for managing data collection, as well as deciding if they want to first test their changes in a test copy of their project before implementing their changes in production. 

Change Tips & Best Practices

• Critical Issues that Will Result in Data Loss or Data Corruption

  • Relabeling a radio button, drop-down or checkbox option.
  • Changing a field type
  • Deleting a variable
  • Re-naming a variable.

• Tips for Mitigating Critical Issues

  • To sunset, archive or deprecate fields or field options that are no longer in use, use the action tag @HIDDEN for a field and @HIDECHOICE for an option.
  • For changes to radio button, drop-down and checkbox options, do not relabel existing options or assign new raw values to existing options. Raw values do not determine the ordering of the options. New options should have new raw values.
  • Changing the field type of an existing field for which data has already been captured most often results in data loss or data corruption, and invalidates functionality that references the field that critical for data collection, and/or causing components of peripheral features that references the fields and the project team relies on for managing data collection to fail. Instead of changing the field type, archive or deprecate the existing field, using the approach described above in the first bullet item, and add a new field with the desired field type.
  • Variable names cannot be changed. Changing the name of a variable is not allowed through the Online Designer. Changing the name of a variable through the Data Dictionary, will be interpreted by REDCap as deleting the existing field with the old variable name and adding a new field with the new variable name.

Adding New Forms

REDCap Functionality

REDCap allows users to create new forms via the same mechanisms employed for making form modifications, which is well documented in Making Production Changes section of the REDCap FAQ, and is also demonstrated in the video linked to the in the call out box at the top of the page. In short, the project builder/point person enters Draft Mode, which does not take the project offline, and makes their changes to add a new form, but the changes for the new form are not made in real time. The changes and the new form are held in draft, and the builder/point person can view a detailed summary of their changes before they submit them for review.

• A new form that doesn't include critical issues will be automatically approved. 
• A new form with critical issues that could result in data loss or data corruption are held up for a REDCap Administrator to review and approve.
• If the new form needs to be added to event or enabled as repeatable see details in the Help & Support section below.
• Learning how determine if your changes will be automatically approved or held up for review the is covered in our video. Making Production Changes.

Help & Support

When a project builder/point person submits a form with a critical issue that could result in data loss or data corruption, the REDCap Team will assess the impact of the changes and follow up with builder/point person about how to modify the changes to eliminate the issue(s), or to how to move forward, confirming that the data loss or data corruption is acceptable.

If the project is set up for longitudinal data collection and the new form needs to be added to an event, skip to the section below, Adding New Forms or Surveys to or Modifying Anything about Events. Only a REDCap administrator can add a form to an event and the project builder/point person will first need to test the new form in a test copy of the project.

If the new form needs to be enabled as a repeating instrument, this setting can only be enabled by a REDCap administrator and the project builder/point person will first need to test the new form in a test copy of the project, per the instructions outlined in the call out box on the right, under When Test Project Required.

Outside of these activities, the REDCap Team is not involved in adding new forms unless:

• The builder/point person has follow up questions after reviewing the video and guidance on this page for making production changes, and the tips covered in the FAQ in REDCap
• The builder/point person is seeking feedback on a specific component of the form for which they've already made an initial determination about the impact, 3) the builder/point person is adding a form that they will enable as survey (see the section below on Adding New Surveys), or 4) the builder/point person is adding a new e-consent (see the call out box above, When Charges Apply ($)).

It is the responsibility of the builder/point person to evaluate the impact of their new form on: 1) the data that's already been collected, 2) the data collection workflow and the functionality that facilitates it, and 3) the components of peripheral features the project team relies on for managing data collection. If a test project is not required, it's also the builder/point person's responsibility to decide if they want to first test their changes in a test copy of their project before implementing their changes in in production. 

Change Tips & Best Practices

• If the new form only contains new fields it should be automatically approved.
• Moving an existing field to the new form and making modifications to the existing field could create critical issues and invalidate existing form functionality. For more details review the Change Tips & Best Practices in the section above, titled Modifying Forms or Surveys.
• It will create a data loss to move an existing field to a new form that needs to be added to a different event than the event that the form that originally contained the field is assigned.

Adding New Surveys (to a project with survey functionality enabled)

The guidance in this section only applies to projects that already have the Main Project Setting enabled for Using surveys and are currently sending out surveys and collecting responses. To enable a project to use survey functionality after it was moved to production, skip to the section Modifying or Enabling/Disabling Main Project Settings, Optional or External Modules, or Customizations.

The guidance in this section does not apply to adding a new e-consent survey to a project that's already in production.

REDCap Functionality

In REDCap, a survey is a data collection form that has survey functionality added to it. This means that the process, described above, for adding a new form applies to adding a new survey.

Help & Support

The help and support activities for adding a new form, described above, apply to adding a new survey. Plus, the REDCap Team provides additional drop-in support to 1) review with the builder/point person how the new survey is set up and how the participant will access it, and 2) conduct a pre-production review, which is required. This is similar to the REDCap Team's role with regard to project building, and consistent with how the REDCap Team supports personnel to build and manage their own survey projects.

It is the responsibility of the builder/point person to evaluate the impact of their new survey on: 1) the data that's already been collected, 2) the data collection workflow, including how the project is set up to send out surveys and collect responses, 3) the existing functionality that was tested and vetted during the development phase that impacts or is related to sending out surveys and collecting responses, and 4) the components of peripheral features the project team relies on for managing sending out surveys and collecting responses.

Change Tips & Best Practices

• Start by reviewing the Change Tips & Best Practices, listed above, for adding a new form.
• Next, determine if how your participants will access the new survey involve or require any of the following:
  • Adding a new invitation;
  • Adding a new connection that has conditions;
  • Both existing participants and new participants to complete it.
• If any of above listed items are true, make sure to first create test records in the test project, completing any existing surveys that may impact how the new survey will be distributed.
• Expect extra effort if you are adding a new distribution method that was never set up and tested when the project was in development.

Event Changes: Adding New Forms or Surveys to an Event OR Adding New or Modifying Existing Events ^{(requires REDCap Admin for implementation)}

Only applies to projects with longitudinal setup.

The guidance in this section only applies to projects that already have the Main Project Setting enabled for Using longitudinal data collection with defined events and are collecting data in forms or surveys assigned to events. To enable a project to use longitudinal data collection functionality after it was moved to production, skip to the section Modifying or Enabling/Disabling Main Project Settings, Optional or External Modules, or Customizations.

REDCap Functionality

OHSU's REDCap is configured so that only a REDCap administrator can make changes to event configurations. This means only a REDCap administrator can make changes that involve the following kinds of activities:

• Adding a new event.
• Adding new or existing forms or surveys to new events, which is referred to as adding new form to event assignments
• Adding new or existing forms or surveys to existing events, which is referred to as editing existing form to event assignments.
• Changing the event order.
• Enabling an event to be repeatable.
• Renaming an event.
• Removing an event.

Help & Support

When a project builder/point person requests any changes to the configuration of events in their project, the REDCap Team will first conduct a change risk assessment to 1) identify any potential barriers to making the event changes, 2) uncover the potential of the event changes to have a negative impact on data that's already been collected or the project's existing setup, and 3) make a pre-determination about the kind of help that will be needed to both test the event changes in a test copy of the project and then implement the changes in the production project. Read more about change risk assessments in section above that covers general considerations for help and support.

The REDCap Team will notify the project builder/point person, via email, the outcome of the risk assessment. If there are no barriers to making the changes, and if additional help is not required, the email will also include instructions for creating a test project, some general guidance about testing, and a reminder to sign up for a drop-in for help with implementation.

Adding New or Modifying Anything about Automated Survey Invitations, the Survey Queue, or Survey Settings

The guidance in this section only applies to projects that already have the Main Project Setting enabled for Using surveys and are currently sending out surveys and collecting responses. To enable a project to use survey functionality after it was moved to production, skip to the section Modifying or Enabling/Disabling Main Project Settings, Optional or External Modules, or Customizations.

REDCap Functionality

REDCap allows a user who has permissions enabled for both Project Design and Setup user rights and Survey Distribution user rights to  add new configurations or make modifications to existing configurations related to Automated Survey Invitations (ASIs), the Survey Queue or a form's existing Survey Settings without oversight. This means that these features are not locked down in such a way that only a REDCap administrator can make changes to them, and users are not forced to enter Draft mode to make changes and submit them for approval (which is the process REDCap imposes on users when making changes to the fields that make up the content of a form or a survey). 

Help & Support

The REDCap Team provides drop-in and email support to help the project builder/point person mitigate the risk, which is elevated, of something going very wrong when making changes related to ASIs, the Queue or Survey Settings, as illustrated in the scenarios below.

• A user makes a change that causes a feature to fail in such a way that participants will not be able to complete their surveys.
  • For example, a user modifies the Queue logic so a batch of surveys are no longer connected to each other, and after a participant completes the first survey in the batch, they cannot access any of the other surveys.
• A user makes a change to a feature that creates a regulatory issue that has to be reported.
  • For example, a user adds a new ASI that sends survey invitations to participants who did not consent.
• A user makes a change to a feature that results in a HIPAA violation.
  • For example, a user changes the Survey Settings to enable Save and Return without a code on a survey that captures PHI, allowing anyone with access to the survey link to return to the survey and view all the information the participant already entered.

It is highly recommended the builder first test their changes related to ASI's, the Queue or a form's Settings in a test copy of their project, especially given the risk of making these types of changes. The REDCap Team will also conduct a change risk assessment, when the builder/point person contacts the team to request the test project.

It's very possible that additional help will be needed for making these types of changes, for which there will be charges ($), because it takes careful consideration, and often technical expertise, to understand and account for the implications of these types of changes, which will be different for existing participants versus new participants.

Enabling/Disabling Main Project Settings or Optional Modules ^{(requires REDCap Admin for implementation)}

REDCap Functionality

Most of the features that are foundational to how a project is set up to collect and store data, and that are grouped together in the Project Setup tab, are locked down when the project is moved to production. This means only a REDCap administrator can enable or disable the following features:

• Main Project Settings
  • Using longitudinal data collection with defined events
  • Using surveys
• Optional Modules
  • Repeating forms or events

  • Auto-numbering for records

  • Scheduling module
  • Randomization module
  • Twilio SMS and Voice Call services for surveys and alerts
  • Clinical Data Pull from OHSU Epic
  • Dynamic Data Pull (DDP) from Research Data Warehouse

The system imposes restrictions on making changes related to the Randomization module, and not even a REDCap Administrator can make modifications to the setup of the Randomization module or the allocation file, except for uploading additional allocations.

Deleting Fields, Forms, Events or Disabling a Main Project Setting or Optional Module

REDCap is configured so that action by a REDCap administrator is required for modifications related to deleting fields, forms, or events, or disabling a main project setting or optional module.

These types of changes almost always involve either data loss and/or cause data collection functionality to fail. For any changes that involve a data loss, there would be charges ($) for the REDCap Team's help in retrieving or re-creating the lost data.

Deleting Fields or Forms

• The system treats deleting a field or a form as a field or form modification. For more details, review the section above for Modifying Existing Forms or Surveys. 
• Deleting a field or a form for which data has already been capture creates a critical issue that will result in data loss.
• As part of the approval process for these types of changes, the REDCap Team sends an email notification to the project builder/point with instructions regarding how to acknowledge the data loss.

Deleting Events ^{(requires REDCap Admin for implementation)}

• The system locks down project settings so that only a REDCap administrator can delete an event, and the REDCap Team treats deleting an event as modification to event configurations. For more details, review the section above for Modifying Anything about Events (only applies to projects with longitudinal setup).
• Deleting an event for which data has already been captured would orphan off that data and create a data loss, and risk invalidating functionality critical for data collection activities.
• As part of the approval process for this type of change, the REDCap Team sends an email notification to the project builder/point with instructions regarding how to acknowledge the data loss.

Disabling a Main Project Setting or Optional Module ^{(requires REDCap Admin for implementation)}

• The system locks down project settings so that only a REDCap administrator can disable a main project setting or an optional module.
• As noted in the section above, Enabling/Disabling Main Project Settings or Optional Modules, the ramifications of disabling or deactivating a main setting or optional module are typically far reaching and/or profound, and the REDCap Team, as a rule does not typically support these types of changes.
• In the rare situations where a project and the project team can accomodate these types of changes, the REDCap Team will need to obtain permission from the PI, for research projects, or the Data Steward.

Ultimately, it is the responsibility of the builder/point person to evaluate the impact of their changes that are related to deleting fields, forms, events or disabling a main project setting or optional module on: 1) the data that's already been collected, 2) the data collection workflow and the functionality that facilitates it, and 3) the components of peripheral features the project team relies on for managing data collection.

Revising an E-Consent Survey/Form (applies to Information Sheet)

General Guidance

Any changes to an e-consent survey/form, even updating approval and expiration dates, require special consideration and management to remain in compliance with IRB guidelines.

OCTRI worked closely with the OHSU's IRB to develop guidance for using REDCap for e-consent, including the approach to making revisions to the e-consent survey/form so that new participants will be presented with the new version of the e-consent survey/form, and the previous version of the e-consent survey/form completed by existing participants will be preserved.

When Charges Apply ($)

The following changes related to e-consent require additional help from the REDCap Team, which we refer to as custom support, and for which there are charges ($).

• Adding an e-consent survey/form to a project in production that was not initially set up for e-consent.
• Adding a new e-consent survey/form, typically for the purpose of re-consenting, to a project in production that is already using e-consent.
• Providing coaching or instruction to the builder point/person to make revisions to an existing e-consent form.
• Intervention is required to address e-consent revisions that have invalidated existing e-consent forms submitted by enrolled participants or would prevent new participants from submitting a valid e-consent form.

REDCap Functionality

The functionality involved in making revisions to an e-consent survey/form is the same as the functionality used to modify any form or survey. For more details, review the section above for Modifying Existing Forms or Surveys.

What makes e-consent revisions different is applying the versioning technique described in the instructions for making revisions to an e-consent survey/form so that new participants will be presented with the new version of the e-consent survey/form, and the previous version of the e-consent survey/form completed by existing participants will be preserved. However, the system does not force the builder to apply the versioning technique. It is the responsibility of the builder/point to know that versioning is required and to understand how to implement it.

Also, because e-consent revisions mostly involve making changes to descriptive text fields, and the system does not impose oversight, via an approval process, for modifications to these types of fields, the REDCap Team will not be alerted some kinds of changes that could create critical issues related to either preserving the previous versions of e-consent survey/forms existing participants have submitted, or presenting new participants with a new versions of valid e-consent survey/form. 

Watch the video linked to in the call out box above, for a demonstration of how to make the revisions and apply the versioning technique.

Help & Support