What should inclusion and exclusion criteria contain?

Every dimension a screener has to judge, expressed so that another person could apply it without asking you: population, intervention or exposure, comparator, outcomes, study designs, setting, period, language and publication types. Mirror each inclusion criterion with the exclusion it implies, and decide in advance what happens to the predictable edge cases: mixed samples, multiple reports of one study, conference abstracts, and records in languages nobody on the team reads. Log any criterion refined during screening with the date.

Why keep a search log?

Because a search is a claim about the literature at a moment, and without a log the claim cannot be checked or repeated, including by you. The log records the date, the database and interface, the query version, the limits and the number of records for every search actually executed, plus the non-database sources such as citation chasing and registries. It supplies the numbers for a PRISMA flow diagram, it answers the reviewer question of how the search was done, and it is what makes updating the review a matter of days rather than a restart.

Do I need a search strategy for a narrative review?

It is not a formal requirement and it is still worth writing. A narrative review does not claim exhaustiveness, but it does implicitly claim coverage, and a recorded strategy turns that into a specific statement: these databases, these terms, this period, searched on this date. It also makes the review updatable and protects you from the reviewer question about how the literature was selected, which is otherwise unanswerable except by appeal to your own familiarity with the field.

How many databases should I search?

Enough to cover your field rather than a number taken from another discipline's guidance. Choose them for what they index: a biomedical question and a social science question need different sets, and several fields have a specialist database that general indexes cover poorly. Then add the sources that no index covers, such as preprint servers, dissertation repositories, trial registries and the agency or standards bodies that publish in your area, and add citation chasing from your anchor papers, which reliably returns records no keyword search finds.

Should I ask a librarian to check my search?

Yes, and it is the cheapest quality improvement available in a review. Research librarians build searches professionally, know the syntax quirks of each interface, and will spot a truncation symbol or a field tag that is silently returning the wrong set. Most universities provide the service free to their own researchers, an appointment takes about an hour, and it is best used after you have drafted the master query rather than before, so there is something concrete to critique.

Literature Review Search Strategy Template

Three copyable blocks: the boolean query written in concept blocks, the inclusion and exclusion criteria table, and the search log that turns a search into something another person could repeat.

A search strategy is the written record of what you searched, where, when and against which criteria, and it is what separates a review someone can trust from a reading list. It matters for a systematic review because it is a reporting requirement, and it matters for a narrative review because it converts a vague claim of coverage into a specific one. This page gives three copyable blocks: a boolean query built in concept blocks and adapted per database, an inclusion and exclusion criteria table, and a search log. Each is annotated with what makes it work. The process these blocks belong to is in our guide to building a literature review, and what to do with the results once they are screened is in the gap analysis guide. The worked example throughout is a health services question, and the structure transfers to any field that has databases.

Block 1: the boolean query in concept blocks

One block per element of your question, synonyms joined with OR inside each block, blocks joined with AND. This is the only query structure that can be adapted across databases without being rewritten, and it is the one every reporting standard expects to see.

Concept block query

RESEARCH QUESTION
Among [population], does [intervention or exposure] affect [outcome], in [setting], between [years]?

CONCEPT 1: POPULATION
("older adults" OR "elderly" OR "aged" OR "geriatric" OR "people aged 65")

CONCEPT 2: INTERVENTION OR EXPOSURE
("telemonitoring" OR "remote monitoring" OR "telehealth" OR "telemedicine" OR "home monitoring")

CONCEPT 3: OUTCOME
("hospital readmission*" OR "rehospitali?ation" OR "unplanned admission*" OR "emergency admission*")

CONCEPT 4: DESIGN (optional, use only if the question requires it)
("randomi?ed controlled trial" OR "RCT" OR "controlled trial" OR "quasi-experimental")

FULL QUERY
(CONCEPT 1) AND (CONCEPT 2) AND (CONCEPT 3) AND (CONCEPT 4)

