PQ-CMC Manufacturing Process 3.2.P.3 — Coding the Process Description
The manufacturing process section 3.2.P.3 is the most operationally complex section of the CMC submission to convert to PQ-CMC structured format — because it requires representing not just data values…
On this pageArticle overview
PQ-CMC Manufacturing Process 3.2.P.3 — Coding the Process Description
The manufacturing process section 3.2.P.3 is the most operationally complex section of the CMC submission to convert to PQ-CMC structured format — because it requires representing not just data values but process logic, equipment specifications, and in-process control relationships in machine-readable FHIR resources.
That sentence carries a precise meaning that practitioners who have worked through PQ-CMC implementation for specifications and batch analysis may not yet fully appreciate. Specifications and batch analysis results present a substantial structured data challenge — the test name coding, the operator-value-unit decomposition of acceptance criteria, the LIMS output reconfiguration, the schematron validation cycles. But at the architectural level, a specification is a list of tests and a batch analysis record is a list of results. The data model is demanding but the logical structure is flat. The manufacturing process is not flat. It is a directed sequence of unit operations, each with associated equipment, critical and non-critical process parameters, and in-process controls — and the relationships between those elements are as important to KASA as the elements themselves. The goal of PQ-CMC structured process data is not merely to encode each step and each parameter. It is to encode the process as a connected FHIR resource graph that preserves the logical architecture of the process: which parameters belong to which steps, which in-process controls are associated with which operations, which equipment executes which actions, and which batch formula components flow through which unit operations. A process description that correctly encodes every parameter but severs the linkages between parameters, steps, and controls is, from KASA’s perspective, a collection of unconnected data objects — not a process model.
Understanding the scope of this challenge requires examining the FHIR resource architecture that the same modeling approach already established by FDA and HL7 for the published portions of the PQ-CMC Implementation Guide will most plausibly require for the remaining 3.2.P.3 manufacturing process content, and understanding why each structural element exists and what it enables.
A scope note matters here before going further, because it changes how a CMC team should read everything below. The HL7 PQ-CMC Implementation Guide is being built and balloted in stages, and as of the current published edition (v2.0.0, STU2), only 3.2.P.3.2 — the batch formula — is live as a published FHIR profile; it is represented through the Ingredient resources already established for product composition. The broader 3.2.P.3 process description — the unit operation sequence, equipment, critical process parameters, and in-process controls addressed in 3.2.P.3.3 and 3.2.P.3.4 — is officially designated by FDA as Phase 2 of the PQ/CMC data-standards effort, covering “Drug Product Manufacturing and Drug Substance Manufacturing,” and FDA describes that phase as under active development rather than published. What follows is the architecture that FHIR’s existing resource vocabulary — and the design patterns FDA and HL7 have already used for the specification and composition content that is published today — makes the most technically coherent choice for that Phase 2 work, not a description of profiles that are already final. CMC teams should treat this as a build-readiness framework to prepare their data against, and should confirm the exact profile names and mandatory elements against the Federal Register Notice and IG ballot text once Phase 2 is formally published, rather than assuming today’s terminology is frozen.
The Process Description in FHIR: Why P.3 Is the Most Complex PQ-CMC Section to Implement
The most technically coherent anchor for a future PQ-CMC manufacturing process resource graph is the manufactured-item representation the IG already uses for composition and container closure data — today published as the “Manufactured Drug Product” profile, built on FHIR’s core product-definition resources rather than a bespoke structure. The natural extension of that same pattern is for the physical manufactured item — the tablet, the capsule, the vial produced at a defined manufacturing site — to carry two additional reference slots once process content is added: a reference to the Organization resource representing the manufacturing site (already a first-class resource type in the published IG for sponsor and supplier identification), and a reference to a process-definition resource that encodes the manufacturing process itself. Core FHIR offers PlanDefinition for exactly this purpose — representing an ordered protocol of actions — and it is the standard resource other FHIR implementation guides use to encode multi-step procedures, which is why it is the most plausible choice for FDA and HL7 to adopt when Phase 2 is published. Until that publication, CMC teams should treat these as the two reference slots to design their internal process data model around, not as confirmed elements of a final profile.
The manufacturing site is the strongest candidate to be represented as an Organization resource, because Organization is already a confirmed, published resource type in the current PQ-CMC IG — today used to identify the sponsor and supplier of drug products and substances, carrying name and address as structured fields. Extending that same profile to a manufacturing site would logically add the facility registration identifiers — the FDA Establishment Identifier (FEI) and, where applicable, the DUNS number — as coded data elements, along with a site-type classification (commercial manufacturing, development, contract manufacturing organization); these specific extensions are a reasonable design expectation, not yet a published requirement. For submissions involving multiple manufacturing sites — a separate granulation site, a compression and coating site, and a packaging site, for example — the coherent design is a discrete Organization resource per site, with the process step sequence carrying references that correctly associate each unit operation with its execution site. That kind of site-level process linkage is what would let a KASA reviewer construct a complete picture of the manufacturing network from the structured data submission, rather than manually tracing the narrative text of a process description — which is precisely the efficiency case for building 3.2.P.3 process data to this standard once it is published.
The manufacturing process itself is the natural fit for a PlanDefinition resource — the FHIR resource purpose-built to represent an ordered protocol of actions, and the standard choice other FHIR implementation guides use for exactly this kind of multi-step process. Modeled this way, the PlanDefinition would represent the complete manufacturing process as an ordered collection of action definitions, where each action corresponds to a unit operation in the manufacturing sequence, with the sequence made explicit — not left implicit in narrative text — through the action.relatedAction elements that allow each step to reference the step that precedes or follows it. This sequencing is what encodes, in machine-readable form, the process logic that a manufacturing technician reads directly off a flowchart.
Each unit operation is the corresponding candidate for an ActivityDefinition resource referenced by the PlanDefinition — again, the standard FHIR resource for defining a single action within a plan. Under this design, the step name would be a coded element rather than free text, drawn from a PQ-CMC controlled vocabulary for pharmaceutical manufacturing operations analogous to the controlled vocabularies FDA and HL7 have already published for specification test names and dosage forms. Such a vocabulary would need coded terms for the standard unit operations of pharmaceutical manufacturing: mixing, wet granulation, dry granulation, fluid bed granulation, blending, milling, sieving, compression, film coating, sugar coating, encapsulation, filling, sterilization, lyophilization, inspection, and packaging. A step name outside any published controlled vocabulary would require either mapping to the closest available term or an extension pathway, consistent with how the current IG already handles terminology gaps elsewhere. Organizations whose internal SOP nomenclature for unit operations has evolved over decades with company-specific or product-specific step names should begin a systematic mapping exercise now, well ahead of Phase 2 publication, so the gap between internal terminology and whatever controlled vocabulary FDA ultimately publishes is already understood rather than discovered under submission deadline pressure.
The equipment associated with each unit operation is the natural candidate for a reference, from the ActivityDefinition, to a DeviceDefinition resource — FHIR’s standard resource for equipment and device representation. Modeled consistently with how the IG already handles other coded, quantitative attributes, a manufacturing DeviceDefinition would be expected to carry the equipment type as a coded value, the equipment name, the equipment capacity expressed as a numeric value with UCUM units (typically kilograms for blenders and granulators, liters for coating pans and tanks), and key operational parameters for the equipment type. A fluid bed granulator DeviceDefinition, for example, would plausibly carry the equipment type code, the batch capacity, the filter type classification, and the inlet air capacity; a tablet press DeviceDefinition would plausibly carry the number of punches and the tooling type. This level of equipment characterization is more granular than many organizations carry in their process descriptions at the NDA stage today, and it is worth surfacing as a likely data gap now: equipment specifications that are described in general narrative terms in a current process description will eventually need to be re-captured as discrete structured fields with numeric values and units, whatever the final published element names turn out to be.
Process Parameters, In-Process Controls, and Equipment in Structured Format
Critical and non-critical process parameters are the logical candidate to be encoded within the ActivityDefinition of the associated unit operation as structured parameter definitions. Following the field-level discrete-data pattern the current published IG already uses for specification acceptance criteria (operator, value, and units as separately populated fields, governed by the same TargetRange-style extension the IG uses today), a coherent CPP model would carry four elements per parameter: the parameter name, drawn from a controlled vocabulary for manufacturing process parameters; the criticality classification, coded as CPP (critical process parameter) or non-CPP; the operating range, expressed as a minimum and maximum value with UCUM units; and, for CPPs, a target value as a discrete numeric field. If FDA and HL7 publish Phase 2 consistent with how they have built every other part of this IG, that classification will be a machine-readable coded element rather than a narrative annotation — which is what would let a KASA reviewer programmatically identify all CPPs across a submission and compare them across batches without manual extraction.
The practical significance of preparing for this kind of structured CPP model is substantial for organizations that have historically represented process parameter classification and ranges in hybrid formats — a parameter table embedded in the process description narrative with ranges expressed as text strings such as “60–80 rpm” or “NMT 2.5% moisture content.” Under the discrete-field pattern the published IG already uses elsewhere, each of those text-string representations will eventually need to be decomposed into a numeric minimum, a numeric maximum, a UCUM unit, and a coded parameter name. The parameter name “impeller speed” would need to map to whatever coded term the eventual controlled vocabulary assigns to that parameter type. The range “60–80 rpm” would become a minimum value of 60 and a maximum value of 80 with the UCUM code for rotational speed. The target value, if separately defined in the process description, becomes a discrete numeric field. Getting this decomposition habit in place now, ahead of a published requirement, is the single highest-leverage preparation step a CMC data team can take for 3.2.P.3.
In-process controls are the most natural fit for linked ObservationDefinition resources associated with the corresponding unit operation ActivityDefinition — ObservationDefinition being FHIR’s standard resource for defining an observation or test type, which is exactly what an IPC is. Modeled this way, the ObservationDefinition for an IPC would carry the test name as a coded element, the sampling plan as structured fields for sampling frequency, sample size, and sampling point within the operation, and the acceptance criterion for the in-process test as a structured operator-value-units triplet — the same triplet structure the published Specification profiles already use today for release acceptance criteria. That structural parallelism between specification and IPC acceptance criteria would be a deliberate, low-cost design choice for FDA and HL7 to make, since it lets a single piece of parsing logic handle both in-process and release testing rather than requiring separate interpretation logic for each.
The linkage between IPC ObservationDefinitions and their parent unit operation ActivityDefinitions would need to be explicitly encoded through FHIR reference syntax for any of this to function as intended. An ObservationDefinition for blend endpoint — blend uniformity by NIR, for example — that is not correctly referenced to the blending step ActivityDefinition would not be recognizable as an in-process control for the blending operation specifically. From a data modeling perspective, an unlinked IPC is an anonymous test definition with no process context. The test may be technically correct in every detail and still fail to contribute a usable process model because its positional and functional relationship within the process was never established — which is exactly the kind of structural gap worth testing for now, before Phase 2 profiles are finalized and a real submission deadline is on the line.
ICH Q8(R2) provides the scientific foundation for CPP classification and the design space concept that informs operating range definition. ICH Q11 extends this framework to drug substance manufacturing and provides the scientific basis for relating process parameters to CQAs in both small molecule and biological manufacturing contexts. FDA’s January 2011 Process Validation Guidance establishes the three-stage process validation lifecycle — process design, process qualification, continued process verification — and whatever structured data model FDA and HL7 ultimately publish for manufacturing process parameters will need to be consistent with the validation data that supports CPP classification and range justification under that three-stage framework, because the underlying science does not change regardless of which FHIR profile eventually carries it. The operating range that any future CPP structured data element should carry is the validated range — the range that has been demonstrated to maintain the CQA within its acceptance criterion — not the wider range of an experimental design or the tighter range of a single development batch. Getting this substantive judgment right is independent of, and more important than, the eventual profile mechanics.
Batch Formula, Batch Size, and Manufacturing Site as Structured FHIR Resources
This is the one part of the 3.2.P.3 resource graph that is not speculative: the batch formula is already published, live, and structured today, through the Drug Product Batch Formula Ingredient profile established in the product composition subgraph — specifically through the per-component quantity fields that carry the amount of each ingredient per batch unit, with worked examples for both a liquid drug product and a two-layer tablet already published as example Bundles in the current IG. In PQ-CMC structured format, the batch formula is not a separate standalone element; it is encoded as the per-unit quantities within those ingredient resources, scaled to the batch size. Batch size itself — a numeric value, UCUM units, and a batch size type classification such as commercial batch, registration batch, or development batch — is the kind of structured element that would let a KASA reviewer distinguish batch types when working through batch analysis and process validation data, and is a reasonable design expectation for wherever FDA ultimately anchors it once the surrounding process content is published.
For products with multiple authorized batch sizes — a registration batch size of 100,000 tablets and a commercial batch size of 400,000 tablets — the coherent design is to encode each batch size as a discrete structured element, with the process parameters and operating ranges that are batch-size-dependent encoded to reflect the applicable batch size context. This is an area of 3.2.P.3 data readiness that already deserves close coordination between the regulatory CMC team and the process development team today, ahead of any published requirement, because the relationship between batch size and process parameter ranges — particularly for equipment-dependent parameters such as granulation spray rate or coating pan speed — is frequently embedded in process development reports rather than explicitly stated in the commercial process description. Surfacing that information now, before it must be submitted in structured form, means reaching back into process development data to establish the batch-size-to-parameter-range relationship as explicit, traceable information while the people who generated it are still available to explain it.
The manufacturing site Organization resource, extended with FEI and, where applicable, DUNS identifiers as structured fields alongside site address and operational classification, would need to accurately represent the operational site for contract manufacturing organizations executing licensed operations — not the corporate parent. This distinction matters today for FDA facility inspection tracking under the existing eCTD process, independent of whether 3.2.P.3 process content is structured yet, and it will matter for associating manufacturing site information with specific process steps once that content is published.
The complete 3.2.P.3 resource graph this article has walked through — a manufactured-item representation referencing Organization and a PlanDefinition-based process model, that PlanDefinition referencing sequenced ActivityDefinitions, each ActivityDefinition carrying equipment DeviceDefinition references, CPP structured parameter elements, and linked IPC ObservationDefinitions, with the already-published batch formula Ingredient resources anchoring the quantities — represents the most defensible current best estimate of what a genuine digital representation of the manufacturing process description will look like. It is not a reformatted PDF, and building your internal process data to this shape now, using resource types FHIR already defines for exactly these purposes, is the lowest-risk way to be ready whichever specific profile names FDA ultimately publishes for Phase 2.
For your primary drug product manufacturing process, list all critical process parameters with their target values and operating ranges — then check whether your current CMC data system can output each CPP as a structured data field with a coded name, a numeric range, and units, independent of what FDA’s eventual controlled vocabulary calls each parameter. That check will tell you exactly where your 3.2.P.3 structured-data readiness stands today, and it is work you can start well before FDA finalizes and publishes the Phase 2 profiles.
THE XGENE PQ-CMC MANUFACTURING PROCESS STRUCTURED DATA ARCHITECTURE
The XGene PQ-CMC Manufacturing Process Structured Data Architecture is the practitioner readiness framework for 3.2.P.3 eCTD structured submission design and implementation. It is built to the resource architecture most consistent with FDA’s published Phase 1 PQ-CMC profiles and standard FHIR design patterns, for use ahead of FDA’s formal publication of Phase 2 (Drug Product and Drug Substance Manufacturing) — confirm exact profile and vocabulary names against the Federal Register Notice and IG ballot text once Phase 2 is published.
Step 1 — Process Step Inventory and PQ-CMC Controlled Vocabulary Coding: List every unit operation in the manufacturing process sequence. Map each step name against the PQ-CMC controlled vocabulary for pharmaceutical manufacturing operations. Identify steps with no direct vocabulary match and determine the appropriate coded term or extension pathway. This inventory is the foundation of the PlanDefinition action sequence.
Step 2 — CPP Classification and Structured Parameter Data Model: For each unit operation, enumerate all associated process parameters. Classify each as CPP or non-CPP using the PQ-CMC criticality coding. For CPPs, establish the structured data elements: coded parameter name from PQ-CMC controlled vocabulary, target value, validated operating range minimum and maximum, and UCUM units. Confirm alignment between encoded ranges and the validated ranges from FDA Process Validation Guidance three-stage lifecycle data.
Step 3 — IPC Structured Data Migration from Narrative Tables: Extract all in-process control tests from the process description. For each IPC, map the test name to PQ-CMC controlled vocabulary, encode the sampling plan as structured frequency, size, and point fields, and decompose the acceptance criterion into operator-value-units format. Confirm correct reference linkage to the parent unit operation ActivityDefinition.
Step 4 — Equipment DeviceDefinition Resource Construction: For each unique equipment type in the process, build a DeviceDefinition resource carrying the equipment type code, capacity with UCUM units, and key operational parameters for the equipment type. Confirm that capacity values and equipment characteristics reflect the commercial manufacturing equipment, not development-scale surrogates.
Step 5 — Batch Formula Ingredient Integration and Batch Size Encoding: Confirm that the already-published Drug Product Batch Formula Ingredient resources carry per-unit quantities that correctly represent the commercial batch formula. Encode batch size as a structured element with numeric value, UCUM units, and batch size type classification, anchored wherever FDA ultimately places it in the manufactured-item representation. For products with multiple authorized batch sizes, encode each batch size as a discrete structured element.
Step 6 — Manufacturing Site Organization Resource Construction: Build Organization resources for each manufacturing site in the process. Populate FEI and DUNS identifiers as structured coded fields. Confirm that site classification accurately reflects the operational site type. Link each site Organization resource to the corresponding unit operation ActivityDefinitions where site-specific step execution is defined.
Step 7 — Process Step FHIR Resource Graph Construction: Assemble the complete PlanDefinition with sequenced ActivityDefinition references. Encode step sequencing through action.relatedAction elements. Confirm that every ActivityDefinition carries correctly structured equipment references, CPP parameter elements, and IPC ObservationDefinition linkages. Trace the complete resource graph from the manufactured-item representation through PlanDefinition to each leaf resource before validation.
Step 8 — Validation Once PQ-CMC Manufacturing Process Profiles Are Published: Run the complete manufacturing process resource graph through the standard HL7 FHIR validator against the PQ-CMC Implementation Guide’s manufacturing process profiles as soon as FDA publishes Phase 2. Until then, validate the underlying data — completeness, coded values instead of free text, discrete operator-value-units fields — against this framework so the migration to the final published profile is a mapping exercise, not a data-collection project. Address all errors and warnings before eCTD submission. Document the validation pass as a submission quality record.