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.
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
Edit the ICF Version
radio button field
.
Add a new option that corresponds to your new version.
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.
Step 2: Add New Dates
Copy the icf date
descriptive text field
that contains the IRB approval and expiration dates to create a new date field.
Edit the
field label
of the new date field with IRB approval and expiration dates for the new version of the consent.
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
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.
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.
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.
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.
(based on the raw value of the new icf version option) to the new Apply branching logic
descriptive text field
that was created to show the new field for new version.
Review the changes before you submit them.
Example of a summary of changes
Special Note: Do Not Edit these Components
Do not edit the
radio button field
that captures the participant's consent decision.
If the e-consent requires the participant to enter their name, do not edit the
text fields
for the first and last name.
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
Do not deactivate survey as an e-consent.
Do not edit the
e-consent framework
settings.
For Projects with a PDF Snapshot Configured
Do not deactivate the
PDF snapshot
trigger. Do not edit the
PDF snapshot
settings.
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.