A Deep Dive for Statistical Programmers

Audience: Statistical programmers in clinical data submission roles

Regulators Covered: FDA (United States) and PMDA (Japan)

Standards Referenced: CDISC SDTM IG 3.3, ADaM IG 1.1, J-SDTM, J-ADaM, CDISC CT, JCTB

1. The Problem These Documents Solve

When FDA or PMDA receives a clinical data package, reviewers do not open the datasets first. They open the documentation that explains the datasets. Without that documentation, every non-standard domain, every custom analysis parameter, and every deviation from the published implementation guide becomes a question — and questions stop the review clock.

The Study Data Standardization Plan (SDSP) for FDA, and PMDA's Form A and Form B, exist to give reviewers context before they open a single XPT file. These documents are not administrative formalities. They are the mechanism by which a sponsor communicates its data architecture to the people responsible for approving the drug.

The distinction between a submission that generates five information requests and one that generates none often comes down to how well these documents were prepared — and how early.

This article covers all three documents in technical depth: what they contain, when to submit them, how they relate to P21 validation output, what patterns of rejection they prevent, and how they affect review timelines.

2. SDSP: The FDA Study Data Standardization Plan

2.1 Regulatory Basis and Submission Context

The SDSP requirement originates in FDA's December 2014 guidance 'Providing Regulatory Submissions in Electronic Format — Standardized Study Data' and is elaborated in the CDER and CBER Technical Conformance Guide (TCG), last substantively updated in 2022. The requirement applies to IND submissions for Phase 2 and 3 studies, and to all NDA, BLA, sNDA, and sBLA applications.

The SDSP is submitted as part of the IND packet — specifically, as an amendment when a Phase 2 or Phase 3 study initiates. If that window has passed, it is submitted at the Type B pre-NDA meeting as a status document. Once submitted, any material change to the standardization approach requires an SDSP amendment: adding a study, changing an IG version, introducing new non-standard domains, or revising the deviation list.

FDA review divisions use the SDSP to:

• Confirm that the data standards described at IND match what arrives in the NDA package
• Understand non-standard domains and custom datasets before encountering them in DEFINE.xml
• Evaluate whether planned deviations from published standards are justified and study-specific
• Anticipate data complexity and plan review workload accordingly

2.2 Required Content Areas

The table below maps each required content area to what FDA expects, based on the TCG and patterns observed in FDA information requests.

2.3 The Four Most Common SDSP Failures

Most SDSP problems that generate downstream queries fall into one of four categories:

• Version ranges instead of specific versions. Writing 'SDTM IG 3.x' or 'current version' is not acceptable. FDA needs exact IG and CT versions. If versions change between IND and NDA, update the SDSP.
• Generic deviation justifications. 'System limitation' or 'not applicable' is not sufficient. Justifications must be study-specific and tied to a data collection reality or analysis need. Reference the relevant IG section and explain why the standard approach does not work.
• SUPPQUAL variable conflicts not documented. SUPPQUAL variable names that match standard SDTM variable names (the SD0089 scenario) are one of the most common and most preventable causes of data integrity queries. Document them explicitly.
• SDSP not updated after protocol amendments. A protocol amendment that adds a new endpoint likely requires new ADaM datasets, new PARAMCD values, or a revised DTYPE. The SDSP must reflect these changes before the NDA arrives.

3. PMDA Form A: The Pre-Submission Standardization Plan

3.1 Japan's CDISC Mandate

PMDA made CDISC-formatted electronic data mandatory for applications for new drugs submitted on or after April 1, 2020, per PMDA notification dated March 2019. The applicable standards are J-SDTM (Japan SDTM Implementation Guide) and J-ADaM — both built on CDISC foundations but with Japan-specific extensions.

Before submitting a JNDA (Japanese New Drug Application), sponsors must complete an RS Consultation — the formal pre-submission meeting on electronic research data standardization. Form A is the document submitted at that meeting. Without an RS Consultation on record, the JNDA application will not pass PMDA's administrative screening, regardless of data quality.

