Overview
The PRISMA 2020 flow diagram is the standard way to show how records move through a systematic review—from how many you found to how many studies you included. It helps readers and peer reviewers see what you searched, how you screened, and why items were excluded. This aligns with the updated PRISMA 2020 statement, which emphasizes transparent reporting of identification, screening, eligibility, and inclusion.
In practice, tally counts at each stage and display them as a simple flowchart. For example, you might identify 3,200 records across databases and trial registers, remove 900 duplicates, screen 2,300 records by titles/abstracts, assess 240 full-text reports, and include 42 studies in syntheses.
To build confidence, cite PRISMA 2020 in your manuscript and keep the diagram synchronized with your methods section. Create the diagram only after your counts and reasons are final.
PRISMA 2020 vs 2009: what changed and how to migrate
PRISMA 2020 revised the flow diagram to reflect modern sourcing, deduplication, and study/report relationships. Key updates include explicit boxes for different sources (databases, registers, websites/organisations), a separate box for records removed before screening (duplicates and other automation), and a clear distinction between “reports” and “studies” for included items, as set out in PRISMA 2020.
If you have a 2009 diagram, map old nodes to the new structure. Split “records identified through database searching” into databases and registers if applicable, add a node for records removed before screening (deduplicated or excluded via automation), and separate “full-text articles assessed” into “reports sought,” “not retrieved,” and “reports assessed for eligibility.”
Finally, report “studies included” and, if you have multiple reports per study, also provide the “reports included” count. Note in your methods that you followed PRISMA 2020 and adjusted the flow diagram accordingly. Before you finalize, rerun simple arithmetic checks so the totals add up.
Records, reports, and studies: precise definitions with examples
In PRISMA 2020, a record is a bibliographic entry you screen, a report is a document that presents study findings (e.g., article, preprint, conference paper), and a study is the underlying investigation that one or more reports describe. The Cochrane Handbook uses similar distinctions to prevent double counting.
Consider three scenarios. First, one RCT appears as a preprint and later as a journal article. Those are two reports describing one study, and both may appear as separate records in your search results.
Second, one cohort study yields two separate journal reports (baseline and long-term outcomes). That’s two reports for one study.
Third, a multi-arm trial publishes a primary paper and a cost-effectiveness paper. Again, multiple reports of one study.
In your diagram, records are counted at screening, reports are counted at full text and inclusion, and studies are counted at inclusion. To stay consistent, keep a study–report linkage table so you can trace which reports roll up to which studies.
Which PRISMA flow diagram to use by review type
Use the PRISMA 2020 flow diagram for interventional and observational systematic reviews that synthesize research studies. For scoping reviews, use the PRISMA-ScR diagram from the extension.
For rapid reviews, adapt the PRISMA 2020 diagram but document any streamlined steps. For living reviews, reuse the PRISMA 2020 diagram across updates and clearly show what is new versus cumulative.
For scoping reviews specifically, the PRISMA-ScR extension aligns the flow diagram and checklist to mapping the evidence rather than evaluating effect sizes. Scoping reviews often include broader sources (e.g., policies, guidelines, conference papers), which should be reflected in your identification and screening counts.
Choose the diagram that corresponds to your review’s objectives and note the extension you followed in your methods.
Systematic vs scoping (PRISMA-ScR) vs rapid vs living reviews
Systematic reviews aim to answer focused questions with critical appraisal and often meta-analysis. The PRISMA 2020 diagram is the default.
Scoping reviews map a field, identify evidence types, and clarify concepts. PRISMA-ScR is purpose-built for that.
Rapid reviews compress timelines by simplifying methods (e.g., single screener with verification). Use the PRISMA 2020 diagram with annotations about your shortcuts.
Living reviews continuously update as new evidence appears. Reuse the same PRISMA 2020 structure, but indicate the date of each update and whether counts are cumulative or specific to the cycle.
Whichever you select, keep labels and reasons consistent so that readers can interpret your flow accurately.
Step-by-step: filling out each box correctly
Think in four stages: Identification, Screening, Eligibility, Inclusion. Sum counts within each stage and ensure inflows minus outflows equal the next box.
For example, records identified minus records removed before screening equals records screened at title/abstract. Records screened minus excluded equals reports sought for retrieval.
Document any automation (e.g., deduplication, machine learning exclusion) and maintain a log of reasons for exclusion at the full-text stage. If you operate multiple screening rounds or updates, keep a versioned spreadsheet so you can reproduce any number in the diagram.
Before export, run a final audit. Every exclusion has one reason, records-to-reports mapping is clear at full text, and included studies equal the number used in your synthesis tables.
Identification stage
Count everything you searched and where it came from. Databases (e.g., MEDLINE, Embase), registers (e.g., trial registries), websites/organisations, and other methods (e.g., citation chasing) should be itemized.
Preprints and registry entries belong under the source where they were discovered. For example, if a preprint came from a database via a preprint filter, it is a database record, while a trial record found in a register is a register record.
Deduplicate before screening and report how many records you removed. If you used automation to remove obviously irrelevant records (e.g., non-human studies), report those “records marked as ineligible by automation” separately from duplicates.
Keep a minimal dedup log noting tools used, fields matched, and counts removed, so your identification math is auditable. As a quick check, “records identified” minus “records removed before screening” should equal “records screened.”
Screening stage
Screen titles and abstracts to exclude clearly irrelevant records. The count in this box is the number of records that a human or validated automation actually screened. Do not include items removed during deduplication or automation pre-filtering.
If an automation tool excludes records at this stage based on a trained classifier, document the process. Record the number excluded by automation versus manual decisions.
Record the number of records excluded at title/abstract with a top-level reason category that matches your eligibility criteria (e.g., wrong population, wrong study design). If you use multiple screener agreement or conflict resolution, note that in methods, but the flow diagram only needs total counts.
Ensure “records screened” minus “records excluded” equals “reports sought for retrieval.”
Eligibility stage
Count the number of reports for which you sought full text, the number not retrieved, and the number assessed for eligibility. “Not retrieved” should be reserved for items you attempted and failed to obtain.
Language barriers, paywalls, and unavailable archives typically fall here, even if you attempted interlibrary loan.
For reports assessed, provide exclusion reasons at full text using mutually exclusive, collectively exhaustive categories (e.g., not primary research, wrong outcome, duplicate report of included study). The Cochrane Handbook recommends clear and reproducible reasons so others can follow your decision path.
Before you finalize, confirm “reports assessed” equals “reports sought” minus “not retrieved.” Also confirm that “reports assessed” minus “reports excluded” equals “reports included.”
Inclusion and synthesis stage
Report the total number of studies included in the review and, optionally, the number of reports included. If multiple reports describe one study, count them once as a study and list the multiple reports in your study characteristics.
If you conduct separate syntheses (e.g., meta-analysis for RCTs and narrative synthesis for observational studies), you may add counts by synthesis group in your text or appendix. The flow diagram’s top line remains the total included studies.
To avoid double counting, maintain a study ID that links all reports to one study and use that to roll up counts. A common pattern is “42 studies (56 reports) included,” which signals that multiple publications mapped to some studies.
Make sure the studies included in the flow diagram match the studies analyzed in your results tables.
Counting edge cases: preprints, trial registries, data repositories, and grey literature
Treat preprints as reports identified from their source (database or preprint server) and screen them like any other report. If a preprint later appears as a journal publication, link them as two reports of the same study.
If both were screened, the preprint may be excluded at full text as a “duplicate report.” For trial registries, count each registry entry as a record from a register, and link the registry entry to published reports when they appear. Register searches commonly include ClinicalTrials.gov and the WHO International Clinical Trials Registry Platform.
Data repositories (e.g., datasets without accompanying articles) may be eligible in some reviews. Count them under websites/organisations or other methods depending on your search strategy, and treat the dataset as a report if it contains analyzable results.
Grey literature such as conference abstracts, theses, and reports should be counted based on where you found them (databases, websites) and screened using the same criteria. In all cases, the action is the same: classify by source at identification, screen and deduplicate as needed, and decide at full text whether the item is a unique report of an eligible study.
Handling languages, translations, retractions, and conference abstracts
For non-English records, count them throughout the flow like any other item. If you exclude a report because translation was not feasible, record it as “not retrieved” if you could not obtain a readable version, or as “excluded: language not eligible” if language was an explicit criterion.
Whenever possible, note how translations were handled in methods to preempt reviewer questions.
Retracted items should be excluded at the earliest confirmed point with a clear reason such as “retracted.” If you discover retraction after inclusion, document the decision in your results and update the flow if it changes counts.
Conference abstracts are reports; include them when they meet your criteria or exclude them with a reason such as “insufficient data.” To avoid confusion, add a short note in your methods about whether you included preprints and abstracts and how you resolved duplicates across versions.
Tools comparison and costs: Covidence, Rayyan, DistillerSR, EPPI-Reviewer, and PRISMA Shiny
Several tools can help you generate a PRISMA 2020 flow diagram and keep counts consistent. Covidence, Rayyan, DistillerSR, and EPPI-Reviewer manage screening decisions and export counts; the PRISMA 2020 Shiny app turns your final numbers into a compliant diagram.
Pick based on team size, budget, audit needs, and interoperability with your reference managers or analysis tools. Use screening software to capture decisions and reasons as you go, then export counts into the PRISMA 2020 flow diagram generator (Shiny app) to produce publication-ready graphics.
The Shiny app accepts manual entry or CSV inputs and exports PDF/PNG/SVG/HTML diagrams, which suits most journals. Whatever you choose, confirm the tool supports PRISMA 2020’s specific fields (e.g., automation exclusions, reports vs studies) before you start.
Feature and compliance overview
Choose tools that support reliable deduplication, transparent exclusion reasons, PRISMA 2020 fields, and audit logs. Look for:
- Deduplication workflows with configurable match rules and logs.
- Customizable reasons for exclusion at title/abstract and full text.
- Separate capture of automation-assisted decisions (e.g., classifier exclusions).
- Exports that include records, reports, studies, and counts needed for each PRISMA 2020 node.
Before committing, run a small pilot on 200–300 records to confirm the tool’s reason taxonomy, dedup performance, and export structure match your protocol and the PRISMA 2020 diagram.
Pricing and licensing snapshot
Expect a range from free/freemium to enterprise licenses. Rayyan offers a free tier with paid upgrades; Covidence and EPPI-Reviewer typically use per-user or institutional subscriptions; DistillerSR is enterprise-focused; the PRISMA Shiny generator is free.
Because pricing changes, verify current costs and storage limits directly with vendors. Balance cost against needs: small academic teams often combine a freemium screener with the free PRISMA Shiny generator, while regulated environments may require enterprise audit features and dedicated support.
Factor in the number of collaborators, need for API access, and institutional licenses you may already have.
Export and interoperability
Plan your data flow from the outset. You will likely export RIS/CSV files from reference managers, import them to a screening tool, then export screening decisions to a CSV that feeds the PRISMA diagram generator.
Confirm that:
- You can export counts by reason and stage (title/abstract vs full text).
- The tool provides a dedup report you can archive.
- CSVs include stable IDs so you can reproduce counts in R or Python if needed.
If you maintain analysis scripts, ensure exports are machine-readable and versioned. This makes it easy to regenerate your diagram and align counts with your manuscript if peer reviewers request changes.
Reproducibility and audit-readiness: logs, version control, and PRISMA-S crosswalk
Reproducibility rests on three logs: search, deduplication, and screening decisions. Use a version-controlled folder to store search strategies, date-stamped export files, and the scripts or tools used to process them.
The PRISMA-S extension provides a structured way to report search elements that map naturally to the flow diagram nodes; see the PRISMA-S checklist. Keep a short README that explains your workflow and references your protocol.
If your journal allows, share de-identified screening data and your final PRISMA diagram CSV as supplementary files. This transparency reduces later queries and supports reuse.
Mapping PRISMA-S fields to PRISMA 2020 nodes
PRISMA-S focuses on reporting the search, including databases, platforms, search dates, strategies, and export details. You can map PRISMA-S items to PRISMA 2020 nodes by:
- Using PRISMA-S “information sources and interfaces” to populate the Identification sub-boxes (databases, registers, websites/organisations).
- Using PRISMA-S “search strategies and dates” to annotate the Identification narrative.
- Using PRISMA-S “deduplication methods” to justify the “records removed before screening” count.
Set up a simple crosswalk spreadsheet so each source and export documented in PRISMA-S rolls up to a specific PRISMA flow node. This enables semi-automated population of counts and reduces transcription errors.
Documenting deduplication across EndNote, Zotero, and automation
Document deduplication so another team could reproduce it. A minimal dedup log should note: tools used (e.g., EndNote, Zotero, scripting), match keys (e.g., DOI, title+year), steps and order, number of records removed at each step, and whether a manual review was performed.
For example, you might run automatic DOI-based matching in EndNote, then fuzzy title matching in Zotero, then a manual sweep of remaining candidates. If you used an automation tool to flag probable duplicates, record thresholds and any spot-check accuracy.
Save pre- and post-dedup files with timestamps so you can reconcile any later discrepancies.
Updated and living reviews: preserving prior counts and running updates
For updated reviews, report both the cumulative counts and the counts for the new search cycle. The simplest approach is to retain the original PRISMA diagram in an appendix and present a new PRISMA 2020 diagram for the update, clearly labeled with the date range.
In your narrative, state how many additional records were identified, screened, and included in the update. Note how these changed the totals.
For living reviews, maintain a master dataset and regenerate the diagram at each update using consistent methods. Note the update date on the diagram and in the caption, and decide whether you present cycle-specific or cumulative counts.
Whichever you choose, be explicit in the figure legend and methods. Align your practice with recognized living review guidance so readers can interpret changes over time.
Programmatic generation in R and Python
You can generate a PRISMA 2020 flow diagram programmatically by structuring your counts in a small CSV and using either a dedicated app or a plotting library. The core idea is to keep a tidy table with one row per PRISMA node and fields for the label and count, then render to vector or bitmap graphics for submission.
In most cases, it’s fastest to prepare counts in a CSV exported from your screening tool and import them into a visual generator. Where you need reproducibility in analysis pipelines, store the CSV alongside scripts that regenerate the diagram and manuscript figures from the same source of truth.
R package and Shiny workflows
A popular option is the PRISMA 2020 flow diagram generator (Shiny app), which supports manual entry, CSV uploads, and URL parameters for automation. You can export diagrams in PDF, PNG, SVG, or interactive HTML, which covers most journal requirements and enables web supplements.
For reproducible pipelines, mirror the Shiny app’s CSV structure, save counts as part of your analysis outputs, and render the diagram as a scripted step. This ensures your diagram updates automatically if counts change during peer review or when you issue an update.
Python examples and visualization options
In Python, organize your counts in a CSV with columns for node name, label text, and value, then read it into your analysis environment. Use common plotting libraries to draw labeled boxes and arrows, or generate SVGs programmatically so text remains crisp in print.
Keep the script simple and modular: a loader for counts, a layout function to position nodes, and an exporter to save PDF/SVG. To preserve auditability, generate the diagram from the same data files that drive your study selection tables.
Saving the script and input CSV in version control lets your team regenerate the figure easily and keeps the diagram synchronized with your manuscript.
Journal and funder requirements you should know
Most health and social science journals endorse PRISMA and expect a PRISMA 2020 flow diagram for systematic reviews. Funders and registries often require adherence to reporting standards in protocols and final reports, and peer reviewers commonly check PRISMA compliance.
Some journals accept scoping reviews under PRISMA-ScR with an adapted flow diagram, and rapid reviews with clearly documented deviations. To demonstrate adherence, cite PRISMA 2020 in methods, include the flow diagram as a figure, and provide your PRISMA checklist as supplementary material.
If your review type follows an extension (e.g., PRISMA-ScR), state that explicitly. When in doubt, check the journal’s author guidelines and match your diagram’s labels to their preferred terminology.
Common mistakes and peer-review pushback: how to avoid them
The most frequent issues are math mismatches, misclassification of records vs reports vs studies, missing or inconsistent exclusion reasons, and unreported automation or dedup steps. Reviewers also flag diagrams that don’t match the methods or where included studies in the flow don’t match the results tables.
Use this quick checklist:
- Totals add up at each arrow; no negative or orphan counts.
- Records, reports, and studies are used consistently across stages.
- Deduplication and automation are disclosed with counts.
- Full-text exclusion reasons are mutually exclusive and exhaustive.
- The number of included studies matches the number analyzed in results.
Before submission, have someone outside the screening team reproduce the counts from your logs. This independent check catches most arithmetic and classification errors.
Examples and benchmarks to sanity-check your numbers
Here are three mini-scenarios to illustrate coherent flows. New review: 5 databases and 2 registers yield 4,800 records; 1,300 duplicates are removed; 3,500 records are screened; 3,100 are excluded at title/abstract; 400 reports are sought, 20 are not retrieved, 380 are assessed; 320 are excluded at full text; 60 studies (78 reports) are included.
Updated review: a 12‑month update adds 1,100 records; 350 duplicates are removed; 750 records screened; 670 exclusions; 80 reports sought, 5 not retrieved, 75 assessed; 62 exclusions; 13 new studies (14 reports) included. Living review: across three cycles, the cumulative total reaches 85 studies (110 reports), while the latest cycle adds 6 studies.
As you sanity-check, keep three evidence-based anchors in mind. First, PRISMA 2020 explicitly distinguishes “records removed before screening” from “records excluded,” so your counts should show both as defined in the PRISMA 2020 statement.
Second, exclusion reasons at full text should be clear and reproducible, a practice reinforced in the Cochrane Handbook. Third, living reviews should describe update cycles and whether counts are cumulative or cycle-specific; consistent reporting across updates aids interpretation.
For benchmarking, compare your duplicate rate and retrieval success to your field norms, but expect variation by topic and source mix. If anything looks off—such as more reports included than reports assessed—return to your logs and fix the underlying mapping between records, reports, and studies before you finalize the figure.