Claude

IntuitionLabs is now a member of the Claude Partner Network – AI training and upskilling with Claude for pharma and biotech. Book a call.

IntuitionLabs
Back to Articles
IntuitionLabs

fda study data standards · fda data standards catalog

FDA Study Data Standards: Version and Rejection Matrix

September 20, 2026
22 min read

A 2026 operational guide to FDA study data standards version selection, including catalog dates, SDTM, SEND, ADaM, Define-XML, and rejection preflight controls.

FDA Study Data Standards: Version and Rejection Matrix
Summary
  1. 01Version selection is a row-level decision using the study start date, submission type, FDA center, data use, exchange format, and support and requirement dates.
  2. 02Supported and required are distinct lifecycle states: FDA can accept a supported version before its use becomes mandatory for an affected cohort.
  3. 03A per-study standards-selection record preserves the selected configuration, source evidence, lifecycle dates, validation releases, and approval history.
  4. 04Preflight must keep catalog eligibility, eCTD mechanics, inbound technical checks, rule conformance, and scientific traceability as separate gates.
01

Executive Summary

FDA study data standards version selection is not a search for the newest Clinical Data Interchange Standards Consortium (CDISC) publication. It is a row-level decision against the current FDA Data Standards Catalog, using the study start date, submission type, FDA center, data use, exchange format, and the row's support and requirement dates. As of September 19, 2026, FDA's live guidance page still identifies the catalog as March 2025, and the downloadable workbook identifies itself as version 11.0 ([1]) ([2]). That as-of date matters: FDA reported one catalog update in 2025 after two in 2024, so a frozen secondary matrix is not a durable source of truth ([3]) ([4]).

The governing distinction is supported versus required. A supported version is one FDA can accept; a requirement date is when use becomes mandatory for the affected study cohort. When multiple versions remain supported, the sponsor can select among them, but the chosen version must fit the applicable row and start date ([5]) ([6]). For the latest major rows verified here, SDTM v2.0 with SDTMIG v3.4 became required on March 15, 2025, SENDIG v3.1.1 became required on March 15, 2023, and ADaMIG v1.3 became required on March 15, 2024 for the catalog-defined CDER and CBER uses ([7]) ([8]) ([9]).

Selection is only half the control. The June 2026 Study Data Technical Conformance Guide makes the Trial Summary dataset, ts.xpt, the operational bridge between a study's start date and inbound validation. For eCTD v3.2.2, FDA links ts.xpt through the Study Tagging File; eCTD v4.0 instead associates it with the relevant study keyword ([10]) ([11]). Preflight therefore needs separate gates for catalog eligibility, file and folder mechanics, automated Technical Rejection Criteria, FDA Business Rules, FDA Validator Rules, and scientific traceability. These artifacts solve different problems and should never be combined into one validator score.

The practical output is a standards-selection record per study, not a project-wide declaration that a program is “on SDTM 3.4.” The record should retain the catalog issue, selected row, start-date evidence, model and implementation-guide pair, controlled-terminology date, exchange format, Define-XML version, waiver status, validation-rule releases, and approval history. IntuitionLabs is an adjacent life-sciences adviser, not a standards vendor; its documented work in governed information, citations, evaluation, integration, and data pipelines supports this evidence-chain framing ([12]) ([13]).

84%

Share of CDER submissions reported in eCTD format in fiscal 2025

17

Regulatory-suitability assessments FDA completed in 2025

1,124

Approximate terms added across six standards families in the March 2026 release

02

Introduction and Background

FDA standards selection looks deceptively like a version lookup. In practice, it is a temporal and jurisdictional decision. The relevant questions are: Which center receives the submission? Which application type is involved? Is the study clinical or nonclinical? What is the legally meaningful study start date? Which catalog row covers the data use? Was the version supported on that date, and had a requirement begun? The answers determine a defensible version set.

The statutory foundation permits electronic-format requirements no earlier than 24 months after final guidance issued through notice and comment, and it authorizes criteria for waivers and exemptions ([14]) ([15]). The implementation guidance covers study data in NDA, ANDA, BLA, and IND submissions and later amendments, supplements, and reports for covered applications ([5]). It does not make every FDA center or submission pathway identical.

