PMDA eCTD v4.0 for Medical Devices: Complete Transition Guide After the April 2026 Mandate

Japan's PMDA made eCTD v4.0 mandatory on April 1, 2026. This guide covers what changed, Japan-specific Module 1 requirements, medical device submission differences, and how to prepare compliant submissions.

Japan's Pharmaceuticals and Medical Devices Agency (PMDA) made eCTD v4.0 the only accepted electronic submission format for new applications effective April 1, 2026. Japan is the first major regulatory authority to mandate the next-generation eCTD standard, making this the single most consequential regulatory operations change of the year for any company submitting to the Japanese market.

This guide covers what the mandate means in practice, how eCTD v4.0 differs from v3.2.2, Japan-specific Module 1 requirements that differ from FDA and EMA, medical device submission considerations unique to PMDA, and the concrete steps you need to take to submit compliant dossiers.

What Changed on April 1, 2026

As of April 1, 2026, PMDA no longer accepts eCTD v3.2.2 for any new applications. This applies across all product categories: pharmaceuticals, medical devices, and in vitro diagnostics. The mandate was preceded by a technical pilot completed in Q2 2021, followed by a voluntary acceptance period from 2022. PMDA published its Japan-specific implementation guide and validation criteria in stages between 2022 and 2025, giving the industry time to prepare.

Key implications of the mandate:

All new submissions must use eCTD v4.0. This includes new drug applications, medical device approval applications, and IVD submissions. There is no grace period and no option to submit in v3.2.2 for new dossiers.
Existing dossiers in v3.2.2 can continue in v3.2.2. You do not need to retroactively convert ongoing sequences. However, once you choose to switch a particular dossier to v4.0, you must re-baseline the entire dossier in the new format. There is no backward compatibility between v3.2.2 and v4.0.
Supplemental and variation submissions to existing v3.2.2 dossiers may continue in v3.2.2 until PMDA announces otherwise. Monitor PMDA notifications for any changes to this policy.
Lifecycle after re-baselining. Once a dossier has been re-baselined in v4.0, all subsequent submission units for that dossier must use v4.0.

The mandate is not limited to drugs. Medical device and IVD submissions are included, and device manufacturers must address the unique structural and metadata requirements that apply to their product types within the eCTD v4.0 framework.

eCTD v3.2.2 vs v4.0: Key Differences

eCTD v4.0 is not an incremental update. It is a fundamentally different architecture built on the HL7 Regulated Product Submission (RPS) standard, replacing the document-centric, folder-hierarchy model that the industry has used for over two decades.

Architectural Changes

Under eCTD v3.2.2, a submission consists of a hierarchical folder structure with separate XML files (index.xml for the Table of Contents, regional XML for Module 1, and Study Tagging Files for clinical data). The XML backbone is defined by a DTD that is difficult to extend. Each sequence in a dossier is a separate package, and documents are physically duplicated across sequences when they are resubmitted or carried forward.

Under eCTD v4.0, a submission is a single XML exchange message (submissionunit.xml) that encapsulates all content from Module 1 through Module 5. The structure is flat rather than hierarchical: files can reside at the root level, and the XML message dictates where each document appears in the Table of Contents. This message-based architecture uses HL7 v3 RPS (Regulated Product Submission) format, which supports structured metadata, controlled vocabularies, and bi-directional communication between sponsors and regulatory authorities.

Comparison Table

Feature	eCTD v3.2.2	eCTD v4.0
Architecture	Folder hierarchy with DTD-validated XML	Flat, message-based (HL7 RPS)
XML Structure	Multiple XML files (index, regional, STF)	Single XML exchange message (submissionunit.xml)
Metadata	Limited, fixed by DTD	Extensive, driven by controlled vocabularies (ICH CV and regional CV)
Document Lifecycle	Basic (replace, delete)	Granular (new, replace, delete, update) with partial lifecycle support
Document Reuse	Physical duplication across sequences	UUID-based reuse without physical resubmission
Content Grouping	Study Tagging Files (STFs)	Document Groups with Context of Use and Keywords
Validation	Manual and tool-based	Comprehensive automated validation (350+ checks for JP)
Sequence Numbering	Four-digit (e.g., 0000, 0001)	Starts at 1, continues incrementally
Terminology	Dossier / Sequence	Application / Submission Unit
Structured Data	Limited	Native support with ISO 21972 metadata
Two-way Communication	Not supported	Supported in the HL7 RPS framework
Global Harmonization	Regional variations require separate packages	Single global specification with regional CV extensions