CONTROLLED VOCABULARY, ADDED PER DATABASE
PubMed:  ("Aged"[Mesh] OR "Aged, 80 and over"[Mesh]) AND ("Telemedicine"[Mesh]) AND ("Patient Readmission"[Mesh])
Embase:  'aged'/exp AND 'telemedicine'/exp AND 'hospital readmission'/exp

LIMITS APPLIED
Years: 2010 to present. Language: none applied. Document types: none excluded at search stage.

VALIDATION SET (must be returned by the search)
[Anchor paper 1, first author, year, DOI]
[Anchor paper 2, first author, year, DOI]
[Anchor paper 3, first author, year, DOI]

Write the question in one sentence first, with its elements marked. Every block below is one element, and a query with a block that matches no element is a block that will silently narrow your results.

Add controlled vocabulary where the database offers it, such as MeSH in PubMed or Emtree in Embase, on top of the free-text block rather than instead of it. Indexing catches records whose title and abstract use none of your words, and free text catches records too recent to have been indexed yet.

Use the design block sparingly. It is the fastest way to lose relevant records, and for most questions it is better applied at screening, where an exclusion is visible and reversible, than at search, where it is invisible.

Apply language and date limits only where you can justify them in writing, and record the justification. A language limit is a known source of bias and needs to be a decision rather than a default.

Build a validation set of three to five papers you already know belong in the review, and check that the query returns all of them before running it in full. A query that misses a known anchor has a fault, and this two minute test finds it before you screen a thousand records.

Block 2: inclusion and exclusion criteria

Criteria written before the records arrive, precise enough that another person could apply them without asking you a question. This is the block that decides how much of your screening time is spent arguing.

Eligibility criteria

INCLUSION CRITERIA
Population: Adults aged 65 and over, community-dwelling, any comorbidity profile.
Intervention: Any remote monitoring of physiological or symptom data transmitted to a clinical team, of at least four weeks' duration.
Comparator: Usual care, or any alternative model of follow-up.
Outcome: Reports at least one of: unplanned hospital readmission, emergency department attendance, length of stay.
Design: Randomised or non-randomised controlled studies, and controlled before-and-after studies.
Setting: Any country; intervention delivered in the participant's home.
Period: Published 2010 onwards.
Language: Any. Records not in [languages read by the team] to be listed and translated where feasible.
Publication: Peer-reviewed articles and preprints. Conference abstracts recorded separately, not synthesised.

EXCLUSION CRITERIA
- Mean participant age below 65, or age not reported.
- Monitoring not transmitted to a clinical team (self-tracking only).
- Intervention shorter than four weeks.
- No comparator group.
- No eligible outcome reported.
- Study protocols, editorials, commentaries, narrative reviews (reference lists of reviews to be citation-chased instead).
- Duplicate reports of the same study population: the most complete report is retained and the others linked to it.

DECISIONS TAKEN DURING SCREENING (append with date)
2026-08-02 Mixed-age samples included where results for the 65+ subgroup are reported separately. Recorded because it changed two decisions already made.
2026-08-06 Hospital-at-home programmes excluded: the monitoring is not the intervention under study.

Mirror every inclusion criterion with the exclusion it implies. A reviewer or a co-author reading only one column should still be able to predict the decisions.; Make each criterion testable from the text of a paper. Adults aged 65 and over, or age not reported, is testable; older adults is not, and it will produce different decisions from two screeners.
Say what happens to the edge cases you can already foresee: mixed-age samples, multiple reports of one study, conference abstracts, records in languages nobody on the team reads. These are the four that arise in almost every review.; Keep a dated log of criteria decisions taken during screening, and note whether earlier decisions had to be revisited. Criteria always develop; undocumented development is what makes a review unrepeatable.; Never exclude at title and abstract on a criterion that can only be checked in the full text, such as intervention duration or an outcome reported in a subgroup. Carry those records forward and exclude them at full text, where the reason is recorded.

Block 3: the search log

