Home / Regulatory Submissions / Electronic Common Technical Document (eCTD): Definition, Modules, Technical Specifications, Submission, and Guidelines

Electronic Common Technical Document (eCTD): Definition, Modules, Technical Specifications, Submission, and Guidelines

Published: March 12, 2026

The electronic Common Technical Document (eCTD) is a standardized, electronic format used to submit regulatory information about medicinal products to health authorities. The eCTD has been developed under the guidelines of the International Council for Harmonisation (ICH). The electronic common technical document is based on the Common Technical Document (CTD) structure and utilizes an XML backbone to manage the submission’s organization, metadata, navigation, and lifecycle tracking. The primary purpose of eCTD is to enhance regulatory review efficiency and dossier lifecycle management.

The eCTD is structured into five modules, as listed below.

Module 1 – Administrative and Prescribing Information: Module 1 includes region-specific forms, labeling information, and administrative documents.
Module 2 – CTD Summaries: Module 2 consists of summarized overviews of quality, nonclinical, and clinical data.
Module 3 – Quality: Module 3 or Chemistry, Manufacturing, and Controls (CMC) provides a comprehensive overview of active substance and drug product quality data.
Module 4 – Nonclinical Study Reports: Module 4 consists of non-clinical study reports, including pharmacological, pharmacokinetic, and toxicological information.
Module 5 – Clinical Study Reports: Module 5 includes the clinical study reports, which present the efficacy and safety data from human trials.

The technical specifications for eCTD are defined by ICH and regional regulatory authorities and include standardized submission content and folder structure, XML backbone, controlled vocabularies, PDF and other file formatting, checksums to ensure file integrity, hyperlinking and granularity requirements, and lifecycle management operations.

The eCTD submission process comprises seven main steps, including document collection and preparation, compilation of CTD modules, eCTD publishing, eCTD validation, submission to authorities via gateways, acknowledgment of eCTD receipt, and ongoing lifecycle management.

Global guidelines for eCTD are based on ICH M4, which defines the regulatory content structure, and ICH M8, which outlines the technical specifications for regulatory submissions. Regional specifications, such as those from the FDA, EMA, and PMDA, define module 1 requirements and local validation rules.

Challenges in implementing eCTD include software cost and resource limitations, lack of trained personnel, and technical complexity.

SimplerQMS is an electronic Quality Management System (eQMS) that helps pharmaceutical companies in their eCTD submissions by streamlining quality processes, such as document control, training management, and change control.

What is an Electronic Common Technical Document (eCTD)?

The electronic Common Technical Document (eCTD) is the standardized electronic format for submitting regulatory information to health authorities for medicinal products. The Common Technical Document (CTD) defines the harmonized structure of modules, sections, and documents agreed by the International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH). The electronic common technical document enables applicants to submit the CTD electronically to regulators.

The primary purpose of the eCTD is regulatory harmonization and efficiency. The eCTD supports electronic receipt, review, lifecycle management, and long-term archiving of regulatory submissions.

The electronic common technical document addresses limitations of paper-based and non-standard electronic submissions. The eCTD reduces review timelines by enabling rapid navigation and structured access to data, while lowering operational costs by removing printing, binding, and physical shipping of the regulatory dossier.

The electronic common technical document relies on a modular CTD structure connected by an XML backbone. The CTD modules define the organization of regulatory content, while the XML backbone defines document relationships and navigation rules. The combination of modular content and XML metadata enables the structured review of regulatory submissions.

The electronic common technical document is accepted or mandated by many regulatory authorities worldwide, including those that are members of ICH. Regulatory authorities using eCTD include the U.S. Food and Drug Administration (FDA), European Union national competent authorities, the European Medicines Agency (EMA), Health Canada, the National Medical Products Administration (NMPA) in China, and the Ministry of Health, Labour and Welfare (MHLW) with the Pharmaceuticals and Medical Devices Agency (PMDA) in Japan.

The eCTD format supports initial submissions, amendments, supplements, or variations, and periodic reports submitted to health authorities throughout the product lifecycle. In the US, the eCTD format is used for Investigational New Drug (IND) applications, New Drug Applications (NDAs), Abbreviated New Drug Applications (ANDAs), Biologics License Applications (BLAs), and Master Files, which are submitted to the FDA’s Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER). In the EU, the eCTD format is mandatory for all centralized, decentralized, and mutual recognition procedures, including New Marketing Authorization Applications (MAAs), variations, renewals, Periodic Safety Update Reports (PSURs), Active Substance Master Files (ASMFs), and Plasma Master Files (PMFs).

Which is the Latest Version of eCTD?

The latest eCTD version is 4.0, which is currently at Step 5 of the ICH process and is available for regulatory implementation. Global implementation of version 4.0 remains gradual. Many regulatory authorities continue to receive submissions in eCTD version 3.2.2 until full regional adoption is completed. The eCTD v3.2.2 remains the accepted format, where eCTD v4.0 is not yet supported.

The main changes introduced in eCTD v4.0 are the single submission unit message, the context of use, the keywords, the context group, and document reuse. The single submission unit message uses the submissionunit.xml file to contain all information required to describe a complete regulatory sequence. The context of use is introduced to describe how documents are used within CTD headings, together with associated keywords. The context of use, combined with keywords, forms the context group. The context group defines how one or more documents are associated within the CTD structure according to ICH M4 instructions.

The eCTD v4.0 improves lifecycle management by allowing lifecycle operations to be applied at the context group level, enabling one document to replace multiple documents, or multiple documents to replace a single document, provided they are under the same context group. The eCTD v4.0 also enables document reuse across regulatory applications through the use of globally unique document identifiers.

What Are the Benefits of Implementing eCTD?

The key benefits of implementing eCTD are listed below.

