Why SDTM Alone Is No Longer the Finish Line

SDTM has served the industry well. As the CDISC foundational standard for organizing and formatting clinical trial data for regulatory submission, it created a common language that reviewers and sponsors could both understand. The Analysis Data Model (ADaM), built on top of SDTM, extended that language to statistical analysis, delivering “analysis-ready” datasets that support tables, figures, and listings with traceable derivations.1 Together, SDTM and ADaM became the operational floor of nearly every regulatory submission in the United States, Japan, and increasingly elsewhere.

But the floor has become the ceiling. SDTM was designed for submission, which means it captures data after the trial has run. It does not describe the protocol. It does not describe the schedule of assessments. It does not describe the endpoints or the analysis plan in a way that a machine can interpret. Everything upstream of SDTM, protocol design, database build, edit checks, data collection, still happens in a fragmented, largely manual world. Sponsors write protocols in Word. Vendors build EDCs from those Word documents. Programmers write SAS code to map raw EDC output back into SDTM. Each handoff is a translation, and each translation is a place where information is lost.

The result is a system that produces good submission-ready data at enormous cost. Standards work often accounts for a substantial share of clinical data management effort, and the redundancy is visible to anyone who has watched the same variable get re-specified in a study builder, an EDC, a mapping specification, and an ADaM programming plan.2 CDISC’s own 360i initiative, launched in March 2025, was explicitly designed to break this pattern by extending standards upstream from submission all the way back to study design.3

The strategic reframe. SDTM is no longer the endpoint of clinical data standardization. It is a waypoint in a lifecycle that starts with digital protocol authoring and extends downstream into real-world evidence, post-market surveillance, and patient-generated data. Sponsors who plan only to the SDTM boundary are planning for yesterday’s problems.

30-40% Estimated reduction in study startup time from full Digital Data Flow adoption4
80+ Industry contributors currently working the CDISC 360i program across design, build, and run streams3
April 2026 Public review comment deadline for SDTM v3.0 and SDTMIG v4.0, the largest SDTM update in nearly a decade5

The Emerging Standards Landscape

To make good investment decisions, leaders first need a mental map of what is actually in play. Beyond SDTM and ADaM, the standards landscape in 2026 includes several overlapping, sometimes competing, initiatives. Each solves a specific problem, and each is at a different level of maturity.

The upstream initiatives

CDISC 360i. An evolution of the earlier CDISC 360 program, 360i is a multi-year initiative to enable end-to-end automation from protocol design through study results by adding the semantic layer that standards like SDTM lack. It is designed to allow biomedical concepts to flow through the study lifecycle without repeated re-specification, and it is the umbrella under which most other CDISC modernization work now sits.3

USDM (Unified Study Definitions Model). Developed by CDISC in partnership with TransCelerate’s Digital Data Flow initiative, USDM is a machine-readable model for the study definition itself, essentially the protocol as structured data rather than a Word document. USDM v3.0 was released in April 2024 and v4.0 in June 2025, with a REST API, OpenAPI 3.0 specification, and machine-executable conformance rules.6

ICH M11. The Clinical electronic Structured Harmonised Protocol, or CeSHarP, is the regulatory counterpart to USDM. Where USDM defines a data model, M11 defines a harmonized protocol template plus a technical specification for structured protocol content acceptable to FDA, EMA, PMDA, and other ICH regions. FDA released a draft technical specification and template in June 2025, and ICH published the finalized Step 4 guideline in November 2025.7

The interoperability layers

FHIR R5 clinical trial extensions. HL7’s FHIR standard, best known for EHR interoperability, is being extended into clinical research through the Vulcan FHIR Accelerator. Vulcan’s Utilizing the Digital Protocol (UDP) implementation guide connects ICH M11, CDISC, and TransCelerate work into a shared FHIR-based exchange model. The current UDP builds on FHIR R6, but existing R5-based Vulcan schedule and CDISC ODM integration guides remain relevant for teams standardizing today.8

OMOP CDM. The Observational Medical Outcomes Partnership Common Data Model, maintained by the OHDSI community, is the dominant standard for real-world data. It supports federated analysis across hospital networks and research databases, and it is becoming the connective tissue for hybrid trials that use real-world data alongside prospective clinical data.9

