From SAS to R in Clinical Programming: What’s Changing, What Isn’t
Why SAS was the default, what the FDA actually accepts, what the R Consortium pilots and the pharmaverse proved, and what stays identical — the CDISC standards
An honest, accurate map of the SAS-to-R shift in clinical trial programming. Why SAS became the convention, what really changed (the FDA accepts R submissions that meet the same requirements; the R Consortium pilots proved an all-R package; the pharmaverse made it practical), what stays identical (the CDISC standards from the earlier foundations lessons are language-agnostic — only the tool changes), and the realistic picture: SAS is still entrenched, most shops are hybrid, R adoption is growing, not total. This is the lesson that motivates the hands-on R/pharmaverse series ahead.
- The FDA accepts R. It requires no specific statistical software — its 2015 Statistical Software Clarifying Statement says so plainly — as long as what you used is fully documented. SAS was a convention, never a regulation.
- The R Consortium pilots removed the doubt. The R Submissions Working Group submitted real, all-R packages through the FDA’s eCTD gateway; Pilot 3 delivered the first public R package that includes ADaM datasets plus tables and figures, and the FDA accepted and reproduced the results.
- The pharmaverse made it practical. A curated, industry-governed set of open-source R packages — admiral (ADaM), sdtm.oak (SDTM), xportr (XPT export), rtables/tern (tables and figures), teal (review apps) — now covers the whole pipeline.
- The standards don’t change — only the tool does. SDTM, ADaM, Define-XML, and the eCTD package from the earlier foundations lessons are language-agnostic. R produces the same conformant datasets a regulator expects; your CDISC knowledge transfers intact.
- Be realistic: this is a shift, not a takeover. SAS is still everywhere, most shops are hybrid, and R adoption is growing, not total. But open-source R is now a first-class way to do submission work — which is exactly what this pillar teaches.
Introduction
If you have spent any time near clinical trials, you have heard it: “Submissions are SAS. That’s just how it is.” For decades that was effectively true — and it shaped an entire profession’s tooling, training, and hiring.
It is no longer the whole story. The FDA accepts R-based submissions that meet its requirements, a working group has submitted complete R packages through the real submission gateway — the eCTD (electronic Common Technical Document) — and had them reviewed, and an open-source R ecosystem now spans the full pipeline. This lesson is the honest map of that shift: why SAS was the default, what actually changed, what stays identical, and what it means for you learning this pillar.
The clinical-trial data flow traced a data point through the five-stage flow (CRF → SDTM → ADaM → TLF → submission); the regulatory context covered the regulators and why CDISC (the Clinical Data Interchange Standards Consortium) is mandatory; the estimand framework defined the clinical question; the CDISC standards mapped the standards themselves. This lesson closes the foundations by answering the question every newcomer asks: can I really do this in R? The short answer is yes — and the rest of the pillar shows you how.
No tooling to install — this lesson is the honest map, not a hands-on build; the hands-on R and pharmaverse work begins in the series that follow.
Why SAS was the default
SAS did not win clinical programming by regulation. It won by inertia and ecosystem, and the inertia was rational:
- It got there first and never left. SAS was the established tool when CDISC and electronic submissions took shape, so processes, validated macro libraries, standard operating procedures, and reviewer familiarity all grew up around it.
- Validated, supported tooling. A regulated environment values software with formal validation, vendor support, and a long track record. SAS offered exactly that, which made it the low-risk institutional choice.
- A trained workforce and a hiring loop. Programmers were trained in SAS, so sponsors hired SAS, so the next generation learned SAS. The convention reinforced itself.
The crucial point — and the one most newcomers get wrong — is that none of this was a legal requirement. There is no rule that says “submit in SAS.” It was a deeply entrenched default, not a mandate. That distinction is the door the rest of this lesson walks through.
What changed: the FDA accepts R
Start with the regulator, because everything else depends on it. The FDA’s position is explicit and has been for years: it does not require any specific statistical software. Its Statistical Software Clarifying Statement (May 2015) states that the agency “does not require use of any specific software for statistical analyses,” provided the software used is “fully documented in the submission, including version and build identification.”
Read that carefully, because it is easy to over- or under-claim:
- R was never forbidden. The “you must use SAS” belief is a persistent myth, not a regulation. What the FDA requires is a conformant submission — the right CDISC datasets, the metadata, the documentation, a reproducible result — regardless of the language that produced it.
- “Accepts” is not “endorses.” The FDA does not bless R, or any tool, as preferred. It accepts submissions that meet its requirements. The burden is on the sponsor to document the computing environment and show the results are reproducible. R clears that bar; it is not handed a pass for being open source.
So the regulatory door was open. What was missing for a long time was proof that a real, end-to-end R package could go through it — and a toolkit mature enough to build one.
What proved it: the R Consortium pilots
The proof came from the R Consortium’s R Submissions Working Group — a cross-industry, open collaboration that did the obvious experiment: build submission packages entirely in R and send them to the FDA through the real eCTD gateway, in the open, with every artifact published on GitHub. They ran a sequence of pilots, each one extending the last:
- Pilot 1 — submitted the tables, listings, and figures (TLFs) as R scripts, showing R could produce conformant analysis outputs.
- Pilot 2 — added an R Shiny application, testing whether interactive review apps could travel in a submission.
- Pilot 3 — the milestone: the first publicly available R-based package that includes ADaM datasets and TLFs, both generated in R. It went through the eCTD gateway, and after review the FDA accepted and reproduced the results, issuing its final response letter in 2024.
- Pilot 4 and beyond — pushed into newer technology (Shiny bundled with WebAssembly and Linux containers for self-contained, reproducible review), with further pilots ongoing.
Across the pilots, the working group deliberately built outputs with different open-source R packages, and FDA staff successfully reproduced the results from each. That is the heart of the proof: not a slide deck arguing R could work, but a real package a regulator actually reviewed and reproduced. Because every artifact is public, they double as a reference blueprint for the shape of an R-based submission.
These are test submissions by a working group, not approvals of a marketed drug. They establish the path and the precedent — the FDA reviewing and reproducing an all-R package — not a guarantee that any given sponsor’s submission sails through. The sponsor still owns conformance, documentation, and validation. What changed is that the path is now proven and public, not hypothetical.
The pilots trace a simple, honest timeline:
| Pilot | Delivered | Milestone |
|---|---|---|
| Pilot 1 | Tables, listings & figures (TLFs) as R scripts | R produces conformant analysis outputs |
| Pilot 2 | An R Shiny application | Interactive review apps in a submission |
| Pilot 3 | First public R package with ADaM + TLFs | FDA accepted & reproduced the results |
| Pilot 4 | Shiny bundled via WebAssembly / containers | Self-contained, reproducible review |
Read down the Delivered column and the trajectory is clear: each pilot adds a piece of the real submission until, by Pilot 3, the package includes the analysis datasets themselves — the part everyone assumed had to be SAS.
What made it practical: the pharmaverse
Regulatory acceptance opens the door; you still need tools to walk through it. That is the pharmaverse — “a connected network of companies and individuals working to promote collaborative development of curated open source R packages for clinical reporting.” It is not one package but a curated, governed collection (backed by PHUSE, decided in the open via GitHub and a community council), and it covers the whole pipeline you met in the clinical-trial data flow and the CDISC standards:
- SDTM — sdtm.oak (a framework, originally from Roche, for mapping raw data to SDTM domains), with synthetic example data in pharmaversesdtm.
- ADaM — admiral, which provides standardized, modular derivations for building ADSL, BDS, and OCCDS datasets; example data in pharmaverseadam.
- Metadata / specifications — metacore and metatools, which carry your dataset specifications and feed Define-XML.
- Tables, listings, and figures — rtables, tern (clinical analysis tables and graphs, including survival outputs), tidytlg, and gtsummary.
- XPT export — xportr, which gets datasets into the SAS Transport v5 (
.xpt) format the agencies require, with the right types, lengths, and labels. - Interactive review — teal, a Shiny framework for the exploratory review apps a team (or a reviewer) uses on the data.
Because these are production-grade and industry-governed — not hobby projects — the result is a credible, auditable R path from raw data to a submission package. This pillar teaches that path with these tools.
What stays identical: the standards
Here is the part that should reassure anyone who has invested years in CDISC: the shift is the tool, not the rules. Everything from the earlier foundations lessons is language-agnostic and does not change:
- SDTM still tabulates collected data into the same fixed domains (DM, AE, VS, …).
- ADaM still derives the same analysis-ready, traceable datasets (ADSL, ADAE, BDS, OCCDS).
- Controlled Terminology, Define-XML, the cSDRG/ADRG reviewer’s guides, and the eCTD package are exactly as the earlier foundations lessons described them.
- The regulators’ requirements — conformance, traceability, documentation — are unchanged.
R is simply a different way to produce the same conformant outputs. Pilot 3 makes this concrete: it generated standard ADaM datasets and their metadata in R, and a reviewer read them through the same Define-XML the standards define. So your CDISC knowledge is not at risk in a move to R — it is the part that transfers completely. You are changing the how, not the what.
The honest reality: a shift, not a takeover
It would be easy — and wrong — to read all this as “SAS is finished.” It is not, and you should hear the balanced version, because it shapes how you’ll actually work:
- SAS is still entrenched. Decades of validated macros, SOPs, legacy studies, and trained staff do not vanish. For many sponsors SAS remains the backbone of compliance-heavy work, and it is still the most common skill in job postings.
- Most real shops are hybrid. The common pattern is SAS for the stability-critical pieces (often ADaM and TLF generation in established processes) and R for innovation — SDTM creation, interactive Shiny review apps, QC and double-programming, exploratory analysis. The two coexist; many teams use R to independently check SAS outputs and vice versa.
- R adoption is growing, not total. The trajectory is real — regulatory acceptance is settled, the pharmaverse keeps maturing, CROs increasingly advertise R expertise — but it is an ongoing migration, measured in years, not a finished switch.
The accurate summary: R is now a first-class, regulator-accepted option for clinical programming, sitting alongside SAS in a field that is gradually rebalancing. That is a genuinely good position to learn into — the demand for people who can do compliant R is rising precisely because the shift is real but incomplete.
What it means for you
Put the pieces together and the takeaway for a learner is direct: you can do real submission work in open-source R, and the skills are in demand. The regulator accepts it, the pilots proved the path, the pharmaverse provides the tools, and your CDISC knowledge carries over unchanged.
That is the premise of this entire pillar. The hands-on series ahead — building SDTM domains, deriving ADaM datasets with admiral, producing TLFs, exporting XPT with xportr, and packaging it all toward a Define-XML-backed submission — teach exactly the workflow the pilots demonstrated. If you are coming from SAS, you keep your CDISC expertise and learn R idioms as the equivalent of the DATA step and your PROCs. If you are new, you are learning the modern, open path from the start. Either way, the free foundations are the frame, and the rest of the pillar is the work.
Ask Prova “is R really accepted by the FDA for clinical trial submissions, and what did the R Consortium pilots prove?” — it answers grounded in this pillar’s lessons, with runnable R you can try on example pharmaverse data. The runtime is the judge. Ask Prova →
Common issues
These are the misconceptions that trip people up when they first hear about the SAS-to-R shift.
Believing the FDA “mandates SAS” — or, the opposite, that it “endorses R.” Neither is true. The FDA requires no specific software; it requires a conformant, documented, reproducible submission. SAS was a convention, not a rule, and R is accepted when it meets the requirements — not preferred. Claim exactly that much and no more.
Thinking R adoption means abandoning CDISC. The opposite — CDISC is the part that does not change. SDTM, ADaM, Define-XML, and the eCTD package are language-agnostic; R just produces the same conformant outputs. Your standards knowledge is the most transferable thing you have.
Reading “the pilots succeeded” as “any R submission is approved.” The pilots are test submissions that proved the path — the FDA reviewing and reproducing an all-R package. They are not a guarantee for a specific marketed-product submission, where the sponsor still owns conformance, validation, and documentation. The path is proven; the work is still the work.
Frequently asked questions
Yes. The FDA does not require any specific statistical software — its 2015 Statistical Software Clarifying Statement says so — as long as the software used is fully documented (including version and build). What it requires is a conformant, reproducible submission, regardless of the language. The R Consortium’s pilots confirmed this in practice by submitting all-R packages through the real eCTD gateway and having them reviewed.
Yes — through the R Consortium R Submissions Working Group. Pilot 3 delivered the first publicly available R-based package that includes ADaM datasets plus tables and figures, all generated in R; it went through the eCTD gateway and the FDA accepted and reproduced the results, issuing its response in 2024. Later pilots added Shiny apps and WebAssembly/container technology. Every artifact is public on the R Consortium GitHub.
The pharmaverse is a curated, community-governed set of open-source R packages for clinical reporting, backed by PHUSE. It is not one package but a connected ecosystem covering the pipeline: sdtm.oak (SDTM), admiral (ADaM), metacore/metatools (metadata), rtables/tern/gtsummary (tables and figures), xportr (XPT export), and teal (interactive review apps). It is what makes an end-to-end R submission workflow practical.
No. SDTM, ADaM, Define-XML, Controlled Terminology, and the eCTD package are language-agnostic — they are defined by CDISC and the regulators, not by SAS or R. R produces the same conformant datasets and metadata a reviewer expects. Your CDISC knowledge transfers completely; only the tool that builds the datasets changes.
Not wholesale. SAS remains entrenched — validated macros, SOPs, legacy studies, and a large trained workforce — and is still the most common skill in job postings. The realistic picture is hybrid: many shops use SAS for stability-critical ADaM/TLF work and R for SDTM, Shiny review apps, QC, and exploratory analysis. R adoption is growing, not total — an ongoing shift toward coexistence, not a finished switch.
It counts for a lot. The hardest-won, most transferable knowledge in clinical programming is CDISC and the regulatory process, and none of that changes. Moving to R means learning R idioms as the equivalents of the DATA step and your PROCs, with admiral playing the role of a validated derivation macro library. Demand for programmers who know CDISC and can work in R is rising precisely because the shift is real but incomplete.
Test your understanding
For each statement, decide whether it is accurate or a myth, and say why in one line:
- “The FDA requires submissions to be programmed in SAS.”
- “The R Consortium pilots proved that an all-R package — including ADaM datasets — can be submitted to and reproduced by the FDA.”
- “Moving to R means re-learning the CDISC standards, because SDTM and ADaM are different in R.”
- “SAS is finished; the industry has fully switched to R.”
Two of these overstate the case (one in favor of SAS, one in favor of R), one is a factual milestone, and one confuses the tool with the standards.
- Myth. The FDA requires no specific software; SAS was a convention, not a rule. Submissions must be conformant and documented, in any language.
- Accurate. That is exactly what Pilot 3 demonstrated — the first public R package with ADaM + TLFs, accepted and reproduced by the FDA.
- Myth. The CDISC standards are language-agnostic; SDTM and ADaM are identical regardless of tool. You learn R idioms, not new standards.
- Myth (overstated the other way). SAS remains entrenched and most shops are hybrid; R adoption is growing, not total. It is a shift toward coexistence, not a completed replacement.
A. The FDA endorses R as its preferred software for clinical trial submissions. B. The FDA forbids R; submissions must be in SAS. C. The FDA requires no specific software and accepts R submissions that meet its requirements (conformant, documented, reproducible).
C. The FDA’s clarifying statement is explicit that it does not require any particular statistical software, as long as what was used is fully documented. A overstates it — the FDA accepts conforming R, it does not endorse or prefer it. B is the persistent myth — SAS was a convention, never a regulation.
References
The load-bearing claims in this lesson come from primary sources — read them directly:
- FDA does not require specific software. U.S. Food and Drug Administration, Statistical Software Clarifying Statement (May 2015): the agency “does not require use of any specific software for statistical analyses,” provided the software is fully documented (including version and build). FDA’s original posting is no longer live; the statement is documented in the R Foundation’s R: Regulatory Compliance and Validation Issues — https://www.r-project.org/doc/R-FDA.pdf.
- The R Consortium R Submissions Working Group (all pilots, public artifacts) — https://github.com/RConsortium/submissions-wg.
- Pilot 3 — FDA accepted and reproduced an all-R package with ADaM + TLFs. R Consortium, News from R Submissions Working Group – Pilot 3 Successfully Reviewed by FDA (2024) — https://r-consortium.org/posts/news-from-r-submissions-working-group-pilot-3/.
- Pilot 4 — Shiny via WebAssembly and containers, submitted through the eCTD gateway. R Consortium, Pilot 4 Successfully Submitted to FDA CDER (2024) — https://r-consortium.org/posts/using-r-to-submit-research-to-the-fda-pilot-4-successfully-submitted/.
- Pilot 5 and beyond — ongoing pilots (e.g. Dataset-JSON). R Consortium, R Submissions Working Group: Pilot 5 Launch and more! — https://r-consortium.org/posts/submissions-wg-pilot5-pilot6-and-more/.
- The pharmaverse — a curated, PHUSE-backed set of open-source R packages for clinical reporting — https://pharmaverse.org/.
Conclusion
The move from SAS to R in clinical programming is real, but it is best understood precisely. SAS became the default through inertia and ecosystem, never regulation — and the regulator has long made clear it requires no specific software, only a conformant, documented submission. The R Consortium pilots turned that open door into a proven, public path, with Pilot 3’s all-R package including ADaM datasets accepted and reproduced by the FDA. The pharmaverse supplies the production-grade tools to walk that path end to end. And through all of it, the CDISC standards do not change — only the tool that builds the datasets does. The honest framing is coexistence: SAS stays widespread, most shops are hybrid, and R adoption is growing — which makes compliant R a genuinely valuable skill to build.
That closes the foundations. You now have the whole frame: the data flow, the regulatory context, the estimand that defines the question, the CDISC standards that shape the data, and the open-source R path that implements all of it. The hands-on series ahead — building SDTM domains, deriving ADaM with admiral, producing tables and figures, and packaging a submission — are where you do the work the pilots demonstrated, on real example data.
Reuse
Citation
@online{2026,
author = {},
title = {From {SAS} to {R} in {Clinical} {Programming:} {What’s}
{Changing,} {What} {Isn’t}},
date = {2026-06-30},
url = {https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/05-sas-to-r},
langid = {en}
}