Regulatory Compliance: The electronic common technical document is mandatory for regulatory submissions in major pharmaceutical markets, including the European Union, the United States, and Japan.
Global Harmonization: The eCTD provides a harmonized structure for Modules 2–5 across regions, with region-specific requirements limited to Module 1.
Operational Efficiency: The eCTD removes paper-based submissions and supports searchable electronic review, leading to faster regulatory review cycles and shorter time-to-market.
Effective Lifecycle Management: The electronic common technical document supports controlled versioning and structured tracking of changes across all submission sequences.
Quality and Submission Integrity: The electronic common technical document enforces strict technical specifications that reduce submission errors, allowing regulators to focus on scientific evaluation rather than administrative corrections.

What Are the Key Differences Between eCTD and CTD?

The key differences between eCTD and CTD relate to purpose and core components. The purpose of CTD is to define a harmonized structure for a regulatory dossier, to ensure consistency and completeness for reviewers. The purpose of eCTD is to define the technical format used to submit that dossier electronically to regulatory authorities, to standardize electronic submissions and support efficient regulatory review, tracking, and lifecycle management.

The core components of the Common Technical Document (CTD) are the five modules that organize quality, nonclinical, and clinical regulatory documentation. The core components of eCTD include the content organization plus a technical framework consisting of an XML backbone, defined PDF specifications, and lifecycle management operations.

What Is the Difference Between eCTD and NeeS (Non-eCTD)?

The difference between eCTD and NeeS (non-eCTD electronic submission) is primarily technical, concerning XML backbone, validation mechanisms, and lifecycle management. The electronic common technical document uses an XML backbone to define dossier structure, navigation, and relationships between documents. NeeS lacks an XML backbone and relies on a predefined folder structure and PDF-based table of contents, bookmarks, and hyperlinks. Additionally, eCTD supports submission validation and file integrity controls, including the use of checksums that verify files are transmitted, received, and maintained without alteration. NeeS relies largely on manual review for submission integrity and does not provide standardized validation mechanisms such as checksums.

The eCTD supports lifecycle management through defined operations that allow documents to be added, replaced, appended, or deleted within the same dossier. The eCTD serves as the globally dominant format for electronic regulatory submissions. NeeS functions as a simpler transitional format and is being phased out across most major regulatory markets.

What are the 5 Modules of eCTD?

The CTD is organized into five modules that define the eCTD structure used for regulatory submissions.

The five modules of eCTD are given below.

eCTD Module 1 – Administrative Information and Prescribing Information: eCTD module 1 contains region-specific administrative documents and product information, such as application forms, proposed labelling, and other regional data.
eCTD Module 2 – Common Technical Document Summaries: Module 2 provides summaries and overviews of quality, nonclinical, and clinical data.
eCTD Module 3 – Quality: Module 3 contains detailed information on drug substance and drug product, covering manufacturing processes, specifications, analytical methods, and stability data.
eCTD Module 4 – Nonclinical Study Reports: eCTD module 4 includes non-clinical study reports, supporting the assessment of nonclinical safety.
eCTD Module 5 – Clinical Study Reports: Module 5 contains clinical reports, providing information on medicinal product safety and efficacy in humans.

eCTD Module 1 – Administrative Information and Prescribing Information

The eCTD module 1 is the region-specific, administrative, and prescribing information module of a dossier. Module 1 includes administrative, legal, and product information that is required by regulatory authorities for the evaluation of a medicinal product submission. The eCTD module 1 content is not harmonized and varies according to national or regional regulatory requirements.

The typical items included in the eCTD module 1 are the following.

Application and Administrative Forms: Module 1 contains application forms, cover letters, and procedural documents required to initiate regulatory review.
Product Information and Labeling: Module 1 includes prescribing information, summaries of product characteristics, package leaflets, and labeling for the region.
Regulatory Correspondence: eCTD module 1 may contain official correspondence between the applicant and the regulatory authority, including commitments and responses.
Regional Certifications and Declarations: Module 1 contains region-specific certificates, legal statements, and compliance declarations.

The eCTD module 1 varies by region because regulatory authorities define their own requirements. For example, the EU module 1 must contain an environmental risk assessment, and the FDA module 1 must contain promotional materials.

Module 1’s purpose is to provide the legal and administrative foundation for the submission. The importance of the eCTD module 1 lies in reducing rejection risks due to insufficient administrative information. The eCTD module 1 deficiencies may delay approval regardless of the scientific information provided in other modules.

The eCTD module 1 documents are typically submitted in the same PDF format as the other modules, following regional and ICH technical specifications. The eCTD module 1 content follows defined folder structures and metadata rules within the eCTD structure. The name of the module 1 folder in eCTD format is defined by the regulatory authorities. In Europe, module 1 is named under the form m1-countrycode for national or decentralized submissions, or m1-ema for centralized submissions.

eCTD Module 2 – Common Technical Document Summaries

The eCTD module 2 is the summaries module of a regulatory submission. The eCTD module 2 provides consolidated summaries of the detailed data presented in modules 3, 4, and 5.

The sections included in the eCTD module 2 are given below.

2.2 CTD Introduction: The eCTD module 2.2 provides a general introduction to the pharmaceutical, including its pharmacologic class, mechanism of action, and proposed clinical use.
2.3 Quality Overall Summary (QOS): The eCTD module 2.3 summarizes drug substance and drug product quality data, appendices, and regional information. QOS normally should not exceed 40 pages of text, excluding tables and figures.
2.4 Nonclinical Overview: The eCTD Module 2.4 presents an integrated assessment of nonclinical pharmacology, pharmacokinetics, and toxicology evaluation of the product. In general, the nonclinical overview should not exceed 30 pages.
2.5 Clinical Overview: The eCTD module 2.5 presents the strengths and limitations of the development program and study results, analyzes the benefits and risks of the medicinal product in its intended use, and describes how the study results support critical parts of the prescribing information. The clinical overview should generally be about 30 pages.
2.6 Nonclinical Written and Tabulated Summaries: The eCTD module 2.6 presents detailed written summaries and tables supporting the nonclinical overview. The total length of the three nonclinical written summaries should not exceed 100-150 pages.
2.7 Clinical Summary: The eCTD Module 2.7 provides detailed and factual summaries of dossier clinical information, including information provided in clinical study reports, information obtained from any meta-analyses or other cross-study analyses, and postmarketing data for products that have been marketed in other regions. Clinical summary will usually be in the range of 50 to 400 pages.

