What a scoping review of eConsent criteria actually covers
Electronic informed consent has moved from a novelty to a default option for a large share of studies, but the criteria ethics committees actually use to review an eConsent process haven't settled into a single, widely agreed standard. A scoping review of the published criteria makes this fragmentation visible, pulling together the range of things different guidance documents and review bodies actually check for.
Why this matters beyond the review itself
An ethics committee approving an eConsent process is making a judgement about whether a digital interface delivers the same protections a well-run paper consent conversation would. That's a harder thing to assess consistently than it sounds, because a digital consent flow introduces failure modes a paper form simply doesn't have: a participant who clicks through screens without reading them, a comprehension check that can be gamed by guessing, a process that technically discloses everything but structures it in a way nobody actually absorbs.
What the review found committees actually look for
Pulling together criteria across the sources it examined, a few recurring themes show up consistently:
- Genuine comprehension verification, not just an "I agree" checkbox. Some form of active confirmation that the participant understood key points, rather than assuming reading equals understanding.
- Accessibility of the interface itself, readable font sizes, navigable structure, compatibility with assistive technology, treated as part of the consent process's validity, not a separate accessibility concern.
- A genuine, accessible route to ask questions, not buried behind several screens or requiring a separate, harder-to-find contact method.
- Security and identity verification appropriate to the sensitivity of what's being consented to, without adding so much friction that participants disengage before completing the process.
- A clear record of exactly what was presented and when, so that if a protocol or consent document is updated, there's an auditable record of which version a given participant actually saw.
What a weak implementation looks like next to a strong one
Each criterion sounds reasonable in the abstract. It's more useful to see what a version that technically satisfies it, but doesn't really deliver on its intent, looks like next to one that does.
| Criterion | Technically present but weak | Actually delivers on the intent |
|---|---|---|
| Comprehension verification | A single "I have read and understood" checkbox at the end | Two or three specific questions about key risks, answered before proceeding |
| Accessibility | Content is technically screen-reader compatible but never tested with an actual assistive-technology user | Tested with participants who genuinely rely on the accessibility features |
| Route to ask questions | A contact email exists, buried in a footer three screens deep | A visible, one-tap contact option on every screen of the flow |
| Security appropriate to sensitivity | The same login step regardless of what's being consented to | Verification scaled to the sensitivity of the specific consent, lighter for a low-risk survey, stronger for genetic data |
| Version record | The current consent document is stored | Every version a participant was shown is stored, timestamped, and linked to that specific participant |
The gap in every row is the same: the weak version satisfies the letter of the criterion with the minimum viable implementation, while the strong version was built around what the criterion is actually trying to protect against. A reviewer working from a checklist can sometimes only tell the difference by testing the flow itself, not by reading a description of it, which is itself part of why review outcomes vary so much between committees looking at ostensibly similar systems.
Why the lack of a single standard is itself a problem
A study running across multiple sites, or multiple countries, can find itself navigating meaningfully different eConsent expectations from different ethics committees, not because the underlying ethical principle differs, but because each committee has developed its own working criteria in the absence of a single unified standard. That's an operational headache, but it's also a signal that the underlying question, what actually constitutes valid consent when the format is digital, is still being worked out in practice rather than settled in policy.
What a study team can reasonably do about it
Given the lack of a single standard, the practical approach is to build an eConsent process that would satisfy the strictest, most thorough version of these criteria, rather than the minimum any one committee happens to require:
- Build genuine comprehension checks into the flow, specific questions about key risks and procedures, not a single blanket acknowledgement.
- Test the interface itself for accessibility, not just the content, with real participants representative of who will actually use it.
- Keep a clear, versioned record of what was shown to each participant, so a protocol amendment doesn't leave ambiguity about what an earlier participant actually consented to.
- Make the question-asking route genuinely easy to find, not technically present but three screens deep.
The underlying principle
None of this is really about technology. It's the same question informed consent has always asked, did the participant actually understand what they were agreeing to, applied to a format where it's easier than paper to create the appearance of disclosure without the substance of it. A scoping review that surfaces just how much variation exists in how committees currently check for this is a useful reminder that a technically compliant eConsent flow and a genuinely good one aren't automatically the same thing.