Page tree
Skip to end of metadata
Go to start of metadata

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

Intended Audience & Prerequisites

Intended Audience

  • Project builder/project point persons

Prerequisite Knowledge & Experience

  • Basics training

  • Survey training for survey projects

  • Expert knowledge of your project's setup



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

(lightbulb) 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.

Project Team Responsibilities, Requirements & Recommendations

(lightbulb) 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 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.

When Charges Apply ($)

Recurrent, extensive, high impact, and support-intensive production changes require additional help, which we refer to as custom support, for which there are charges.

Charges for additional help also applies to adding a new e-consent survey/form to a project in production and if custom support is needed for making revisions to an existing e-consent survey/form.


Recurrent Changes

Recurrent changes refer to a high rate of change activity, which we define as follows:

  • Submitting several or more form changes that require review over the course of single day or multiple days in close range.

  • Requesting several or more changes to project settings over the course of a single month or multiple months in a row.


Extensive Changes

Extensive changes involve modifications to multiple features related to project settings or survey functionality, such as adding new forms to an event, changing the order of events, enabling some forms to be repeating, and adding a new Automated Survey Invitation.


High Impact Changes

High impact changes involve implementing modifications to foundational project settings or other functionality that are integral to data collection. Examples include:

  • Enabling survey functionality
  • Enabling longitudinal data collection
  • Changing form/event assignments 
  • Changing event names 
  • Enabling Twilio
  • Setting up DAGs

Support-Intensive Changes

Support-intensive changes involve additional effort, via coaching, instruction, analysis, testing, and/or hands-on problem solving to help the builder/point person conceptualize the changes they need to make, assess the impact of their changes, and/or validate that changes were implemented correctly and had their intended result. 


E-Consent Changes

E-Consent changes, for which there are charges, involve the following activities:

  • Adding an e-consent form to a production project that was not initially set up for e-consent.
  • Adding a new e-consent 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 have failed to preserve existing e-consent forms submitted by enrolled participants or would prevent new participants from submitting a valid e-consent form.



Change Risk Categories

A change risk assessment is conducted to understand and/or uncover potential issues in relation to the following risk categories.


Changes could create a critical issue that result in a data quality or data loss issue, OR cause essential components of data collection functionality to fail.


The complexity and/or scope of the changes OR the complexity and/or scope of the project require expert technical knowledge about how REDCap works to effectively test or evaluate the changes or  requires additional help to implement the changes.


The changes, as proposed, cannot be implemented and additional help is needed to strategize on alternative solutions.



Test Project Operations

  • A test project is a sandbox that a project builder/point person creates to test the changes they want to make to their production project.
  • Test projects have a 60 day lifespan.
  • Real records are not copied into a test project.
  • Project users, other than the requestor, are not copied into a test project.
  • Contact the REDCap Team, before making a copy of your project to use for testing.

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.

Test Project Optional

Although first testing your form or survey modifications in a test project is not required, it is often the most effective way to determine the impact of your changes and to validate that your changes will have their intended effect, in which case the builder/point will also need to plan on creating some real records as test records, before making any changes in the test project. Testing first is especially a good idea for making changes that involve using advanced features, such as piping, action tags, field embedding, smart variables, or special functions, as well as using REDCap syntax to create compound logic statements for piping,  branching logic or calculated fields.

Read more information about test projects.

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe, in detail, the form or survey changes you plan on testing.

  • The REDCap Team will email you with instructions and guidance specific to creating a test project for testing form or survey changes.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • You are responsible for implementing the changes in your production project.
  • The test project will be expired on or about 60 days after it was created.
  • 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 result in data loss or data corruption. 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.
  • Other Tips

    • Applying branching logic to an existing field where data is already stored may prompt users to erase values that were previously entered and saved during data entry.
    • New fields held in draft mode cannot be embedded elsewhere on the form or survey to which the new fields are being. To embed new fields, first add new fields to a form or survey and submit the changes, and then, go back into Draft Mode and apply field embedding.
  • Best Practices

    • Before submitting changes, review the change details for critical issues, and whenever possible, make additional modifications to eliminate the issues based on the tips described above.
      • To learn how to review the change details and see the most common types of critical issues and how they can be resolved, watch the video linked to in the call out box on the right and download the accompanying slide deck 
    • Consolidate change submissions using the following guidelines:
      • Submit in a single batch all the changes that will get automatically approved.
      • Submit in a single batch any changes will have critical issues that may result in a data loss or data corruption.

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.
  • 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, 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.