The eCTD module 2 excludes section 2.1 for the Common Technical Document Table of Contents for Modules 2–5, since the CTD table of contents applies only to paper submissions.

The eCTD module 2’s purpose is to provide a consolidated overview of product quality, safety, and efficacy to regulatory assessors. Module 2 is important because it enables regulators to assess scientific rationale before reviewing detailed modules, facilitating efficient review.

The eCTD Module 2 documents primarily use searchable PDF files, including hyperlinks, and all files are integrated into the eCTD XML backbone for metadata and technical validation. The eCTD v3.2.2 format requires the module 2 folder to be named m2 and have subfolders for 22-intro, 23-qos, 24-nonclin-over, 25-clin-over, 26-nonclin-sum, and 27-clin-sum. In the eCTD v4.0 format, only the m2 folder is necessary, with content organization controlled through metadata rather than fixed subfolders.

eCTD Module 3 – Quality

The eCTD module 3 defines the quality section of a regulatory submission and is commonly referred to as the Chemistry, Manufacturing, and Controls (CMC) module. Module 3 contains comprehensive quality data describing drug substance and drug product development, manufacture, and control. The body of data of the CTD module 3 is included in module 3.2.

The following sections are included in the eCTD module 3.

3.2.S Drug Substance: Module 3.2.S describes the active pharmaceutical ingredient (API), including general information, manufacture, characterization, controls, container closure system, and stability.
3.2.P Drug Product: Module 3.2.P describes the finished dosage form, including formulation, development, manufacturing process, control of excipients and drug product, container closure system, and stability.
3.2. Appendices: eCTD module 3.2. A includes supporting information such as facilities, adventitious agent safety evaluation, and excipient data.
3.2.R Regional Information: eCTD Module 3.2.R contains additional region-specific quality data defined by the regulatory authority. For example, in the U.S., executed batch records are required, and in the EU, a process validation scheme for the drug product is required.
3.3 Literature References: eCTD Module 3.3 provides bibliographic references that support quality-related data.

The eCTD Module 3 purpose is to provide complete CMC data that assures product quality, reproducibility, and regulatory compliance throughout the lifecycle. The data provided in module 3 support the medicinal product’s formula, manufacturing, analytical processes, specifications, and shelf-life. The eCTD Module 3 is important because it provides proof of consistent product quality.

The eCTD format requires the module folder name m3. The eCTD v4.0 structure requires folders named 32-app, 32-sub, 32-prod, 32-reg, and 33-lit. Additional folders should be used to separate content with identical names, such as multiple active substances. The eCTD v3.2.2 structure requires deeper subfolder organization, including 32-body-data and specific folders such as 32p56-justif-spec for detailed content organization.

eCTD Module 4 – Nonclinical Study Reports

The eCTD module 4 contains a collection of detailed nonclinical study reports that provide the scientific evidence for a drug’s safety profile, corresponding to the summarized data in module 2. The nonclinical study reports are included in section 4.2 of the common technical document.

The following sections are the key sections of the eCTD module 4.

4.2.1 Pharmacology: eCTD module 4.2.1 includes studies on primary pharmacodynamics, secondary pharmacodynamics, safety pharmacology, and pharmacodynamic drug interactions.
4.2.2 Pharmacokinetics: eCTD module 4.2.2 includes analytical methods and validation reports, absorption, distribution, metabolism, excretion studies, and pharmacokinetic drug interactions.
4.2.3 Toxicology: eCTD module 4.2.3 includes single-dose and repeat-dose toxicity, genotoxicity, carcinogenicity, reproductive and developmental toxicity, and local tolerance studies.
4.3 Literature References: eCTD module 4.3 includes bibliographic references supporting nonclinical data.

Module 4’s purpose is to establish the scientific rationale for non-clinical safety and support further clinical trials on humans. The importance of the eCTD module 4 lies in providing complete study data for regulatory assessment.

The eCTD format requires the module folder name m4. The primary document format is searchable PDFs. The eCTD v4.0 format necessary folders are 421-phm, 422-pk, 423-tox, and 43-lit. The eCTD v3.2.2 format requires different necessary folders, including a higher-level folder 42-stud-rep with additional subfolders, such as 4214-pd-drug-interact. The module 4 folder structure allows additional folders to organize study files, including multiple files with the same name. Study-level folders typically use the study identifier as the folder name. Regional and module 1 implementation guides may define additional structural requirements.

eCTD Module 5 – Clinical Study Reports

The eCTD module 5 is the section of the dossier dedicated to clinical study reports and contains complete reports of human studies that demonstrate drug safety and efficacy. Module 5 presents the full clinical evidence that supports the risk-benefit profile of the medicinal product. The detailed clinical study reports are located in module 5.3 of the CTD.

The sections below are included in the eCTD module 5.

5.2 Tabular Listing of All Clinical Studies: Module 5.2 provides a structured overview of all clinical studies included in the submission.
5.3.1 Reports of Biopharmaceutic Studies: eCTD module 5.3.1 includes bioavailability, bioequivalence, and in vivo–in vitro correlation studies, and reports of bioanalytical and analytical methods.
5.3.2 Reports of Studies Pertinent to Pharmacokinetics Using Human Biomaterials: eCTD module 5.3.2 includes plasma-protein binding studies, hepatic metabolism and drug Interaction studies, and studies using human biomaterials.
5.3.3 Reports of Human Pharmacokinetic Studies: eCTD module 5.3.3 includes clinical pharmacokinetic studies.
5.3.4 Reports of Human Pharmacodynamic Studies: eCTD module 5.3.4 includes studies evaluating pharmacodynamic effects on healthy subjects and patients.
5.3.5 Reports of Efficacy and Safety Studies: Module 5.3.5 includes clinical trials assessing therapeutic efficacy and safety.
5.3.6 Reports of Postmarketing Experience: Module 5.3.6 includes post-authorization safety and effectiveness data where applicable.
5.3.7 Case Report Forms and Individual Patient Listings: Module 5.3.7 includes case report forms and patient-level data listings.
5.4 Literature References: eCTD Module 5.4 includes bibliographic references supporting clinical data.