This report therefore treats the catalog as a controlled regulatory dataset. The model, implementation guide, terminology, metadata standard, and exchange format are separate but connected configuration items. CDISC describes the Study Data Tabulation Model (SDTM) as the standard for organizing and formatting data, while each implementation guide identifies its associated model version ([16]) ([17]). Treating “SDTM” as a single version field loses that relationship.

An operational selection method has four stages:

  • Scope: classify the center, application, study, and submission sequence.

  • Time: establish the study start date from source evidence.

  • Catalog: filter eligible rows, then distinguish support, requirement, and preference.

  • Preflight: test transport, placement, metadata, rule conformance, and traceability separately.

This framing also prevents a common category error: CDISC publication does not equal FDA support. For example, CDISC published SDTM v2.0 on November 29, 2021, but FDA support and requirement came through its own catalog and notice process ([18]) ([19]).

03

Key Changes

The catalog's Date Support Begins means FDA can accept the indicated property. Date Support Ends means FDA will no longer accept it; an empty field means that no end date has been established. Requirement dates answer a different question: when use becomes mandatory and when that mandate ceases. FDA's own workbook defines these concepts separately ([20]) ([21]).

That separation creates three operational states:

  • Supported, not required: FDA can accept the version, but an older eligible version may remain permissible.

  • Supported and required: studies in the affected cohort must use that standard or an accepted alternative path.

  • No longer supported: new selections should not use the version; a study started before the end date may continue under the catalog rule, subject to the exact row and waiver discussion.

The last point is temporal, not merely technical. FDA's workbook says a study begun before support ends can continue, which makes preserved start-date evidence essential ([22]).

Model, guide, metadata, and terminology versions must be coupled

SDTM is the conceptual tabulation model. SDTMIG applies that model to human clinical domains. SENDIG applies SDTM principles to nonclinical data. ADaM creates analysis-ready structures with traceability back to SDTM. Define-XML conveys machine-readable metadata describing datasets, variables, controlled terms, and derivations. CDISC expressly describes ADaM's traceability role. EMA likewise characterizes ADaM around traceability among results, analysis data, and SDTM data ([23]).

Controlled Terminology (CT) is another independent axis. NCI preserves terminology by dated release and maintains historical archives, so “current CT” is not an inspectable statement unless the exact date is recorded ([24]). CDISC's March 27, 2026 release updated multiple standards families, and the terminology program describes what values should be submitted, not what a protocol should collect ([25]) ([26]).

Exchange format is changing more slowly than content standards

As of the report date, FDA's Technical Conformance Guide still specifies SAS Transport Format v5, or XPT v5, for study datasets ([27]). CDISC identifies the familiar XPT constraints of 8-character variable names and 200-character text fields ([28]).

Dataset-JSON is not a production substitute merely because it has been published. CDISC defines Dataset-JSON v1.1 as a JSON-based tabular exchange standard and allows it to reference a Define-XML document for fuller metadata ([29]) ([30]). FDA's 2025 assessment concluded that Dataset-JSON does not demonstrate superiority over existing processes and that premature adoption was found to risk negatively impacting reviewer and analyst productivity and efficiency ([31]). The catalog, not pilot success, controls production selection.

F.01
Supported versus required
Supported
  • FDA can accept the version, while an older eligible version may remain permissible.
  • The support-end field can be empty when no end date has been established.
Required
  • Affected studies must use the standard or an accepted alternative path.
  • Requirement dates govern when use becomes mandatory and when that mandate ceases.

The chosen version must fit the applicable catalog row and study start date.

The governing distinction is **supported versus required**. A supported version is one FDA can accept; a requirement date is when use becomes mandatory for the affected study cohort.

04

Operational Version Selection Matrix

Step 1: determine whether the CDER and CBER rule set applies

Table 1 separates the principal pathways before any version is selected.

