If you are filing in Japan on eCTD v4.0, the question that matters is simple: will PMDA accept the package the first time? The answer depends on rules that are more precise — and in places easier to misread — than any other region’s.

Japan’s move to eCTD v4.0 brings a validation regime that is precise, extensive and, in places, easy to misread. PMDA publishes its rules not just as a document but as configuration: tables that say which element is checked, by which check function, with which parameters, and whether the rule is currently switched on.

That is good news for anyone building or evaluating a publishing tool, because rules published as data can be enforced as data. It also hides a few traps that are worth understanding before your first Japan v4.0 submission.

The families of rules

PMDA’s checks fall into recognisable families:

  • Required elements. The backbone of every submission unit — the receiving device, submission unit identifiers and codes, the sequence number, submission and application identity, and the category event — must be present.
  • Elements that must not appear. A large family of rules names elements or attributes that must be absent. These are easy to overlook, because a tool that never writes them will never fail them on its own output.
  • Fixed values, code systems and lengths. Values that must be exact, the identifiers of the code systems in use, codes that must exist in the vocabulary their code system names, and length limits.
  • Identifiers and occurrences. Identifier formats, how many times an element may appear under its parent, and uniqueness within a submission unit.
  • Permitted characters. Brand and generic names, the applicant name, document titles and keyword values must use PMDA’s permitted character set.
  • Study data. File tags for Japanese-terminology datasets, and file-naming and length rules for study data.
  • The package on disk. Folders, file names, sizes and the checksum that anchors the package, and agreement between the sequence number and its folder.

Where teams get caught out

  • Conditions hidden in the rule text. Some requirements apply only “at first-version submission” or “in the case of” something — and that condition appears only in the description, not in the structured rule. Read literally, the rules contradict each other, and either your first sequence or every later one fails.
  • Retired rules coming back. PMDA switches rules off with an effective date. A tool that ignores the date can fail you on a rule that no longer applies.
  • Only checking your own output. A tool that only validates what it produced will pass problems in packages from a partner or a previous vendor — which is exactly where they tend to be.

How DnXT approaches it

DnXT publishes and validates Japan eCTD v4.0 against PMDA’s configuration as published:

  • PMDA’s configuration files are bundled as published, so a PMDA update is a file replacement rather than a code change.
  • Rules PMDA has switched off are excluded by their effective window.
  • Conditions stated only in the rule text are applied, so first and later sequences are judged correctly.
  • The same checks run on imported and externally authored packages.
  • New rule families are verified against PMDA’s own reference submission and real published sequences before release — so a passing result is a meaningful one, not the product of a test written to match the code.

Before your first Japan v4.0 submission

Ask any vendor three questions. How do you handle rules whose conditions are only in the text? How do you treat rules PMDA has retired? And will your validator check a package you did not produce? The answers will tell you quickly whether the tool reads PMDA’s rules, or only its own output.

DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see Japan eCTD v4.0 validation against PMDA’s rules on a package of your own.