Practical Implications for Publishers

The shift from v3.2.2 to v4.0 means you cannot simply rearrange files from one format into another. The v4.0 XML is significantly less human-readable than v3.2.2. Constructing and reviewing the XML requires dedicated publishing software or RIMS (Regulatory Information Management System) tools that support the HL7 RPS schema. Legacy eCTD v3.x publishing tools will not work.

The terminology has also changed. What you previously called a "dossier" is now an "application." What was a "sequence" is now a "submission unit." Study Tagging Files have been eliminated and replaced by Document Groups that use Context of Use keywords and Priority Numbers for ordering. A new lifecycle status called "update" allows metadata changes without resubmitting the physical file.

Global eCTD v4.0 Implementation Timeline

Japan is the first mover, but every major regulatory authority is on a path toward eCTD v4.0. Understanding the global timeline helps you plan a unified transition strategy rather than treating each region as a separate project.

Authority	Voluntary Start	Mandatory Date	Notes
Japan (PMDA)	2022	April 1, 2026	First major authority to mandate. Applies to drugs, devices, and IVDs.
EU (EMA)	Late 2025 (pilot)	2026-2027 for CAPs	Centrally authorised products first. National procedures (MRP/DCP/NAP) will follow.
US (FDA)	September 2024	Projected ~2029	Voluntary for new applications since Sep 16, 2024. Mandatory date not yet finalized.
Health Canada	2026 (planned)	Projected 2027-2028	Technical pilot completed in 2023.
Swissmedic	2024 (pilot)	Projected ~2028-2030	Technical pilot ongoing.
Australia (TGA)	2026 (planned)	TBD (likely 2028+)	Following EMA/FDA lead.
Brazil (ANVISA)	Late 2025 (pilot)	TBD	Pilot slated.

The fact that Japan mandated first means that any company with a global submission pipeline should prioritize Japan readiness. The lessons learned and infrastructure built for PMDA will directly support your FDA and EMA v4.0 transitions when those mandates arrive.

Japan-Specific Module 1 Requirements

This is where most companies stumble. Module 1 in Japan is not a simple localization of the US or EU Module 1. PMDA has unique structural, language, and metadata requirements that are codified in the ICH eCTD v4.0 Implementation Guide for Japan (currently v1.5.0) and the Japan-specific controlled vocabulary (JP CV) published by PMDA.

Language Requirements

All documents submitted in Module 1 must be in Japanese or accompanied by Japanese translations. This is not new with v4.0, but the metadata framework in v4.0 adds a new dimension: the XML metadata itself must accommodate Japanese language display names. JP eCTD v4.0 specifications define value types that allow UTF-8 characters, including full Japanese character sets. This means metadata fields, titles, and keywords can and must contain Japanese text in many cases.

Japan-Specific Controlled Vocabulary (JP CV)

In addition to the ICH-controlled vocabulary (ICH CV) that applies globally, PMDA requires a Japan-specific controlled vocabulary (JP CV). The JP CV covers:

Product categories specific to Japan
Document types unique to the Japanese regulatory framework
Submission types and lifecycle operations specific to PMDA
Regional code lists managed by PMDA with their own OID identifiers

When submitting, you must provide the valid versions of both ICH CV and JP CV as of the earliest application date included in the eCTD. The OID assigned to each code list indicates its version number. PMDA publishes the "JP OID Listing" in its domestic implementation package, and you must reference these OIDs in the XML message.

Unique JP Module 1 Sections

