What is USDM?

What is USDM, in one paragraph?

USDM (Unified Study Definitions Model) is a CDISC data standard that represents the full design of a clinical trial — its objectives, population, arms, epochs, visits, schedule of activities, interventions, and estimands — as a single, structured, machine-readable model rather than free text buried in a protocol PDF. Instead of a study existing only as prose that humans re-key into a dozen downstream systems, USDM lets the study be written once as data and read many times by EDC builders, CTMS, registries, and analysis tools.

USDM is the flagship deliverable of CDISC's Digital Data Flow (DDF) initiative, developed jointly with TransCelerate. It is expressed formally as a UML class model, backed by CDISC Controlled Terminology, an API (JSON), a set of conformance (CORE) rules, and a detailed Implementation Guide.

The problem USDM was built to solve

Today, a clinical trial protocol is authored as a Word document. Every downstream system — the EDC, the CTMS, the randomization/IRT system, the SDTM programming team, the clinical trial registry submission — then has someone manually re-read that document and re-key the same facts: the same visit schedule, the same eligibility criteria, the same list of assessments. This is slow, expensive, and error-prone, and it means the "digital record" of a study's design doesn't really exist anywhere; it has to be reverse-engineered from prose every time.

USDM addresses this with a "write once, read many" philosophy: capture the study design as structured, computable USDM content one time, during design, and let every downstream system and document consume that same source. See Why was USDM created? for the fuller history.

The USDM backbone

Every USDM study follows the same skeleton. A Study has one or more StudyVersions (so amendments are just new versions). A version has one or more StudyDesigns (interventional or observational). A design contains everything that actually describes how the trial runs.

Reading the diagram left to right: the Study is the root container. The StudyVersion carries titles, identifiers, and amendment history. The StudyDesign is where the interesting content lives — arms, epochs, encounters, timelines, activities, and biomedical concepts all hang off it. This backbone is the single most important mental model to keep in mind whenever you're looking at a USDM UML diagram or a USDM JSON file: almost everything is reachable by walking down from Study.

What a USDM study actually contains

A useful concrete illustration is the Study Cell — the intersection of an arm and an epoch:

Each Study Cell is where an Arm meets an Epoch, and it points to one or more Study Elements describing the treatment strategy in force during that period. This is exactly the logic behind CDISC SDTM's Trial Arms (TA) and Trial Elements (TE) domains — USDM was deliberately aligned with that existing SDTM convention, so the same structure can drive automated SDTM Trial Design domain creation later. See USDM vs SDTM for the full comparison.

USDM as JSON

The USDM logical model is expressed as UML, but the thing you actually exchange between systems is JSON, produced according to the USDM API specification. The API rule of thumb: each instance appears exactly once (nested under its "natural parent"), and every other place that needs it links to it with an Id or Ids cross-reference attribute. A tiny excerpt looks like this:

{
  "id": "StudyEpoch_2",
  "instanceType": "StudyEpoch",
  "name": "Treatment",
  "type": { "code": "C101526", "decode": "Treatment" },
  "previousId": "StudyEpoch_1",
  "nextId": "StudyEpoch_3"
}

See USDM JSON Examples for a walkthrough of a complete, minimal study, and download a full worked example below.

Who actually uses USDM

• Sponsors & study designers — author the Schedule of Activities and protocol content once, digitally, instead of in a static document.
• EDC, CTMS and IRT vendors — consume USDM to auto-configure visit schedules, forms, and randomization structures.
• Regulators — USDM v4.0 was explicitly built in alignment with ICH M11 CeSHarP, the harmonised electronic protocol standard.
• Data standards teams — use USDM to auto-derive SDTM Trial Design domains (TA, TE, TV, TI) and inform registry submissions (ClinicalTrials.gov, CTIS).
• Tooling builders — anyone building a Study Definitions Repository (SDR), protocol authoring tool, or feasibility engine on top of the CDISC/TransCelerate reference architecture.

Where to go next

If you're new to USDM, a good learning path is: this page → Why was USDM created? → USDM Object Model → USDM Examples → USDM JSON Examples. If you already know CDISC standards, jump straight to USDM vs SDTM or USDM vs ODM to see how USDM fits alongside what you already use.

USDM in one sentence, for five different roles

Because USDM gets described differently depending on who's asking, it helps to see the same model paraphrased for each audience:

A minimal mental checklist for reading any USDM diagram or file

1. Find the backbone first. Locate Study, StudyVersion, and StudyDesign before anything else — everything else hangs off StudyDesign.
2. Separate "design" from "timeline." Arms/Epochs/Cells/Elements describe the high-level shape; ScheduleTimeline/ScheduledActivityInstance/Timing describe the actual visit-by-visit schedule.
3. Look for the word "reference." If an attribute is described as a relationship rather than a value, it's a pointer to another instance, not embedded content — in JSON this shows up as an Id/Ids suffix.
4. Check for controlled terminology. Attributes typed as Code or AliasCode must be populated from a specific CDISC (or SDTM, or DDF) codelist — free text is not allowed there.
5. Assume reuse is intentional. The same Study Element, Biomedical Concept, or eligibility criterion item appearing in multiple places is normal USDM design, not duplication to clean up.

What USDM deliberately does not do

It's just as useful to know USDM's boundaries as its scope. USDM does not: capture actual collected subject data (that's SDTM's job); define a live, callable REST API with granular per-field operations (the API is a bulk-transfer JSON exchange format); replace a sponsor's own protocol authoring tool (it's the underlying data layer such a tool could be built on); or specify execution/operational details like site-level logistics, drug supply chain, or monitoring visit schedules (it covers the planned design, not trial conduct). Keeping this boundary clear avoids a common early mistake: trying to force operational or post-hoc analysis content into a USDM study design when it belongs in SDTM, a CTMS, or an operational data store instead.

Frequently asked questions