A systematic-review search needs a defined question, suitable information sources and a record that another reader can inspect. This tutorial shows how to develop concepts, combine terms, adapt syntax to each database interface and record the searches you actually ran. Even a carefully designed search can miss eligible evidence, so its coverage and limits must remain explicit.
Define Your Review Question
Break the review question into concepts. PICO can organize an intervention question; other question types may need a different framework. For exercise versus medication for chronic pain, population and intervention terms might form useful search blocks. Do not assume that every PICO element belongs in the query: comparator and outcome terms can exclude relevant records whose abstracts do not mention them.
List synonyms, spelling variants and candidate controlled-vocabulary terms for each selected concept. MeSH is used in MEDLINE/PubMed; Emtree is used in Embase. Check the relevant thesaurus instead of treating a free-text phrase as an established subject heading.
Choose Databases and Sources Carefully
Choose sources for the subject, study designs and evidence needed, not the country in which the reviewer happens to work. A clinical intervention review may need biomedical databases and trial registers; an education or engineering question may require different subject sources. Document the rationale, access limits and relevant regional or non-English sources with an information specialist where possible. The Cochrane search chapter explains how source selection fits a review’s scope.
Build Your Search String with Boolean Logic
Combine synonyms with OR within a concept and concepts with AND. The following PubMed title/abstract example illustrates two blocks. It has not been run or validated for a review and is not a complete strategy; develop and test the controlled-vocabulary component separately.
("chronic pain"[tiab] OR "persistent pain"[tiab])
AND
(exercise[tiab] OR "physical therapy"[tiab] OR physiotherapy[tiab])Combine appropriate subject headings with free-text terms to cover differences in indexing and terminology. Test whether each added block retrieves known relevant records. Use NOT cautiously: an otherwise relevant report can mention the excluded term. A smaller result set is not, by itself, evidence of a better search.
Ask an information specialist to review the strategy where possible. The PRESS guideline and assessment form support structured peer review. Record who reviewed which version, the comments received and the changes made. Describe a search as peer reviewed only when that review actually happened; do not add a claim of validation merely to strengthen the manuscript.
Understand Search Syntax Across Different Academic Databases
Translate the strategy for each named interface. Field tags, proximity, phrase handling, truncation and subject-heading expansion differ across platforms. The examples below illustrate syntax only: they have not been executed as review searches. Check the current help page, run the translated query and inspect its behavior before recording it as final.
PubMed. PubMed Help documents [tiab] for title/abstract, [mh] for MeSH terms and [pt] for publication type. For example: ("digital health"[tiab] OR telemedicine[tiab]) AND "Diabetes Mellitus"[mh]. Its proximity syntax includes "patient physician relationship"[Title/Abstract:~0]: distance zero requires adjacent terms, in any order. Do not assume that this syntax works in another MEDLINE interface.
Embase.com. An illustrative combination is 'diabetes mellitus'/exp OR diabet*:ti,ab. Here /exp expands an Emtree term and :ti,ab targets title/abstract text. Consult Elsevier’s Embase field guidance and the current interface help. This is Embase.com syntax, not a query to paste unchanged into Ovid Embase.
Ovid interfaces. Use Ovid’s own field codes, thesaurus mapping and proximity rules. In Ovid guidance, ADJn allows up to n − 1 intervening words in either order; ADJ3 therefore allows up to two intervening words. Check the database-specific guide and test the translated search.
Scopus. TITLE-ABS-KEY() searches titles, abstracts and keywords. The official advanced-search guidance distinguishes W/n for proximity in either order and PRE/n for the specified order. A simple illustration is TITLE-ABS-KEY(patient W/3 experience). Check how proximity, phrase and wildcard rules interact before building more complex expressions.
Web of Science Core Collection. Advanced Search uses field tags such as TS= for Topic, TI= for Title and AB= for Abstract. For example, TS=("systematic review" AND "search strategy"). Its search-operator guidance explains NEAR/x for terms within the specified distance. Record the collection and interface, not just the vendor name.
Cochrane Library. Search Manager supports line-by-line construction and combinations of subject-heading and text searches. Use the Cochrane Library MeSH search to inspect a heading and its expansion, then record the resulting search lines and combinations. Specify the database searched within the Library, such as CENTRAL.
Google Scholar and web searching. These can help with citation searching and finding reports outside selected bibliographic databases. Record the exact query, date, ordering, pages inspected and stopping rule. Distinguish a displayed estimate from the records actually accessible or screened, and describe the search’s role and limitations alongside the other sources.
Keep the conceptual strategy stable while testing each interface translation. Differences in retrieved records may reflect coverage, indexing or syntax, so investigate missing known records before treating the translated version as ready.
Refine, Filter, and Document
Apply date, language and design filters only with a rationale tied to the question and source. Check the scope of any validated filter before using it in a different database or interface. Do not add a study-design filter automatically to a source already restricted to that design, and do not treat a convenient result count as the reason for a limit.
Preserve the exact query as executed, including all search lines and limits, and retain the export with a run identifier. The log below is a working record, not evidence that a search has been completed.
| Run | Database and interface | Exact executed query | Date | Retrieved records | Amendment and reason |
|---|---|---|---|---|---|
| S-01 | To complete | Paste the query after execution | Initial run or documented revision |
Leave the date and result count blank until execution. Preserve the original query when you revise it, and record which known relevant records the revised strategy retrieves. Test filters for the question rather than adding limits simply to make the result set smaller. Carry the actual source totals into the search and selection report, resolving duplicates separately.
The search log feeds the PRISMA reporting package. Software that ranks or summarizes results still needs a separate screening and extraction evaluation.