Skip to content

Adopt a protocol amendment

Move from one approved Protocol Version to another without pretending the whole suite changes atomically or rewriting conduct that occurred under the previous version.

ProtocolVersion 1
-> ProtocolAmendment
-> ProtocolVersion 2
-> DomainImpactAssessment[]
-> CountryApprovalRequirement[]
-> ConsentImpactAssessment
-> ParticipantImpactAssessment[]
-> DomainAdoptionPlan[]
-> AdoptionDecision[]
-> ProtocolAssignment changes
  1. Protocol.approveAmendment(...) creates immutable Version 2 and the change relationship.
  2. Each affected domain assesses impact on its definitions, open work, occurrences, data, materials, decisions, and evidence.
  3. Startup determines required authority and ethics approvals by country/site.
  4. Consent determines whether and when reconsent is required.
  5. Participant Conduct determines applicability to each participant.
  6. EDC, eCOA, RTSM, laboratories, imaging, and eTMF prepare separate adoption plans.
  7. Authorized owners decide adoption and effective cutover.
  8. Participant ProtocolAssignment objects change only when applicable prerequisites are met.
  • Approval of the amendment does not automatically adopt it operationally.
  • Existing observations remain governed by their original definitions.
  • In-flight activities receive an explicit continue, cancel, replace, or migrate decision.
  • Different countries, sites, participants, and domains may temporarily use different versions.
  • The current applicable version must always be explainable for each participant activity.
  • Reconsent status does not silently rewrite the participant’s overall enrollment state.
  • What is the authority for a participant’s amendment applicability?
  • Can a participant permanently remain on the previous Protocol Version?
  • How are retroactive changes distinguished from corrections to protocol metadata?
  • Which downstream configuration changes require independent validation and approval?