T.01
QuestionOperational classificationEvidence to retain
Is the submission an NDA, ANDA, BLA, or IND to CDER or CBER?Apply the standardized-study-data framework to covered study data and later amendments, supplements, and reports.Application type, center, sequence, eCTD module, and submission plan. The 2014 notice identifies the four application families ([5]).
Is the IND noncommercial?FDA has exempted noncommercial IND submissions, including investigator-sponsored and expanded-access INDs, from this standardized-study-data requirement.Regulatory classification and exemption rationale ([32]).
Is the product a CBER-regulated device?Do not assume the drug-and-biologic framework applies. The guidance excludes devices regulated by CBER as biological products.Product jurisdiction decision and applicable device pathway ([33]).
Is CDRH receiving medical-device clinical data?CDRH states that it does not require one specific clinical-trial-data format.CDRH interaction record and selected terminology or format rationale ([34]).
Is CVM the receiving center?Use CVM's distinct electronic-submission documentation and eSubmitter pathway rather than importing CDER and CBER assumptions.CVM submission route and technical specification ([35]).
Is a different supported version necessary?A waiver request may concern a specific FDA-supported version, not permission to ignore all supported standards.Request, technical rationale, review correspondence, and outcome. FDA generally intends a response within 30 days ([36]).

The table shows why “FDA submission” is too broad a selection key. Center and statutory pathway precede standards-family choice. FDA guidance itself does not create enforceable duties unless mandatory language describes a statutory or regulatory requirement, which makes the source and status of each rule important ([37]).

Step 2: establish the study start date

For a clinical study, the start date is the earliest informed-consent date among enrolled subjects. For a nonclinical study, it is the date the study director approves and signs the protocol or study plan ([38]) ([39]). This date should be derived once from authoritative study evidence, reconciled to SSTDTC in Trial Summary, and reused across selection, validation, and reviewer documentation.

The broad mandate began by study initiation after December 17, 2016 for NDAs, BLAs, and ANDAs, and after December 17, 2017 for commercial INDs ([40]). Later version-specific requirement dates further segment those cohorts. A pre-mandate study and a post-mandate study in the same application can therefore legitimately carry different standards selections.

Step 3: filter the live catalog row by row

Table 2 is an as-of-dated operational matrix of the latest major rows verified for this report. It is not a substitute for downloading the catalog at the next decision point.

T.03
Data useLatest verified version setSupport and requirement logicOperational note
Clinical tabulationSDTM v2.0 with SDTMIG v3.4FDA support began December 13, 2023 and the requirement began March 15, 2025 for catalog-defined NDA, ANDA, certain BLA, and certain IND uses ([41]).Pair model and guide. Do not infer support from CDISC publication alone.
Nonclinical tabulationSENDIG v3.1.1Support began February 15, 2022 and the requirement began March 15, 2023 for the applicable CBER and CDER rows ([42]).SENDIG is based on SDTM but has its own catalog lifecycle ([43]).
Clinical analysisADaM v2.1 with ADaMIG v1.3Catalog v11.0 identifies ADaMIG v1.3 support from July 18, 2022 and requirement from March 15, 2024 for applicable CBER and CDER clinical XPT datasets ([9]).ADaMIG defines dataset structures, variables, and naming conventions ([44]).
MetadataDefine-XML v2.1 in the catalog; 2.0 or later strongly preferred in the June 2026 guideCheck the catalog row for the selected study cohort and metadata use. Define-XML identifies standards and CT versions referenced by the metadata ([45]).“Preferred” is technical guidance, not a separate catalog status.
Exchange formatSAS XPORT v5Remains the specified clinical and nonclinical dataset transport in the verified catalog and guide.FDA concluded that Dataset-JSON does not demonstrate superiority over existing processes and that premature adoption was found to risk negatively impacting reviewer and analyst productivity and efficiency ([31]).
Controlled terminologyStandard-family-specific, date-versioned packagesUse the most recent dictionary available at study start, document later updates, and use one version for pooled analyses where FDA guidance calls for consistency.Preserve exact release dates and codelist exceptions. NCI's archive makes historical reconstruction possible ([46]).

The matrix should be joined to the sponsor's inventory by study, not by program. If more than one version is supported for the same use, FDA allows a selection or review-division discussion. If support ends, the start-date rule can preserve an older selection for a study already underway. Neither conclusion should be inferred from the requirement date alone.

05

Implementation Considerations and Process Changes

Build one standards-selection record per study