The Japan Module 1 structure includes sections that do not exist in US or EU implementations. Several new sections were introduced specifically for JP eCTD v4.0:

jp_m1.13.4.1 -- Documents submitted to PMDA (Section changed from the previous M1-13-04-01 structure)
jp_m1.13.4.1.1 -- List of target values/settings in the manufacturing method column of the approval application
jp_m1.13.4.1.2 -- Documents related to new additives
jp_m1.13.4.1.3 -- Other documents
jp_m1.13.4.2 -- Documents submitted to MHLW (copies)
jp_other -- Used only when there is no other available means and there is an unavoidable reason. Prior consultation with the review authority is required before use.

The folder structure within Module 1 requires a regionally specified folder named "jp" (m1/jp/), and additional subfolders can be used as needed. The cover letter for eCTD (cover.pdf) must be included in m1/jp/ and does not need to be referenced from the eCTD v4.0 XML message.

Metadata Differences from FDA and EMA

The following attributes behave differently or have different requirements for Japan compared to US and EU:

Attribute / Feature	Japan (PMDA)	US (FDA)	EU (EMA)
Category Event	Allowed	Not applicable	Not applicable
Contact Party	Excluded	Required	Required
File Description	Required for clinical pharmacology documents	Standard	Standard
Dataset Encoding	.xpt files require character code attribute	Standard	Standard
Language Display	Japanese text required in many metadata fields	English	EU language requirements
Cover Letter	Physical inclusion in m1/jp/ required; not referenced in XML	Referenced in XML	Referenced in XML
Submission Methods	Gateway system or physical media (DVD-R/BD-R)	Electronic gateway	CESP / electronic

Using US or EU Module 1 templates for a Japan submission will result in validation failures. You must use the JP-specific Module 1 implementation guide and JP CV.

Medical Device-Specific Considerations

Medical device submissions to PMDA have unique structural and regulatory requirements that interact with the eCTD v4.0 framework in specific ways. If your experience with eCTD is primarily pharmaceutical, you need to account for these differences.

Device Classification and Submission Pathways

PMDA classifies medical devices into four classes based on risk, following the IMDRF/GHTF framework:

Class	Risk Level	Registration Pathway	Review Body
Class I	Extremely low risk	Notification (Todokede)	PMDA (administrative only, no review)
Class II	Low to moderate risk	Certification (Ninsho) or Approval	Registered Certification Body (RCB) or PMDA
Class III	Moderate to high risk	Approval (Shonin) or Certification	PMDA or RCB
Class IV	High risk	Approval (Shonin)	PMDA/MHLW

Class I devices require only a pre-market notification (Todokede) to PMDA. This is a self-declaration process with no substantive review. Class II devices with existing certification standards go through pre-market certification (Ninsho) by a Registered Certification Body (RCB) such as the Japan Quality Assurance Organization (JQA) or TUV. Class II devices without certification standards, most Class III devices, and all Class IV devices require pre-market approval (Shonin) from MHLW based on PMDA review.

The practical impact on your eCTD submission: the submission type and regulatory pathway determine which Module 1 sections are required, what level of technical documentation is needed, and whether clinical data is expected.

STED Format Within eCTD

For Class III and Class IV device submissions (and Class II devices requiring approval), PMDA expects technical documentation in the Summary of Technical Documentation (STED) format. STED follows the GHTF/IMDRF structure and is mapped into the CTD Modules 2-5 within the eCTD framework. Key STED components include:

Device description and specification
Essential principles checklist
Risk analysis and management (aligned with ISO 14971)
Clinical evaluation data
Non-clinical testing reports
Labeling and instructions for use (in Japanese)

When preparing eCTD v4.0 for a medical device, the STED content is organized within the CTD module structure, with Context of Use keywords and Document Groups used to associate related clinical study reports, test data, and risk analysis documents.

QMS Compliance: MHLW Ordinance No. 169

