REDCap E-Consent Two Signatures: Setup Guide

Learn how to set up two signatures in REDCap e-consent, including participant and staff signing workflows, countersignatures, signature fields, and key setup considerations.

Guide

· 17 min read

On this page
LoreSign guide showing a REDCap survey with one signature field beside a printed consent form with two signature lines and a smartphone displaying a two-signature e-signature workflow.

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 signerParticipant or legally authorized representative
Typical second signerStudy staff, investigator, witness, or other required party
Common REDCap approachSeparate participant and countersignature instruments
Final-document optionPDF Snapshot or an approved Multi Signature Consent External Module
External ModulesInstitution-specific and not part of core REDCap
Regulatory reviewWorkflow should be reviewed against IRB/REB and applicable regulatory requirements
Best use caseResearch consent workflows already managed inside REDCap

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.

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.

ApproachHow it worksMain consideration
Separate REDCap instrumentsParticipant signs one instrument; second signer completes anotherKeeps roles separate inside REDCap
PDF Snapshot workflowCompleted data from relevant instruments is preserved as a PDF according to configured triggersRequires careful setup and testing
Multi Signature Consent External ModuleApproved module merges multiple REDCap forms into one final PDFAvailability depends on institution
Dedicated e-signature platformMultiple recipients sign through a purpose-built signing workflowSeparate 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.

  1. Create the participant e-consent instrument.
  2. Enable the appropriate e-consent settings for that survey.
  3. Add the participant's required consent and signature fields.
  4. Create a separate countersignature or attestation instrument.
  5. Add the second signer's name, role, date, signature, and any required attestation wording.
  6. Control when the second instrument becomes available.
  7. Configure your final PDF or archival workflow.
  8. 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

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:

FieldExamplePurpose
Signer nameJane SmithIdentifies second signer
RoleStudy CoordinatorRecords why they are signing
Attestation“I confirm that…”Documents the meaning of the signature
SignatureSignature fieldCaptures sign-off
DateStudy-defined field or timestampRecords 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.

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:

  1. opens the e-consent survey;
  2. reviews the consent information;
  3. enters any required information;
  4. signs;
  5. 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.

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:

CheckWhy it matters
Who completed each actionEstablishes responsibility
When each action occurredEstablishes sequence
Which consent version was usedPrevents version ambiguity
What was preserved after completionSupports record retention
How edits are recordedHelps reconstruct changes
How signatures relate to the corresponding recordMaintains 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

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.

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

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

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.

All blog posts