A systematic review that reports following PRISMA 2020 is expected to search more than one bibliographic database and to document each database’s search strategy in full, typically as supplementary material (see the PRISMA 2020 reporting guideline and its literature-search extension, PRISMA-S). Because MEDLINE/PubMed and Embase are indexed with different controlled vocabularies and searched through different query syntaxes, a strategy written for one cannot simply be re-run, unedited, in the other. The Cochrane Handbook, Chapter 4 goes further for Cochrane reviews specifically, stating that it is mandatory to search CENTRAL, MEDLINE, and Embase, and it recommends that anyone without information-retrieval expertise work with a trained information specialist on this kind of search translation project. This guide walks through why translation is necessary, the concrete syntax and vocabulary differences between the two systems, a practical line-by-line workflow, the mistakes that most commonly slip through, and how to validate a translated strategy before it goes into a protocol or manuscript.
Why PubMed and Embase Need Separately Written Strategies
PubMed and Embase overlap substantially in what they index, but neither is a subset of the other, and each has its own controlled vocabulary layered on top of free-text indexing. PubMed uses the U.S. National Library of Medicine’s MeSH (Medical Subject Headings) thesaurus. Embase uses Elsevier’s Emtree thesaurus, which is structured differently from MeSH and, owing to Embase’s origins as the Excerpta Medica database, has historically stronger coverage of pharmacology, drug and device literature, and conference abstracts. Running a MeSH-built PubMed strategy verbatim in Embase typically retrieves a much smaller, skewed set of records, because Embase does not recognize MeSH heading syntax and the Emtree hierarchy does not always mirror MeSH’s. Reviewers who copy a PubMed strategy into Embase and change nothing beyond quotation marks routinely under-search the literature without realizing it — the missing records are simply invisible rather than flagged as missing.
Controlled Vocabulary: MeSH vs. Emtree
The starting point for translation is recognizing that MeSH terms and Emtree terms are not a simple lookup table of synonyms. Two behaviors matter most:
- Explosion is not the same by default. In PubMed, searching a MeSH heading (
[mesh]or[mh]) automatically includes its narrower terms in the MeSH tree unless the searcher specifically restricts it with the “do not explode” option ([mesh:noexp]). In Ovid-platform Embase, exploding a heading is opt-in: the searcher has to addexpin front of the subject heading (or check the “Explode” box on Embase.com) to pull in narrower Emtree terms; without it, only records indexed to that exact term are retrieved. - The hierarchies themselves don’t match. Emtree and MeSH are separately maintained thesauri, so a term’s place in one tree does not predict its place in the other. As one academic library’s Embase guidance illustrates, in MeSH Wrist is a narrower term nested under Hand, while in Emtree wrist/ sits at the same hierarchical level as hand/, with both classified as narrower terms of arm/. A translated strategy that assumes MeSH parent-child relationships hold in Emtree will systematically miss or over-include records.
Because of this, controlled-vocabulary translation is manual, concept-by-concept work: for every MeSH heading in the original strategy, look up the closest Emtree equivalent in the Emtree thesaurus (available directly on Embase.com or through the Ovid interface’s built-in mapping), check where it sits in the Emtree hierarchy, and decide explosion and any subheading/qualifier restrictions on their own merits rather than by carrying over the PubMed settings unchanged.
Field Codes and Operators: A Side-by-Side Comparison
Free-text (word-search) elements of a strategy translate more mechanically than controlled vocabulary, but the field codes are not interchangeable strings — each system defines what a “broad” or “title/abstract” search actually includes slightly differently.
| Search element | PubMed | Ovid (MEDLINE/Embase) | Embase.com |
|---|---|---|---|
| Title/abstract | [tiab] |
.ti,ab. |
:ti,ab |
| Title only | [ti] |
.ti. |
:ti |
| Controlled vocabulary heading | [mesh] / [mh] (auto-explodes) |
exp Heading/ to explode; Heading/ for exact term only |
Emtree term with Explode toggle |
| Major-topic / focused heading | [majr] |
Focus search (checkbox) approximates a major-concept restriction | Focus search (checkbox) |
| Broadest word search | [tw] — title, abstract, MeSH terms/subheadings, publication type, substance names, and more |
.mp. — title, abstract, heading word, original title, and related fields; composition is not identical to PubMed’s [tw] |
Equivalent multi-field mapping |
| Truncation | * (also suppresses PubMed’s automatic term mapping) |
$ for unlimited, $N for a limited number of characters |
* |
| Ordered proximity | Not supported as a distinct “ordered” operator | ADJn — terms within n words, in the order given |
NEXT/n — terms within n words, in the order given |
| Unordered proximity | "term1 term2"[tiab:~N] — added to PubMed in November 2022; works only in the [ti], [tiab], or [ad] fields, and cannot be combined with truncation |
Not a native concept the same way; adjacency generally expressed via ADJn |
NEAR/n — terms within n words, in any order |
A useful shortcut when translating into Ovid Embase specifically: because Ovid runs both MEDLINE and Embase on the same platform, its field-code syntax for free-text elements (.ti,ab., .mp., exp) is shared across the two databases, which is why libraries often route both a MEDLINE and an Embase search through Ovid rather than through PubMed and Embase.com separately — it removes one layer of syntax translation, though the MeSH-to-Emtree vocabulary mapping still has to be done by hand either way.
A Practical Step-by-Step Translation Workflow
- Start from a fully documented source strategy. Translation only works line-by-line if the PubMed strategy is saved with its full line history (line numbers, each concept block, and how blocks were combined with AND/OR), consistent with PRISMA-S reporting standards for search strategies.
- Break the strategy into concept blocks. Most systematic review strategies are structured around PICO elements (population, intervention, comparator, outcome, or a subset of these) combined with AND between blocks and OR within each block. Translate one concept block at a time rather than the whole string at once.
- Map each MeSH heading to its nearest Emtree term. Look each heading up individually in the Emtree thesaurus rather than assuming the label matches; confirm where it sits in the Emtree hierarchy and set explosion deliberately for that term, not by default.
- Decide focus/major-topic restrictions on their own merits. If the PubMed strategy used
[majr]to restrict to studies where a concept is a major focus, evaluate whether the equivalent Focus restriction in Embase is still appropriate — it narrows recall in both systems and should be a deliberate choice, not a copied default. - Convert field codes for every free-text line using the table above, checking that the destination field’s scope (e.g.,
.mp.versus PubMed’s[tw]) doesn’t pull in unrelated content such as drug trade names or manufacturer fields that a broad Embase multi-purpose field can include. - Re-examine free-text synonyms rather than reusing the PubMed list unchanged. Embase’s stronger pharmacology/device coverage and its own indexing conventions mean additional free-text terms (brand names, alternate device terminology, conference-abstract phrasing) are often needed to reach comparable sensitivity. Recently published records in either database may not yet be indexed with controlled-vocabulary terms at all, so a translated strategy that relies solely on Emtree headings will systematically miss the most recent literature — free-text terms remain necessary even after controlled vocabulary is translated.
- Rebuild the boolean and proximity structure with the destination syntax (
ADJn/NEAR/nin place of PubMed’s~Nproximity, translated truncation symbols), preserving the original’s logical structure rather than only its keywords. - Pilot-test the translated strategy before finalizing it (see validation section below).
- Document both strategies in full — original and translated, one per database, with line numbers, dates run, and platform/interface used (e.g., “Embase (Ovid)” versus “Embase.com”) — as supplementary material, consistent with PRISMA-S.
Common Pitfalls
- Assuming a 1:1 MeSH-to-Emtree label match. Similarly named terms can sit in different places in the two hierarchies (see the wrist/hand example above), so a term-for-term substitution without checking the Emtree tree can silently narrow or skew results.
- Forgetting Embase’s opt-in explosion. Because PubMed auto-explodes MeSH headings by default, reviewers translating into Ovid syntax sometimes forget to add
exp, producing a translated strategy that looks structurally identical but retrieves far fewer records. - Treating
.mp.and[tw]as equivalent. Both are “broad” multi-field searches, but their exact field composition differs between systems; a straight substitution can introduce noise (e.g., drug trade-name matches) or omit fields the original strategy relied on. - Ignoring proximity-operator order sensitivity. Ovid’s
ADJnand Embase.com’sNEXT/nrequire terms in the order specified, whileNEAR/ndoes not — substituting one for the other changes what gets retrieved. - Relying only on translation software for vocabulary mapping. Semi-automated tools (such as the Polyglot Search Translator) can reliably convert boolean operators, field codes, and truncation symbols, but they cannot map MeSH concepts to Emtree concepts automatically — vocabulary mapping still requires a person checking the thesaurus.
- Skipping documentation of the translated strategy. A translated strategy that isn’t saved with line numbers and platform/date details the same way the original was creates a PRISMA-S reporting gap and makes peer review or replication of the search impossible later.
Validating and Peer-Reviewing the Translated Strategy
A translated strategy should be checked before it is treated as final, not assumed correct because the syntax compiles without errors:
- Test against known relevant records. Compile a small set of studies already known to be eligible for the review (from a prior review on the same topic, hand-searched reference lists, or content-expert recommendations) and confirm the translated Embase strategy actually retrieves them. Records it fails to retrieve point to a specific gap — often a missed Emtree term or an over-restrictive explosion/focus setting — that can be fixed before the search is finalized.
- Sanity-check the result count. A translated strategy that returns a dramatically smaller or larger record set than the source strategy, relative to what’s expected from the two databases’ known overlap, is a signal to re-check the translation rather than proceed.
- Have a second information specialist peer review it. The Peer Review of Electronic Search Strategies (PRESS) checklist, developed for exactly this purpose and published by McGowan and colleagues, gives a structured framework for a second searcher to review Boolean logic, spelling, line combinations, and translation accuracy before the strategy is run for the final review.
- Report both strategies in full. PRISMA-S calls for the complete, executable search strategy for every database searched, including the platform/interface (e.g., Ovid Embase vs. Embase.com) and the date each was run, since results can differ between interfaces even for the “same” database.
Frequently Asked Questions
Can I just copy my PubMed search into Embase and run it as-is?
No. PubMed’s field codes ([mesh], [tiab], [tw]) are not recognized Embase syntax, and even where wording looks similar, Embase’s Emtree vocabulary and field definitions differ from MeSH and PubMed’s field codes. An unedited PubMed strategy run in Embase will either error out or silently retrieve a small, unrepresentative subset of the literature.
Is Embase’s coverage just a subset of what PubMed indexes?
No — the two overlap substantially but neither is a subset of the other. Embase has historically stronger coverage of pharmacology, drug/device literature, and conference abstracts, reflecting its origins as the Excerpta Medica database, while PubMed/MEDLINE has its own distinct coverage. This is a core reason the Cochrane Handbook requires searching both, not just one, for Cochrane reviews.
What does “explode” mean in a database search, and why does it matter for translation?
Exploding a controlled-vocabulary heading tells the database to include records indexed to that heading’s narrower terms, not just the exact heading itself. PubMed does this automatically for MeSH searches; Ovid-platform Embase requires the searcher to add it explicitly (exp), so a direct copy of a PubMed strategy into Ovid syntax without adding exp will under-retrieve.
Are there tools that automate this translation?
Semi-automated tools such as the Polyglot Search Translator can convert boolean structure, field codes, and truncation/proximity syntax between database platforms, which saves time on the mechanical part of translation. They cannot reliably map MeSH concepts onto their nearest Emtree equivalents — that step still requires a person checking the Emtree thesaurus for each heading.
How many databases does a PRISMA-compliant systematic review need to search?
PRISMA 2020 does not fix a specific number, but it requires reporting the full search strategy for every database used and the dates searched. In practice, reviews aiming for comprehensive evidence coverage commonly search MEDLINE/PubMed, Embase, and a trials register such as CENTRAL at minimum; Cochrane reviews specifically are required to search all three.
