Clinical Trial Data Flow: From CRF to SDTM, ADaM, TLF, and Submission

How a Phase III trial’s raw measurements become a regulatory submission — the standards, the owners, and the R packages at every stage

The orienting map for clinical trial programming in R. Follow a single data point from the case report form (CRF/EDC) through SDTM tabulation and ADaM analysis datasets to the tables, listings, and figures (TLF) that go to the FDA — and see which CDISC standard governs each stage and which pharmaverse package (admiral, sdtm.oak, xportr, rtables, tern) implements it.

TipKey takeaways

• A clinical trial’s data moves through five stages — CRF/EDC → SDTM → ADaM → TLF → submission — and clinical programming is the craft of moving it correctly.
• SDTM (Study Data Tabulation Model) standardizes the collected data into fixed domains; ADaM (Analysis Data Model) derives analysis-ready datasets from SDTM; TLF (Tables, Listings, Figures) are the outputs that go into the submission.
• CDISC sets the standards at each stage (CDASH for collection, SDTM-IG, ADaM-IG, Controlled Terminology, Define-XML); the pharmaverse is the open-source R toolkit that implements them (admiral, sdtm.oak, xportr, rtables, tern).
• The non-negotiable thread is traceability: every analysis number must trace back through ADaM and SDTM to the raw value a site recorded. ADaM exists to make that walk-back possible.
• The industry is shifting SAS → R for submissions — the FDA accepts R-based packages — so these standards plus the pharmaverse are now a credible, end-to-end path to a regulatory filing.

Introduction

A Phase III trial enrolls a few hundred patients across dozens of sites. Each visit generates data — vital signs, lab draws, adverse events, doses given, the date a patient progressed — and all of it lands in an electronic data capture (EDC) system as raw, study-specific tables. Months later, a regulator opens a submission and expects to find a demographics table, a survival curve, and an adverse-event summary, each one traceable back to those raw values, in a format they have seen a thousand times before.

Getting from the first to the second is clinical trial programming. This lesson is the map of that journey: the five stages a data point passes through, who owns each one, which CDISC (Clinical Data Interchange Standards Consortium) standard governs it, and which pharmaverse R package does the work. It is the orienting lesson for the whole pillar — read it once and every later lesson (build an ADSL, derive a time-to-event endpoint, render an AE table) slots into a place you already understand.

No code to install and no CDISC background assumed. If you know base R, you have enough.

The clinical trial data flow

The pipeline is a one-way standardization-then-analysis flow, with one critical twist: each downstream stage stays traceable back to the stage before it.

flowchart TD
  A["CRF / EDC<br/>raw collected data"] --> B["SDTM<br/>standardized tabulation"]
  B --> C["ADaM<br/>analysis-ready datasets"]
  C --> D["TLF<br/>tables · listings · figures"]
  D --> E["Submission<br/>FDA · EMA · PMDA"]
  C -. "traceable to" .-> B
  D -. "traceable to" .-> C

Figure 1

Read it as a sentence: collect the data (CRF/EDC), standardize it (SDTM), derive what you will analyze (ADaM), produce the outputs (TLF), and submit. The dashed arrows are the point of the whole discipline — an analysis value is only as trustworthy as the path that links it back to a number a clinical site actually recorded.

Stage 1 — Raw data (CRF / EDC)

A case report form (CRF) is the structured questionnaire a site fills in for each subject; an EDC (electronic data capture) system is the software that collects those forms. The output is raw, study-specific data — column names, layouts, and code-lists chosen for this trial, not for any external standard. It is usually owned by clinical data management, and the CRF itself is typically designed to the CDISC CDASH standard (Clinical Data Acquisition Standards Harmonization) so that collection is consistent and maps cleanly to SDTM later.

The key property to remember: raw data is not comparable across studies. Every sponsor and every EDC vendor names things differently. Standardization is the next stage’s whole job.

Stage 2 — SDTM (Study Data Tabulation Model)

SDTM reshapes the raw data into a fixed, regulator-expected structure. The data is split into domains — standardized tables, each holding one kind of information, identified by a two-letter code: DM (demographics), AE (adverse events), EX (exposure/dosing), VS (vital signs), LB (laboratory results), and many more. Every domain has prescribed variables (subject identifier, a sequence number, ISO-8601 dates) defined by the SDTM Implementation Guide (SDTM-IG), and coded values come from CDISC Controlled Terminology.

SDTM is essentially tabulation: a faithful, standardized record of what was observed, mostly one row per observation. It is not yet shaped for statistics — that is deliberate. SDTM’s job is to make any study’s data findable in the same place, every time. It is typically produced by clinical or statistical programmers and is one of the two dataset packages a sponsor submits.

Stage 3 — ADaM (Analysis Data Model)