The eCTD module 5’s purpose is to provide detailed clinical evidence for the efficacy and safety of the drug product. The eCTD Module 5 supports regulatory decisions on indication, dosing, and labeling. Module 5 is important because regulatory authorities rely on it to confirm efficacy, safety, and prescribing information.

The eCTD format requires the module folder name m5. The eCTD v4.0 structure includes as necessary the folders 531-biopharm, 532-pkbiomat, 533-humanpk, 534-pd, 535-eff-safe, 536-pms, 537-listing, and 54-lit. The eCTD module 5 folder structure supports additional folders to organize study files and manage identical file names. Study-level folders typically use study identifier numbers. The eCTD v3.2.2 structure uses higher and lower-level folders. Regional and module 1 implementation guides may define additional requirements.

What Are the Technical Specifications for eCTD?

The eCTD technical specifications define the mandatory technical rules that govern the structure, validation, and transmission rules of an electronic common technical document. The eCTD technical specifications ensure consistent electronic submissions that regulatory authorities can efficiently review.

The eCTD technical specifications are defined by ICH guidelines and regional implementation requirements. The ICH eCTD specification has been developed by the ICH M2 expert working group and is maintained by the M8 expert working group. Regional authorities publish any additional requirements, typically for module 1 of eCTD.

The eCTD technical backbone consists of structured content, metadata, and lifecycle rules. The technical backbone combines standardized folder structures, XML metadata files, controlled vocabularies, and defined lifecycle operations to manage submissions across sequences.

The core technical elements required for eCTD compliance include the following components.

Submission Contents, Folder, and File Structure: The eCTD requires predefined module folders, specific naming, and hierarchical organization of documents.
XML Backbone: The eCTD XML backbone defines metadata, document relationships, and organization, navigation, and lifecycle operations for each sequence.
Controlled Vocabulary: The eCTD uses authority-defined controlled terms to enable interoperability, establishing clear, unambiguous communications between systems sending and receiving XML messages.
PDF and Other File Format Requirements: The eCTD mandates searchable PDF files with appropriate headers and footers, and limits formats to ensure document readability throughout the lifecycle.
Lifecycle Management: The eCTD applies lifecycle operators such as new, replace, delete, and append to track document changes across sequences. The support for the “append” operation has been removed from the eCTD v4.0 specification.
Checksum and File Integrity: The eCTD uses MD5 checksums to verify that submitted files remain intact and unaltered during transmission and storage in the regulatory authority’s archive.
Hyperlinking Requirements: The eCTD suggests hyperlinking to support document navigation and cross-referencing.
Granularity Requirements: The eCTD defines document granularity to ensure sections are submitted at an appropriate level for review and lifecycle control.
Sequence Numbering: The eCTD uses sequential numbering to uniquely identify each submission sequence within the product lifecycle. The numbering format changes from eCTD version 3.2.2 to version 4.0.
Regional Specifications: The eCTD applies region-specific technical rules that supplement ICH guidance and govern local requirements.

Submission Contents, Folder, and File Structure

Submission contents, folder, and file structure are standardized and specify how regulatory information must be arranged across eCTD modules. Submission contents, folder, and file structure specifications ensure that regulators receive submissions in a consistent, predictable, machine-readable, and review-ready format.

The key regulatory expectations for submission contents, folder, and file structure are listed below.

Standardized Module Folders: Submission contents, folder, and file structure require fixed top-level module folders named m1 through m5 that reflect the corresponding CTD modular structure.
Defined Subfolder Conventions: Submission contents, folder, and file structure apply ICH and regional naming conventions to subfolders to reflect CTD sections.
Version-Specific Structure Rules: Submission contents, folder, and file structure differ between eCTD v3.2.2 and eCTD v4.0, with v4.0 relying more on metadata than fixed subfolders.
File Naming Rules: Submission structure enforces specific file naming requirements that prohibit special characters and excessive path length.
Regional Implementation Constraints: Submission structure must follow authority-specific implementation guides that may impose additional folder structures or naming rules.

The specified modular structure enables technical validation, navigation, and lifecycle tracking. Submission contents, folder, and file structure allow regulators to locate, review, and manage documents consistently across submission sequences.

XML Backbone

The XML backbone is the core machine-readable control file of an eCTD submission. The XML backbone functions as a structured table of contents that describes each submitted file’s metadata, physical location, lifecycle operation, and placement within the eCTD structure. The XML backbone does not contain regulatory content, but controls how content is interpreted and processed by regulatory systems.

The XML backbone technical requirements vary by eCTD version. In eCTD v3.2.2, the XML backbone is submitted as a single file named index.xml. The index.xml file is placed at the root of each submission sequence number folder, along with the MD5 checksum file, indexmd5.txt. The DTD against which the index.xml is validated should be in the “util” folder for each submission. In eCTD v4.0, the XML backbone is submitted as submissionunit.xml. The submissionunit.xml replaces index.xml, regional XML, and study tagging files, and the util folder is no longer used.

The XML backbone serves multiple critical functions, including enabling navigation, validation, lifecycle management, and regulatory processing of the entire eCTD submission.

Controlled Vocabulary

Controlled vocabulary is the standardized set of terms used to classify, describe, and organize content within an electronic common technical document submission. Controlled vocabulary ensures consistent interpretation of submission metadata and content by regulatory systems.

