Strata Academy

Living systematic reviews – keeping evidence up to date

When continuous search and update makes sense, workflow differences from one-off reviews, and reporting expectations

• LSRs version outputs (v1.0, v1.1) with public changelogs — check the date before citing.
• Update searches must match original databases and eligibility unless protocol-amended.
• AMSTAR 2 and PRISMA apply to each published version, not only the first release.
• Students can appraise version differences or run bounded update searches — not full LSRs solo.

1. What is a living systematic review?

A living systematic review (LSR) is a systematic review that is continually updated as new eligible evidence becomes available. Instead of fixing a single search date and publishing a static article, the review team commits to re-running searches on a schedule and incorporating new studies into an evolving synthesis.

The Cochrane Living Evidence network and publishers such as PLOS and BMJ have supported LSR models for topics where evidence accrues quickly – pandemic therapeutics, novel vaccines, and fast-changing diagnostic pathways are canonical examples.

LSRs are not simply 'we searched again last month'. They require an amended or living protocol, predefined rules for when new evidence triggers re-analysis, and public versioning so readers know which estimate they are citing.

For students reading the literature, LSRs are increasingly cited in guidelines. You must check the version date and changelog before treating a pooled estimate as current.

2. Living review vs standard systematic review

Standard systematic reviews fix methods and search dates at a point in time. They are the right choice for stable questions, thesis timelines, and topics where new trials appear slowly.

Living reviews commit to transparent update protocols, versioned outputs (v1.0, v1.1, v2.0), and often a public change log describing what new studies altered conclusions or GRADE certainty.

Resource demands differ sharply. A one-off review can be completed in a semester with a defined team. An LSR needs sustained librarian time, screening capacity, and often institutional hosting for versioned outputs.

AMSTAR 2 and PRISMA apply to each published version. Appraise whether update searches were as comprehensive as the original and whether new studies were integrated with the same eligibility criteria.

• Search frequency – monthly to quarterly vs one-off
• Versioning – numbered releases with changelog vs single journal article
• Team – standing core group vs time-limited student cohort
• Registration – PROSPERO living-review options; protocol amendments documented
• Certainty tracking – GRADE may change when new trials reduce imprecision

Note: A full LSR is rarely feasible as a solo intercal project without institutional infrastructure.

3. When a living model makes sense

LSRs suit questions where practice decisions are made weekly or monthly and outdated evidence could harm patients – emergent infections, drug safety signals, and contested interventions with ongoing trial programmes.

They are poor fits for narrow thesis questions with stable evidence bases, historical topics, or areas where new primary studies appear once every few years.

Decision-makers should specify what change in evidence would alter practice. Without that threshold, teams risk endless updates without interpretable milestones.

Students appraising LSRs should ask: What was the last search date? Did the new version change the pooled estimate meaningfully? Was GRADE certainty upgraded or downgraded?

4. Methodological requirements

LSRs still require PRISMA-compliant reporting for each version: identification, screening, inclusion, and synthesis counts must reconcile. New records flow through the same dual screening standards as the original review.

Pre-specified rules should define when meta-analysis is re-run, when subgroup analyses are updated, and when clinical conclusions or GRADE ratings change. Ad hoc changes between versions undermine credibility.

Automation appears in some LSR pipelines – machine learning classifiers for screening prioritisation, alerts from databases, and semi-automated extraction. Human verification remains standard for final inclusion and for risk-of-bias judgements in high-stakes reviews.

Living network meta-analyses add complexity: new nodes or comparisons may require model refitting and inconsistency re-evaluation. Report software and model choices for each version.

• Maintain identical eligibility criteria unless protocol amendment justifies change
• Track excluded studies at full-text stage with PRISMA reason codes
• Re-apply ROB 2 / ROBINS-I to all new included trials
• Publish a summary of what changed – not only a new forest plot

5. How to critically appraise a living review

Treat each version as an update study: read the changelog before the abstract. Check whether new trials were identified through the same databases and search strategy as the original.

