PMDA SDTM Submission Requirements vs FDA: Where They Actually Diverge
Global teams often say, "PMDA and FDA both take SDTM, so one package should work for both." That is only half true.
At the model level, the overlap is real. Both agencies expect CDISC-based submissions, SAS XPT v5 transport files, define.xml, and reviewer-facing documentation. But the real question is not whether your SDTM is CDISC-compliant. The real question is this: will the same study package survive both agencies' rule engines, review workflows, and local review habits without late rework?
For teams that build for FDA first, the answer is often no, at least not without adjustment. The differences that matter most are not random. They cluster around standards catalog timing, PMDA pre-submission consultation, Japanese text handling, clinical pharmacology traceability, validation behavior, and Japanese date and time conventions.
1. The common ground is real, but it is not the hard part
Both FDA and PMDA anchor clinical study data expectations in CDISC standards. Both expect SDTM and ADaM datasets in SAS XPORT Version 5 format. Both expect define.xml. Both expect reviewer-facing documentation.
That shared base is real, but it does not remove the operational differences. The trouble starts in the last mile, where agencies differ in validation behavior, local documentation expectations, accepted standards timing, and handling of Japanese source content.
2. Data standards catalog timing is not handled the same way
FDA and PMDA both publish accepted standards catalogs, but teams should not assume the timing logic is identical. FDA allows older supported standards in ways that are tied to study timing and catalog support windows. PMDA is more tightly anchored to what is accepted at the time of submission.
In practice, this means a study that is still acceptable to FDA under an older SDTMIG version may need a closer check for PMDA if the PMDA catalog in force at filing no longer lists that version. For pooled analyses built from studies that used different versions, PMDA also expects the differences and their effect on the integrated package to be explained clearly in the reviewer's guide.
3. PMDA pre-submission consultation is a real operational gate
FDA has meeting options, but PMDA's data-focused consultation process plays a much bigger role in how the package is prepared. In practice, sponsors are expected to go through formal PMDA data consultation before filing. This is where dataset structure, validation findings, and unresolved submission issues are discussed before the NDA reaches the gateway.
Form A and related consultation materials are not just paperwork. They force the sponsor to show what datasets will be submitted, what findings remain, and how each issue will be handled. That changes behavior upstream. Teams preparing a PMDA package cannot treat this as an FDA package with a regional note added at the end.
4. Japanese text handling is one of the biggest real differences
This is where many FDA-first teams get caught. PMDA allows Japanese data in submission datasets when translation would lose meaning, but it does not do this casually. It uses a paired dataset model.
When Japanese text must be preserved, the sponsor may need:
- a standard alphanumeric dataset in
sdtmoradam - a Japanese dataset in
sdtm_joradam_j - the same structure, same variables, same record order, and same record count in both
- clear explanation in the reviewer's guide
The alphanumeric version may use a placeholder such as
JAPANESE TEXT IN SOURCE DATABASE where the source value is carried in the Japanese dataset.
The encoding used for the Japanese dataset also needs to be documented.
FDA has no parallel dataset folder model like this. That is one reason a single global SDTM package is often not really single.
/* Example: basic check before PMDA XPT export */ proc contents data=sdtm.ae; run; /* Review character variables and dataset encoding. If Japanese text is present and cannot be translated safely, plan paired submission datasets and document the handling. */
5. Clinical pharmacology submission expectations are tighter
For clinical pharmacology studies, PMDA expects stronger traceability between concentration data, derived parameters,
and the analysis path used to produce them.
In practice, this means the PP domain is expected alongside PC for clinical pharmacology work,
and missing PP content is likely to raise conformance questions.
PMDA also expects clear linkage between PC and PP, typically through RELREC or equivalent documented traceability. If RELREC is not used, the reviewer guide should explain how individual parameters can be traced back to the source profile.
/* Illustrative RELREC concept linking PP back to PC */ /* RDOMAIN USUBJID IDVAR IDVARVAL RELTYPE RELID */ /* PP 001-001 PPSEQ 1 ONE PK01 */ /* PC 001-001 PCSEQ 1 2 3 4 MANY PK01 */
For PK and PK/PD work, PMDA also puts more weight on analysis metadata and reproducibility than many FDA-first teams expect. This becomes even more visible when population PK or PBPK materials are involved.
6. PMDA puts more weight on submitted programs and reproducibility
FDA strongly values SDRG, ADRG, and clean metadata. PMDA wants that too, but often goes further on executable traceability. The expectation is not just to describe the analysis well. The expectation is to make it reproducible enough for review.
For confirmatory studies, PMDA expects the primary analysis program in principle, along with supporting programs for ADaM creation and key efficacy, safety, or dose-setting outputs where relevant. If the exact program cannot be submitted, the fallback is still a detailed algorithm description, not silence.
This changes how statisticians and programmers should prepare the package. A package that feels well documented for FDA can still be weak for PMDA if the derivation chain is hard to reconstruct.
7. MedDRA/J matters, even though the PT code stays the anchor
MedDRA/J is the Japanese localization of MedDRA. The key point for SDTM work is that the code remains stable, while the label surface may be Japanese. That means the safest join point across Japanese and English safety content is the code, not the term label.
For PMDA SDTM submission, variables such as AEDECOD, AESOC, AEHLT,
and related coded fields should still align with standard MedDRA concepts expected by SDTM.
If the source or coding activity used Japanese labels, that Japanese content belongs in the paired Japanese dataset
or related documented handling path.
PMDA is also stricter in wording around controlled terminology use. It expects accepted standards, terminology, and dictionaries to be used without changing spelling, notation, or capitalization.
8. JADER is not an SDTM target, but it still matters
JADER is PMDA's post-marketing adverse drug reaction database. It is not a clinical SDTM submission target. That point needs to stay clean, because people often blur these two ideas.
JADER still matters for advanced programmers and statisticians because teams sometimes need to align or compare JADER safety data with internal clinical trial safety data. When that happens, the Japanese labeling, MedDRA/J usage, and local safety conventions become part of the mapping problem.
| JADER Table | Content | Nearest SDTM Analog |
|---|---|---|
| DEMO | Patient demographics, outcome, report details | DM, DS |
| DRUG | Suspected and concomitant drugs | CM, EX |
| REAC | Adverse reactions coded with MedDRA/J | AE |
| HIST | History / background disease information | MH |
One practical limitation is age granularity. JADER often carries age in grouped bins, not exact age. That matters if a team tries to compare JADER signals directly with FAERS or trial data without adjusting the analysis plan.
9. Japanese date and time handling can quietly break traceability
SDTM --DTC variables must still be ISO 8601 for both FDA and PMDA.
The issue is not the SDTM output format.
The issue is the source data.
Japanese source systems may contain era-based dates rather than plain Gregorian dates. The current era is Reiwa (令和), which began on May 1, 2019. The previous era was Heisei (平成), which ran from 1989 to April 30, 2019. Before that was Showa (昭和).
So a source date like 令和6年3月15日 needs conversion to 2024-03-15.
A date like 平成31年4月30日 converts to 2019-04-30.
This is not just formatting.
It is source interpretation and QC.
/* Era conversion reference */ /* Showa : 1926-12-25 to 1989-01-07 */ /* Heisei : 1989-01-08 to 2019-04-30 */ /* Reiwa : 2019-05-01 onward */ /* Reiwa Year N = Gregorian Year (2018 + N) */ /* Heisei Year N = Gregorian Year (1988 + N) */ /* Example: 令和6 -> 2024 平成31 -> 2019 */
The 2019 transition window needs extra QC. Any site data around the Heisei-to-Reiwa change should be checked carefully before conversion and SDTM derivation.
Time zone also matters. Japan Standard Time is UTC+9 and does not use daylight saving time. In mixed-region studies, local source time, normalized analysis time, and SDTM submission time should not be treated as the same thing by default.
10. Validation is not just "run P21 once"
This is one of the biggest mistakes in dual submissions. PMDA uses its own validation rule set within Pinnacle 21 Enterprise. FDA-facing validation and PMDA-facing validation are not interchangeable.
The same dataset can behave differently depending on:
- the rule set in use
- the engine selected
- the accepted standards version at filing
- how each agency handles severity and reviewer explanation
So "we ran P21" is not enough. The real question is, "Which rules, which engine, and for which authority?"
11. Controlled terminology drift is handled more tightly on the PMDA side
Both agencies depend on CDISC controlled terminology, but PMDA's wording is stricter around exact notation. It expects accepted terminology and dictionaries to be used without changing spelling, notation, or capitalization.
This matters in real programming work. Old sponsor terms, local lab carryover values, and slightly edited codelist values that may survive longer in FDA-focused workflows are more likely to become PMDA review points.
Another practical difference is laboratory terminology. FDA reviewers may ask more questions around LOINC alignment. PMDA does not place the same visible weight on that point in its SDTM conformance posture.
12. SEND is still a scope difference
FDA requires SEND for applicable nonclinical submissions. PMDA does not currently require SEND in the same way. That is a plain scope difference teams should keep separate from the SDTM conversation.
Summary table
| Area | FDA | PMDA |
|---|---|---|
| Standards timing | Tied to supported catalog windows and study timing | More tightly tied to standards accepted at submission |
| Pre-submission data consultation | No direct equivalent gate | Formal consultation plays a major role before filing |
| Japanese text handling | English-only submission model | Paired Japanese and alphanumeric dataset model when needed |
| Clinical pharmacology traceability | Strongly expected, often explained through metadata | Tighter expectation around PP, linkage, and reproducibility |
| Programs and reproducibility | Reviewer docs emphasized | Programs and algorithm traceability weigh more heavily |
| Validation behavior | Authority-specific review posture | Authority-specific rule set with stricter blocking behavior in practice |
| Japanese era dates | Usually not a source issue | Can require source interpretation and dedicated QC |
| MedDRA localization | International MedDRA workflow | MedDRA/J context with the code as the stable bridge |
| Post-marketing safety database | FAERS | JADER |
Final point
FDA and PMDA both accept SDTM. That is the easy part.
The hard part is how each agency expects the package to behave in review. PMDA is not just FDA with Japanese labels on top. It is a different operating environment, with different pressure points.
Teams that do well with PMDA usually make those decisions early, not a few weeks before filing.