Published on 21/12/2025
Breaking Down the Structure of an eCTD Submission for Regulatory Filing
Introduction to the eCTD Format
The electronic Common Technical Document (eCTD) is the globally accepted format for submitting regulatory dossiers to health authorities such as the U.S. FDA, EMA, Health Canada, and PMDA. It provides a standardized structure that ensures consistent presentation and navigation of complex documents for reviewers.
Developed by the International Council for Harmonisation (ICH), the eCTD format is designed to replace paper-based submissions, facilitating efficient review and lifecycle management. At its core, eCTD is an XML-based folder structure that links content across five modules using a defined backbone.
The Five Modules of the eCTD
eCTD submissions are divided into five modules, each serving a specific regulatory purpose:
- Module 1: Regional administrative information (e.g., cover letters, application forms)
- Module 2: Summaries and overviews (nonclinical and clinical)
- Module 3: Quality/CMC information
- Module 4: Nonclinical study reports (pharmacology, toxicology)
- Module 5: Clinical study reports and related data
Folder Structure and XML Backbone
Each eCTD submission is organized using a hierarchical folder structure, supported by an XML backbone file (index.xml). This backbone provides metadata and hyperlinks that allow regulators to navigate the submission.
The general folder layout looks like this:
root/
│
├── m1/
├── m2/
├── m3/
├── m4/
├── m5/
├── util/
└── index.xml
The util folder contains style sheets and DTD files. The index.xml file is the backbone of the eCTD, dictating the presentation of documents and enabling lifecycle operations like replace, delete, and append.
Granularity and Document Placement
The concept of granularity refers to how content is grouped and split into files. Regulatory agencies have specific recommendations on granularity. For example, each clinical study report (CSR) should be submitted as a separate PDF, while modules like Quality Overall Summary (QOS) may remain a single file.
| Document | Recommended Granularity |
|---|---|
| Clinical Study Report | One CSR per file |
| CMC Stability Data | Split by study or lot number |
| Module 2 Summaries | Grouped by section (e.g., 2.4, 2.5) |
Continue with Lifecycle Management and Submission Strategies
Lifecycle Management and eCTD Sequences
One of the biggest advantages of eCTD over paper submissions is lifecycle management. Each submission is a “sequence” with a unique number (e.g., 0000, 0001, 0002) indicating its position in the application lifecycle.
Lifecycle operators include:
- New: Adds a new document
- Replace: Updates an existing document
- Delete: Removes a document from view
For example, if a clinical protocol was submitted in sequence 0000 and needs revision, a replacement can be submitted in sequence 0001 using the “replace” operation.
Best Practices in Folder Naming and Metadata
Folder naming must align with the official CTD table of contents. Each file must be correctly tagged using controlled vocabulary to enable automation and navigation. Naming should reflect:
- CTD location (e.g., 3.2.P.5.1)
- Document type (e.g., validation report)
- Version control (e.g., v1, v2)
Metadata embedded in the XML is just as critical as the content itself. Errors in metadata can lead to technical rejection by health authorities.
Tools Used in eCTD Compilation and Validation
Various commercial tools are available to support eCTD authoring, publishing, and validation. Some of the commonly used software includes:
- Extedo eCTDmanager
- Lorenz docuBridge
- Phlexglobal’s PhlexSubmission
- GlobalSubmit
These tools help generate the XML backbone, enforce validation criteria, and simulate the reviewer’s navigation experience.
Technical Rejection Criteria and Prevention
Regulatory authorities like the FDA and EMA conduct technical validation before scientific review. Submissions may be rejected for:
- Improper file formats (e.g., Word instead of PDF)
- Corrupt XML backbone
- Improper lifecycle operation
- Missing required documents
Pre-validation using tools like Lorenz Validator or FDA’s ESG gateway test environment helps avoid such setbacks.
Regional Differences in Module 1
While Modules 2–5 follow ICH guidelines, Module 1 is tailored to regional authority needs. For example:
- FDA: Requires Form 356h, REMS, SBRA
- EMA: Includes cover letter, application form, product information
- Health Canada: Requests Canadian Module 1 TOC XML
Detailed instructions are provided by each agency in their eCTD regional specification guidance.
eCTD Versioning and the Transition to v4.0
The current standard (eCTD v3.2.2) is being phased out in favor of eCTD v4.0, which offers improved two-way communication, reduced sequence numbers, and enhanced metadata tagging. Agencies like the EMA and FDA have begun pilots for v4.0 adoption.
For up-to-date info, refer to the EU Clinical Trials Register or FDA’s eCTD NextGen documentation portals.
Conclusion: A Well-Structured eCTD Enhances Approval Efficiency
A deep understanding of the eCTD structure is essential for regulatory teams aiming to streamline submissions and minimize technical review delays. By mastering module layout, lifecycle principles, granularity, and regional requirements, sponsors can increase the likelihood of successful, first-pass regulatory approval.