--- title: "What CDISC USDM is, and why the protocol is becoming data" description: "Trelice is an ICH M11-native platform for sponsors, CROs, and research sites to author clinical trial protocols and generate aligned downstream documents." canonical_url: "https://www.trelice.com/resources/what-is-cdisc-usdm" --- Regulatory October 8, 2026 · 7 min read # What CDISC USDM is, and why the protocol is becoming data The Unified Study Definitions Model explained for protocol teams: what it contains, how it relates to ICH M11, and what it changes about authoring. For most of the history of clinical research, the protocol has been a document. It is written in Word, approved as a PDF, and then read by dozens of people who each transcribe the part they need into the system they run: the EDC build team re-keys the schedule of assessments, the CRO rebuilds the visit structure in the CTMS, the statistical programmers re-express the design as trial design datasets, and the site coordinator rewrites the eligibility criteria into a screening checklist. Every one of those transcriptions is a chance for the study that runs to differ from the study that was written. USDM, the Unified Study Definitions Model, is the industry’s answer to that problem. It is a CDISC standard, developed through TransCelerate BioPharma’s Digital Data Flow initiative, that defines a clinical study as machine-readable data. A USDM study definition holds the study design with its arms, epochs, and elements; the schedule timelines with their encounters and activities; the eligibility criteria; the objectives and endpoints; the interventions; the controlled terminology and biomedical concepts; and the narrative content of the protocol mapped to its sections. It ships with an implementation guide, conformance rules, and an API specification, so two systems can exchange a study definition and agree on what it means. The model has matured quickly. The first version appeared in 2022. Version 3.0, released in April 2024, aligned USDM with the ICH M11 protocol template, and version 4.0, released in June 2025, extended that alignment to cover the breadth of M11. In 2026 CDISC published an implementation handbook on constructing SDTM trial design domains directly from USDM metadata, which is the first concrete, submission-facing payoff: the trial design the regulator receives is derived from the protocol’s data rather than reconstructed from its prose. USDM and ICH M11 are easy to confuse, and the distinction matters. M11 is a harmonised template and technical specification for the protocol document: which sections exist, in what order, with which headings and vocabulary. USDM is the data model that carries that content together with the design detail the document describes. The M11 data elements are a subset of USDM, which is why the two are described as aligned. A protocol can follow M11 without being USDM data, in the way a Word file can follow a template. It cannot be a USDM study definition unless its structure exists as data in the first place. That last point is the one that decides whether a tool can support USDM at all. If the authoring system holds the protocol as text under headings, USDM is an extraction project: someone, or some model, has to read the prose and guess at the arms, the visits, and the criteria. If the authoring system holds the protocol as structured fields from the start, USDM is an export. The schedule of assessments is already a matrix of visits and activities with timing and windows. The eligibility criteria are already a numbered list with categories. The endpoints are already linked to the objectives they serve. Producing the study definition is a matter of mapping, not interpretation. Trelice took the second path from the beginning, which is why it supports USDM without a separate workflow. Writers author in structured forms with the regulatory context beside each field, reviewers approve through a controlled workflow, and the approved protocol is produced as a USDM study definition versioned with the protocol itself. When an amendment changes a visit or a criterion, the change is recorded per field with a reason, a new frozen version is cut, and the study definition follows it, so an EDC team or a CRO can always tell which version they are reading. We are also going further than the standard currently does. USDM describes the study. It does not yet describe the documents every study derives from its protocol: the consent forms, the visit worksheets, the screening forms, the ethics committee questionnaires, the schematics, the budgets, the redacted versions. Trelice generates all of those from the protocol’s structured data today, and we are defining USDM-based structured definitions for each of them, so that a consent form’s procedures or a worksheet’s checklist is expressed as a view over the study definition. The expectation is the same one behind USDM itself: the protocol stopped being a document first, and the documents that depend on it will follow. If you own protocols, study build, or data standards, the practical question is not whether USDM will matter but when your organization will hold its protocols as data. The sooner the protocol is structured, the less there is to transcribe, and the smaller the gap between the study that was written and the study that runs. The full picture of how Trelice supports USDM, with the mapping from protocol structure to the model, is at trelice.com/usdm. * * * By Ilan Slonim [← All resources](/resources)