Japan does not accept ISO 13485 certification alone. Medical device quality management systems must comply with MHLW Ministerial Ordinance No. 169 (2004), titled "Standards for Manufacturing Control and Quality Control for Medical Devices and In-Vitro Diagnostics." MO 169 was last revised in March 2021 to align with ISO 13485:2016, with a compliance deadline of March 25, 2024.

MO 169 has three chapters. Chapter 2 closely mirrors ISO 13485:2016. Chapter 3 contains Japan-specific additional requirements including local document retention rules, supplier oversight obligations, and provisions unique to the Japanese regulatory framework. Chapter 4 addresses requirements for re-manufactured single-use devices.

QMS conformity is investigated in parallel with the product registration review. PMDA or the RCB will audit the QMS of the MAH/DMAH, the manufacturer, and all manufacturing facilities including contract manufacturers. If any single entity is found non-compliant with MO 169, the entire QMS is determined non-compliant.

Foreign Manufacturer Registration (FMR)

Before a foreign manufacturer can register any medical device in Japan, the manufacturer must obtain Foreign Manufacturer Registration (FMR) from PMDA. The FMR application includes information about manufacturing facilities, quality systems, and the products to be manufactured. FMR certificates are valid for five years, and MHLW recommends beginning renewal at least five months before expiration.

FMR is a prerequisite for product registration, not a parallel process. Without a valid FMR, your MAH cannot file a device application.

Marketing Authorization Holder (MAH) / Designated MAH (DMAH)

Under the Pharmaceutical and Medical Device (PMD) Act, only a licensed Marketing Authorization Holder (MAH) based in Japan can submit regulatory applications to PMDA. Foreign manufacturers cannot submit directly. You must appoint either:

MAH: A Japanese entity that takes full legal responsibility as the manufacturer of record. The device is registered under the MAH's name.
Designated MAH (DMAH): Under the Foreign Special Approval System (FSAS), available for Class II, III, and IV devices, a foreign manufacturer can register products under its own name but must appoint a DMAH to handle local QMS duties (per Article 72-3 of MO 169) and Good Vigilance Practice obligations (per MHLW Ministry Ordinance No. 135).

The MAH/DMAH relationship affects your eCTD submission because the applicant information, product information, and responsible party metadata in Module 1 must correctly reflect the MAH/DMAH structure. For a deeper understanding of the Japanese regulatory landscape for devices, see the Japan PMDA approval guide.

Technical Implementation Steps

Transitioning from eCTD v3.2.2 to v4.0 is not just a publishing change. It is an authoring, metadata management, and infrastructure change. The following steps outline a practical implementation path.

Step 1: Conduct a Gap Analysis

Audit your current publishing systems, RIMS, document management systems, and SOPs. Identify every component that will not support HL7 v3 RPS schemas, JP CV, or the v4.0 XML message format. This includes:

Publishing software versions
Validation engine compatibility
RIMS metadata field configurations
Document templates and naming conventions
Staff skill sets

Step 2: Upgrade Your Technology Stack

Your RIMS must support HL7 RPS format and must capture v4.0 metadata fields at authoring time, not patch them in during publishing. The new metadata fields include document context, submission context, product context, keywords, and grouping attributes. If your RIMS cannot handle these, you will need to upgrade or replace it.

Your publishing software must be able to generate the submissionunit.xml in HL7 v3 RPS format, apply JP CV codes, and run PMDA validation rules. Major commercial platforms (such as Veeva Vault RIM, LORENZ docuBridge, Extedo RIM, and others) have released v4.0-compatible versions, but you must verify that the JP-specific components are included and up to date.

Step 3: Train Your Team on XML Metadata Authoring

eCTD v4.0 XML is not human-readable in the way that v3.2.2 XML was. You cannot manually open the XML in a text editor and make meaningful changes. Staff who previously authored or reviewed the XML backbone must be trained on:

The HL7 RPS message structure
Controlled vocabulary management (ICH CV and JP CV)
UUID assignment and document reuse workflows
Context of Use and Keyword tagging
Lifecycle operations (new, replace, delete, update)
The new terminology (application vs. dossier, submission unit vs. sequence)

