The FDA recently updated the Data Standards Catalog, and for clinical programmers, this is a significant shift. The Catalog — a deceptively simple spreadsheet published on the FDA’s Study Data Standards Resources page — is the authoritative reference that dictates which versions of CDISC standards are supported, required, and retired for regulatory submissions to CBER and CDER. When the Catalog changes, your macro libraries, define.xml templates, and validation configurations need to follow.

This article walks through the key changes in the latest Catalog update cycle, what they mean for your day-to-day programming work, and what actions you should be taking now.

Key Changes

The Sunsetting of SDTMIG v3.2

The most notable update is the sunsetting of support for SDTMIG v3.2. This version, published back in 2013, was the industry workhorse for over a decade. The FDA formally ended the requirement for SDTMIG v3.2 on December 13, 2023. What does this mean in practice? Studies that started before that date can continue using v3.2 through submission. But any study initiated after that date can no longer use v3.2 — full stop.

For many organizations, v3.2 is still deeply embedded in standard macro libraries, mapping specifications, and validation rule sets. If your company has not yet migrated, the clock is not ticking — it has already expired for new studies.

SDTM v2.0 / SDTMIG v3.4: Now Required

The FDA announced via Federal Register notice that support for SDTM v2.0, SDTMIG v3.4, and SENDIG-Genetox v1.0 began on December 13, 2023, with a transition date of March 15, 2024. As of March 15, 2025, these versions are required for NDAs, ANDAs, certain BLAs, and certain INDs submitted to CBER or CDER.

SDTMIG v3.4, published in July 2022, is a substantial update from v3.2. Key changes include new domains for Genomics Findings (GF) and Cell Phenotype Findings (CP), expanded scope for the Disease Assessments (DA) domain, updates to the Subject Visits (SV) domain, alignment of screen failure handling with FDA’s Technical Conformance Guide (ARM/ARMCD left blank for screen failures), and integration of biospecimen domains previously housed in the SDTMIG-PGx supplement.

The practical impact: your SDTM mapping specifications, validation configurations, and Pinnacle 21 / CORE rule sets all need to reference v3.4 for any new study starting today. This is not optional — it is a regulatory requirement.

SENDIG-Genetox v1.0: A New Addition

The Catalog now includes SENDIG-Genetox v1.0 as a required standard, also effective March 15, 2025. This is a specialized nonclinical implementation guide for genetic toxicology studies. For sponsors with genetox data in their submissions, this means a dedicated IG now governs data structure rather than relying on general SENDIG conventions.

Dataset-JSON v1.1: The XPT Replacement on the Horizon

While not yet in the Catalog as a supported standard, the FDA published a Federal Register notice in April 2025 requesting public comments on CDISC Dataset-JSON v1.1 as a potential replacement for the SAS v5 XPORT (XPT) transport format. This is a significant signal. The XPT format, rooted in SAS technology from the 1980s, has long-known limitations: the 200-character variable label ceiling, 8-character variable name constraints inherited from SAS v5, and the 32-character dataset name limit.

Dataset-JSON eliminates these constraints and is tool-agnostic — it does not require SAS to create or read. The comment period closed in June 2025, and the FDA is expected to announce a formal adoption timeline. For forward-looking teams, now is the time to start evaluating Dataset-JSON tooling.

Current Catalog Snapshot

The table below summarizes the current state of key standards in the FDA Data Standards Catalog as of the March 2025 publication. Always refer to the official Catalog on the FDA website for definitive dates.

Source: FDA Data Standards Catalog and Federal Register notices. Dates and statuses reflect the most recent Catalog publication. The “Support Ends” column in the official Catalog spreadsheet is the critical field for determining version eligibility based on study start date.

Impact on Define-XML

With the move to newer standards, Define-XML v2.0 is slowly being phased out in favor of Define-XML v2.1. The FDA announced support for Define-XML v2.1 via Federal Register notice, and it is now recommended for any study initiated on or after March 15, 2023. Define-XML v2.0 remains accepted, but the direction is clear.

The practical differences between v2.0 and v2.1 are worth understanding:

