Living Evidence Review vs. Scheduled Review Update

A review is never really finished. Between the day you lock a search strategy and the day your manuscript goes to production, new trials appear, corrections land, and a coauthor asks whether the evidence still holds. The practical question behind "living evidence review vs. scheduled review update" is not which label sounds more modern. It is which one you can actually run with your team, your timeline, and your need for an auditable method trail.

This article compares the two approaches on the same task, shows where each one breaks down, and gives you a decision table plus a combined workflow. It uses a manuscript revision as the running example, because that is where the choice usually becomes urgent.

A living evidence review treats the evidence synthesis as a maintained product. The search is designed to be rerun, records are tracked as they arrive, and the review is refreshed on an ongoing basis rather than only at a single publication moment. The defining work is continuity: the method trail stays open and current.

A scheduled review update treats the synthesis as a finished artifact that is revisited at planned intervals. You complete the review, publish it, and then return to it on a calendar trigger to rerun searches and fold in new evidence. The defining work is a clean, repeatable restart.

Both depend on the same foundation. Cochrane guidance in its Handbook chapter on searching and selecting studies recommends planning searches from eligibility criteria, using multiple sources, combining free-text terms with subject headings, documenting the process, deduplicating records, screening in stages, linking multiple reports of one study, and rerunning searches before publication. Notice that rerunning searches before publication is already part of good practice. The difference between the two approaches is how much of that rerun discipline you institutionalize.

Most teams do not choose between these approaches in the abstract. They choose from a specific situation. Identify which one describes you.

• You are revising a manuscript and the search is months old. You need a defensible rerun and a record of what changed.
• You are closing a project. You need the method trail to be complete enough that a future team could restart it.
• You are handing off to a lab successor. You need the search logic, sources, and screening decisions to be legible to someone who was not there.
• You are starting a new review. You can design for continuity from the beginning rather than retrofitting it.

The first three situations usually point toward a scheduled update with a strong trail. The fourth is where a living approach becomes realistic, because you can build the rerun into the design.

Take one concrete task: rerunning the search for a manuscript revision and documenting what changed. Here is how each approach handles it.

A living review builds the search so it can be rerun on demand. Field tags, phrase searching, filters, and saved searches in PubMed make this practical, and PubMed's search details show how terms were translated and combined, which supports documenting the rerun. A scheduled update does the same rerun, but as a discrete event tied to the calendar.

Both approaches need deduplication and staged screening, as Cochrane recommends. A living review spreads this work across the maintenance cycle. A scheduled update concentrates it into the update window.

Cochrane guidance calls for linking multiple reports of one study. In a living review, this linking is maintained continuously. In a scheduled update, it is reconstructed at each update, which is where errors tend to creep in if the trail is thin.

This is where the two diverge most sharply. A living review keeps documentation current by design. A scheduled update depends on whether the original team wrote down enough for the restart to be faithful.

A living review is not automatically better. It fails when the maintenance burden outpaces the team. If no one owns the rerun cadence, the "living" label becomes aspirational and the review quietly goes stale. It also fails when the search is not designed for reruns in the first place, because retrofitting continuity onto a one-off search is expensive.

A living review also struggles when the evidence base is stable. If little new work is appearing, continuous maintenance spends effort for little gain.

A scheduled update fails when the interval is too long for a fast-moving field, so the published review is already behind at release. It fails when the original method trail is incomplete, because the update team cannot reconstruct the search logic and screening decisions. And it fails when the calendar trigger is treated as sufficient, so no one checks whether the field moved faster than the schedule assumed.

Use the table as a starting point, not a verdict. The decisive factor is usually whether you have someone who will own the rerun.

In practice, most teams land on a hybrid: a scheduled update cadence with living-review discipline in the documentation. Here is a workflow that works for a manuscript revision.

Before rerunning anything, write down the eligibility criteria, the sources used, the free-text terms and subject headings, and the filters. Cochrane's guidance to plan searches from eligibility criteria and document the process applies directly here. If you are starting fresh rather than reconstructing, use a scholarly search interface to find candidate papers and keep the query logic visible. WisPaper search is the entry point for finding academic papers through WisPaper's scholarly search interface.

Rerun the search and record what is new, what is unchanged, and what has been retracted or corrected. PubMed's saved searches and search details help you reproduce the exact query, and Google Scholar's date limits and alerts help you catch recent work. Capture the delta as an artifact, not as memory.

Follow the staged screening and deduplication that Cochrane recommends. Keep the screening decisions attached to the records so a successor can see why something was excluded.

Save the included and candidate papers where the team can find them. My Library lets you save or upload papers and organize them in the WisPaper library, which is where the trail lives between update cycles.

When you need to check what the collected papers say about a specific question, Library QA lets you ask questions based on papers uploaded to My Library or added from search results. This is useful during revision when a coauthor asks whether a claim is still supported.

A rerun often adds references, and new references are where citation errors enter. TrueCite checks BibTeX against real academic databases to flag hallucinated references. Run it on the updated bibliography before the manuscript goes back to coauthors.

If the project is closing or transferring, put the search logic, the delta record, and the screening decisions in one place. Research Projects is the WisPaper Research Projects area where you can create a new project to hold the work.

The result is ready when a colleague who was not involved could rerun your search and reach the same included set. Concretely, check that:

• The eligibility criteria and search terms are written down, not just remembered.
• The rerun is reproducible from the documented query, including field tags and filters.
• New records are deduplicated and screened in stages.
• Multiple reports of the same study are linked.
• The delta between the original and updated search is recorded.
• The bibliography has been checked for references that do not resolve to real work.

If any of these is missing, the review is not ready to hand off, regardless of which label you chose.