Clinical SAS, R and CDISC: How Clinical Trial Data Reaches the FDA, and Where Statistical Programming Is Heading

When a new medicine is approved, the headlines focus on the science and the patients. Rarely does anyone mention the thousands of datasets, programs and metadata files that allowed regulators to check the results independently. Yet without them, no approval would happen.

Behind every submission sits a team of clinical data managers and statistical programmers whose job is to turn raw trial data into standardised, traceable, reviewable evidence. It is one of the most in-demand skill sets in the life sciences, and it is going through an interesting period of change.

From case report form to reviewer's desk

Data in a clinical trial begins its journey at the site, typically captured in an electronic data capture (EDC) system. Laboratory results, ECGs, imaging reads and electronic patient-reported outcomes may arrive from separate vendors. Clinical data management teams clean, reconcile and query that data until the database is locked.

Then the programming work begins in earnest. Raw data must be converted into the standard formats regulators expect, analysis datasets must be derived, and tables, listings and figures (TLFs) must be produced for the clinical study report. Every step has to be reproducible and traceable back to the source.

CDISC standards: the common language

The Clinical Data Interchange Standards Consortium (CDISC) develops the standards that make this possible. For submissions to the FDA, the most important are:

SDTM (Study Data Tabulation Model). SDTM organises collected trial data into standard domains, such as DM for demographics, AE for adverse events, LB for laboratory results and VS for vital signs. It standardises variable names, structures and controlled terminology, so that a reviewer can navigate any study in a familiar way.

ADaM (Analysis Data Model). ADaM defines analysis-ready datasets derived from SDTM, such as ADSL, the subject-level analysis dataset, and structures like the Basic Data Structure (BDS) for measurements over time. A key ADaM principle is traceability: a reviewer should be able to follow any analysis value back to the SDTM data it came from.

SEND (Standard for Exchange of Nonclinical Data). SEND applies similar principles to nonclinical toxicology studies.

Define-XML. This metadata file describes every dataset and variable in a submission: its label, type, origin, derivation and controlled terminology.

Submitting study data in FDA-supported standards has been a binding requirement for studies in most NDAs, BLAs and ANDAs that started after 17 December 2016, under the FDA's guidance Providing Regulatory Submissions in Electronic Format - Standardized Study Data. The FDA Data Standards Catalog lists which versions are supported and when.

What the FDA's Technical Conformance Guide asks for

The FDA's Study Data Technical Conformance Guide (version 6.0 was released in March 2025) provides the practical detail. Among its recommendations:

• Sponsors should implement SDTM for clinical trial tabulation data, ideally before the study is conducted, rather than converting at the end.
• ADaM datasets should be derived from the data contained in SDTM datasets.
• Datasets are submitted in SAS XPORT version 5 transport format (.xpt), one dataset per file.
• Submissions include a define.xml file, a Clinical Study Data Reviewer's Guide (cSDRG) and an Analysis Data Reviewer's Guide (ADRG).
• The programs used to create ADaM datasets and key analyses are provided so that reviewers can understand how results were produced.

Sponsors also run conformance checks, such as those published by the FDA and applied through validation tools, to catch structural issues before submission.

Why SAS became the industry standard

For decades, SAS has been the dominant language for clinical statistical programming. There are good reasons. It handles large, structured datasets reliably, it has long-established procedures for the statistical methods used in trials, and it offers the kind of stable, well-documented, validated environment that regulated work demands. The XPT transport format itself originated with SAS.

As a result, most pharmaceutical companies and CROs have extensive SAS codebases, validated macros and standard operating procedures built around it. That installed base is a major reason why Clinical SAS programmers remain in strong demand.

The rise of R, and what the pilots showed

It is a common misconception that the FDA requires SAS. It does not. The agency's Statistical Software Clarifying Statement makes clear that it does not mandate any particular software, but that the software used should be fully documented, including version and build information.

