A PubMed String Is Not an Embase String

A search strategy is usually designed once. Someone builds it in PubMed, tests it against a handful of known relevant studies, refines it until the yield looks right, and then copies it into Embase, CINAHL, Web of Science and whatever else the protocol names. The syntax is adjusted where the interface complains. The controlled vocabulary is usually left as it was.

The result is a strategy that is well designed for one database and approximately right for the others. Reviewers who specialise in searching recognise it immediately, because the Embase strategy in the supplementary file still contains MeSH headings, PubMed field tags, or a structure that only makes sense in PubMed's automatic term mapping. Peer review of searches against the PRESS checklist asks specifically whether the strategy has been adapted to each database's subject headings and syntax (McGowan et al., 2016). A copied strategy fails that question by construction.

Among the registered protocols we read in exercise and health sciences, this is the single most common search defect. It is also among the cheapest to fix before the search runs, and among the most expensive to fix after.

Why the same words do not retrieve the same records

The problem is not that databases use different syntax. Syntax is easy; every interface will tell you when you get it wrong. The problem is that databases index the same paper differently, and a strategy built around one indexing system does not exercise the other.

Controlled vocabulary is not shared. MEDLINE indexes with MeSH. Embase indexes with Emtree. The two overlap substantially but are not the same thesaurus. Emtree is larger, includes many drug and device terms that MeSH lacks, and organises some concepts under different parents. A concept that is a single MeSH heading may be split across two Emtree terms, or sit under an Emtree heading with a broader or narrower scope. Exercise science is a field where this matters: training modalities, performance outcomes and sport-specific terms are indexed differently enough that a direct MeSH-to-Emtree substitution misses records.

Explosion behaves differently. In Ovid MEDLINE, a subject heading is exploded only if you ask for it (exp). In Embase.com, Emtree searches are exploded by default. A translator who mirrors the Ovid syntax mechanically can end up with narrower or broader retrieval than intended in the second database without noticing, because the string looks equivalent.

Automatic term mapping hides what PubMed is doing. PubMed silently maps untagged text to MeSH terms and synonyms. A PubMed string that looks like free text may in fact be retrieving records through MeSH mapping. When that string is pasted into a database without automatic mapping, the hidden half of the search disappears. The PubMed "Details" view shows exactly how a query was translated; it is worth reading before treating any PubMed string as a template.

Indexing depth and lag differ. Embase indexes conference abstracts in large numbers, which affects both yield and screening load. Records in either database may sit unindexed for weeks or months after they appear, which is why free-text terms are needed alongside subject headings in every database, not only the ones where the headings seem weak.

The "CENTRAL covers Embase" justification

A recurring variant in registered protocols is a decision not to search Embase directly, justified on the grounds that CENTRAL incorporates Embase records and that Scopus or Web of Science provide substantial overlap.

The first half of that argument is partly true and mostly misapplied. CENTRAL does include records identified from Embase, but only those identified as reports of randomised or quasi-randomised trials through Cochrane's own processes. It is a curated subset, not a mirror. A review that includes non-randomised designs, or that depends on records CENTRAL has not yet processed, does not have Embase coverage through CENTRAL. Scopus includes Embase content but is searched without Emtree, so the controlled-vocabulary advantage that justifies searching Embase in the first place is lost.

Bramer and colleagues' analysis of searches across a large set of published reviews found that Embase retrieved more unique relevant references than any other single database, and that the best-performing combinations included it (Bramer et al., 2017). Not every review needs Embase. Reviews of interventions in health sciences almost always do, and a reviewer will expect a reason if it is missing. "CENTRAL covers it" is not usually a reason that survives scrutiny. Our earlier note on how many databases is enough covers the wider question of database selection.

Filters and limits that travel badly

Copied strategies also carry filters across databases where they do not belong.

Study design filters are database-specific. The Cochrane Highly Sensitive Search Strategy for identifying randomised trials was developed and validated for MEDLINE (Lefebvre et al., 2025). Embase has separate validated RCT filters. Applying the MEDLINE filter's terms in Embase, or a PubMed "Clinical Trial" publication type limit, gives an unvalidated filter whose sensitivity nobody knows. If a design filter is used, cite the validated version for each database and use that version.

Interface limits are worse, because they are often invisible in the reported strategy. A date limit set in the PubMed sidebar, a "Humans" limit, an "English" filter or an Embase "Article" limit may be applied at search time and never written into the documented string. PRISMA-S item 9 asks for all limits and restrictions to be reported, with justification (Rethlefsen et al., 2021). A strategy that is reproduced exactly from the supplementary file but yields a different number of records usually has an unreported limit somewhere.

