CDASH vs. SDTM vs. ADaM: The CDISC Standards, Demystified
CDASH, SDTM, and ADaM map to three stages of the data journey — collection, tabulation, and analysis. Here is how they connect, why the order is non-negotiable, and where the mapping burden actually hurts.
It is the week before database lock, and the mapping specs are still in flux. The SDTM datasets do not quite reconcile with the CRFs, ADaM derivations keep tripping over edge cases nobody documented, and every fix ripples into three more. You know the CDISC standards cold — that was never the problem. The problem is that the work of moving data cleanly from the case report form to the analysis dataset has quietly become the longest pole in your submission tent.
If you have ever watched biostatisticians and data managers throw CDASH, SDTM, and ADaM around in the same sentence, the key insight that cuts through the noise is simple: these three CDISC standards describe the same data at three different stages of its life. Collection, tabulation, analysis. Get the order right and most of the pain you feel at lock is designed away months earlier.
The standards stack, at a glance
Before the individual standards, it helps to see how CDISC layers fit together — collection at the bottom, the submission map at the top.
CDASH — how you collect
CDASH (Clinical Data Acquisition Standards Harmonization, current implementation guide CDASHIG v2.1) standardises data *collection*. It defines recommended fields, prompts, and structures for case report forms so the data you gather is already aligned with what comes downstream. Design your CRFs to CDASH and you are not fighting the data later — the variables you collect map cleanly toward SDTM instead of forcing painful reverse-engineering.
Think of CDASH as designing the intake form so everything you write down already has a defined home. The teams that skip this step pay for it twice: once in messy collection, and again when every field needs a bespoke mapping decision.
SDTM — how you tabulate for submission
SDTM (Study Data Tabulation Model, current SDTMIG v3.4) standardises how collected data is organised into *tabulation* datasets for regulatory submission. SDTM arranges observations into domains — DM (Demographics), AE (Adverse Events), LB (Laboratory), VS (Vital Signs), EX (Exposure), and many more — each with a defined structure and controlled terminology.
SDTM stays deliberately close to the raw, observed data. It is not analysis-ready; it is *submission-ready tabulation*. The FDA and PMDA require SDTM for standardised study data submissions. Crucially, SDTM is where most of the manual mapping effort lands: taking heterogeneous collected fields and forcing them into the right domain, variable, and controlled-terminology value.
ADaM — how you analyse
ADaM (Analysis Data Model) standardises the *analysis* datasets that directly support the statistical results in your tables, listings, and figures. ADaM datasets — the subject-level ADSL, Basic Data Structure (BDS) datasets like ADAE or ADLB, and Occurrence Data Structure (OCCDS) datasets — are built from SDTM and carry the derived variables, flags, and timing that analyses actually need.
The defining principle of ADaM is traceability: a reviewer must be able to trace any analysis result back through ADaM to SDTM to the collected data. Nothing in a table should be a black box. When ADaM is done well, a reviewer can follow a treatment-emergent flag from the summary table all the way to the observed adverse event.
The pipeline you cannot reorder
The flow is always CDASH to SDTM to ADaM to TLF (Tables, Listings, and Figures). Each stage feeds the next, and each carries traceability forward.
Skipping or reversing steps breaks the chain. Design CRFs without CDASH in mind and SDTM mapping becomes a slog of one-off decisions. Build analysis datasets that do not trace back cleanly to SDTM and reviewers cannot verify your results — which turns into information requests, delays, and re-work at exactly the moment you have no schedule left to absorb it.
Where it actually goes wrong
The failure modes are predictable, and almost all of them are upstream problems that only surface downstream:
- Non-CDASH CRFs that make every SDTM variable a negotiation instead of a mapping.
- Controlled terminology drift — collecting free text where a code list was expected, or referencing a different CT version than Define-XML declares.
- Broken traceability — ADaM derivations that cannot be followed back to an SDTM source, so a reviewer cannot reproduce a number.
- Spec-versus-data drift — the mapping specification says one thing and the actual dataset does another, discovered only at validation.
- Late validation — running conformance checks once, at the end, so systemic issues arrive as a wall of findings instead of a trickle.
Define-XML ties it together
Each of SDTM and ADaM ships with a Define-XML file (current version 2.1) — machine-readable metadata documenting every dataset, variable, controlled terminology reference, and derivation. Define-XML is the reviewer's guide to your data package and is itself a submission requirement. It is the map that makes the whole pipeline legible to someone who has never seen your study.
Where automation actually helps
Mapping collected data to SDTM and deriving ADaM has traditionally consumed enormous programming effort — and it is exactly the repetitive, pattern-heavy work that AI is well suited to accelerate. AI-assisted mapping can propose SDTM annotations directly from CRF design, draft first-pass SDTM and ADaM specifications, apply the correct controlled terminology version, and run CDISC conformance checks (Pinnacle 21 style) early and continuously rather than once at the end.
The point is not to remove the statistician. Every derivation, every mapping decision, and every conformance judgment stays under human control. The point is to compress the weeks of mechanical spec-writing and re-work so the expert time goes to the decisions that genuinely require judgment — and so lock week stops being a scramble.
The bottom line
CDASH is collection, SDTM is tabulation, ADaM is analysis, and Define-XML is the map. Respect the sequence, preserve traceability end to end, validate conformance continuously instead of at the finish line, and let automation carry the repetitive mapping load while you keep control of every derivation.