Over the past several years, open-source R has gained ground in the industry, especially for data visualisation, exploratory analysis and interactive applications. To test how R-based submissions would work in practice, the R Consortium's R Submissions Working Group, a collaboration between pharmaceutical companies and the FDA, has run a series of public pilots:

• Pilot 1 (2021): tables and figures produced in R were submitted and reviewed.
• Pilot 2 (2022): the same outputs were delivered through an interactive Shiny application.
• Pilot 3: extended the approach to ADaM datasets as well as TLFs, all generated in R, and was successfully reviewed by the FDA.
• Pilot 4: tested WebAssembly and container technologies for delivering Shiny applications. FDA reviewers reportedly preferred the WebAssembly approach because it only required a web browser.
• Pilot 5: explored replacing XPT files with the CDISC Dataset-JSON format, with a resubmission in January 2026.

These pilots matter because they are open. Their code and submission packages are publicly available, which lets the whole industry learn from them.

So, SAS or R?

For people building careers in this field, the practical answer is: understand the data first, then learn the tools.

SAS remains deeply embedded in production submission work across pharma and CROs, and the demand for Clinical SAS programmers who understand SDTM and ADaM is well established. R skills are increasingly valued alongside SAS, particularly in organisations modernising their programming environments. Many teams now use both.

What does not change is the importance of the standards. A programmer who understands why ADaM requires traceability, how controlled terminology works, and what a reviewer needs from a define.xml file will adapt to any language.

Where AI fits in

AI and automation are starting to appear across the programming workflow: suggesting SDTM mappings, generating draft code for standard outputs, and helping check conformance. The R Consortium's planned Pilot 6 explicitly includes AI and automation tools.

These tools can save time, but they do not change the accountability. In a regulated submission, a human programmer and statistician must still be able to explain and defend every derivation. The FDA's broader thinking on AI, with its focus on context of use and credibility, applies here too. Generated code still needs to be reviewed, tested and validated like any other program.

Key takeaways

• CDISC standards (SDTM, ADaM, SEND and Define-XML) are the common language of FDA data submissions, and standardised study data has been required for studies starting after 17 December 2016 in most applications.
• The FDA's Study Data Technical Conformance Guide (v6.0, March 2025) sets out practical expectations, including XPT v5 datasets and reviewer's guides.
• The FDA does not mandate specific statistical software; the software used must be documented.
• R Consortium pilots have shown that R-based submissions, including ADaM datasets, can be successfully reviewed by the FDA.
• Clinical SAS remains central to industry workflows, with R and AI tools growing alongside it.

Start your statistical programming journey

CliniXen Institute's six-month Advanced Diploma in Clinical SAS is designed for life sciences, pharmacy and statistics graduates who want to build practical, submission-ready skills. The programme covers SAS programming, CDISC SDTM and ADaM, and the production of tables, listings and figures, with mentorship focused on helping learners move into industry roles.

References

1. US Food and Drug Administration. Study Data Technical Conformance Guide, Version 6.0, March 2025. https://www.fda.gov/media/88173/download
2. US Food and Drug Administration. Providing Regulatory Submissions in Electronic Format - Standardized Study Data: Guidance for Industry. https://www.fda.gov/media/82716/download
3. US Food and Drug Administration. Study Data Standards Resources (including the FDA Data Standards Catalog). https://www.fda.gov/industry/fda-data-standards-advisory-board/study-data-standards-resources
4. US Food and Drug Administration. Statistical Software Clarifying Statement, 2015. https://www.fda.gov/media/161196/download
5. CDISC. SDTM and ADaM standards. https://www.cdisc.org/standards/foundational/sdtm
6. R Consortium. R Submissions Working Group: 2026 Plans and 2025 Success. https://r-consortium.org/posts/submissions-wg-2026/
7. R Consortium. News from R Submissions Working Group - Pilot 3 Successfully Reviewed by FDA. https://r-consortium.org/posts/news-from-r-submissions-working-group-pilot-3/

Disclaimer: This article is for educational purposes and reflects publicly available regulatory and scientific information at the time of writing. Guidance documents are updated periodically; always consult the latest official version.