When Test Project Optional 

If the new form DOES NOT need to be added to an event or enabled as a repeating form, a test project is not required, but it is highly recommended. Entering test data on a form is the only way to determine if it looks and behaves as intended, and to and review how the data collected in it would exported, and/or acted on by components of peripheral functionality, like reports or data quality rules.

When Test Project Required

If the new form needs to be added to an event or enabled as repeating instrument, testing the new form in a test copy of the project is required.

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe the new form you are testing. Make sure to indicate if the form needs to be added to an event or enabled as a repeating instrument.

  • The REDCap Team will email you with instructions specific to creating a test project for adding a new form, and if needed adding a new form to an event or enabling a form to be a repeating instrument.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • You are responsible for implementing the changes in your production project, and if the form that needs to be added to an event or enabled as a repeating instrument, there will be instructions for how to coordinate with a REDCap administrator.
  • The test project will be expired on or about 60 days after it was created.
  • Moving an existing field to a new form that needs to be enabled as repeating instrument may cause unintended behavior.
  • If adding more than one new form, separate each form into its own change submission.
  • Consolidate change submissions using the following guidelines:
    • Submit in a single batch all the changes for new forms without critical issues that will get automatically approved.
    • Submit in a single batch any changes for new forms with critical issues that may result in a data loss or data corruption.
  • If the new form needs to be added to an event or enabled as repeating instrument, download the instrument zip and upload it into the test project for testing. For more information on downloading and uploading instrument zips, review the section, Other Functionality Related to Copying on the Copy Project or Project Entities page.

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.

Test Project Required

Testing the new survey in a test copy of the project is required. 

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe the new survey you are testing and how you plan to get the survey to your participants. Also, make sure to indicate if the new survey needs to be added to an event. 

  • The REDCap Team will email you with instructions specific to creating a test project for adding a new survey, and if needed adding a new survey to an event.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • Follow the instructions in email for getting help and managing the requirements for implementing the new survey.
  • The test project will be expired on or about 60 days after it was created.

Modifying Anything about Events (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.

Test Project Required

Testing the changes to the event configurations in a test project is required.

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe the kinds of changes you need to make to your events.  

  • The REDCap team will conduct a change risk assessment and email you with guidance specific to creating a test project project for making event changes.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • Follow the instructions in email for getting help and managing the requirements for implementing the changes to your events.
  • The test project will be expired on or about 60 days after it was created.

If there are barriers to making changes to the events the email will include the REDCap Team's recommendations for how to move forward with an alternate solution. In these situations, it's not unusual if additional help or instruction is required to implement the alternate solution.

If additional help is needed, the email will include information about the next steps, which will involve meeting outside drop-in to create an estimate for the REDCap Team's help.

Ultimately, even when the REDCap Team is providing additional help, it is the responsibility of the builder/point person to evaluate the impact of their event 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. 

Change Tips & Best Practices

Typically, the biggest risks in making changes to events involve the following:

  • Removing an event or removing a form from an event, which will orphan off data that's already been collected and create a data loss.
  • Renaming an event or editing an existing form to event assignment in order to move a form from one event to another event, which will cause any dependent logic statements or syntactical references that invoke the event name in calculated fields, piping, branching logic, report filters, automated survey invitations, survey queue connections, etc., to fail.

For these types for changes we recommend the following alternate solutions: 

  • Instead of removing an event, we recommend using the Form Display Logic tool to create conditional logic to disable data entry access to the forms assigned to the event you want to remove.
  • Instead of removing a form from an event, we recommend using the Form Display Logic tool to create conditional logic to disable data entry access to the form at the event you want to remove the form from.
  • Instead of editing an existing form to event assignment in order to move a form from one event to another event, we recommend using the Form Display Logic tool to create conditional logic to disable data entry access to the form at the event you want to move the form from.
  • Instead of renaming an event, we recommend you create a Custom Event Label to add a short helpful note or alternate name that will be meaningful to other users on the project.

For projects using surveys, making any changes to events heightens the risk of having a negative impact on the project and/or creating complexity that would require additional help because: 1) there are likely dependencies on features that are related to sending out surveys and collecting responses, such as Automated Survey Invitations, Survey Settings or the Survey Queue, all of which have their own learning curves, and 2) there is often a different effect of the changes on existing participants versus new participants that has to be accounted for.

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.

