USDM Use Cases

1. Automated SDTM Trial Design domain creation

Because USDM's StudyArm/StudyEpoch/StudyElement/StudyCell/Encounter/EligibilityCriterion classes were deliberately aligned with SDTM's Trial Design domains, a documented use case runs the transformation as code: USDM-to-SDTM mappings are expressed as JSONata queries, extracted from mapping files by a small Python program, and executed directly against a USDM API JSON file to produce TA/TE/TV/TI output — no manual re-keying required. See USDM vs SDTM for the underlying field-level mapping.

2. Patient journey visualization

Because Arm, Epoch, Encounter, and ScheduledInstance combinations — along with their Timing relationships — are all fully explicit in a USDM study design, a visualization tool can walk that structure directly to render a patient's expected visit-by-visit journey for any given arm, with zero manual diagramming. This extends naturally to conditional logic: when a ScheduledDecisionInstance and its ConditionAssignment route around a visit (e.g. "no mutation X → skip Visit 8"), the generated patient journey for that subgroup automatically excludes the skipped visit, and the ISO 8601 timing values let the tool compute exact elapsed time between any two visits on the diagram.

3. EDC set-up automation

The richer the Biomedical Concept detail attached to an Activity, the more of the EDC build becomes derivable rather than manual:

• Repeated measures (triplicate ECGs, supine/standing blood pressure) map directly to sub-timeline structures, informing exactly how many entry fields and timing captures an EDC form needs.
• Required vs. optional BC properties (isRequired / isEnabled) drive which fields are mandatory on a form and which are hidden entirely for a given study.
• Enabled response codes on a BC property constrain a form's pick-list to exactly the values the protocol allows, rather than the full CDISC codelist.
• BC-to-CRF specialization mappings (CDASH, SDTM, ODM) let the same standardized concept drive form generation across multiple target systems from one definition.

4. Feasibility, cost, and patient-burden assessment

Once a Schedule of Activities is digitized, several assessment tasks that used to require manual protocol review become computable:

5. Lab specification alignment

A commonly cited pain point: protocol text describing lab assessments is often not specific enough, so labs and sponsors spend significant time aligning on test/specimen/method/units through side agreements, and the same assessment ends up described inconsistently within and between studies. USDM's Biomedical Concept model addresses this directly — a AliasCode on a BC lets a study-standard test description link automatically to LOINC codes or country-specific lab codes, so the "company standard" is attached the moment a standard test is chosen at design time, with study-specific overrides only where genuinely necessary.

6. Adoption patterns from the field

TransCelerate-shared industry adoption stories converge on a few consistent lessons:

• Most common starting use cases: building a study design repository, Schedule-of-Activities digitization tooling, feasibility assessments, and monitoring.
• Change management, not technology, is the larger barrier. The data model itself is rarely the blocker — getting medical writers, data managers, and IT to change how they work is.
• Incremental adoption beats a big-bang rollout. An "add-on" approach — layering USDM onto existing processes gradually while keeping the end state in mind — consistently outperforms trying to replace everything at once.
• Small, visible wins build momentum. Taking concrete, demonstrable progress to leadership at each step is what sustains investment in further phases of adoption.

7. Registry submission support (ClinicalTrials.gov and CTIS)

A well-formed USDM study design covers a substantial share of the fields required for public registry submission. Per the USDM Implementation Guide's own mapping table, USDM directly supports Study Identification, Sponsor/Collaborators, Study Design, Arms/Groups/Interventions, Outcome Measures, and (for interventional designs) Eligibility. It does not cover Study Status, Oversight, Conditions/Keywords, or IPD Sharing Statements — these depend on information that doesn't exist yet at the design stage (like actual enrollment status) or falls outside USDM's design-only scope entirely. A registry-submission use case therefore treats USDM as a strong partial source, not a complete one, and still needs a manual or separately-sourced completion step for the remaining fields.

8. Protocol document generation (ICH M11)

Perhaps the most strategically important use case: generating a full ICH M11 CeSHarP-conformant protocol document directly from a USDM study design. This relies on the NarrativeContent/NarrativeContentItem classes to carry document structure (section numbers, titles, ordering) and on XHTML referencing to pull live values from structured USDM content (objectives, eligibility criteria, intervention details) directly into the rendered protocol text. Because the reference stays live rather than being copy-pasted, a change to the underlying structured data (say, a corrected eligibility age range) automatically updates every place in the document that referenced it — eliminating an entire category of amendment error where a value gets updated in one place in a protocol but missed in another.

9. Study design repositories and reuse libraries

Once a sponsor has authored even a handful of studies in USDM, the model's reuse-friendly structure (Study Elements, Biomedical Concepts, eligibility criterion text, syntax templates) makes it practical to build an internal library of standard, pre-vetted design components — a standard "Screening" element, a standard vital signs BC category, a standard set of contraception-requirement eligibility text. New studies then compose from that library rather than starting from a blank page, which is exactly the "study design repository" use case TransCelerate's adoption stories report as one of the most common starting points in practice.

Putting it together: a realistic first 90 days

For an organization starting from zero, the use cases above suggest a realistic adoption sequence: weeks 1–4, model one real, already-completed study in USDM by hand to build internal familiarity; weeks 5–8, validate it against the CORE rules and attempt one automated derivation (most teams start with SDTM Trial Design domains, since the mapping is the most mature); weeks 9–12, expand to a second, in-flight study and begin building the internal reuse library described above. This mirrors the "incremental, not big-bang" lesson reported consistently across real DDF adoption stories.

Frequently asked questions