Data Extraction Checklist for Systematic Reviews and Meta-Analysis

Data extraction is where a systematic review stops being a list of included studies and becomes a dataset you can actually pool.

It is also where small omissions compound. A missing sample size, an unrecorded unit, or a standard deviation that was never distinguished from a standard error does not usually surface until analysis—by which point tracking it down means reopening a PDF, or worse, emailing a study author who may not reply.

This checklist groups what to extract into the categories that actually matter for pooling and reporting: identification, methods, population, intervention, outcomes, and the specific details that feed a Cochrane RoB 2 judgement. Treat it as a floor, not a ceiling—a protocol-specific review will always need fields this general checklist cannot anticipate.

Before you extract anything: align to the protocol

Extraction fields should be decided before the first study is opened, not discovered one study at a time. Pull three things directly from your protocol or PICO:

• The pre-specified outcomes, in the order you intend to report them.
• Whether each outcome is dichotomous (events/total) or continuous (mean/SD/N), since that determines which columns the extraction table needs.
• The comparison(s) you plan to pool—extracting the wrong arm as the comparator is a common, late-discovered error in multi-arm trials.

EvidenceFlow’s free extraction table template starts from this exact column set, with a worked example filled in.

1. Study identification

Capture this once, correctly, and every later table and citation reuses it without re-checking the paper.

2. Study design and methods

This section is also where most of the raw material for a risk-of-bias judgement actually gets captured—extract it in enough detail to answer the RoB 2 signalling questions later, not just a design label.

3. Population characteristics

• Total sample size, and sample size per arm.
• Age (mean/median and range or SD) and sex/gender distribution, per arm if reported separately.
• The specific inclusion and exclusion criteria actually applied by the study - not the review’s own criteria.
• Baseline comparability between arms - an imbalance here is a direct input to RoB 2 Domain 1.

4. Intervention and comparator

Vague intervention descriptions are one of the most common reasons a meta-analysis gets challenged at peer review. Record enough that someone who has never read the paper could describe what was actually compared.

• Intervention: dose, frequency, duration, and delivery method.
• Comparator: placebo, active comparator, usual care, or waitlist - and what that actually consisted of.
• Co-interventions permitted in either arm, if the paper reports them.

5. Outcome data - the fields that actually get pooled

This is the section worth the most care, because the raw numbers determine which effect measures are even computable. Prefer raw counts or summary statistics over a pre-calculated effect size whenever the paper reports both.

Never back-calculate a raw count from a percentage and a sample size to fill a gap, and never fabricate an effect size when only raw counts are available - record what the paper actually reports, and flag what it does not.

6. Missing data and provenance

• If an outcome is missing for some participants, record how many and why - this is the raw material for RoB 2 Domain 3, not a footnote to skip.
• For every number that will enter a forest plot, note where it came from - page number, table number, or figure - so a disagreement at analysis time is a two-minute lookup instead of a re-read of the full text.

Common extraction mistakes this checklist exists to prevent

• Recording a percentage instead of the raw event count and denominator.
• Not distinguishing standard deviation from standard error.
• Extracting from the wrong comparator arm in a multi-arm trial.
• Treating a conference abstract and its later full publication as two separate studies.
• Copying a published OR or RR when the paper also reports raw counts that would let the review compute it consistently with every other included study.
• Leaving a field blank instead of recording "not reported" - a blank looks like an oversight; "not reported" is itself a finding.

Dual extraction and reconciliation

Where resources allow, two reviewers extracting independently and reconciling disagreements catches far more errors than a single extractor, however careful. At minimum, a second reviewer should verify the outcome data and risk-of-bias fields on a random sample of included studies, since those are the fields most directly feeding the pooled result.

Turning this checklist into a working table

A checklist tells you what to capture; a table is where you actually capture it. EvidenceFlow’s free data extraction template is this exact field set, already laid out in Excel and CSV, with a worked example filled in so you can see the expected format before starting your own.

For reviews with a dual-review workflow, AI auto-fill, or risk-of-bias assessment built around the same records, continue with the full data extraction and risk-of-bias guide.