This is the task-level companion to the Log: ICF Version Control and Re-Consent Tracking. That log tracks who still needs re-consenting after an amendment; this instruction is how the session itself is run, remote, in person, or hybrid, so the conversation is consistent regardless of who is holding the tablet. Replace every <<FILL: ...>> placeholder and route it through document control. A filled specimen follows. This content is general educational reference, not legal or regulatory advice.
Control header
| Field | Entry |
|---|---|
| Document title | Conducting a Participant Re-Consent Session |
| Document number | <<FILL: WI-ID, e.g. WI-CLIN-031>> |
| Version | <<FILL: version>> |
| Effective date | <<FILL: date>> |
| Parent SOP | <<FILL: SOP-ID for informed consent process>> |
| Related log | ICF Version Control and Re-Consent Tracking, <<FILL: reference>> |
| Owner | <<FILL: role, e.g. Clinical Trial Lead>> |
Purpose
To re-consent an already-enrolled participant after a protocol amendment or new safety information in a way that confirms actual understanding of what changed, captures a properly bound signature under the new informed consent form (ICF) version, and leaves a complete record, before the participant undergoes any procedure the amendment gates.
Scope
Applies whenever the IRB/IEC determination on an amendment requires re-consenting already-enrolled participants, regardless of modality (remote eConsent session, in-person tablet presentation, or hybrid remote presentation with site countersignature). Does not cover first-time consent of a newly enrolling participant, which follows the parent SOP’s standard consent process.
Prerequisites
- The amendment and its electronic materials are IRB/IEC-approved and loaded in the eConsent system.
- The participant appears in the version control log as “re-consent pending,” with the specific change identified (new risk information, new procedure, revised schedule, or other).
- The re-consent session is scheduled before the participant’s next procedure gated by the amendment.
- The person conducting the session has the delegated authority to obtain consent under the trial’s delegation log.
Procedure
| Step | Action | Per-step acceptance |
|---|---|---|
| R1 | Confirm from the version control log that this participant is flagged “re-consent pending” and identify exactly what changed in the new ICF version. | Correct participant and correct amendment identified; the specific change is named, not just “new version.” |
| R2 | Contact the participant to schedule the session before their next gated procedure. | Session scheduled; if the participant cannot be reached within <<FILL: window, e.g. 5 business days>>, escalate per the parent SOP rather than letting the procedure proceed under the old version. |
| R3 | At the start of the session, confirm the participant’s identity using the same method used for their original consent. | Identity confirmed and recorded in the audit trail or session note. |
| R4 | Present a summary of what changed, pointing directly to the new or revised section rather than reopening the full document from page one. | Participant has seen or heard the specific change, not just been handed the whole ICF again. |
| R5 | Ask the participant to restate, in their own words, what changed and what it means for them (teach-back), rather than relying only on a knowledge-check score. | Participant can explain the change; if they cannot after reasonable discussion, do not proceed to step R6. |
| R6 | If the participant agrees to continue, capture the signature under the new ICF version with the same metadata as original consent: signer name, date/time, and the meaning of the signature. | Signature captured and bound to the new version, not the superseded one. |
| R7 | If the participant does not agree to continue under the new version, stop any procedure gated by the amendment and notify the investigator the same day. | Non-agreement is handled as a withdrawal-scope conversation using the Form: Consent Withdrawal Scope and Downstream Data-Handling Record, not left open with no documented outcome. |
| R8 | Update the version control log with the outcome (re-consented, declined, or pending further discussion) the same day. | Log entry current; no participant left showing “pending” after the session actually occurred. |
| R9 | Provide the participant a copy of the newly signed ICF. | Copy delivered and the delivery recorded. |
Special situations
- Legally authorized representative (LAR) re-consent. Apply the identity, relationship, and basis-of-authority checks described for proxy consent in the parent article; a change in who is signing (a new LAR, or a minor who has reached the age of majority and must now consent in their own right) is itself a scheduled transition, not a routine re-consent.
- Participant unreachable past the escalation window. Follow the parent SOP’s lost-to-contact procedure; do not allow a gated procedure to occur under the superseded version while the participant remains unreached.
- Remote-only session. Confirm connectivity supports the full session before starting; a dropped call mid-session is handled per the connectivity-loss behavior validated for the eConsent system, not improvised.
Per-step acceptance summary
The session is acceptable when: the participant’s identity was confirmed, the specific change was presented and explained (not buried in a full re-read), teach-back confirmed actual understanding, the outcome (agreement or decline) was captured with correct signature metadata or routed to the withdrawal-scope conversation, the version control log was updated the same day, and a copy was delivered where consent was obtained.
Record generated: re-consent session note
| Field | Format | Required | Who | When |
|---|---|---|---|---|
| Participant ID and site | Text | Yes | Conductor | At session |
| Amendment / new ICF version | Text | Yes | Conductor | At session |
| Session modality | Remote / in-person / hybrid | Yes | Conductor | At session |
| Identity confirmation method and result | Text | Yes | Conductor | At session start |
| Teach-back outcome | Pass / needs further discussion | Yes | Conductor | During session |
| Outcome | Re-consented / declined / pending | Yes | Conductor | End of session |
| Copy delivered (if re-consented) | Yes/No | Conditional | Conductor | End of session |
| Conductor name and date | Text | Yes | Conductor | At session |
Retain per the records retention schedule, not less than <<FILL: retention period>>.
Filled specimen
A daily pain diary study amends the ICF to add a new, uncommon but serious risk identified from blinded safety data. Illustrative only.
| Field | Entry |
|---|---|
| Participant / site | 07-022, Site 07 |
| Amendment / version | v2.1-EN, new safety section 4.3 |
| Modality | Remote video session |
| Identity confirmation | Video identity check against enrollment photo, matched |
| Teach-back outcome | Pass: participant restated the new risk and the symptom to report immediately |
| Outcome | Re-consented |
| Copy delivered | Yes, emailed same session |
| Conductor / date | R. Nkemelu, CRC, 2026-09-18 |
The participant initially described the new risk incorrectly; the conductor paused, re-explained using the plain-language summary, and confirmed understanding before proceeding to signature. That pause, not skipping to the signature on the first pass, is what the teach-back step is for.
Common inspection findings this instruction prevents
- A re-consent signature captured with no evidence the participant understood what changed, only that they clicked through a document a second time.
- A participant shown “pending” in the tracking log for weeks after the session actually happened, because the log update was never tied to the session itself.
- A gated procedure performed before re-consent was obtained, because no one checked the escalation window.
- A participant who declined re-consent left with no documented next step, instead of a routed withdrawal-scope conversation.
How to adapt this instruction
- Set the document number, parent SOP, and the version control log reference in the header.
- Point the escalation window in step R2 to your program’s real contact-attempt policy.
- Add a translated-session variant if re-consent sessions are run in multiple languages; the teach-back check still applies in each language.
- Confirm the signature metadata captured in step R6 matches exactly what your validated eConsent system records for original consent.