• Dataset subclass metadata: Define-XML v2.1 introduces the def:Subclass element, allowing more granular classification of ADaM datasets (e.g., distinguishing BDS from OCCDS within the same define file). This was not possible in v2.0.
• Standards referencing: v2.1 can explicitly reference which ADaMIG version applies to each dataset, improving traceability for reviewers who need to verify conformance against the correct IG version.
• Controlled terminology alignment: The v2.1 specification aligns with CDISC’s Define-XML controlled terminology, reducing ambiguity in how dataset classes and other coded values are represented.
• Analysis Results Metadata (ARM): While ARM was supported in v2.0, the v2.1 structure provides cleaner integration. Including ARM in your ADaM define.xml is not explicitly required by FDA, but it is increasingly valued by reviewers and highly recommended for submissions.

Bottom line: if you are starting a new study today, there is no reason to use Define-XML v2.0. Build your templates and tooling around v2.1.

How to Read the Catalog

The Catalog is published as an Excel spreadsheet with multiple tabs. The key columns to pay attention to are:

• Support Begins: The date FDA tools and processes can accept submissions using this version.
• Support Ends: The critical field. If a study starts after this date, that version of the standard can no longer be used. Studies started before this date are grandfathered.
• Requirement Begins: The date after which this version must be used in applicable submissions (NDAs, ANDAs, certain BLAs/INDs).
• Requirement Ends: When the mandatory use of this version expires, typically because a newer version’s requirement has begun.

The critical rule: the FDA determines version eligibility based on study start date, not submission date. This is different from PMDA, which uses submission date. For global programs submitting to both agencies, this distinction matters and should be addressed early in study setup.

What You Should Do Now

• Audit your current standard macro libraries. If your SDTM mapping templates, domain creation macros, or validation configurations still reference SDTMIG v3.2 as the default, they need to be updated. For any study starting now, v3.3 or v3.4 should be the standard. Given that v3.4 is the required version going forward, prioritize migrating directly to v3.4 rather than making an interim stop at v3.3.
• Review the “Support Ends” column in the Catalog carefully. Cross-reference this against your active study inventory. For each study, confirm that the SDTM, ADaM, and Define-XML versions in your specifications are still supported based on the study start date. Flag any studies that may be caught in a version gap.
• Start pilot submissions using Define-XML v2.1. If your team is still generating Define-XML v2.0, begin the migration. Update your SAS or open-source define generation tools, test the output against Pinnacle 21 or CORE validation, and confirm the rendered define.xml displays correctly. The subclass metadata and standards referencing features in v2.1 are not just cosmetic — they improve reviewer experience and reduce conformance findings.
• Get Dataset-JSON on your radar. While XPT is not going away tomorrow, the FDA’s formal request for comments signals that the transition is coming. Evaluate tools from the pharmaverse ecosystem and CDISC that can read and write Dataset-JSON. Running a parallel pilot — generating both XPT and Dataset-JSON for a study — is a low-risk way to build institutional knowledge before the requirement lands.
• Update your Pinnacle 21 / CORE configurations. Validation rule sets are version-specific. Running SDTMIG v3.4 data through v3.2 rules (or vice versa) will produce misleading findings. Ensure your validation tool is configured to match the standard version declared in your define.xml.
• Communicate with your statisticians and data management leads. Catalog changes affect CRF design (CDASH), SDTM mapping, ADaM derivations, and TFL specifications. Standards version decisions should be made at study setup and documented in the Data Standards Plan, not discovered at submission time.

The Bigger Picture

The 2025 Catalog update is not a one-time event — it is part of a broader modernization trajectory. The FDA’s Data Standards Program Action Plan lays out ongoing initiatives including the evaluation of Dataset-JSON as an exchange format, exploration of HL7 FHIR for real-world data submissions, continued updates to the Study Data Technical Conformance Guide (sdTCG), and progress toward IDMP (Identification of Medicinal Products) standards implementation.

For statistical programmers, the takeaway is straightforward: the standards landscape is evolving faster than it has in years. The gap between SDTMIG v3.2 (2013) and v3.4 (2022) was nearly a decade. The next cycle will likely be shorter. Building processes that can absorb version changes — modular macros, configurable define generation, version-aware validation — is no longer a nice-to-have. It is a requirement for staying submission-ready.

clinstandards.org — Technical depth for statistical programmers.