PQ-CMC Drug Substance 3.2.S — Structured Data Submission Deep Dive

PQ-CMC Drug Substance 3.2.S — Structured Data Submission Deep Dive

FDA’s PQ-CMC program has already published its HL7 FHIR Implementation Guide through Stage 2 — and the companies that wait for a final FDA mandate before mapping their 3.2.S data against it are going to discover the gap when a reviewer query lands, not during preparation.

That is not a hypothetical risk. It is the logical consequence of building a submission around narrative documents while the regulatory framework moves deliberately, stage by stage, toward requiring machine-readable data alongside those documents, and while the reviewer infrastructure — FDA’s KASA (Knowledge-aided Assessment & Structured Application) system, already the routine review platform for non-sterile solid oral dosage form ANDAs — is being built around structured inputs that your systems have not been configured to produce. FDA has been explicit that Connectathon testing and balloting of the IG do not themselves constitute a statement of policy, but the direction is unambiguous, and the discovery moment arrives when a deficiency letter asks for data in a format your LIMS was never configured to export.

Drug substance Module 3 content — the 3.2.S sections covering general information, manufacture, characterization, control, reference standards, container closure, and stability — represents the most densely data-rich portion of a typical CMC submission. The PQ-CMC structured data requirements for 3.2.S are not a thin overlay on existing narrative content. They require pharmaceutical companies to decompose every specification table, batch analysis record, and stability result into discrete, coded, machine-readable FHIR resources that carry terminology-bound field values and maintain explicit resource linkages that a narrative PDF cannot express. Understanding what that decomposition requires — at the level of actual FHIR resource architecture — is the only way to honestly assess whether your organization is prepared.

What PQ-CMC 3.2.S Structured Data Requires: FHIR Resources, Coded Terminology, and Machine-Readable Specifications

The HL7 FHIR PQ-CMC Implementation Guide, published through HL7.org and maintained through FDA’s phased rollout program, defines a specific set of FHIR resource types that collectively represent the drug substance content of a Module 3 submission in structured form. Each resource type corresponds to a distinct category of CMC content, and each resource carries defined required and optional elements with prescribed terminology bindings and structural constraints. There is no ambiguity about what is required — the IG specifies it, and the PQ-CMC IG’s published Validator Pack, run against the standard HL7 FHIR Validator, checks submissions against those specifications automatically.

The foundation of drug substance structured data is the SubstanceDefinition resource. This resource encodes the identity of the drug substance itself: the substance name and synonyms as text and coded values, the molecular formula, the molecular weight with numeric value and units, stereochemical description, CAS registry number, and identification codes. The UNII — Unique Ingredient Identifier — assigned through FDA’s Substance Registration System (SRS) is the required code system for substance identity in PQ-CMC submissions. Every active substance in a PQ-CMC-compliant submission must have a registered UNII, and that UNII must appear as the primary coded identifier in the SubstanceDefinition resource. For organizations whose regulatory affairs teams have not maintained current UNII registrations, or who are working with novel substances not yet assigned a UNII, this is an upstream prerequisite that must be resolved before any downstream FHIR construction is possible.

The Ingredient resource links the identified substance to the product context, encoding the component’s role (active, inactive, excipient), the reference amount or concentration, and the reference to the parent SubstanceDefinition. The chain of resource relationships — SubstanceDefinition to Ingredient to MedicinalProductDefinition — is explicit and mandatory in the PQ-CMC data model. These are not independent data objects. They are interlinked FHIR resources, and the relationships between them must be correctly expressed through FHIR reference syntax for the submission bundle to be valid. A SubstanceDefinition that is not properly referenced from an Ingredient, or an Ingredient that does not carry a valid reference to a MedicinalProductDefinition, will fail schematron validation. This relational architecture is fundamentally different from a document structure, and it requires a deliberate design step, not a formatting conversion.

Specifications — the data captured in 3.2.S.4.1 — are encoded in the PQ-CMC model using PlanDefinition and ActivityDefinition resource structures. The critical conceptual shift here is that a specification is not a table in PQ-CMC — it is a structured set of action definitions, where each test is an ActivityDefinition carrying the test name as a coded value from the PQ-CMC controlled terminology, the analytical method as a referenced identifier, and the acceptance criterion as three discrete structured fields: the operator (equal to, not more than, not less than, between), the numeric value or values, and the units expressed in UCUM — the Unified Code for Units of Measure. What appears as a single row in a traditional specification table — “Assay: 98.0% to 102.0% (HPLC)” — becomes a structured ActivityDefinition with individually addressable fields for each component of that criterion.

The test name itself is not free text in a PQ-CMC-compliant submission. It is drawn from the PQ-CMC controlled terminology maintained as part of the IG, which defines coded terms for standard pharmaceutical quality tests. Using a non-coded, free-text test name will cause validation failures. This means that CMC teams must map every test name used in their existing specifications against the PQ-CMC controlled terminology and either match to an existing term or follow the defined process for handling tests not covered by the standard term set. For organizations with large specification libraries developed over years with internally standardized but non-IG-aligned terminology, this mapping exercise is a significant upstream effort that reveals the real scope of the implementation task.

