Skip to content

Below is a concrete “table-top exercise” stress test for a protocol amendment that triggers (a) re-consent and (b) a jsPsych battery change, using your sidebar IA and the role visibility model (CRC, PI, DM, Monitor, Safety). I am assuming an ODM-informed system where metadata versions are first-class and assessments are linked to StudyEventDef.

Stress Test Scenario

Amendment

  • Protocol Amendment v2.0 approved by REB/IRB.
  • Requires re-consent for all active participants because:
  • New data use clause (or new risk disclosure).
  • Requires ** battery change :**
  • Battery “Cognition v1” is replaced with “Cognition v2” (new module + scoring update).
  • Effective starting Visit 3 onward.
  • For participants who have not yet done Visit 3: use v2.
  • For participants who already completed Visit 3 under v1: do not change retroactively (unless protocol says otherwise).

Core risks this stress test probes

  1. Version drift: participants completing assessments under the wrong battery version.
  2. Consent mismatch: data collected under v2 without updated consent.
  3. In-flight sessions: participant starts battery v1, amendment goes live mid-session.
  4. Audit and provenance: inspectors ask “who approved what, when; what data was collected under which versions.”
  5. Export integrity: ODM/SDTM exports are consistent with versions and consent.

Required Platform Capabilities (Pass/Fail Criteria)

A. Versioned governance with effective dates

  • Study Design / Metadata Versions supports:
  • Draft → Review → Approve → Publish
  • Effective date/time (or immediate publish with cutover rules)
  • Diff view highlighting impacted Events/Forms/Batteries/Items
  • Re-consent must be enforced such that:
  • For events requiring consent v2, data entry/assessments are blocked until consent is completed (or explicitly waived if allowed)
  • Every assessment result is associated with the consent version in effect at time of capture

C. Assessment/battery version binding

  • Every delivered assessment instance records:
  • Battery ID + Battery Version
  • Module versions (if applicable)
  • Study metadata version
  • Linked StudyEvent instance

D. Non-destructive change handling

  • Data collected under v1 remains valid, immutable (subject to normal query workflows).
  • New collection is under v2.

E. Auditability

  • Signed approvals for:
  • Metadata Version publication (PI)
  • eConsent version activation (PI)
  • Audit trail records operational actions:
  • resend/remind, reopen, overrides, exception reasons

Step-by-Step Workflow by Role

1) Data Manager prepares the amendment (Configure)

DM actions

Configure → Study Design

  • Update StudyEventDefs / visit schedule rules:
  • Mark Visit 3+ as requiring “Consent v2” (or a “Consent Required” flag tied to version)
  • Update assessment binding:
  • Event Linking changes Visit 3 battery from “Cognition v1” to “Cognition v2”

Configure → Assessments Designer

  • Create/activate “Cognition v2”
  • Define compatibility rules:
  • If participant has scheduled Visit 3 but not started battery: deliver v2
  • If battery instance already delivered (queued) under v1: either
    • auto-cancel and re-issue v2 (with audit), or
    • allow completion of v1 only if protocol permits
  • This must be explicit and configurable; do not improvise at runtime.

Configure → eConsent Designer

  • Create Consent Form v2, language variants, signature requirements
  • Define triggers:
  • Required for all active participants
  • Required before any Visit 3+ activity (data entry or assessments)

Configure → Metadata Versions

  • Create metadata version “Amendment v2.0”
  • Generate diff showing:
  • new consent version binding
  • battery change
  • any new variables/items

System validations (hard requirements)

  • Warn if:
  • Battery v2 adds new Items not mapped to ODM ItemDefs
  • Battery v2 changes scoring definitions without version increment
  • Visit schedule refers to a battery version not published
  • Consent gating is not defined for impacted events

Outcome: DM prepares a publish-ready metadata package.

2) PI approves (Configure)

PI actions

Configure → Metadata Versions

  • Review diff
  • Confirm governance checklist:
  • consent version ready
  • battery version ready
  • cutover rules defined
  • Approve + Sign metadata version publication

Configure → eConsent Designer

  • Approve + Sign consent v2 activation

Outcome: approvals are captured and immutable.

3) Cutover occurs (System behavior)

At publication time, the system performs:

A. Participant segmentation

Create cohorts:

  • Cohort A: active participants who have not re-consented (need action)
  • Cohort B: participants with Visit 3 scheduled but not yet completed
  • Cohort C: participants mid-battery or with delivered-but-not-started battery instances
  • Cohort D: participants already past Visit 3 (no change unless protocol says)