The submission layer

Dataset-JSON. The FDA published a Request for Comments in April 2025 exploring CDISC Dataset-JSON v1.1 as a modern replacement for the aging SAS XPORT (XPT) format. In fall 2025, the R Consortium’s Submissions Working Group successfully submitted ADaM datasets in Dataset-JSON to the FDA, demonstrating that open-source tools can meet regulatory acceptance.10

SDTM v3.0 and SDTMIG v4.0. The most significant SDTM update in nearly a decade is currently in public review through April 2026. It eliminates SUPPQUAL datasets in favor of Non-Standard Variables, adds Multiple Subject Instances support, and introduces new domains including Event Adjudication and Gastrointestinal Findings.5

USDM, ICH M11, and the Digital Protocol

The single most important shift in clinical standards is happening upstream, at the protocol. For years, the protocol has been a document, a PDF that humans read and manually translate into every downstream system. USDM and ICH M11 are, together, ending that pattern.

USDM is the data model. It defines how study elements (objectives, endpoints, populations, interventions, schedule of assessments, epochs, and arms) are structured so a machine can consume them. ICH M11 is the regulatory template and technical specification that makes the same content acceptable across FDA, EMA, PMDA, Health Canada, and other ICH regions. They are designed to align: an M11-structured protocol can be represented in USDM, and a USDM-based Study Definition Repository can produce M11-compliant content.11

The practical consequence, once implemented, is that a single, versioned, structured protocol becomes the source of truth for study design, EDC build, IRT randomization, statistical analysis plans, and clinical study reports. TransCelerate’s DDF initiative estimates this can reduce startup time by 30-40 percent by removing redundant manual system builds and eliminating the “translation loss” between systems.4

The SD perspective. USDM and M11 are not just process improvements. They are architectural bets. Adopting them well means rethinking how protocol authors, biostatisticians, data managers, and vendors collaborate. Adopting them badly, treating them as another export format, produces the same fragmented workflow with more layers on top. This is a change program, not a tooling upgrade.

FHIR R5 and OMOP: Bridging Trials and Real-World Data

The other major shift is horizontal, not vertical. Trials no longer sit in a vacuum. External control arms, hybrid designs, post-approval evidence generation, and pragmatic trials all require clinical data to move fluidly between prospective study data and real-world data captured in electronic health records, claims, and registries. Two standards, FHIR and OMOP, are the connective tissue.

FHIR in clinical research

FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard that has, over the past decade, become the default modern language of healthcare interoperability. Its clinical research extensions, developed through the Vulcan FHIR Accelerator, are what allow trial data to move between EHR-based site systems and sponsor-side clinical data platforms. The Vulcan UDP implementation guide integrates CDISC standards, ICH M11, and TransCelerate protocol content into a shared FHIR representation.8

The immediate use cases are practical. EHR-to-EDC pre-population reduces double data entry at investigator sites. FHIR-based device data ingestion supports wearables and remote monitoring. And FHIR bridges are the mechanism by which the emerging European Health Data Space (EHDS) will connect to trial and post-market safety systems.12

OMOP for real-world evidence

Where FHIR handles the point-to-point interoperability, OMOP handles the population-level analytics. Maintained by the OHDSI community, the OMOP Common Data Model is used by hospital networks, registries, and pharma sponsors to standardize observational data for federated analysis. This is the standard that lets a sponsor run the same cohort definition across data from ten hospital systems without transferring patient-level data, a critical property for privacy compliance under GDPR and HIPAA.13

Adoption is broad and growing. In 2025, OMOP’s role in cancer research expanded through initiatives like Kineret in Israel and pan-European federated networks; IQVIA has published cardiometabolic RWE case studies using OMOP as the backbone.14 For sponsors building RWE strategies, OMOP is now less a “should we consider” and more a “which vendors and networks do we align with.”

The RWE regulatory reality. FDA inspections of submissions including real-world data have flagged data missingness, misalignment of visit cadences, and inadequate documentation of data provenance as recurring failure modes. Standards adoption does not solve these on its own; sponsors still need governed data quality processes and clear traceability from raw EHR data through the analytic dataset.15

