The study team is responsible for ensuring their e-consent survey is up-to-date with modifications made to their paper consent form, as well as maintaining, over the lifetime of their project, any components of the project that refer to the participant's e-consent decision, such as logic embedded in displaying forms, in connections between the e-consent survey and subsequent surveys, or embedded in automated survey invitations scheduled to send to enrolled participants. 

This page focuses on making changes related to e-consent surveys and related settings and components when a project is in production.

When Charges Apply ($)

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

  • Adding an e-consent survey to a production project that was not initially set up for e-consent.
  • Adding a new e-consent survey, 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 survey.
  • Intervention that is needed to address e-consent revisions that 1) have have failed to preserve existing submitted e-consent surveys, 2)  would prevent new participants from submitting a valid e-consent survey.

Disclaimer: This page refers to features and functionality that are covered in Basics and Survey trainings, or well documented in REDCap itself. These features will not be described in detail here. For help with any of this functionality, once you've completed trainings and started building your e-consent project, please contact the REDCap Team or sign up for a drop-in.



Topics Covered:



Managing Change

Any study staff assigned to a REDCap project with the user permission enabled for the Project Design and Setup user right can make changes to the project, including modifying the e-consent survey and/or any other components that may have been set up to distribute the e-consent survey and/or have a dependency on the consent decision recorded in the e-consent survey.

The number one thing a study team can do to manage e-consent and e-consent related revisions is to apply principle of least privilege in assigning user permission, and monitor user permissions throughout the lifecycle of the project to ensure principle of least privilege has been assigned. 

Best Practices for User Management

  • User Permission Management
    • Create a User Role for the study staff managing the project. 
      • Only assign Project Design and Setup permissions to this role.
      • Assign no more than 2 users (the project point person and their back-up) to this role.
    • Limit how many users have permission enabled to User Rights to restrict who can modify user permissions.
  • E-Consent Revision Training
    • Review making e-consent revisions with any user for whom the Project Design and Setup user right has been enabled.

The number two thing a study team can do to manage e-consent and e-consent related revisions is first test and vet their changes in a test copy of the project. Find more information about test projects on the wiki page that cover making production changes

Best Practices for Testing

  • Test making revisions to the e-consent survey in a test copy of the project before implementing the changes to the e-consent survey in the production project.

  • Test any productions changes that would impact any components of the project that refer to the participant's e-consent decision, such as logic embedded in displaying forms, in connections between the e-consent survey and subsequent surveys, or embedded in automated survey invitations scheduled to send to enrolled participants.


Support Track Availability

Intended Audience & Prerequisites

Intended Audience

  • Project point persons

Prerequisite Knowledge & Experience

  • Basics & Survey trainings.

  • Working knowledge of the Online Designer, Survey Settings, and optional survey tools.

E-Consent Workflow in REDCap

Study staff share the e-consent survey link with the participant.


Participant completes the e-consent survey.


REDCap saves a PDF copy of the submitted e-consent survey.


Study staff provide participant with a copy of the submitted e-consent survey, or a copy of the consent form if the participant signature is not required.


For a Consent and Authorization e-consent survey that requires the documentation of the study staff obtaining consent, study staff completes the Consent Attestation survey.


REDCap saves a PDF copy of the submitted Attestation survey. 

Versioning Revisions 

The guidance for revising an e-consent survey is focused on version management so that:

1) the most recent version of the e-consent survey is distributed to new participants.

2) older versions of the e-consent survey that were submitted by existing participants are preserved. 

Except for correcting typos, the project builder/point person is expected to follow the instructions, outlined below, for versioning their revisions to their e-consent survey. However, the system does not force the builder/point person to version their revisions, and it is the responsibility of the builder/point person to know that versioning is required and to understand how to implement it.

Why Versioning is Important

When revisions are versioned, the study staff can open a participant's record in REDCap and review the participant's submitted e-consent survey response, and reliably know the elements of the study the participant consented to.

When revisions are not versioned, already submitted e-consent surveys will be updated with the language and content of the most recent consent version, which makes it appear the participant submitted the most recent version of the e-consent and consented to new element of the study they have not consented to.


