PQ-CMC Drug Product 3.2.P — eCTD Structured Format Implementation
The drug product Module 3 sections are the most complex part of the PQ-CMC structured data implementation — because they require structured representation not just of specifications and batch data,…
On this pageArticle overview
PQ-CMC Drug Product 3.2.P — eCTD Structured Format Implementation
The drug product Module 3 sections are the most complex part of the PQ-CMC structured data implementation — because they require structured representation not just of specifications and batch data, but of the entire pharmaceutical development rationale, the manufacturing process, and the finished product quality profile.
That sentence is not a caveat or a hedge. It is a statement of architectural fact. When FDA launched the PQ-CMC initiative under its Data Modernization Action Plan and began issuing HL7 FHIR-based Implementation Guides for structured CMC data submissions, the drug product sections presented a categorically different implementation challenge than drug substance. Drug substance structured data — 3.2.S — is demanding. It requires FHIR resources for substance identity, molecular structure, physicochemical characterization, specification, batch analysis, and manufacturing. But the resource graph for a drug substance, while complex, is relatively linear. The drug product resource graph is not linear. It is a web of interconnected FHIR resources that must represent not only what the product is, but what it contains, how it is made, how its performance is controlled, and how the container system maintains its quality — all in machine-readable structured format.
Practitioners who approach 3.2.P PQ-CMC structured data implementation the same way they approach 3.2.S will encounter failures at the KASA validation stage that are not failures of data accuracy. The specifications will be correct. The batch results will reflect the actual data. The excipient list will be complete. The failures will be structural — disconnected resource references, incomplete profile conformance, missing mandatory coded elements — because the drug product implementation was built incrementally, section by section, rather than architecturally, as a resource graph with defined linkage points.
Understanding why this happens requires understanding the HL7 FHIR PQ-CMC drug product resource architecture at the foundational level.
The drug product FHIR resource graph starts with MedicinalProductDefinition. This resource is the anchor of the entire 3.2.P structured data submission. It carries the product name — both the international nonproprietary name and any proprietary name — the dosage form coded using an established terminology, the route of administration, the regulatory status, and references to the regulatory authorization. The MedicinalProductDefinition is not simply an identifier record. It is the central node from which the rest of the resource graph branches. Everything else — the composition, the manufacturing process representation, the specification, the batch analysis — either references MedicinalProductDefinition directly or references a resource that references it. If the MedicinalProductDefinition is constructed incompletely, or if its references to downstream resources are absent, the entire resource graph becomes disconnected at the root.
From MedicinalProductDefinition, the resource graph extends to ManufacturedItemDefinition. This resource represents the physical manufactured item — the tablet, the capsule, the vial, the prefilled syringe — and carries the physical form description, the unit of presentation, and references to the manufacturing site. The distinction between MedicinalProductDefinition and ManufacturedItemDefinition is not merely semantic. MedicinalProductDefinition represents the authorized product as a regulatory construct. ManufacturedItemDefinition represents the physical object that is produced at a defined manufacturing location. A single MedicinalProductDefinition can, in complex cases, reference multiple ManufacturedItemDefinitions — for example, a combination product with multiple physical components. For most solid oral dosage form NDAs, there is a one-to-one relationship, but the architecture must accommodate the distinction.
The Ingredient resources are where the drug product structured data implementation diverges most sharply from drug substance. Every excipient in the drug product formula must be represented as a separate Ingredient resource. The Ingredient resource carries the substance identity — referenced back to a SubstanceDefinition resource — the function of that excipient in the formulation, and the quantity, expressed as a structured data element with numeric value, units, and reference to the total composition. The substance identity within the SubstanceDefinition resource must include the UNII code — the Unique Ingredient Identifier assigned by the FDA Substance Registration System — as a machine-readable coded identifier. INCI coding is an acceptable alternative for certain cosmetically-derived excipients, but UNII is the standard for pharmaceutical excipients in PQ-CMC structured submissions.
Consider what this means in practice for a typical solid oral dosage form — an immediate-release tablet with eight to ten excipients. The active ingredient requires one Ingredient resource, coded with its UNII and referencing a SubstanceDefinition that carries molecular formula, molecular weight, and physical form data. Each of the seven to nine excipients — a diluent such as microcrystalline cellulose, a binder such as hydroxypropyl cellulose, a disintegrant such as croscarmellose sodium, a lubricant such as magnesium stearate, and so on — requires its own Ingredient resource with its own UNII code and function coding. By the time the composition is fully structured, you have eight to ten Ingredient resources, eight to ten SubstanceDefinition resources (or references to pre-existing shared SubstanceDefinition resources in the FDA substance registry), all linked to a single ManufacturedItemDefinition, which is itself linked to MedicinalProductDefinition. This is the composition subgraph alone.
The specification subgraph adds another layer of complexity — and it is architecturally different from what practitioners coming out of the drug substance side tend to assume. In PQ-CMC structured format, the drug product release and shelf-life specification for 3.2.P.5 is represented as a single PlanDefinition resource, profiled as the Quality Specification — not as a PlanDefinition with a separate resource instance spun up for every test. Each individual specification test — appearance, identification, assay, content uniformity, dissolution, degradation products, microbial limits, and so on — is represented as a nested action element within that same PlanDefinition, carrying the test name and analytical method reference as coded elements (using the PQ-CMC test category terminology) and an order extension that preserves the CTD test sequence. The acceptance criterion itself is represented as a goal element referenced from its corresponding action by a goalId, structured as a coded interpretation — EQ, LT (less than), MT (more than), NLT (not less than), NMT (not more than) — paired with a numeric value and unit code, which is the FHIR-native equivalent of an operator-value-units triplet. Staged tests such as dissolution timepoints or cascade-impactor plate groupings nest as child actions beneath a parent action, each carrying its own goalId, so a single multi-stage test can require three or four levels of nested actions before the acceptance criteria resolve. Free-text acceptance criteria — “the assay result shall be within acceptable limits” — are not compatible with PQ-CMC structured format. Every acceptance criterion must be deconstructed into a coded interpretation, a value, and a unit before it can be entered as a goal.
For a typical solid oral dosage form with fifteen to twenty release tests, the specification domain contributes a single PlanDefinition resource containing fifteen to twenty nested action/goal pairs, referenced back to the MedicinalProductDefinition — one richly structured resource rather than a proliferation of resource instances, which is precisely why practitioners who count resources instead of validating internal action/goal linkage underestimate the implementation risk. Combined with the composition subgraph’s Ingredient and SubstanceDefinition resources, a routine solid oral dosage form 3.2.P PQ-CMC structured submission will typically contain somewhere in the range of fifteen to twenty-five top-level linked FHIR resources before batch analysis data is added — fewer discrete resources than a one-resource-per-test model would suggest, with the real complexity concentrated inside the nested action/goal structure of the specification PlanDefinition itself.
Batch analysis data in 3.2.P.8 is represented as FHIR Observation resources, typically grouped under a DiagnosticReport that captures the batch conclusion. Each test result for each batch is one Observation, carrying a reference back to the specific action and goal within the specification PlanDefinition that defines the test and its acceptance criterion, a reference to the lot number and manufacturing information, the numeric result, the units, and the pass/fail determination against that acceptance criterion. For a product with three or four validation batches and fifteen to twenty tests per batch, the batch analysis subgraph alone may contain sixty to eighty Observation resources. These Observations must correctly reference the specific action/goal pair in the specification PlanDefinition. An Observation that references a nonexistent or misidentified action or goal will fail resource graph validation even if the numeric result is perfectly accurate.
The manufacturing process structured representation in 3.2.P.3 introduces yet another set of FHIR resources. The manufacturing process is encoded as a single PlanDefinition resource whose nested action elements represent each process step in sequence — the same action-based backbone structure used in the specification domain — with DeviceDefinition resources referenced for manufacturing equipment and in-process controls and critical process parameters captured as structured data within the relevant action steps where applicable. This is one of the more practically difficult areas of PQ-CMC drug product implementation because manufacturing processes are inherently narrative and procedural — they were designed to be read by manufacturing technicians, not parsed by algorithms — and the structured encoding must preserve the technical meaning while converting the narrative to coded data elements.
Container closure system data for 3.2.P.7 is also structured in PQ-CMC format, representing the container components, materials of construction, and relevant specifications as structured FHIR resources with references back to the product they contain.
The organizational implication of this architecture is fundamental. An organization that assigns the drug product PQ-CMC structured data implementation to a regulatory affairs team working section by section through the CTD will produce a collection of FHIR resources, not a FHIR resource graph. The resources will be individually populated but not architecturally connected. The composition resources will not correctly reference the specification resources. The batch analysis Observations will not correctly reference the actions and goals nested inside the specification PlanDefinition. The KASA system will reject the submission not because the pharmaceutical data is wrong, but because the data model is incomplete.
The organizations that execute 3.2.P PQ-CMC structured data implementation successfully are those that begin with resource graph architecture design before they populate any individual resource. They map every FHIR resource required for the submission, define the reference linkages between them, establish the coded element requirements for each resource, and only then begin the data population work. The architecture must precede the execution.
ICH Q8(R2) pharmaceutical development principles apply here in a way that has direct practical relevance: quality cannot be inspected into a product, it must be designed in. The same principle applies to PQ-CMC structured data submissions. Structural completeness cannot be corrected at the validation stage. It must be designed into the resource graph architecture before the first resource is populated.
FDA’s KASA — Knowledge-Aided Assessment and Structured Application — system is designed to extract and analyze structured CMC data as a connected graph. KASA cannot function as intended on a collection of disconnected resources, regardless of how accurately those resources represent the individual data points. The structured data submission must be a graph, and the graph must be complete.
THE XGENE PQ-CMC DRUG PRODUCT STRUCTURED DATA ARCHITECTURE
The XGene PQ-CMC Drug Product Structured Data Architecture is the practitioner framework for 3.2.P eCTD structured submission design and implementation.
Step 1 — MedicinalProductDefinition Construction: Build the root resource first. Populate product name (INN and proprietary), dosage form code, route of administration code, and regulatory status. Establish all downstream reference slots before populating referenced resources.
Step 2 — Ingredient Resource Construction with UNII Coding: Enumerate all drug product components — active ingredient and every excipient. Create a SubstanceDefinition resource for each unique substance, including UNII code from the FDA Substance Registration System. Create an Ingredient resource for each component, linking to the corresponding SubstanceDefinition and carrying quantity and function coding.
Step 3 — Specification PlanDefinition Construction with Nested Action/Goal Entries: Construct the release and shelf-life specification as a single PlanDefinition. Create a nested action element for each specification test, with a linked goal element carrying the acceptance criterion. Populate test name code from the PQ-CMC test terminology, method reference, and structured acceptance criterion (interpretation code + numeric value + unit code). Validate that every acceptance criterion in the existing specification document can be encoded in interpretation-value-units format, including staged and multi-level tests that require nested child actions.
Step 4 — Batch Analysis Observation Construction from LIMS Data: For each batch included in 3.2.P.8, create one Observation per test result. Each Observation must reference the corresponding action/goal pair in the specification PlanDefinition. Map LIMS output fields to FHIR Observation elements. Validate numeric result, units, and pass/fail determination for each entry.
Step 5 — Manufacturing Process Structured Encoding: Represent the manufacturing process as a single PlanDefinition with nested action elements for each process step in sequence. Include in-process control parameters as structured data within the relevant action steps where applicable. Reference manufacturing equipment using DeviceDefinition resources.
Step 6 — Container Closure Structured Representation: Represent container system components, materials of construction, and closure integrity specifications as structured FHIR resources with appropriate references to the product they contain.
Step 7 — FHIR Resource Graph Validation Against PQ-CMC IG: Run the complete resource graph through the HL7 FHIR validator against the PQ-CMC Drug Product Implementation Guide profiles. Verify that every mandatory element is populated, every reference resolves, and every coded element uses the required terminology.
Step 8 — Schematron Validator Testing Before Submission: Run FDA schematron validation rules against the complete bundle. Address all errors and warnings before eCTD submission. Document validator output as submission quality record.