What Is eCTD? A Practical Guide for Regulatory Teams
What is eCTD? A working guide
The electronic Common Technical Document is how a marketing application is packaged, sent and kept current with a health authority. Here is what is actually inside a sequence, how lifecycle works, and where submissions go wrong.
Two standards, one dossier
People use “eCTD” for two things that are worth keeping apart. The CTD (ICH M4) decides what goes where: a five-module table of contents that every ICH region shares for quality, nonclinical and clinical content. The eCTD (ICH M2 and M8) decides how it is packaged: the folder structure, the XML backbone that lists every file, the checksums, and the lifecycle metadata that tells a reviewer what each new document does to the ones already on file.
The second part is what makes eCTD different from a well-organised folder of PDFs. An application is not sent once. It is built up over years as a series of sequences — the original application, then amendments, responses to questions, safety reports, labeling changes, annual reports. The agency’s review system replays every sequence in order to show the reviewer the current state of the dossier. If the metadata in sequence 0047 is wrong, the reviewer’s view of the whole application is wrong.
The five modules
Modules 2 to 5 are harmonised across ICH regions. Module 1 is not, which is why the same product needs a different Module 1 for every market it is filed in.
Forms, cover letter, labeling, correspondence and administrative information, defined by each authority. The US has Form 356h, Form 1571 and promotional material under 1.15; the EU has the application form, SmPC and product information in every language; Japan has its own Japanese-titled sections. Module 1 also carries the envelope: application number, submission type and sequence metadata.
The Quality Overall Summary, the nonclinical and clinical overviews, and the written and tabulated summaries. Reviewers usually start here, so the hyperlinks from Module 2 into the study reports in Modules 3–5 matter more than anywhere else.
Drug substance and drug product: manufacture, controls, specifications, stability, container closure. Organised by substance, manufacturer and dosage form, so a product with two API sites carries two parallel 3.2.S sections. For most products this is where post-approval change happens.
Pharmacology, pharmacokinetics and toxicology study reports. In the US and Japan each study is grouped under a Study Tagging File that tells the reviewer which documents belong to which study.
Clinical study reports, case report forms, datasets and literature. For a large program this is thousands of files. FDA also expects standardised study data here, alongside the reports.
What actually gets sent
A sequence is a folder named with a four-digit number — 0000 for the first, then upward. It is never renumbered and never reused within an application.
The backbone
index.xml lists every document in Modules 2–5 with its location, checksum, title and lifecycle operation. The agency reads this file, not your folder tree. A file that is on disk but missing from the backbone does not exist as far as the reviewer is concerned.
The regional file
Module 1 has its own backbone — us-regional.xml for FDA, eu-regional.xml for the EU, and so on — validated against that region’s own DTD or schema. It also carries the envelope that identifies the application and the submission.
Checksums
index-md5.txt holds the checksum of the backbone, and every leaf in the backbone carries the checksum of its file. If a PDF changes after the backbone is built, validation fails.
Specification files
The util folder carries the DTDs and stylesheets the backbone was built against. Validators check these against the published versions, so an outdated copy is an error even if nothing else changed.
Study Tagging Files
For FDA and PMDA, nonclinical and clinical studies in Modules 4 and 5 are grouped by an STF that names the study and tags each file’s role — protocol, report body, amendment, case report form.
The documents
Mostly PDF: text-searchable, unsecured, fonts embedded, with bookmarks and relative hyperlinks. File and folder names are lowercase and kept short, because the specification limits name and path length.
Four operations, and why they matter
Every document in a sequence declares what it does to the dossier. Get one wrong and the reviewer sees two “current” versions of a specification, or none.
New
A document that does not replace anything. The first submission of a protocol, a new study report, a new response to a question.
Replace
Supersedes a specific earlier document, identified by a pointer to that leaf. The old version stays in the history but drops out of the current view. This is the operation most often done wrong — pointing at the wrong leaf, or at one in another section.
Append
Adds to an earlier document without superseding it, such as an addendum. Some regions discourage it; many teams avoid it and use replace instead.
Delete
Removes a document from the current view without a replacement. Nothing is physically deleted — the history still shows it was there.
Who requires eCTD, and which version
Most current filings use eCTD 3.2.2 with a regional Module 1. Version 4.0 is arriving region by region.
Required for NDAs, ANDAs, BLAs and master files since May 2017, and for commercial INDs since May 2018. Module 1 must use the US regional DTD v3.3 (required since March 2022). FDA has accepted eCTD 4.0 for new applications since September 2024, on a voluntary basis.
eCTD is the required format for centralised, decentralised and mutual recognition procedures, with national procedures following country by country. Module 1 follows the EU Module 1 specification (currently v3.1.x), and EMA publishes the validation criteria every sequence is checked against.
eCTD 4.0 is mandatory for new applications from 1 April 2026. Dossiers already in eCTD 3.2.2 can continue their lifecycle in 3.2.2. Module 1 section titles are in Japanese.
Health Canada, Australia’s TGA, Swissmedic, the GCC, South Africa’s SAHPRA and others each publish their own Module 1 and validation rules on the same ICH backbone. A sequence that passes in one region can fail in another on Module 1 alone.
What gets a sequence rejected
Agencies run technical validation before a reviewer opens anything. FDA classes its criteria by severity, and high-severity errors stop the submission; the EU uses pass/fail criteria, and any failure stops it.
Envelope metadata
Wrong application number, a submission sub-type that is not valid for the submission type, or a sequence number that does not match its folder. Small fields, hard stops.
Lifecycle errors
A replace that points at a document that is not there, or at one in a different section. These often pass validation and only show up when the reviewer sees the wrong current version.
PDF problems
Password protection, fonts not embedded, an unsupported PDF version, scanned pages with no searchable text, or bookmarks and links that go nowhere.
Broken hyperlinks
Links from Module 2 into a study report that was renamed or moved. They are technically valid and practically useless, and reviewers notice.
Specification drift
Building against an outdated DTD, a retired Module 1 version, or validation criteria that the agency has since updated.
File and path rules
Upper-case or special characters in file names, names or paths over the length limit, or a file format that region does not accept in that module.
eCTD 4.0 in plain terms
eCTD 4.0 keeps the CTD structure but replaces the way it is packaged. Instead of a folder backbone plus a regional XML file, each submission is a single message (based on the HL7 Regulated Product Submission standard). Documents get a permanent identifier, so the same document can be referenced again in a later sequence instead of being sent twice. Lifecycle is tracked on each document’s context of use — where it sits and what it is for — rather than on the file. Controlled vocabularies are published by each authority as code lists, so submission types and keywords are picked from the agency’s list rather than typed.
For a team, the practical change is that more of the metadata has to be right before you publish, because more of it is structured. The two versions will run side by side for years: existing applications continue in 3.2.2 unless a region says otherwise, while new applications move to 4.0 on each region’s timetable.
Take the guide with you
The full guide as a PDF, for onboarding new team members or briefing colleagues outside regulatory.
- CTD and eCTD: two standards, one dossier
- The five modules
- What is inside a sequence
- Lifecycle: the four operations
- Who requires eCTD, and which version
- What gets a sequence rejected
- eCTD 4.0 in plain terms
Frequently asked
What is the difference between CTD and eCTD?
CTD is the content structure — five modules and the table of contents inside them. eCTD is the electronic format that packages that content with an XML backbone, checksums and lifecycle metadata so the agency can validate it and review it as a living dossier.
Is eCTD required for an IND?
For FDA, commercial INDs have required eCTD since May 2018. Noncommercial INDs, such as investigator-sponsored studies, are exempt, although they may still be submitted in eCTD.
What is a sequence number?
The four-digit name of each submission folder, starting at 0000 for the first submission in an application. It must match the number in the envelope and is never reused within that application.
How is an eCTD sent to the agency?
Through the agency’s electronic gateway rather than by email or disk — for example the FDA Electronic Submissions Gateway, or the EMA eSubmission Gateway and Web Client in the EU.
What happens if a sequence fails technical validation?
In the US, a high-severity error leads to technical rejection and the sequence has to be corrected and sent again. In the EU, failing any pass/fail criterion has the same effect. Either way the review clock does not start, which is why teams validate against the agency’s own criteria before sending.
Do I have to move existing applications to eCTD 4.0?
Not as things stand. FDA accepts 4.0 voluntarily for new applications, and Japan’s 4.0 mandate applies to new applications while existing 3.2.2 dossiers continue. Check each region’s current guidance before planning a migration.
See a sequence built and validated end to end
DnXT Publisher assembles the backbone, Module 1 and lifecycle for 16 eCTD regions and checks each sequence against that region’s own validation criteria before it is sent.