ADaM takes the standardized SDTM data and turns it into analysis-ready datasets — the inputs a statistical program can run on directly. Where SDTM tabulates, ADaM derives: treatment variables, population flags (e.g. a Safety Population flag), baseline values, change-from-baseline, and visit windows that SDTM does not carry. The common dataset shapes are ADSL (one row per subject — the subject-level backbone), BDS (Basic Data Structure, for measurements over time), and OCCDS (Occurrence Data Structure, for events like adverse events). Frequent datasets include ADSL, ADAE (adverse events), ADLB (labs), and ADTTE (time-to-event).

The ADaM Implementation Guide (ADaM-IG) rests on a few fundamental principles: ADaM data and its metadata must support clear, unambiguous communication, provide traceability (every value walks back to its SDTM source, and forward to the analysis result), be analysis-ready (usable by common software with minimal extra programming), and be associated with metadata. In practice an ADaM dataset is therefore also self-contained (it carries every variable its analysis needs) and usually structured one row per analysis unit. Traceability is the soul of ADaM and the reason it exists as a separate stage rather than analyzing SDTM directly. ADaM is typically owned by statistical programmers, who build it to realize the analysis the biostatistician specified in the Statistical Analysis Plan.

Stage 4 — TLF (Tables, Listings, Figures)

TLF are the actual outputs of the trial: the tables (a demographics summary, an adverse-event incidence table), listings (per-subject data printouts), and figures (a Kaplan–Meier survival curve, a forest plot) that go into the Clinical Study Report and the submission. They are produced from the ADaM datasets, following pre-agreed mock shells that specify each output’s title, layout, and footnotes before any code is written. TLF programming is typically owned by statistical programmers, against shells designed by the biostatistician.

A TLF is the most visible artifact — it is what a reviewer reads — but it carries no new data: it is a formatted view of ADaM, which is a derived view of SDTM, which is a standardized view of the raw data. Trace any number on a submission table back along that chain and you should land on a value a site recorded.

Stage 5 — Submission

The final package goes to a health authority — the FDA (United States), EMA (Europe), PMDA (Japan) — as part of the eCTD (electronic Common Technical Document), with the study data living in Module 5. It contains the SDTM and ADaM datasets (as XPT transport files), the TLF outputs, a Define-XML document describing the datasets and their derivations for the reviewer, reviewer’s guides (ADRG/SDRG), and the analysis programs. Define-XML is the machine-readable backbone of traceability — it is how a reviewer navigates from a result back to its source without opening your code.

Historically this was a SAS world. That is changing: the FDA now accepts R-based submissions, and the R Consortium’s Submissions Working Group has run several successful pilot submissions to the FDA using exactly the open-source toolkit below. That shift is why learning the pharmaverse path is now a credible career and submission strategy, not a hobby.

From tabulation to analysis: a concrete look

The single most important structural idea in the whole flow is the SDTM → ADaM shift: SDTM tabulates one row per record, while ADaM’s subject-level dataset (ADSL) collapses to one row per subject and adds derived analysis variables. Here is that shift in a few lines of base R — no packages, made-up values (the real teaching data lives in {pharmaversesdtm} and {pharmaverseadam}, used in the later series):

# SDTM EX (Exposure): one row per dosing RECORD — a subject can appear many times.
ex <- data.frame(
  USUBJID = c("01-701", "01-701", "01-702", "01-703"),
  EXTRT   = c("DRUG", "DRUG", "PLACEBO", "DRUG"),
  EXSTDTC = c("2026-01-05", "2026-01-19", "2026-01-06", "2026-01-04")
)
ex

  USUBJID   EXTRT    EXSTDTC
1  01-701    DRUG 2026-01-05
2  01-701    DRUG 2026-01-19
3  01-702 PLACEBO 2026-01-06
4  01-703    DRUG 2026-01-04

Subject 01-701 has two exposure records. SDTM keeps them as two rows — it faithfully tabulates every dosing event. Now the ADaM ADSL: exactly one row per subject, with a derived Safety Population flag (SAFFL) — “did this subject receive at least one dose?” — computed from the EX records above.

subjects <- c("01-701", "01-702", "01-703")

adsl <- data.frame(
  USUBJID = subjects,
  TRT01A  = c("Drug", "Placebo", "Drug"),                 # actual treatment, analysis-ready
  SAFFL   = ifelse(subjects %in% ex$USUBJID, "Y", "N")    # derived: dosed at least once
)
adsl

  USUBJID  TRT01A SAFFL
1  01-701    Drug     Y
2  01-702 Placebo     Y
3  01-703    Drug     Y