Controlled vocabulary has been formalized and significantly expanded in eCTD version 4.0. While eCTD v3.2.2 used some predefined terms, v4.0 introduced five comprehensive, version-controlled vocabulary sets, including those specified by ICH, those specified regionally, those specified by HL7, those specified by an external organization, and those that are sender-defined.

The core requirements related to controlled vocabularies are described below.

Version-Specific Vocabulary Sets: Controlled vocabularies are maintained as separate, versioned packages with documented code lists. The vocabulary sets specified by ICH, regional, HL7, and external organizations are published in their respective implementation packages or standards documentation, while sender-defined vocabularies must be documented by the submitting sponsor.
Validation Enforcement: Controlled vocabulary must be applied exactly as specified, and invalid terms trigger technical validation failures.
Metadata Consistency Rules: Controlled vocabulary requires consistent use of the same terms across sequences to support lifecycle management.

Controlled vocabulary enables automated processing, validation, and interoperability by eliminating ambiguity in metadata interpretation and submission classification.

PDF and Other File Format Requirements

PDF and other file format requirements define the acceptable electronic formats for documents submitted within an eCTD. PDF and other file format requirements ensure that submission documents are readable, searchable, archivable, and compatible with regulatory review systems. PDF serves as the primary document format across all eCTD Modules.

The key technical requirements for PDF and other file formats are listed below.

Searchable PDF Requirement: PDF files must be searchable to support efficient regulatory review.
PDF Versioning: PDF files must comply with authority-accepted versions and use PDF formats that ensure long-term archiving.
Font, Page Size, and Margins: PDF and other file format requirements mandate embedded fonts to preserve text appearance and readability across review systems. The print area for pages should fit on a sheet of A4 and letter-sized paper, with a sufficient margin on the left side of each page.
Headers and Footers: PDF is suggested to have an identifier, such as a header or a footer. Even in the eCTD, where there is a significant amount of metadata available to the reviewer, an identifier allows easy identification of the document.
Methods for Creating PDF Documents and Images: PDF and other file format requirements require direct PDF generation from source files rather than scanned images, except where scanning is unavoidable. Documents that are available only in paper should be scanned at sufficient resolution to ensure the pages are legible both on the computer screen and when printed. At the same time, the file size should be limited.
Page Numbering: PDF and other file format requirements require consistent page numbering within documents to support citation and regulatory review.
Security Settings: PDF and other file formats prohibit security features that restrict printing, copying, or searching.

PDF and other file format requirements ensure that regulators can access, review, search, and archive submission content without technical barriers and that the submission documentation will remain readable throughout the lifecycle.

Lifecycle Management

Lifecycle management defines the technical mechanism in an eCTD that controls how documents are tracked when updated across submission sequences. Lifecycle management in eCTD uses XML attributes to identify document status and change history across sequences. Lifecycle management allows sponsors to submit only new or modified content while enabling regulators to maintain a complete, current view of the entire dossier.

The key specifications of lifecycle management are given below.

Lifecycle Operators: Lifecycle management applies defined operators such as new, replace, and delete to control document evolution across sequences.
Version Control Across Sequences: Lifecycle management maintains a complete history of document changes linked to sequence numbers.
eCTD v3.2.2 Lifecycle Rules: Lifecycle management in eCTD v3.2.2 supports operators, including new, replace, append, and delete, with limited replacement flexibility.
eCTD v4.0 Lifecycle Enhancements: Lifecycle management in eCTD v4.0 does not support the append operator, with append actions submitted as “replace”. eCTD v4.0 supports more complex replacements at the context group level, including one document replaced by many or many replaced by one.

Lifecycle management enables regulators to efficiently track the current version of a regulatory submission while maintaining a complete revision history.

Checksum and File Integrity

Checksum and file integrity specify the technical controls used in an eCTD to verify that submission files remain intact and unaltered during transmission, receipt, and long-term archival.

The core specifications for checksums are listed below.

File-Level Checksum Requirement: Checksum and file integrity requirements specify that each individual file in the submission must have an associated checksum value, recorded in the XML backbone.
Algorithm Standard: Checksum and file integrity use the MD5 Message-Digest Algorithm as the standard method for checksum generation and verification in eCTD v.3.2.2. In eCTD v4.0, however, the SHA-256 integrity check algorithm should be applied to obtain a checksum for all files referenced in a document element within a given submission unit.
Version-Specific Placement Rules: Checksum and file integrity follow different folder placement rules in eCTD v3.2.2 and eCTD v4.0, as defined by the applicable implementation guides.
Integrity Verification: Checksum and file integrity allow authorities to compare submitted checksum values with calculated values to confirm file integrity.
Transmission Integrity: Checksum validation occurs at multiple points during submission processing, during packaging by the sponsor, transmission through secure gateways, and upon receipt by regulatory agencies.
Archive Protection: Checksum and file integrity enable regulators to verify that archived files remain unchanged over time.

Checksum and file integrity allow recipients to confirm that the submission content is authentic, complete, and unaltered.

Hyperlinking Requirements

Hyperlinking requirements define the technical rules for creating and maintaining electronic links within and between documents in an electronic common technical document. Hyperlinking improves navigation without compromising technical validation or submission integrity.

The key hyperlinking requirements are listed below.

Internal and Cross-document Hyperlink Rules: Hyperlinking requirements mandate functional links between documents submitted within the same eCTD sequence.
Relative Path Linking: Hyperlinking requirements require the use of relative paths rather than absolute paths to maintain the eCTD submission as a self-contained package.
Link Stability Across Lifecycle: Hyperlinks must remain valid when documents are replaced or updated through lifecycle operations.

Hyperlinking supports efficient regulatory review and navigation by allowing reviewers to move seamlessly between related content while preserving technical integrity.

Granularity Requirements

Granularity requirements describe the required level of document subdivision within an eCTD submission. Granularity requirements specify how submission content must be split into individual documents to align with CTD sections.

Granularity requirements are defined in the ICH M4 guideline. ICH M4 describes the levels in the CTD/eCTD hierarchy at which documents/files should be placed and whether single or multiple documents are appropriate at each point.

