eCTD Submission Anatomy: What’s in a Clinical Study Data Package

The map of what a regulatory submission actually contains — the eCTD modules, the Module 5 folder layout, the SDTM and ADaM datasets, Define-XML, and the reviewer’s guides that make up the clinical data package — before you build each piece

You have validated ADaM datasets and a set of tables, listings, and figures. This lesson is the big-picture map of what happens next: what a regulatory submission data package actually contains and how it is organized. Learn the five eCTD modules (Module 5 holds the clinical study data), the Module-5 folder layout for SDTM and ADaM datasets, the Define-XML metadata and the cSDRG/ADRG reviewer’s guides, the SAS Transport (XPT) v5 exchange format your datasets ship in, and the reality of submitting R-based analyses — grounded in the R Consortium’s public FDA pilots. One runnable example exports a real ADaM dataset to a compliant XPT v5 file, the deliverable itself.

TipKey takeaways

• A submission is a highly structured package, not a folder of files. The eCTD (electronic Common Technical Document) organizes everything a health authority receives into five modules; the clinical study data lives in Module 5.
• The data package is datasets plus the metadata to read them. SDTM and ADaM datasets ship as XPT files, each accompanied by a Define-XML metadata file, a human reviewer’s guide (cSDRG for SDTM, ADRG for ADaM), and — for ADaM — the analysis programs that reproduce the results.
• Datasets travel as SAS Transport (XPT) version 5. It is the required exchange format, with strict limits: variable names ≤ 8 characters, labels ≤ 40, character values ≤ 200.
• You can produce a compliant XPT from R. The xportr package writes a conformant v5 transport file and enforces those limits — this lesson exports a real ADaM dataset and reads it back to prove it.
• R-based submissions are a demonstrated reality, not a claim. The R Consortium’s public pilots submitted R packages through the real FDA gateway and the agency completed the statistical review — a proof of feasibility, not a regulatory endorsement of any language.

Introduction

You have done the hard part. The SDTM (Study Data Tabulation Model) datasets are mapped, the ADaM (Analysis Data Model) datasets are derived and double-programmed, and the tables, listings, and figures — TLF for short — match the statistical analysis plan. Now the sponsor asks the question this series answers: what does the FDA actually receive, and how is it arranged?

The answer is not “a folder of .xpt files.” A regulatory submission is a strictly structured package so that any reviewer, at any agency, can open any study and find the same things in the same places. That structure is the eCTD — the electronic Common Technical Document — the harmonized format defined by ICH M4 (the International Council for Harmonisation’s Common Technical Document guideline). It sorts a marketing application into five modules, and the one you build as a clinical programmer is Module 5: the clinical study reports and their study data.

This lesson is the map you read before assembling any single piece. It covers the eCTD modules, the Module-5 folder layout, what the data package contains, the transport format your datasets ship in, and the reality of submitting R. The hands-on lessons that follow build each part; here is the whole shape first.

Every box in that tree is something you will build in this series. The rest of this lesson names each one — starting from the outermost structure, the eCTD.

The eCTD: five modules, one of them is yours

The eCTD is the electronic format for a regulatory application. It is not a filing convention layered on top of the science — it is how the science is organized for review, defined by the harmonized Common Technical Document (ICH M4) so that the FDA, EMA, and PMDA can all read the same submission. It has five modules:

Module	Name	What it holds
1	Regional administrative information	Region-specific forms, the cover letter, and labeling. Not part of the harmonized CTD — it differs by agency.
2	CTD summaries	The Clinical Overview and Clinical Summary, plus the nonclinical summaries.
3	Quality	Chemistry, manufacturing, and controls (CMC).
4	Nonclinical study reports	Pharmacology and toxicology.
5	Clinical study reports + study data	The CSR (Clinical Study Report) and the SDTM/ADaM datasets, Define-XML, reviewer’s guides, and analysis programs — the “data package.”

