Examples
Worked examples
- Is an instance
A sponsor filing an NDA organizes the dossier into Module 1 (US-specific forms including FDA Form 356h and administrative correspondence), Module 2 (quality/nonclinical/clinical overviews and summaries), Module 3 (chemistry, manufacturing, and controls data), Module 4 (nonclinical study reports), and Module 5 (clinical study reports prepared under ICH E3) -- all indexed by an XML backbone that FDA's electronic submission gateway validates on receipt.
- Is an instance
When a sponsor later adds a new clinical study report to an already-submitted NDA, the eCTD lifecycle mechanism lets them submit it as an 'append' operation to a specific Module 5 node in a new submission sequence, rather than resubmitting the entire dossier -- FDA's review system links the new sequence to the existing application history automatically.
Counter-examples
Looks similar, but isn't
- Not an instance
A sponsor emailing FDA a set of PDFs organized by its own internal folder-naming convention, with no XML backbone and no Module 1-5 structure, is not an eCTD submission even if every required document is present and complete -- FDA's electronic submission gateway requires the standardized structure and lifecycle metadata to accept and process the filing at all.
Editorial commentary
The electronic Common Technical Document (eCTD) is the standardized electronic submission format that FDA and other ICH regulatory authorities require for structuring applications such as New Drug Applications (NDAs), Abbreviated New Drug Applications (ANDAs), Biologics License Applications (BLAs), Investigational New Drug applications (INDs), and Drug Master Files (DMFs). It is the electronic implementation of the paper-era Common Technical Document (CTD) harmonized format developed under the International Council for Harmonisation (ICH), organizing a submission into a fixed five-module folder hierarchy plus an XML backbone that gives reviewers a hyperlinked table of contents and tracks the document’s lifecycle across amendments.
The five-module hierarchy
Every eCTD submission follows the same top-level structure, regardless of application type:
- Module 1 — Administrative and regional information. The only module that is not harmonized internationally; its contents are defined by each regulatory authority rather than by ICH. For FDA, Module 1 holds the application’s cover forms and correspondence — including FDA Form 356h for NDA/ANDA/BLA submissions, or Form FDA-1571 as the cover sheet for an Investigational New Drug (IND) application — along with labeling, meeting requests, annual reports, and other US-specific administrative content.
- Module 2 — CTD summaries. Overview and summary documents (Quality Overall Summary, Nonclinical Overview/Summary, Clinical Overview/Summary) that synthesize the detailed data in Modules 3-5 for reviewers.
- Module 3 — Quality. Chemistry, manufacturing, and controls (CMC) data for the drug substance and drug product, structured per the ICH M4Q guideline.
- Module 4 — Nonclinical study reports. Pharmacology, pharmacokinetics, and toxicology study reports, structured per ICH M4S.
- Module 5 — Clinical study reports. Clinical study protocols and reports, including full Clinical Study Reports (CSRs) prepared under the ICH E3 structure, plus other clinical data.
Modules 2-5 are harmonized across ICH regions (the same structure applies whether the submission goes to FDA, EMA, or another ICH regulatory authority); Module 1 content and organization is set independently by each authority.
XML backbone and lifecycle management
What distinguishes an eCTD from an ordinary electronic folder of documents is the XML backbone (an index.xml file and related XML metadata) that sits on top of the Module 1-5 folder tree. The backbone does two things a plain folder structure cannot: it builds the hyperlinked, navigable table of contents reviewers use to move through the submission, and it assigns a lifecycle operation — new, append, replace, or delete — to each individual file. That lifecycle metadata is what lets a sponsor submit an amendment, a safety update, or a new study report as an incremental addition to an existing application’s submission history, rather than resubmitting the entire dossier each time. FDA’s Electronic Submissions Gateway validates this structure on receipt; a submission that is missing the backbone or does not conform to the required hierarchy is rejected rather than processed.
Who is required to use eCTD
FDA’s Providing Regulatory Submissions in Electronic Format guidance made eCTD mandatory in stages: NDAs, ANDAs, BLAs, and Drug Master Files (new and existing) were required to be submitted in eCTD format beginning May 5, 2017; commercial INDs (those intended to eventually support marketing) followed on May 5, 2018. Once an application is under an active eCTD mandate, every subsequent submission to that application — amendments, annual reports, correspondence — must also be filed in eCTD format, even if the original application predates the mandate.
eCTD vs. CTD
The CTD is the harmonized content and organization standard itself, agreed by ICH; the eCTD is the electronic, XML-backboned implementation of that standard used for actual submission and lifecycle management. In practice, essentially all NDA/ANDA/BLA/IND traffic to FDA today is filed as eCTD rather than as a paper CTD, so the two terms are frequently used interchangeably in practice even though they describe distinct things — the content standard versus its electronic submission format.
Related CASRAI terms
See CASRAI’s entries on the Investigational New Drug (IND) application (which the eCTD’s Module 1 cover sheet, Form FDA-1571, accompanies), FDA Form 1572 (Statement of Investigator), FDA Form 356h (the NDA/ANDA/BLA cover form filed in Module 1), and the Clinical Study Report (CSR) (filed in Module 5) for how these pieces fit into a complete eCTD submission.
Machine-readable encodings
Use in your systems
<role vocab="credit"
vocab-identifier="https://casrai.org/dictionary/"
vocab-term="eCTD (Electronic Common Technical Document)"
vocab-term-identifier="https://casrai.org/dictionary/term/ectd" />{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"@id": "https://casrai.org/dictionary/term/ectd",
"name": "eCTD (Electronic Common Technical Document)",
"identifier": "https://casrai.org/dictionary/term/ectd",
"description": "A regulatory submission qualifies as an eCTD only when its files are organized into the standardized five-module folder hierarchy (Module 1 region-specific administrative/prescribing information, Module 2 CTD summaries, Module 3 quality/CMC, Module 4 nonclinical study reports, Module 5 clinical study reports) AND wrapped in an XML backbone (index.xml) that assigns each file lifecycle-operation metadata (new, append, replace, delete) so a reviewer's system and the sponsor's own submission history can track changes across amendments to the same application. A folder of complete, correctly-labeled PDFs that lacks the XML backbone and Module 1-5 structure is not an eCTD, regardless of content completeness.",
"inDefinedTermSet": "https://casrai.org/dictionary/domain/clinical-research#set",
"url": "https://casrai.org/dictionary/term/ectd",
"sameAs": [],
"license": "https://creativecommons.org/licenses/by/4.0/",
"publisher": {
"@id": "https://casrai.org/#organization"
},
"dateModified": "2026-07-18T06:30:46",
"inLanguage": "en"
}






