Systematic Review Data Extraction Form Template

A flat form can manufacture ambiguity

A systematic review does not extract a study as one undifferentiated object. It collects evidence from reports, resolves those reports to investigations, describes study and arm characteristics, and records repeated outcome estimates. A spreadsheet that places one publication in each row and mixes all these levels in adjacent columns may appear efficient, yet it creates uncertainty about what a value represents. When one study has several reports, one report has several arms, or one outcome is reported at several time points, the row ceases to have a stable scientific meaning.

The form must therefore be designed from the intended synthesis rather than from the visual convenience of a spreadsheet. Cochrane guidance recommends linking multiple reports of one study, piloting collection forms, recording the source of information, and retaining both reported and derived data.¹ The protocol and analysis plan determine which characteristics and outcomes are required. PRISMA 2020 then requires transparent reporting of how collection was performed, including reviewer independence and automation.^2,3 None of these standards endorses an unmodified universal form.

The practical risk is not restricted to typographical error. Extraction includes interpretation: deciding which analysis population a denominator represents, whether a value is adjusted, which time point matches the protocol, whether two reports describe the same participants, and whether an outcome is reported in a usable form. The record must preserve those decisions so that later reconciliation does not depend on memory.

Use connected registers instead of one overloaded row

The template uses five conceptual registers: report, study, arm, outcome and estimate. These can be implemented as separate sheets, database tables or repeated form sections. The essential requirement is that every record carries stable identifiers that permit a controlled join. Report-level fields include citation, source role and evidence location. Study-level fields describe the underlying investigation. Arm-level fields describe interventions, exposures or groups. Outcome-level fields define the construct and measurement context. Estimate-level fields contain the reported value, dispersion, unit, denominator and analytical status.

This architecture also controls repetition. Funding or study design should not be copied into every outcome row because later corrections could leave inconsistent versions. Conversely, an outcome measure should not be stored only at study level when its definition or instrument differs across arms or time points. Normalised storage can later be converted into a wide table for analysis (see the study characteristics table template); converting an ambiguous flat file back into its true entities is much harder.

Write the data dictionary before the main extraction

Each field needs a definition that a second qualified reviewer can apply. State the entity level, permissible type, unit, source priority, controlled vocabulary and missing-information states. For outcomes, specify construct, instrument, direction, metric, time window and analysis population. For estimates, identify the reported statistic and all inputs needed for any planned transformation. If the field feeds a subgroup or sensitivity analysis, record the operational rule that assigns categories.

Distinguish “not reported”, “unclear”, “not applicable” and “not sought”. An empty cell is not a scientifically interpretable status. It can indicate absence, incomplete work, a data-entry failure or a field that does not apply. Explicit codes allow the team to identify incomplete extraction and later evaluate whether missing information is patterned by study or outcome.

Controlled vocabularies should remain readable. Store a stable code for computation and a reader-facing label for interpretation. Avoid abbreviations that depend on one person’s memory. Where an open-text note is necessary, retain it alongside rather than instead of the structured field. The dictionary should travel with every export and should be versioned whenever definitions change.

Pilot for representational failure

Select studies that stress the proposed structure: multiple reports, multiple arms, repeated time points, alternative outcome instruments, incomplete reporting and at least one complex analysis. Reviewers should extract independently under the intended workflow and compare not only values but entity assignments, source choices and interpretations. No universal pilot sample size has been established for all reviews; the sample should be justified by the diversity and risk of the evidence base.

Record every substantive revision, its rationale, approver and effective version. If a field definition changes after records have been collected, determine whether previous records require re-extraction or mapping. Do not silently modify labels in a way that makes earlier and later entries appear equivalent. A pilot is successful when the schema can represent expected cases, reviewers can locate the requested evidence, and discrepancies reveal a resolvable method rather than competing plausible forms.

Keep the reported state separate from the usable state

The source record should preserve what the report actually states. If the analysis requires correction or transformation, add a new field rather than replacing the source value. Store the inputs, formula or script, output, reason and reviewer. This applies to converted dispersion measures, combined groups, digitised figures, change scores, unit conversions and values corrected after author contact (track these interactions using the missing data contact log and request templates). The analysis field should point back to the reported state.

Source locations must be specific enough for verification. Include the report identifier and the page, table, figure, appendix or registry field. If several reports contribute, record which one supplies each component. When reports disagree, preserve both values and document the rule used to select or reconcile them. Convenience is not an evidence hierarchy.

Match checking to the downstream risk

Outcome values that enter a meta-analysis can directly change estimates and commonly warrant independent duplicate collection or verification under the applicable standard. Single extraction has been associated with more errors than double extraction, while methodological evaluations show that errors can persist across extraction approaches.^5,9 For Cochrane intervention reviews, duplicate outcome collection is mandatory and duplicate study-characteristic collection is highly desirable.¹ Other review types must follow their own requirements rather than inheriting these classifications automatically.

Preserve both initial entries until the discrepancy is resolved. Classify the difference, source selection, transcription, interpretation, entity linkage or calculation, because the corrective action differs. Repeated interpretation conflicts indicate that the data dictionary or protocol rule needs revision. A range check can catch an impossible percentage; it cannot determine whether the correct population was extracted.

Automation may assist with candidate identification, form completion and consistency checking, but evidence remains context dependent.⁶ Record the system and version, retain the source span, and verify every value before it becomes authoritative. The template deliberately asks for a source location and accountable verifier because an automatically populated field without those elements is not reproducible.

Quality monitoring should be field specific. A single overall disagreement percentage can conceal a small number of consequential outcome errors among many simple descriptive fields. Summarise discrepancies by type, source and analytical impact, then use the pattern to revise instructions or interface controls. If one extractor or report format is associated with repeated problems, increase targeted verification without assuming that error-free fields establish validity across the dataset.

Use the browser record as a design and training surface

The browser form demonstrates the minimum provenance chain for one observation. It is not a multi-user database, does not provide immutable audit history and should not hold confidential personal information. Export drafts to the review’s approved repository, apply institutional access controls and maintain the complete schema in the accompanying Word template or controlled data system.

Before main extraction, pair the form with its methodological guide, How to Design a Data Extraction Form for a Systematic Review, write the review-specific dictionary, add design-specific fields and test the export. For large or complex reviews, implement the same architecture in a platform that supports repeated entities, permissions, backups and version control as outlined in the systematic review data extraction and data management hub. The scientific model should remain portable even when the interface changes.

Prepare a field-to-output map before deployment. For every variable, identify the table, calculation, judgment or reporting item it supports and name the person responsible for resolving exceptions. This map exposes unused fields and analyses that lack inputs. It also prevents the form from becoming an accidental substitute for the protocol: when a new field changes the scientific scope, route the decision through the amendment process rather than adding it silently.

At handoff, include a worked record that demonstrates a linked report, a missing-information code, a derivation and a resolved discrepancy. Worked examples make the dictionary operational, but they should be labelled as illustrations and must not be treated as universal defaults. Remove example content before live extraction and verify that exports preserve identifiers, Unicode, line breaks and controlled codes.