A search string for a systematic reviewসিস্টেম্যাটিক রিভিউয়ের খোঁজার শব্দ

Concepts ANDed, synonyms ORed

A systematic review's question breaks into two or three concepts, not a paragraph. "Does index insurance increase savings among smallholder farmers" is two concepts and an outcome: the intervention, the population, and what is being measured. Each concept gets its own list of synonyms, because researchers do not agree on a name for anything: one paper's "index insurance" is another's "weather index insurance" or "parametric insurance", and a string that names only one of the three quietly loses the other two.

Inside a concept, the synonyms are joined with OR: any one of them is enough to make a record a candidate. Between concepts, the joins are AND: a record has to mention the intervention and the population, not merely one of the two. Get the two the wrong way round, AND inside a concept and OR between concepts, and the count explodes: every paper about smallholder farmers, plus every paper about insurance of any kind, whether or not the two ever meet inside the same paper.

Truncation and phrase searching

Two devices do most of the work inside a concept's synonym list.

Truncation cuts a word to its stem and adds a wildcard, usually an asterisk, so one term catches every ending: farm* finds farm, farmer, farmers and farming in a single search rather than four. It is a shortcut, and a blunt one: farm* also finds farmed and farmyard, so a shorter stem is not automatically a better one. Test what a stem actually returns before trusting it inside the full string.

A phrase in quotation marks does the opposite: it pins two or more words together so the database looks for them in that order, next to each other, rather than anywhere at all in the record. index insurance without quotes finds every record that mentions index somewhere and insurance somewhere else, which in a large database is most of agricultural economics. "index insurance" with the quotes finds the term.

One string per database

The idea, concepts ANDed and synonyms ORed, is the same everywhere. The syntax that says it is not. A string written for one database is not pasted into the next; it is translated, term list and all, into that database's own rules for AND, OR, truncation, phrase and which fields it searches by default.

The search log

A protocol without a log is a promise nobody can check. The log is a table, kept from the first search onward rather than reconstructed at the end from memory, and it needs four things for every database searched: which database, the exact string run, the date it was run, and how many records it returned.

Write the log as you search, not afterwards. A database's index changes week to week, and a count reconstructed from memory a month later is a number nobody, including you, can check.

Worked example: index insurance and smallholder farmers

The three concepts ANDed together, in Scopus syntax:

TITLE-ABS-KEY(("index insurance" OR "index-based insurance" OR "weather index insurance" OR "parametric insurance") AND (smallhold* OR "small-scale farm*" OR "subsistence farm*") AND (adopt* OR uptake OR "take-up" OR demand OR purchas*))

The same three concepts in OpenAlex, where truncation is not reliable, so the outcome list is spelled out rather than stemmed: adopt OR adoption OR adopting OR adopted OR uptake OR "take-up" OR demand OR purchase OR purchasing, searched against title and abstract.

Three databases, three counts, none of them the true size of the literature: some of it is the same paper indexed three times, and the log's job is only to say exactly what was run and when, so that whoever checks the review later can run it again and expect to land close to the same place.

Where it goes wrong

• One synonym per concept, so a paper that calls it "weather index insurance" never appears at all.
• OR between concepts instead of AND, which returns everything about farmers and everything about insurance separately, in the tens of thousands.
• A stem so short it pulls in unrelated words: farm* alone, with no population qualifier, also finds pharmacology.
• Pasting one database's string into another database's search box unchanged, where the field tags and the truncation symbol mean nothing or mean something else.
• Quoting Google Scholar's result count as though it were comparable to a database with a controlled index.

• Every concept the question needs has its own synonym list, ORed.
• Concepts are joined with AND, not OR.
• A stem has been tested before being trusted, not assumed.
• A phrase that must stay together is in quotation marks.
• The string has been translated into each database's own syntax, not copied across.
• The log names the database, the exact string, the date and the hit count, for every database searched.

The find room runs one search across several indexes at once and keeps the log automatically; the Boolean builder in the review room turns a concept table like the one above into a string in each database's own syntax without your having to remember which one takes an asterisk and which one does not.