HL7 FHIR for Pharmaceutical CMC — The Architecture Behind PQ-CMC
Most pharmaceutical CMC professionals know that PQ-CMC requires HL7 FHIR-formatted data — very few understand what FHIR actually is, how it structures pharmaceutical data, and why the data model matters…
On this pageArticle overview
HL7 FHIR for Pharmaceutical CMC — The Architecture Behind PQ-CMC
Most pharmaceutical CMC professionals know that PQ-CMC requires HL7 FHIR-formatted data — very few understand what FHIR actually is, how it structures pharmaceutical data, and why the data model matters for how you design and implement your CMC data systems.
This is not a criticism. It is a structural observation about how the pharmaceutical industry has been trained to think about regulatory submissions. For decades, CMC data lived in documents — Word files, PDFs, formatted tables, narrative paragraphs. The ICH M4Q(R1) CTD structure organized those documents into a logical architecture, but the underlying data remained unstructured. A specification was a table in a Word document. A batch analytical result was a row in a formatted Excel sheet exported to PDF. The regulatory reviewer read those documents, extracted the data mentally, and made an assessment. The data itself — the actual numbers, codes, and relationships — was never machine-readable. It existed only as formatted text.
HL7 FHIR changes that foundation entirely. And understanding what FHIR actually is — not as a file format, not as a conversion task, but as an information architecture — is the prerequisite for understanding why PQ-CMC implementation is as technically demanding as it is, and why the organizations that treat it as a document conversion exercise produce structurally incomplete submissions that fail validation.
FHIR stands for Fast Healthcare Interoperability Resources. It is a standard developed and maintained by Health Level Seven International (HL7) — the healthcare information technology standards organization — and it was originally designed to enable interoperability between electronic health record systems, clinical data platforms, and healthcare payers. The core innovation of FHIR is the concept of the resource: a standardized, discrete data unit with defined elements, defined data types, defined relationships to other resources, and a defined serialization format. A resource is not a document section. It is a structured data object with machine-readable content.
In FHIR, every entity — a patient, a medication, a diagnostic observation, an authorized product — is represented by its own resource type. Each resource type has a defined profile specifying which data elements are required, which are optional, and what coded terminologies must be used for each element. Resources reference each other through machine-readable references — effectively URL-based identifiers that allow one resource to point to another resource within the same submission bundle or within an external registry. A medication resource references the substance resource that defines its active ingredient. An observation resource references the test definition resource that specifies what was measured. The relationships between entities are not expressed as prose in a document — they are expressed as machine-readable references between data objects.
This is why FHIR is correctly described as a linked data architecture. A complete pharmaceutical product representation in FHIR is not a single file. It is a graph of interconnected resources — a network of data objects connected by references, forming a structured representation of the pharmaceutical product and its quality profile that can be traversed, queried, and analyzed by machine. The FDA’s KASA system — Knowledge-Aided Assessment and Structured Application — is built to operate on exactly this kind of structured graph, extracting relationships and patterns across submissions in ways that document-based review has never permitted.
The PQ-CMC Implementation Guide is published in two coordinated forms: the universal industry guide at hl7.org/fhir/uv/pharm-quality and the FDA-specific US Realm guide at hl7.org/fhir/us/pq-cmc-fda. Both are built on FHIR Release 5 (version 5.0.0) — not Release 4 — and that version dependency is not a technicality a CMC data architect can skip past. The entire Medication Definition resource family the PQ-CMC IG relies on — SubstanceDefinition, Ingredient, MedicinalProductDefinition, ManufacturedItemDefinition, RegulatedAuthorization, and PackagedProductDefinition — was introduced in R5 as a structural replacement for the R4-era MedicinalProduct resource family (MedicinalProduct, MedicinalProductIngredient, MedicinalProductManufactured, MedicinalProductPackaged, MedicinalProductAuthorization, SubstanceSpecification), which HL7 has since retired from active development. A FHIR server, validator, or data pipeline built or certified against R4 does not merely need reconfiguration to handle PQ-CMC data — the resource types the IG depends on do not exist in that version at all, and any vendor claiming “FHIR-compliant” output without confirming R5 conformance has not actually confirmed PQ-CMC readiness. Each profile in the IG takes a base FHIR R5 resource type and constrains it for pharmaceutical use — specifying which elements are mandatory in the PQ-CMC context, which coded terminologies must be used, and how resources must be linked to each other. The base FHIR standard defines the resource types. The PQ-CMC IG defines the profiles that pharmaceutical submissions must conform to. Both layers matter for implementation.
The foundational resources in the PQ-CMC architecture map directly to concepts that CMC scientists already understand. SubstanceDefinition is the resource that represents a drug substance or excipient — its identity, molecular structure, molecular formula, molecular weight, physical form, and regulatory identifiers including the UNII code from the FDA Substance Registration System. Every unique substance in a pharmaceutical submission — the active pharmaceutical ingredient, every excipient, every impurity reference standard that requires characterization — is represented by a SubstanceDefinition resource. The profile for SubstanceDefinition in the PQ-CMC IG requires the UNII code as a mandatory element, conforming to the ISO/IEC 21090 data type standard for coded values, and requires the molecular formula in Hill notation for new molecular entities.
Ingredient is the resource that represents a component in the context of a product — it is the resource that links a substance (via SubstanceDefinition reference) to a product (via ManufacturedItemDefinition reference) and carries the function and quantity of that component in the formula. SubstanceDefinition says what a substance is. Ingredient says what role that substance plays and in what amount in a specific product. This distinction is architecturally important: the same SubstanceDefinition for microcrystalline cellulose may be referenced by Ingredient resources in dozens of different products, each carrying different quantities and potentially different functions.
MedicinalProductDefinition represents the authorized medicinal product as a regulatory construct — the named product, its dosage form, its route, its regulatory status, and its regulatory authorization references. ManufacturedItemDefinition represents the physical manufactured item — the tablet, capsule, or vial that is physically produced at a manufacturing site. RegulatedAuthorization represents the regulatory approval itself. PackagedProductDefinition represents the marketed package — the container closure system and its configuration.
For specification data, the PQ-CMC IG uses a combination of ObservationDefinition, PlanDefinition, and ActivityDefinition resources. ObservationDefinition defines what a specific measurement or test is — its code, its data type, its permissible units. PlanDefinition assembles a structured plan — the specification itself — as a collection of test definitions. ActivityDefinition represents an individual test entry within the specification, carrying the test code, method reference, and structured acceptance criterion. The acceptance criterion structure — operator, value, units — is a machine-readable decomposition of what was previously expressed as a narrative statement in a formatted specification table.
Actual test result data — the batch analysis results that populate 3.2.S.4.4 for drug substance and 3.2.P.8 for drug product — is represented using Observation resources. Each Observation is a single test result record: it references the test definition via ObservationDefinition or ActivityDefinition, carries the numeric result and units, records the specimen identity and lot number, and captures the pass/fail determination against the acceptance criterion. The structure of the Observation resource is directly analogous to a single cell in a batch analysis table — but it is a machine-readable data object with explicit relationships to the test definition, the acceptance criterion, and the product, rather than a value in a formatted document.
FHIR submissions are delivered as FHIR Bundles. A Bundle is a structured collection of resources packaged together as a single submission document in JSON or XML serialization format. JSON is the more commonly used serialization for PQ-CMC submissions. The Bundle carries all the resources that compose the submission — the product definition, the substance definitions, the ingredient resources, the specification plan, the batch analysis observations — packaged together with their reference relationships intact. The FDA eCTD submission contains FHIR Bundle files that replace the formatted document sections of the traditional CTD.
The validation layer is what distinguishes a structurally complete submission from a collection of populated resources. The HL7 FHIR validator checks conformance of each resource to its PQ-CMC IG profile — verifying that all mandatory elements are present, that coded elements use the correct terminologies, and that all resource references resolve correctly within the bundle. The FDA schematron validator applies a second layer of business rules — checking regulatory logic and cross-resource consistency requirements that go beyond profile conformance. A submission that passes profile validation but fails schematron validation is one where the data is correctly structured but violates a business rule — for example, a batch analysis result that references a test not included in the current approved specification.
The reason that pharmaceutical companies underestimate FHIR implementation complexity is that they interpret “FHIR compliance” as a property of individual resources rather than a property of the resource graph. A single SubstanceDefinition resource can be profile-compliant in isolation — all mandatory elements present, correct terminologies used — and yet produce a KASA validation failure when it is referenced by an Ingredient resource that carries incorrect reference syntax, or when it is absent from the bundle entirely and the Ingredient reference resolves to nothing. Graph completeness is a property that cannot be verified by examining individual resources. It must be assessed at the bundle level, with all references validated against the full resource graph.
The FDA Federal Register notices on structured CMC submissions make clear that the intent of PQ-CMC is not simply to produce machine-readable versions of existing documents. The intent is to enable a fundamentally different mode of regulatory review — one in which the KASA system can query structured data across submissions, identify patterns in pharmaceutical development, flag outliers in specification setting, and support more informed and efficient regulatory assessment. That capability depends entirely on the structural completeness of the resource graph. It depends on every Ingredient correctly referencing its SubstanceDefinition. It depends on every Observation correctly referencing its specification ActivityDefinition. It depends on every resource in the graph being connected.
ISO 11616:2017 provides the internationally standardized terminology for pharmaceutical product identification that underpins many of the coded elements required in MedicinalProductDefinition and related resources. CMC practitioners implementing PQ-CMC structured data systems should be aware of both the ISO 11616 and ISO/IEC 21090 standards as foundational references for the data type and terminology requirements that the FHIR profiles formalize.
The practical implication for CMC organizations is direct. FHIR implementation is not a task for the regulatory affairs team working alone in document preparation mode. It is a cross-functional data architecture exercise that requires CMC scientists who understand what the data means, data engineers who understand how FHIR resources are constructed and validated, and regulatory professionals who understand the submission requirements and FDA expectations. The architecture must be designed before any resource is populated. And the architecture must be validated as a graph — not resource by resource — before any submission is filed.
THE XGENE FHIR FOR CMC ARCHITECTURE AND IMPLEMENTATION GUIDE
The XGene FHIR for CMC Architecture and Implementation Guide translates the HL7 FHIR standard into practical implementation guidance for CMC scientists and regulatory teams.
Module 1 — CMC-Science-First FHIR Architecture Walkthrough: A resource-by-resource explanation of the PQ-CMC FHIR graph in pharmaceutical terms — what SubstanceDefinition represents scientifically, what Ingredient means for formulation data, what PlanDefinition represents as a specification structure, and what Observation means for batch analysis data. Designed for CMC scientists, not information technology professionals.
Module 2 — Data Model Design for Drug Substance and Drug Product: Structured data model templates for 3.2.S and 3.2.P resource graphs. Defines every resource required, every reference linkage, and every mandatory coded element for both drug substance and drug product PQ-CMC submissions.
Module 3 — FHIR Profile Compliance Mapping: Element-by-element mapping of PQ-CMC IG profile requirements to CMC data source fields. Identifies mandatory elements, required terminologies, and data type requirements for each resource type in the submission.
Module 4 — CMC Data System Vendor Evaluation Criteria for FHIR Output Capability: Evaluation framework for assessing whether a laboratory information management system, quality management system, or document management system can produce FHIR-conformant output. Key criteria: native FHIR R5 (5.0.0) resource support rather than legacy R4-only output; structured field output for test results (result value, units, test code, acceptance criterion operator as discrete fields); UNII code maintenance; FHIR Bundle generation capability; profile validation integration.
Module 5 — Implementation Validation Protocol Using HL7 and FDA Validators: Step-by-step protocol for validating FHIR Bundle submissions using the HL7 FHIR validator and FDA schematron rules. Includes pre-submission validation checklist and error resolution guide for common PQ-CMC profile conformance failures.
Module 6 — FHIR Resource Library of Pre-Built Templates for Common CMC Data Patterns: Library of validated FHIR resource templates for common CMC data patterns — drug substance specification entries, excipient ingredient resources, batch analysis observation structures, container closure representations. Templates are pre-validated against current PQ-CMC IG profiles.