Protocol planning
Protocol Amendment and Deviation Log for Systematic Reviews
Record what changed after systematic reviews protocol approval or registration, when it changed, why it changed, who approved it, and how the change affects analysis and reporting.
A protocol only protects a review if its later changes stay visible
Most reviews change course at least once after the protocol is approved or registered. What matters is not that the change happened, but whether the record still shows the original plan, what changed, why, when, who signed off on it, and what it did to the review.
Good reasons for change come up constantly. A pilot round of screening exposes an eligibility rule nobody had thought to define precisely. A database goes offline right before the final search. The included studies turn out too heterogeneous for the meta-analysis the team had planned. None of that is a problem by itself. The problem starts when someone overwrites the original protocol file, keeps only the final version of a method, or tries to reconstruct the reasoning from memory while writing the manuscript.
PRISMA-P asks protocol authors to say in advance how they will document important amendments, and PRISMA 2020 asks the finished review to explain any changes to what was registered or originally planned.12 A version number alone doesn’t satisfy that. A reader should be able to tell whether the team made the call before or after seeing study results, who approved it, and which parts of the review had to be redone.
Lost chronology
Once the original protocol is overwritten, there’s no way to show what the team actually planned before the change.
Hidden knowledge
A one-line reason doesn’t tell anyone whether results or effect direction may have shaped the decision.
Document drift
The registry, working files, analysis scripts and manuscript quietly start describing three different methods.
This log gives you one continuous audit trail, from the first proposed change through to final reporting. Use the summary table to track every event at a glance, then fill out a full detailed record for anything substantive — copy that record block in the editable Word version if you have more than one change to log. For the reasoning behind each field, see the paired guide, Protocol Amendments and Deviations in Systematic Reviews: What to Record and Report.
Protocol amendment and deviation log
Log the event while the decision is still fresh and traceable. Leave the approved protocol untouched, give the revised method its own version number, and make sure every affected record gets reconciled.
1. Identify the review and control the record
Use the same identifiers everywhere — protocol, registry, this log and the final report.
2. Classify the event before you touch the method
Different organisations use these words differently. Decide how your team uses them, write that down, and then describe the event in plain language regardless of label.
Amendment
The team approves a change to the protocol or registration, ideally before applying the revised method.
Deviation
What actually happened in the review differs from the approved plan — whether by choice, error or circumstance.
Clarification or correction
Wording gets tidied up or an error gets fixed, with no real change to the methodological decisions. Check that this is actually true before you file it here.
Non-implementation
A planned method can’t be carried out because the condition it depended on never showed up, or using it would mislead readers.
If the edit changes which records, outcomes, data, judgements or analyses the team accepts or performs, treat it as a methodological change — not a cosmetic clarification.
3. Keep a running summary log
Give every event a stable ID here, then put the full reasoning in the detailed record below.
| ID | Date identified | Class | Review stage | Short description | Status |
|---|---|---|---|---|---|
4. Fill out one detailed record per event
If your review has more than one change, copy this block in the editable Word file for each additional entry.
Detailed change record
5. Reconcile and close the event
An event is only closed once the decision, the working files, the public record and the final report all tell the same story.
Protocol record
Keep the approved version and its dated successor side by side. Never quietly swap out the historical file.
Public record
Follow whatever procedure your registry or repository currently uses, and hold onto its permanent link.
Review report
Describe the change somewhere readers can actually compare the planned and completed methods. Point to a full log in the supplement if it helps.
Important: Anything you type into this webpage is temporary and can disappear on reload. Use the editable Word version as your controlled project record, or print this page with your browser’s Print command for a working copy.
A short log works fine, as long as each entry carries real evidence
Every field here exists to help someone reconstruct the decision later. The date and stage pin down the chronology. The original and revised methods show exactly what changed. The knowledge declaration lets a reader judge whether the team’s own results might have shaped the choice. The impact assessment stops a small local edit from leaving inconsistent decisions scattered elsewhere in the review.
Keep the effort proportionate to the change. A typo fix probably needs one short line. A change to eligibility, outcomes or synthesis deserves the full record. AMSTAR 2 treats the justification of significant protocol deviations as part of critical appraisal,5 and selective after-the-fact changes to outcomes are a well-documented way that published reviews end up distorted — which is exactly why documenting things as they happen, and reporting them plainly in the final review, matters so much.89
Registry rules aren’t fixed, and they differ by platform. PROSPERO and OSF each run their own process for updating a registered record,67 so check current platform instructions before you submit anything. Whatever terminology a given platform uses, keep the thread connecting your change log, your revised protocol and your final review intact.
Get every MetaSyn template free, including this one.
Leave your email and I’ll send this resource as an editable Word file and a printable PDF, plus access to the smart online version. You’ll also get every new template as it’s finished. No noise, just the resources.
- Shamseer L, Moher D, Clarke M, et al. Preferred reporting items for systematic review and meta-analysis protocols (PRISMA-P) 2015: elaboration and explanation. BMJ. 2015;350:g7647. doi:10.1136/bmj.g7647
- Page MJ, Moher D, Bossuyt PM, et al. PRISMA 2020 explanation and elaboration: updated guidance and exemplars for reporting systematic reviews. BMJ. 2021;372:n160. doi:10.1136/bmj.n160
- Page MJ, McKenzie JE, Bossuyt PM, et al. The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ. 2021;372:n71. doi:10.1136/bmj.n71
- Cumpston M, Lasserson T, Flemyng E, Page MJ. Chapter III: Reporting the review. In: Higgins JPT, Thomas J, Chandler J, et al., editors. Cochrane Handbook for Systematic Reviews of Interventions. Current version. Cochrane. Current chapter
- Shea BJ, Reeves BC, Wells G, et al. AMSTAR 2: a critical appraisal tool for systematic reviews that include randomised or non-randomised studies of healthcare interventions, or both. BMJ. 2017;358:j4008. doi:10.1136/bmj.j4008
- Centre for Reviews and Dissemination. PROSPERO frequently asked questions. University of York. Current PROSPERO guidance
- Center for Open Science. Welcome to registrations. OSF Support. Current OSF registration guidance
- Kirkham JJ, Dwan KM, Altman DG, et al. The impact of outcome reporting bias in randomised controlled trials on a cohort of systematic reviews. BMJ. 2010;340:c365. doi:10.1136/bmj.c365
- Page MJ, McKenzie JE, Kirkham J, et al. Bias due to selective inclusion and reporting of outcomes and analyses in systematic reviews of randomised trials of healthcare interventions. Cochrane Database of Systematic Reviews. 2014;(10):MR000035. doi:10.1002/14651858.MR000035.pub2