Therapeutic Area Standards and the CFAST Model

Even a fully modernized SDTM will not cover every disease area meaningfully. That gap is what the Coalition For Accelerating Standards and Therapies (CFAST) was created to fill. A joint initiative of CDISC and the Critical Path Institute (C-Path), with participation from FDA, NCI Enterprise Vocabulary Services, TransCelerate, and PMDA, CFAST develops disease-specific extensions to CDISC foundational standards.16

Final therapeutic area user guides have been published for a broad range of conditions including Alzheimer’s disease, asthma, multiple sclerosis, polycystic kidney disease, Parkinson’s disease, virology, pain, tuberculosis, HIV, colorectal cancer, influenza, and QT studies. Each guide defines domain-specific data structures, controlled terminology, and metadata that a general SDTM implementation cannot capture cleanly.16

PhUSE (the Pharmaceutical Users Software Exchange), meanwhile, provides the practitioner-driven counterpart. Its working groups produce the open-source tooling, best practices, and reference implementations that translate CDISC standards into working code. For sponsors building a data standards capability, participation in PhUSE working groups is one of the cheapest ways to stay current with practitioner-level implementation detail.

When to invest in a therapeutic area standard

Not every program justifies deep therapeutic area standards investment. The decision hinges on three questions:

  • Portfolio concentration. If a substantial share of your pipeline is in a single therapeutic area, the return on internalizing that TA standard is high. If you have one asset in that area, external partners can often carry the standards work.
  • Endpoint complexity. Disease areas with heavily specialized endpoints (oncology response criteria, MS disability scoring, Alzheimer’s cognitive scales) get the most benefit from a TA user guide, because the alternative is a large volume of custom SDTM extensions.
  • Data reuse expectations. If you plan to pool trials for meta-analysis, external control arms, or platform trials, TA standardization pays for itself in the pooling step. If each trial is analyzed in isolation, the benefit is smaller.

The Real Gaps: Where Standards Still Break Down

It is tempting to describe the emerging standards landscape as a clean, converging ecosystem. In practice, four persistent gaps still create real work for sponsors, and no current standard fully solves them.

Gap 1: Derived variables

ADaM’s Basic Data Structure (BDS) and Occurrence Data Structure (OCCDS) provide guidance on how to represent derived analysis variables, but the derivation logic itself is still expressed in prose (in the SAP) and then re-implemented in code. This is a well-known source of quality risk, and it becomes acute for complex derivations like time-to-event with competing risks, adjudicated events, or composite endpoints.1 USDM and 360i are moving toward machine-readable analysis specifications, but derived-variable executability is still an emerging capability, not a solved problem.

Gap 2: Non-standard endpoints

Real trials use real endpoints, many of which are not covered by any published SDTM domain, ADaM structure, or therapeutic area guide. Novel biomarkers, digital endpoints from wearables, patient-reported outcomes with custom scoring, and adaptive endpoints all require custom variable structures. The current SDTM approach handles these through SUPPQUAL datasets, which the upcoming v4.0 replaces with Non-Standard Variables (NSVs), a genuine improvement but still a “here be dragons” territory that requires careful governance.5

Gap 3: Protocol-to-database traceability

This is the gap USDM and M11 are actually attacking. In today’s world, tracing a value in an ADaM dataset back to the protocol requirement it satisfies is a manual archaeology exercise across specification documents, mapping documents, and code. The USDM/M11 promise is bidirectional traceability by construction. The reality, until the tooling matures, is that traceability remains a heavy manual investment for most sponsors.

Gap 4: ePRO and wearable integration

Wearables and ePRO systems produce high-frequency, heterogeneous data that does not fit cleanly into any single standard. Devices use different sampling rates, algorithms, and formats; consumer wearables may not meet clinical validation thresholds; and even FHIR-based ingestion pipelines still require substantial harmonization before data lands in an analytic dataset.17 Standards work is underway in this space, but sponsors currently need to treat every wearable and ePRO integration as an engineering project, not a plug-in.

The pragmatic takeaway. Do not budget or plan as though these gaps will close on their own in the next 18 months. They will narrow, but the operational work of custom domains, custom derivations, and device-specific pipelines is not going away in this planning cycle. Build the capability, do not wait for the standard.