Module 1 is regional; Modules 2–5 are the harmonized CTD every agency shares. As a clinical data programmer, Module 5 is where your work lands — specifically its study-data section, which sits alongside each study’s CSR. The FDA’s expectations for that study data are set out in the Study Data Technical Conformance Guide and the broader Study Data Standards Resources hub, which name the CDISC standards and the transport format a submission must use.

The Module-5 folder layout

Inside Module 5, the study data follows a conventional folder structure, keyed by study. The exact nesting varies slightly across the FDA guide’s examples and sponsor conventions — treat the tree below as the representative shape (it is consistent with the FDA conformance guide and the community PHUSE paper What You Need to Know About Submitting Data to the FDA (DS02)), not a single universal rule:

m5/datasets/<study-id>/
├── tabulations/sdtm/        SDTM datasets
│     dm.xpt, ae.xpt, vs.xpt, ...   (XPT v5)
│     define.xml + define2-0-0.xsl  (metadata + stylesheet)
│     csdrg.pdf                     (reviewer's guide for SDTM)
│
└── analysis/adam/
      ├── datasets/          ADaM datasets
      │     adsl.xpt, adae.xpt, adtte.xpt   (XPT v5)
      │     define.xml + define2-0-0.xsl    (metadata + stylesheet)
      │     adrg.pdf                        (reviewer's guide for ADaM)
      │
      └── programs/          analysis programs
            *.r  /  *.sas    (code that reproduces the TLFs)

Two things in this layout catch people out. First, each standard carries its own define.xml — one for SDTM under tabulations/sdtm/, a separate one for ADaM under analysis/adam/datasets/ — not a single shared metadata file. Second, sponsors typically do not submit the SDTM mapping programs, but they do submit the ADaM and TLF analysis programs under analysis/adam/programs/, so the derivations and displays are reproducible from the submitted datasets.

What the data package contains

Each folder holds a small, fixed set of deliverables. Here is the full contents list — the pieces the rest of this series teaches you to build:

Deliverable	Format	Where	Purpose
SDTM datasets	XPT v5	tabulations/sdtm/	The collected trial data, standardized per the SDTMIG (SDTM Implementation Guide)
ADaM datasets	XPT v5	analysis/adam/datasets/	Analysis-ready data, derived per the ADaMIG (ADaM Implementation Guide)
Define-XML (SDTM)	XML + XSL	tabulations/sdtm/	Machine-readable metadata describing every SDTM variable
Define-XML (ADaM)	XML + XSL	analysis/adam/datasets/	ADaM metadata, including traceability back to SDTM
cSDRG	PDF	tabulations/sdtm/	The clinical SDTM Reviewer’s Guide — human context for the SDTM data
ADRG	PDF	analysis/adam/datasets/	The Analysis Data Reviewer’s Guide — analysis context and results metadata
Analysis programs	.r / .sas	analysis/adam/programs/	Code that reproduces the ADaM derivations and the TLFs

A few definitions, because these acronyms recur through the series. Define-XML is a machine-readable metadata file — the reviewer’s data dictionary — that describes every dataset and variable so a tool can validate and navigate the data; it ships with a stylesheet (define2-0-0.xsl) that renders it as a readable page. The two reviewer’s guides are human documents: the cSDRG (clinical SDTM Reviewer’s Guide) explains the SDTM datasets, and the ADRG (Analysis Data Reviewer’s Guide) explains the ADaM datasets and how the analyses were run. Both follow community templates published by PHUSE and CDISC — they are industry deliverables, not FDA-authored forms.

The transport format: SAS Transport (XPT) version 5

Your datasets do not travel as .rds, .parquet, or .sas7bdat. They ship as XPT — SAS Transport Format (XPORT) version 5 — the required exchange format named in the FDA conformance guide and registered as a preservation format in the Library of Congress format registry. It is a decades-old, deliberately simple format, and its age is why it has strict constraints:

• Variable names ≤ 8 characters (this is why SDTM and ADaM variable names are short — USUBJID, AVAL, TRTP).
• Variable labels ≤ 40 characters.
• Character values ≤ 200 characters.
• No compression and no custom SAS formats.

You do not hand-craft an XPT. In R, the xportr package (part of the pharmaverse) writes a compliant v5 transport file and enforces those limits as it goes. The pipeline below takes a real ADaM subject-level dataset (ADSL, one row per subject) from pharmaverseadam, attaches an illustrative metadata spec (the kind of information a Define-XML carries — variable types, lengths, and labels), applies it, and writes the transport file. Read it top to bottom: xportr_type(), xportr_length(), and xportr_label() set each variable’s storage type, length, and label from the spec, and xportr_write() emits the .xpt.

library(xportr)
library(pharmaverseadam)
library(haven)

adsl  <- pharmaverseadam::adsl
vars  <- c("STUDYID", "USUBJID", "SUBJID", "SITEID", "AGE", "SEX", "RACE", "ARM")
small <- adsl[1:15, vars]

# An illustrative metadata spec — the kind of information a real Define-XML carries
# for ADSL (variable types, lengths, and labels). Not an official spec; it shows what
# xportr reads to build a conformant transport file.
meta <- data.frame(
  dataset  = "ADSL",
  variable = vars,
  type     = c("character", "character", "character", "character",
               "numeric", "character", "character", "character"),
  format   = NA_character_,
  length   = c(20, 40, 10, 10, 8, 2, 20, 20),
  label    = c("Study Identifier", "Unique Subject Identifier",
               "Subject Identifier for the Study", "Study Site Identifier",
               "Age", "Sex", "Race", "Description of Planned Arm"),
  order    = 1:8,
  stringsAsFactors = FALSE
)

out <- file.path(tempdir(), "adsl.xpt")
small |>
  xportr_metadata(meta, domain = "ADSL") |>  # attach the spec first (xportr requires it)
  xportr_type()   |>                         # set each variable's storage type
  xportr_length() |>                         # apply the v5 length limits
  xportr_label()  |>                         # attach the <= 40-char labels
  xportr_write(path = out, strict_checks = FALSE)

file.exists(out)      # the transport file was written

[1] TRUE

file.info(out)$size   # its size in bytes

[1] 3840

The file exists and is a few kilobytes — small, but that .xpt is the deliverable, the exact object that goes into analysis/adam/datasets/. To confirm it is a genuine, readable v5 transport file rather than an opaque blob, read it back and inspect it:

library(haven)

back <- haven::read_xpt(out)

dim(back)                                  # 15 subjects x 8 variables, round-tripped

[1] 15  8

attr(back$STUDYID, "label")                # the label survived the transport

[1] "Study Identifier"

readBin(out, "character", n = 1)           # the v5 transport header signature

[1] "HEADER RECORD*******LIBRARY HEADER RECORD!!!!!!!000000000000000000000000000000  SAS     SAS     SASLIB  6.06    bsd4.2                          01JUL26:21:10:5901JUL26:21:10:59                                                                HEADER RECORD*******MEMBER  HEADER RECORD!!!!!!!000000000000000001600000000140  HEADER RECORD*******DSCRPTR HEADER RECORD!!!!!!!000000000000000000000000000000  SAS     adsl    SASDATA 6.06    bsd4.2                          01JUL26:21:10:5901JUL26:21:10:59                Subject Level Analysis                          HEADER RECORD*******NAMESTR HEADER RECORD!!!!!!!000000000800000000000000000000  "

The dataset round-trips to 15 rows by 8 columns, the variable label ("Study Identifier") is preserved, and the first bytes of the file are the SAS transport header HEADER RECORD*******LIBRARY HEADER RECORD!!!!!!! — the signature that proves it is a valid version-5 transport file. One note for real submissions: we passed strict_checks = FALSE here so the demo renders cleanly; a submission-grade run uses strict_checks = TRUE, which promotes xportr’s length and type warnings to hard errors so a non-conformant dataset cannot slip through.

Submitting R to a regulator: what the pilots actually showed

A fair question follows all of this: can a submission built in R — not SAS — be sent to the FDA? The honest, precisely-stated answer is yes, this has been done publicly, and it is worth being careful about what that does and does not mean.

The R Consortium’s R Submissions Working Group ran a series of public pilots that submitted R-based packages to the FDA through the real eCTD gateway:

• Pilot 1 submitted the R scripts that generate a set of TLFs; it was sent in late 2021 and the FDA completed its statistical review in 2022 — the first public R-based example (pilot 1 site, repository).
• Pilot 2 submitted an R Shiny application.
• Pilot 3 submitted a full R package that generates ADaM datasets and TLFs — built on exactly the toolchain this pillar teaches (admiral, metacore/metatools, and xportr). It went through the eCTD gateway and the FDA issued its response in 2024 (pilot 3 write-up, pilot 3 site).

Here is the careful framing, because it is easy to overstate. These pilots demonstrate feasibility and give the industry a public, working example of an all-R submission that the FDA reviewed. They do not mean R is “FDA-approved” or “endorsed” — the FDA is software-agnostic. It does not approve, endorse, or require any particular programming language; the sponsor owns their tools, their qualification, and their results. What the pilots prove is that an R-based package can meet the submission requirements — the formats, the folder structure, the reproducibility — that this series teaches you to satisfy. All the pilot materials are public, so they double as a reference implementation of everything mapped above.

One tool worth knowing by name here: pkglite compacts an entire R package (its scripts and structure) into a single plain-text file that can be submitted through the eCTD as one document, then restored — the mechanism the pilots used to bundle their R code. It sits outside this lesson’s runnable example, but you will meet it when you assemble the submission bundle; the pilot repositories above show it in use.

Where the rest of this series goes

You now have the map. The hands-on lessons that follow build each box in the tree at the top of this page: exporting datasets to conformant XPT v5 with xportr, generating the Define-XML metadata, writing the cSDRG and ADRG reviewer’s guides, and bundling R programs for the eCTD with pkglite — assembling, piece by piece, the package the R Consortium pilots submitted. Every one of them slots into the Module-5 layout you just read.

🟢 With an AI agent

Ask Prova “I have validated ADaM datasets and TLFs — walk me through exactly what goes into the Module 5 submission package and where each file belongs.” — it answers grounded in this pillar’s lessons, with runnable pharmaverse code you can try on example data. The runtime is the judge. Ask Prova →

Common issues

Your dataset breaks the XPT v5 length limits. SAS Transport v5 caps variable names at 8 characters, labels at 40, and character values at 200. A long derived variable name (TREATMENT_GROUP), a verbose label, or a free-text field over 200 characters will fail conformance. This is why CDISC variable names are terse — design to the limit from the start. xportr flags these violations, and running xportr_write(..., strict_checks = TRUE) turns them into hard errors so a non-conformant dataset cannot be written by accident.

You ship one define.xml for the whole submission. Each standard needs its own Define-XML: one for SDTM in tabulations/sdtm/, a separate one for ADaM in analysis/adam/datasets/. A single shared metadata file — or an ADaM define that omits the traceability back to SDTM — is a common conformance finding. Build and validate the two define files independently, against their respective datasets.

You submit the wrong programs, or none. Sponsors generally do not submit the SDTM mapping programs, but they do submit the ADaM and TLF analysis programs (analysis/adam/programs/) so the derivations and displays are reproducible. Omitting the analysis programs, or including SDTM mapping code that was not requested, both miss the expectation — the goal is that a reviewer can reproduce every submitted analysis result from the submitted ADaM data.

Frequently asked questions

NoteWhat is eCTD Module 5?

The eCTD (electronic Common Technical Document) is the harmonized format for a regulatory submission, and Module 5 is the section that holds the clinical study reports and study data. For a clinical data programmer, Module 5 is where your work lands: each study’s Clinical Study Report (CSR) sits alongside its SDTM and ADaM datasets, the Define-XML metadata, the cSDRG/ADRG reviewer’s guides, and the ADaM analysis programs. Modules 1–4 cover regional administrative information, the CTD summaries, quality (CMC), and nonclinical reports. See ICH M4.

NoteWhat is in a clinical submission data package?

The Module-5 data package contains, per study: the SDTM datasets (collected data, standardized) and ADaM datasets (analysis-ready data), each as XPT v5 files; a Define-XML metadata file for each standard, with its rendering stylesheet; a cSDRG (clinical SDTM Reviewer’s Guide) and an ADRG (Analysis Data Reviewer’s Guide) as PDFs; and the analysis programs (.r/.sas) that reproduce the tables, listings, and figures. The FDA’s Study Data Technical Conformance Guide specifies the standards and formats it must use.

NoteCan you submit R to the FDA?

Yes — it has been done publicly. The R Consortium’s R Submissions Working Group submitted R-based packages through the real FDA eCTD gateway, and the FDA completed the statistical review (Pilot 1; Pilot 3 submitted ADaM datasets and TLFs generated with admiral and xportr). Be precise about what this means: the pilots demonstrate feasibility, not that R is “FDA-approved.” The FDA is software-agnostic — it does not approve or require any language; the sponsor owns their tools, qualification, and results. R can meet the submission requirements, and the pilots are a public working example.

NoteWhat is an ADRG?

The ADRG (Analysis Data Reviewer’s Guide) is a PDF that accompanies the ADaM datasets and gives a reviewer the human context the datasets alone cannot: how the analysis datasets were derived, the analysis conventions used, and any study-specific decisions, plus analysis-results metadata. Its SDTM counterpart is the cSDRG (clinical SDTM Reviewer’s Guide). Both follow community templates published by PHUSE and CDISC — they are industry deliverables, not FDA forms.

NoteWhat is XPT (SAS Transport) format?

XPT is SAS Transport Format (XPORT) version 5, the required exchange format for datasets in a regulatory submission — a simple, open, decades-old format registered by the Library of Congress. Its age imposes strict limits: variable names ≤ 8 characters, labels ≤ 40, character values ≤ 200, no compression. In R, the xportr package writes a compliant .xpt and enforces those limits, so a dataset you export round-trips to the exact variables and labels the metadata specifies.

Test your understanding

ImportantYour turn: place the deliverables in the package

You have finished a study and hold six things ready to submit: (1) adsl.xpt, (2) the SDTM Define-XML, (3) the ADRG, (4) ae.xpt (the SDTM adverse-events dataset), (5) the analysis program that produces the efficacy TLFs, and (6) the cSDRG. Using the Module-5 layout in this lesson, name the folder each one belongs in, and state which eCTD module the whole package sits in.

TipHint

There are two branches under m5/datasets/<study-id>/: tabulations/sdtm/ for the SDTM standard and analysis/adam/ for the ADaM standard (with datasets/ and programs/ beneath it). Each standard keeps its own datasets, its own Define-XML, and its own reviewer’s guide. Ask, for each item: is it SDTM or ADaM, and is it a dataset, metadata, a reviewer’s guide, or a program?

TipSolution

The whole package sits in eCTD Module 5 (clinical study reports and study data). Within m5/datasets/<study-id>/:

• ae.xpt (SDTM) and the SDTM Define-XML and the cSDRG → tabulations/sdtm/. All three belong to the SDTM standard: its dataset, its metadata, its reviewer’s guide.
• adsl.xpt (ADaM) and the ADRG → analysis/adam/datasets/. The ADaM dataset and its reviewer’s guide live together (the ADaM Define-XML would join them here too).
• The efficacy-TLF analysis program → analysis/adam/programs/. Analysis programs are submitted so a reviewer can reproduce the results from the ADaM data.

The pattern to hold: each standard — SDTM and ADaM — carries its own datasets plus its own metadata plus its own reviewer’s guide, and the analysis programs sit beside the ADaM data they produce.

NoteQuick check: how many Define-XML files does a submission with both SDTM and ADaM contain?

A. One shared define.xml for the whole submission B. Two — one for SDTM and a separate one for ADaM C. One per dataset (a define.xml for dm.xpt, another for ae.xpt, and so on)

TipShow answer

B. Each standard carries its own Define-XML: one under tabulations/sdtm/ describing all the SDTM datasets, and a separate one under analysis/adam/datasets/ describing the ADaM datasets (including their traceability back to SDTM). A is the common mistake — a single shared file is a conformance finding. C is wrong because a Define-XML describes all the datasets in its standard, not one file per dataset.

Conclusion

A regulatory submission is a structured package, and the clinical data programmer owns one well-defined part of it. The eCTD sorts the application into five modules; Module 5 holds the clinical study data; and within it, each standard — SDTM and ADaM — travels as XPT v5 datasets alongside its own Define-XML metadata and its own reviewer’s guide (cSDRG for SDTM, ADRG for ADaM), with the ADaM analysis programs so the results reproduce. R can produce every one of these deliverables — the xportr example here wrote a conformant transport file, and the R Consortium’s public pilots showed a full R-based submission clear the FDA’s review. Hold this map, and each hands-on lesson that follows is one box in the tree: export, metadata, reviewer’s guides, and the bundle.

Note

This lesson is reproducible: every result on this page was produced by the code shown — copy any block and run it to reproduce them. The runtime is the judge.

References

• ICH M4: The Common Technical Document — the harmonized CTD structure the eCTD implements, including the five modules.
• FDA Study Data Technical Conformance Guide and the Study Data Standards Resources hub — the FDA’s expectations for submitted study data, the CDISC standards, and the transport format.
• Solanki & Low, What You Need to Know About Submitting Data to the FDA (Paper DS02), PHUSE US Connect 2020 — a community reference for the Module-5 study-data folder layout.
• SAS Transport Format (XPORT) V5 — Library of Congress format registry — the XPT v5 exchange format and its constraints.
• xportr (CRAN) — the pharmaverse package that writes compliant XPT v5 transport files from R.
• PHUSE — the community organization that publishes the cSDRG and ADRG reviewer’s guide templates.
• R Consortium R Submissions Working Group: working group · Pilot 1 (TLF scripts to FDA) · Pilot 3 (ADaM + TLF package) — public, reviewed R-based submissions demonstrating feasibility.

Related lessons

• The SDTM tabulation model — the structure of the SDTM datasets that fill tabulations/sdtm/. · Create ADSL in R with admiral — building the analysis dataset this lesson exports to XPT. · R package qualification with riskmetric — qualifying the packages (xportr, admiral) that produce the package. · The clinical-trial data flow — where the submission sits in the wider drug-development pipeline.
• Where this fits: map the SDTM and ADaM data → validate it → assemble the submission package (you are here) → export to XPT, generate Define-XML, write the reviewer’s guides, and bundle the R programs in the lessons that follow. · Submission packaging — the full series. · Pharma & Clinical — the pillar.

Was this page helpful?

Prove you can do it. Master the whole Clinical Programming in R (pharmaverse) series — track your path, build projects, and earn a certificate.

Start free →

Go Pro — unlimited Prova on your own data and a verifiable certificate that proves the skill.

from $15/mo billed yearly

Go Pro →

✓ You're Pro — keep going. The runtime is the judge.

Get new R & Python lessons by email

Practical, reproducible, no spam. Unsubscribe anytime.

Double opt-in. We never share your email.

Share this pageXLinkedInRedditHN