The selection record should be a controlled object with fields that are machine-readable and reviewable. At minimum, retain:

  • Identity: study ID, protocol ID, application number, center, submission type, and eCTD version.

  • Study classification: clinical or nonclinical, pivotal or supportive, and applicable data uses.

  • Start-date evidence: source record, derived date, derivation rule, approver, and reconciliation to SSTDTC.

  • Catalog provenance: issue month, workbook version, retrieval date, source URL, worksheet, and row identifier.

  • Version set: model, implementation guide, Define-XML, terminology packages, dictionaries, and XPT format.

  • Lifecycle state: support begin, requirement begin, support end, requirement end, and preference notes.

  • Exception status: waiver need, review-division discussion, question, response, and decision.

  • Validation baseline: Technical Rejection Criteria release, Business Rules version, Validator Rules version, and CDISC conformance-rule release.

  • Approval trail: preparer, independent reviewer, regulatory owner, effective date, and change history.

This is more than documentation. It creates an executable join between the portfolio inventory and external lifecycle data. The ICH Common Technical Document places nonclinical reports and data in Module 4, while FDA recommends nonclinical and clinical reviewer guides with study data in Modules 4 and 5, respectively ([47]) ([48]). The selection record should drive both content generation and placement checks.

Separate selection policy from implementation policy

A selection policy answers what may or must be submitted. An implementation policy answers how the chosen standards are applied consistently. Conflating them encourages teams to upgrade content because a new CDISC version exists even when FDA has not added it to the catalog.

The implementation layer should maintain:

  • Mapping specifications from collection structures to SDTM or SEND.

  • Analysis specifications from SDTM to ADaM, with explicit derivation traceability.

  • Metadata generation for Define-XML, reviewer guides, annotated forms, and terminology provenance.

  • Rule dispositioning that distinguishes true nonconformance, sponsor convention, known limitation, and justified exception.

  • Reproducible builds so datasets, metadata, and validation reports derive from the same approved configuration.

Standards implementation depends on explicit guide-to-model pairing, so a model number alone is insufficient. CDISC also says SEND releases should assess and realign with the SDTM model, another reason to store the explicit pairing rather than a loose family label ([49]).

Manage notice periods as change-control lead time

FDA states that it will give at least one year before requiring a new version of an existing standard and at least two years for an entirely new standard ([19]) ([14]). Organizations should use that interval for impact assessment, not wait for the requirement date.

An effective change workflow is:

  1. Detect: monitor the catalog page, workbook checksum, Federal Register notices, Technical Conformance Guide, and rule-package pages.

  2. Diff: compare rows and fields, not only workbook version numbers.

  3. Join: match changed rows to active and planned studies by start date and use.

  4. Classify: mark each study as unaffected, review required, migration candidate, or exception candidate.

  5. Test: run representative conversions and metadata builds under the new configuration.

  6. Approve: obtain statistical programming, data management, regulatory operations, and quality sign-off.

  7. Deploy: version templates, validation profiles, and platform configuration.

  8. Evidence: archive the source catalog, diff, impact results, approvals, and effective date.

06

Technical Rejection Preflight

Technical Rejection Criteria are automated inbound checks. They do not replace FDA Business Rules, Validator Rules, CDISC conformance rules, or scientific review. FDA's resource page identifies Business Rules v1.5 from May 2019 and Validator Rules v1.6 from December 2022 ([50]) ([51]).

Table 3 turns the rule layers into a preflight sequence.

T.02
GateWhat to testPass evidence
1. Catalog eligibilitySelected row matches center, application, data use, study start date, support dates, and requirement dates.Approved standards-selection record and archived catalog source.
2. Trial Summaryts.xpt exists where required; STUDYID, TSPARMCD, TSVAL, and TSVALNF are present in the simplified clinical structure; SSTDTC matches source evidence.Dataset listing and source reconciliation ([52]).
3. eCTD associationFor v3.2.2, ts.xpt is connected through a valid Study Tagging File. For v4.0, it is associated with the applicable study keyword.Structure validation log and visual manifest review. ICH notes that regional documents must be used with the core eCTD package ([53]).
4. Required anchorsSEND has DM plus Define-XML; SDTM has DM plus Define-XML; ADaM has ADSL plus Define-XML, as applicable.Inbound-criteria simulation and manifest.
5. File tags and placementDefine-XML has the correct tabulation or analysis file tag; reviewer guides and data are in the expected module locations.eCTD file-tag report and folder inventory.
6. Transport and metadataXPT v5 constraints, dataset names, variable attributes, code lists, origins, methods, and leaf references agree.Dataset and Define-XML cross-check. Define-XML is designed to describe tabular structures ([54]).
7. Rule conformanceRun the approved FDA Business Rules, FDA Validator Rules, and applicable CDISC rules as separate profiles.Versioned reports, severity mapping, and signed dispositions.
8. Scientific traceabilityAnalysis results trace through ADaM to SDTM and source, with reviewer documentation explaining transformations.Traceability matrix and reproducible outputs. EMA emphasizes links among analysis results, analysis data, and source tabulations ([23]).

