Why Change Control Matters in an Adaptive Trial
Adaptive-trial documents do more than describe a study: they specify how information is interpreted and how decisions are made as the trial proceeds. A protocol may describe the adaptation; an analysis plan may define the analysis supporting it; a decision charter may specify who may act; and a simulation report may document evidence that the design performs as intended. If these documents change without coordinated control, a reader may be unable to tell which rule was approved, when it applied, or why it was revised.
Change control is the process for identifying, reviewing, approving, releasing, and preserving revisions to controlled documents. It is not simply saving a new file or adding tracked changes. Good control makes the document’s status and history understandable without relying on someone’s memory or on an informal email thread. The procedures below are good practice; applicable regulations, institutional procedures, and sponsor quality systems determine the binding requirements for a particular trial.
Separate Identity, Approval, Release, and Effectiveness
Several dates can matter for a single revision, and they should not be treated as interchangeable. The version identifier distinguishes one issue from another, for example “1.2” or “Amendment 3.” The approval date records when the required authority approved the document. The release date records when the controlled copy was issued or made available to the relevant users. The effective date states when the content applies to the study or a defined part of it.
A revision may be approved on one date and take effect later. For example, a revised analysis plan could be approved before an interim review but state that it applies only to data collected after a specified cutoff. Such a boundary must be explicit, justified, and consistent with the protocol and other governing materials. Do not infer an effective date from a file’s creation date, an approval signature, or the date someone circulated an attachment.
A useful controlled-document record identifies at least the document title and identifier, version, status, approval authority and date, effective date or applicability condition, and the location of the authoritative copy. Status labels should be unambiguous: “draft,” “under review,” “approved,” and “superseded” describe different states. A draft must not look like an approved instruction to trial staff.
Worked Example: Distinguishing the Relevant Dates
Suppose a hypothetical trial’s revised analysis plan is version 2.0. The statistical review is completed on 4 March, the authorized approver signs it on 7 March, the document-control group releases it on 10 March, and the plan states that it applies to the interim analysis using a data cutoff of 1 April. What should the controlled record say?
The version is 2.0; the approval date is 7 March; and the release date is 10 March. The applicability statement is not simply “effective 7 March.” It should say that version 2.0 governs the specified interim analysis based on the 1 April cutoff, if that is the approved intent. The record should preserve the 4 March review date if the document-control process tracks review completion.
This distinction prevents a reader from assuming that the new plan governed an analysis merely because it had been signed or circulated. The approval record establishes authorization; the explicit applicability condition establishes which analysis the plan governs.
Constructing a Useful Change Log
A change log should make each revision interpretable on its own. “Updated per discussion” is not a sufficient rationale: it does not identify what changed or the reason. A concise entry should state the section or requirement affected, the prior and revised content at an appropriate level of detail, the rationale, the documents affected or checked for consistency, the review and approval status, and the effective date or condition.
The rationale should explain the basis for the change, not merely repeat its wording. For example, “Clarified the data cutoff definition to remove ambiguity between database extraction and endpoint ascertainment” explains why a change was made. If the change affects an adaptation rule, the entry should identify the relevant rationale and supporting review, while leaving the detailed record of a particular adaptation decision to the appropriate study records.
A change log is not a substitute for the controlled document itself. The log points to the revision and summarizes it; the approved document contains the operative text. Similarly, tracked changes can help reviewers compare drafts, but a marked-up draft should not be confused with the clean approved version. Retain both when required by procedure, with clear status labels and a reliable link between them.
Worked Example: Writing a Change-Log Entry
In a hypothetical adaptive trial, version 1.0 of the decision charter says that the independent committee receives a report “after approximately 50% of planned information.” Reviewers identify that “approximately” and “planned information” do not specify a reproducible trigger. The approved revision defines the trigger as 50% of the planned information fraction, calculated using the prespecified event target. The protocol and analysis plan are checked for consistent wording.
A useful change-log entry could read: “Charter, section 4.2: replaced ‘after approximately 50% of planned information’ with the prespecified 50% information-fraction trigger based on the event target. Rationale: make the timing criterion operational and consistent with the protocol and analysis plan. Related documents checked: protocol 2.1 and analysis plan 1.3. Approved 12 May; effective for the interim review scheduled after the trigger is met.”
The entry states where the change occurred, what was clarified, why, which linked materials were checked, and how applicability is determined. If the protocol or analysis plan also requires amendment, those revisions need their own controlled versions and approval records; the charter log cannot silently amend them.
Control a Coordinated Document Set
Adaptive-trial documents are linked by their statements about design, analysis, decision authority, and supporting evidence. A change to one document can therefore create a consistency problem elsewhere even if the other document remains unchanged. Version control should preserve both the history of each document and a clear view of which versions were intended to operate together.
For each proposed revision, identify the affected documents and check whether their terminology, thresholds, timing, roles, and references still agree. This does not mean every change requires every document to be revised. It means the decision not to revise a linked document should follow an explicit consistency check, rather than an assumption that the change is local.
Record the affected document, section, current version, and the precise issue requiring revision.
Determine whether the change affects the protocol, analysis plan, charter, simulation report, or their cross-references. Record which documents were checked and why an amendment is or is not needed.
Obtain the reviews and approvals required by the applicable procedure. Keep draft status distinct from approved status, and resolve inconsistent wording before release.
Issue the authoritative version, state its effective date or condition, and communicate which version users should follow.
Retain superseded versions and their change records; ensure users can identify the current approved copy without mistaking an obsolete file for an operative instruction.
The logic of coordinated control can be expressed as a traceability chain: proposed change → documented rationale → reviewed and approved version → explicit applicability → preserved history. Each link answers a different question. The rationale explains why the revision exists; approval establishes authorization; applicability specifies when it governs; and preservation allows a reviewer to reconstruct the sequence. If one link is missing, the document set may no longer establish what instruction was authorized for a particular point in the study.
Worked Example: Revising a Simulation Report
Worked Example: Linking a Simulation Revision to Its Design Basis
A hypothetical trial’s simulation report, version 1.0, evaluates 10,000 simulated trials under the originally proposed adaptation rule. Before the design is finalized, the planned interim information fraction changes from 0.50 to 0.60. The team runs a new set of 10,000 simulations under the revised rule and issues report version 2.0. The simulated rejection proportion under a specified null scenario is 0.047 in version 1.0 and 0.049 in version 2.0.
The report should identify the design rule used for each simulation set and not present the two results as if they came from one unchanged design. The change log can state: “Simulation report, version 2.0: reran the prespecified simulation scenarios with the interim information fraction changed from 0.50 to 0.60. Rationale: evaluate the performance of the revised timing rule. Under the specified null scenario, the simulated rejection proportions were 0.047 for version 1.0 and 0.049 for version 2.0, each based on 10,000 simulated trials. The revised report supports protocol version 2.0 and analysis plan version 1.4.”
The arithmetic is straightforward: 0.047 corresponds to 470 rejections among 10,000 simulated trials, and 0.049 corresponds to 490 among 10,000. These are simulation estimates under the stated scenario, not exact guarantees of the trial’s error rate. The report should also identify its simulation assumptions and methods so a reviewer can interpret the estimates. Version 2.0 should state which design documents it evaluates, while version 1.0 remains preserved as evidence of the earlier design assessment.
This example illustrates why a simulation report’s version must be linked to the design version it evaluates. A new report cannot be interpreted correctly if it omits whether the adaptation rule changed, which scenarios were rerun, or which design documents define the simulated procedure.
Storage, Comparison, and Common Failure Modes
A controlled repository is generally safer than relying on individual computers or email attachments because it can provide a designated authoritative copy, access controls, status information, and version history. A document-management system is not the only possible mechanism, but whatever mechanism is used must reliably distinguish approved documents from drafts and preserve superseded versions. File names alone are weak controls: “final,” “final2,” and “final_revised” do not establish approval or applicability.
Comparison tools and tracked changes are useful for review, but they answer only “what text differs?” They do not establish why a change was made, whether it was approved, when it became effective, or whether related documents were checked. Conversely, a change log without access to the corresponding clean approved document is incomplete. The two tools serve complementary purposes.
- Overwriting the old file. This removes evidence of the earlier approved wording. Preserve the superseded issue and mark it clearly as no longer current.
- Using approval date as the effective date by default. Approval and applicability can differ. State the intended effective date or condition directly.
- Recording only “minor editorial change.” A change that appears editorial can alter a threshold, timing rule, role, or interpretation. Describe the substance and assess its impact.
- Updating one document but not its cross-references. Check linked documents for consistency and record the outcome, including when no other revision is required.
- Treating a simulation report as independent of design versions. Identify the exact design assumptions and document versions evaluated, so results are not attributed to a different design.
- Leaving drafts accessible as if they were approved instructions. Label status prominently and make the current authoritative copy easy to identify.
A practical diagnostic is to ask whether an informed reviewer, without asking the document author, can answer: Which version was approved? Who authorized it and when? What changed and why? When did the change apply? Which related documents were assessed? Where is the superseded version? If any answer requires guesswork, the control record needs improvement.
Limitations and Scope
Version control establishes document identity and history; it does not prove that a design is statistically valid, that an adaptation is appropriate, or that implementation followed the approved plan. Those questions require substantive review and study records. Likewise, a complete change log does not replace required regulatory submissions, ethics review, or local approval processes. The document-control process should make those dependencies visible, not imply that a log entry itself grants authorization.
The level of detail should be proportionate to the change but sufficiently specific to reconstruct it. A correction to a typographical error may need less explanation than a revision to an adaptation threshold. However, even a small change should not obscure whether the operative meaning changed. If there is uncertainty about whether a revision affects interpretation or study conduct, document the assessment and seek the review required by the applicable governance process.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A protocol amendment is approved on 2 June, released on 5 June, and states that it applies only after a specified interim cutoff on 20 June. Which date determines applicability?
- Why is “updated after team discussion” an inadequate change-log rationale?
- A revised simulation report uses a new adaptation threshold but cites the same protocol version as the earlier report. What should be checked before release?
- What is the main difference between tracked changes and a change log?
- A typographical correction is made in a charter. Must the change record still identify the revision and its status? Explain.
Solutions. (1) The explicit applicability condition governs: the revised protocol applies after the specified cutoff, subject to the approved wording and applicable procedures; approval and release dates alone do not determine this. (2) It does not say what changed or why, so a reviewer cannot assess the revision’s purpose or impact. (3) Check whether the cited protocol actually contains the new threshold; if not, reconcile the document set and identify the correct versions before release. (4) Tracked changes show textual differences; a change log records the reason, review and approval information, related-document assessment, and applicability. (5) Yes. The revision should remain identifiable and its status clear, even if the change is editorial, so users can distinguish controlled copies and the history remains interpretable.