Is R Accepted by the FDA? The State of R-Based Submissions
“Regulators only accept SAS” was already folklore a decade ago — the FDA’s own Statistical Software Clarifying Statement says the agency does not require any specific software — but folklore with a licence renewal attached tends to live long. What finally changed the conversation was the R Consortium R Submissions Working Group: a series of pilot submissions, prepared openly and reviewed by the FDA, demonstrating the full path in practice.
What the pilots showed
Across the pilots, sponsor-style teams assembled and the FDA received and reviewed submission packages in which:
- analysis datasets and TLFs were produced entirely in R, with the R code included in the package;
- a Shiny application was submitted and successfully executed in the agency’s own environment;
- container- and webassembly-based delivery of interactive components was exercised in later pilots.
The point was never that R produces prettier p-values. It was operational: the eCTD structure, the code delivery format, the reviewer’s ability to re-run the analysis — all of it works with R. The “is it accepted?” question is settled; what remains is engineering discipline.
“But is R validated?”
Validation is a property of your process, not of a software licence. SAS installations are validated by their owners’ quality systems — the same logic applies to R:
- Pin the environment. {renv} locks package versions per project; the lockfile ships with the deliverable, and
sessionInfo()is captured in every run log. - Assess package risk. {riskmetric} scores packages on documentation, test coverage, maintenance and community adoption — the evidence base for your package acceptance SOP. Core packages (base R, survival, and the pharmaverse tools) publish extensive test suites.
- Qualify the installation. Run the package test suites in your environment and file the results — the R equivalent of an installation/operational qualification.
- Double-program the outputs. Independent reproduction from the spec remains the QC gold standard regardless of language — we describe the workflow on our CRO services page.
A version-pinned, test-covered, double-programmed R pipeline produces stronger validation evidence than an unversioned macro library that has “always been there”.
The ecosystem that makes it practical
The pharmaverse — an industry collaboration including Roche, GSK, J&J, Novartis and others — now covers the submission pipeline end to end: admiral for ADaM derivations, rtables/tern for CSR-grade TLFs, xportr for transport files with define.xml-ready metadata, and {mmrm} for the standard longitudinal model. These are not hobby packages; they are the internal tooling of the industry, published.
What this means if you run a CRO
The cost case for SAS-to-R migration was always obvious; the pilots removed the regulatory excuse for postponing it. The teams that migrate carefully — pilot study, parallel run, documented equivalence — get the licence savings and a more auditable pipeline. The teams that wait are now competing against them on price.
Weighing this up for your own shop? We run fixed-scope pilot migrations and R-based TLF production — talk to us, or start with the migration guide.