The order matters. Running a validator before establishing catalog eligibility can produce a technically clean package built to the wrong version. Conversely, a correct version choice does not prove that file tags, anchors, metadata, or analysis lineage are sound. FDA can decline to file an NDA or BLA, or decline to receive an ANDA, when required study data do not conform, so the inbound gate deserves independent release-controlled testing ([19]).

F.02
Technical rejection preflight
01Catalog eligibility

Confirm the selected row against center, application, data use, start date, and lifecycle dates.

02Trial Summary

Confirm the Trial Summary dataset and reconcile its study start date to source evidence.

03eCTD association

Associate the Trial Summary dataset through the correct study mechanism for the eCTD version.

04Required anchors

Check the required dataset and Define-XML anchors for the applicable standards family.

05Rule conformance

Run the approved FDA and CDISC rule sets as separate validation profiles.

06Scientific traceability

Trace analysis results through ADaM and SDTM to source, with documented transformations.

Versioned reports, severity mapping, and signed dispositions.

07

Data Analysis and Evidence

The external change stream is measurable. FDA published six Technical Conformance Guide updates in 2023, three versions in 2024, and reported two catalog updates in 2024 followed by one in 2025 ([55]) ([56]). In 2025, FDA also completed 17 regulatory-suitability assessments across models, technical documents, and terminologies ([57]). This is enough movement to justify automated monitoring and portfolio impact analysis.

Terminology changes faster than foundational models. CDISC says Controlled Terminology is released quarterly, while foundational standards and therapeutic-area guides are less frequent ([58]). Its March 2026 release added approximately 1,124 terms across six standards families plus approximately 248 QRS terms ([59]). NCI EVS independently exposes the date-versioned package and archives, enabling exact reconstruction of a submission configuration ([46]) ([60]).

Submission scale reinforces the governance case. FDA reported that 84% of CDER submissions were in eCTD format in fiscal 2025 ([61]). The same assessment described Dataset-JSON work using five clinical and three nonclinical studies from industry volunteers ([62]). These figures show both production scale and the deliberately bounded nature of emerging-format evaluation.

Organizations can quantify internal impact without inventing industry cost benchmarks. A simple change-impact calculation is:

Records needing review = active or planned study records whose center, application type, data use, start-date interval, or selected version intersects a changed catalog row.

Report the result as counts and proportions:

  • Total studies inventoried by clinical and nonclinical class.

  • Studies matched to each changed catalog row.

  • Studies before and after each requirement or support-end date.

  • Studies using an affected version today.

  • Records missing start-date evidence or an approved selection record.

  • Packages requiring validation-profile changes even when dataset versions remain unchanged.

  • Exception candidates needing review-division discussion or a waiver decision.

This calculation should not estimate migration hours or cost unless the sponsor has measured its own historical effort. Its purpose is prioritization. (Hypothetical Example) A portfolio of 120 studies with 9 affected records presents a different control problem from one with 90 affected records, but public sources do not support a universal conversion-duration benchmark.

Evidence provenance cross-checks

