PQ-CMC Stability Structured Format — What FDA’s Parser Actually Reads
Stability data is the most data-rich component of any CMC submission — and the PQ-CMC structured format for stability data is designed to make that data machine-readable, cross-referenceable, and comparable…
On this pageArticle overview
PQ-CMC Stability Structured Format — What FDA’s Parser Actually Reads
Stability data is the most data-rich component of any CMC submission — and the PQ-CMC structured format for stability data is designed to make that data machine-readable, cross-referenceable, and comparable across submissions in ways that narrative stability tables and PDF reports have never enabled.
That statement deserves a precise unpacking, because it carries implementation consequences that are not obvious from the surface-level description of PQ-CMC as a “structured data initiative.” Most pharmaceutical professionals who have reviewed a stability section of a 3.2.P.8 or 3.2.S.7 submission understand stability data as tables: rows of time points, columns of tests, cells containing numeric results with pass/fail designations, a summary table of shelf-life statistics at the end. That tabular structure is intuitive for human readers and has served CMC review well for decades. The problem is not that the tables are unclear. The problem is that a table embedded in a PDF or a Word document — regardless of how well it is formatted — is a visual artifact, not a data structure. A reviewer can read it. An algorithm cannot query it. A stability trending system at FDA cannot extract the individual results, link each result to a specific batch and a specific storage condition, compare results across products and manufacturers, or compute shelf-life statistics from primary data without a human first converting the visual table back into discrete data fields. The PQ-CMC stability structured format eliminates that reconversion requirement by requiring that every individual stability result be submitted as a discrete, coded, machine-readable FHIR resource from the beginning.
Understanding what this requires in practice — and why legacy stability management systems and LIMS that generate stability reports are architecturally incapable of meeting this requirement — demands a careful examination of the FHIR resource architecture that the HL7 PQ-CMC Implementation Guide prescribes for stability data, and an equally careful examination of what ICH Q1A(R2), Q1B, Q1D, Q5C, and the associated FDA stability guidance actually require in terms of study design, storage condition characterization, and statistical analysis. The structured data implementation does not exist in a vacuum. Every element of the FHIR architecture for stability data is anchored to a specific ICH or FDA requirement — and understanding that anchoring is what separates a principled PQ-CMC stability implementation from a mechanical FHIR mapping exercise.
Why Stability Data Is the Most Technically Challenging PQ-CMC Implementation Challenge
The technical challenge of PQ-CMC stability structured data implementation begins with the sheer volume of individual data points that a compliant stability program generates. A single primary stability study for a small molecule drug product conducted under ICH Q1A(R2) protocol — long-term 25°C/60%RH and accelerated 40°C/75%RH conditions, with a five-year shelf-life support objective — will generate results at time points T0, T1M, T3M, T6M, T9M, T12M, T18M, T24M, T36M, T48M, and T60M. At each time point, the standard specification test battery for a solid oral dosage form might include appearance, assay, related substances (individual impurities and total), dissolution, water content, and hardness — a minimum of six to eight test categories, several of which involve multiple individual reportable results. Across two storage conditions and a minimum of three registration batches, this program generates several hundred individual result values before any intermediate or stressed conditions are added. For a drug substance program under ICH Q1A(R2) with the same scope, the numbers are comparable. For a biological product program under ICH Q5C, where multiple container types, multiple fill volumes, and freeze-thaw cycling studies may be required, the individual result count reaches into the thousands.
In a conventional PDF-based CTD submission, all of those results are compressed into formatted tables — organized by batch, by time point, or by test depending on the company’s format preference — and the summary statistics, shelf-life extrapolation, and ICH Q1E statistical analysis are presented in a narrative section with supporting tables. That compression is appropriate for human reading. For the PQ-CMC structured format, that compression must be reversed. Every individual result — every single numeric value for every single test at every single time point for every single storage condition for every single batch — must be represented as a discrete FHIR Observation resource with a complete set of coded attributes. This is not a reformatting exercise. It is a data architecture change that requires either a stability management system or LIMS capable of exporting individual results at the required granularity, or a data transformation layer that can take whatever output the stability system produces and decompose it into the required Observation resource structure.
The architectural requirement for discrete Observation resources — one resource per result per test per time point per storage condition per batch — is the single requirement that most clearly differentiates PQ-CMC stability structured data from any prior submission format. It is the requirement that most legacy stability management systems cannot meet with their current report-generation architecture. And it is the requirement that KASA — FDA’s Knowledge-Aided Assessment and Structured Application system — depends on to perform cross-submission stability trending, comparative shelf-life analysis, and automated consistency review. The FDA parser does not read a stability table. It reads Observation resources. If the Observation resources are not there — or if they are present but incorrectly structured, missing coded attributes, or disconnected from their study protocol context — the structured data submission fails to deliver the analytical value it is designed to provide.
The study design context for each Observation is encoded in a stability study PlanDefinition resource. This is the FHIR representation of the stability protocol — the document that specifies which batches will be tested, under which storage conditions, at which time points, against which specification. Under ICH Q1A(R2), the PlanDefinition for a long-term study must encode the storage condition as a coded element: 25°C/60%RH for long-term, 40°C/75%RH for accelerated, 30°C/65%RH for intermediate, using the PQ-CMC coded vocabulary aligned with ICH Q1A(R2) storage condition designations. These are not free-text descriptions. They are coded identifiers from the PQ-CMC controlled vocabulary that allow KASA to recognize the storage condition type programmatically and apply the appropriate ICH guideline framework for that condition type. A storage condition described as “room temperature” or “controlled room temperature” in a narrative protocol cannot be processed by the stability data parser. It must be expressed as the specific coded ICH Q1A(R2) condition type with the associated temperature and relative humidity values as structured numeric fields with units.
Time points in the PlanDefinition are similarly coded. The PQ-CMC controlled vocabulary for stability time points includes coded terms for each of the standard ICH Q1A(R2) intervals: T0, T1M, T3M, T6M, T9M, T12M, T18M, T24M, T36M, T48M, T60M — expressed as numeric values with a coded time unit. The time point coding serves a specific function: it allows KASA to correctly sequence Observations in time without parsing free-text time descriptions, and it allows the ICH Q1E statistical analysis engine to identify the time point values for shelf-life regression analysis without manual data entry. Each batch enrolled in the stability study is referenced in the PlanDefinition through a link to its ManufacturedItemDefinition resource — the same resource that carries batch identification, batch size, and manufacturing site information from other sections of the PQ-CMC submission. That cross-reference is what enables KASA to correlate stability results with specific manufacturing batches, specific manufacturing sites, and specific process parameters encoded elsewhere in the structured submission.
The stability specification against which each result is evaluated is encoded as a separate PlanDefinition resource — a specification PlanDefinition structurally parallel to the release specification PlanDefinition in 3.2.P.5 or 3.2.S.4 — and it is linked from the stability study PlanDefinition to establish the study-specification relationship in machine-readable form. This linkage is architecturally significant. It allows KASA to identify the acceptance criterion applicable to each Observation result without requiring a reviewer to manually locate the relevant specification document. The pass/fail designation for each Observation is not a calculated value that KASA derives; it is a structured data element that the submitter must encode explicitly, referencing the linked specification PlanDefinition as the basis for the determination.
The FHIR Observation Architecture for Stability: One Resource Per Result
The FHIR Observation resource for a stability result carries a defined set of mandatory structured attributes, each of which serves a specific function in the KASA processing architecture. Understanding each attribute — what it encodes, where the coded value comes from, and what breaks if it is absent or incorrectly coded — is prerequisite knowledge for any organization undertaking PQ-CMC stability structured data implementation.
The test name is coded from the PQ-CMC controlled vocabulary for pharmaceutical quality tests — the same vocabulary used for release specification test coding in the specification PlanDefinition and for IPC test coding in the manufacturing process ObservationDefinitions. For stability, the test vocabulary must cover not only standard release tests but also stability-specific tests that may not appear in the release specification: appearance at elevated stress conditions, crystallinity for amorphous drug products, subvisible particle counts for parenterals, reconstitution time for lyophilized products. Organizations whose stability testing battery extends beyond the release specification tests must verify that each stability-specific test name maps to a PQ-CMC coded vocabulary term before the Observation resources are built. Unmapped test names cannot be correctly coded and will fail schematron validation.
The result value for each Observation is encoded as a numeric quantity with a UCUM unit — the Unified Code for Units of Measure system used throughout the PQ-CMC FHIR implementation. A result of 98.7% assay is encoded as the numeric value 98.7 with the UCUM unit “%” or the appropriate percent-based unit code. A dissolution result of 84% in 30 minutes is encoded as the numeric value 84 with unit “%” and the time parameter as a separate coded observation component. An impurity result of 0.12% is encoded as the numeric value 0.12 with appropriate UCUM percentage units. Results reported as “not detected” or “below the limit of detection” require specific structured encoding that the PQ-CMC IG addresses through defined coded qualifiers — they cannot be encoded as blank fields or free-text annotations. The completeness of numeric encoding is not a formatting requirement. It is the precondition for any computational analysis of the stability dataset.
The storage condition for each Observation is encoded as a coded element linked to the storage condition specified in the stability study PlanDefinition. Each Observation carries an explicit reference to the storage condition under which the tested sample was held — expressed using the same ICH Q1A(R2) coded condition vocabulary as the PlanDefinition. This explicit per-Observation storage condition coding — rather than implicit inheritance from the study protocol — is what enables KASA to correctly segregate results by storage condition when computing condition-specific trending and when applying the ICH Q1E statistical model for shelf-life determination. An Observation that does not carry an explicit coded storage condition reference is ambiguous in the KASA processing model, even if its parent PlanDefinition encodes the storage condition correctly.
The time point for each Observation is encoded as a coded reference to the applicable time point in the stability study PlanDefinition, along with the actual test date as a structured date field. The coded time point serves the algorithmic sequencing function described above. The actual test date is a separate structured field that carries the calendar date of testing — relevant for calculating actual elapsed time, assessing compliance with the ICH Q1A(R2) testing schedule tolerances, and supporting any investigation of out-of-trend results where the timing of testing relative to the nominal time point may be relevant. The PQ-CMC IG requires both — the coded nominal time point and the actual date — because they serve different analytical functions.
The batch identifier for each Observation is encoded as a structured reference to the batch record, linking the individual result to the ManufacturedItemDefinition batch resource that carries the batch number, manufacturing date, manufacturing site, and batch size. This reference is what makes individual Observations traceable to their batch provenance in the KASA structured data model. It is also what enables cross-section consistency checking: the batch numbers referenced in stability Observations should be consistent with the batches described in the batch analysis section, and KASA can verify that consistency programmatically because the batch reference is a structured coded link, not a free-text batch number that must be matched by string comparison.
OOT Flagging, Statistical Analysis, and Shelf-Life Claim Representation in Structured Format
The PQ-CMC structured format for stability data extends beyond individual result Observations to encompass the analytical outputs that FDA stability reviewers use to assess stability program adequacy and support shelf-life determination: out-of-trend (OOT) designations, ICH Q1E statistical analysis outputs, and the shelf-life claim itself. Each of these analytical elements is represented in structured FHIR format, not as narrative text or embedded tables.
Out-of-trend designation is represented as a structured attribute on the Observation resource flagged as OOT. The PQ-CMC IG provides a coded OOT status element that can be set on any Observation that has been identified as an out-of-trend result through the stability trending analysis process. The OOT flag is not a free-text annotation; it is a coded binary element that the KASA stability processing engine can use to identify flagged results without narrative parsing. Critically, an OOT-flagged Observation must also carry a structured reference to the investigation or assessment associated with the OOT result — a reference to the associated investigation record that documents the trending analysis, root cause assessment, and disposition decision for the flagged result. This investigation linkage is the structured-format equivalent of the OOT footnote that appears in a narrative stability table, but in machine-readable form that preserves the relationship between the flagged result and its evaluation context.
The statistical analysis required by ICH Q1E — the linear regression of stability results over time, the 95% confidence interval for the regression slope, and the intersection of the lower confidence limit with the specification acceptance criterion — is represented in the PQ-CMC structured format through derived Observation resources. Derived Observations are FHIR Observations that represent calculated statistical quantities rather than direct measurements. For ICH Q1E shelf-life analysis, the derived Observations include the regression slope for each degradation pathway, the intercept value, the 95% confidence interval bounds for the slope, and the estimated shelf-life value calculated from the intersection of the confidence limit with the acceptance criterion. Each of these statistical quantities is a discrete numeric value with UCUM units, encoded as a structured derived Observation linked to the primary stability Observations from which it was calculated.
This statistical derivation structure is significant because it means the statistical analysis is not a document embedded in the submission — it is a set of structured data resources that KASA can verify against the primary result Observations. The parser can recalculate the regression from the primary Observation data and compare the result to the derived Observations in the submission. If the derived statistical quantities are inconsistent with the primary result data, that inconsistency is detectable programmatically. This represents a fundamentally different level of statistical verification than is possible with narrative stability summaries, where a reviewer must manually re-perform the calculation to detect errors.
For ICH Q1D reduced stability designs — matrix and bracketing designs used to reduce the number of stability samples without compromising the statistical integrity of the shelf-life determination — the PQ-CMC structured format must accurately represent the reduced design in the stability study PlanDefinition. The planned testing schedule under a matrix or bracketing design is not a full-factorial schedule, and the PlanDefinition must encode which batches, time points, and storage conditions are included in the reduced design — distinguishing planned non-testing intervals from missing data. KASA needs that design information to correctly interpret the Observation set: a time point that is absent because it was not scheduled under a matrix design is not equivalent to a missing result at a scheduled time point, and the structured PlanDefinition encoding of the reduced design is what makes that distinction machine-readable.
The shelf-life claim itself — the authorized shelf-life that the submission proposes for the product, based on the stability data and ICH Q1E statistical analysis — is represented as a RegulatedAuthorization resource linked to the stability study PlanDefinition. The RegulatedAuthorization resource for the shelf-life claim carries the shelf-life value as a structured numeric field expressed in months, the storage condition under which the shelf-life applies as a coded element, the container type and closure system as structured references to the container closure system resources elsewhere in the PQ-CMC submission, and a reference to the stability study PlanDefinition that provides the evidentiary basis for the claim. This linkage structure means that the shelf-life claim in the structured submission is not a standalone assertion. It is a claim with an explicit, machine-readable reference to the supporting data — a reference that KASA can traverse to verify that the claimed shelf-life is supported by the stability Observations in the submission.
The complete stability FHIR resource graph — stability study PlanDefinition with coded storage conditions and time points, ManufacturedItemDefinition batch references, specification PlanDefinition linkage, individual result Observations with coded test names and UCUM units, OOT-flagged Observations with investigation references, derived statistical Observations encoding ICH Q1E analysis outputs, and RegulatedAuthorization shelf-life claim with container and storage condition coding — represents the full scope of what the PQ-CMC parser reads when it processes a stability data submission. Stability management systems that generate PDF tables are generating a visual artifact of this data structure. They are not generating the data structure itself.
For your primary drug product stability program, verify that your stability management software or LIMS can export individual stability test results — one result per test per time point per storage condition per batch — as discrete machine-readable data fields with coded storage condition, coded test name, numeric result, and units; if it can only export a stability table as a PDF, your system is not PQ-CMC-ready.
THE XGENE PQ-CMC STABILITY STRUCTURED DATA IMPLEMENTATION PROGRAM
The XGene PQ-CMC Stability Structured Data Implementation Program is the practitioner framework for converting existing stability programs — with their associated protocols, study data, statistical analyses, and shelf-life claims — into fully compliant PQ-CMC FHIR resource graphs ready for eCTD structured submission.
Step 1 — Stability Study Protocol Review and Storage Condition Coding: For each active stability study in the program, map the storage condition to the PQ-CMC coded vocabulary aligned with ICH Q1A(R2) condition designations: long-term 25°C/60%RH, accelerated 40°C/75%RH, intermediate 30°C/65%RH, and any stress or photostability conditions under ICH Q1B. Confirm that each storage condition is expressible as a coded ICH Q1A(R2) condition type with structured temperature and relative humidity numeric values and units. Document any storage conditions used in existing protocols that do not map directly to ICH Q1A(R2) coded condition types and determine the appropriate coded representation.
Step 2 — Time Point Inventory and Coded Vocabulary Mapping: List all nominal time points in each stability study protocol. Map each time point against the PQ-CMC coded time point vocabulary: T0, T1M, T3M, T6M, T9M, T12M, T18M, T24M, T36M, T48M, T60M. Confirm that the coded time point vocabulary covers all time points in the stability program. For ICH Q5C biological product programs with non-standard time points, identify any time points requiring coded vocabulary extension.
Step 3 — Stability Test Battery PQ-CMC Vocabulary Mapping: List every test in the stability test battery, including stability-specific tests not present in the release specification. Map each test name against the PQ-CMC controlled vocabulary for pharmaceutical quality tests. Identify stability-specific tests with no direct vocabulary match and determine the appropriate coded representation. This mapping exercise is prerequisite to Observation resource construction and must be completed before any FHIR resource building begins.
Step 4 — Stability Management System Data Export Assessment: Evaluate the current stability management software or LIMS for the ability to export individual stability results — one result per test per time point per storage condition per batch — as discrete machine-readable data fields with coded test name, numeric result value, and UCUM units. If the system can only generate formatted stability reports or PDF tables, design the data extraction and transformation architecture needed to produce individual result records from the available system output. This assessment determines the technical scope of the LIMS-to-FHIR implementation pathway.
Step 5 — Stability Study PlanDefinition Construction: Build the stability study PlanDefinition for each registered or ongoing stability study. Populate coded storage conditions, coded time point schedules, batch references to ManufacturedItemDefinition resources, and linkage to the stability specification PlanDefinition. For ICH Q1D matrix and bracketing designs, encode the reduced testing schedule explicitly in the PlanDefinition to distinguish planned non-testing intervals from missing data.
Step 6 — Individual Result Observation Resource Construction: For each individual stability result — one Observation per test per time point per storage condition per batch — construct a FHIR Observation resource carrying coded test name from PQ-CMC vocabulary, numeric result value with UCUM units, coded storage condition reference to the study PlanDefinition, coded time point reference, actual test date, batch identifier reference to ManufacturedItemDefinition, pass/fail status coded against the linked specification PlanDefinition, and OOT flag with investigation reference for any OOT-designated results.
Step 7 — ICH Q1E Statistical Analysis Structured Output: For each degradation pathway subject to ICH Q1E statistical analysis, construct derived Observation resources encoding the regression slope, intercept, 95% confidence interval bounds, and estimated shelf-life value as discrete numeric fields with UCUM units. Link each derived Observation to the primary Observations from which it was calculated. Verify that the derived statistical quantities are consistent with the primary result data and with the shelf-life claim encoded in the RegulatedAuthorization resource.
Step 8 — Shelf-Life Claim RegulatedAuthorization Resource Construction: Build the RegulatedAuthorization resource for the shelf-life claim carrying the claim value in months as a structured numeric field, the storage condition as a coded element, the container type and closure system as structured references, and a reference to the supporting stability study PlanDefinition. Confirm that the claimed shelf-life is supported by the ICH Q1E statistical analysis encoded in the derived Observations and that the storage condition coding on the claim matches the long-term study condition.
Step 9 — Pre-Submission Validation Against PQ-CMC Stability Profile Validators: Run the complete stability resource graph — PlanDefinitions, Observations, derived Observations, and RegulatedAuthorization — through the HL7 FHIR validator against the PQ-CMC Implementation Guide stability profiles. Execute FDA schematron validation. Verify coded storage conditions, coded time points, coded test names, UCUM units, and cross-resource linkages. Resolve all errors and warnings. Document the validation pass as a submission quality record before eCTD filing.