3.2 J-SDTM: What Statistical Programmers Need to Know

J-SDTM is not a replacement for SDTM — it is SDTM with PMDA-specific amendments. The differences that affect programming work most directly:

• J-ADaM includes the ADEX dataset (Exposure-Response Analysis) as a required submission element for bridging studies under ICH E5. It is not part of standard ADaM.
• DEFINE.xml variable labels must appear in both Japanese and English. This is a data engineering requirement, not just a translation task. Build bilingual labels into the DEFINE.xml specification from the start.
• Subject identifiers (USUBJID) must follow a PMDA-approved masking scheme compliant with Japan's Act on Protection of Personal Information (APPI). Raw hospital IDs, patient registration numbers, or any identifier that could link back to an individual are not permitted.
• The Japan Controlled Terminology Backbone (JCTB) extends CDISC CT with Japan-specific entries for coding categories not covered in the global CT. JCTB entries must be used where applicable.
• Deviations must reference specific sections of PMDA's electronic data submission guidelines, not only CDISC IG sections.

3.3 Form A Required Content Areas

4. PMDA Form B: The As-Submitted Implementation Record

4.1 From Plan to Implementation

Form B is submitted with the JNDA application. It converts the prospective plan in Form A into the actual record of what was submitted. PMDA reviewers use Form B as their first point of reference when beginning the data review — before they open a dataset.

The relationship between Form A and Form B matters practically. If Form B shows datasets, domains, or deviations that were not in Form A, PMDA must determine whether the gap was an oversight or a sign that something changed during the study. Either way, it generates queries. A good change log in Form B answers those questions before they become formal queries.

4.2 How Form B Relates to FDA's SDRG

FDA does not use a 'Form B' by that name. The closest FDA equivalent is the Study Data Reviewer's Guide (SDRG), submitted with the NDA. The SDRG provides dataset-level guidance to FDA reviewers — traceability from ADaM endpoints to CSR tables, primary analysis dataset identification, key variable definitions. Form B's reviewer notes section serves the same function for PMDA.

The coverage mapping:

• SDSP (FDA) corresponds to Form A (PMDA) — both are pre-submission standardization plans
• SDRG (FDA) corresponds to Form B reviewer notes section (PMDA) — both guide reviewers through submitted data
• Form B known issues section (PMDA) has no direct single FDA counterpart. The SDSP deviation table and SDRG together cover this function for FDA submissions

4.3 Form B Required Content Areas

5. Document Comparison Matrix

The table below puts SDSP, Form A, and Form B side-by-side on the dimensions that affect submission planning and programming decisions.

6. Using the SDSP to Communicate with FDA

6.1 Pre-IND and Type B Meeting Context

For a Phase 2/3 program, the first SDSP goes in with the Phase 2 IND amendment that initiates the pivotal study. At that point it is a plan. It gives FDA the opportunity to flag concerns before data is locked. An FDA comment on SDSP content at IND stage is a far cheaper problem than an information request at NDA review.

For Type B pre-NDA meetings, the SDSP is included in the briefing package as a status document: this is what we planned, this is what we implemented, and these are the known deviations. FDA reviewers at that meeting use the SDSP to assess whether the incoming NDA data package will be reviewable without significant queries.

6.2 What FDA Actually Checks Against the SDSP

Based on FDA's published technical rejection patterns and recurring information request content:

• IG version match: The SDTM IG and ADaM IG versions in the SDSP are compared directly to the <Study> element in DEFINE.xml. A mismatch — even a minor version difference — triggers a query.
• NSD completeness: If DEFINE.xml contains a non-standard domain not listed in the SDSP NSD table, FDA will ask. DEFINE.xml is reviewed before datasets in many cases.
• Deviation pre-documentation: P21 warnings in the submitted report are cross-referenced against the SDSP deviation table. Warnings with no corresponding SDSP entry are flagged as unexplained.
• CT version alignment: The CDISC CT version in the SDSP is compared to the CT version specified in DEFINE.xml codelist origin fields. Any discrepancy requires explanation.

6.3 When to Update the SDSP

