USPI, DTS, SmPC, CT.gov, and the Final Push to Drug Approval

Deep Dive Series — CDISC Open Source Ecosystem clinstandards.org | Published: March 2026

Abstract

The period between submission acceptance and drug approval is among the most intense in the life of a clinical program — and statistical programmers are far more central to it than most realize. Beyond the primary NDA/BLA, a constellation of regulatory-driven documents must be produced, reconciled, and maintained: the US Prescribing Information (USPI), Drug Trial Snapshot (DTS), Patient Information (PI/Medication Guide), ClinicalTrials.gov result posting, the EU Summary of Product Characteristics (SmPC), and a series of agency-specific labeling and communication requirements. Each has its own format, statutory deadline, clinical data dependency, and programmer touchpoint. This article explains what each document is, why it exists, what clinical outputs it draws from, what the programmer's specific role is, and what the timing expectations look like. Written entirely from primary regulatory sources.

Table of Contents

1. The Closeout Landscape — Why This Phase Is Different
2. US Prescribing Information (USPI)
3. Drug Trial Snapshot (DTS)
4. Patient Information — Medication Guide and Patient Package Insert
5. ClinicalTrials.gov — Results Posting Requirements
6. EU Summary of Product Characteristics (SmPC)
7. EMA Risk Management Plan (RMP) — Quantitative Annex
8. Japanese Package Insert (JPI) and PMDA-Specific Outputs
9. Agency Communication — Labeling Negotiations and Information Requests
10. Timing Map — When Everything Is Due
11. The Statistical Programmer's Checklist for Closeout
12. Common Errors in the Closeout Phase
13. Summary and Key Takeaways

References

1. The Closeout Landscape

1.1 Why This Phase Catches Programmers Off Guard

In most clinical programming teams, the months between NDA/BLA submission and PDUFA date are mentally classified as "waiting." In practice, they are nothing of the sort. The regulatory review cycle triggers a cascade of parallel deliverables — some mandatory by statute, some agency-requested, some commercially driven — each requiring verified clinical data drawn from the exact same datasets that supported the submission. The difference is that these outputs are often produced under extreme time pressure, with non-programmer stakeholders (Medical Writing, Regulatory Affairs, Commercial) as primary drivers, and with formatting requirements that look nothing like a conventional TFL.

Programmers who understand this landscape before it arrives are exponentially more effective than those who encounter it reactively. This article is designed to produce the former.

1.2 The Document Web at Close of Approval

Each document in the closeout package serves a distinct audience and regulatory mandate:

Table 1.1. The regulatory closeout document web. Each document has a distinct regulatory basis, audience, and clinical data dependency.

1.3 The Programmer's Dual Role

Statistical programmers play two distinct roles in closeout:

Data custodian: The submission datasets (ADaM, SDTM) are the single source of truth. Any number in any label document must be traceable to a submission dataset or a protocol-specified analysis. When Regulatory Affairs asks "where does the 68.3% responder rate on page 12 of the label come from?", the programmer must have the answer in under an hour.

Output generator: Most closeout documents require new outputs not produced during the primary submission — subgroup breakdowns, demographic summaries by race/ethnicity, reformatted tables meeting FDA or EMA-specific display requirements, or program-generated text that populates structured label templates. These are programming deliverables as real as any CSR TFL.

NOTE: The source of truth for all label numbers is the submitted ADaM datasets and the final CSR. Any deviation — even rounding — must be explicitly justified and approved by the statistician and regulatory lead. "Close enough" is not acceptable in label negotiation.

2. USPI — US Prescribing Information

2.1 What It Is and Why It Matters

The US Prescribing Information (USPI), commonly called the "label" or "package insert," is the primary official document describing a drug's approved indications, clinical pharmacology, efficacy, safety, dosing, and contraindications for US healthcare providers. It is a legally binding regulatory document — every claim must be substantiated by data in the application.

The USPI is governed by the Physician Labeling Rule (PLR), finalized by FDA in 2006 (21 CFR 201.56 and 201.57), which established the standardized PLR format required for all new molecular entities and new biologics. The PLR replaced the older pre-2006 format and introduced the Highlights of Prescribing Information section (the "highlights") as a mandatory front-page summary.

2.2 USPI Structure — The PLR Format

The PLR format mandates the following section structure in this order:

