eCTD Structure Explained: Complete Guide to Modules, Folders, and XML Backbone

The eCTD structure is the standardized organizational framework for Electronic Common Technical Document (eCTD) submissions, consisting of five hierarchical modules, an XML backbone for navigation, and a defined folder hierarchy that regulatory agencies worldwide require for drug and biologic applications. The eCTD structure ensures consistent presentation of regulatory data across FDA, EMA, Health Canada, and 60+ other agencies.

Understanding the eCTD structure is fundamental to successful regulatory submissions. A submission that follows perfect formatting but violates structural requirements will be rejected at the gateway. Conversely, mastering the eCTD structure enables faster assembly, easier amendments, and smoother regulatory review.

In this guide, you'll learn:

• The complete breakdown of eCTD modules 1, 2, 3, 4, and 5 with their specific purposes
• How the XML backbone creates navigable submission structure
• The exact folder hierarchy and naming conventions required by ICH M8
• Regional structural differences between FDA, EMA, and other agencies
• How the CTD format evolved into the modern eCTD structure

What Is eCTD Structure?

The eCTD structure is the standardized organizational architecture that defines how pharmaceutical regulatory submissions are assembled, formatted, and presented to health authorities. This structure encompasses three interconnected layers: the five-module content organization, the XML backbone that provides navigation, and the file system hierarchy that contains all documents.

Key characteristics of eCTD structure:

• Five-module organization based on ICH M4 Common Technical Document
• XML backbone files (index.xml, regional.xml) providing navigable structure
• Standardized folder naming following ICH M8 specifications
• Leaf-level document organization within each module
• Lifecycle management through sequence numbering
• Harmonized content structure (Modules 2-5) with regional variation (Module 1)

The eCTD structure serves two critical purposes: it provides regulatory reviewers with a predictable, navigable organization for efficient assessment, and it enables sponsors to manage complex submissions with thousands of documents across global markets.

The CTD Format: Foundation of eCTD Structure

The CTD format (Common Technical Document format) is the organizational blueprint that the eCTD structure implements electronically. Understanding the CTD format is essential because the eCTD directly mirrors its content organization.

History of the CTD Format

The CTD format emerged from the International Council for Harmonisation (ICH) effort to standardize regulatory submissions across regions:

The CTD Triangle

The CTD triangle is a visual representation of how submission content flows from detailed data to summarized overviews:

This structure enables reviewers to start with summaries (Module 2) and drill down into supporting detail (Modules 3, 4, 5) as needed.

CTD Format vs eCTD Structure

Complete eCTD Modules Breakdown

The eCTD structure organizes all submission content into five modules. Understanding each module's purpose and content is essential for proper eCTD structure implementation.

eCTD Module Overview Table

Module 1: Administrative Information and Prescribing Information

Module 1 is the only region-specific module in the eCTD structure. Its organization differs between FDA, EMA, Health Canada, and other regulatory authorities.

Module 1 Purpose:

• Contains all administrative documents required by the specific regulatory authority
• Houses product labeling in the regional format
• Includes regulatory correspondence and forms
• Provides region-specific information not included in harmonized modules

FDA Module 1 Structure:

EMA Module 1 Structure:

Module 2: Common Technical Document Summaries

Module 2 provides the summaries and overviews that reviewers read first. This module synthesizes all data from Modules 3, 4, and 5 into accessible narrative form.

Module 2 Structure:

Module 2.3 Quality Overall Summary Subsections:

Module 3: Quality (Chemistry, Manufacturing, and Controls)

Module 3 contains the complete Chemistry, Manufacturing, and Controls (CMC) data for both drug substance and drug product. This module follows the ICH M4Q structure.

Module 3 Structure:

Module 4: Nonclinical Study Reports

Module 4 contains all nonclinical (animal and in vitro) studies following the ICH M4S structure. This module organizes pharmacology, pharmacokinetics, and toxicology data.

Module 4 Structure:

Module 5: Clinical Study Reports

Module 5 is typically the largest module, containing all clinical study reports and supporting clinical data following ICH E3 format requirements.

Module 5 Structure:

eCTD Folder Hierarchy and File Organization

The eCTD structure defines exact folder naming conventions and file organization that must be followed precisely. This folder hierarchy enables automated validation and consistent navigation.

Root Level Folder Structure

The eCTD uses sequence folders at the root level to track submission lifecycle:

Module Folder Naming Conventions

Each module follows specific folder naming rules defined by ICH M8:

Module 1 Folder Structure (FDA Example):

Module 2 Folder Structure:

Module 3 Folder Structure:

File Naming Requirements

The eCTD structure enforces strict file naming conventions:

File Naming Comparison:

eCTD XML Backbone Structure

The XML backbone is the navigation layer of the eCTD structure. It creates the hyperlinked table of contents that enables reviewers to navigate through thousands of documents.

XML Backbone Components

Index.xml Structure

The index.xml file serves as the entry point for the entire submission:

Leaf Elements

Leaves are the fundamental building blocks of the eCTD XML structure. Each leaf represents one document:

Leaf Attributes:

Lifecycle Operations:

MD5 Checksum Verification

Every document in the eCTD structure must have a valid MD5 checksum:

Checksum Generation Process:

1. Calculate MD5 hash of the PDF file
2. Record 32-character hexadecimal string in leaf element
3. Verify checksum after any file operation
4. Regenerate if file is modified

Regional eCTD Structure Differences

While Modules 2-5 follow harmonized ICH structure globally, significant differences exist in Module 1 organization and regional XML requirements.

FDA vs EMA vs Health Canada Structure Comparison

Regional Module 1 Numbering

FDA Module 1 Numbering:

EMA Module 1 Numbering:

eCTD v4.0 Structural Changes

eCTD v4.0 introduces significant structural enhancements:

eCTD Structure Best Practices

Following eCTD structure best practices ensures submission success and efficient regulatory review.

Document Organization Best Practices

1. Plan structure early - Map your documents to eCTD sections during development
2. Use consistent naming - Establish file naming conventions before authoring
3. Maintain granularity - Keep documents at appropriate sizes (5-50 MB typical)
4. Group related content - Use the structure logically, not just technically
5. Track versions - Document which version corresponds to which leaf ID

Cross-Reference Best Practices

Lifecycle Management Best Practices

Sequence Strategy:

• Use sequence 0000 for initial submission
• Increment sequences chronologically (0001, 0002...)
• Never skip sequence numbers
• Document sequence purpose in cover letters

Leaf Operations Strategy:

• Use new only for truly new documents
• Use replace for updated versions (maintains audit trail)
• Use delete sparingly (may raise questions)
• Use append only when adding to existing content

Key Takeaways

Next Steps

Understanding the eCTD structure is essential for regulatory submission success, but implementing it correctly across thousands of documents requires systematic validation. Structural errors cause gateway rejections and delay your drug approval timeline.

Need help validating your eCTD structure? Assyro's AI-powered platform validates your submission against all ICH M8 structural requirements, checking folder hierarchy, file naming, XML backbone integrity, and cross-module consistency before you submit. Catch structural errors before they become gateway rejections.

See How Assyro Validates eCTD Structure - Request a Demo

Sources