USDM Object Model

USDM's ten model areas

USDM classes are commonly grouped into ten functional model areas. This is the fastest way to get oriented before diving into the full UML diagram:

These ten areas map fairly directly onto ICH M11 protocol sections too — which is by design. See USDM Implementation Guide Explained for that mapping.

The backbone, one more time, in depth

Walking the backbone with real attribute-level detail: Study.versions → one or more StudyVersion (each a distinct amendment/version). StudyVersion.studyDesigns → one or more StudyDesign (interventional or observational). From StudyDesign, everything fans out: arms, epochs, elements, studyCells, encounters, scheduleTimelines, activities, population, objectives, estimands, studyInterventions, eligibilityCriteria, and biospecimenRetentions.

Standard attributes every class shares

USDM enforces a consistent naming convention across the entire model:

Complex datatypes

Beyond plain strings and numbers, USDM defines a small set of reusable complex datatypes used throughout the model:

• Code — a code/decode pair plus the code system and its version. The universal way any controlled term (CDISC, SNOMED, LOINC, or other) is referenced.
• AliasCode — a standard code plus zero or more alias codes, for cross-linking multiple coding systems to the same concept.
• Quantity — a value plus an optional unit (itself an AliasCode).
• Range — a minValue and maxValue (both Quantity), with an isApproximate flag.
• QuantityRange — an abstract class inherited by either Quantity or Range.
• Duration — refers to a QuantityRange, with durationWillVary / reasonDurationWillVary flags.
• CommentAnnotation — a general-purpose note, optionally coded against a custom codelist.
• PersonName — aligned with the FHIR HumanName datatype (given names, family name, prefixes, suffixes).

The Biomedical Concept sub-model

One of the richest corners of the object model is the Biomedical Concept group, because it's the seam that connects USDM to CDISC 360i automation:

An Activity can point to any mix of a BiomedicalConceptCategory (a named grouping, e.g. "Vital Signs"), individual BiomedicalConcepts (e.g. "Systolic Blood Pressure," backed by a CDISC C-code), or a BiomedicalConceptSurrogate — a placeholder used when no standard BC definition exists yet, holding just a name, description, and optional reference URL. Each real BC decomposes further into BiomedicalConceptProperty instances (result, unit, body position, method …), each of which can be flagged required/enabled and constrained to specific ResponseCode values.

Abstract classes: the model areas rely on a small set of shared parents

A detail that clarifies a lot of otherwise-confusing repetition in the model: several USDM classes are abstract — they're never instantiated directly, but exist purely so multiple concrete classes can inherit a common set of attributes and relationships. Recognizing the abstract classes makes the ten model areas click into place faster:

Every time you see the same attribute name (criteria, plannedAge, text, dictionary) show up on multiple, seemingly unrelated classes, check whether they share one of these abstract parents before assuming it's a coincidence — it almost never is.

How the model areas map onto a real protocol's table of contents

Because USDM v4.0 was explicitly aligned to ICH M11's CeSHarP structure, the ten model areas roughly track the sections of a modern harmonised protocol:

• Study, Titles & Identifiers → the M11 title page and identifiers table.
• Amendments → the M11 Amendment Details / Overview of Changes sections.
• Study Design, Arms & Epochs and Detailed Study Logic/Timelines → M11 Section 4 (Trial Design) and the Schedule of Activities.
• Population & Eligibility Criteria → M11 Section 5 (Trial Population).
• Objectives/Endpoints/Estimands → M11 Section 3 (Trial Objectives and Associated Estimands).
• Interventions → M11 Section 6 (Trial Intervention and Concomitant Therapy).
• Procedures/Biomedical Concepts → M11 Section 8 (Trial Assessments and Procedures).

This alignment is exactly why a well-formed USDM study design can, in principle, generate large parts of an M11-conformant protocol document automatically — see USDM Implementation Guide Explained for the document-generation mechanics.

Quick reference: which class do I need?

How class count has grown across versions

USDM's object model has grown additively rather than being rewritten between versions. The most visible recent growth was the v4.0 IDMP-aligned intervention expansion (AdministrableProduct, Ingredient, Substance, Strength, MedicalDevice, and related identifier/property classes) — see USDM Version 4.0 Explained for the full list. Earlier growth included the estimand-related classes (Estimand, IntercurrentEvent, AnalysisPopulation) added to align with ICH E9(R1), and the syntax template mechanism added to support reusable, tagged eligibility and objective text. Knowing this growth pattern is useful when reading older training material or example files: a v1.0-era example simply won't contain classes introduced in v3.0 or v4.0, which is not an error in the example, just a version-scope difference.

Frequently asked questions