Skip to content

SOP: Protocol Amendments Requiring Re-Consent and Assessment Changes

SOP ID: EDC-AMEND-001

Version: 1.0

Effective Date: [To be completed]

Supersedes: N/A

Applies to: All clinical studies managed within the EDC platform

Scope: Protocol amendments that require participant re-consent and/or changes to participant-completed assessments (e.g., jsPsych batteries)

1. Purpose

To define a controlled, auditable process for implementing protocol amendments that require:

  • Re-consent of active participants, and/or
  • Changes to assessment instruments (including jsPsych batteries)

while ensuring:

  • Regulatory compliance
  • Data integrity and provenance
  • Participant protection
  • Inspection readiness

2. Definitions

  • Amendment: A formal change to an approved study protocol.
  • Metadata Version: A versioned definition of study structure, including visits, forms, assessments, and rules.
  • Assessment Battery: A structured collection of jsPsych modules delivered to participants.
  • Effective Date: The date/time at which amended metadata becomes active.
  • Cutover: The controlled transition from pre-amendment to post-amendment configuration.
  • Re-Consent: Participant signing of a new consent version required by an amendment.

3. Roles and Responsibilities

Data Manager (DM)

  • Authors metadata changes
  • Configures assessment and consent updates
  • Initiates amendment publication
  • Oversees data reconciliation and exports

Principal Investigator (PI)

  • Reviews and approves amendments
  • Provides electronic signature for:
  • Metadata publication
  • Consent activation
  • Data lock (if applicable)

Clinical Research Coordinator (CRC)

  • Executes re-consent at the participant level
  • Manages assessment delivery and follow-up
  • Documents exceptions and issues

Monitor (CRA)

  • Verifies amendment compliance
  • Reviews consent and assessment adherence
  • Raises queries for deviations

Safety Officer

  • Reviews safety-related implications
  • Ensures AE/SAE workflows remain compliant

4. Preconditions

Before initiating an amendment:

  • REB/IRB approval documentation must be available
  • Amendment impact analysis completed, including:
  • Affected visits/events
  • Affected assessments
  • Consent implications
  • Sponsor authorization (if applicable)

5. Procedure

Step 1: Amendment Preparation (Configure)

Responsible: Data Manager

  1. Update study configuration in Study Design:
  2. Modify affected Study Events (visits)
  3. Identify events requiring updated consent
  4. Update assessments in Assessments Designer:
  5. Create new battery version(s) as required
  6. Define compatibility rules for in-flight assessments
  7. Update consent documents in eConsent Designer:
  8. Create new consent version(s)
  9. Define triggers for re-consent (e.g., all active participants)
  10. Create a new ** Metadata Version :**
  11. Clearly label amendment identifier (e.g., “Protocol Amendment v2.0”)
  12. Generate system diff and review impacted objects

System Validation Checks (Required):

  • All new assessment outputs are mapped to ODM ItemDefs
  • Battery version increments for any structural or scoring changes
  • Consent gating rules defined for impacted events
  • No orphaned or unpublished references remain

Step 2: Review and Approval

Responsible: Principal Investigator

  1. Review metadata diff and amendment summary
  2. Confirm:
  3. Re-consent requirements are correctly configured
  4. Assessment changes align with protocol language
  5. Provide electronic signature to:
  6. Approve metadata version
  7. Activate new consent version(s)

Outcome: Amendment is approved and ready for publication.

Step 3: Publication and Cutover

Responsible: System (triggered by DM)

Upon publication:

  1. System timestamps amendment effective date/time
  2. Participants are segmented into cohorts:
  3. Pending re-consent
  4. Upcoming affected visits
  5. In-progress or queued assessments
  6. Assessment queue reconciliation occurs:
  7. Superseded battery instances cancelled (with audit)
  8. New battery instances issued as required
  9. Consent gating is enforced:
  10. Block data entry or assessments for events requiring re-consent
  11. Display clear status indicators to users

All actions are recorded in the audit trail.

Responsible: CRC

  1. Access Study → eConsent
  2. Initiate re-consent for affected participants
  3. Monitor consent status:
  4. Sent / Viewed / Signed / Failed / Expired
  5. Resolve issues:
  6. Identity verification failures
  7. Technical/device problems
  8. Document any protocol-permitted exceptions with rationale

System Guardrails:

  • Assessments and visit data collection remain blocked until re-consent is complete
  • Overrides require explicit authorization, reason entry, and audit logging

Step 5: Assessment Execution and Monitoring

Responsible: CRC, Monitor

  • CRC:
  • Sends/reminds assessments post-consent
  • Monitors completion and issues
  • Monitor:
  • Verifies no assessments were completed without valid consent
  • Reviews version correctness and deviations

Step 6: Data Review, Lock, and Export

Responsible: Data Manager, PI

  1. Review data completeness and version alignment
  2. Confirm:
  3. All post-amendment data collected under correct versions
  4. No unauthorized overrides occurred
  5. Initiate data freeze
  6. Obtain PI approval for data lock (if applicable)
  7. Generate exports with embedded provenance:
  8. Metadata version
  9. Consent version
  10. Assessment/battery version

6. Documentation and Audit Requirements

The following must be retained and accessible:

  • Amendment metadata diff
  • PI approval signatures
  • Consent versions and signatures
  • Assessment version history
  • Queue reconciliation logs
  • Override justifications
  • Complete audit trail

7. Deviations and Exceptions

  • Any deviation from this SOP must:
  • Be documented with rationale
  • Be approved according to study governance
  • Appear in monitoring and audit reports

8. Inspection Readiness Checklist

✔ Metadata version published with PI approval

✔ Consent re-execution documented and complete

✔ Assessments delivered under correct version

✔ No data collected without valid consent

✔ Full audit trail available

9. Revision History

Version Date Description Approved By
1.0 TBD Initial release PI Name