Japan eCTD v4.0 — PMDA Rules, Enforced Before You Submit
Japan eCTD v4.0, Checked Against PMDA’s Own Rules
PMDA publishes its validation rules as configuration. DnXT reads that configuration directly — so a Japan eCTD v4.0 package is checked the way PMDA will check it, whether DnXT published it or not.
Japan v4.0 rules are precise — and some only make sense in Japanese
PMDA’s eCTD v4.0 validation rules cover what must appear, what must not, how often, in which code system, at what length and in which characters. Several rules carry conditions — “at first-version submission”, “in the case of” — that exist only in the prose, not in a structured column.
A validator that reads the columns literally will fail every later sequence, or every first one. A publishing tool that only checks what it generates itself will pass a package someone else authored that PMDA will reject.
DnXT validates against PMDA’s configuration as published, with those conditions handled, and runs the same checks over any package.
Built for the people who own the outcome
Japan regulatory operations
Know before submission that a v4.0 package meets PMDA’s rules, including the conditional ones.
Global publishing teams
Bring Japan into the same publishing and validation process as your other regions.
Partners filing in Japan
Validate a package your partner or vendor produced before it goes to PMDA.
What is checked
Required and forbidden elements
The elements PMDA requires and the elements it forbids, including the rules that apply only at first-version submission or only in particular cases.
Values and code systems
Fixed values, code-system identifiers, codes that must exist in the vocabulary their code system names, and length limits.
Identifiers and occurrences
Identifier format, how many times each element may appear under its parent, and uniqueness within a submission unit.
Permitted characters
PMDA’s permitted character set for brand and generic names, the applicant name, document titles and keyword values.
Study data
Japanese-terminology dataset tags and PMDA’s study-data file naming and length rules.
The package on disk
Folders, file names, sizes and the checksum that anchors the package, plus the agreement between sequence number and folder.
How we make sure the rules are right
PMDA’s configuration, bundled as published
Rules are derived from PMDA’s own configuration files, so a PMDA update is a file replacement rather than a code change.
Effective dates respected
Rules PMDA has switched off are excluded by their effective window — a retired rule never comes back because an old flag still says “on”.
Conditions handled, not flattened
Where a requirement depends on a condition stated only in the rule text, the condition is applied, so first and later sequences are each judged correctly.
Verified on real packages first
New rule families are run against PMDA’s reference submission and real published sequences before release, so a passing result means something.
Frequently asked
Can DnXT publish Japan eCTD v4.0 as well as validate it?
Yes. DnXT publishes Japan v4.0 submissions and validates them, alongside v3.2.2 and other regions, from the same platform.
Does validation work on packages DnXT did not create?
Yes. The same checks run on imported and externally authored packages — which is where forbidden elements and missing required ones usually appear.
How quickly do you follow PMDA rule updates?
Because the rules are read from PMDA’s configuration files, an update is a file replacement followed by our verification run against real packages.
Do you support other regions on eCTD v4.0?
Yes. See eCTD publishing and multi-regional compliance for the regions DnXT supports.
Submit to PMDA with the rules already checked.
Send us a Japan v4.0 package — yours or a partner’s — and we will walk you through what PMDA’s rules say about it.
