Open Science Practices for Systematic Reviews: Sharing Your Data and Code

Open science practices for systematic reviews -- sharing your extracted data, your analysis code, and your full search strategies publicly -- have moved from a nice-to-have addition to an increasingly explicit expectation from funders, journals, and the broader research community, and adopting them is generally less burdensome than researchers unfamiliar with the practice often assume.

What open science means specifically for a systematic review

Beyond the registration and PRISMA reporting already expected of rigorous systematic reviews, open science practices extend to making your underlying extracted data, your full search strategies for every database, your risk-of-bias assessment details, and your statistical analysis code available in a public, accessible repository alongside your published manuscript.

Why this matters beyond general transparency values

A published systematic review's text and tables summarize an enormous amount of underlying work, but a reader or future researcher wanting to verify a specific extracted value, rerun your statistical analysis with a slightly different assumption, or build directly on your search strategy for an update review, cannot do so without access to the underlying materials themselves. Sharing these materials transforms your review from a reported conclusion readers must simply trust into a genuinely verifiable, buildable piece of research infrastructure.

Where to share your materials

The Open Science Framework is among the most widely used general-purpose repositories for this kind of supplementary systematic review material, offering free, permanent, citable hosting for extraction spreadsheets, analysis code, and search strategy documents. Many journals also now support supplementary material hosting directly, though a dedicated, independently citable repository like OSF offers more durability and easier discoverability than material buried in a journal's own supplementary file system.

What specifically to share

Your full search strategies for every database, exactly as run, not just a summarized version. Your data extraction spreadsheet, with clear column headers matching your reported extraction fields. Your risk-of-bias assessment details, ideally at the individual domain level for each included study, not just an overall summary judgment. Your statistical analysis code, whether in R, Stata, or another package, with enough comments that someone unfamiliar with your specific project could follow the logic.

Addressing data sensitivity concerns

Systematic review extraction data drawn from published literature generally doesn't carry the same participant-level privacy concerns as sharing raw primary study data, since you're sharing study-level summary information already present in published sources, not individual patient records. This makes systematic review data sharing considerably more straightforward from a privacy standpoint than open data practices in primary research often are.

Licensing your shared materials appropriately

Applying a clear, permissive license, commonly a Creative Commons license, to your shared materials clarifies exactly how others may use and build on your work, removing ambiguity that might otherwise discourage legitimate reuse by researchers uncertain about what's actually permitted.

Open science and your PRISMA reporting

PRISMA 2020 explicitly includes a data availability item, expecting authors to state whether and where extracted data, analysis code, and other materials are available. Completing this item honestly, whether the answer is a specific repository link or an explanation of why materials aren't shared, is now a standard reporting expectation rather than an optional addition.

Funder and institutional requirements

Many major research funders now explicitly require data sharing plans as part of grant applications, including for systematic review projects, and institutions increasingly encourage or require open science practices as part of their own research policies. Checking your specific funder's and institution's current requirements before finalizing your data management plan avoids a late-stage scramble to meet a requirement you hadn't initially planned for.

A practical starting point

If open science practices are new to your team, start with the lowest-effort, highest-value step: sharing your full search strategies and your data extraction spreadsheet, even before tackling analysis code sharing if that feels like a bigger initial undertaking. This alone meaningfully improves your review's transparency and reproducibility, and expanding to code sharing as your team becomes more comfortable with the practice is a reasonable, incremental way to build toward fuller open science adoption over successive projects.

Addressing common hesitations about sharing

Some researchers hesitate to share extraction data or code out of concern about errors being publicly visible, but this concern, while understandable, generally reflects a misunderstanding of how open science practices are actually received -- shared materials that enable a reader to spot and constructively flag a genuine error are a sign of a transparent, correctable process, not a mark against the review's credibility, and this transparency is increasingly viewed as a strength rather than a vulnerability by informed readers and reviewers.

Open science as a team habit, not a final step

Building data and code sharing into your working process from the start, saving and organizing materials as you go rather than scrambling to compile them only once a manuscript is accepted, makes the eventual sharing step considerably less burdensome than treating it as an afterthought tacked onto an already-completed project. Teams that adopt this habit early tend to find each subsequent review's sharing step considerably faster and less burdensome than the one before it. Over a longer research career, this accumulated ease becomes a genuine competitive advantage, letting a team meet increasingly common funder and journal expectations with noticeably less friction than teams encountering these requirements for the first time on every new project. This cumulative advantage compounds meaningfully across a research career, making early investment in open science habits one of the more durable, transferable skills a systematic reviewer can develop. Starting this practice on your very next review, rather than waiting for an ideal future project to begin the habit, is the most practical way to actually build it into your standard working process. Small, consistent habits adopted early tend to compound into considerably more efficient and more transparent research practices across an entire career, rather than remaining isolated to any single project, compounding steadily as these habits become genuinely second nature over time, until careful, transparent reporting becomes simply how a team works, rather than an extra step layered on top.