PlagiatScanner

Source evaluation · template · QUE-06

How to document a systematic literature search

In brief: For every database, record the platform, date, complete query, fields, filters and result count. Then preserve exports, deduplication, inclusion and exclusion criteria, and decisions at title, abstract and full-text stages. Keep raw exports unchanged and maintain a versioned decision file. This creates a checkable route from research question to included literature.

Database–query–results–selection protocol

One row for every executed search
Field Record
Search ID Unique identifier linked to the question
Database Name, platform and subject coverage
Time Date and, for dynamic collections, time where material
Query Exact syntax, fields, brackets, phrases and operators
Limits Date, language and document type; expose defaults
Results Displayed count and number actually exported
Export Filename, format, version and checksum
Selection Duplicates, screening stage, exclusion reason and final set

Supporting files: concept matrix, untouched exports, duplicate log, screening register and protocol version history.

Translate the question into concepts

Separate the research question into meaningful concepts before writing a long query. Gather synonyms, controlled terms, spellings and translations for each. Record where key vocabulary came from: scoping searches, thesauri, known papers or subject advice. An AI suggestion is only a candidate until tested in real databases.

Define eligibility criteria before the main screening. Population, topic, period, publication type, language and methodological requirements should remain distinct. Do not tighten criteria after encountering inconvenient evidence without recording the amendment. “Too many results” is not by itself an academic rationale for excluding a perspective.

Translate syntax for each platform

Do not paste one query unchanged into every interface. Field codes, truncation, phrase rules, proximity operators and controlled vocabularies differ. Preserve the query actually run in each database. Screenshots can support the record, but copyable text is more useful for repetition. Note automatic mapping or term expansion shown by the system.

  1. Create a small test set of known relevant studies.
  2. Use their records to identify terms and subject headings.
  3. Run a broad pilot and inspect patterns of irrelevant retrieval.
  4. Revise with a reason and preserve every version.
  5. Freeze the final run with date and result count.
  6. Name and archive the raw export immediately.

A large result set is not a quality measure. Aim for justified sensitivity without filters that silently remove relevant viewpoints. Distinguish database from host platform where alternative interfaces implement syntax differently.

Make duplicate and screening decisions traceable

Keep all raw files before merging. Record software and rules used for duplicate detection. Matching DOI is helpful, but records without correct identifiers require title, author and year comparison. A preprint and version of record are related, yet not always simple duplicates; decide according to question and publication status.

Record who screened at each stage. Standard categories may suffice for title and abstract review. At full text, retain one primary reason for each excluded work. “Not relevant” is usually too vague; wrong population, design, publication type or date is more inspectable.

A tidy protocol does not automatically make a review methodologically systematic. Registration, independent screening, appraisal and reporting depend on the question, discipline and review type.

Report amendments and counts honestly

When a pilot changes the strategy, preserve old and new versions, date, reason and effect. Repeat affected searches or justify the chosen remedy. Failed searches belong in the internal record because they explain the final strategy. Published reporting can show a readable final query while an appendix preserves complete strings.

Reconcile counts across export, deduplication, screening and flow diagram. Explain differences. Use stable internal IDs so title or metadata corrections do not create double counts. An update is a new run with a new cut-off date, not an overwrite of the original evidence.

The source evaluation hub connects identity and quality checks. Checking a DOI assists deduplication. The academic writing overview locates searching within the wider project.

Submission audit

  • Does every search include platform, date and exact query?
  • Are automatic and manual limits visible?
  • Do displayed and exported counts reconcile?
  • Are raw files unchanged?
  • Are duplicate rules and version choices explained?
  • Were criteria defined before selection and amendments dated?
  • Does every full-text exclusion have an intelligible reason?
  • Can every reported count be derived from the files?

Open the package in a clean environment. Can queries be copied, files opened and IDs connected? Another person should be able to follow one included and one excluded item from raw result to decision. That test is stronger than a visually complete spreadsheet.

Turn the search trail into an auditable decision log

A defensible protocol does not stop when records have been exported from a database. At every screening stage, record who made the decision, which version of the record was inspected and which predefined reason applied. A note such as “not relevant” is too vague to audit. More useful categories include an ineligible population, the wrong study design, an unreported outcome or a full text that could not be obtained. Define those categories before screening and document any later refinement rather than silently changing the rules.

Duplicates also require judgement. One study may surface as a preprint, a conference abstract and a journal article. A similar title is therefore neither sufficient reason to delete a record nor proof that two records represent separate evidence. Compare authorship, dates, identifiers, samples and reported findings. Link related manifestations in the log and state which version informed the synthesis. This prevents one underlying dataset from being counted several times without obscuring its publication history.

Before submission, run a small reproducibility check. Give a second reviewer the database, platform, search date, exact query and limits, but not the exported results. They should be able to repeat the technical procedure and explain any discrepancy. Database holdings change, so an identical result count is not always realistic. The stronger test is whether the documented route and decision rules make differences understandable and permit a later reader to reconstruct what was actually searched.

Methodological foundations