The SDSP should be treated as a living document during the IND phase. Update it when:

• A new Phase 3 study joins the program — update domain list and add any new NSD or deviations
• An IG version upgrade occurs — update standards catalog and document the migration rationale
• A protocol amendment adds or removes efficacy endpoints — update ADaM dataset list and PARAMCD entries
• The statistical analysis plan changes imputation methods — update any affected DTYPE or derivation documentation
• New NSD domains emerge from late protocol additions — they need an SDSP entry before submission

FDA review teams typically pull the most recent SDSP from the IND file before NDA review begins. An SDSP that is two years out of date relative to the submitted data is visible immediately and will generate reconciliation questions.

7. Using Form A and Form B to Communicate with PMDA

7.1 RS Consultation Workflow

The RS Consultation is a formal process with a defined sequence. For a standard JNDA program:

1. Request the RS Consultation meeting from PMDA — typically 6–8 weeks before the intended meeting date.
2. Submit Form A with the meeting request, or at least 3 weeks before the meeting date.
3. Hold the RS Consultation. PMDA reviews Form A and raises questions. A formal consultation record with a reference number is issued.
4. Address PMDA comments on Form A. If PMDA requests changes to the standardization plan, implement them and confirm in writing.
5. Proceed with data programming using Form A as the SDTM/ADaM architecture specification for Japan datasets.
6. After data lock, prepare Form B: reconcile actual implementation against Form A and document all changes in the change log.
7. Submit Form B with the JNDA. PMDA uses it as the primary reference document in the data review.

7.2 Translation and Bilingual Requirements

Statistical programmers supporting a Japan submission need to plan translation timelines carefully:

• Variable labels and dataset descriptions in DEFINE.xml must be in Japanese. This is not a post-production task — it needs to be built into the DEFINE.xml specification process.
• Non-standard domain justifications in Form A must be written in Japanese. Use a technical translator familiar with CDISC terminology. Generic medical translators often do not know the regulatory data standards vocabulary.
• The APPI anonymization section requires reference to specific APPI articles. Japan regulatory affairs review is needed before submission of this section.

7.3 Query Patterns from Incomplete Form A or Form B

PMDA queries arising from Form A or Form B gaps follow predictable patterns:

• Row count discrepancy: Form A estimates 4,200 rows in the efficacy dataset. Form B reports 3,840. PMDA asks what happened to the 360 subjects. Both 'subjects excluded post-Form A' and 'estimate was wrong' require documented explanation.
• Unannounced deviation: A new SUPPQUAL variable appears in submitted data that was not in Form A's deviation plan. PMDA asks when the decision was made and why it was not raised at RS Consultation.
• Missing change log: Form B omits a change log section. PMDA cannot determine which elements evolved between Form A and submission and generates a broad query requesting a full description of differences.
• Anonymization gap: Form A describes masking but Form B does not confirm implementation. PMDA requests a compliance statement from the sponsor's data privacy officer before proceeding.

8. Data Scenarios and Documentation Implications

The following ten scenarios represent data situations statistical programmers encounter across Phase 2/3 programs. For each, the table identifies the documentation challenge, how it appears in P21 output, and what the agency response looks like with and without proper SDSP or Form A/B coverage.

9. P21 Errors and Warnings: Documentation Coverage Map

Pinnacle 21 (Veeva conformance validation) runs against FDA's published CDISC validation rules and, in the PMDA conformance profile, against PMDA-specific rules. A P21 finding that is documented in the SDSP or Form A/B is an anticipated finding — reviewers see the explanation alongside the flag and move on. A P21 finding with no documentation is an open question that becomes a formal query.

The table below covers common P21 rule categories and their connection to SDSP and PMDA form documentation. Rule IDs follow Pinnacle 21 naming conventions and are representative; exact IDs vary by P21 version.

9.1 Handling Remaining P21 Findings Before Submission

The target is not to eliminate all P21 findings. Some are inherent to the data design and cannot be resolved without compromising data integrity or analysis methodology. The target is to explain every remaining finding before the agency encounters it.

