Building a Data Extraction Template in Covidence

Covidence is the only one of the three major systematic-review platforms that bundles screening, data extraction, and risk-of-bias assessment into one built-in workflow — but “customizable” extraction template does not mean “correct” extraction template. A form that skips Cochrane’s own design steps produces exactly the kind of extractor disagreement Covidence’s consensus step exists to catch. This guide is about configuring that template inside Covidence specifically: which sections to build, how to shape fields so two independent extractors actually converge, where Covidence’s built-in risk-of-bias module fits, what its AI auto-populate feature can and cannot be trusted with, and how the output exports for synthesis. For the underlying Cochrane Handbook methodology this all rests on — independent of any specific tool — see Systematic Review Data Extraction Form: Fields, Piloting, and Dual Extraction.

What “built-in and customizable” actually means in Covidence

Unlike Rayyan, which has no structured extraction module at all, Covidence includes a built-in, customizable data-extraction template with side-by-side PDF viewing (the source document stays visible next to the fields being completed) and an integrated risk-of-bias assessment module covering Cochrane’s RoB 2 and ROBINS-I tools. That combination is why Covidence is Cochrane’s own recommended screening-and-extraction tool, and why many Cochrane review groups standardise on it. It sits between Rayyan (screening only, no extraction) and DistillerSR (deeper configurability — conditional/branching logic, multi-reviewer reconciliation — but enterprise-priced and aimed at regulatory/HTA-scale programs). For a small-to-mid-size team running a standard Cochrane-methodology review, Covidence’s template covers the same ground DistillerSR does without needing that extra configuration surface.

Build sections around Cochrane’s six data-element categories, not around Covidence’s default blank form

Starting from an empty Covidence extraction screen and adding fields as they come to mind is how forms end up missing a category partway through extraction, forcing a re-open on every already-extracted study. Cochrane Handbook Chapter 5 groups everything a form needs to capture into six categories, and structuring the Covidence template as six matching sections keeps nothing implicit:

• Study methods and risk-of-bias detail — design, randomisation/allocation approach, blinding. Build this section to feed directly into Covidence’s linked RoB 2/ROBINS-I assessment rather than duplicating the same judgements as free text.
• Participant characteristics and setting — eligibility criteria as actually applied, baseline demographics, recruitment setting, country.
• Intervention description — detailed enough to support replication; the Handbook points 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 numeric fields that will ultimately feed a meta-analysis.
• Funding source and conflicts of interest — expected by PRISMA 2020 reporting item 26.

Before adding a single field, follow the Handbook’s own sequencing: sketch the tables and figures the finished review needs first, then work backward to the data those tables require. A template built forward from a generic checklist routinely collects fields nobody ends up using, and misses the one number a planned forest plot actually needs.

Design fields so two independent extractors converge, not just so the form looks complete

Covidence enforces the same blind, dual-reviewer model on extraction that it uses for screening — two extractors complete the template independently, without seeing each other’s entries, and Covidence flags every mismatch for a documented consensus step before the record is finalised. How much rework that consensus step generates is determined almost entirely by how the fields were written, not by how careful the extractors are:

• Frame fields as closed-ended questions with explicit non-answers built in. A free-text box invites two defensible-but-different phrasings of the same fact, which then reads as a disagreement Covidence has to flag even though both extractors actually agree. Give every field that can be closed-ended a fixed set of response options, including explicit “not applicable” and “cannot tell” choices — not a blank field left empty, which is indistinguishable from “not extracted yet.”
• Apply Cochrane’s dual-extraction tiering deliberately, not uniformly. Per MECIR, independent double-extraction of study characteristics is “highly desirable” (MECIR C45) but not mandatory; independent double-extraction of outcome data is mandatory (MECIR C46). A template that forces full blind double-entry on every field, including low-risk descriptive fields, burns reviewer time on categories where a single extractor plus spot-checking is an accepted standard — reserve mandatory dual entry for the outcome-data section specifically.
• Route disagreements the same way Cochrane specifies for resolving conflicts: discussion between the two extractors first, third-party arbitration second, and contacting the study authors for clarification only if the disagreement still can’t be resolved from the paper itself. Covidence’s consensus screen supports a third reviewer for exactly this escalation path.

Pilot the template before running it against the full study list

MECIR Box 5.4.a treats piloting as a formal requirement, not optional good practice: the form must have been piloted before full use. In Covidence terms, that means running the actual template — not a paper mock-up — against several real included studies with multiple extractors, before opening it against the rest of the list. Check the pilot output for two separate things: whether extractors interpreted fields the same way (a wording problem, fixed by editing the field), and whether the fields were even the right ones to ask (a scope problem, fixed by adding or cutting a section). A template needing major revision after piloting should be re-piloted against a fresh set of studies, not patched and trusted — the whole point of the step is confirming the fix actually worked.

Where Covidence’s AI auto-populate feature fits, and its real limits

Covidence offers an AI-assisted auto-populate feature that pre-fills a subset of extraction-template fields directly from an uploaded PDF once a DOI is attached to the study record. Covidence’s own documentation is explicit that this output must be human-verified, not accepted as-is — it is a drafting aid for the extractor, not a replacement extractor. That caveat is not just good practice; it now has a citable standard behind it. The Cochrane/Campbell Collaboration/JBI/Collaboration for Environmental Evidence joint RAISE statement (published 31 October 2025) requires that any AI use which “makes or suggests judgements” in a systematic review — and auto-populated data extraction fields are squarely that — be disclosed in the review’s methods, including the system name/version, its purpose, and its known limitations. Build that disclosure line into the review’s protocol or methods section from the outset if the template will use auto-populate at all, rather than treating it as a detail to add after the fact.

Exporting the completed template for synthesis

Covidence exports structured extraction data in a form suitable for direct import into meta-analysis software, alongside its standard CSV/RIS export of screening results and reference data — extraction does not stay locked inside the platform the way it effectively does in Rayyan, which has no extraction module to export from. Plan the export format the template will need to hit before finalising field types: a results field intended to feed a meta-analysis in R with metafor, RevMan, or another synthesis tool needs to store numeric effect data as actual numbers, not as a free-text summary a human would have to re-key. See Systematic Review vs. Meta-Analysis for how the extraction stage and the synthesis stage relate as two distinct steps in the same review.

FAQ

Does Covidence replace the need for a separate risk-of-bias tool?

No separate tool is needed for RoB 2 or ROBINS-I specifically — both are built into Covidence’s extraction workflow alongside the data-extraction template. A review using a different risk-of-bias instrument not included in that module would still need to run it separately.

Can extraction data built in Covidence be exported to R or RevMan?

Yes — Covidence exports structured extraction data suitable for direct import into meta-analysis software, provided the template’s fields were built to store results as structured numeric data rather than free text.

Do extractors need to double-enter every field?

No. Cochrane’s MECIR standards make double-extraction “highly desirable” but not mandatory for study-characteristics fields, and mandatory only for outcome-data fields (MECIR C45 and C46 respectively). A template can apply Covidence’s blind dual-entry selectively along that line rather than uniformly across every field.

Is it safe to rely on Covidence’s AI auto-populate feature without checking it?

No — Covidence’s own documentation states the auto-populated fields must be human-verified, and the Cochrane/Campbell/JBI/CEE joint RAISE statement (2025) requires disclosing its use in the review’s methods since it suggests extraction judgements rather than performing purely mechanical formatting.