The operational record should preserve corroborating provenance, not just a copied conclusion:

  • Authority: statutory timing, waiver authority, and application scope come from the Code and official notices ([14]) ([15]) ([5]) ([19]) ([37]).

  • Transition: requirement cohorts are anchored to formal notices rather than standards-body publication dates ([40]) ([7]) ([19]) ([5]) ([14]).

  • Exceptions: exemptions and waiver decisions should retain both legal and guidance provenance ([15]) ([33]) ([37]) ([19]) ([40]).

  • Terminology: release dates should be reconstructable from NCI's dated distribution and archive ([24]) ([60]) ([46]) ([46]) ([24]).

  • Semantics: terminology supports consistent meaning across tabulation, analysis, and metadata layers ([60]) ([46]) ([24]) ([23]) ([23]).

  • Traceability: analysis evidence should connect results, ADaM, SDTM, and implementation rules ([23]) ([23]) ([23]) ([23]) ([23]).

  • Modules: eCTD implementation must preserve both harmonized and regional requirements ([47]) ([53]) ([53]) ([37]) ([5]).

  • Guidance status: teams should distinguish recommendations from mandatory statutory or regulatory language ([37]) ([37]) ([14]) ([15]) ([19]).

  • Emerging exchange: FDA concluded that Dataset-JSON does not demonstrate superiority over existing processes and that premature adoption was found to risk negatively impacting reviewer and analyst productivity and efficiency ([31]) ([63]) ([63]) ([63]) ([53]) ([19]).

  • Start-date cohorts: archived notices provide the evidence for historical requirement boundaries ([40]) ([40]) ([7]) ([19]) ([5]).

  • Version evidence: the latest SDTM requirement date should be corroborated against the formal notice and catalog snapshot ([7]) ([7]) ([19]) ([14]) ([37]).

  • Independent review: a second reviewer should be able to trace implementation, analysis, and metadata decisions to their originators ([23]) ([23]) ([24]) ([46]) ([47]).

F.03
FDA Technical Conformance Guide updatesupdates or versions
Source: FDA reported

The order matters. Running a validator before establishing catalog eligibility can produce a technically clean package built to the wrong version.

08

Implications and Future Directions

The near-term direction is a more granular standards stack, not a single synchronized release. Model versions, implementation guides, terminology, metadata, eCTD validation criteria, and exchange formats move on different calendars. CDISC's SDTM v2.0 was designed for backward compatibility, but that design fact does not create FDA catalog eligibility ([64]). Platform owners should therefore model standards as related entities with effective intervals, not as a text field attached to a study.

Dataset-JSON deserves architectural preparation but not premature production substitution. Its tabular JSON design can reference Define-XML, but FDA's 2025 assessment concluded that Dataset-JSON does not demonstrate superiority over existing processes and that premature adoption was found to risk negatively impacting reviewer and analyst productivity and efficiency ([65]) ([31]). A prudent design separates the canonical data model from the exchange serializer so a future catalog change does not require rebuilding derivation logic.

Three governance priorities follow:

  • Machine-readable provenance: retain source URL, retrieval time, workbook hash, worksheet, row, and exact selected values.

  • Effective-dated configuration: make every selection queryable by study start date and catalog interval.

  • Independent controls: keep catalog eligibility, technical acceptance, standards conformance, and scientific traceability as distinct approval gates.

The same structure supports governed automation. A system can flag catalog diffs, identify affected studies, regenerate validation profiles, and assemble evidence, but accountable owners should approve interpretation and exceptions. This aligns with the publisher's documented emphasis on authoritative sources, permissions, citations, evaluation, and accountable operation, while keeping the regulatory decision with sponsor functions ([12]).

09

Frequently Asked Questions (FAQs)

Does FDA require the newest SDTM version?

The governing statute authorizes electronic-format timetables and criteria for waivers and exemptions ([66]).

Not automatically. FDA requires the version or version set specified by the applicable catalog row for the relevant center, submission, data use, and study-start-date cohort. A newer CDISC publication is not selectable until FDA supports it. When multiple versions are supported, sponsors may select one or discuss the choice with the review division. The Federal Register transition process is the bridge between publication and FDA lifecycle status ([19]).

Is supported the same as required?

No. Supported means FDA can accept the format. Required means use is mandatory for the affected cohort. Support may precede requirement, allowing an implementation interval. A blank support-end field means no end has been established, not that the version will remain supported forever.

Which date controls version selection?

Use the FDA-defined study start date: earliest informed consent among enrolled subjects for a clinical study, and study-director approval of the protocol or plan for a nonclinical study. Record the source and reconcile it to Trial Summary. Do not substitute database lock, first data transfer, or submission date.

Are SDTM, ADaM, and Define-XML interchangeable choices?

No. They occupy different layers. SDTM and SEND organize tabulation data, ADaM structures analysis data, and Define-XML describes metadata. CDISC describes Define-XML as transmitting metadata for tabular structures, while ADaM supports reproducible review and traceability ([54]) ([67]).

Does a clean validator report prevent technical rejection?