A Standards Adoption Matrix for 2026 Portfolios

For portfolio-level planning, sponsors need a shared view of which standards are ready for production, which are ready for pilots, and which are still emerging. The matrix below represents our view of the state of play as of mid-2026.

Standard Primary Use Maturity Regulatory Weight 2026 Recommendation
SDTM (current) / ADaM Submission tabulation, analysis-ready data Production Required (FDA, PMDA) Continue as backbone; prepare for v3.0/v4.0
SDTM v3.0 / SDTMIG v4.0 Next-generation submission tabulation Public review (finalization pending) Expected required within 2-3 years Comment on public review; plan migration timeline
CDASH / CDASHIG v2.1 Data collection at source (EDC) Production Recommended (not required) Standard EDC configuration; align with SDTM v4.0
USDM v4.0 Machine-readable study definitions Early production / pilot Enabling, not required Pilot in 1-2 studies; build vendor requirements
ICH M11 CeSHarP Harmonized structured protocol Step 4 finalized (2025); regional adoption emerging Expected required (ICH regions, phased) Adopt template now; plan technical spec integration
Dataset-JSON Modern submission transport format Production-validated (R Consortium, 2025) Under active FDA evaluation Pilot alongside XPT; monitor FDA guidance
FHIR R5 (Vulcan) EHR-to-trial interoperability, device data Production for select use cases Enabling, EHDS-relevant Adopt for EHR pre-population, wearable ingestion
OMOP CDM Real-world evidence, federated analytics Production (broad network) Accepted for RWE submissions with governance Standard for RWE strategy; align with data partners
CFAST TA standards Disease-specific extensions Varies by TA (production to draft) Recommended per program Adopt for concentrated TAs; participate in CFAST
CDISC 360i biomedical concepts Semantic layer, end-to-end automation In development Enabling, forward-looking Track roadmap; participate through CDISC

Investment Prioritization Framework

The matrix answers “what exists.” The harder question is “where should we spend.” For CFOs, Chief Data Officers, and Heads of Clinical Data Management deciding how much of the next planning cycle to allocate to emerging standards, we recommend a four-lens framework.

LENS 1

Regulatory Compulsion

Any standard that is required, or will imminently be required, by a regulator you file with must be funded. This is not optional and it sets the floor. SDTM/ADaM, and soon the v3.0/v4.0 migration, live here.

LENS 2

Cost of Non-Adoption

Some standards are not required but are so widely used by partners, CROs, EHR networks, RWE vendors, that not adopting them creates friction cost on every trial. FHIR and OMOP typically sit here for pharma sponsors with any RWE ambition.

LENS 3

Portfolio Fit

Therapeutic area standards, novel endpoint frameworks, and specialized submission formats should be evaluated against your pipeline concentration and time horizon. Investment scales with reuse.

LENS 4

Architectural Optionality

USDM, ICH M11, and Dataset-JSON are architectural bets that pay off over multiple studies. Fund pilots even when the immediate ROI is unclear, because the cost of adopting them once tooling matures without prior investment is catastrophic.

A phased implementation roadmap

1

Stabilize the current backbone (0-6 months)

Confirm SDTM/ADaM governance, standards library, and metadata repository are functioning. If they are not, no other investment will land. Assess readiness for SDTMIG v4.0 transition and Dataset-JSON.

2

Pilot the upstream shift (6-12 months)

Select one or two studies to pilot USDM-based protocol authoring and ICH M11 template adoption. Focus on protocol-to-EDC handoff. Measure startup time, amendment rate, and translation-loss defects.

3

Build the interoperability layer (12-18 months)

Stand up FHIR-based ingestion for EHR pre-population and wearable data on selected studies. Formalize OMOP alignment for any real-world evidence commitments in the portfolio.

4

Extend into therapeutic areas and semantics (18-30 months)

For concentrated therapeutic areas, invest in CFAST-published standards and internal biomedical concept libraries aligned with CDISC 360i. Participate in CDISC and PhUSE working groups to shape emerging standards.

5

Institutionalize the change (30+ months)

Move from pilot to production. Retire redundant tools and mappings. Rebuild governance and role definitions (standards engineers, biomedical concept stewards) to reflect the new architecture, not the old one.