Batch analysis results, captured in 3.2.S.4.4, are represented in PQ-CMC as FHIR Observation resources. Each Observation encodes a single test result from a single batch: a reference to the test as defined in the specification ActivityDefinition, the result value and units, a reference to the batch identity, the testing date, the pass/fail determination, and the method reference. The Observation model is explicit about result linkage — the Observation must reference both the specification ActivityDefinition from which the test criterion was drawn and the batch record against which the result is being reported. This linkage is what enables KASA to automatically compare reported results against specification limits without manual reviewer extraction. If your batch analysis records exist only as PDF exports from your LIMS, there is no automated path to constructing FHIR Observations. The source data must be accessible in a structured form at the field level — result value, units, batch number, test reference — and your systems must be able to export that data in a format from which valid FHIR Observation bundles can be constructed.

Stability data in 3.2.S.7 follows the same Observation resource pattern, with the addition of two required contextual fields that distinguish stability Observations from batch analysis Observations: the time point — encoded as a numeric value with units (months, weeks, days) using UCUM — and the storage condition — encoded as a coded term specifying temperature and humidity from the PQ-CMC controlled terminology (25°C/60%RH for long-term, 40°C/75%RH for accelerated, and so on). A stability dataset that in narrative format might appear as a multi-column table with time points as column headers becomes, in PQ-CMC format, a series of individual Observation resources, each carrying a single result at a single time point under a single storage condition, with all contextual fields explicitly encoded. The granularity is intentional — it enables KASA to process stability trends, compare time-point results to the specification criterion at each interval, and flag out-of-trend observations automatically.

The PQ-CMC IG’s published Validator Pack, designed for use with the standard HL7 FHIR Validator, is publicly available on the IG’s Downloads page and represents the definitive automated check against which any PQ-CMC submission should be tested before filing. This validation tooling checks resource structure, required element presence, terminology code validity, UCUM unit format, and cross-resource reference integrity. A submission that passes schematron validation has cleared the structural compliance bar — the data architecture is correct and the coded terminology is valid. A submission that fails produces specific error messages that identify the precise resource, element, and constraint violated. Organizations building PQ-CMC capability for the first time should plan for multiple validation-remediation cycles before achieving a clean pass, because the error set from a first attempt against real CMC data routinely reveals both data model gaps and source system data quality issues that were not visible when the same data was reported in narrative format.

The action is specific: locate the PQ-CMC Implementation Guide on FDA.gov and identify whether your most recent or upcoming NDA, BLA, or ANDA submission type is in the current scope — and if it is, assess whether your drug substance specification data can be output in the required FHIR structured format from your current data systems.

The XGene PQ-CMC 3.2.S Structured Data Implementation Program

At XGene, we approach PQ-CMC 3.2.S structured data implementation as a seven-component program, not a documentation project.

COMPONENT 1 — UNII Registration for All Active Substances Confirm current UNII registration status for every active drug substance in your development and commercial portfolio. UNII codes are required as the primary coded identifier in the PQ-CMC SubstanceDefinition resource. Unregistered or lapsed UNII registrations must be resolved upstream of any FHIR construction activity.

COMPONENT 2 — Specification Data Model Redesign Against PQ-CMC FHIR Resource Structures Map your existing specification content — every test, method, and acceptance criterion across your 3.2.S.4.1 specification tables — against the PlanDefinition/ActivityDefinition resource structure required by the PQ-CMC IG. This mapping identifies where free-text test names require replacement with PQ-CMC controlled terminology codes, where acceptance criteria must be decomposed into operator/value/unit fields, and where method references must be formalized as identifiers rather than narrative descriptions.

COMPONENT 3 — LIMS/QMS Output Configuration for FHIR-Compatible Data Export Assess your LIMS and QMS systems for the ability to export batch analysis data in FHIR-compatible structured format. Configure export templates or middleware to produce FHIR Observation resource inputs from batch release records, with correct references to specification ActivityDefinitions, batch identifiers, and UCUM-formatted units.

COMPONENT 4 — Batch Analysis FHIR Observation Construction and Validation Build and validate FHIR Observation resources for batch analysis data. Confirm that each Observation carries a valid reference to the specification test ActivityDefinition, a valid batch reference, a properly structured result value and UCUM unit, and the correct pass/fail determination. Run against FDA PQ-CMC schematron validators at each build stage.

COMPONENT 5 — Stability Data Structured Format Implementation Implement stability Observation resources with time-point and storage condition fields encoded to PQ-CMC controlled terminology and UCUM standards. Validate the completeness and integrity of the stability dataset as a structured FHIR bundle, confirming that all time points, storage conditions, and test references are correctly encoded and cross-referenced.

COMPONENT 6 — FDA PQ-CMC FHIR Validator Testing Execute validation cycles against the PQ-CMC IG’s published Validator Pack, using the standard HL7 FHIR Validator, against real CMC data from an in-scope submission. Document error sets, remediate data model and source system issues, and re-validate until a clean pass is achieved. Plan for three to five validation-remediation cycles on a first implementation.

COMPONENT 7 — Phased Submission Timeline Aligned to FDA Implementation Requirements Build a phased implementation timeline that aligns internal data system readiness to FDA’s current and projected PQ-CMC scope expansion schedule. Prioritize submission types with the earliest structured data requirements, and build a validation-tested FHIR export capability into your standard submission authoring workflow before the first in-scope filing date.