Assess whether new evidence was combined with the same synthesis model (random vs fixed effects) pre-specified in the protocol. Unplanned switching between models across versions is a red flag.

Examine GRADE certainty ratings per outcome. Living updates often narrow confidence intervals – certainty may upgrade – but new high-risk trials can also increase heterogeneity or bias concerns.

Use AMSTAR 2 on the latest full methods supplement. Items on comprehensive search, duplicate screening, and risk-of-bias integration apply to every update wave.

6. What students can do instead of running an LSR

Appraise published living reviews as structured coursework: compare version 1.0 and the latest release, document what changed in participants, interventions, and pooled estimates.

Propose an update search in your dissertation discussion: repeat the original search strategy to a new date and report how many additional trials would have been eligible – without necessarily completing full synthesis.

Use StrataResearch to appraise the latest published version of a review series and compare reported methods to the original PROSPERO protocol.

If your supervisor supports a mini-update, pre-register a bounded protocol (single new search, narrative summary only) rather than promising a living model you cannot sustain.

Tip: Pair this guide with our systematic review methodology and PRISMA 2020 framework pages.

7. Versioning, changelogs, and citation

Living reviews publish numbered versions — v1.0 at initial release, v1.1 after the first update wave, v2.0 when methods change materially. Always cite the version you read, not the landing page URL that silently redirects to the latest.

Changelogs should list: new studies included, studies excluded on re-screening, effect estimate changes, GRADE certainty shifts, and any protocol amendments. If no changelog exists, treat the review as a standard static review and note the limitation.

Guidelines and examiners may reference a specific version. Compare your downloaded PDF date to the online changelog before writing 'the review shows…' in coursework.

DOI versioning varies by publisher — some issue new DOIs per version, others update in place. Check the methods supplement for the search date of the version you cite.

• Cite version number and date in references
• Read changelog before abstract conclusions
• Note if pooled estimate crossed null between versions
• Flag silent in-place updates as appraisal limitation

8. Automation, alerts, and machine learning in LSRs

Living pipelines often use database alerts (PubMed RSS, Embase alerts), continuous Cochrane CENTRAL feeds, and trial registry monitoring. Some teams add machine learning classifiers to prioritise new records — same validation standards as non-living AI-assisted screening.

Automation reduces delay between trial publication and review update; it does not remove dual human screening for final inclusion. Report alert sources and screening workflow per PRISMA-S extensions where applicable.

Students appraising LSRs should ask whether update waves used the same classifier training as v1.0 or were retrained — performance drift affects false-negative risk.

Semi-automated extraction may appear in mature LSR programmes. Treat extracted numbers as human-verified unless the changelog states otherwise.

Note: A living badge on a website does not prove rigorous update methods — appraise the changelog and search dates like any systematic review.

9. Worked example: comparing two LSR versions

Use this template in journal club or SSC coursework: download two versions, complete a comparison table (studies added, estimates changed, GRADE shifts), and conclude whether the living model added value over reading v1.0 only.

Frequently asked questions

How often are living reviews updated?

Typically monthly to quarterly, pre-specified in the protocol. Some topics pause updates when evidence stabilises. Check the changelog — 'living' does not mean daily.

Can I cite a living review in my dissertation?

Yes — cite the specific version number and access date. Note that conclusions may change after submission; mention this limitation in your discussion if the topic is fast-moving.

Is a living review the same as a Cochrane review update?

Related. Cochrane publishes formal review updates with new search dates. Living models emphasise continuous surveillance and versioned web outputs. Both require transparent search and screening methods.

Do AMSTAR 2 criteria apply to each LSR version?

Yes. Appraise the latest full methods supplement. Critical flaws in update searches (e.g. dropping Embase in v1.1) undermine the living model.

Can I run a one-off update search for my dissertation?

Yes — a bounded 'update search' repeating the original strategy to a new date is realistic student work. Call it an update search, not a living review, unless you commit to ongoing versions.

Interactive walkthroughs and quizzes load when JavaScript is enabled — the checklist and tables above are fully readable without it.