"Humans" limits deserve a specific warning. In PubMed, restricting to Humans removes records that have not yet been indexed with the Humans heading, which includes most recent records. The standard workaround is to exclude records indexed as animal-only rather than including only records indexed as human. The same logic applies in Embase with its own terms.

How to translate a strategy properly

The aim is not identical strings across databases. It is an equivalent search of each database's content, using that database's own tools.

Start from concepts, not from a string. Write the strategy first as a concept table: one column per PICO element, listing the free-text synonyms and the controlled vocabulary separately. The free-text column travels between databases with syntax changes. The vocabulary column is rebuilt for each database.

Rebuild the subject headings in each thesaurus. For each concept, search the Emtree browser (or the CINAHL Headings, or the APA Thesaurus) directly. Read the scope note, check what sits beneath the term, decide whether to explode, and record the decision. Do not look up the MeSH term and find its nearest Emtree equivalent; look up the concept.

Translate field codes and proximity deliberately. Title/abstract in PubMed is [tiab]; in Embase.com it is :ti,ab (with :kw for author keywords if wanted); in Ovid it is .ti,ab. Proximity operators differ across all of them. Truncation and wildcard behaviour differ. Tools such as the Polyglot Search Translator can speed up the syntax conversion, but they convert syntax only. They do not choose subject headings.

Test against a validation set in each database. Before running the search for real, identify a set of known relevant studies, ideally ten to twenty, drawn from previous reviews or from scoping. Check that each one is indexed in the database you are testing, and that your strategy retrieves it. If a known relevant record is in Embase and your Embase strategy misses it, the strategy has a gap; look at how that record is indexed and why your terms did not reach it.

Record everything. Save the full strategy for every database, line by line, with the number of results per line, the interface and platform used, and the date run. PRISMA-S asks for exactly this, and it is far easier to save at the time than to reconstruct later.

What reviewers look for

A reviewer checking a search does not run it. They read the supplementary strategies and look for signs that each database was searched on its own terms. The signals they notice are specific: MeSH headings in an Embase strategy; PubMed field tags in Ovid; identical line counts across databases with very different sizes; a single strategy labelled "adapted for all databases"; design filters with no citation; a yield from Embase that is smaller than the yield from MEDLINE for a clinical topic.

Each of these is a small thing. Together they suggest that the search was designed once and distributed, and a reviewer who concludes that will ask what was missed. The answer to that question is unknowable after the fact, which is why the reviewer's usual request is to rerun the search. That is a request no review team wants to receive at revision, with screening and extraction already done.

The way to avoid it is to treat each database as its own search. It takes longer at the start. It takes much less time overall.

References

Bramer, W. M., Rethlefsen, M. L., Kleijnen, J., & Franco, O. H. (2017). Optimal database combinations for literature searches in systematic reviews: A prospective exploratory study. Systematic Reviews, 6, 245. https://doi.org/10.1186/s13643-017-0644-y

Lefebvre, C., Glanville, J., Briscoe, S., Featherstone, R., Littlewood, A., Metzendorf, M.-I., Noel-Storr, A., Paynter, R., Rader, T., Thomas, J., & Wieland, L. S. (2025). Chapter 4: Searching for and selecting studies (last updated March 2025). In J. P. T. Higgins, J. Thomas, J. Chandler, M. Cumpston, T. Li, M. J. Page, & V. A. Welch (Eds.), Cochrane handbook for systematic reviews of interventions (version 6.5.1). Cochrane. https://www.cochrane.org/authors/handbooks-and-manuals/handbook/current/chapter-04

McGowan, J., Sampson, M., Salzwedel, D. M., Cogo, E., Foerster, V., & Lefebvre, C. (2016). PRESS Peer Review of Electronic Search Strategies: 2015 guideline statement. Journal of Clinical Epidemiology, 75, 40–46. https://doi.org/10.1016/j.jclinepi.2016.01.021

Rethlefsen, M. L., Kirtley, S., Waffenschmidt, S., Ayala, A. P., Moher, D., Page, M. J., Koffel, J. B., & PRISMA-S Group. (2021). PRISMA-S: An extension to the PRISMA statement for reporting literature searches in systematic reviews. Systematic Reviews, 10, 39. https://doi.org/10.1186/s13643-020-01542-z