Three rows out, one per subject, each carrying a variable (SAFFL) that did not exist in the raw or SDTM data — it was derived, and you can trace it straight back to the EX records that produced it. That is ADaM in miniature: per-analysis-unit structure, derived variables, full traceability. Real derivations get far richer (baseline, change-from-baseline, treatment-emergent flags, event/censor logic), and the admiral package exists to do them correctly — but the shape of the idea is exactly this.

Where CDISC standards apply

CDISC (Clinical Data Interchange Standards Consortium) is the body whose standards make a submission legible to a regulator. Each stage above has its governing standard:

Standard	Governs	Stage
CDASH	How data is collected on the CRF	Raw / CRF
SDTM-IG	How collected data is tabulated into domains	SDTM
Controlled Terminology	Standardized code-lists / valid values (NCI/EVS-maintained)	SDTM & ADaM
ADaM-IG	How analysis-ready datasets are structured & derived	ADaM
Define-XML	Machine-readable dataset metadata & derivation traceability	Submission

A sixth piece sits above the data: ICH E9(R1) (an International Council for Harmonisation guideline) and its estimands framework define what question the analysis answers, which the biostatistician translates into the ADaM variables and TLF shells — the bridge from the trial’s objective to the programming. (That framework gets its own lesson later in this series.)

Where the pharmaverse fits

The pharmaverse is a cross-industry family of open-source R packages, one (or several) for each stage — the R answer to the SAS macros that did this work for decades. You will meet each of these hands-on in the later series; for now, just see the map:

Stage	Lead pharmaverse packages	What they do
Raw → SDTM	sdtm.oak, pharmaversesdtm	Map raw to SDTM domains; example SDTM data
SDTM checks / metadata	xportr, sdtmchecks, metacore, metatools	Type/label, conformance checks, spec-driven metadata
SDTM → ADaM	admiral, metacore, metatools	Derive ADaM datasets (admiral is the flagship)
ADaM → TLF	rtables, tern, gtsummary, cards, ggsurvfit	Build tables, clinical templates, KM figures
Submission	xportr, metacore, pkglite	Export XPT, manage Define-XML metadata, package programs

admiral is the centerpiece: a tidyverse-based, deliberately non-black-box toolbox for ADaM derivations, co-developed and maintained across many pharmaceutical companies through the pharmaverse community. Most of this pillar’s flagship lessons live in and around it.

🟢 With an AI agent

Ask Prova “what’s the difference between SDTM and ADaM?” — 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 →

How this maps to the rest of the pillar

Each stage above becomes its own series of hands-on lessons:

• SDTM programming — build core domains (DM, AE, EX, VS) from raw data with sdtm.oak, apply Controlled Terminology, and check conformance.
• ADaM with admiral — the flagship series: build ADSL, then BDS and OCCDS datasets (ADAE, ADLB), and ADTTE for time-to-event endpoints, which reuses the survival-analysis methods already on Datanovia.
• TLF generation — turn ADaM into demographics tables, AE summaries, and Kaplan–Meier figures with rtables/tern and gtsummary.
• Validation, QC, submission packaging, and agentic (AI-assisted) clinical programming round out the path to a complete, traceable, submission-ready package.

Those series are rolling out; this foundation is the frame they all hang on. Where a hands-on lesson on a given stage exists, the pillar hub links to it.

Common issues

These are conceptual mix-ups that quietly derail people new to clinical programming.

Confusing SDTM with ADaM. They look similar — both are CDISC-standard datasets with subject IDs — but they have different jobs. SDTM tabulates what was observed (faithful, mostly one row per record); ADaM derives what you analyze (analysis-ready, one row per analysis unit, with new variables). You analyze ADaM, not SDTM. If you find yourself computing change-from-baseline in SDTM, you are in the wrong stage.

Treating a TLF as the source of truth. A submission table carries no new data — it is a formatted view of ADaM, which derives from SDTM, which standardizes the raw data. When a number looks wrong, debug backwards along that chain (TLF → ADaM → SDTM → raw), not by patching the table.

Assuming you still need SAS. The whole pipeline above runs end-to-end in open-source R via the pharmaverse, and the FDA has accepted R-based submissions. SAS interoperability is handled by haven (read and write both .xpt and .sas7bdat) and xportr (CDISC-compliant .xpt export) — R is a first-class path, not a workaround.

Frequently asked questions

NoteWhat is the difference between SDTM and ADaM?

SDTM standardizes collected data into fixed domains for tabulation — a faithful record of what was observed, mostly one row per observation. ADaM derives analysis-ready datasets from SDTM — one row per analysis unit, with new derived variables (flags, baseline, change-from-baseline) and full traceability back to SDTM. You run statistics on ADaM, not SDTM.

NoteWhat does CDISC stand for, and why does it matter?

CDISC is the Clinical Data Interchange Standards Consortium. It defines the standards (CDASH, SDTM, ADaM, Controlled Terminology, Define-XML) that make every trial’s data follow the same structure, so regulators like the FDA and EMA can review submissions consistently and require these formats for new drug applications.

