CDISC DDF Explained

What is Digital Data Flow (DDF)?

Digital Data Flow (DDF) is the industry initiative, led by TransCelerate Biopharma in collaboration with CDISC, to replace document-based clinical trial protocols with a digital, "write once, read many" data flow. Its ambition, in TransCelerate's own framing, is: a Unified Study Definitions Model (USDM), an API specification, and CDISC Controlled Terminology feeding a Study Definitions Repository (SDR) and reference implementation — which then drives automation back into the study team's own design and protocol-authoring workflow.

In short: USDM is the model; DDF is the program that built it (plus the surrounding API, terminology, guide, rules, and reference tooling needed to make it real).

Who runs DDF

DDF has a clean division of labor between its two parent organizations:

Both organizations publish on GitHub: CDISC's model-level deliverables live at github.com/cdisc-org/DDF-RA, and TransCelerate's adoption and tooling resources live at github.com/transcelerate/ddf-home and github.com/transcelerate/ddf-sdr-platform.

The four DDF phases

Each phase's output is still in active use today — nothing has been deprecated, so the model, CT, API, IG and CORE rules from Phases 1–3 remain the authoritative, versioned reference for anyone implementing USDM v4.0.

What DDF actually produces, concretely

The Study Definitions Repository (SDR)

The SDR is TransCelerate's reference implementation of the DDF architecture — a system built to demonstrate that USDM-conformant study definitions can actually be stored, versioned, queried, and served, not just described on paper. It's the practical proof that "write once, read many" works end to end: a study is authored once into the SDR, and different consumers (EDC build tools, dashboards, registries) pull from the same source of truth rather than re-deriving it.

Alongside the SDR, Phase 4 delivered persona toolkits aimed at three concrete adoption audiences — medical writers, data managers, and IT teams — recognizing that DDF adoption succeeds or fails based on whether it fits into each of those groups' existing workflows, not just whether the model is technically correct.

DDF governance: how decisions actually get made

DDF is not a single committee — it operates as a set of coordinated volunteer teams, consistent with how CDISC runs all of its standards work. Model and terminology changes go through the same kind of public-review process CDISC uses for SDTM and other standards: draft content is published, the industry comments, and a consensus-based revision cycle produces the next versioned release. This is why USDM has moved through four major versions (see USDM Version 4.0 Explained) rather than being declared "finished" once — the governance model assumes ongoing, incremental refinement based on real implementation feedback, the same way ICH M11 itself went through multiple public consultation rounds before final adoption.

DDF vs. a typical internal "digital protocol" project

Many sponsor organizations ran their own internal digital-protocol pilots before or alongside DDF. The key difference DDF brings that a purely internal effort can't: a shared, cross-industry model with published controlled terminology and conformance rules that every vendor, CRO, and regulator can build against without bespoke integration work per sponsor. An internal-only model solves one company's re-keying problem; DDF's ambition is to solve the re-keying problem between companies, vendors, and regulators, which only works if everyone is targeting the same published standard.

How to actually get started with DDF/USDM today

1. Read the model, not just the marketing. Work through the USDM Object Model and UML Tutorial pages on this site, or the official USDM-IG, before evaluating any vendor tool.
2. Get the reference files. Pull the UML PNG, USDM_CT.xlsx, and USDM_CORE_Rules.xlsx from CDISC's DDF-RA GitHub repository so you have the authoritative, versioned source of truth on hand.
3. Try a small, real example. Model one actual study's Schedule of Activities in USDM JSON by hand before evaluating automated tooling — it's the fastest way to internalize where the model's flexibility helps and where it constrains you.
4. Check CORE conformance early. Validate your first attempt against the CORE rules rather than waiting until a tool integration depends on it being correct.
5. Look at TransCelerate's adoption stories. The ddf-home GitHub repository's stories directory has real, shared lessons from organizations further along in adoption — see USDM Use Cases for a summary.

Quick reference: DDF acronyms and terms

DDF's relationship to regional regulators

DDF itself is an industry-led initiative, not a regulatory mandate — no health authority currently requires a USDM submission. Its regulatory relevance comes indirectly, through ICH M11: because ICH M11 is a genuine regulatory guideline (adopted by ICH's Regulatory Members, including the EMA, FDA, and PMDA-aligned bodies), and USDM is explicitly aligned with M11's CeSHarP template, USDM adoption is best understood as preparing an organization for M11-era protocol submission workflows rather than meeting a distinct DDF-specific regulatory requirement. This is an important distinction when building an internal business case for DDF adoption: the near-term value is operational efficiency (less re-keying, more automation); the medium-term value is being ready for a regulatory landscape that increasingly expects structured, harmonised protocol data.

Frequently asked questions