For PMDA, a clean validation run is only part of the story. The real pressure is in the documentation layer, rule-version timing, reviewer guide detail, and how clearly the package explains itself at submission.

-
StudySAS • SDTM • Define.xml • Regulatory Submissions

PMDA’s Extra Documentation Burden — What Programmers Should Prepare Before Handoff

For PMDA, a clean validation run is only part of the story. The real pressure is in the documentation layer, rule-version timing, reviewer guide detail, and how clearly the package explains itself at submission.

Most SDTM teams have a handoff checklist.

Datasets locked.
define.xml generated.
Reviewer guide drafted.
P21 run clean.

Done.

For PMDA, that checklist is not complete.

The submission package is not just what you validated.
It is:

  • how you validated
  • what you validated with
  • what changed between runs
  • how clearly you explained every finding that was not corrected

That last part is where PMDA feels fundamentally different from FDA.
Not in the data standards. In the documentation standards.

Validation philosophy

The core difference in validation philosophy

Both FDA and PMDA use Pinnacle 21 Enterprise.

But they do not treat the results the same way.

FDA has deprecated severity classification. There is no formal Reject, Error, or Warning requirement driving submission acceptance. The expectation is simple:

Every unresolved issue must be explained.

PMDA is different.

PMDA maintains a strict severity hierarchy:

  • Reject
  • Error
  • Warning

This is not cosmetic.

Reject-level findings stop review.

PMDA will not begin or continue review when:

  • Reject issues are present
  • validation cannot run because files are corrupt or malformed

This is enforced at the gateway level.

According to Pinnacle 21 documentation, applications have been halted due to unresolved Reject findings.

Source: Pinnacle 21 Help Center, PMDA Engine Update 2211.0

For programmers, this changes your priority:

Reject findings must be fully resolved before handoff. Everything else comes after.
Engine version control

Validation engine version is submission metadata, not background context

For FDA, the reviewer guide typically records:

  • tool used
  • issues remaining

That is usually enough.

For PMDA, the validation engine version is part of the submission record.

PMDA publishes acceptable rule versions tied to submission windows.

Practical view:

Version 3.0 → PMDA 2010.2 → Jan 2022 – Mar 2025
Version 4.0 → PMDA 2211.1 → Apr 2023 – Mar 2026
Version 5.0 → PMDA 2311.0 → Apr 2024 – Mar 2027
Version 6.0 → PMDA 2411.0 → Apr 2025 onward

Source: PMDA Electronic Data Review Page

PMDA runs your package through its own validation environment and compares results against your reviewer guide.

If your engine and PMDA’s engine differ:

  • findings differ
  • explanations don’t match
  • queries follow
Submission timing

The rule-version problem most teams miss

Validation is tied to submission timing.

A common scenario:

  • study validated months earlier
  • submission delayed
  • new engine becomes current
  • new findings appear

Now your reviewer guide no longer reflects what PMDA sees.

PMDA states:

  • submission validation uses the current acceptable rule set
  • follow-up data may use the rule set active at filing

Source: PMDA Electronic Review Page

If your validation engine is no longer acceptable at submission time, validation must be rerun, findings must be reassessed, and the reviewer guide must be updated.

This is not a documentation update.

It is a re-validation requirement.

Multi-study applications

One engine per application

For multi-study programs, PMDA expects one validation engine version across the entire application.

During development:

  • different studies may use different engines

At submission:

  • everything must align

If:

  • Study A → PMDA 2211.1
  • Study B → PMDA 2311.0

Someone must reconcile that before submission.

It does not fix itself.

Reviewer guide detail

What the reviewer guide must actually contain

The PMDA reviewer guide is not a summary.

It is a structured validation record.

It must include:

  • validation tool and version
  • engine version, explicitly named
  • rule version
  • for each unresolved finding:
    • rule ID
    • severity
    • justification
Reject findings must not remain.

If they do, you do not have a documentation issue.
You have a submission-blocking issue.

Example language

What “good” looks like

Validation Summary: Initial validation performed using Pinnacle 21 Enterprise with PMDA Engine v5.0. Final validation performed prior to submission using PMDA Engine v6.0, which is the acceptable version at the time of submission. New findings identified in final validation were reviewed and assessed. All Reject-level issues were resolved prior to submission. Remaining findings are documented with justification in Section 6.3.
Form A

Form A is not the SDSP, and timing matters

PMDA requires the Explanation of Electronic Study Data, Form A.

  • no longer required before initial submission for applications dated from October 2023 onward
  • still required for pre-NDA consultation
  • still required for supplemental submissions
  • must be updated if PMDA requests clarification

Before handoff, confirm:

  • Form A is current
  • it aligns with the reviewer guide
  • it reflects the validation engine used

Mismatch between Form A and the reviewer guide is a known source of PMDA queries.

Define.xml control

Define.xml is a validation object, not a publishing step

PMDA independently validates:

  • dataset vs dataset consistency
  • define.xml vs dataset consistency
  • XML structure

Source: PMDA Technical Conformance Guide

Define.xml 1.0 is not accepted.
2.0 and 2.1 are required.

If your pipeline still produces Define.xml 1.0, that is a Reject-level issue.

PMDA also strongly expects Analysis Results Metadata, ARM, in ADaM define.xml. This documents the link between define.xml, analysis outputs, and CDISC standards.

Define.xml must reflect:

  • final datasets
  • final derivation logic
  • final value-level metadata

If it lags, your package is not ready.

Pre-handoff QC

Pre-handoff checklist for PMDA

Before calling a package ready:

  • Define.xml is 2.0 or 2.1
  • Validation engine version is explicitly documented
  • Engine version is valid for the submission date
  • All Reject findings are resolved
  • Error findings are documented in the reviewer guide and Form A
  • Rule IDs, severity, and explanations are included
  • Validation logs are archived
  • Engine version is unified across studies
  • Submission date is recorded for revalidation risk
The FDA checklist is shorter. That is the point.

The question PMDA is actually asking

FDA asks:
Did you validate your data?

PMDA asks:
Can you prove how you validated, with what, when, and is that still valid at submission?

Your handoff package is the answer.

Sources

References