Not by itself. Technical Rejection Criteria are inbound structural checks, while Business Rules and Validator Rules address other forms of standards conformance. A clean result under one profile does not prove the catalog row, file tags, study association, required anchors, terminology, or analysis traceability are correct.

How often should the catalog be checked?

Check at study planning, standards-selection approval, major protocol or data-model changes, pre-submission planning, and immediately before package freeze. Also monitor catalog and guide change notifications continuously. FDA's recent update counts show that annual-only review can miss multiple guide changes within one year.

What should be retained for inspection readiness?

Retain the catalog source and checksum, selected row, study-start-date evidence, complete version set, terminology dates, rule-package versions, validation reports, dispositions, exception correspondence, approvals, and change history. That record should allow an independent reviewer to reproduce why the version was eligible on the decision date.

10

Conclusion

FDA study data standards version selection is a controlled, effective-dated decision. The defensible method begins with jurisdiction and application scope, establishes the FDA-defined study start date, filters the live catalog by data use, and distinguishes support from requirement and technical preference. It then records the full configuration across SDTM or SEND, ADaM, Define-XML, terminology, and exchange format.

As of September 19, 2026, the authoritative baseline is the March 2025 FDA Data Standards Catalog v11.0 paired with the June 2026 Technical Conformance Guide and the current applicable validation criteria. The exact baseline will change. FDA's recent catalog and guide update counts, CDISC's quarterly terminology cadence, and FDA's conclusion that Dataset-JSON does not demonstrate superiority over existing processes make maintenance a continuing portfolio process rather than a one-time submission task ([31]).

The strongest operating model is a per-study standards-selection record linked to source evidence and separate preflight gates. Catalog eligibility, eCTD mechanics, inbound technical criteria, business and validator rules, and scientific traceability should each have their own versioned evidence. That structure lets biostatistics, programming, data management, regulatory operations, and platform teams change at the speed of official notices without losing the historical reasoning behind any study's submission configuration.

The publisher

About IntuitionLabs

Build practical AI for pharma and biotech with IntuitionLabs. We help life-science teams turn complex information and workflows into useful software, governed knowledge systems and AI tools.

IntuitionLabs is an AI consulting, custom software development and data engineering firm serving pharmaceutical, biotechnology, medical-device and other life-science organizations. We work with clinical, regulatory, medical-affairs, commercial, quality and IT teams to connect technology decisions with the work people need to accomplish.

AI consulting and adoption

Our AI enablement services cover readiness assessments, use-case selection, governance and policies, team workshops, adoption measurement and ongoing advisory support. We help organizations structure the information layer behind AI: source material, context, permissions and maintained knowledge that make generated answers useful and reviewable. Private LLM inference and hosted AI options support teams evaluating how to operate AI with appropriate control over their data and infrastructure.

Software, data and life-science workflows

IntuitionLabs develops custom software for pharma and biotech, integrates enterprise systems, and builds data engineering and business intelligence solutions. Areas of focus include AI agents, regulatory research, medical writing, medical affairs, CMC information, competitive intelligence and clinical-document workflows. Our eTMF intelligence work includes cross-system reconciliation and inspection-readiness support.

Enterprise platforms and regulated delivery

We provide Veeva services, application support, managed services, integrations and custom applications, alongside enterprise content work involving platforms such as Egnyte. For regulated workflows, our services include GxP enablement, computer-system validation and software development addressing 21 CFR Part 11 requirements. The applicable controls, validation responsibilities and acceptance criteria are defined for each engagement.

Work with IntuitionLabs

Explore AI enablement, pharma and biotech software development, data engineering and BI, and Veeva services. Contact IntuitionLabs to discuss your workflow, information sources and implementation needs.

IntuitionLabs publishes educational research to help life-science teams make informed technology decisions. Coverage of a product or organization does not imply a client relationship, endorsement or partnership.

Sources / 67
Adrien Laurent

Need Expert Guidance on This Topic?

Let's discuss how IntuitionLabs can help you navigate the challenges covered in this article.

I'm Adrien Laurent, Founder & CEO of IntuitionLabs. With 25+ years of experience in enterprise software development, I specialize in creating custom AI solutions for the pharmaceutical and life science industries.

Disclaimer

The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.

Related Articles

Need help with AI?

© 2026 IntuitionLabs. All rights reserved.