The eCTD was designed as a harmonized global format, and Modules 2 through 5 — the ICH backbone — largely are. Everything else is regional, and everything regional is where submissions get rejected. Module 1 is a different specification in every jurisdiction, DTD and schema versions differ, envelope metadata differs, file-format rules differ, and each authority runs its own validation criteria. This guide maps the practical differences region by region, then covers what ‘multi-region support’ should actually mean when you evaluate publishing software.
The Architecture: One Backbone, Many Module 1s
Every eCTD submission shares the ICH structure: an index.xml backbone referencing leaf documents across Modules 2–5, with lifecycle operations (new, replace, append, delete) connecting versions across sequences. What each region adds is its own regional layer — a Module 1 specification with its own DTD or schema, its own envelope metadata (application numbers, submission types, contact structures), and its own administrative documents. If you learn one thing from this guide: regional Module 1 is where the complexity lives. (New to the format? Start with our eCTD definitive guide and Module 1 explainer.)
Region by Region
United States (FDA)
The most prescriptive regional implementation. US regional runs on the us-regional v3.3 DTD (with eCTD 4.0 adoption progressing), a detailed envelope (application type, submission type and sub-type, contact and applicant structures), and Module 1 packed with XFA forms — 1571, 356h, 3674 and more. Two US-specific traps: DTD and stylesheet references in regional XML must resolve exactly as FDA’s validator expects, and FDA’s validation criteria are published, numbered, and enforced — a dangling leaf reference or malformed regional XML is an automatic technical rejection. Study Tagging Files (STFs) for Module 4/5 study content are also effectively mandatory in US practice.
European Union (EMA and national agencies)
EU eCTD uses its own Module 1 specification with envelope metadata reflecting European procedures — centralised, decentralised, mutual recognition — plus per-member-state considerations within one framework. EU validation criteria are maintained as a numbered criteria set with pass/fail severities, and the procedure type drives structural expectations. The multilingual dimension (labeling across member states) adds document-management complexity the US doesn’t have.
Japan (PMDA)
Japan runs its own regional specification with Japanese-language administrative content and distinct envelope semantics. Practical differences that bite: character-encoding correctness for Japanese text, region-specific controlled vocabularies for application and submission types, and validation criteria keyed to PMDA’s expectations rather than a copy of FDA’s. Software that treats Japan as ‘US with different labels’ fails here in ways that are tedious to debug.
GCC (Gulf Cooperation Council)
The GCC states operate a shared regional specification for the Gulf market with its own Module 1 structure and envelope, and validation criteria that have matured rapidly. A growing filing destination — and a good test of whether a vendor’s ‘multi-region’ claim extends beyond the big three.
Australia (TGA) and Singapore (HSA)
Both run eCTD implementations with their own Module 1 specifications and validation profiles — structurally familiar if you know EU/ICH patterns, but with regional envelopes, controlled vocabularies, and administrative documents of their own. Additional markets including Thailand and Taiwan continue to adopt eCTD variants, so regional coverage is a moving target, not a fixed list.
What Differs, Concretely
| Dimension | What varies by region |
|---|---|
| Module 1 structure | Entirely regional — folder structure, required documents, forms |
| DTD / schema versions | Each region versions independently; a real platform tracks 20+ DTD versions across regions and ICH baselines |
| Envelope metadata | Application identifiers, submission types, contacts — different vocabularies everywhere |
| Validation criteria | Separate numbered rule sets per authority, updated on their own schedules |
| Lifecycle conventions | Shared operations, regionally different practices (e.g., STF usage, baseline submissions) |
What ‘Multi-Region Support’ Should Mean in Software
Vendor decks all claim global coverage. Useful evaluation questions:
- Is each region a first-class template? Real regional folder structures, envelopes, and controlled vocabularies per DTD version — not a US template with renamed folders.
- Are validation criteria per-region and current? Ask to see the criteria list for a smaller region (Singapore, GCC) — that’s where box-ticking vendors get caught.
- Can one dossier feed many regions? The whole economic point of eCTD: shared Modules 2–5 with regional Module 1 variants, without maintaining parallel dossiers per market.
- How fast do new regions and versions arrive? Regional specs update continuously; the vendor’s update cadence is part of what you’re buying.
DnXT publishes and validates across US (3.3 and 4.0 criteria), EU, Japan, GCC, Australia, Singapore and additional markets from region-specific templates and per-region validation criteria — built on our multi-regional compliance engine, with regional content maintained as seeded configuration rather than code, so new regions and DTD versions ship without re-platforming.
Frequently Asked Questions
Is eCTD mandatory everywhere?
No — mandates vary by region, procedure type, and application type, and several markets still accept or require alternative formats in specific cases (see eCTD vs NeeS). The trend is uniformly toward eCTD, and new-application mandates keep expanding.
Can I reuse my US dossier for the EU or Japan?
Modules 2–5 substantially, yes — that’s the design. Module 1 must be rebuilt per region, envelope metadata re-entered against regional vocabularies, and regional content requirements (local labeling, regional administrative documents) added. Good software makes this a variant, not a rewrite.
Do all regions use the same validation rules?
No. Each authority maintains its own numbered criteria set with its own severities and update cadence. Passing FDA validation says nothing about passing EU or PMDA validation on the same content.
What trips teams up most in new regions?
Controlled vocabulary mismatches in the envelope (application/submission types that don’t exist regionally), character encoding for non-Latin scripts, and assuming US lifecycle conventions apply globally. All three are software problems when your platform models regions properly.
Expanding into new markets this year? Talk to a regulatory expert — we’ll walk through your target regions and show the same dossier published and validated for each.
