eCTD 4.0 Vendor Landscape in 2026
eCTD v4.0 rollout remains authority-specific. FDA officially supports certain new eCTD v4.0 submissions, while other regions continue phased pilots or staged adoption. Vendor claims about "readiness" should be tested against the exact authority, submission type, and production evidence you need.
Key Takeaways
Key Takeaways
- eCTD v4.0 is based on HL7 v3 RPS, not FHIR.
- FDA has published official support for certain new eCTD v4.0 submissions; other authority timelines should be confirmed directly from current primary sources.
- Vendor claims about pilots, accepted submissions, and authority support should be checked against current official or vendor-primary documentation.
- Architecture still matters, but buyers should prioritize demonstrable support over marketing language.
- The eCTD 4.0 transition is no longer theoretical. FDA is already supporting certain new eCTD v4.0 submissions, and multiple other authorities are pursuing staged rollouts, pilots, or local implementation plans.
- For a detailed look at the technical changes from v3.2.2 to v4.0, see our eCTD v4.0 migration guide.
- This article focuses on what can be supported directly from authority pages and official vendor materials: the technical shift in the standard, the current public implementation picture, and the questions buyers should ask vendors.
- In this article, you'll learn:
- What eCTD v4.0 changes technically (HL7 RPS, metadata, controlled vocabularies)
- The current implementation picture by region using primary sources only
- How each major vendor's architecture maps to 4.0 requirements
- Why the 3.2.2-to-4.0 migration is not a simple upgrade for legacy platforms
- What to prioritize when evaluating eCTD 4.0 software
- ---
What Changes Technically in eCTD v4.0
eCTD v4.0 is the next-generation electronic Common Technical Document specification, developed under ICH M8, that replaces the XML DTD backbone of v3.2.2 with a messaging architecture based on HL7 Regulated Product Submission (RPS). It introduces metadata-driven content management, controlled vocabularies, and a unified XML message model.
Before evaluating vendors, you need to understand what is actually changing. eCTD v4.0 is not a minor version bump. It changes how regulatory submissions are structured, transmitted, and processed.
From XML Backbone to HL7 RPS
eCTD v3.2.2 uses a directory-based structure with an XML DTD backbone. Submissions are organized as sequential "sequences," each with its own XML index pointing to documents in a folder hierarchy. The Table of Contents (TOC) is rigid and fixed by the specification.
eCTD v4.0 replaces this with an HL7 Regulated Product Submission (RPS) message model rather than the classic v3.2.2 backbone-and-folder approach.
“Clarification: eCTD v4.0 is based on HL7 v3 RPS, not HL7 FHIR.
Key Technical Differences
| Dimension | eCTD v3.2.2 | eCTD v4.0 |
|---|---|---|
| Message basis | XML DTD backbone | HL7 v3 RPS R-MIM schema |
| Message count | Multiple sequential XML indices | Single unified XML message |
| TOC structure | Fixed hierarchy defined in specification | Dynamic, managed via code lists |
| Content referencing | Leaf elements in folder directories | Context groups with metadata |
| Vocabulary management | Static index lists | Genericode-formatted, continuously updatable |
| Document lifecycle | Replace/append/delete per leaf | One-to-many replacements via context and priority metadata |
| Module 1 integration | Region-specific DTDs, separate files | Integrated into single RPS message with regional IGs |
| Ordering | Implied by file/folder structure | Explicit priority attributes in XML |
Metadata and Controlled Vocabularies
eCTD v4.0 introduces a metadata-driven architecture that differs materially from v3.2.2's file-and-folder approach:
- Context groups assign every document a coded position in the TOC hierarchy (e.g., a Module 3 quality report receives a context group like "3QC").
- Keywords are controlled codes attached to submissions, capturing attributes such as application type, product classification, or therapeutic area.
- Priority numbers determine sort order within sections, since XML elements do not inherently preserve sequence.
- Controlled vocabularies are published as Genericode files by ICH and regional agencies (FDA, EMA, PMDA), and can be updated independently of the core specification.
This is a significant change. In v3.2.2, the TOC structure is largely fixed. In v4.0, new content categories can be handled through controlled vocabulary updates rather than only through broader specification changes. Buyers should therefore confirm how each product handles dynamic TOC resolution, vocabulary versioning, and metadata validation.
Forward Compatibility with v3.2.2
eCTD v4.0 supports lifecycle continuation from existing v3.2.2 dossiers. Products with active v3.2.2 submissions can transition mid-stream to v4.0 format. The specification defines how to reference prior v3.2.2 content within a v4.0 submission unit. This matters in practice because sponsors typically need continuity across existing dossiers.
eCTD v4.0 Implementation Picture by Region
The rollout is staggered, and not every authority has published the same level of detail.
| Region | Agency | Current Public Position |
|---|---|---|
| United States | FDA | Supports certain new eCTD v4.0 submissions beginning September 16, 2024, per FDA eCTD resources |
| European Union | EMA | Continuing staged implementation and technical work; confirm the latest production status through EMA eSubmission resources |
| Japan | PMDA | Confirm current production requirements directly with PMDA and your vendor for the specific application type |
| Other regions | Various authorities | Confirm directly with each authority and vendor because local implementation details continue to evolve |
What This Means in Practice
If you submit to FDA, use FDA's published scope carefully. FDA states support for certain new applications in eCTD v4.0 and notes important current limitations, including forward-compatibility constraints.
If you submit to EMA, PMDA, or other authorities, do not rely on generalized market timelines. Verify the exact status for your procedure, region, and filing type using current authority documentation.
If you submit globally, build your plan around the earliest authority that truly applies to your product and submission type, not the most aggressive industry forecast.
Vendor Readiness Assessment
Here is how major eCTD publishing vendors describe their current v4.0 positioning in official materials.
Readiness Comparison Matrix
| Vendor | Product | Vendor-Documented v4.0 Positioning | Deployment |
|---|---|---|---|
| Assyro | Assyro AI | Positions itself around modern eCTD workflows and validation support | Cloud |
| Veeva | Vault RIM / Submissions | Publicly discusses eCTD 4.0 readiness inside unified RIM | Cloud |
| LORENZ | docuBridge | Publicly documents eCTD 4.0 support in current product materials | On-prem + Cloud |
| Extedo | EXTEDOpulse / eCTDmanager | Publicly documents eCTD v3 and v4 support | Cloud + On-prem |
| Ennov | Ennov Dossier / InSight | Publicly positions its suite around eCTD v4.0 support | Cloud + On-prem |
| Certara | GlobalSubmit | Publicly positions GlobalSubmit around eCTD v4.0 support | Cloud |
Vendor-by-Vendor Analysis
Assyro AI: Validation-First Positioning
Assyro is positioned as an AI-native compliance platform rather than a traditional legacy publishing suite.
Key capabilities:
- Validation-first workflow support
- Cloud-native deployment
- Support for current eCTD workflows and vendor-described v4.0 readiness items
Why it matters for 4.0: Buyers evaluating Assyro should ask for concrete evidence of the exact v4.0 workflows they need, not just general positioning around modern architecture.
Learn more at assyro.com.
Veeva Vault RIM: Unified RIM Positioning
Veeva Vault RIM is positioned as an end-to-end regulatory suite covering submission planning, authoring, publishing, and lifecycle management.
eCTD 4.0 status: Veeva publicly discusses eCTD 4.0 readiness within its unified RIM architecture.
Considerations:
- Buyers using Vault RIM should evaluate how current v4.0 support fits into the broader platform workflow.
- Veeva's enterprise sales cycle and implementation model may not suit every organization.
- Buyers should request direct evidence for the exact authorities and submission types they care about.
- The platform is cloud-native, which aligns well with modern deployment expectations.
Risk factor: Evaluate actual product support, not general roadmap language.
LORENZ docuBridge: Established Publishing Platform
LORENZ docuBridge is an established eCTD publishing tool.
eCTD 4.0 status: LORENZ publicly documents current eCTD 4.0 support in product materials.
Considerations:
- docuBridge documents v3.2.2-to-4.0 conversion capabilities that may matter for teams with large existing dossiers.
- LORENZ publicly documents a recurring release cadence for the product.
- docuBridge ONE (cloud) and docuBridge TWO (on-premise) provide deployment options.
Risk factor: Confirm the exact forward-compatibility and workflow behavior you need using a real dossier or pilot package.
Extedo (EXTEDOpulse / eCTDmanager): Multi-Region Publishing Suite
Extedo positions its products around regulatory portfolio management and multi-region submission support.
eCTD 4.0 status: Extedo publicly documents support for both eCTD v3 and v4 product workflows.
Considerations:
- Vendor materials describe support across multiple regions.
- Submission readiness assessments are available as a service offering.
- Cloud and on-premise deployment options.
Risk factor: Evaluate the actual migration and validation workflow rather than relying on broad marketing descriptions.
Ennov: Dossier and Publishing Suite
Ennov publicly positions its dossier and publishing products around eCTD v4.0 support.
Considerations:
- Ennov materials describe support for CTD, eCTD (v3 and v4), NeeS, vNeeS, and eCopy formats.
- Ennov positions its products for both cloud and on-premise deployment.
Risk factor: Ask Ennov to distinguish clearly between pilot evidence, accepted production use, and roadmap commitments.
Certara GlobalSubmit: Publishing and Validation Positioning
Certara's approach to eCTD 4.0 includes public messaging around both sponsor-side publishing and authority-facing partnerships.
eCTD 4.0 status: GlobalSubmit is publicly positioned around eCTD v4.0 publishing and validation support. The platform is cloud-based.
Considerations:
- Vendor materials describe cloud deployment and multi-region support.
- Live validation and automated hyperlink creation features.
Risk factor: Ask for authority-specific production evidence rather than broad geographic claims.
The Legacy Architecture Problem
This is the core issue that many vendor comparison articles blur: eCTD v3.2.2 and eCTD v4.0 are not identical operating models.
What v3.2.2 Software Was Built To Do
- Parse and generate XML DTD backbone files
- Manage documents in fixed folder hierarchies
- Handle sequential submission numbering
- Validate against static rule sets tied to folder structure
- Generate leaf elements with lifecycle operations (new, replace, append, delete)
What v4.0 Software Must Do
- Generate and validate HL7 v3 RPS XML messages
- Manage metadata-driven content with context groups and keywords
- Resolve dynamic Table of Contents from Genericode vocabulary files
- Support one-to-many document replacement via metadata, not folder operations
- Handle priority-based ordering within XML
- Validate against continuously updatable vocabulary sets published by ICH and regional agencies
- Support forward-compatible lifecycle continuation from v3.2.2 dossiers
These are materially different requirements. Buyers should therefore test how each product actually handles metadata, controlled vocabularies, and forward compatibility in the workflow they will use.
Why This Matters to You
If your vendor treats v4.0 as an export format rather than a native operating model:
- Vocabulary updates may lag. When ICH or a regional agency publishes updated Genericode files, your software needs a clear update path.
- Metadata validation may be shallow. Schema validation alone does not prove the metadata model is being used well.
- Lifecycle handling may be fragile. v4.0 relies more heavily on metadata relationships than classic folder logic.
- Future v4.x updates may expose weak implementations. Extensibility is a strength of v4.0, but only if the product can keep pace.
What to Evaluate When Choosing an eCTD 4.0 Vendor
1. Architecture Origin
Ask: How does the platform currently handle the v4.0 message model, metadata, and controlled vocabularies?
Architecture matters because v4.0 relies more heavily on metadata, vocabulary management, and forward compatibility than v3.2.2.
2. Vocabulary Management
Ask: How does the platform handle Genericode vocabulary updates?
In v4.0, ICH and regional agencies publish controlled vocabulary updates independently of the core specification. Ask the vendor how those updates are applied in practice.
3. Pilot and Production Track Record
Ask: Has the vendor completed successful v4.0 work for your target agencies, and what kind of evidence can they show?
Distinguish clearly between pilot submissions, accepted production use, and general roadmap statements.
4. Forward Compatibility
Ask: How does the platform handle v3.2.2-to-v4.0 lifecycle continuation?
If you have existing v3.2.2 dossiers, ask the vendor how forward compatibility is handled in the product you will use.
5. Multi-Authority Support
Ask: Can the platform produce v4.0 submissions for all your target agencies from a single workspace?
Regional Module 1 Implementation Guides differ between FDA, EMA, PMDA, Health Canada, and others. Ask the vendor how those differences are implemented in the product you will actually use.
6. Validation Depth
Ask: Does the platform validate only XML schema compliance, or does it also provide broader review support?
Schema validation confirms that the XML message is structurally correct. Broader regulatory review checks whether the submission content aligns with agency-specific rules. For a capability comparison, see our eCTD validation software guide.
7. Total Cost of Transition
Ask: What is the full cost of moving to v4.0 with this vendor?
Include software licensing, implementation, training, data migration, validation (per 21 CFR Part 11 / Annex 11), and ongoing maintenance. Some vendors bundle v4.0 in existing subscriptions. Others charge for upgrades, migration services, or additional modules.
Migration Considerations for Regulatory Teams
Start With Japan (If Applicable)
If your organization submits to PMDA, confirm the current production requirements directly with PMDA and your vendor before setting your internal timeline.
Plan for Dual-Format Operations
The staggered regional timelines mean many organizations may need to operate in both v3.2.2 and v4.0 for a period of time. Your vendor should explain clearly how dual-format support works in practice.
Validate Your Vendor's Output Against Agency Tools
Do not rely solely on your vendor's built-in validator. Use current authority documentation and any available authority-side validation tools or criteria when testing production readiness.
Budget for Training
eCTD v4.0 introduces concepts (context groups, keywords, priority ordering, Genericode vocabularies) that are unfamiliar to teams who have worked exclusively with v3.2.2. Training is not optional. Budget for it explicitly and plan for hands-on practice with test submissions before your first production v4.0 filing.
Assess Your Vendor's Long-Term Viability
Evaluate how each vendor handles specification updates, vocabulary changes, and authority-specific implementation work over time.
The Bottom Line
The eCTD v4.0 transition requires organizations to evaluate software architecture and product evidence carefully. Some vendors already publish concrete support statements and product materials. Others still communicate more cautiously or at a higher level.
For organizations evaluating eCTD 4.0 readiness in 2026, the decision framework is straightforward:
- Identify the earliest authority requirement that actually applies to you.
- Verify your vendor has demonstrated v4.0 output to your target agencies.
- Test the workflow, not just the marketing. Can the platform handle dynamic vocabularies, context groups, and lifecycle changes in practice?
- Evaluate total migration cost, including dual-format operations during the transition period.
- Choose a platform based on evidence, not generalized readiness language.
The practical takeaway is to treat eCTD v4.0 as both a standards change and a workflow change, not just a naming update in vendor materials.
References
It depends on the region and submission type. FDA has published support dates for certain new eCTD v4.0 submissions. For EMA, PMDA, and other authorities, confirm the latest production status and any mandatory timing directly from current authority sources.