How to Use EvidenceTableBuilder in a Real SLR Workflow (Step-by-Step SOP)

TL;DR

Use EvidenceTableBuilder as a workflow system, not as a summarizer.

The highest-leverage setup is:

lock your extraction schema first
run AI first-pass extraction
verify high-risk fields with humans
export audit-ready evidence tables for synthesis

This guide is an operational SOP for teams running systematic reviews in HEOR, market access, and evidence synthesis.

Scope: where this fits in an SLR

EvidenceTableBuilder sits primarily in:

full-text data extraction
evidence table standardization
QA and traceability preparation

It supports faster extraction, but the bigger gain is reducing reconciliation rework later in the review.

If you need the full review lifecycle, start with What Are the 7 Steps of a Systematic Review?.

SOP: how to run the tool in production

Step 1: define extraction objectives before upload

Before adding PDFs, write down:

primary decisions the review must support
outcome domains and preferred timepoints
required denominator/effect-size rules
critical vs non-critical fields

This avoids the most common failure mode: extracting a lot of data that cannot be synthesized cleanly.

Step 2: lock schema using one-variable-per-column

Design columns so each asks for one thing only.

Good:

"Mean age at baseline (years)"
"Primary endpoint at week 12 (definition as reported)"
"Risk ratio for outcome X (95% CI)"

Weak:

"Extract demographics and key outcomes"

For column logic, use What Columns Should an Evidence Table for a Systematic Review Include?.

Step 3: batch upload and run first pass

Upload studies in coherent batches (for example by intervention class, design type, or endpoint family). Smaller coherent batches reduce QA burden.

The first pass is a draft, not a final output.

Step 4: verify by risk tier

Use a simple verification policy:

Tier A (always verify): primary outcomes, key comparators, effect sizes, adverse events
Tier B (sample verify): secondary outcomes and baseline descriptors
Tier C (spot check): low-impact metadata

Step 5: resolve discrepancies with explicit rules

When disagreements appear, log a short rule:

preferred timepoint hierarchy
preferred analysis set (ITT vs PP)
handling of subgroup-only reports
missingness labels ("not reported", "unclear", "not extractable")

Reuse these rules in future batches to improve consistency and speed.

Step 6: export and freeze evidence table version

Export to Excel/Sheets, freeze version, and link final table to synthesis outputs. If you run multiple extraction rounds, maintain versioned tables instead of overwriting.

Quality controls that prevent rework

Apply this checklist before scaling:

pilot schema on 3-5 studies
confirm all critical outcomes have explicit definitions
separate effect estimates from confidence intervals
confirm units and timepoint labels are explicit
verify traceability is available for high-stakes values

If this checklist fails, refine schema before continuing.

Common implementation mistakes

Treating the tool like a chat interface

Result: narrative output that cannot be compared across studies.

Combining multiple variables in one column

Result: mixed values, broken filtering, difficult synthesis.

Starting extraction before rules are defined

Result: large reconciliation overhead and delayed analysis.

No risk-tier verification

Result: too much time spent checking low-impact fields and not enough on decision-critical values.

When this workflow is most useful

This SOP is strongest when teams are:

extracting from multiple full texts with similar question structures
preparing HTA or market-access evidence packs
producing defensible internal evidence summaries
handling tight timelines with limited extraction capacity

Final thought

The best way to use EvidenceTableBuilder is to treat it as a structured extraction pipeline: AI for speed, humans for judgement, and clear rules for consistency.

That combination scales better than either manual-only or automation-only approaches.