PRISMA Flow Diagrams From Browser Exports: Counting Without Double-Counting

The PRISMA flow diagram looks like a simple box chart. Producing accurate counts is harder than it appears, because the numbers depend on decisions made during deduplication and screening, and reviewers increasingly ask for the logic behind each box. A browser-assisted workflow can capture those decisions, provided the counting rules are fixed before screening begins.

Fix the counting rules first

Decide what counts as a record. A record is one database entry, identified by its database-specific ID. Two records describing the same paper are duplicates, not one record.

The first box, "records identified", is the sum of per-database results before deduplication. Do not subtract overlapping databases here; the overlap belongs in the duplicates box.

The duplicates box should include both exact duplicates within a database and cross-database duplicates. Report the method: DOI match, title-year match, or fuzzy match with manual review. A number without a method is not reproducible.

Export with stable identifiers

Export from each database with the native record ID, DOI where available, title, authors, year, and source. Keep the raw export files. They are the audit trail.

PubMed, Scopus, and Web of Science use different ID schemes, so a unified key is necessary. Use DOI first; when absent, use a normalized title plus year. Store both the original ID and the unified key so you can trace a record back.

Deduplicate in stages

Run exact DOI matching first and count removals. Then exact normalized title matching. Then fuzzy matching above a similarity threshold, with a human reviewing each proposed merge.

Record counts after each stage. If a reviewer asks why 4,312 minus 1,208 is not 3,104, you need to show where the difference went.

Fuzzy matching is where errors hide. Two papers with the same title in different years are usually distinct; the same title in the same year with different authors is often a preprint and its published version. Treat those merges as decisions, not automation.

Track screening exclusions with reasons

Title and abstract exclusions need a reason category: wrong population, wrong design, wrong outcome, not peer reviewed, duplicate. Full-text exclusions need the specific criterion from the protocol.

A browser-based screening tool that stores the reason per record produces these counts directly. A spreadsheet works too, as long as the reason column is filled at the time of the decision rather than reconstructed later.

Reporting automation honestly, and the final check

If AI assisted screening, say so in the methods: which model, which prompt or criteria, whether it ordered records or filtered them, and how many records a human reviewed. PRISMA 2020 includes an item for automation tools, and omitting it is a methods weakness.

Include the counts removed by automation separately from human exclusions. A diagram that implies humans screened everything when a model filtered 80% is misleading even if the final inclusion set is correct.

Recompute the diagram from the raw exports and your decision log, then compare with the manuscript. The arithmetic should close: identified minus duplicates minus exclusions equals included. If it does not, the diagram is describing a different process than the one you ran.

Where the numbers go wrong, and building the arithmetic check

Three discrepancies account for most PRISMA errors.

First, database counts include results removed before export by the interface's default filters. Record the interface, the filters, and the result count at the moment of export.

Second, citation tracking adds records that are not in any database export. Put them in a separate row or note, not in the initial identified count.

Third, full-text retrieval failures are reported as exclusions in some templates and as "not retrieved" in others. PRISMA 2020 distinguishes them; follow the current template rather than an older example.

Write the flow as a small calculation with named variables: identified, duplicates, screened, excludedTitleAbstract, retrieved, excludedFullText, included. Assert that the equation closes before submission.

If it does not close, the difference is usually records excluded in the tool but not in the spreadsheet, or duplicates merged after screening began. Reconciling after screening is painful; record decisions as you go.

Duplicates by database, automation reporting, and supplementary material

A table of duplicates removed per database pair is useful for readers reproducing the search. It also reveals an export that was not deduplicated at all.

Do not report a single duplicates number if the process ran in stages. Report the count after each stage and the method used.

The PRISMA 2020 checklist includes an item for automation tools used in screening. Name the tool, the model version if applicable, the task it performed, and the human oversight. Vague statements such as "AI-assisted screening" invite reviewer questions.

Report the number of records the tool prioritized, filtered, or flagged, and how many humans reviewed.

Include the search strings with dates, the export counts, the deduplication script or rules, and the screening decision log if the journal permits. Reviewers increasingly request the raw exports.

Store all of this in a repository with a DOI if the journal requires data availability. It makes the review auditable and saves correspondence during revision.

Archiving the search, screening, and reporting

Export each database's results with the query and date. Store them alongside the review protocol.

If a database changes its interface, the export is the only reproducible record.

State whether a model ranked, filtered, or summarized records, and how many humans reviewed each stage. Reviewers increasingly ask.

For an update, rerun the search from the last date and report the new records separately. Combining old and new counts hides the update's yield.

Record a decision for every record, including the ones excluded on title alone. PRISMA counts require the numbers to reconcile at each stage, and "excluded without record" breaks the flow diagram.

Use two independent screeners on a sample and report agreement. A single screener on everything is a limitation worth stating.

Give the full query for each database, not a description of it. The date of the search and the interface used belong in the same block.

If a database was searched through a vendor platform, name the platform. The same database behaves differently across interfaces, and reviewers replicate the interface.