REDCap eConsent Framework: Setup and Regulatory Fit

REDCap’s eConsent Framework turns an ordinary REDCap survey instrument into an electronic informed-consent process: it adds a signature field, a submission-time PDF snapshot, and (via REDCap’s separate Survey Queue feature) automatic gating of downstream study surveys on a completed consent. It is a real, widely-adopted REDCap feature — not a bolt-on third-party product — but it is a documentation and signature-capture mechanism, not a regulatory approval. This guide covers the setup mechanics and, more importantly, exactly what the Framework does and does not satisfy under 21 CFR Part 11 and the Common Rule (45 CFR 46).

What the eConsent Framework actually is

The eConsent Framework is a setting available on any REDCap survey instrument, not a separate module you install. Enabling it on a consent instrument does three things a plain survey doesn’t:

• It exposes a dedicated Signature field type in the Online Designer, so the participant signs by drawing (mouse, stylus, or touchscreen) directly on the consent form rather than typing initials or checking a box.
• On submission, REDCap generates a static PDF rendering of the completed, signed instrument and stores it as a locked file attached to that record — a fixed snapshot of exactly what the participant saw and signed, independent of any later edits to the underlying instrument design.
• It supports REDCap’s role-based user rights and audit-trail logging on the consent record the same way it does for any other instrument, so who viewed or modified the record, and when, is captured.

None of this is unique to clinical trials — the same mechanism works for any study that needs a signed, dated, tamper-evident consent record, which is why it sits in CASRAI’s research-tools coverage as a survey-and-data-collection feature rather than purely a clinical-research one.

Setting it up: instrument, signature field, and the survey queue

Three separate pieces have to be configured correctly for the eConsent Framework to behave as intended:

1. Enable the Framework on the consent instrument

The consent form has to exist as its own REDCap instrument, set up as a survey (not a data-entry form only), with the eConsent Framework option turned on in that instrument’s survey settings. This is what activates the signature field type and the submission-time PDF generation for that specific instrument — it is a per-instrument setting, not a project-wide switch.

2. Add and configure the signature field

The Signature field is added like any other field in the Online Designer. Because it captures a drawn signature rather than typed text, it should sit at the end of the consent language, after every disclosure element the study’s IRB-approved form requires — REDCap does not enforce field order or completeness against the approved paper version; that alignment is the study team’s responsibility during instrument build, and it is worth a second reviewer checking the built instrument against the approved consent document line by line before go-live.

3. Chain it into the study with the Survey Queue

The eConsent instrument itself only handles consent capture. To make later study surveys conditional on having consented, use REDCap’s Survey Queue (a project-level setting, separate from the eConsent Framework) to sequence instruments and set display logic on downstream surveys keyed to the consent field’s value — e.g., a data-collection survey configured not to appear in the queue unless the consent instrument’s signature field is complete. This queue logic has to be built deliberately; simply enabling eConsent on the first instrument does not automatically block access to the rest of the project.

What happens after submission: the archived PDF

The auto-generated PDF is the part of the Framework that does the most real compliance work, and it’s worth understanding precisely what it is. It is a rendered copy of the instrument exactly as completed and signed — including the drawn signature image, and the values of any fields on the same instrument (name, date fields, etc.) — saved to the project’s File Repository and attached to that record at the moment of submission. Because it’s a static rendering rather than a live view of the underlying data, it stays defensible even if the instrument’s field labels or logic are later changed in the Online Designer: the archived copy shows what the participant actually saw and signed, not what the form currently looks like. That distinction — a locked, submission-time artifact versus a live, editable record — is the practical reason this feature satisfies more of Part 11’s electronic-record requirements than a signature field alone would.

21 CFR Part 11: what it satisfies

21 CFR Part 11 governs electronic records and electronic signatures for FDA-regulated research; its requirements sit across three subparts, and the eConsent Framework’s design maps onto specific ones:

• 11.50 (Signature manifestations) requires a signed electronic record show the signer’s printed name, the date/time of signing, and the meaning associated with the signature (e.g., that it represents consent). The auto-archived PDF, timestamped at submission, satisfies the record-content half of this if the instrument’s fields (name, date, a clear consent statement) are built to capture it — REDCap doesn’t guarantee this content is present; the instrument design has to include it.
• 11.10(e) (Audit trails) and the broader 11.10 record-protection controls are supported by REDCap’s project-level logging, which records who created/edited the consent record and when.
• 11.70 (Signature/record linking) is addressed by the fact that the signature is captured on, and archived within, the same locked PDF as the consent content itself, rather than as a separate detachable record.

What it does not automatically satisfy:

