TwoSampleMR pulls OpenGWAS data into R to run Mendelian randomization

An R package that turns GWAS summary data into MR estimates

TwoSampleMR exists to make two-sample Mendelian randomization reproducible without hand-assembling every input. The package description says it is for performing Mendelian randomization using GWAS summary data, that it uses the IEU OpenGWAS database to obtain data automatically, and that it provides a wide range of methods to run the analysis. The audience is therefore genetic epidemiology researchers who already think in terms of instruments, exposure and outcome associations, and who want the plumbing of data retrieval and exposure outcome pairing handled by code rather than by spreadsheets. The key word in the design is automatically. Rather than pasting coefficients from published papers into a table, you name the studies and let the package fetch the summary statistics, which also means the analysis can be rerun later against the current state of the database. That convenience is the core value proposition, and it is also the main dependency to think about before committing.

The January 2020 release changed package, database and reference panels

The README gives unusual prominence to a single breaking change, under the heading January 2020 major update. It says the project has made substantial changes to the package, the database and the reference panels, and directs readers to a dedicated article at the mrcieu.github.io TwoSampleMR site for full details. Three things moved at once there: the code, the data source and the genetic ancestry reference panels used for harmonisation. A pipeline written before that update and not revisited since can therefore fail for reasons that have nothing to do with the statistics, for instance because instruments are now harmonised against a different set of reference data or because an API response changed shape. The package also carries the r-lib lifecycle badge labelled experimental, and the badge is not decorative. A package whose data source is a live web database and whose reference panels are periodically refreshed is a moving target by construction, and the maintainers signal that with the badge. For anyone treating MR output as decision-grade evidence, that combination deserves attention before the results are quoted.

Installing on Windows and macOS through the MRC IEU r-universe

The installation instructions are split by platform, which tells you the package is not distributed the same way everywhere. Users on Windows and macOS are told to install the latest version from the MRC IEU r-universe, and the command to run is:

install.packages("TwoSampleMR", repos = c("https://mrcieu.r-universe.dev", "https://cloud.r-project.org"))

The second repository in the list is the main CRAN mirror, with the r-universe listed first so the MRC IEU build wins when both carry the package. Users on Linux or WebR are sent to separate instructions hosted in the mrcieu.r-universe.dev repository. Updating is the same command run again, which is convenient and worth remembering before you assume an old analysis used the current code. If you would rather build from the source tree, the README also gives a two step path:

install.packages("remotes")
remotes::install_github("MRCIEU/TwoSampleMR")

Running the remotes::install_github command again is what updates a source install. A multi-platform Docker image with R and the package pre-installed, for both x86_64 and ARM machines, is published at hub.docker.com/r/mrcieu/twosamplemr, which is the most reproducible of the options when your collaborators need the same environment.

A justfile covers the developer loop, including the OpenGWAS tests

The repository root contains a justfile that shows how the maintainers work, and it is a better map of the project than the README. The docs recipe runs devtools::document() to regenerate documentation, and check runs devtools::check() on top of it, so a full CRAN style check happens on every invocation. The test recipe runs devtools::test(), while a separate test-server recipe runs the same test suite with the environment variable TWOSAMPLEMR_ENABLE_OPENGWAS_TESTS=TRUE set. That split is the important detail: the default test run does not need to reach the live database, and the recipe that does reach it is opt-in. A package that pulls live data can otherwise have a test suite that is slow and flaky, and this is the mechanism that keeps the default path deterministic. There is also an install recipe using devtools::install with vignettes built, an install-fast recipe that skips vignettes for a quicker cycle, a dev recipe based on pak::local_install_dev_deps(), a readme recipe that renders README.Rmd, and a urlcheck recipe that runs urlchecker::url_check(), which matters in a package full of database links.

Where the network dependency bites: live data and versioned releases

Two constraints define the operational reality of this package. The first is that the analysis depends on a remote database being available and consistent at the moment the code runs, so an analysis pinned to a past result depends on whatever the database returned at that time. The second is that the dependency list for developers is small but not trivial. The repository layout is a conventional R package, with R/ for code, man/ for generated documentation, tests/ for the test suite, vignettes/ for long-form articles, inst/ for shipped assets, and pkgdown/ plus _pkgdown.yml for the site that renders at the mrcieu.github.io address. DESCRIPTION and NAMESPACE define the package metadata, NEWS.md tracks changes, and CITATION.cff gives the citation metadata. The build is also quality controlled in continuous integration, judging by the R-CMD-check workflow badge and the Codecov coverage badge pointing at the master branch. In other words, the software side is well instrumented, and the risk sits in the data side rather than in the code side.

Automatic retrieval versus hand-collected study estimates

The real alternative to this package is the traditional route: take the per-study published effect estimates for your exposure and outcome from the published literature, harmonise them by hand, and run the analysis in whatever statistical software you already use, with a fixed script of your own. The difference in approach is worth being precise about. The manual route gives you complete control over which studies enter, and it produces a self-contained script with no network dependency at run time, which is a genuine advantage when the result has to be reproducible years later. What you give up is the data plumbing, because study selection, exposure and outcome matching and instrument lookup all become manual steps, and every sensitivity analysis starts from that same manual base. TwoSampleMR inverts that: it makes the retrieval and pairing cheap and repeatable, at the cost of coupling the analysis to a live database and to the reference panels in use at the time. Neither approach is universally better. The manual path suits a small, frozen, well understood exposure where the study list is already known. The package suits exploratory work across many traits where the bookkeeping, not the modelling, is what consumes the time.

Maintenance pace, and a licence that GitHub could not classify

The repository is not archived and the last push was on 2026-10-20. The release history matches that: version 0.7.13 was published on 2026-10-20, 0.7.12 on 2026-10-08 and 0.7.11 on 2026-09-25, which is a visible cadence of maintenance rather than an occasional burst. The README asks for issues and feature requests in the usual way and points at the documentation site for the full details, including the 2020 update article. The licence needs attention. The repository is not distributed under a standard SPDX identifier that GitHub can label automatically; the listing records the licence as Other, meaning a custom licence, and the root of the repository contains both a LICENSE file and a LICENSE.md file. Anyone planning to use the package in a pipeline that has to satisfy a licence allow list should read those files directly and check them against their own compliance requirements, and they should do it before the analysis rather than after, since the licence text sits outside what the README summarises. The package is also archived on Zenodo under a DOI, which matters for the citation side of a research workflow.

Editorial conclusion

TwoSampleMR suits researchers who want MR analysis driven by OpenGWAS summary statistics rather than by hand-collected per-study estimates, and who can accept a network dependent workflow and a package still marked experimental on the r-lib lifecycle. Do not adopt it if you need a stable, frozen analysis pipeline without upstream data changes. Before your first run, read the January 2020 update notes at the gwas2020 article, because the package, the database and the reference panels all changed in that release.

Frequently asked questions

Official sources

1. Issues
2. MRCIEU/TwoSampleMR on GitHub
3. Project website
4. README
5. Releases