What “good” looks like. The organizations that get this right in the next 3-5 years will see fewer study-startup delays, fewer late-stage data mapping issues, faster CSR timelines, and RWE evidence packages that survive regulatory inspection. IQVIA and others have already documented CSR timeline compressions from weeks to days when governed standards and clinical data repositories are combined with proper standards engineering.18

Common failure modes to avoid

Several patterns show up repeatedly when standards investments underperform. First is the “export format” fallacy, where sponsors treat USDM or Dataset-JSON as another output artifact from their existing tools rather than as a source of truth that upstream tools should consume. This preserves every existing manual step and simply adds a new one at the end. The whole point of USDM is to eliminate the Word protocol as the master; if the Word protocol is still master and USDM is generated from it, the value is nearly zero.

Second is the “single pilot” trap, where one study team runs a successful pilot but the organization never institutionalizes the change. Standards pilots need governance, budget continuity, and an explicit path to portfolio-level adoption. Without those, the pilot ends with a good report and the second study reverts to the old process.

Third is under-investment in vendor management. Most sponsors do not build their own EDC, CTMS, or SDR platform; they buy from Medidata, Veeva, Oracle, and specialized vendors. If those vendors do not support USDM, ICH M11, Dataset-JSON, or FHIR in their roadmaps, no amount of internal standards work will produce end-to-end automation. Vendor selection and contract language are the highest-leverage points a Head of Clinical Data Management has, and they are consistently underused. Explicit standards clauses, roadmap commitments, and integration test coverage should be non-negotiable in new master service agreements.

Fourth is treating standards as a purely IT problem. The people who write protocols, design endpoints, and specify analyses are subject-matter experts, not systems analysts. A standards program that does not train and support them produces friction and shadow processes. Successful programs invest in role-based enablement: clinical scientists learn what USDM allows them to express, biostatisticians learn how machine-readable analysis specifications constrain and free their work, and data managers learn how the standards layer changes their review responsibilities.

The role of AI in the new standards stack

AI does not replace clinical data standards; it depends on them. Large language models trained on unstructured protocol text can extract endpoints and populations with reasonable accuracy, but the accuracy ceiling is much higher when the source material is already structured. Every serious agentic or automation use case in clinical development, protocol authoring assistance, automated EDC configuration, adverse event coding, SDTM mapping suggestions, endpoint adjudication support, gets better as the underlying data becomes more structured and traceable.

This is the strategic connection between the CDISC 360i biomedical concepts effort and the current wave of AI investment. Biomedical concepts are the vocabulary that makes AI outputs verifiable, referenceable, and auditable. Sponsors who invest in standards adoption now are also investing in the data foundation that will make their AI use cases regulatory-acceptable in three to five years. The reverse is also true: sponsors who invest heavily in AI while their upstream data remains unstructured will hit an accuracy and defensibility wall.

From a governance standpoint, this argues for keeping AI strategy and clinical data standards strategy tightly linked. In many organizations, they sit in separate reporting lines, AI under a Chief Digital or Chief AI Officer, standards under Clinical Data Management or Biostatistics. That separation is a structural risk. The organizations that will move fastest over the next planning cycle are the ones treating “AI plus standards” as one program, with joint funding and joint accountability for outcomes like study startup time, data lock cycle time, and inspection readiness.

Conclusion

SDTM is not going away. It remains the mandatory floor of regulatory submission, and the SDTMIG v4.0 update in review now will keep it relevant for another decade. But treating SDTM as the ceiling of your data strategy in 2026 is a portfolio-level risk. The action is upstream at the protocol (USDM and ICH M11), horizontally at interoperability (FHIR and OMOP), and semantically at the biomedical concept layer that CDISC 360i is building. Sponsors who invest in these layers now, in pilots, in vendor requirements, in internal capability, will spend the next planning cycle building. Sponsors who wait will spend it catching up.

Sakara Digital works with pharma and biotech organizations building this kind of standards strategy, particularly at the intersection of AI, quality, and clinical data architecture. If you are exploring how far to invest in emerging standards versus consolidating on proven ones, and want an independent perspective on where to start, we are happy to have that conversation.