↑ top of the page


Revision Instructions

In short, versioning a revision to the e-consent survey, which is required, involves the following activities

1) editing ICF version radio button field to add option, and updating the DEFAULT action tag with the value of the new option.

2) adding new descriptive text fields that correspond to new or revised sections of the most recently approved paper consent.

3) applying branching logic to hide dates and and outdated sections of the e-consent survey that correspond to the old version of the consent, and show dates and new or revised sections that correspond to the new version.

We highly recommend you keep separate e-consent revisions from other production changes, meaning  do not make changes to fields on other forms or surveys at the same time you're making changes to the e-consent survey. This approach reduces the chance for errors in making revisions, submitting the types of changes that will be held up for review, and makes it easier to review the changes before you submit them.

These instructions assume you understand how to enter Draft mode and make form changes.

Step 1: Update the Version Control Field 

(tick) Edit the ICF Version radio button field.


(tick) Add a new option that corresponds to your new version.


(tick) Update the @DEFAULT action tag with the raw value of the new option you added for your new version.



Examples
of edits to the ICF Version field.


Edits made to the ICF Version field 



Edited ICF Version field

Step 2: Add New Dates

(tick) Copy the icf date descriptive text field that contains the IRB approval and expiration dates to create a new date field.


(tick) Edit the field label of the new date field with IRB approval and expiration dates for the new version of the consent.


(tick) Apply branching logic (based on the raw values of the icf version field) to date field that was copied and the new one that was created to hide the IRB approval dates for the expired version of consent and show IRB approval dates for new version of consent.


Step 3: Add Revised or New Content

(tick) For revised language, make a copy of the existing corresponding descriptive text field.
In example below, we are making a copy the field that covers of the Exams, Tests and Procedures.


(tick) Edit the field label of the new field with updated  language approved by the IRB.
In example below, we are adding the new procedure to the new field that covers of the IRB approved revision to Exams, Tests and Procedures.


(tick) Apply branching logic (based on the raw values of the icf version field) to the descriptive text field that was copied and the new field that was created to hide the outdated language associated with the expired version of the consent and show the revised language approval dates for new version.

 

(tick) For new content: 1) add a new descriptive text field, 2) define the variable name, 2) add the content to the field label, and 3) use the rich text editor to format the field to be consistent with the formatting for the rest of the e-consent survey.

 

(tick) Apply branching logic (based on the raw value of the new icf version option) to the new descriptive text field that was created to show the new field for new version.

 

(tick) Review the changes before you submit them.


Example of a summary of changes

Special Note: Do Not Edit these Components

(minus) Do not edit the radio button field that captures the participant's consent decision.

(minus) If the e-consent requires the participant to enter their name, do not edit the text fields for the first and last name.

(minus) If there is an Attestation Survey that staff complete, do not edit any part of the survey.

For Projects with E-Consent Framework Settings Configured

(minus) Do not deactivate survey as an e-consent.


(minus) Do not edit the e-consent framework settings.

For Projects with a PDF Snapshot Configured

(minus) Do not deactivate the PDF snapshot trigger.


(minus) Do not edit the PDF snapshot settings.


↑ top of the page


Other Changes with a Dependency on the E-Consent Survey

In this section we are referring to any components of the project that refer to the participant's e-consent decision.

Not every project has the other components configured, and for those that do, not every project has the same components configured. Below we have listed out some of common components that we've observed study teams configure to refer to the participant's e-consent decision.

  • Branching Logic to show fields for consented participants and hide fields for participants who did not consent.
  • Form Display Logic to show forms for consented participants and hide fields for participants who did not consent.
  • Survey Queue to connect participants who consented to a subsequent survey.
  • Automated Survey Invitations that send survey invitations to subsequent surveys to consented participants.

Changing how these components are configured should first be tested in a test copy of the project to ensure the component is still working as intended. Reach out to the REDCap Team at redcap@ohsu.edu to request a test project.


↑ top of the page