Developing a Systematic Review Search Strategy: A Step-by-Step Workflow

Developing a systematic review search strategy is a sequence of distinct stages, not a single act of writing search terms. Methodological guidance published specifically on this process breaks it into identifying the question's core concepts, selecting databases, building and testing terms for each concept, combining them, running and recording the search, and validating the result before it is finalized. Skipping or compressing any one of these stages is one of the more common, avoidable reasons a finished search strategy turns out to be incomplete, and the stages are designed to detect different kinds of error.

Stage one: defining the question's core concepts

The first stage is extracting the question's distinct concepts, typically population, exposure or intervention, and outcome, and deciding which of these need to be represented in the search at all, since including every element of a complex question as a separate search concept can over-narrow results unnecessarily1. Bramer and colleagues' systematic approach recommends this concept-identification step be done deliberately and recorded, rather than left implicit, because later stages of the process depend on having a clear, written list of concepts to build terms against1. This stage also typically distinguishes which concepts are mandatory, usually the exposure or intervention, from which should be used only as a check rather than a formal search restriction, since representing every concept, including sometimes the outcome, directly in the search string can inadvertently exclude relevant studies that discuss the outcome using unexpected terminology2.

Stage two: selecting databases and building terms

Database selection should match the question's subject area; core biomedical databases such as MEDLINE, Embase, and the Cochrane Library are supplemented, depending on topic, with subject-specific databases like PsycINFO or CINAHL3. For each concept identified in stage one, this stage builds out a list of synonyms, related terms, and relevant controlled-vocabulary headings, such as MeSH in MEDLINE or Emtree in Embase, checking that the chosen terms are neither so broad they return excessive irrelevant results nor so narrow they miss studies using different terminology for the same underlying concept3. The Joanna Briggs Institute's guidance on search strategy development, used widely across nursing, public health, and allied health reviews, recommends testing candidate terms against a small number of already-known relevant papers at this stage, before the full strategy is assembled, to identify an obviously missing term early4.

Stage three: combining terms and running the search

With terms built for each concept, this stage combines them using Boolean operators, OR within a concept's synonym list, AND between concepts, applies truncation and wildcards for word variants, and accounts for spelling differences, plural forms, and word order across the target databases3. The strategy is then run in each selected database separately, since the exact syntax for truncation and field restriction differs by platform, and the number of hits returned by each database and search line is recorded as the search proceeds, not reconstructed afterward from memory5. Running the strategy in stages, line by line, rather than all at once also makes it considerably easier to identify which specific concept or term is responsible for an unexpectedly high or low result count. Saving each search line's exact syntax and result count as it runs, rather than only the final combined line, also makes it possible to later isolate exactly which concept drove a change if the strategy needs revisiting after an early round of screening reveals an unexpected pattern in what is or is not being retrieved.

Stage four: validating and documenting the final strategy

Before accepting a strategy as final, Bramer and colleagues recommend checking it against a set of studies already confirmed relevant to the review, through a prior scoping search or through citation tracking, to confirm the strategy actually retrieves them; a strategy that misses a study known to be relevant indicates a gap that must be corrected before full screening begins1. Once validated, the strategy needs to be documented in enough detail to satisfy PRISMA-S reporting requirements: the exact search string for every database, the date each search was run, any limits applied, and the total number of records retrieved, maintained as a running record rather than assembled retroactively6. This documentation both supports replication by other researchers and provides the evidence needed if a reviewer or reader later questions whether the search was thorough enough to support the review's conclusions7.

Criteria for updating or rerunning a search

A systematic review's search is not necessarily a one-time event; guidance on search strategy development generally recommends rerunning or updating the search close to submission if a substantial amount of time has passed since it was originally run, since new relevant studies may have been published in the interim3. The Cochrane Handbook recommends that reviews intended to remain current over time plan for periodic re-running of the search strategy as part of the review's maintenance, rather than treating the original search as permanently sufficient8. Deciding on an update policy at the protocol stage, rather than reacting to a reviewer's comment about currency during peer review, prevents this stage from becoming a hurried, last-minute task that risks introducing exactly the kind of undocumented, rushed search-strategy change this whole workflow is built to avoid.

Adaptation of the workflow for scoping reviews

All four stages above still apply when the review is a scoping review rather than a systematic review of effectiveness, but their emphasis shifts. Munn and colleagues' guidance on choosing between the two review types notes that a scoping review's concept-identification stage typically produces a broader, less restrictive concept list, since the purpose is mapping a literature's extent rather than isolating only the studies that meet narrow comparator-based criteria9. The validation stage changes correspondingly: rather than checking that the strategy retrieves a small set of known comparator-based studies, a scoping review's validation more often checks that the strategy retrieves known examples across the different sub-topics the mapping exercise is meant to cover, which is a broader and sometimes more subjective check than the systematic-review version of the same step10. Database selection in stage two also typically widens for a scoping review, since mapping a literature's full extent often calls for including grey-literature sources and subject-specific registers that a narrower, comparator-based systematic review would not need to consult, and deciding this scope deliberately at the protocol stage, rather than adding sources reactively partway through screening, keeps the whole four-stage workflow internally consistent. The same logic applies to how much time a team budgets for each stage: a scoping review's broader concept list and wider database selection generally take proportionally longer to screen at stage three than a narrower systematic review search would, and a protocol that fails to anticipate this often ends up compressing the validation stage under time pressure, which is precisely the stage whose omission causes the most downstream problems. Building explicit time estimates for each of the four stages into a review's protocol, rather than a single undifferentiated estimate for "the literature search," is a simple planning habit that makes this kind of compression far less likely to happen unnoticed. A team that has already budgeted, in writing, roughly how long concept identification, database and term selection, running and recording the search, and validation are each expected to take has a concrete basis for noticing early when one stage is running over, rather than only discovering the shortfall once the whole search is already finished and submission is imminent. Revisiting that written time budget at the midpoint of the search process, rather than only at the end, gives a team an actual opportunity to reallocate time toward validation if an earlier stage has already run long, instead of simply absorbing the delay into a shortened final check.

Key points

Practical application

Frequently asked questions

@misc{/la_developing_search_strategy_workflow_2026,
  author       = {{Pubrica Academy}},
  title        = {Developing a Systematic Review Search Strategy: A Step-by-Step Workflow},
  howpublished = {Pubrica},
  year         = {2026},
  month        = {oct},
  url          = {https://pubrica.com/academy/publication-support/how-to-develop-a-search-strategy-for-a-systematic-review/},
  note         = {Accessed: <span data-cite-acc="iso">2026-10-15</span>}
}

Stage 1 - Concepts identified: ____________________
Stage 2 - Databases selected: ____________________ | Terms per concept: ____________________
Stage 3 - Combined string(s) run: ____________________ | Hits per database/date: ____________________
Stage 4 - Validation studies checked: ____________________ | All retrieved? Y/N | PRISMA-S documentation complete? Y/N
Update policy: rerun search on/before: ____________________