One row per search actually executed. This is the block people intend to write afterwards and never can, and it is also the block that answers the reviewer question of how the search was done.

Search log

SEARCH LOG, review: [short title]
Searcher: [name]   Protocol registered: [PROSPERO ID or: not registered]

| Date       | Source            | Interface / platform   | Query run                          | Limits           | Records |
|------------|-------------------|------------------------|------------------------------------|------------------|---------|
| 2026-07-14 | MEDLINE           | PubMed                 | See query v1.2, appendix A         | 2010-, none      |   1,284 |
| 2026-07-14 | Embase            | Ovid                   | See query v1.2 adapted, appendix A | 2010-, none      |   1,907 |
| 2026-07-15 | CINAHL            | EBSCOhost              | See query v1.2 adapted, appendix A | 2010-, none      |     612 |
| 2026-07-15 | Cochrane CENTRAL  | Cochrane Library       | See query v1.2 adapted, appendix A | 2010-            |     338 |
| 2026-07-16 | medRxiv           | medRxiv site search    | Free text, concepts 2 and 3 only   | 2010-            |      41 |
| 2026-07-16 | ClinicalTrials.gov| Registry site          | Condition + intervention terms     | Completed studies|      77 |
| 2026-07-17 | Backward chasing  | Reference lists        | 6 anchor papers + 2 reviews        | none             |      54 |
| 2026-07-17 | Forward chasing   | OpenAlex               | Citations of 6 anchor papers       | 2010-            |     216 |
| 2026-07-18 | Hand search       | [Journal name]         | Tables of contents 2024-2026       | none             |      12 |

Total records retrieved: 4,541
Duplicates removed: 1,398
Records screened on title and abstract: 3,143
Full texts assessed: 118
Studies included: 27

ALERTS SET
2026-07-18  PubMed saved search, weekly email.
2026-07-18  Google Scholar alerts on 6 anchor papers.
2026-07-18  OpenAlex citation alert on 6 anchor papers.

SEARCH UPDATED
2026-11-03  All database searches re-run, date limit 2026-07-14 onwards. 61 new records, 3 included.

Record the interface as well as the database. MEDLINE searched through PubMed and MEDLINE searched through Ovid take different syntax and return different sets, and a log that names only the database cannot be repeated.; Store the full query strings in an appendix and reference the version from the log. PRISMA-S sets out what a reported search should contain, and a version number in the log is what keeps a query that was corrected mid-search from becoming untraceable.
Log the non-database sources on the same sheet: preprint servers, registries, citation chasing and hand searching. They are part of the search, they frequently supply records nothing else found, and they are the part most often left out of the report.; Carry the numbers all the way to the included set. Retrieved, deduplicated, screened, full text, included is the sequence that populates a PRISMA flow diagram, and it is also the honest answer to how much of this literature you actually looked at.; Record the alerts and the update run in the same file. An update logged as a separate search with its own date is what lets you say the review is current as of a stated day rather than in the present tense.

Adapting the strategy per database, and what to report

The blocks above are the master version. Each database will need its own adaptation, and the difference between the master and the adaptations is what most people fail to record.

Adapt rather than paste. Field tags, truncation symbols, phrase syntax, proximity operators and controlled vocabulary all differ, and a query pasted unchanged into a second interface usually runs and quietly returns the wrong set, which is worse than failing.

Re-run the validation set check after each adaptation. It takes two minutes per database and catches the syntax errors that produce plausible but wrong result counts.

Ask a librarian to look at the master query before you run anything. Research librarians do this professionally, most institutions provide the service free, and it is the highest-yield hour available in the entire review.

Frequently asked questions

Write the question in one sentence, split it into concepts, and build one block per concept: synonyms and spelling variants joined with OR inside the block, blocks joined with AND. Add controlled vocabulary such as MeSH or Emtree on top of the free text rather than instead of it. Apply limits only where you can justify them in writing. Then validate: pick three to five papers you already know belong in the review and check the query returns all of them before you run it in full.