FDA Technical Rejection Criteria for Study Data: A Comprehensive Deep Dive

Understanding the Electronic Submissions Gateway Validation Process

Executive Summary

The FDA’'s Technical Rejection Criteria (TRC) represent a critical set of automated validation rules that determine whether clinical and nonclinical data submissions are accepted into FDA systems or technically rejected at the Electronic Submissions Gateway (ESG). Implemented in September 2021, these criteria enforce standardized study data requirements across all New Drug Applications (NDAs), Abbreviated New Drug Applications (ANDAs), Biologics License Applications (BLAs), and Investigational New Drug applications (INDs) submitted to CDER and CBER.

This article provides a comprehensive examination of each technical rejection criterion, supported by practical scenarios and corrective actions based on the FDA’'s official “Specifications for eCTD Validation Criteria” (Version 4.5).

Regulatory Background

The TRC derives its authority from Section 745A(a) of the FD&C Act. These are not “suggestions” but binding requirements. If a submission fails a High-severity code, the ESG will physically block the data from reaching the reviewer’'s desk, effectively halting the regulatory clock.

The Sequential Validation Process

Validation follows a strict “Stop-on-Fail” logic. The gateway processes checks in a specific order; if Sequence 1 fails, the system stops and will not even check for Sequence 2 or 3 errors.

Technical Codes: Failures, Pitfalls, and Corrective Actions

Code 1789: STF File Requirement

The Failure: A file is submitted in a study section without an accompanying Study Tagging File (STF).

Real-World Pitfall: A programmer creates a new folder for a supplemental study but forgets to include the stf-xxxx.xml. Because the automated gateway cannot “tag” the files to a specific study ID, the entire sequence is rejected.

Corrective Action: Generate a valid STF XML that references every file in that directory. Ensure the STF is placed in the same folder as the study datasets.

Code 1734: Trial Summary (TS) Dataset

The Failure: Missing ts.xpt or missing SSTDTC variable.

Real-World Pitfall (The Date Format Trap): A programmer enters the date as 01-JAN-2024 or 2024/01/01.

Result: REJECTION. The FDA system requires ISO 8601 (YYYY-MM-DD).

Corrective Action: Update the ts.xpt dataset. Ensure TSPARMCD = 'SSTDTC' and TSVAL follows the strict YYYY-MM-DD format.

Code 1735: Correct STF File-Tags

The Failure: Using non-standard tags in the STF XML.

Real-World Pitfall (The “Data-Listing” Error): A programmer tags the dm.xpt file as data-listing instead of data-tabulation-dataset-sdtm.

Result: REJECTION. The gateway ignores the file because it doesn’'t recognize the tag as a “standardized dataset.”

Corrective Action: Edit the STF XML. Cross-reference the FDA’'s “Valid eCTD File Tags” table and update the <file-tag> attribute to the correct standard.

Code 1736: Core Datasets and define.xml

The Failure: Missing the “anchor” files (dm.xpt or adsl.xpt).

Real-World Pitfall (The “Legacy” Logic Error): A sponsor submits an ADaM package but forgets the adsl.xpt because they felt the data was redundant with SDTM.

Result: REJECTION. adsl.xpt is the parent for all ADaM analysis; without it, validation fails.

Corrective Action: Ensure dm.xpt or adsl.xpt and a valid define.xml are present in every study folder.

Cross-Functional Collaboration: Avoiding Rejection

Successful submission is not the responsibility of a single department. It requires a synchronized “hand-shake” between Statistical Programming and Regulatory Affairs.

The Role of the Statistical Programming Team

Programmers are the creators of the technical metadata. Their focus must be on Data Integrity:

• Precision in TS: Ensuring the ts.xpt contains the accurate SSTDTC derived from the protocol or first subject enrollment.

• Standardization: Ensuring all file names are lowercase and .xpt extensions are used consistently.

• Anchor Management: Guaranteeing that every ADaM folder contains an adsl.xpt.

The Role of the Regulatory Operations Team

Regulatory teams are the gatekeepers. Their focus is on eCTD Structure:

• STF Generation: Ensuring that the STFs correctly reference the path to the programmer’'s datasets.

• Tagging Accuracy: Double-checking that the “File Tag” assigned in the eCTD software matches the standard.

• Lifecycle Management: Managing the “New” vs “Replace” operators to avoid Code 1737 (Duplicate) rejections.

Pre-Submission QC Checklist

☐1. STF Presence: Every study folder in M4/M5 has an .xml STF?

☐2. TS Presence: Every study folder contains a ts.xpt?