Test Project Highly Recommended 

Testing changes related to Automated Survey Invitations, the Queue or Survey Settings in a test project is highly recommend.

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe the kinds of changes you need to make to related to ASI's, the Survey Queue or one or more form's Survey Settings.  

  • The REDCap team will conduct a change risk assessment and email you with guidance specific to creating a test project project for making these types of changes.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • Follow the instructions in email for getting help and managing the recommendation and/or requirements for implementing changes related to your ASI's, Survey Queue or Survey Settings.
  • The test project will be expired on or about 60 days after it was created.

Additionally, there could be charges ($) for the REDCap Team's help to fix changes related to ASI's, the Queue or Survey settings that were not first tested in a test copy of the project and/or for which the project builder/point person did not seek drop-in support.

Ultimately, even when the REDCap Team is providing additional help, it is the responsibility of the builder/point person to evaluate the impact of their changes related to ASIs, the Survey Queue or Survey Settings 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

The only guardrail built into the system to try to prevent users from making the kinds of changes related to ASIs, the Queue, or Survey Settings, which risk having a negative impact on the project, is secondhand, via  the careful application of User Rights.

  • Restrict which users are assigned permissions to both Project Design and Setup user rights and Survey Distribution user rights.
  • Ensure any user who is assigned permissions to both Project Design and Setup user rights and Survey Distribution user rights, have completed our Basics and Survey trainings.

The REDCap Team can be a helpful guardrail and sounding board for project builders/point persons who email us and/or come to a drop-in sessions to talk through their plans for making changes related to ASIs, the Queue, or Survey Settings. For these kinds of production changes, we provide for the builder/point person the same kind of drop-in and email support that we provide during the development phase of the project.

ASI Change Tips

The ASI Tips page in the Survey Projects section covers topics, such as canceling or rescheduling an ASI, as well as modifying or deactivating an ASI.

Enabling/Disabling Main Project Settings or Optional Modules

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.

Contact the REDCap Team

When a project team needs to make modifications to a project's main settings, or for the use of optional modules, the first step is for project builder/point person to contact the REDCap Team.

Please include in your email the exact title of your project and specifics and details about the types of changes you are requesting.

Most of these types of changes will require additional help from the REDCap Team, and for which there are charges ($).

Help & Support

Typically, modifications to a project's main settings, or for the use of optional modules, are considered to be high impact and/or support-intensive types of changes that will require additional help from the REDCap Team, and for which there are charges ($). See the call out box at the top of the page, When Charges Apply ($). This is because these types of changes are:

  • Inherently riskier (read more about change risk assessments in section above that covers general considerations for help and support);

  • Often introduce unforeseen issues the project team didn't plan for;

  • May have regulatory implications that require additional analysis;

  • Demand technical expertise for testing and implementation.

There are a few modules, listed below, where changes can usually be managed by the project builder/point person first testing the changes in a test copy of their production project and then signing up for a drop-in for the REDCap Team's help with implementation.

  • Enabling repeating forms or events.

  • Enabling or disabling auto-numbering for records.