B. Queue reconciliation rules (Assessments)

For each participant:

  • If battery instance not started and battery version changed:
  • cancel old instance (audit event)
  • generate new instance under v2 (audit event)
  • If in progress:
  • either allow completion (if allowed), or force restart (if required)
  • both require explicit protocol-configurable policy, not ad hoc
  • Any attempt to:
  • open Visit 3 forms, or
  • start Visit 3 battery is blocked until consent v2 completed (unless override policy exists).

CRC actions

Study → eConsent

  • Worklist:
  • Not started / sent / viewed / signed / failed / expired
  • Trigger sends/reminders (RBAC-controlled)
  • Resolve failures (identity mismatch, device issues, etc.)
  • Document exceptions (if allowed): “participant unreachable,” “withdrawn,” etc.

Study → Participants

  • Participant card shows:
  • Consent status: v1 signed, v2 pending/signed
  • “blocked activities” banner: “Visit 3 locked pending re-consent”
  • CRC can contact participant, initiate re-consent flow.

Study → Assessments

  • Worklist shows:
  • which version is queued (v2)
  • any cancellations/reissues
  • CRC can resend/remind after consent completed.

System guardrails (critical)

  • CRC cannot “force unlock” assessment without:
  • explicit override permission + reason + audit
  • Consent must be completed before assessment start if gating applies.

Outcome: re-consent progresses without version leakage.

5) Monitor verifies compliance (Study)

Monitor actions

Study → Queries & Safety

  • Focus: protocol deviations and consent compliance
  • Verify:
  • participants did not complete Visit 3 battery without consent v2
  • any overrides have documented reasons

Study → Audit Trail (via Reports & Exports)

  • Review audit for:
  • metadata publication approval
  • consent activation approval
  • battery cancellations/reissues
  • overrides

What a monitor expects to see (UI requirement)

  • A “Amendment v2.0 compliance” report:
  • list of active participants, consent status, visit status, assessment version status
  • Drill-down from a participant to:
  • exact consent form version signed
  • battery instance version delivered/completed

Outcome: monitoring is feasible without system access beyond read/query management.

6) Data Manager locks and exports (Study)

DM actions

Study → Data Review

  • Confirm all impacted Visit 3 data is under correct versions
  • Review missingness and out-of-window
  • Ensure coding impact handled if new AE-related fields exist
  • Freeze and prepare lock

Study → Reports & Exports

  • Export ODM / SDTM-ready packages that include:
  • consent version metadata
  • assessment battery version metadata
  • clear provenance for amendment effective date

Outcome: exports are coherent and inspection-ready.

Common Failure Modes and Required UI/Policy Fixes

Failure Mode 1: Participant completes v1 battery after amendment

Prevent by

  • Queue reconciliation + consent gating at launch time
  • Assessment start checks:
  • “is this battery instance still valid under current metadata?”
  • “is required consent version signed?”

Prevent by

  • Automatic invalidation/reissue of queued assessments at publication time
  • Clear UI indicator: “Superseded by v2, reissued on Jan X”

Failure Mode 3: Mid-session amendment breaks assessment

Handle by explicit policy

  • “Allow completion if started pre-cutover” vs “terminate and restart”
  • UI must show “in-progress at cutover” list, with DM adjudication if needed

Failure Mode 4: Data review cannot reconcile versions

Prevent by

  • Storing version identifiers on every record:
  • MetadataVersionID
  • ConsentVersionID
  • BatteryVersionID

Failure Mode 5: Auditors ask “who approved and when?”

Prevent by

  • PI-signature events for:
  • metadata publication
  • consent activation
  • Immutable audit records accessible via Audit Trail

Minimal UI Additions That Make This Smooth

  1. Amendment Cutover Dashboard (DM + PI + Monitor)
  2. participants pending re-consent
  3. assessments reissued
  4. blocked events
  5. overrides
  6. Participant “Version Strip” on profile
  7. Consent: v1 signed, v2 signed/pending
  8. Current metadata version applied
  9. Next scheduled event version binding
  10. Assessment instance banner
  11. “Battery Cognition v2 (effective Jan X)”
  12. “Supersedes Cognition v1 instance #…”
  13. Override workflow
  14. restricted permission
  15. mandatory reason
  16. audit logged
  17. appears in monitoring report

Bottom Line

Your IA and role visibility model will handle this scenario well if you enforce three non-negotiables:

  1. Consent gating at the point of data capture and assessment launch
  2. Explicit version binding (metadata, consent, battery) stamped on every instance
  3. Automatic queue reconciliation at publication time with auditable events