Granularity requirements support effective lifecycle management and regulatory review.

Sequence Numbering

Sequence numbering is the ordered identification system used to track each submission within an eCTD lifecycle. Sequence numbering assigns a unique, incrementing number to every eCTD submission sequence to reflect chronological order and lifecycle progression.

Sequence numbering conventions differ between eCTD version 3.2.2 and 4.0. Sequence numbering in eCTD v3.2.2 uses fixed four-digit numeric values such as 0000, 0001, and 0002. Sequence numbering in eCTD v4.0 uses whole numbers without leading zeros. Sequence numbering during the transition from eCTD v3.2.2 to eCTD v4.0 requires the next available whole number. The sequence numbering example shows that the last v3.2.2 sequence numbered “0003” leads to the first v4.0 submission unit numbered “4”, thus maintaining chronological continuity.

Sequence numbering enables dossier lifecycle monitoring and maintains traceability, allowing regulatory authorities to establish submission chronology and effectively track any update to the original file.

Regional Specifications

Regional specifications are technical and procedural rules, published by individual health authorities that supplement the ICH eCTD guidelines. Regional specifications adapt the global eCTD framework to local regulatory, legal, and operational requirements.

Regional specifications define mandatory local rules and may impose additional technical checks beyond ICH requirements. Regional specifications ensure that eCTD submissions comply with local authority systems, review workflows, and legal obligations while remaining aligned with the global eCTD standard.

How Does the eCTD Submission Process Work?

The eCTD submission process is the structured workflow used to prepare and transmit regulatory dossiers to health authorities.

The seven stages of the eCTD submission process are listed below.

Document Collection and Preparation: The eCTD submission process begins with collecting source documents and converting them into compliant electronic formats.
Compilation of the CTD Modules: During the eCTD submission process, the applicant organizes submission content into the five CTD modules according to ICH guidance.
eCTD Publishing (Technical Packaging): During eCTD publishing, specialized software is used to build the eCTD, generating the XML backbone.
Validation (Technical Compliance Check): The eCTD submission process includes automated validation to confirm compliance with ICH and regional technical rules.
Submission to Health Authorities: The eCTD submission process transmits the validated sequence to regulatory authorities through approved electronic gateways.
Acknowledgment of eCTD Receipt: The applicant receives official acknowledgment confirming technical acceptance or identifying submission errors.
Lifecycle Management (Future Submissions): The eCTD submission process continues through subsequent sequences that update, replace, delete, or supplement dossier content across the product and dossier lifecycle.

1. Document Collection and Preparation

Document collection and preparation is the initial stage where all source content for CTD Modules 1–5 is gathered, reviewed, and converted into eCTD-compliant formats.

Document collection and preparation functions as the foundation of the eCTD submission process.

The following activities are part of document collection and preparation.

Authoring and Drafting: Document collection includes creation, review, and finalization of quality, pre-clinical, clinical, and administrative content.
Document Formatting: Document preparation applies eCTD-compliant formatting, including searchable PDFs and page numbering.
Version Control and Management: Proper version control and documentation management ensure only approved and current content is included in the submission.
Regional Adaptation: During the document collection and preparation, the applicant issues regional-specific documentation to meet regulatory requirements.
Metadata Tagging: Titles, headings, and keywords are assigned to the documents to support later XML mapping.

Document collection and preparation are critical for eCTD compliance, since they establish technical and scientific compliance for all modules.

Errors at this stage directly affect later workflow stages and may lead to validation errors, such as non-searchable PDFs.

Common tools used during document collection and preparation include authoring software, PDF tools, and Regulatory Information Management System (RIMS), or document management platforms. The use of centralized repositories with controlled versioning, audit trails, and workflow management streamlines the document collection and preparation process.

Best practices for document collection and preparation include aligning content and structure with ICH M4 guidance and other applicable regulatory requirements from the outset. Early submission planning, efficient tracking of dossier compilation, use of standardized templates, and centralized document storage are beneficial.

Quality checks applied during the document collection and preparation step include verification of content accuracy and confirmation of formatting compliance. The output of that step is a complete and accurate regulatory dossier.

2. Compilation of the CTD Modules

Compilation of the CTD modules is the stage in the eCTD workflow where all prepared documents are organized into the standardized common technical document modular structure.

Compilation of the CTD modules aligns submission content structure with CTD requirements, integrates region-specific module 1 administrative content, and prepares documents for XML backbone mapping during eCTD publishing.

The tasks included in the compilation of the CTD modules step are given below.

Module Hierarchy Mapping: During the compilation of the CTD modules, each document is placed in the correct CTD module based on ICH requirements.
Granularity Verification: At this stage, the applicant verifies that documents are split at the appropriate CTD section level.
Applying Technical Structure for eCTD: During the compilation of the CTD Modules, the applicant applies ICH-compliant folder naming in preparation for eCTD publishing.
Cross-Referencing Setup: The applicant establishes internal and cross-document hyperlinks to improve readability and the review process.

Compilation of the CTD modules is critical for eCTD compliance and authority acceptance. Misplaced documents or incomplete module structures are frequent causes of technical validation failure.

Errors during the compilation of the CTD modules affect the next stages of the workflow. Incorrect granularity or module placement may lead to XML backbone errors during publishing and subsequent submission rejection.

Best practices for compilation of the CTD modules include adhering to ICH M4 submission content requirements and ICH M8 technical structure requirements.

Quality checks during compilation of the CTD modules include verification of correct module placement, confirmation of complete regional module 1 content, compliant document granularity, and accurate alignment between module 2 summaries and data in modules 3 to 5.

The output of compilation of the CTD Modules is a compiled dossier ready for eCTD publishing in accordance with CTD and regional requirements.

3. eCTD Publishing

The eCTD publishing is the automated process that converts a compiled CTD dossier into a technically compliant electronic common technical document submission using specialized software.

