By: Danielle Stephenson, Senior Manager, Statistical Programming; Audrey Chin, Statistical Programmer; Madeline Penniston, Statistical Programmer
Proof From a Real, Validated Statistical Programming Workflow
For directors and VPs of biostatistics, the practical question about open-source R is how it holds up to FDA scrutiny after submission. The Atorus™ team set out to answer that question in the most direct way available and shared their findings at PharmaSUG 2026.¹
The team rebuilt the outputs the FDA itself defines as the standard. Working entirely in validated, open-source R, they recreated the tables and listings from the FDA’s Standard Safety Tables and Figures Integrated Guide, then held every output to the test that carries weight in regulatory work: numerical equivalence with SAS®-produced outputs. ²
Rebuilding the FDA’s Standard Outputs in R
The Integrated Guide specifies 55 safety tables, including 6 listings, alongside 22 safety figures, organized across general, adverse event, subgroup, laboratory, and vital signs categories. The Atorus team designed shells for 54 of those tables and all 6 listings, then built working R template programs for 37 tables and all 6 listings using CDISC Pilot ADaM datasets. Choosing an industry-standard test dataset made every result verifiable and reproducible.
They didn’t stop at the FDA set. Drawing on standard mocks covering 32 safety tables, 24 efficacy tables, and 32 figures, the team produced templates for all the mock safety tables, 22 of the efficacy tables, and 29 of the figures.
It is worth highlighting — many clinical outputs share a common structure, and one well-built template can generate numerous deliverables with small modifications — that’s where efficiency gains start to compound across a study.
How Validated R Statistical Programming Held Up Against SAS®-Produced Outputs
Evidence is only as strong as the validation behind it, so the team worked at two levels:
First, every R package entering the workflow went through structured package validation and risk assessment, confirming each function behaved as expected inside a controlled environment. That foundation was provided by OpenVal® — a clinical-grade, validated R environment installed directly on your system for reproducibility and traceability. Many of the used packages came from the pharmaverse, a coordinated set of open-source R packages built specifically for clinical reporting rather than adapted from general-purpose tooling.³
Second, each template output was compared to an independently produced SAS® version of the same shell. The team evaluated layout, row and column definitions, labeling, and most critically the cell-level numeric results. Any discrepancy was investigated, resolved, and documented before a template was finalized.
That parallel approach revealed exactly the kind of detail that separates a demo from a submission-ready workflow. R and SAS® handle numeric rounding differently, which can produce discrepancies. The team wrote a rounding function that reflects SAS® behavior, then applied the same logic across every related table and figure, so calculated statistics remained consistent everywhere they appeared.
The programs ran in RStudio Pro on Posit Workbench inside Ageirein™, Atorus’ clinical data analytics platform. Built on R 4.4.2, they were confirmed to run on R 4.5.0 as well, so the workflow is consistent as new versions are released.
The Next Phase: A Reusable Framework
Rather than writing a separate program for every table, the team built a standardized framework with consistent naming, input expectations, and output behavior. If you can understand one template, you can understand them all. A controlled .Rprofile set default options, so every generated document came out uniform — no manual formatting decisions, no inconsistency across outputs. Also, the templates were parameterized to accept standardized inputs and metadata, which means the same structural code works across studies with very little change.
A handful of efficacy tables and figures involving more complex statistical methods were deferred to a later phase, and not every table in the guide was programmed because of data constraints. That level of transparency is important to a technical reviewer. It indicates a workflow built for real regulatory conditions rather than a controlled showcase.
What This Means for Your Submission Strategy
For anyone evaluating where R fits alongside SAS®, the findings are clear: R and SAS® both have a place in a statistical programming workflow. The goal is validated outputs, not a specific tool or language. Validated open-source packages generated every foundational safety output the FDA guide describes.
Standardized architecture made those outputs repeatable across studies, and parallel SAS® validation confirmed numerical equivalence. In short, open-source adoption in clinical programming meets the control and rigor that regulatory work demands.
Atorus approaches analytical programming across R, Python, and SAS®, pairing open-source flexibility with the validation discipline that submissions require. With OpenVal supplying the validated R package foundation and Ageirein providing the platform to build and run outputs, teams get both the flexibility of open-source and the traceability regulators expect.
If your team is evaluating where validated R fits in your clinical data analytics and submission strategy, reach out to start the conversation.
FAQs
References
- Stephenson, D., Chin, A., & Penniston, M. (2026). Breaking the Shell: Validated R Workflows To Meet FDA Standards. PharmaSUG 2026, Paper ET-189.
- U.S. Food & Drug Administration. (2025). Standard Safety Tables and Figures: Integrated Guide. Retrieved February 23, 2025.
- pharmaverse. An Open-Source Ecosystem of R Packages for Clinical Reporting.
Danielle Stephenson
Senior Manager, Statistical Programming, Atorus
Danielle has supported clinical studies across multiple phases since 2017, spanning SDTM and ADaM datasets, define.xml files, reviewer’s guides, and TFLs for FDA and PMDA submissions. She works in both SAS® and R, with a focus on the clarity, traceability, and rigor that regulated environments demand, and on helping teams deliver careful, high-quality technical work inside complex systems.
Audrey Chin
Statistical Programmer, Atorus
Audrey has been with the Atorus team for almost two years. Her work includes utilizing SAS® and R to develop SDTMs, ADaMs, and TFLs for FDA submission. Another professional endeavor of Audrey’s is Atorus Academy, where she assists the training team as a content creator and backup trainer, teaching clinical programmers R through a SAS® lens.
Madeleine Penniston
Statistical Programmer, Atorus
Madeleine produces analysis displays from the clinical database, including datasets, tables, listings, and graphs for clinical study reports. She programs primarily in SAS® and R to develop SDTM, ADaM, and TFL outputs in line with sponsor SOPs, Good Clinical Practice, and ICH guidelines. She also supports the Atorus Academy™ training team, which teaches the transition from SAS® to R within clinical programming workflows.