USDM vs SDTM

The core difference: planned design vs. collected data

The simplest way to separate USDM from SDTM is when each one applies in a study's lifecycle:

USDM is a design-time model. It exists before a single subject is enrolled, and it describes what the study is supposed to do: which arms exist, what happens in each epoch, what gets measured at each visit, and what the estimand of interest is. SDTM (Study Data Tabulation Model) is a submission-time model. It exists after data collection, and it describes the tabulated, tabular datasets (DM, AE, VS, LB, and so on) that get submitted to a regulator.

They overlap in exactly one place on purpose: SDTM's Trial Design Model domains (TA, TE, TV, TI, TS) describe the planned design retrospectively, in the same conceptual terms USDM uses prospectively. That overlap is intentional — USDM was built to align with the existing SDTM Trial Design conventions specifically so that those domains could be automated.

USDM → SDTM Trial Design mapping

CDISC publishes a maintained sdtm_mapping.xlsx spreadsheet in the DDF-RA GitHub repository (Documents/Mappings) with the exact field-level mapping, and CDISC's training materials show working examples of USDM-to-TV mappings expressed as JSONata queries executed directly against USDM API JSON.

Why you still need both standards

USDM cannot replace SDTM because they answer different questions and are governed by different parts of a submission:

• USDM answers: "What was the plan?" — arms, epochs, visits, assessments, estimands, as designed.
• SDTM answers: "What actually happened, tabulated for review?" — subject-level, collected, submitted data (demographics, adverse events, labs, vitals).
• SDTM's Trial Design domains are the one exception — they restate the plan (USDM's job) in SDTM's submission format, which is exactly the seam USDM is built to auto-populate.

In practice, mature CDISC 360-style pipelines treat USDM as the upstream source of truth for study design metadata, and treat SDTM (including Trial Design domains) as a downstream, derived artifact — generated, not hand-built, wherever the USDM content is rich enough to support it. See CDISC 360 Explained and USDM Use Cases for how this plays out in real pipelines.

Worked example: one Study Cell, two standards

Consider a two-arm, three-epoch trial. In USDM, this is six StudyCell instances (2 arms × 3 epochs), each pointing to one or more StudyElements:

{
  "id": "StudyCell_2",
  "instanceType": "StudyCell",
  "armId": "StudyArm_1",
  "epochId": "StudyEpoch_2",
  "elementIds": ["StudyElement_2"]
}

The equivalent SDTM TA domain record (conceptually) restates the same fact in tabular form: ARMCD=A, TAETORD=2, ETCD=DRUGX, EPOCH=TREATMENT. Because both sides describe the identical design fact, a deterministic transform — not a human re-reading a protocol — can produce one from the other.

Terminology reuse: how much CT do USDM and SDTM actually share?

Because USDM and SDTM come from the same organization, they deliberately reuse controlled terminology wherever the underlying concept is identical, rather than maintaining two parallel codelists for the same thing. Concrete examples pulled directly from the USDM controlled terminology spreadsheet:

Only where SDTM's existing terminology genuinely doesn't cover a USDM-specific concept (for example, StudyAmendmentReason or GovernanceDate.type) does USDM introduce its own DDF-specific codelist. This is a deliberate governance choice: CDISC and ICH jointly maintain the controlled terminology behind both standards specifically to keep this kind of reuse consistent and avoid semantic drift between them over time.

A common point of confusion: "Epoch" means slightly different things

Both standards use the word "Epoch," and the concepts are closely related but not byte-for-byte identical in scope. In USDM, StudyEpoch is a first-class design object with its own id, ordering (previous/next), and transition rules, referenced from StudyCell and from every ScheduledActivityInstance/Encounter in the timeline. In SDTM, EPOCH is usually a variable value stamped onto observation records (in domains like VS or AE) to indicate which period an observation falls into — it's a classification tag on collected data, not a standalone design object. USDM's StudyEpoch is the upstream source of truth that the downstream SDTM EPOCH variable value should ultimately be populated from.

Frequently confused terms, clarified

The pattern is consistent throughout: USDM's classes are the design-time objects; SDTM's variables are flattened, tabulated restatements of those same design facts, stamped onto collected data records after the fact.

Practical guidance: building a USDM-to-SDTM pipeline

If you're implementing this mapping yourself rather than using CDISC's published sdtm_mapping.xlsx, the practical build order that avoids rework is: (1) validate the USDM StudyDesign against the CORE rules first, since a structurally invalid design will produce a structurally invalid TA/TE/TV/TI output; (2) generate TE from StudyElement plus its transition rules; (3) generate TA from StudyCell, walking the epoch order via previous/next; (4) generate TV from Encounter, again walking its own ordering chain; (5) generate TI last, since EligibilityCriterion.identifier and category map almost directly to IETESTCD/IECAT with minimal transformation logic required.

A note on versioning and amendments

One more practical difference worth knowing: USDM treats a protocol amendment as a new StudyVersion of the same Study, with full amendment metadata (StudyAmendment, reasons, impacts, prior-amendment history) built directly into the model. SDTM has no equivalent concept — a submission simply contains the final, as-conducted dataset, with protocol deviations captured separately (typically in a Trial Summary parameter or a dedicated deviations dataset). This is another reason USDM can't be replaced by SDTM: SDTM was never designed to carry a design's version history, only its final collected state.

Frequently asked questions