How to Set Up REDCap E-Consent with Two Signatures
REDCap e-consent two signatures is a common requirement when a consent workflow needs both a participant signature and another sign-off—for example, from a study team member, investigator, witness, parent, or legally authorized representative.
The important thing to understand is that REDCap's standard e-consent workflow is primarily designed around a participant completing and certifying an e-consent survey. When another person also needs to sign, many institutions handle that second signature through a separate instrument or countersignature form, then preserve the completed consent documentation using REDCap's PDF tools.
Some institutions also use External Modules to combine multiple signed instruments into one final PDF. However, External Modules are not part of core REDCap and availability depends on the institution running your REDCap instance. ctsi.ucla.edu
This guide explains the practical options, how a two-signature workflow can be structured, where External Modules fit, and what to check with your IRB or research administration team before implementation.
At a glance
| Details | |
|---|---|
| Typical first signer | Participant or legally authorized representative |
| Typical second signer | Study staff, investigator, witness, or other required party |
| Common REDCap approach | Separate participant and countersignature instruments |
| Final-document option | PDF Snapshot or an approved Multi Signature Consent External Module |
| External Modules | Institution-specific and not part of core REDCap |
| Regulatory review | Workflow should be reviewed against IRB/REB and applicable regulatory requirements |
| Best use case | Research consent workflows already managed inside REDCap |
How REDCap e-Consent Works
REDCap's e-Consent Framework adds controls around an electronic consent survey.
Depending on the REDCap implementation, the framework can add a certification step and preserve a static PDF representation of the completed consent.
For example, the University of Colorado Anschutz describes the framework as adding:
- a certification page at the end of the consent survey; and
- a PDF Snapshot of the submitted responses saved in the File Repository. REDCap Help Center
The participant still completes fields created by the study team, such as their name, consent choices, and signature.
What the signature field captures
REDCap includes a signature field that allows a person to sign using a mouse, stylus, or finger.
Published research describing the REDCap eConsent system notes that the signature can be stored as an image and rendered in the resulting consent PDF along with a timestamp. PubMed Central (PMC)
However, collecting another person's countersignature is a separate workflow question.
An institutional REDCap guide from the University of Alberta specifically notes that the eConsent Framework itself does not directly provide for a study coordinator or other third party to witness consent. It suggests using an additional survey or a separate form for study-staff attestation when required. REDCap Support
Note: A requirement for a witness, investigator signature, or staff attestation is study-specific. Do not assume every e-consent requires two signatures. Confirm the requirement with your IRB/REB and applicable study procedures.
When Does REDCap E-Consent Need Two Signatures?
There is no single universal two-signature requirement.
A second sign-off may be needed because of the study protocol, institutional policy, IRB/REB requirements, or a particular consent process.
Examples can include:
Participant + study team member
The participant signs the consent first.
A study coordinator or investigator then confirms that the consent process was completed according to the approved procedure.
Participant + legally authorized representative
Some study designs may require a legally authorized representative, parent, or guardian to participate in the consent process.
Exactly who signs—and in what order—depends on the applicable research and institutional requirements.
Participant + witness
Some consent processes may require witness documentation.
But witness requirements are not universal. The University of Alberta's REDCap guidance explicitly recommends seeking REB guidance rather than assuming that every electronic consent must be witnessed. REDCap Support
Native REDCap vs External Module vs Dedicated E-Signature Platform
There are several ways to structure a two-signature process.
| Approach | How it works | Main consideration |
|---|---|---|
| Separate REDCap instruments | Participant signs one instrument; second signer completes another | Keeps roles separate inside REDCap |
| PDF Snapshot workflow | Completed data from relevant instruments is preserved as a PDF according to configured triggers | Requires careful setup and testing |
| Multi Signature Consent External Module | Approved module merges multiple REDCap forms into one final PDF | Availability depends on institution |
| Dedicated e-signature platform | Multiple recipients sign through a purpose-built signing workflow | Separate from the REDCap research-data workflow |
This distinction matters because the Multi Signature Consent External Module does not simply place two independent native signature fields into one REDCap e-consent survey.
The publicly available Stanford/SUSOM module describes itself as combining data from multiple REDCap forms into a single PDF, and UCLA documents it for participant consent plus investigator or study-personnel countersigning. GitHub
Prerequisites for REDCap E-Consent Two Signatures
Before building the workflow, decide these four things.
1. Which two people must sign?
Write down the exact roles.
For example:
- Participant + study coordinator
- Participant + investigator
- Participant + witness
- Participant + legally authorized representative
Do not label the second person generically if the study documents define a specific role.
2. Must the signatures appear on one final document?
This changes the implementation.
If both signatures merely need to be retained in the study record, separate REDCap instruments may be sufficient.
If your approved workflow requires a final document containing both sign-offs, you may need PDF Snapshot configuration or an approved External Module that combines instruments.
3. Which REDCap features are available at your institution?
REDCap is locally administered.
External Modules must typically be reviewed and enabled by the institution's REDCap administrators.
Some institutions restrict modules because third-party code requires security, compatibility, and governance review. REDCap Help Center
4. Has the workflow been reviewed by the IRB or REB?
Do this before assuming a technical workflow is acceptable.
CU Anschutz, for example, tells study teams to obtain COMIRB approval before implementing e-consent. REDCap Help Center
Tip: Build a one-page workflow showing who signs → in what order → where each signature is stored → what final PDF is retained. It is much easier to review this with your REDCap administrator and IRB than to describe the setup after it has already been built.
REDCap E-Consent Two Signatures: A Step-by-Step Guide
A common structure is to use two instruments rather than trying to force two independent people through one participant survey.
- Create the participant e-consent instrument.
- Enable the appropriate e-consent settings for that survey.
- Add the participant's required consent and signature fields.
- Create a separate countersignature or attestation instrument.
- Add the second signer's name, role, date, signature, and any required attestation wording.
- Control when the second instrument becomes available.
- Configure your final PDF or archival workflow.
- Test the workflow with dummy records before production use.
This structure is consistent with institutional guidance for study-staff countersigning.
A REDCap e-consent implementation guide recommends a separate form such as Researcher witness or Researcher countersigning, then controlling when it becomes available so that the researcher cannot countersign before the participant has consented. Norwich CRTU
Step 1: Create the Participant E-Consent Instrument
Create your consent instrument using REDCap's Online Designer.
Typical fields might include:
- participant name;
- required consent statements;
- consent choices;
- signature;
- date where required;
- relevant study identifiers.
Then enable the instrument as a survey.
If your institution supports and approves use of REDCap's e-Consent Framework, configure it according to your local REDCap guidance.
Do not rely entirely on a generic internet tutorial because institutions can configure REDCap differently.
Step 2: Create the Second-Signer Instrument
Create a second instrument for the study staff member, investigator, witness, or other required signer.
For a study-team countersignature, this might include:
| Field | Example | Purpose |
|---|---|---|
| Signer name | Jane Smith | Identifies second signer |
| Role | Study Coordinator | Records why they are signing |
| Attestation | “I confirm that…” | Documents the meaning of the signature |
| Signature | Signature field | Captures sign-off |
| Date | Study-defined field or timestamp | Records timing where required |
Keeping this second signer on another instrument can also make permissions easier to manage.
The participant can complete the participant-facing survey while authorized study staff access the countersignature instrument separately.
Step 3: Prevent the Second Signature From Happening Too Early
The second signer should not necessarily be able to complete their section before the participant signs.
Depending on the study design, you can control access through:
- branching logic;
- instrument status;
- survey queue logic;
- automated invitations;
- workflow controls approved for your REDCap environment.
One published REDCap e-consent implementation guide specifically recommends ensuring that the researcher countersign form becomes available only once the participant has signed. Norwich CRTU
That creates a cleaner order:
Participant signs → participant consent completes → second signer becomes eligible → second signer signs → final documentation is generated
Combining the Two Signatures Into One PDF
This is where the original draft was most inaccurate.
There are at least two approaches depending on the REDCap version and your institution's configuration.
Option 1: PDF Snapshot tools
Newer REDCap implementations may use built-in PDF Snapshot functionality.
Washington University's REDCap documentation describes moving from the older Multi Signature Consent External Module to REDCap's built-in PDF Snapshot tools.
Their workflow can create a snapshot once configured logic becomes true and save the resulting PDF to the File Repository and/or a file-upload field. washu.atlassian.net
This is significant because older guides may still describe an External Module even when your local REDCap now has native tools capable of handling the required PDF workflow.
Option 2: Multi Signature Consent External Module
Where approved and installed, the Multi Signature Consent External Module can combine multiple instruments into one PDF.
For example, UCLA documents the following structure:
Participant e-consent instrument → PI/study-personnel countersign instrument → file-upload instrument → module merges the selected instruments once the required conditions are met. ctsi.ucla.edu
The Stanford/SUSOM module likewise states that it was designed to combine participant and coordinator consent signatures from multiple forms into a single PDF. GitHub
What the module does not mean
It does not mean:
“Add one native participant signature field and let the module inject a second signature field underneath it on the same survey.”
That description in the earlier draft should be removed.
Should You Use an External Module?
Think of an External Module as an extension to REDCap rather than standard REDCap functionality.
It may make sense when:
- your institution already supports the module;
- the research team needs a merged final PDF;
- the workflow has been reviewed locally;
- module maintenance is handled by your REDCap administrators.
It may not make sense when:
- your REDCap instance does not permit the module;
- equivalent built-in PDF Snapshot features are already available;
- the workflow can be handled cleanly with separate records/instruments;
- your institution requires formal module security review.
Note: External Modules are not universally available. A tutorial should never tell researchers to activate one and assume it will appear in every REDCap installation.
What the Participant and Second Signer Actually See
The two people do not necessarily sign one after another on the exact same REDCap page.
That was another misleading part of the original article. Pasted text
A more typical separate-instrument workflow looks like this:
Participant experience
The participant:
- opens the e-consent survey;
- reviews the consent information;
- enters any required information;
- signs;
- certifies or submits the consent according to the configured framework.
The participant's part is then stored according to the project's e-consent configuration.
Study-team experience
After the participant completes consent, the authorized study-team member opens the separate countersignature instrument.
They may review the relevant participant consent information, complete their attestation, and add their own signature.
The project can then generate or merge the final documentation as configured.
One Device or Two Devices?
That depends entirely on the approved workflow.
A participant and study staff member might interact during the same consent session, but they do not have to share one signature pad or manually pass the same browser window back and forth.
Separate instruments allow the workflow to support different users and access permissions.
That is usually cleaner than treating the process as:
Participant signs → scroll down → investigator grabs the device → investigator signs the next field.
Troubleshooting Common Two-Signature Problems
The second signer cannot access the instrument
First check the workflow logic.
Make sure the instrument is actually available after the participant consent reaches the required status.
Also verify that the person has the correct project permissions or survey access.
The final PDF contains only the participant signature
Determine when the PDF was generated.
If it was produced before the second signer completed their instrument, the second signature obviously cannot appear in that version.
Configure final PDF generation to occur only once the conditions for all required signatures have been met.
The Multi Signature Consent module is missing
That does not necessarily indicate an error.
External Modules must be available and enabled on your institution's REDCap installation.
Contact the local REDCap administrator rather than trying to install an unsupported module yourself.
The module exists but does not create a PDF
Review:
- which instruments were selected;
- the merge condition;
- whether both source instruments are complete;
- file-storage settings;
- module-version compatibility.
The Stanford/SUSOM repository also documents a potential configuration conflict involving the redcap_pdf hook, so module-specific documentation should be checked when troubleshooting. GitHub
Regulatory and Compliance Considerations
This section of the original article also needed correction.
It claimed that 21 CFR Part 11 essentially requires only three things and that REDCap fails because it does not verify identity, lock documents, or provide certain specific audit evidence. Pasted text
That is too simplistic.
21 CFR Part 11 is broader than three requirements
Part 11 contains requirements concerning electronic records and electronic signatures when it applies.
FDA describes controls including areas such as:
- access restrictions;
- authority checks;
- operational checks;
- appropriate electronic-signature controls;
- system documentation;
- policies holding individuals accountable for actions under electronic signatures.
Part 11 also interacts with the underlying predicate rules that require particular records to be maintained. U.S. Food and Drug Administration
So an article should not reduce Part 11 compliance to:
identity + signature + audit trail = compliant.
Compliance is system- and use-case-specific.
Identity verification
For FDA-regulated clinical investigations, FDA states that the organization must verify an individual's identity before establishing or sanctioning that person's electronic signature.
FDA does not prescribe one universal identity-verification method.
Potential methods can include official identification, security questions, strong login credentials with multifactor authentication, or video observation, depending on the circumstances. U.S. Food and Drug Administration
The appropriate method depends on the study and system.
A drawn signature and an electronic signature are not always the same regulatory concept
This is an important technical distinction.
FDA's more recent guidance says that a signature drawn using a finger or stylus is considered a handwritten signature executed to an electronic record, rather than an “electronic signature” in the specific Part 11 definitional sense. It must still be linked to its corresponding electronic record. U.S. Food and Drug Administration
That is why broad claims such as “a signature image plus timestamp is Part 11 compliant” should be avoided.
REDCap and Part 11
Whether a particular REDCap implementation can support a regulated workflow depends on how the institution configures, validates, controls, and operates it.
Do not write:
“REDCap is not Part 11 compliant.”
And do not write:
“REDCap is Part 11 compliant.”
Neither statement is appropriately universal.
The better wording is:
If your study is subject to FDA electronic-record requirements, confirm with your institution's regulatory, REDCap, and IT teams whether the configured REDCap environment and e-consent workflow meet the requirements applicable to that study.
FDA's electronic informed-consent guidance specifically states that the information, electronic process, and documentation must meet applicable requirements in Parts 11, 50, 56 and other relevant regulations. U.S. Food and Drug Administration
Audit Trail: What to Verify
Rather than promising a universal set of REDCap audit capabilities, verify your own implementation.
For a two-signature consent workflow, document:
| Check | Why it matters |
|---|---|
| Who completed each action | Establishes responsibility |
| When each action occurred | Establishes sequence |
| Which consent version was used | Prevents version ambiguity |
| What was preserved after completion | Supports record retention |
| How edits are recorded | Helps reconstruct changes |
| How signatures relate to the corresponding record | Maintains context and meaning |
FDA describes an audit trail as a secure, computer-generated, time-stamped electronic record that allows reconstruction of events involving creation, modification, or deletion of an electronic record. U.S. Food and Drug Administration
Your institution should determine which controls are required for the specific study.
When to Use a Dedicated E-Signature Platform Instead
REDCap is primarily a research data platform.
A purpose-built e-signature system may be easier when the document is primarily a contract or general business document rather than a research consent record.
Examples include:
- client agreements;
- employment documents;
- vendor contracts;
- agency contracts;
- multi-party commercial agreements.
For those workflows, a dedicated signing application can provide features such as recipient routing, reminders, signer-status tracking, and completed-document delivery.
That does not automatically make a commercial signing platform appropriate for a regulated research consent workflow.
If a study uses an external signing platform for informed consent, the research team still needs to determine whether it satisfies the protocol, IRB/REB requirements, privacy requirements, institutional policy, and any applicable regulations.
How LoreSign fits
LoreSign is designed for sending ordinary documents and contracts for signature.
A sender can prepare a document, place required signing fields, add recipients, send it for signature, and track completion.
That makes it a potentially simpler fit for general multi-party document signing.
It should not be presented as an automatic substitute for REDCap in regulated clinical research.
For research consent, the institution should first determine whether an external platform is authorized for that use.
Frequently Asked Questions
Can REDCap collect two signatures for one consent workflow?
Yes, a study can structure REDCap to collect multiple required sign-offs, often using separate instruments for the participant and the second signer. The appropriate workflow depends on the study and the REDCap features available at the institution.
Does REDCap natively put two independent signers on one e-consent survey?
Do not assume so. Institutional guidance commonly uses a separate participant e-consent and a separate researcher or countersignature instrument when a second person must sign. REDCap Support
What does the Multi Signature Consent External Module do?
The publicly documented Stanford/SUSOM module combines information from multiple REDCap forms into one final PDF. It was specifically designed to combine participant and coordinator consent signatures. GitHub
Do I need an External Module?
Not necessarily. Newer REDCap functionality can support more advanced PDF Snapshot workflows, and some institutions have explicitly migrated away from the Multi Signature Consent External Module to built-in tools. washu.atlassian.net
Can participants sign REDCap consent on a phone or tablet?
REDCap's signature field supports signing using a finger or stylus, and REDCap surveys can be accessed through mobile browsers. The exact user experience should be tested on the devices your participant population is expected to use. PubMed Central (PMC)
Is REDCap automatically 21 CFR Part 11 compliant?
That should not be treated as a universal yes/no property of the software. Compliance depends on whether Part 11 applies to the study and how the electronic system, procedures, controls, validation, signatures, and records are configured and operated. FDA recommends evaluating the system against the relevant regulatory requirements. U.S. Food and Drug Administration
The Bottom Line
REDCap e-consent two signatures is best treated as a workflow problem rather than simply a request to place two signature pads on one form.
A common approach is:
Participant e-consent → separate second-signer instrument → both completed → final PDF generated or assembled.
Where available, REDCap's built-in PDF Snapshot functionality may support the final-document workflow. Some institutions still use approved External Modules that combine multiple signed instruments into one PDF. GitHub
The correct setup depends on your REDCap version, local institutional configuration, IRB/REB requirements, and the regulatory context of the study.
If the document is instead a general contract or business agreement requiring multiple signers, a dedicated e-signature platform such as LoreSign may provide a simpler multi-recipient workflow.
Sources and further reading
- FDA — Use of Electronic Informed Consent in Clinical Investigations: regulatory guidance for electronic informed consent. U.S. Food and Drug Administration
- FDA — Part 11, Electronic Records; Electronic Signatures: scope and application of Part 11 requirements. U.S. Food and Drug Administration
- Stanford/SUSOM — Multi Signature Consent External Module: describes merging multiple REDCap forms into one PDF. GitHub
- UCLA REDCap — External Modules: documents its Multi Signature Consent workflow using separate e-consent and countersign instruments. ctsi.ucla.edu
- Washington University REDCap — Move from External Module to Built-in Tools: documents migration from Multi Signature Consent to PDF Snapshot functionality. washu.atlassian.net
- CU Anschutz — e-Consent Framework: describes certification and PDF Snapshot behavior. REDCap Help Center
About LoreSign
LoreSign helps businesses, freelancers, and teams send documents and contracts for signature. Add recipients and signing fields, track signer progress, and receive the completed document when signing is finished.
Research organizations should independently determine whether any external e-signature service is appropriate for a specific research-consent workflow.



