yila-review-protocol

Writing a Review Protocol Before You Search

A review protocol is a short document written before the search that states what the review will do and how. It feels like paperwork, especially for students who want to get on with reading, but it is the single most effective protection against the problems that undermine reviews later: scope that drifts, criteria that change to fit the studies found, analyses chosen after seeing the data and a methods section reconstructed from memory. This guide explains what a protocol should contain, how to write one efficiently, when and where to register it, and how a source-linked assistant such as Yila can support the review that follows without replacing the decisions the protocol records.

Why write a protocol at all

A protocol does three things. It forces you to make decisions early, while you are still neutral about the results. It creates a record against which readers can compare the finished review, so that changes are visible and justified. And it saves time: the methods section of the final review is largely the protocol rewritten in the past tense.

Formal systematic reviews in health are expected to have a registered protocol, often on PROSPERO, and many journals now ask for one. Scoping reviews, rapid reviews and literature reviews in other fields benefit just as much, even if the protocol is only shared with a supervisor or posted on a repository such as OSF.

The core sections

Reporting guidance such as PRISMA-P lists many items, but most protocols can be organised around a handful of sections.

Background and rationale. In a few paragraphs, explain the problem, what existing reviews have found and why a new review is needed. Check for existing or ongoing reviews before writing this; duplicating a recent review without a reason is a common cause of rejection.

Question and objectives. State the review question precisely, using a framework such as PICO, PEO or SPIDER if it helps. List the specific objectives, including any secondary questions or subgroup comparisons.

Eligibility criteria. Define the population, the intervention, exposure or phenomenon, comparators, outcomes, study designs, settings, languages and date limits. Explain each limit: a date cut-off or language restriction should have a reason.

Information sources and search strategy. List the databases, registers and other sources, such as reference lists or grey literature. Include a draft search strategy for at least one database, ideally developed with a librarian, and say how it will be adapted for the others.

Study selection. Describe how many reviewers will screen at each stage, whether screening will be independent, how disagreements will be resolved and what software will be used.

Data extraction. List the data items to be extracted and describe the process: a piloted form, single or double extraction and how missing data will be handled, including whether authors will be contacted.

Risk of bias or quality assessment. Name the tool to be used for each study design and say how the assessment will inform the synthesis.

Synthesis. Describe how results will be combined: narrative synthesis, meta-analysis, thematic synthesis or another method. For meta-analysis, specify the effect measures, the model, how heterogeneity will be assessed and any planned subgroup or sensitivity analyses. For narrative synthesis, describe how studies will be grouped and compared.

Certainty of evidence and reporting. If relevant, state whether a framework such as GRADE will be used, and which reporting guideline the review will follow.

Amendments. Include a short section stating that any changes will be dated and explained in the final review.

Writing it efficiently

A protocol does not need to be long. For a student project, four to eight pages is usually enough. Start from a template, such as the PRISMA-P checklist or the PROSPERO form, and fill in each item briefly. Where a decision is not yet clear, make a provisional choice and mark it as such, rather than leaving the item empty.

Draft the search strategy early, because developing it often reveals problems with the question. If a search returns tens of thousands of records, the question is probably too broad; if it returns a handful, it may be too narrow or the terminology may need work. Revising the question at this stage is cheap. Revising it after screening is expensive and needs to be reported.

Ask someone outside the project, such as a colleague or librarian, to read the protocol. They will notice terms that seem obvious to you but are ambiguous to others.

Registering and sharing

Registration timestamps your plan publicly. PROSPERO accepts systematic reviews with a health-related outcome; for other fields, OSF Registries, institutional repositories or journals that publish protocols are good options. Register before you start screening. Some registries reject protocols once data extraction has begun.

If you do not register, at least save a dated version of the protocol and share it with your supervisor or team. A version-controlled document, a dated PDF or an email with an attachment all create a record.

Handling changes honestly

Reviews almost always deviate from their protocols in some way. A database becomes unavailable, an outcome turns out never to be reported, or a planned meta-analysis is not possible because studies are too different. Deviations are not a problem if they are recorded. Keep a short amendments log with the date, the change, the reason and whether the change was made before or after seeing results. Report the log in the final review.

The changes that damage credibility are the unreported ones: an outcome quietly switched, an inclusion criterion relaxed to admit a favourable study, an analysis chosen because it gave a cleaner result. A protocol makes these visible, which is exactly why it is valuable.

Where an assistant fits

The protocol is a set of decisions, and those decisions should be yours. An assistant can help with background reading, such as finding and summarising existing reviews on the topic, but the question, criteria and analysis plan need to be written and owned by the review team.

After the protocol is fixed and the studies are selected, the workload shifts to reading, extracting and drafting, and that is where a source-linked assistant earns its place. Yila is designed to turn papers and data into cited reviews, figures and slides, keeping each statement tied to the passage it came from. Working within the scope the protocol defines, it can produce draft summaries and syntheses whose claims link back to specific locations in the included studies, which makes it easier to check them against your extraction and risk-of-bias records before they enter the review.

A protocol checklist

• Background and rationale, including a check for existing reviews.
• A precise question and objectives.
• Eligibility criteria with reasons for every limit.
• Sources and a draft search strategy for at least one database.
• Screening and extraction procedures, including the number of reviewers.
• Risk-of-bias tools for each design.
• A synthesis plan with planned subgroup and sensitivity analyses.
• An amendments section and a dated version, registered if possible.

Conclusion

Writing a protocol before searching takes a few days and saves weeks. It turns implicit choices into explicit ones, gives readers a benchmark for the finished review and makes the methods section almost write itself. Combined with a reading and drafting workflow that keeps every claim linked to its source, whether by hand or with an assistant like Yila, it is what lets a review show not only what it found but that it found it the way it said it would.