Table 2.1. PLR USPI section structure with primary programmer data sources.

2.3 Section 6 — Adverse Reactions: The Programmer's Core USPI Deliverable

Section 6 of the USPI is where statistical programmers spend the majority of their label-support time. It requires:

6.1 Clinical Trials Experience — An adverse reaction table listing all TEAEs occurring at ≥5% (or a protocol-defined threshold) in the drug arm, with a comparison to placebo or active comparator. The format is standardized but not templated — FDA negotiates the exact presentation during labeling discussions.

Key requirements for Section 6 adverse reaction tables:

• Rates expressed as percentage of subjects in each treatment arm (not events per subject-year)
• System Organ Class (SOC) grouping per MedDRA hierarchy, listed alphabetically by SOC
• Preferred Terms (PTs) listed alphabetically within each SOC
• Denominator = number of subjects who received ≥1 dose (safety analysis set)
• Drug name arm first, then comparator — always

Example Section 6 Table format:

Table 6.1  Adverse Reactions Occurring in ≥5% of Patients Receiving DRUGX and
           at a Higher Rate Than Placebo in Study PIVOTAL-001

                              DRUGX 100 mg      PlaceboSystem Organ Class            (N=312)           (N=156)
  Preferred Term                %                 %
─────────────────────────────────────────────────────
Gastrointestinal disorders
  Nausea                        23                 8
  Diarrhea                      18                 6
  Vomiting                      11                 4
General disorders
  Fatigue                       15                 9
  Pyrexia                        8                 3
Investigations
  ALT increased                  7                 2
─────────────────────────────────────────────────────

Figure 2.1. Example Section 6 adverse reaction table format. SOCs are listed alphabetically; PTs are alphabetical within SOC. Note: "at a higher rate than placebo" — PTs below the threshold in the active arm OR with lower rates than placebo are excluded per FDA convention.

WARNING: The denominator for Section 6 must exactly match the safety analysis set denominator stated in the label text. If the label states "safety analysis set (N=312)", the table header must show N=312. Any mismatch — including subjects who received drug but were excluded from the analysis set — will be flagged by FDA during label review. Confirm denominator logic with the statistician before any label table is finalized.

2.4 Section 14 — Clinical Studies: The Efficacy Section

Section 14 is the second major programmer deliverable within the USPI. It presents the pivotal trial results in a format that substantiates the indication statement in Section 1. Key content:

• Trial design description (randomization, blinding, treatment arms, key eligibility)
• Baseline demographics table (often reproduced from CSR Table 1)
• Primary endpoint result with confidence interval and p-value
• Key secondary endpoints
• Kaplan-Meier figures (for survival/PFS endpoints) — FDA often requires specific KM plot formats
• Subgroup forest plots for key subgroups (if the subgroup analysis supports a broad label)
• Response rate table if applicable (ORR, CR rate, PR rate, DOR)

KM Figures for the Label: FDA expects Kaplan-Meier curves in Section 14 that include:

• Number at risk table below the x-axis (at regular intervals specified by FDA)
• Median estimate with 95% CI
• Hazard ratio with 95% CI and p-value from the primary analysis
• Minimum 6-point font for all elements (accessibility requirement)

These KM figures must be generated from the submission ADaM datasets (ADTTE) using the exact same analysis as the primary submission. Generating a new KM from a different dataset or with different censoring rules — even if visually identical — is a protocol deviation.

2.5 USPI Labeling Negotiation Process

The USPI is not written once and submitted — it goes through multiple rounds of negotiation with FDA:

Table 2.2. USPI negotiation timeline and programmer involvement.

NOTE: FDA labeling comments frequently request analyses not pre-specified in the SAP — for example, "provide adverse reaction rates by age group (< 65, ≥ 65)" or "provide the subgroup analysis for patients with prior treatment." These are ad hoc programming requests that must be fulfilled rapidly (often within 5–10 business days). Maintaining clean, well-documented ADaM programs is the only way to execute these efficiently.

2.6 Structured Product Labeling (SPL)

