Modify E-Consent: Public Surveys (version control)

Initial Considerations

If you wish to learn how to set up a new e-consent (as opposed to modifying an existing econsent which is the focus of this article) please refer to our E-Consent Knowledge Article.

Design changes after the Production phase are discouraged but sometimes needed. If a new version of the consent is needed, it is critical to modify the project in such a way as to not lose existing data nor compromise the audit trail of the REDCap e-Consent.
There are two ways to implement new versions of e-consent:

1. Creation of new instruments
2. Branching Logic

If you are using a public survey as your e-consent you must use the branching logic methodology

 
The Process

Background: 

Below are images of what a previously set up e-consent looks like and how the files are stored in the file repository

Here is an image of an existing e-consent configuration as view in Survey Settings. 

• Note that REDCap automatically inserts "public survey" as the e-consent type

• When e-consent framework has been implemented, PDFs of the signed consents are automatically stored in the project's file repository as shown below

• When you click on the file repository the "User files" tab is displayed. You must click on the PDF Survey archive
  
  • Note that the e-consent type is prefilled as public survey
    
    
• You can click on the PDF to see the signed consent which shows the participants first & last name and version # in the footer

If you need to modify the consent to Version 2,  do NOT copy the project (including the existing records) with the plan to insert a new public instrument as this will break the audit trail of the previously e-consented participants.

• While the record status dashboard and the first screen of the File Repository may appear normal, the PDFs are no longer intact as shown below

• Once you click on PDF survey archive, you will notice that the previous e-consents are not listed
  

The PDFs of the previous records are gone! This exemplifies the stringent audit trail that the e-consent maintains thus proving the e-consents can't be altered once signed by the participant.

The optimal way to add a new version to an existing E-consent Public Survey project is to modify the current instrument and use branching logic.

1. Keep the existing public survey instrument as the first instrument in the project
   
   
   
2. Create new fields for each updated section of the consent.
   1. These updated fields should sit under the original field
      
      
3. Create a field in the public survey to denote Consent Version.
   1. Use Action tags to ensure that only the current version of the e-consent is selected.
   2. Use the @Default to ensure only the most current version is presented and @HIDDEN SURVEY)
      
      
      
      
      
4. Use of branching logic makes the new fields visible only when the appropriate current version of the e-consent is selected.
   
   
   
5. Remember to also increment the version number in the Survey Settings to prevent the PDF file from indicating version 1 when it should be version 2.
   1. Below is an example of where participant #3 actually filled out Version 2 but because the survey settings were not updated, the accurate version is not shown in the PDF file display. (However if you open the PDF it will be second version signed by the participant)
       
6. Below is the updated Version control performed in Survey Settings (some people like to include the date of the version)
   
   
   
   
7. The PDF file now accurately reflects the version of each participant

All records are also accurately displayed as well on the record status dashboard

Additional Considerations

Q. What is the optimal way to handle multiple signatures? For instance, the parent or participant consents and then our PI would need to sign the consent. Usually this is all done in person, however, with e-Consent what is the best workflow? I know the records are locked, so what is the best way to have that signed?
A. Use a two-part system.

1. Survey 1 – e-Consent, signed, reviewed, and submitted within the e-consent framework.
2. Survey 2 – is triggered by submission of survey 1 and is emailed to the study coordinator or PI. The survey is an attestation that has the participant's information piped in and can be signed by the PI, reviewed, and also submitted within the e-consent framework.

A guide to setting up the 2 part e-consent with a  second survey capturing the second signature is outlined in the knowledge article titled Remote Contactless e-Consent & Attestation