Treat metadata authoring as a regulated activity. It requires the same rigor and quality control as document authoring.

Step 4: Run PMDA Validation Early and Often

PMDA publishes its JP Check Items List, which as of v1.6.0.0 contains over 350 validation rules covering message structure, controlled vocabulary, lifecycle attributes, and content requirements. These checks validate the XML message structure, metadata correctness, document referencing, and regulatory compliance.

Run validation at multiple stages: after metadata authoring, after document assembly, and as a final QC before submission. Catching validation errors early is orders of magnitude cheaper than discovering them after submission to PMDA.

Step 5: Execute Pilot Submissions

Before filing a real application, conduct at least one pilot submission through PMDA's gateway system. This tests your entire workflow end-to-end: document preparation, metadata tagging, XML generation, validation, packaging, and transmission. Several companies completed voluntary v4.0 submissions during the 2022-2026 voluntary period. If you have not done so, consider a pilot with a low-complexity submission to surface process gaps.

Step 6: Define Your Re-Baselining Policy

For each existing v3.2.2 dossier, you need a policy for when (and whether) to re-baseline to v4.0. Considerations include:

The number of remaining sequences expected for the dossier
Whether the dossier will be submitted to other regions in v4.0
The cost of re-baselining versus the operational overhead of maintaining two formats
PMDA's future guidance on when existing dossiers must transition

Re-baselining is a one-way door. Once a dossier is converted to v4.0, it cannot revert to v3.2.2.

Common Pitfalls and How to Avoid Them

Using US/EU Templates for Japan Module 1

This is the single most common error. Japan Module 1 has unique sections (jp_m1.13.4.1.x, jp_other), unique metadata requirements (Category Event allowed, Contact Party excluded), and the JP CV that do not exist in US or EU implementations. Copying a US Module 1 structure and translating the document titles into Japanese will fail PMDA validation. Always start from the JP Implementation Guide and JP CV.

Treating Metadata as an Afterthought

In eCTD v3.2.2, metadata was relatively simple and could be handled during publishing. In v4.0, metadata is the backbone of the submission. Context of Use keywords, document UUIDs, lifecycle attributes, and controlled vocabulary codes must be defined at authoring time. If you leave metadata to the publishing step, you will face extensive rework and validation failures.

Underestimating Data Remediation Timelines

If your existing documents do not have the metadata required for v4.0, you will need to remediate them. This includes assigning UUIDs, defining Context of Use, tagging keywords, and ensuring document types match the JP CV. Data remediation often takes longer than document publishing. Build this into your project timelines from the start.

Not Testing Against the PMDA Validator Early

Companies that wait until the final QC step to run PMDA validation often discover systemic issues (incorrect CV versions, missing JP-specific attributes, wrong lifecycle operations) that require fundamental rework. Integrate validation into your authoring workflow and run checks incrementally.

Mismatched Lifecycle Attributes

eCTD v4.0 supports granular lifecycle operations, but getting them wrong causes validation failures and can corrupt the dossier lifecycle. Common mistakes include applying "replace" when "update" is appropriate (update handles metadata changes without resubmitting the file), using incorrect UUID references when reusing documents across submission units, and failing to maintain lifecycle consistency across related documents in a Document Group.

Incorrect Document Types and Naming Conventions

The JP CV defines specific document types that must be used. Using a generic or US/EU document type where a JP-specific type is required will trigger a validation error. File naming conventions also differ. Module 1 files must follow the JP-specific folder structure (m1/jp/) and naming rules defined in the JP Implementation Guide.

Practical Checklist for Japan eCTD v4.0 Readiness

Use this checklist to assess your organization's preparedness for PMDA eCTD v4.0 submissions.

Strategy and Planning

Confirm which active dossiers will continue in v3.2.2 and which will be re-baselined to v4.0
Establish a re-baselining timeline for each dossier
Identify all upcoming Japan submissions and confirm they will use v4.0
Assign a project lead for the v4.0 transition

Technology and Systems