Occasionally, due to the complexity or breadth of a project, and/or because of the main project settings or optional modules involved, the changes the builder/point person is requesting cannot be accommodated in the existing production project. These situations will likely involve a design consultation or custom support to explore alternate solutions, which most often involve starting over in a new version of the project.

Lastly, as a general rule the REDCap Team doesn't disable or deactivate settings related to a project's main settings or to discontinue the use of an optional module, and there are special considerations when we do. See the section below, Deleting Fields, Forms, Events or Disabling a Main Project Setting or Optional Module.

Ultimately, even when the REDCap Team is providing additional help, it is the responsibility of the builder/point person to evaluate the impact of their 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.

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

  • 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

  • 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.

When Test Project Optional 

For deleting a field or a form that is not assigned to an event or enabled as repeating instrument, a test project is not required, but it is recommended. Testing is the only way to assess impact of deleting a field or form on the data collection workflow and the functionality that facilitates it, and  the components of peripheral features the project team relies on for managing data collection. 

When Test Project Required

Testing in a test copy of the project is required for deleting a form assigned to an event or enabled as repeating instrument, deleting an event, or a disabling a main project setting or optional module 

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe in detail what you plan to delete or disable.

  • The REDCap team will conduct a change risk assessment will email you with instructions specific to creating a test project for deleting or disabling.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • Follow the instructions in email for getting help and managing the requirements for implementing the changes to your events.
  • The test project will be expired on or about 60 days after it was created.

Revising an E-Consent Survey/Form

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

Test Project Optional

If you have never made revisions to an e-consent form, practicing making revisions in a test project is highly recommended

Read more information about test projects.

Creating a Test Project

  • First, email the REDCap Team the exact title of your project, and describe, in detail, the kinds of e-consent revisions you plan on testing.

  • The REDCap Team will email you with instructions and guidance specific to creating a test project for testing e-consent revisions.

  • You will be considered the owner of the test project and the point person for testing the changes.
  • You are responsible for implementing the changes in your production project.
  • The test project will be expired on or about 60 days after it was created.

The REDCap Team provides instruction and guidance for making e-consent revisions via the wiki instructions, through the video that is linked to in the call out box above, by answering follow up questions over email or at a drop-in session, and through supporting the project builder/point person to test or practice making revisions to their e-consent survey/form in a test copy of their project, which can be helpful for all builders/point persons, but is highly recommended for builders/point persons who are making revisions to an e-consent survey/form for the first time.

Additionally, when a project builder/point person submits an e-consent revision with the kinds of critical issues that could result in data loss or data corruption, the REDCap Team will reject the changes, and notify the builder/point person.

Outside of these activities, the REDCap Team is not involved in making e-consent revisions unless, additional help is needed, for which there would be charges, for the following kinds of activities.

  • Prior to submitting their changes, the builder/point person would like the REDCap Team to review their revisions to check for issues, such as if they applied the versioning technique correctly, or validate the changes against the paper form(s) approved by the IRB.
  • The builder/point person would like additional coaching or instruction for making e-consent revisions in the context of their project and their e-consent survey/form.
  • Intervention is required to address e-consent revisions that have failed to preserve the existing e-consent survey/forms submitted by enrolled participants and/or would prevent new participants from submitting a valid e-consent survey/form.

Ultimately, even if the REDCap Team provides additional help, it is the responsibility of the builder/point person to evaluate the impact of the revisions they've made to their e-consent form on: 1) the e-consent survey/forms that existing participants have already submitted, 2) the e-consent survey/form that will be presented to new participants, 3) any other data that's been collected, 4) the data collection workflow and the functionality that facilitates it, paying special attention functionality involved obtaining consent, and 5) the components of peripheral features the project team relies on for managing data collection, and getting e-consent surveys to potential participants and collecting their responses.

Change Tips & Best Practices

  • At a minimum, the e-consent survey/form t will need to be updated when IRB approval dates change. 
  • If IRB requires you to submit a copy of the revised e-consent survey/form, reach out to the REDCap Team to request a copy of your project before submitting your form edits for approval in REDCap.
  • No labels