eCTD v4 Technical Architecture — What Changes for CMC Submissions
eCTD version 4.0 represents a fundamental redesign of the electronic Common Technical Document — not a format update but an architecture change from document-centric to data-centric submissions — and the…
On this pageArticle overview
eCTD v4 Technical Architecture — What Changes for CMC Submissions
eCTD version 4.0 represents a fundamental redesign of the electronic Common Technical Document — not a format update but an architecture change from document-centric to data-centric submissions — and the CMC sections are where this change has the most significant operational implications.
I want to be precise about what “architecture change” means in this context, because the phrase is often used loosely in regulatory technology discussions without the technical specificity that allows a CMC team to understand what they actually need to do differently. When I say architecture change, I mean that the fundamental submission unit changes. In eCTD v3 — the version that has governed electronic submissions since its ICH M2 adoption and that remains the required format for FDA and EMA submissions during the current transition period — the submission unit is a PDF document organized in a folder hierarchy that mirrors the CTD structure. The folder is 3.2.P.2.1, and in it sits a PDF. The submission software knows to put that PDF there because a human organized it there, and the regulatory authority reviewer knows to find it there because the folder name is the section reference.
In eCTD v4, the submission unit is a data object with an XML manifest. The manifest carries structured metadata — what type of document this is, what section it corresponds to, what its relationship is to previously submitted documents, what its lifecycle status is (new, replacement, deletion, appendix). The PDF may still exist as the narrative content, but the navigation, the relationship logic, the lifecycle tracking, and the cross-referencing that in v3 are managed by folder organization and human convention are in v4 managed by machine-readable XML. This is not a refinement of v3. It is a different technical paradigm.
WHAT CHANGES IN ECTD V4: FROM DOCUMENT HIERARCHY TO DATA GRAPH
The eCTD v3 architecture — as specified in ICH M2 and implemented through FDA and EMA regional technical guidance — is fundamentally a file system metaphor. Documents are organized in a directory tree. The CTD section numbering maps to folder paths. The backbone XML in v3 provides a table of contents, but the organizational logic is the folder structure. Reviewers navigate submissions by understanding the CTD hierarchy and knowing where in that hierarchy to find the content they need. This architecture has worked for over two decades because it is human-readable and maps intuitively to the CTD structure that regulatory scientists use to organize and communicate pharmaceutical development data.
The limitation of the v3 architecture becomes apparent when submissions evolve over time. A product with ten years of post-approval history may have dozens of sequences — each sequence adding, replacing, or modifying documents from prior sequences. The lifecycle of any given document in v3 is tracked through the sequence backbone XML and a set of operations (new, replace, delete, append), but the relationship between an original document and all of its subsequent amendments is reconstructed by navigating the sequence history. For reviewers and for sponsors maintaining the submission lifecycle, this reconstruction is a manual and error-prone process that scales poorly with submission complexity.
ICH M8 eCTD v4.0 redesigns this around explicit document relationships encoded in XML. In v4, every document in the submission has a manifest record that carries its document type — drawn from a controlled vocabulary — its relationship to other documents in the submission, its lifecycle operation, and its regional metadata. The lifecycle operations in v4 (new, replace, delete, append) operate at the document level with explicit reference to the document being replaced, not through the positional logic of folder placement and sequence numbering. A v4 submission can express “this document replaces document X in prior submission Y” as a machine-readable statement, not as a inference drawn from folder position and sequence chronology.
For CMC submissions specifically, this has operational implications that begin with submission authoring and extend through the full product lifecycle. The ICH M4Q(R1) CTD Quality section numbering — the 3.2.P and 3.2.S and 3.2.A structure that every CMC practitioner knows — is preserved in v4. The section assignments do not change. What changes is how the assignment is expressed. In v3, assigning a document to 3.2.P.3.2 means placing it in the correct folder with the correct filename in a correctly organized directory tree. In v4, assigning a document to 3.2.P.3.2 means recording that section reference as a metadata field in the document’s XML manifest, alongside its document type classification, its relationship declarations, and its lifecycle status. These are structurally different operations. The first is a file management task. The second is a data management task.
The transition has implications for submission authoring systems that go beyond format support. A submission publishing tool that produces eCTD v4-compliant output must be capable of generating and validating XML manifests that conform to the v4 schema, populating document type fields from the correct controlled vocabulary, expressing document relationships and lifecycle operations correctly, and incorporating region-specific metadata requirements from the FDA eCTD v4 Technical Implementation Guide and the EMA eCTD Working Group technical specifications. The capability to compile PDFs into folder hierarchies — which is the core technical function of v3 authoring tools — is necessary but not sufficient for v4 production.
This is the transition readiness gap that I want CMC teams to understand clearly. It is not primarily a question of whether your submission content is good. It is a question of whether your submission infrastructure — authoring tools, data management processes, and team competencies — can produce the XML-manifested data objects that v4 requires. Teams that have invested in their v3 authoring workflows have built competencies that partially transfer — CTD organization knowledge, lifecycle management experience, regulatory metadata judgment — but the technical execution layer must change.
The ICH M8 eCTD v4.0 Implementation Guide makes explicit that eCTD v4 is designed to accommodate FHIR-formatted structured data alongside narrative PDFs in the same submission bundle. This is the architectural connection to PQ-CMC that makes v4 a CMC-critical transition, not merely a regulatory IT transition.
MODULE 3 IN V4: SAME CTD STRUCTURE, FUNDAMENTALLY DIFFERENT TECHNICAL ARCHITECTURE
Module 3 content — drug substance, drug product, excipients, container closure, stability — represents the largest and most technically complex section of the CTD for most pharmaceutical products. It is also the section most directly affected by eCTD v4’s architectural changes, because Module 3 submissions have the richest document lifecycle histories, the most extensive cross-referencing requirements, and — with PQ-CMC’s expansion of structured data requirements — the most significant convergence of narrative and structured content that v4’s architecture is designed to accommodate.
The v4 document type controlled vocabulary introduces explicit classification for Module 3 document types that in v3 are implied by folder placement. In v3, a document is a drug substance specification because it is placed in folder 3.2.S.4.1. In v4, a document is explicitly typed as a drug substance specification in its XML manifest, regardless of — or in addition to — its section assignment. This explicit typing enables automated validation that a document of a given type has been placed in the correct section, and enables cross-referencing by document type across submissions and sequences. For CMC teams managing multi-product portfolios with shared excipients, shared container closure systems, or shared manufacturing facilities, this cross-referencing capability has genuine practical value — a facility information document registered once can be explicitly referenced by multiple product submissions through v4’s document relationship model, rather than duplicated or inconsistently cross-referenced through v3’s folder-based approach.
The lifecycle management improvement in v4 is operationally significant for post-approval CMC submissions. A product with an approved NDA or MAA accumulates post-approval CMC changes through CBE-30 filings, Prior Approval Supplements, and Type IA/IB/II variations. Each filing amends specific Module 3 documents. In v3, tracking which documents are current across a multi-year post-approval history requires reconstructing the sequence history — a task that becomes increasingly burdensome as the submission grows. In v4, the explicit document replacement references in the XML manifest create a machine-readable document history that can be traversed without sequence-by-sequence reconstruction. This is a meaningful improvement in the tractability of long-term regulatory submission lifecycle management.
The regional metadata requirements add a layer of compliance obligation. FDA’s eCTD v4 Technical Implementation Guide and EMA’s technical specifications both specify region-specific metadata fields that must be populated in the document manifests. These fields differ between FDA and EMA implementations, which means that a global submission strategy must manage two sets of regional metadata requirements within the same v4 architecture. The ICH M2 specification establishes the common framework; the regional implementation guides establish the agency-specific requirements within that framework. Teams preparing dual submissions — the same Module 3 content filed simultaneously with FDA and EMA — must ensure their authoring systems can produce v4 manifests that satisfy both regional specifications for the same document set.
PQ-CMC AND ECTD V4 INTEGRATION: THE CONVERGENCE OF STRUCTURED CMC DATA STANDARDS
The reason eCTD v4 is a CMC practitioner issue — not merely a regulatory IT infrastructure issue — is the PQ-CMC integration architecture. PQ-CMC, the FDA’s structured data standard for pharmaceutical quality CMC information in Module 3, produces FHIR JSON-formatted data files representing drug substance specifications, drug product specifications, batch formula, stability data, and other Module 3 content in machine-readable structured format. These FHIR files are a different content type from narrative PDFs. They are not replacements for narrative PDFs in the current PQ-CMC rollout. They are supplementary structured data that accompany the narrative sections of Module 3 submissions.
In eCTD v3, incorporating FHIR-formatted PQ-CMC files alongside narrative PDFs requires workarounds that the v3 architecture does not natively accommodate — the architecture was designed for documents, not for structured data objects with their own validation schemas and data relationships. eCTD v4 is designed from the ground up to accommodate both. The v4 manifest can represent a FHIR JSON file as a typed document object with its own manifest record, its relationship to the narrative PDF it supplements, its section assignment, and its lifecycle status. The architecture treats the FHIR file and the narrative PDF as complementary data objects within the same submission, rather than forcing one into the organizational framework designed for the other.
This convergence is not a future aspiration. ICH M8 eCTD v4.0 explicitly addresses the accommodation of structured data content. FDA’s CDER and CBER have accepted new NDA, BLA, ANDA, IND, and Master File submissions in eCTD v4.0 format on a voluntary basis since September 16, 2024, with future implementation phases addressing forward compatibility for existing v3.2.2 applications; FDA has not published a mandatory v4.0 go-live date as of this writing. EMA opened optional use of eCTD v4.0 for new centrally authorised marketing authorization applications on December 22, 2025, with mandatory use for the centralized procedure anticipated in the 2027–2028 window pending final confirmation, while Japan’s PMDA became the first ICH region to mandate v4.0 outright, effective April 1, 2026. eCTD v3.2.2 remains the required baseline format for the large majority of FDA and EMA submissions during this transition period. But the CMC teams that understand the v4 architecture now — and that are building their PQ-CMC structured data capabilities in the context of v4 compatibility — are not doing redundant work. They are building the single integrated CMC data capability that the convergence of PQ-CMC and eCTD v4 requires.
The thesis I stated at the opening of this article is the operational conclusion: the CMC teams that understand this architecture shift will be positioned to integrate PQ-CMC structured data into v4 submissions seamlessly, while those that do not will face the same retroactive data architecture work that PQ-CMC alone has required. The pattern of retroactive remediation — building the capability after the regulatory requirement has arrived — is expensive, disruptive, and avoidable. The eCTD v4 technical specifications are publicly available. The FDA and EMA implementation guidance is published and being updated. The time to assess readiness is now, not at the implementation deadline.
THE XGENE ECTD V4 CMC READINESS AND TRANSITION PROGRAM
The XGene eCTD v4 CMC Readiness and Transition Program provides the structured assessment and implementation roadmap that CMC teams need to transition from v3 document compilation workflows to v4 data-centric submission architecture.
The program delivers:
v4 vs. v3 Architecture Gap Analysis for Module 3 — A detailed technical assessment of the current v3 submission authoring workflow mapped against v4 requirements, identifying gaps in XML manifest generation capability, document type controlled vocabulary coverage, lifecycle operation implementation, and regional metadata compliance for both FDA and EMA.
XML Metadata Schema Mapping for CMC Document Types — A complete mapping of Module 3 document types — drug substance and drug product specifications, development reports, stability data, facility information, container closure documentation — to the v4 XML document type controlled vocabulary and manifest structure, providing the CMC team with a v4-ready document classification framework.
PQ-CMC FHIR Integration Architecture for v4 Submissions — A technical architecture design for incorporating PQ-CMC FHIR JSON files alongside narrative Module 3 PDFs in v4 submission bundles, including manifest structure, document relationship design, and section assignment strategy.
Submission Authoring System Vendor Assessment for v4 Capability — A structured evaluation of the current submission publishing system’s v4 capability, using the FDA and EMA v4 technical implementation guides as the assessment criteria, with gap identification and vendor upgrade or replacement recommendations.
CMC Team Training on v4 Document Lifecycle Operations — Training for regulatory operations and CMC submission teams on the v4 lifecycle operation model — new, replace, delete, append — with comparison to v3 sequence-based lifecycle management and practical guidance on post-approval CMC submission management under v4.
Transition Roadmap Aligned to FDA and EMA Implementation Timelines — A phased implementation roadmap that sequences v4 readiness investments against the FDA and EMA mandatory v4 implementation timelines, ensuring the organization is positioned for v4 compliance before mandatory requirements take effect.