Build a PubMed Dataset for a Literature Review
Turn a documented PubMed search into a review-ready dataset with stable identifiers, screening fields, provenance, and transparent exclusions.

A defensible review dataset begins before the export. Record the research question, complete PubMed expression, run date, date filters, and sort mode. Without that provenance, a clean spreadsheet is still hard to reproduce.
Run the documented expression with the PubMed Research Scraper. The output includes screening-friendly fields such as title, abstract, authors, affiliations, publication types, MeSH terms, journal, date, PMID, and DOI. Preserve the raw output as an immutable source table.
Add a separate screening table
Create review columns for include/exclude, exclusion reason, reviewer, review round, and notes. Do not edit article metadata during screening. Link the screening decision back to the source row by PMID.
When combining databases, normalize whitespace and DOI casing, but never merge records solely because titles look similar. Keep a crosswalk of source identifiers and document every automated rule. The Actor accelerates retrieval; methodological decisions remain visible and owned by the research team.
Freeze the search and preserve provenance
Store a manifest with the full search expression, all date bounds, sort order, run ID, collection time, and exported row count. Hash the raw JSON file before screening begins. If the review team changes a synonym or eligibility date later, run a new version and retain the old manifest instead of silently replacing it.
PubMed records can gain an abstract, MeSH terms, or a DOI after first indexing. Keep both the first retrieved record and the most recent metadata snapshot when those changes matter. A metadata update should not become a second screening candidate: PMID remains the stable key, while first_seen_at and last_seen_at describe the collection history.
Design a review-ready data model
Use three linked tables rather than one spreadsheet that mixes source data and decisions:
| Table | Grain | Typical fields |
|---|---|---|
| Articles | One row per PMID | title, abstract, journal, publication date, DOI |
| Search provenance | One row per query run | expression, filters, run date, input hash |
| Screening | One row per PMID and review round | reviewer, decision, exclusion reason, notes |
This structure supports dual screening without overwriting another reviewer's decision. It also lets you rerun metadata collection without erasing the audit trail.
Check coverage before screening
Report duplicate PMIDs, missing abstracts, missing dates, and publication-type coverage before reviewers start. Spot-check the newest and oldest records against their PubMed pages. If multiple databases are involved, retain every source identifier and record which database supplied each field.
The export is a retrieval aid, not a claim that the search is comprehensive. A formal systematic review may require additional databases, citation chasing, protocol registration, and PRISMA reporting. Document those steps outside the Actor so the final evidence package distinguishes collection automation from methodological judgment.
Frequently asked questions
Can this replace a formal systematic-review protocol?
No. It collects records; researchers still define databases, criteria, screening, and reporting.
What is the safest deduplication key?
Use PMID within PubMed, then use DOI cautiously when combining results from other databases.
Related
100 free credits, no credit card.
About 30 real searches. Add the MCP to Claude or Cursor in two minutes.