The eCTD publishing creates the machine-readable format by generating the XML backbone, applying the defined directory structure, enabling both applicant and health authority systems to validate the submission automatically.

The tasks included in the eCTD publishing step are the following.

XML Backbone Generation: eCTD publishing generates the required XML control file that defines metadata, CTD placement, and lifecycle operations.
Checksum Generation: During the eCTD publishing, a checksum is created for all files to ensure submission integrity during transmission and archival.
Sequence Packaging: eCTD publishing assembles the complete sequence folder with correct numbering, folder structure, and version-specific technical requirements.

Publishing is critical for technical acceptance and functions as the technical gateway to health authority systems. eCTD publishing errors directly impact the following stages. Invalid XML, missing checksums, or incorrect structure lead to technical validation rejection.

Best practices include pre-submission testing, available in some authorities’ test gateways, such as the FDA Electronic Submissions Gateway (ESG), to detect technical issues before submission.

The output of eCTD publishing is a complete eCTD sequence folder.

4. eCTD Validation

Validation is the stage in which an eCTD dossier is systematically examined for technical and structural errors. Validation verifies that the submission complies with ICH and regional technical specifications before transmission to health authorities.

The activities performed during sequence validation are listed below.

Checking File Formats: Validation confirms that PDF and non-PDF files meet accepted format, version, and security requirements.
Verifying Structure and Organization: Validation verifies correct module structure, folder and file naming, granularity, and sequence numbering.
Reviewing Links and Navigation: During validation, hyperlinks and bookmarks are checked for functionality.
Verifying Lifecycle Operators: Validation confirms the correct application of lifecycle operations such as new, replace, or delete.

Validation is critical for regulatory acceptance, since it ensures that there are no technical and administrative errors, allowing regulators to focus on scientific review.

Validation failures require correction before submission is permitted.

Validation is performed by a specialized eCTD validation software aligned with the authority rule sets.

The best practice to perform validation is to use the latest validation criteria published by regulatory authorities. Validation quality checks focus on reviewing the validation report and resolving findings.

The output of eCTD validation is either a technically compliant eCTD sequence or a validation report identifying required corrections.

5. Submission to Health Authorities

Submission to health authorities is the transmission stage where a validated eCTD sequence is electronically delivered to regulatory agencies, typically through secure submission portals.

Submission to health authorities typically requires registration to authority-specific electronic portals. For the submission step, applicants must seek and follow official authority guidance for portal access.

The best practice for the submission step is to strictly adhere to the relevant authority’s instructions, follow submission windows, and technical specifications.

The output of the submission step is a successfully transmitted eCTD sequence delivered to the relevant regulatory authority.

6. Acknowledgment of eCTD Receipt

Acknowledgment of eCTD receipt is the automated response phase following submission, where health authorities confirm technical acceptance or rejection of an eCTD sequence.

Acknowledgment of eCTD receipt formally notifies the applicant that the submission passed the authority’s initial automated checks and has been accepted into the regulatory review system. ΕCTD receipt acknowledgement officially starts the regulatory review clock and is distinct from the internal validation performed by the applicant prior to submission.

Τhe applicant must correct and resubmit the eCTD sequence, resetting the process to eCTD publishing and validation phases, ιf the acknowledgement indicates errors.

Quality checks of eCTD receipt focus on verifying that the acknowledgment references the correct application number and sequence number. Acknowledgment of eCTD receipt confirmation signals readiness for scientific review, leading to regulatory authorization or rejection.

7. Lifecycle Management

Lifecycle management is the ongoing process of submitting amendments, supplements, or variations to an existing eCTD dossier through subsequent sequences.

Proper lifecycle management ensures that regulatory authorities always access the most current product information. Lifecycle management maintains a complete and traceable history of all dossier changes, from initial submission through post-approval variations and renewals.

Dossier lifecycle management links regulatory updates to approved changes, managed through the company’s change control system.

Lifecycle management is critical for compliance, as the dossier updates must align with product lifecycle changes to preserve marketing authorization status. An outdated dossier increases the risk of regulatory action, including product recall or marketing authorization suspension.

Lifecycle management operations use the same technical tools as initial submissions. Lifecycle operations rely on eCTD publishing software, validation tools, and authority submission portals.

The best practice for product and dossier lifecycle management is managing product lifecycle changes within the Quality Management System (QMS). A successful lifecycle management leads to an up-to-date regulatory dossier that reflects the current state of the product.

What Are the Guidelines and Requirements for eCTD?

The eCTD guidelines and requirements define the global and regional rules that control CTD content organization and eCTD technical packaging.

eCTD universal requirements follow ICH M4 and ICH M8. ICH M4 defines the harmonized CTD content organization across modules 2–5. ICH M8 defines the eCTD submission format and separates submission-format specifications from eCTD v4.0 and eCTD v3.2.2.

eCTD regional requirements differ by authority and require direct consultation of the target agency implementation guides for module 1 and regional technical specifications. eCTD applicants need the authority rule set for controlled vocabulary, validation criteria, and module 1 structure.

Below are listed the key regional requirements of major health authorities.