For FDA submissions: the P21 report is typically submitted as part of the NDA package. Cross-reference remaining errors in the SDRG or in DEFINE.xml notes at the value level. The SDSP provides the framework; the SDRG provides the dataset-specific explanation.

For PMDA submissions: Form B's known issues section is the formal location for this explanation. For each remaining error, list the rule ID, affected dataset and variable, and a statement explaining why the finding is acceptable given the data design. PMDA reviewers check this section at the start of data review.

10. Rejection and Refusal Patterns

The table below documents rejection and refusal patterns drawn from publicly documented FDA RTF actions, PMDA screening rejection notices, and recurring information request categories. Timeline estimates reflect typical review cycle times as of 2024–2025.

11. How Early Documentation Reduces Review Time

11.1 The Reviewer Economics

FDA reviewers work against PDUFA dates; PMDA reviewers against defined review periods. Every information request issued pauses the formal review clock or consumes reviewer time equivalent to stopping it. Reviewers are motivated to find answers in the submission documents rather than issue requests — but only if the answers are there.

An SDSP or Form A/B that answers the question before the reviewer asks it is directly faster than issuing a request, waiting 30 days, reading the response, and resuming. The challenge is that the submission team cannot know in advance exactly which questions the reviewer would have asked. The solution is comprehensive coverage of everything non-standard in the data.

Documented experience across multiple NDA and BLA submissions shows that thorough SDSP preparation reduces formal information requests related to data standards by 60–80%. The same pattern holds for PMDA with Form A and Form B. This is not a guarantee, but the consistency of the effect across programs makes it a standard practice at experienced sponsors.

11.2 Cost of Fixing Standards Issues at Different Stages

11.3 Actions Within the Statistical Programmer's Control

These actions have the highest direct impact on review quality and speed:

• Draft the SDSP domain list as soon as the Phase 3 SAP is finalized. Do not wait for study completion.
• Run P21 against each planned domain type during the programming build phase, before data lock. Use the output to populate the SDSP deviation table proactively.
• Keep a living SDSP amendment log. Track every change to standards, IG versions, or domain plans. Reconstructing the change history at NDA stage adds weeks of work.
• For Japan submissions, begin Form A preparation when Phase 3 SDTM programming begins. Bilingual variable labels take longer to produce than expected.
• Map all P21 findings to exactly one of three categories: fixed before submission, documented in SDSP or Form B, or inherent to data design and explained in DEFINE.xml. Nothing should be in a fourth category of unexplained.
• Coordinate SDSP and Form A/B reviews with the medical writer handling the CSR. Traceability between ADaM endpoint datasets and CSR efficacy tables should be reflected consistently across both document types.

12. Summary

SDSP, PMDA Form A, and PMDA Form B serve the same fundamental purpose: establishing a shared understanding of data architecture between the sponsor and the reviewing agency before the review begins. Each document does this at a different point in the regulatory process and with a different level of detail.

For FDA, the SDSP is the IND-stage commitment. It defines what standards will be used, what non-standard elements are planned, and what deviations are justified. A well-maintained SDSP transforms P21 warnings from unexplained flags into acknowledged design choices.

For PMDA, Form A is the mandatory RS Consultation deliverable. Without it, the JNDA will not pass screening. Form B is the implementation record submitted with the application, reconciling plan against reality and pre-empting reviewer queries through the known issues section. Both documents have Japan-specific requirements — J-SDTM extensions, APPI anonymization requirements, JCTB controlled terminology, and bilingual labeling — that have no direct FDA equivalent.

Statistical programmers who treat these documents as active programming artifacts — built alongside the datasets and updated when the datasets change — will encounter fewer agency queries, faster review outcomes, and significantly less amendment work at the NDA or JNDA stage.

Source: clinstandards.org | Based on FDA Technical Conformance Guide (2022), PMDA Electronic Data Submission Guidelines, CDISC SDTM IG 3.3, ADaM IG 1.1, J-SDTM and J-ADaM PMDA guidance documents, and CDISC CT/JCTB current releases.