The final USPI is published in Structured Product Labeling (SPL) format — an HL7-based XML format required by FDA for all approved drug labels. SPL is the format used in DailyMed (the FDA's official label repository) and is the machine-readable version of the label.

Statistical programmers do not typically author SPL directly — this is done by Regulatory Affairs using specialized SPL authoring tools. However, programmers must ensure that every number in the SPL-rendered label exactly matches the source analysis. Post-approval discrepancies between the SPL label and the submitted analyses are a regulatory compliance issue.

3. Drug Trial Snapshot (DTS)

3.1 What It Is

The Drug Trial Snapshot (DTS) is an FDA-mandated plain-language summary of the clinical trials that supported a drug's approval, with specific emphasis on the representation of diverse participant populations — particularly by sex, race, and age. It is published on the FDA website at the time of approval and updated as new labeling supplements are approved.

The legal basis is the FDA Reauthorization Act of 2017 (FDARA), specifically Section 505(d)(7) of the Federal Food, Drug, and Cosmetic Act (21 USC 355(d)(7)), which requires FDA to publish a Drug Trial Snapshot for each new molecular entity (NME) or new biologic approved.

3.2 DTS Content and Structure

The DTS is a structured web-formatted document, not a PDF. It contains three mandatory components:

Component 1: The Basics

• What the drug is approved for (indication in plain language)
• What type of drug it is (small molecule, biologic, etc.)
• How it was studied (trial design summary for each pivotal trial)
• Who was in the trials (participant demographics)

Component 2: The Results

• Did the drug work? (primary endpoint result in plain language with numbers)
• What were the side effects? (most common adverse reactions in plain language)

Component 3: Using this Snapshot

• Caveats and methodological notes
• Link to the full prescribing information

3.3 The Diversity Demographics Table — The Programmer's Core DTS Deliverable

The most data-intensive component for programmers is the participant demographics table, which must report:

Table 3.1. DTS demographics requirements. All categories are mandatory; "Unknown/Not Reported" must be shown when applicable — it cannot be rolled into another category or suppressed.

NOTE: FDA is intensely focused on the race/ethnicity reporting in the DTS. The five OMB race categories are mandatory, and "Unknown" must be reported separately. A common programming error is categorizing "Other" races into "Unknown" or aggregating multiracial subjects. The ADSL RACE and ETHNIC variables must align with the FDA's OMB-based categorization scheme. If CDASH collection used different terminology, the mapping must be pre-specified and documented.

3.4 DTS Efficacy Summary — Numbers Must Match the Label

The DTS efficacy section reports the primary endpoint result in plain language. For example:

"In the main study, 68% of patients who received DRUGX responded to treatment, compared with 32% of patients who received placebo. This difference was statistically significant."

The 68% and 32% values must exactly match Section 14 of the USPI and the submitted CSR. The DTS is cross-checked against the approved label by FDA's Drug Information team — discrepancies are not tolerated and require a label update (a regulatory action in itself).

3.5 DTS Process and Timing

Table 3.2. DTS process timeline. The DTS is typically finalized in parallel with the USPI negotiations.

4. Patient Information — Medication Guide and Patient Package Insert

4.1 Types of Patient-Directed Labeling

FDA recognizes two distinct types of patient-directed labeling, governed by different regulations:

Table 4.1. Patient-directed labeling types. Medication Guides are the most common and most rigorous.

4.2 Medication Guide Requirements and Content

A Medication Guide must contain the following sections in plain language (8th-grade reading level is the standard target):

• What is [Drug Name]? — Approved use in plain language
• Who should not take [Drug Name]? — Contraindications
• What should I tell my healthcare provider before taking [Drug Name]? — Medical history, other drugs
• How should I take [Drug Name]? — Dosing and administration
• What are the possible side effects of [Drug Name]? — Including serious side effects requiring immediate attention
• How should I store [Drug Name]?
• General information about the safe and effective use of [Drug Name]
• What are the ingredients in [Drug Name]?

The serious side effects section is where statistical programmers contribute: the MedGuide must include a list of adverse reactions that patients should watch for and report immediately. This list is derived from the serious adverse events in the safety datasets (ADAE, filtered on AESER = 'Y' or AE severity = Grade 3/4 under CTCAE grading) and aligned with the Warnings and Precautions section of the USPI.

WARNING: The Medication Guide is a legal document. Its serious adverse reaction list must be consistent with Section 5 (Warnings and Precautions) of the USPI. Any AE category listed in Section 5 must appear in the MedGuide, and vice versa. Programmers who produce the Section 5 safety analyses and the MedGuide supporting data must cross-check these two lists explicitly — inconsistency between the MedGuide and the USPI is a labeling error.

4.3 REMS — Risk Evaluation and Mitigation Strategy

Some drugs require a Risk Evaluation and Mitigation Strategy (REMS), which is a drug safety program required by FDA when a drug's benefits can only outweigh its risks if specific measures are taken to mitigate those risks. REMS programs can include:

• MedGuide only (simplest form)
• Communication plan (letters to healthcare providers)
• Elements to Assure Safe Use (ETASU) — e.g., prescriber certification, patient enrollment, pharmacy certification, monitoring requirements

Programmer role in REMS: If a REMS program includes mandatory safety monitoring (e.g., regular lab tests, pregnancy testing), the clinical safety data justifying the REMS requirements must be quantified from the submission datasets. The frequency, severity, and reversibility of the safety signal driving the REMS requirement must be documented with specific numbers from ADAE, ADLB, or relevant safety ADaM datasets.

5. ClinicalTrials.gov — Results Posting Requirements

5.1 Legal Framework

ClinicalTrials.gov results posting is governed by the FDA Amendments Act of 2007 (FDAAA 801), codified at 42 USC 282(j), and operationalized by the NIH Final Rule (42 CFR Part 11), effective January 2017. Non-compliance carries civil monetary penalties of up to $12,608 per day (adjusted for inflation) per violation. This is not a soft requirement — it is federal law with financial penalties that have been enforced.

Key provisions:

• All applicable clinical trials (ACTs) of FDA-regulated drugs, devices, and biologics must register on ClinicalTrials.gov before enrollment begins
• Results must be posted within 12 months of the Primary Completion Date (PCD) — the date the last participant is examined or receives an intervention for the purposes of the primary endpoint
• FDA-approved drugs: If the sponsor has submitted results to FDA but needs to delay public posting (e.g., to avoid disclosing proprietary information before approval), they may request a results posting delay — but must notify ClinicalTrials.gov with justification

5.2 What Must Be Posted as Results

The ClinicalTrials.gov results database requires the following structured data elements:

Table 5.1. ClinicalTrials.gov required results data elements and programmer sources.

5.3 The Outcome Measures Section — Critical Precision Requirements

The Outcome Measures section is where programmers must be most precise. Each pre-registered primary and secondary endpoint must have results posted. The requirements:

For continuous endpoints (e.g., change from baseline in a scale score):

• Mean or median by arm
• Standard deviation or interquartile range
• Number analyzed (not enrolled — the analysis set denominator)

For binary endpoints (e.g., ORR, response rate):

• Number of participants with the event / total number analyzed
• Proportion (not percentage in all fields — check the field type)

For time-to-event endpoints (e.g., PFS, OS):

• Median estimate by arm with 95% CI
• Number analyzed
• Hazard ratio (if applicable) with 95% CI and p-value
• Number of events

Statistical analysis fields:

• Statistical test method (e.g., "Log-rank test," "Fisher's exact test," "Cox proportional hazards")
• P-value (exact, not "NS" or ">0.05" — the actual value)
• Confidence interval type (95%) and estimates

WARNING: ClinicalTrials.gov results must match the CSR and the USPI. FDA cross-references the posted results against the approved label. A discrepancy — even in rounding or the number of decimal places — is a compliance finding. The FDA's Drug Trial Snapshot also cross-references ClinicalTrials.gov. All three documents (ClinicalTrials.gov, DTS, USPI) must be internally consistent.

5.4 Adverse Event Reporting on ClinicalTrials.gov

The adverse event section on ClinicalTrials.gov has specific requirements that differ from the USPI:

Table 5.2. Adverse event reporting comparison: ClinicalTrials.gov vs. USPI. The denominators and inclusion criteria differ.

5.5 The ClinicalTrials.gov Entry Process

The entry process for results is typically a shared responsibility:

1. Regulatory Affairs / Clinical Operations own the ClinicalTrials.gov account and system entry
2. Medical Writing drafts the narrative sections (outcome measure descriptions, study design)
3. Statistical Programming provides the numerical data for all results tables, formatted to ClinicalTrials.gov field specifications

Programmers should expect to receive a results data shell — a structured spreadsheet or template with field names corresponding to ClinicalTrials.gov data elements — and populate it from the final ADaM datasets. This shell is then entered into the ClinicalTrials.gov Protocol Registration and Results System (PRS) by Regulatory Affairs.

Key field-level precision requirements that trip up programmers:

• Age: ClinicalTrials.gov accepts mean ± SD or median [IQR/range] — the choice must match what was pre-registered in the protocol
• Race/Ethnicity: Must use the five OMB race categories — the same as required for DTS
• Proportions: Enter as a count and denominator (e.g., "68 of 100"), not as a percentage — the system computes the percentage
• P-values: Must be numeric (e.g., "0.003"), not text (e.g., "<0.05")

5.6 Delayed Posting — The Certification Process

If a sponsor needs to delay results posting (e.g., to protect proprietary information before approval, or while preparing a new indication application), they must file a certification of delay with ClinicalTrials.gov stating the reason. The maximum allowable delay for an approved drug is until the date of approval or 30 days after, whichever is earlier. After approval, the results must be posted promptly — there is no grace period post-approval for delay.

6. SmPC — Summary of Product Characteristics (EU)

6.1 Regulatory Basis and Role

The Summary of Product Characteristics (SmPC) is the EU equivalent of the USPI. It is the official scientific document summarizing information for healthcare professionals on how to use a medicinal product safely and effectively. The SmPC is mandated by Directive 2001/83/EC (as amended) and EU Regulation 726/2004 for centrally authorized products.

For centrally authorized products (those authorized via the EMA), the SmPC is prepared by the applicant and reviewed by the Committee for Medicinal Products for Human Use (CHMP). The template format is defined in the EMA QRD (Quality Review of Documents) template, currently in version 10.1.

6.2 SmPC Structure vs. USPI — Key Differences

The SmPC and USPI cover similar scientific ground but differ substantially in structure, required content, and terminology:

Table 6.1. USPI vs. SmPC structural comparison.

6.3 Section 4.8 — Adverse Reactions in the SmPC

The SmPC Section 4.8 adverse reactions section uses MedDRA frequency bands — a standardized system for categorizing adverse reaction frequency. This is distinct from the USPI, which presents raw percentages:

Table 6.2. MedDRA frequency bands for SmPC Section 4.8. Programmer task: categorize each adverse reaction's observed rate into the appropriate frequency band.

Programmer task for SmPC Section 4.8:

The SmPC AE table presents PTs organized by SOC, with the frequency band replacing the percentage. Programmers must:

1. Compute the observed percentage rate for each PT in the safety analysis set (same source as USPI Section 6)
2. Map each rate to the appropriate MedDRA frequency band
3. Within each SOC, list PTs by frequency band (most frequent to least frequent)
4. For PTs that are "not known" (typically from postmarketing), coordinate with the safety/pharmacovigilance team

A common error: using the total exposure-adjusted rate (events per patient-year) rather than the subject-level rate (% of subjects with ≥1 occurrence) for frequency band assignment. The frequency bands are based on subject-level rates.

6.4 CHMP Review and Day 120 / Day 180 Responses

The CHMP review process for a centrally authorized application (CAP) operates on a 210-day clock with stops. Key programming touchpoints:

Table 6.3. CHMP 210-day review clock and programmer involvement milestones.

NOTE: The Day 120 and Day 180 responses are the EU equivalent of FDA's Information Requests — they require new or revised analyses, often within tight timelines (typically 30 days for Day 120 responses, shorter for Day 180). Programs must be well-documented and immediately re-executable against the locked datasets.

6.5 EMA-Specific Output Requirements

EMA may request specific output formats not required by FDA:

• Forest plots: EMA frequently requests pre-specified subgroup forest plots in standardized formats for the EPAR (European Public Assessment Report). These may need different subgroup definitions than FDA versions.
• Exposure-response analyses: EMA places high weight on PK/PD analyses; programmers should expect requests for exposure-response tables and figures linking PK parameters to efficacy and safety outcomes.
• Risk-benefit assessment tables: EMA's integrated benefit-risk assessment may require specific structured tables quantifying benefit and risk that feed into the benefit-risk section of the EPAR.

7. EMA Risk Management Plan — Quantitative Annex

7.1 What the RMP Is

The Risk Management Plan (RMP) is a comprehensive document required for all EU marketing authorization applications. It documents what is known and unknown about the safety of a medicine and how any risks will be monitored and minimized. The regulatory basis is EMA GVP (Good Pharmacovigilance Practices) Module V.

The RMP contains a quantitative safety annex — Part II: Safety Specification, Module SII — which is the programmer-relevant component. It requires structured quantitative summaries of safety data.

7.2 RMP Safety Specification — Programmer Data Requirements

Table 7.1. RMP quantitative annex programmer data requirements.

7.3 Exposure-Adjusted Incidence Rates

The RMP typically requires adverse event rates expressed as exposure-adjusted incidence rates (EAIRs) rather than the subject-level percentages used in the USPI. The formula:

EAIR (per 100 patient-years) = (Number of subjects with ≥1 event / Total patient-years of exposure) × 100

where: Total patient-years = sum(treatment duration in days) / 365.25 across all subjects

This requires the ADEX (exposure) dataset, which tracks actual drug exposure duration per subject. If ADEX does not exist or exposure duration is not directly available, it can be derived from ADCM (concomitant medications) or from dose records in the protocol-specific datasets.

8. Japanese Package Insert and PMDA-Specific Outputs

8.1 The Japanese Package Insert (JPI)

The Japanese Package Insert (JPI), known as 添付文書 (Tenpusho), is the official prescribing information document for drugs approved in Japan by the Pharmaceuticals and Medical Devices Agency (PMDA). It follows a structure defined by Ministry of Health, Labour and Welfare (MHLW) guidelines, which was substantially revised in 2019 to align more closely with ICH E3 and international norms.

Key structural elements of the JPI relevant to programmers:

Table 8.1. JPI sections with programming relevance.

8.2 PMDA's Bridging Data Requirements

Japan has historically required a bridging strategy to establish that international clinical data can be extrapolated to the Japanese population. The E5 ICH guideline governs this. In the modern era, PMDA increasingly accepts global studies with Japanese subgroup data as sufficient for approval (the multi-regional clinical trial, or MRCT, approach per ICH E17).

Programmer implications of Japanese bridging:

• The Japanese subgroup must be specifically identifiable in ADSL via COUNTRY = 'JPN' or a Japan-specific site variable
• Japanese subgroup efficacy and safety analyses must be pre-specified in the SAP (even if exploratory) for PMDA
• PMDA expects Japanese subgroup results to be "consistent" with overall results — not necessarily identical, but within a qualitative consistency standard. Programmers may need to produce Japanese subgroup forest plots, response rate tables, and PFS/OS Kaplan-Meier curves separately
• PMDA's Day 120 equivalent (written inquiry) and Day 180 (oral explanation) processes mirror the EMA process but operate on Japanese timelines

NOTE: PMDA expects Analysis Results Metadata (ARM) — the structured metadata describing how analyses were performed — in the submission. This is distinct from FDA, where ARM is optional (though expected by PMDA as noted in CDISC ARM specifications). If ARM is being produced for PMDA, programmers must ensure the ARM metadata accurately reflects the actual analysis programs, including Japanese subgroup analyses.

9. Agency Communication — Labeling Negotiations and Information Requests

9.1 Types of FDA Communication During Review

During the review period, FDA may issue several types of formal communication that require rapid programming responses:

Table 9.1. FDA communication types during review and programmer response requirements.

9.2 Responding to Information Requests — The Programming Protocol

When an IR arrives that requires new analysis, the following protocol should be applied:

1. Triage immediately — Regulatory Affairs and the statistician assess whether the IR requires new programming or can be answered from existing outputs within 24–48 hours of receipt
2. Dataset confirmation — Confirm that the locked submission datasets support the requested analysis. If a new dataset or derivation is needed, confirm with the statistician whether it can be derived from submission ADaM or whether SDTM re-derivation is required
3. Program development — Use existing program infrastructure. Do not rebuild from scratch. New IR programs should source from the same input datasets (ADSL, ADaM) as the primary submission programs
4. QC — All IR outputs require the same QC standard as submission TFLs — independent programming verification, with discrepancy resolution documented
5. Documentation — IR response programs are regulatory documents. They must be archived with version control, with metadata documenting the exact dataset versions and program versions used
6. Sign-off chain — Statistician → Medical Monitor → Regulatory Lead must approve all IR responses before submission. Programmers do not submit IR responses directly.

9.3 Advisory Committee (AdComm) Data Packages

When FDA convenes an Advisory Committee to review a NDA/BLA, the agency prepares briefing documents from the submitted datasets. Sponsors also prepare their own briefing documents. These packages often require:

• Key efficacy summaries formatted for slide presentation (not standard TFL format)
• Benefit-risk analyses quantifying the magnitude of benefit vs. the frequency/severity of risk
• Subgroup analyses formatted as forest plots for the committee's benefit-risk discussion
• Patient-level data displays (e.g., waterfall plots showing individual responses)
• Real-time simulation capability — some teams bring a laptop with live SAS/R sessions capable of running pre-approved analyses during the public meeting if committee members request specific subgroup looks

NOTE: AdComm presentations require FDA prior approval of the materials. Sponsor briefing documents are submitted to FDA before the committee meeting and reviewed for accuracy. Every number in an AdComm presentation package must be traceable to the submission datasets with the same rigor as a label number.

10. Timing Map — When Everything Is Due

10.1 The 12-Month Review Calendar (NDA/BLA Standard Review)

The following timeline maps the major closeout deliverables against the FDA standard 12-month review clock. Accelerated Approval and Priority Review (6-month) timelines compress this significantly.

Table 10.1. 12-month NDA/BLA review timeline with programmer deliverable mapping. Priority Review compresses Months 1–6; timelines are indicative.

10.2 The EU Timeline (CHMP Centralized Procedure)

Table 10.2. CHMP 210-day review clock with programmer touchpoints.

10.3 ClinicalTrials.gov Deadline Calculation

ClinicalTrials.gov deadlines require precise date calculation:

Primary Completion Date (PCD) = date last subject examined/receives intervention for primary endpoint
                                  (pre-registered in the protocol)

Results Posting Deadline = PCD + 12 months (standard)
                         = PCD + 30 days after approval (if delay certification filed)

For a drug approved on 01-Jan-2026:
  If PCD was 01-Jul-2024:
    Standard deadline: 01-Jul-2025 (already passed → must post immediately)
    Post-approval: within 30 days of approval = 31-Jan-2026

Figure 10.1. ClinicalTrials.gov deadline calculation. The 12-month clock from PCD runs independently of the FDA review clock. Studies where the PCD was more than 12 months before the PDUFA date require posting regardless of approval status.

11. The Statistical Programmer's Checklist for Closeout

11.1 Pre-PDUFA Readiness Checklist

The following checklist should be completed before the PDUFA date arrives:

Table 11.1. Statistical programmer closeout readiness checklist.

11.2 The Data Reconciliation Imperative

The single most important practice during the closeout phase is cross-document data reconciliation — ensuring that every number referencing clinical data is consistent across all documents:

Table 11.2. Cross-document data reconciliation requirements. Every cell in this table represents a potential discrepancy finding during regulatory review.

A practical approach: maintain a master numbers table — a single spreadsheet maintained by the lead programmer or biostatistician that lists every key efficacy and safety number, its source (dataset + program + output table reference), and its current value. Every document that references that number is checked against the master table before submission.

12. Common Errors in the Closeout Phase

12.1 Error Catalog

Table 12.1. Common closeout phase errors with prevention strategies.

12.2 The "One Source of Truth" Imperative

The most systemic error pattern in the closeout phase is not any individual calculation mistake — it is the fragmentation of outputs across multiple teams, each maintaining their own version of a number. Medical Writing has a draft label table from Month 6 that has not been updated since the database lock. Regulatory Affairs is pulling numbers from a PowerPoint from the Phase III advisory board. The programmer has the correct final table from the locked datasets, but nobody has reconciled all three.

The prevention is organizational as much as technical: establish a single-source principle from the outset of the closeout phase. The lead programmer and lead biostatistician own the master numbers table. Every document that references a clinical data number is reconciled against that table before any regulatory submission.

13. Summary and Key Takeaways

The regulatory closeout phase is not a denouement — it is a distinct and demanding phase of clinical programming with its own deliverables, standards, and failure modes. These are the essential takeaways:

1. Know what documents are due and when. The USPI, DTS, ClinicalTrials.gov results, SmPC, RMP, JPI, and MedGuide all have different owners, timelines, and regulatory bases. Programmers who understand the full landscape can prioritize proactively rather than reactively.
2. Every label number is a regulatory commitment. Numbers in the USPI, DTS, SmPC, and ClinicalTrials.gov are legally binding statements that must be traceable to submitted, locked datasets. Rounding, denominator choice, and subgroup definition must be identical across all documents.
3. Cross-document reconciliation is not optional. The FDA, CHMP, and PMDA all cross-reference documents against each other. A discrepancy between ClinicalTrials.gov results and the USPI is a compliance finding, not an editorial error.
4. Information Requests and labeling comments require the same QC rigor as primary submission outputs. The compressed timelines during IR response periods tempt programmers to shortcut QC. This is where label errors are introduced. Maintain the full QC process regardless of timeline pressure.
5. Archive everything at the point of lock. Program versions, dataset versions, format catalogs, macro libraries, and SAS environment metadata must all be archived. Re-running a CT.gov results program 18 months after submission requires the identical computational environment as the original.
6. Race/ethnicity reporting is under regulatory scrutiny. The DTS and ClinicalTrials.gov both require OMB-compliant race and ethnicity categories. Programmers must ensure ADSL maps to these categories correctly from the outset — fixing it at the DTS stage is late.
7. SmPC and RMP outputs are different from USPI outputs. The frequency band system, exposure-adjusted incidence rates, and CHMP-specific subgroup formats require specific programming logic that does not exist in the standard CSR macro library. Build these early.
8. For global programs, Japanese and EU analyses are not afterthoughts. The PMDA and EMA review processes run in parallel with FDA and issue their own IRs on their own timelines. The Japanese subgroup and EU-specific analyses must be ready when those agencies ask — which is often not when FDA asks.
9. Establish IR readiness before the PDUFA clock starts. The ability to respond to an FDA Information Request within 14 business days depends entirely on how well-organized the submission programs are. Programs with hardcoded paths, undocumented macros, and no run logs are a liability in the closeout phase.
10. The programmer's role is not to produce outputs — it is to defend numbers. At the close of approval, every number in every regulatory document may be questioned by an agency reviewer, a medical officer, or a labeling reviewer. Programmers who understand the science, the datasets, and the derivation chain are indispensable partners to Regulatory Affairs, Medical Writing, and the statistician throughout this process.

References

• FDA. Physician Labeling Rule (PLR): Requirements for Prescribing Information. 21 CFR Parts 201, 314, and 601. Effective June 30, 2006. fda.gov
• FDA. Guidance for Industry: Labeling — Revised Recommendations for Selection and Use of a Reference Standard. 21 CFR Part 201.57. fda.gov
• FDA. Drug Trial Snapshots. Section 505(d)(7) of the FD&C Act; as added by FDARA 2017. fda.gov/patients/drug-approvals-and-databases/drug-trial-snapshots
• FDA. Guidance for Industry: Medication Guides — Distribution Requirements and Inclusion in Risk Evaluation and Mitigation Strategies (REMS). 21 CFR Part 208. fda.gov
• NIH/NLM. ClinicalTrials.gov Protocol Registration and Results System (PRS). 42 CFR Part 11 — Final Rule (2016). FDAAA 801 (42 USC 282(j)). clinicaltrials.gov
• EMA. Guideline on Summary of Product Characteristics (SmPC). QRD Template v10.1. ema.europa.eu
• EMA. Good Pharmacovigilance Practices (GVP) Module V — Risk Management Systems. Rev 2. ema.europa.eu
• ICH. E5(R1): Ethnic Factors in the Acceptability of Foreign Clinical Data. 1998. ich.org
• ICH. E17: General Principles for Planning and Design of Multi-Regional Clinical Trials. 2017. ich.org
• ICH. E3: Structure and Content of Clinical Study Reports. 1995. ich.org
• CDISC. Analysis Results Metadata (ARM) User Guide. cdisc.org. cdisc.org
• FDA. Guidance for Industry: Structured Product Labeling (SPL). HL7 SPL Implementation Guide. fda.gov
• FDA. Guidance for Industry and Investigators: Safety Reporting Requirements for INDs and BA/BE Studies. fda.gov
• PMDA. New Drug Application Review Process and Package Insert Requirements. MHLW/PMDA. pmda.go.jp

Published by clinstandards.org — Technical Reference for the CDISC Statistical Programming Community. All content is based on primary regulatory and CDISC sources.