FDA: eCTD regional requirements for the United States follow FDA eCTD module 1 specifications and FDA-controlled technical rules. FDA eCTD module 1 includes 1.1 Forms, 1.2 Cover letters, 1.3 Administrative information, 1.4 References, 1.5 Application status, 1.6 Meetings, 1.7 Fast Track, 1.8 Special protocol assessment request, 1.9 Pediatric administrative information, 1.10 Dispute resolution, 1.11 Information amendment, 1.12 Other correspondence, 1.13 Annual report, 1.14 Labeling, 1.15 Promotional material, 1.16 Risk management plan, 1.17 Postmarketing studies, 1.18 Naming, 1.19 Pre-EUA and EUA, 1.20 General investigational plan for initial IND.
EMA and EU National Competent Authorities: eCTD regional requirements for the European Union follow the EU module 1 eCTD Specification and regional validation rules. Europe eCTD module 1 sections include 1.0 Cover Letter, 1.2 Application Form, 1.3 Product Information, 1.4 Information about the Experts, 1.5 Specific Requirements for Different Types of Applications, 1.6 Environmental Risk Assessment, 1.7 Orphan Market Exclusivity information, 1.8 Pharmacovigilance information, 1.9 Clinical Trials information, 1.10 Pediatrics information, plus Responses to Questions and Additional Data sections defined by EU practice. eCTD EU technical rules reference a util folder in EU workflows, while eCTD v4.0 removes the util folder.
Pharmaceuticals and Medical Devices Agency in Japan: eCTD regional requirements for Japan follow PMDA eCTD implementation guides and Japan regional rules for Module 1. Japan eCTD Module 1 sections include a Cover Letter, a module 1 table of contents, an approval application form, statement of personnel responsible for collection and compilation of data for approval application materials, statement about scanning of paper document, patent information, origin, development and discovery details, foreign countries drug use information, lists of similar products with the same therapeutic category and the same efficacy, a draft package insert, nonproprietary name documents, data for the designation of poisonous/powerful drugs, risk management plan drafts, appendix lists, and review history records such as inquiries and responses.

What Are the Specific Requirements for eCTD 4.0 Transition?

eCTD v4.0 transition requirements focus on authority-specific timelines, forward-compatibility rules, and the mandatory use of v4.0 for all subsequent sequences in a dossier after the first v4.0 submission.

eCTD v4.0 transition timelines remain subject to revision. The estimated timelines are listed below.

ANVISA (Brazil): eCTD v4.0 transition expectations indicate a voluntary phase beginning in 2027, and a mandatory date has not yet been determined in published timelines.
EMA and EU National Competent Authorities: eCTD v4.0 transition expectations describe a staged rollout by procedure type, with voluntary use for CAPs beginning in late 2025, voluntary use expansion to MRP/DCP/National procedures in 2026, and mandatory use for CAPs in 2027.
FDA (United States): eCTD v4.0 transition expectations indicate a voluntary acceptance period starting in 2024 and a published target for mandatory use of 2029.
Health Canada (Canada): eCTD v4.0 transition expectations include voluntary adoption of eCTD v4 beginning in 2027 and mandatory adoption in 2029.
MFDS (Republic of Korea): eCTD v4.0 transition expectations include a voluntary phase beginning in 2027, while a mandatory adoption date has not yet been determined in published timelines.
MHLW/PMDA (Japan): eCTD v4.0 transition expectations include a voluntary phase starting in 2022 and a mandatory adoption in 2026.
Swissmedic (Switzerland): eCTD v4.0 transition includes a voluntary period beginning in 2027 and mandatory adoption in 2030.
TGA (Australia): eCTD v4.0 transition includes a voluntary period starting in 2027, and the mandatory adoption timeline has not yet been determined.

The purpose of the eCTD v4.0 transition centers on stronger lifecycle control, richer metadata, easier document reuse, and more consistent validation compared to v3.2.2, with the goal of reducing technical rework and enabling more efficient regulatory review workflows across the dossier lifecycle.

What Are the Challenges of Implementing eCTD?

The challenges of implementing eCTD are listed below.

Cost and Resource Constraints: eCTD implementation requires investment in publishing and validation software. eCTD adoption increases short-term workload during process transition and system setup.
Lack of Trained Personnel: eCTD implementation depends on specialized regulatory and technical expertise. Knowledge gaps increase the risk of structural errors and submission delays.
Technical Complexity: eCTD implementation involves strict technical rules for XML metadata, lifecycle management, controlled vocabulary, and validation. eCTD complexity increases the probability of errors without standardized processes and expertise.

How Can SimplerQMS Help Pharma Companies in Implementing eCTD?

SimplerQMS is an electronic Quality Management System (eQMS) designed for life science companies, including pharmaceuticals. SimplerQMS helps companies to control their documentation, training, and change management in compliance with regulatory and quality requirements. SimplerQMS is a pharmaceutical QMS software that supports broad quality processes and regulatory documentation needs, directly supporting eCTD preparation and lifecycle maintenance.

SimplerQMS addresses key challenges encountered during eCTD implementation, as given below.

Poor Management of Submission Documentation: SimplerQMS centralizes controlled documents used for eCTD submissions. SimplerQMS enforces version control and streamlines the review and approval process, preserving the document integrity required for regulatory submissions.
Lack of Training Readiness: SimplerQMS supports training management, improving the role-based training process and centrally storing qualification records for personnel, including regulatory and quality staff. SimplerQMS helps pharma companies ensure that personnel involved in eCTD preparation are trained on current procedures and requirements.
Disconnected Change Management: Within SimplerQMS, change controls can be linked to impacted documents and training. SimplerQMS supports lifecycle management and dossier updates by streamlining the change management process.

SimplerQMS supports the quality management processes that help maintain controlled documentation and records used in regulatory submissions, including eCTD submissions. SimplerQMS document control ensures accurate, approved source documents for eCTD publishing. SimplerQMS change control aligns regulatory updates with product and process changes. SimplerQMS training management ensures enhanced oversight of personnel qualification status, including the staff involved in dossier preparation. SimplerQMS CAPA management supports effective corrective action tracking from initiation to completion.

SimplerQMS improves document accuracy and reduces errors by enforcing controlled document lifecycle and traceability, minimizing the risk of outdated, inconsistent, or unapproved content entering eCTD submissions. SimplerQMS streamlines preparation by providing a single source of truth for regulatory and quality documentation.

SimplerQMS software provides regulatory benefits, helping pharmaceutical companies comply with FDA, EU, and ICH quality requirements. The QMS platform supports data integrity principles and includes technical controls aligned with FDA 21 CFR Part 11 and EU Annex 11 requirements for electronic records and signatures. SimplerQMS helps maintain controlled quality documentation and processes that support regulatory submissions and product lifecycle compliance.