NoteWhat are TLFs in clinical trials?

TLF stands for Tables, Listings, and Figures — the summary outputs of a trial (a demographics table, an adverse-event summary, a Kaplan–Meier curve). They are produced from the ADaM datasets, following pre-specified mock shells, and go into the Clinical Study Report and the regulatory submission.

NoteCan you really submit to the FDA using R instead of SAS?

Yes. The FDA accepts R-based submissions, and the R Consortium’s Submissions Working Group has run successful pilot submissions to the FDA using the open-source pharmaverse toolkit. SAS is still common, but R via packages like admiral, rtables, and xportr is now a credible, accepted path.

NoteWhat is the pharmaverse?

The pharmaverse is a cross-industry collaboration of open-source R packages for clinical reporting — admiral (ADaM), sdtm.oak (SDTM), xportr (XPT export), rtables/tern (tables and figures), metacore/metatools (metadata), and more. Together they cover the whole CRF→submission pipeline in R.

Test your understanding

ImportantYour turn: place the artifact in the pipeline

For each artifact below, name the stage it belongs to (raw / SDTM / ADaM / TLF / submission) and say who typically owns it:

1. A DM domain with one standardized row per subject.
2. A Kaplan–Meier survival figure for the Clinical Study Report.
3. An ADSL dataset with a derived Safety Population flag (SAFFL).
4. A Define-XML file describing every dataset’s derivations.

TipHint

Walk the flow in order — collect, standardize, derive, produce, submit. “Standardized domain” and “derived flag” are different stages; a figure is an output; Define-XML travels with the final package.

TipSolution

1. SDTM — DM is a standardized tabulation domain; produced by clinical/statistical programmers.
2. TLF — a figure is a trial output, produced by statistical programmers from ADaM, against a biostatistician’s shell.
3. ADaM — a derived subject-level analysis variable; produced by statistical programmers per the Statistical Analysis Plan.
4. Submission — Define-XML is part of the package sent to the regulator, providing the traceability metadata.

NoteQuick check: which dataset do you run your statistical analysis on?

A. The raw EDC export, because it is closest to what was collected. B. SDTM, because it is already CDISC-standardized. C. ADaM, because it is the analysis-ready, derived dataset.

TipShow answer

C. You analyze ADaM. SDTM is standardized but tabulation — it has no derived variables, no baseline or change-from-baseline, and is structured one row per observation rather than per analysis unit. ADaM exists precisely to be analysis-ready while staying traceable back to SDTM.

References

The standards and tools in this lesson are defined by their primary sources:

• CDISC Foundational Standards — CDISC, the standards body, and its foundational suite.
• CDASH (data collection / CRF) — cdisc.org/standards/foundational/cdash.
• SDTM (Study Data Tabulation Model) — cdisc.org/standards/foundational/sdtm and the SDTM Implementation Guide (SDTM-IG).
• Controlled Terminology (NCI/EVS-maintained codelists) — cdisc.org/standards/terminology/controlled-terminology.
• ADaM (Analysis Data Model) — cdisc.org/standards/foundational/adam and the ADaM Implementation Guide (ADaM-IG).
• Define-XML (dataset metadata & traceability) — cdisc.org/standards/data-exchange/define-xml.
• eCTD submission & study-data standards (FDA) — FDA Study Data Standards Resources.
• ICH E9(R1) (estimands framework) — ICH Efficacy Guidelines.
• R-based submissions to the FDA — R Consortium Submissions Working Group.
• pharmaverse (open-source R toolkit) — pharmaverse.org and the admiral package.

Conclusion

A clinical trial’s data takes a five-stop journey: it is collected on the CRF/EDC, standardized into SDTM domains, derived into analysis-ready ADaM datasets, produced as TLF outputs, and submitted to a regulator — with traceability linking every step back to the last. CDISC sets the rules at each stage; the pharmaverse implements them in R; and the discipline that holds it together is the ability to walk any submission number back to the raw value behind it. Keep this map in mind and every later lesson — building an ADSL, deriving a time-to-event endpoint, rendering an AE table — is just a closer look at one stop on a route you already know.

Related lessons

• What is survival analysis? — the methods behind time-to-event endpoints (the ADTTE dataset and KM figures you will meet in the ADaM and TLF series). · Kaplan–Meier estimation — the survival curve that becomes a clinical-trial figure. · CDISC ADTTE for regulatory submission — how a time-to-event analysis is packaged for a submission, the bridge from biostatistics into this pillar.
• Where this fits: drug development & data flow (you are here) → SDTM programming → ADaM with admiral → TLF generation → validation, QC & submission — the concepts first, then the hands-on workflow they power.

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

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.