• 11.10(a) (System validation) and 11.100 (identity verification and the written certification to FDA that electronic signatures are the legal equivalent of handwritten ones) are institution-level obligations, not something REDCap-the-software can certify on a study’s behalf. Whether a given REDCap instance meets these depends on how the hosting institution validated and administers that instance — REDCap’s own documentation frames Part 11 support as a platform capability, not a compliance guarantee (see CASRAI’s REDCap entry and 21 CFR Part 11 compliance checklist for the full clause-by-clause picture).
• 11.300 (identification-code/password controls) — REDCap’s login and account-management controls have to be configured to these standards by the institution’s REDCap administrator; the eConsent Framework itself doesn’t touch authentication.

In short: the Framework gives a study the record-and-signature mechanics Part 11 expects, but Part 11 compliance is a property of the validated, administered instance the study runs on, not a checkbox the Framework flips on its own.

45 CFR 46 (Common Rule): what still needs IRB sign-off separately

This is the distinction most worth getting right, because it’s easy to conflate “the signature is captured electronically and compliantly” with “the consent process is IRB-compliant.” They are governed by different sections of the same regulation, and the eConsent Framework only reaches one of them.

• 45 CFR 46.116 sets the substantive requirements for the consent process itself: the content has to be comprehensible, disclose the required elements (purpose, risks, benefits, alternatives, confidentiality, voluntariness), and be presented in a way that gives the participant a genuine opportunity to consider it. Nothing about switching a paper form to a REDCap eConsent instrument changes whether the content clears this bar — the IRB has to review and approve the actual consent language exactly as it would for a paper form, and re-review it if the electronic version reflows the same content differently (e.g., pagination, how much is visible before the signature field).
• 45 CFR 46.117 is the documentation requirement — this is the part the eConsent Framework’s signature field and archived PDF actually address, since 46.117 is specifically about how consent is recorded, separate from the consent process itself.
• The Framework does not decide, on its own, whether a given study can even use electronic consent at all, whether a witness signature is required, whether assent (for a study enrolling minors, see the Common Rule’s Subpart D protections) needs a separate capture step, or how a participant without reliable technology access is accommodated — all of that is the IRB’s determination as part of protocol review, not a REDCap configuration choice.

Practically: building the consent instrument in REDCap is an implementation step that happens after the IRB has approved the consent form’s content and the study’s electronic-consent method, not a substitute for that review. Submit the built instrument (or screenshots of it) to the IRB as the actual electronic consent document being used, not just the underlying paper-form text — a functionally different presentation format is a real change the IRB needs to see, per the same logic that governs any consent-form modification. See CASRAI’s informed consent process guide for how this fits into the broader consent workflow, and Electronic Data Capture (EDC) for how REDCap’s eConsent function relates to its broader EDC role.

A short checklist before go-live

1. Consent instrument built as a survey, eConsent Framework enabled on that instrument specifically.
2. Signature field placed after all disclosure content, instrument checked field-by-field against the IRB-approved consent language.
3. Survey Queue display logic configured so dependent instruments require a completed consent signature — verified by testing as a test participant, not assumed.
4. Confirm with the REDCap administrator (institutional, not project-level) that the hosting instance’s validation, access controls, and audit configuration meet the institution’s own Part 11 posture — this is outside what any individual project can configure.
5. IRB has reviewed and approved the actual built instrument (not just the source consent text) as the electronic consent method, including any witness, assent, or accessibility accommodations the protocol requires.

Frequently asked questions

Does enabling the eConsent Framework make a REDCap project 21 CFR Part 11 compliant?

No. It provides the signature-capture and locked-record mechanics Part 11 expects on a consent document, but full compliance also depends on how the hosting REDCap instance is validated, administered, and access-controlled — obligations that sit with the institution, not the Framework setting itself.

Does the eConsent Framework need separate IRB approval?

The Framework itself is a REDCap configuration choice, but the electronic consent instrument it produces is the actual document participants see and sign — the IRB needs to review and approve that built instrument as the study’s consent method, the same way it reviews a paper form.

What’s the difference between the eConsent Framework and REDCap’s Survey Queue?

The eConsent Framework is a per-instrument setting that adds signature capture and PDF archiving to a single consent survey. The Survey Queue is a separate, project-level feature that sequences multiple surveys and can gate later ones on an earlier one’s completion — it’s what makes “no further surveys until consent is signed” work, and it has to be configured independently of the eConsent Framework itself.

Can the eConsent Framework be used outside clinical trials?

Yes. The underlying mechanism — a signed, PDF-archived survey instrument — works for any study needing a durable, tamper-evident consent record, including non-clinical human-subjects research governed only by the Common Rule rather than FDA regulations.