Written and maintained by CASRAI Editorial Board
Last updated
A systematic review’s data extraction form is the instrument that turns dozens of included studies into one comparable dataset — and the Cochrane Handbook treats its design, piloting, and staffing as formal, checkable requirements, not a template you fill in once and forget. Cochrane’s Methodological Expectations of Cochrane Intervention Reviews (MECIR) standards specify a four-step design process, a mandatory piloting step, and a dual-extraction rule that is stricter for outcome data than for study characteristics. This guide walks through all three, with the exact standard numbers so a review team can cite them in a protocol or methods section.
What a data extraction form actually needs to capture
Per Cochrane Handbook Chapter 5 (Collecting data), a data collection form is built around six categories of data element:
- Study methods and risk-of-bias detail — design, randomization/allocation approach, blinding, and anything feeding a later RoB 2 or ROBINS-I assessment.
- Participant characteristics and setting — eligibility criteria as actually applied, baseline demographics, recruitment setting, country.
- Intervention description — detailed enough to support replication; the Handbook points reviewers to the TIDieR checklist as the reporting framework for this field group specifically.
- Outcome definitions and measurement — what was measured, with which instrument, at which time point, and how the study itself defined the outcome.
- Results per group and time point — the actual numbers that will feed a later synthesis or meta-analysis.
- Funding source and conflicts of interest — increasingly expected by journals and by PRISMA 2020 reporting item 26.
Cochrane’s four-step form design process
The Handbook does not treat form design as a single drafting pass. It lays out four sequential steps:
- Develop outlines of the review’s planned tables and figures first. Knowing what the final summary-of-findings table or forest plot needs to show determines what data actually has to be collected — working backward from output to form, not forward from a generic template.
- Assemble the data elements using the Handbook’s own grouping guidance (Table 5.3.a) so nothing from the six categories above gets missed.
- Frame each item as a closed-ended question wherever possible, with explicit “not applicable” and “cannot tell” response options built in, rather than leaving fields as open free text that different extractors will fill in inconsistently.
- Pilot-test the form thoroughly before the full extraction round begins.
Piloting is a formal requirement, not optional QA
MECIR Box 5.4.a states plainly that data collection forms “have been piloted” — this is a checkable standard against a submitted Cochrane review, not general advice. In practice, piloting means multiple people on the review team independently extract from the same handful of already-included articles using the draft form, then compare results for clarity and completeness and check the extracted values against the source documents. If piloting turns up a form that needs major revision — ambiguous item wording, a missing response category, a field nobody can consistently answer — the Handbook’s expectation is that the revised form gets re-piloted, not pushed straight into full use.
Dual extraction: mandatory for outcomes, highly desirable for study characteristics
This is the distinction that trips up review teams working from memory rather than the actual standard text. MECIR sets two different bars:
| Data type | MECIR standard | Requirement level |
|---|---|---|
| Study characteristics (design, participants, setting, intervention description) | MECIR C45 | Highly desirable to have two people extract independently |
| Outcome data (the actual results feeding synthesis) | MECIR C46 | Mandatory — two independent extractors required |
The reasoning behind the split is proportional to error consequence: a mistranscribed baseline characteristic is usually caught and low-stakes to correct, while a transcription error in an outcome value propagates directly into a pooled effect estimate. When two independent extractions disagree, the Handbook’s expected resolution path is, in order: discussion between the two extractors, arbitration by a third team member, and — if the disagreement traces back to how the original study reported something — contacting the study authors directly for clarification.
Software for running extraction, not just designing the form
The Handbook discusses several platforms built specifically to manage dual-extraction workflows at scale: Covidence, Rayyan, and DistillerSR for screening-through-extraction pipelines, EPPI-Reviewer and the Systematic Review Data Repository (SRDR) as dedicated extraction-and-synthesis tools, Cochrane’s own RevMan for teams working entirely inside the Cochrane ecosystem, and plain Google Forms as a lightweight option for smaller, non-Cochrane reviews that don’t need a dedicated platform’s reconciliation features. All of the dedicated tools support recording two independent extractions per field and flagging disagreements automatically — which is the practical mechanism that makes the MECIR C46 mandate achievable at review scale rather than a manual spreadsheet-diffing exercise.
Where this fits in the review timeline
Form design and piloting happen before full-text screening is complete, not after: a form built and tested against a handful of early included studies can then be applied consistently as the rest of full-text screening finishes. Protocol registries such as PROSPERO accept registration up to the point data extraction has actually been completed — ideally before title/abstract screening begins — so a well-piloted extraction form belongs in the same planning phase as the review protocol itself, alongside the PICO question and the planned risk-of-bias and GRADE assessment approach.
Frequently asked questions
Is dual data extraction required for every systematic review, or only Cochrane reviews?
The MECIR standards are Cochrane’s own conduct standards and formally apply to Cochrane reviews specifically. In practice, though, the same two-tier logic — independent dual extraction as mandatory for outcome data and strongly recommended for study characteristics — is widely adopted as best practice by non-Cochrane systematic reviews and is frequently expected by journal reviewers and by appraisal tools such as AMSTAR 2, which specifically asks whether data extraction was done in duplicate.
What happens if the two extractors disagree and the study authors don’t respond?
The Handbook’s escalation path ends at author contact, but doesn’t mandate a specific outcome if authors don’t reply. Review teams typically resolve unresolved disagreements through documented team consensus or a pre-specified default rule (for example, treating an ambiguous value as missing rather than guessing), and note the unresolved ambiguity explicitly in the review’s risk-of-bias or limitations discussion.
Do I need a dedicated tool like Covidence, or can I build a form in a spreadsheet?
A spreadsheet or plain form can satisfy the Handbook’s design and piloting requirements for a small review. The main thing a dedicated tool adds is built-in dual-extraction reconciliation — automatically flagging where two extractors’ entries differ — which becomes valuable once a review has more than a handful of included studies or more than two people extracting.