☐3. SSTDTC Check: Does ts.xpt have a row where TSPARMCD = 'SSTDTC'?

☐4. ISO 8601 Check: Is the TSVAL date strictly YYYY-MM-DD?

☐5. File-Tag Audit: Are SDTM files tagged as data-tabulation-dataset-sdtm?

☐6. Anchor Check: Is dm.xpt (SDTM) or adsl.xpt (ADaM) included?

☐7. Define Check: Is define.xml present and correctly tagged?

☐8. Lifecycle Check: Are updated files set to replace (not new)?

☐9. Exact ID Match: Does the STF ID match TS.STUDYID exactly (Case & Spaces)?

☐10. Filename Check: Are all dataset filenames lowercase?

Valid eCTD File Tags Reference

Common Rejection Scenarios and Solutions

Scenario 1: The Missing Study Start Date

Problem: ts.xpt exists but lacks TSPARMCD = 'SSTDTC'

Impact: Code 1734 rejection

Solution: Add a row to ts.xpt:

STUDYID = 'PROTO-001'

DOMAIN = 'TS'

TSPARMCD = 'SSTDTC'

TSVAL = '2018-03-15'

Scenario 2: The Case-Sensitive Study ID Mismatch

Problem: STF Study ID = 'PROTO001' but ts.xpt has STUDYID = 'Proto001'

Impact: Code 1738 warning (Medium severity)

Solution: Update ALL datasets to use exact matching case: 'PROTO001'

Scenario 3: The Wrong File Tag Error

Problem: STF file-tag = 'data-listing' for dm.xpt

Impact: Code 1735 rejection

Solution: Update STF XML to <file-tag>data-tabulation-dataset-sdtm</file-tag>

Scenario 4: The Missing Define.xml

Problem: All datasets present but define.xml is missing

Impact: Code 1736 rejection

Solution: Generate define.xml using Pinnacle 21 or equivalent validator

Best Practices for Organizations

1. Implement Automated Pre-Validation

• Use FDA's eCTD Validator tool before every submission

• Integrate validation into your CI/CD pipeline

• Run Pinnacle 21 Community checks on all datasets

2. Establish Clear SOPs

• Document study start date determination process

• Maintain a master list of valid file-tags

• Create templates for simplified TS datasets

3. Cross-Train Teams

• Programmers should understand eCTD structure basics

• Regulatory staff should understand CDISC fundamentals

• Conduct quarterly TRC training sessions

4. Maintain Version Control

• Track which datasets are 'new' vs 'replace' in each sequence

• Document all STF modifications

• Use Git or equivalent for submission package management

Study Start Date Determination Guidelines

The study start date is the earlier of:

• For clinical studies: Date first subject signed informed consent

• For clinical studies (no enrollment): Date protocol was finalized

• For nonclinical studies: Date first animal was dosed

• For in vitro studies: Date first assay was conducted

Note: This determination is critical because it defines whether a study falls under standardized data requirements based on the applicability dates in the Data Standards Catalog.

eCTD Lifecycle Operators Reference

Conclusion

The FDA Technical Rejection Criteria represent a fundamental quality control mechanism in the regulatory submission process. Understanding these requirements and implementing robust quality checks can prevent costly delays caused by technical rejections at the Electronic Submissions Gateway. The four primary High-severity codes (1789, 1734, 1735, 1736) operate sequentially, meaning that correcting issues early in the validation chain is essential for successful submission acceptance.

Organizations should invest in automated validation tools, establish clear SOPs for study ID management and eCTD lifecycle operations, and maintain close attention to the Study Data Technical Conformance Guide and Data Standards Catalog for the most current requirements. Regular training of programming staff on these criteria and their practical implications will minimize technical rejection risks and accelerate the regulatory review timeline.

References

1. U.S. Food and Drug Administration (2025). Specifications for eCTD Validation Criteria, Version 4.5. Retrieved from https://www.fda.gov/media/87056/download

2. U.S. Food and Drug Administration (2021). Study Data Technical Conformance Guide. Retrieved from https://www.fda.gov/industry/study-data-standards-resources/study-data-submission-cder-and-cber

3. U.S. Food and Drug Administration (2022). Providing Regulatory Submissions in Electronic Format — Standardized Study Data: Guidance for Industry. Retrieved from https://www.fda.gov/regulatory-information/search-fda-guidance-documents

4. U.S. Food and Drug Administration (2020). Providing Regulatory Submissions in Electronic Format — Submissions Under Section 745A(a) of the FD&C Act. Retrieved from https://www.fda.gov/regulatory-information/search-fda-guidance-documents