Verify that your RIMS supports HL7 v3 RPS schema and JP CV
Verify that your publishing software generates valid submissionunit.xml for JP
Install and configure PMDA validation rules (JP Check Items List v1.6.0.0 or later)
Test end-to-end workflow with a mock submission
Confirm your eCTD viewer supports v4.0 format

Authoring and Metadata

Train all regulatory publishing staff on v4.0 XML structure and terminology
Train regulatory affairs staff on metadata authoring requirements
Document your controlled vocabulary management process (ICH CV and JP CV version tracking)
Create JP-specific Module 1 templates based on the JP Implementation Guide
Define UUID assignment and document reuse procedures

Quality and Validation

Integrate PMDA validation checks into your authoring workflow (not just final QC)
Establish a process for tracking and resolving validation errors
Update SOPs to reflect v4.0 terminology and processes
Conduct at least one pilot submission through PMDA's gateway

Japan-Specific Requirements

Confirm all documents are in Japanese or accompanied by Japanese translations
Verify MAH/DMAH information is correctly configured in Module 1 metadata
Confirm FMR is current for all foreign manufacturing sites
Verify QMS compliance with MHLW Ordinance No. 169 (not just ISO 13485)
For medical devices, confirm STED documentation is structured within CTD modules
Ensure cover.pdf is included in m1/jp/ per JP requirements

Cross-Reference with Other Markets

If submitting the same product to the US, confirm your FDA eSTAR strategy is independent of your eCTD strategy (eSTAR is for 510(k)/De Novo, not eCTD)
If submitting to EU, confirm your EMA v4.0 readiness timeline aligns with your JP readiness
Ensure controlled vocabulary versions are tracked separately for each region

Frequently Asked Questions

Does the April 2026 mandate apply to medical devices, or only to pharmaceuticals?

It applies to all product types regulated by PMDA: pharmaceuticals, medical devices, and IVDs. Medical device manufacturers must submit in eCTD v4.0 format for all new applications filed on or after April 1, 2026.

Can I continue submitting supplements and variations to an existing v3.2.2 dossier in v3.2.2?

Yes, as of the mandate date. PMDA allows ongoing dossiers to continue in v3.2.2 for subsequent sequences. Once you re-baseline a dossier to v4.0, all future submission units for that dossier must use v4.0. Monitor PMDA notifications for any deadlines on converting existing dossiers.

Is eCTD v4.0 backward compatible with v3.2.2?

No. The two formats are architecturally incompatible. v4.0 uses HL7 RPS message-based architecture with a single XML exchange message, while v3.2.2 uses a folder hierarchy with DTD-validated XML. You cannot convert a v3.2.2 sequence into a v4.0 submission unit by rearranging files. Re-baselining requires building the entire dossier from scratch in v4.0 format.

What happens if I submit in v3.2.2 after April 1, 2026?

PMDA will reject the submission. The gateway system and reception desk are configured to accept only v4.0 format for new applications. There is no grace period.

Do I need different publishing software for Japan v4.0 versus US/EU v4.0?

Not necessarily different software, but you need software that supports JP-specific components: the JP CV, JP Module 1 sections, JP validation rules, and JP OID references. Verify with your vendor that the Japan regional package is included and current. Major platforms support multi-region v4.0 publishing, but JP support may be licensed separately or require specific configuration.

For medical devices, does the STED format change under eCTD v4.0?

The content requirements of STED remain the same. What changes is how STED content is packaged and referenced within the eCTD structure. Under v4.0, STED documents are organized using Context of Use keywords and Document Groups rather than the folder hierarchy used in v3.2.2. The technical content of your STED does not need to change, but the metadata tagging and structural referencing does.

How many validation checks does PMDA apply to eCTD v4.0 submissions?

The PMDA JP Check Items List v1.6.0.0 contains over 350 validation rules covering message structure (sender/receiver identification, OIDs), controlled vocabulary (ICH CV and JP CV version compliance), Context of Use, Document Groups, lifecycle attributes, and content-specific requirements. This number will likely grow as PMDA updates the check items list. Always use the latest published version.