Setup and Implementation of Electronic Consent
TrialKit can electronically enforce the completion of a consent form and provide the patient access to site-specific consent documents. This is an alternative to the traditional paper method often used at sites. However, even if paper is still used at some sites, TrialKit supports a hybrid approach as well.
This article covers how to configure various parts of the consent process, but here's an overview of the overall capabilities:
-
Subjects/patients can fill out their own consent forms and receive an automatic email verification of that consent along with copies of the documents that were signed.
-
Subjects can view site-specific and version-specific consent documents.
-
Consent can be used to control further data entry of forms being deployed to the Participant (read more about ePRO).
-
Patients can revoke consent with reason, or Administrators can require re-consent on batches of subjects.
-
Subjects, consent status, and consent history can be tracked.
Table of Contents
Configuring Consent
Prerequisites:
- Study is licensed to utilize the Consent and ePRO
- The study is configured for ePRO
- User has role permission access to Informed Consent, Configure informed consent
Once enabled, there will be an option under the study configuration menu "Informed Consent".
Mobile App:
Reference the annotated image below on the various functions defined on the screen.
1. Enable the consent tracking function.
If consent tracking is enabled, the system will require patient consent prior to any other forms being accessible to both the Participant and Clinicians.
Read more below for information on setting up the study for hybrid paper consent where some of the subjects will be consenting via traditional means.
2. Define which form the patient will be filling out as the consent form. Only ePRO log forms will display as options here. Those are defined in the form properties.
3. Opt to send the Participant an automated email once consent is completed, and set which email notification should go out. Email notification can be configured within the form builder.
4. If there are general documents that need to be sent to consented participants regardless of their site, this full list of files can be used to choose from.
5. A site document file for informed consent is the most common option to include as email attachments to the patient. This section is a list of upload fields from the site document forms in the study. Any file uploaded to that field for each site will be included as an attachment in the email to the Participant after they provide consent. Read more below about setting up a site document to store versioned consent documents.
6. Select which file upload field on the site documents should be mapped to a help button on the Consent form. This is optional but recommended so Participants can reference the site-specific study information directly on the form they are providing consent on. The only alternative to this is embedding all wording/content on the form itself, which is more work than linking a pre-made document.
7. Include any CC email addresses which should be on the recipient list when consent verification is sent to the patient after they consent. For example, if a Study Coordinator or Study Administrator would also like to be copied on each Consent verification email.
8. This option will only show based on permission granted. It is a function used when adding hybrid consent to a study that is already running.
Be sure to save the configuration at the bottom of the page when finished.
Tips:
- As Participants consent to the study, the Consent Report will track the history and allow Administrators to deploy new versions of consent, or force re-consenting in the future.
- The subject manager will indicate which subjects are consented, not consented, or using paper consent.
Site Consent Documents
As defined in the configuration above, a field within a site form needs to be set to store the site-specific consent documents, since each site could have a different version of the same document. Furthermore, there can be new versions added over time that correspond to new versions of the study. Making sure a subject on version 2, for example, has access to their own site's version 2 document is important.
Normally it makes sense to have a dedicated site form like "Consent Documents". The minimum this form should contain is an upload field and a dropdown field mapped to versioning (see example below). Within the form builder, the form should also be set as a log form with a relation of many, so that each site over time can have multiple consent versions logged.
In the Site Documents screen, when a document is uploaded, it will be necessary to indicate which study version the document is applicable to. If this is not done, the system will assume/use the first one in the log if one exists.
If a new version is needed later on, do not update the existing form. Instead simply add a new log/record:
Multi-Signature Consent
Multi-Signature consent refers to two (or more) separate parties being required to sign before the participant is considered fully consented. This is often both the Participant and Site, but can include any number of roles.
To accomplish this, additional signature fields can be added to the consent form and assigned to the roles responsible for signing as shown below.
When the Participant fills out and saves the consent form with no errors and a signature, they will remain un-consented until the other required signatures are present. Once that is done, the system will consider the Participant as consented.
Signatures assigned to specific roles prevent other roles from seeing that signature. If a given role needs to be able to see all signatures, they need to be given permission to view all signatures within the role security settings.
If a signature is assigned to a role, it will be required when a user with that role is saving the form.
In a consent form, once all signatures are applied, an email will be sent to the Participant.
Hybrid e-Consent/Paper Consent Studies, or Where e-Consent is Being Enabled Mid-Study
If some patients will be e-consenting and others by some other means, such as paper, a couple of extra steps are needed before enabling e-consent on the whole study.
First, add a checkbox to the registration form and set the Paper Consent property. This is what the site will check on the registration form to prevent the system from enforcing electronic consent for specific patients.
Second, if some subjects already exist in the study, they need to be updated to reference the new paper consent option. On the consent configuration (#8 described above), there is a button to Add Informed consent to the existing study.
User must have role permission access to Populate all Patients with Paper Consent
Allow Consent to be Revoked
Participants or any other user roles can be given the ability to revoke the Participants consent. This is done by the "Revoke consent" permission within the role security settings.
When a user has this permission, they will see an option at the top of the consent form, only within the Mobile App.
With consent revoked, the Participant will no longer be able to access forms. This should be used in combination with a study exit form that the Clinician still completes because only the study exit form will prevent future data entry from Clinicians and also prevent notifications from going to the Participant.
Automatically Revoke Consent
It's possible to force automatic loss of consent for the purpose of requiring consent again before the Participant can continue with study activities. Age is the most common factor that determines this, which is why there is an option within the study configuration to "Enforce re-consent rules"
It can be enabled with pre-defined age values so the system knows when a given Participant should need to re-consent. This is found under the study configuration settings (shown here on the mobile app, but also available via the web):
Tap the Setup button to define the age thresholds, along with the message that the user should see when they sign in to re-consent. It's also possible to force the user's login PIN to change at this point. This is to ensure that a Participant who may have been a minor previously now has their own PIN that a guardian cannot access.
For all of this to work, the system needs to know the Participant age any time the sign in. That part is done by making sure the birthdate is defined within the form builder.
Anytime the Participant signs in, the system will check if the pre-defined age values have been passed. If it has been, the Participant will be required to re-consent again.