FAIR Data Applied to Pharmaceutical CMC — The Practical Implementation

Every pharmaceutical company that has committed to FAIR data principles has a beautiful diagram showing how their CMC data will be Findable, Accessible, Interoperable, and Reusable — and most of them discover during implementation that the gap between the principle and the practice is where the entire CMC data transformation challenge actually lives.

The FAIR Guiding Principles, articulated by Wilkinson et al. in Nature Scientific Data in 2016, were not written for pharmaceutical manufacturing. They were written for scientific research data sharing at the institutional and cross-institutional level. The pharmaceutical industry adopted them as a framework for CMC data governance, and in doing so inherited a set of abstract criteria — persistent identifiers, rich metadata, formal shared vocabularies, FAIR-enabling APIs — that require concrete, domain-specific engineering decisions before a single batch record becomes genuinely interoperable. Companies that treat FAIR as a data architecture exercise, rather than a CMC data model redesign, will produce systems that are findable within the enterprise but still incapable of the regulatory interoperability that FDA’s PQ-CMC structured data initiative is building toward.

The regulatory consequence is not theoretical, even though PQ-CMC is not yet a mandatory submission requirement. FDA’s PQ-CMC FHIR Implementation Guide — still progressing through HL7 Standard for Trial Use (STU) development rather than serving as a required submission format today — operationalizes a specific structured data model for CMC submission content, and an organization whose internal CMC data does not conform to that model will face manual data transformation at every submission event once structured PQ-CMC submission becomes standard practice. That transformation cost will accumulate across every NDA, ANDA, BLA, and post-approval supplement the organization files, compounding the original implementation failure into a recurring compliance burden.

The Gap Between FAIR Principles and CMC Data Reality: What Most Organizations Start With

The GO FAIR initiative’s FAIR Maturity Indicators (available at go-fair.org) provide a structured evaluation framework with measurable criteria for each of the four FAIR principles. Most pharmaceutical organizations, when assessed honestly against those indicators, sit at FAIR maturity Level 1 or Level 2 — data that is findable within the organization using internal search tools, and accessible to authorized users through standard enterprise authentication. Level 1 and Level 2 FAIR are necessary conditions for internal data management but are insufficient for regulatory interoperability. PQ-CMC-ready structured submission requires Level 3 and Level 4 — data that is interoperable with external regulatory systems via FHIR-structured exchange protocols, and reusable across submission contexts without re-entry or manual transformation.

The gap between Level 2 and Level 3 is not primarily an infrastructure gap. It is a data model gap. Companies that deploy a cloud data lake, implement an enterprise metadata layer, and declare their FAIR implementation complete have addressed the infrastructure dimension while leaving the data model untouched. A stability result stored in a LIMS as a free-text string in a proprietary schema — with a test name in whatever vocabulary the LIMS vendor chose, a unit expressed as “%” without formal UCUM coding, and a storage condition described as “40C/75%RH” rather than the ICH Q1A coded format — is findable inside the enterprise but is not interoperable with any external regulatory system. The architecture diagram is accurate; the underlying data objects simply have not been redesigned to meet the FAIR standard.

ICH Q10, the Pharmaceutical Quality System guideline, establishes data management as a core quality system element, and its expectations for data integrity, traceability, and lifecycle management create the GMP-facing rationale for FAIR implementation. But ICH Q10 does not prescribe FAIR data standards specifically — it establishes the quality system framework within which a FAIR CMC data program must operate. ISPE GAMP 5 adds the data governance layer for GxP computerized systems, requiring that validated systems maintain data integrity throughout the data lifecycle. Neither framework tells an organization exactly how to assign persistent identifiers to a reference standard certificate or how to map stability test names to PQ-CMC coded terminology. That translation is where the implementation work actually lives.

The Three CMC Data Domains Where FAIR Implementation Delivers the Highest Regulatory Value

The highest regulatory return on FAIR implementation investment concentrates in three CMC data domains: stability data, release testing data, and drug substance/drug product specifications. These three domains are the primary data sources for the CMC sections of an NDA or BLA — Module 3.2.P.5 for release testing and acceptance criteria, Module 3.2.P.8 for stability — and they are the data objects that FDA reviewers interrogate most directly during application review and pre-approval inspection. A FAIR-compliant stability dataset means that when an FDA reviewer queries a submitted PQ-CMC FHIR resource for all stability results associated with a specific batch under a specific storage condition, the system can return a complete, structured response without manual intervention from the sponsor’s data team.

For stability data specifically, the metadata schema required for genuine FAIR compliance is non-trivial. Each stability result must carry: a batch identifier in a structured, persistent format (not a folder path); a storage condition coded to ICH Q1A vocabulary; a time point expressed in coded units; a test name mapped to PQ-CMC coded terminology; an analyst identifier; an instrument identifier with current calibration status; a result value with UCUM-coded units; the applicable acceptance criterion; a pass/fail determination; and a creation date with provenance tagging identifying the method version used. That is not a metadata wish list — it is the minimum metadata schema that makes a stability result genuinely reusable for regulatory submission without manual data reconstruction at submission time.

The Pistoia Alliance has published pharmaceutical-specific FAIR implementation resources (available at pistoiaalliance.org) that address the organizational and technical barriers to FAIR adoption in drug development contexts. Their work identifies controlled vocabulary alignment as the single most underestimated implementation challenge — not because the vocabularies do not exist, but because aligning legacy CMC data to formal controlled vocabularies (PQ-CMC coded terminology for test names, UCUM for units, EDQM Standard Terms for dose forms, UNII for substance identification) requires a systematic audit of every existing data object and a remediation program for any data that does not conform. Organizations that perform vocabulary alignment only for new data systems, leaving legacy data in non-FAIR format, create a split-system data management burden that grows more expensive to resolve with every passing submission cycle.

Metadata Standards, Persistent Identifiers, and the Technical Requirements for CMC FAIR Data

Persistent identifier assignment is the most concrete technical requirement of a FAIR CMC program, and it is the step most organizations skip or implement incompletely. A persistent identifier is not a filename, a folder path, or a LIMS record number that exists only within the enterprise. For CMC data objects, persistent identifiers have specific forms: drug substances are identified by UNII (Unique Ingredient Identifier), the FDA-maintained registry that provides a globally unique, persistent identifier for every approved and investigational substance. Batch numbers, when expressed in a structured, documented format consistently applied across the organization, function as persistent identifiers for manufactured batches — but only if the format is defined, documented, and maintained with sufficient specificity to distinguish batches across manufacturing sites, process generations, and time. Method identifiers and specification version identifiers require equivalent discipline: each analytical method must have a unique, versioned identifier that travels with every data record generated using that method, enabling a reviewer to trace any result back to the exact method version in use at the time.

The API layer is the FAIR implementation component most often treated as optional or deferred. A REST API that enables programmatic retrieval of CMC data objects by structured identifier — returning a stability result set for a specified batch and storage condition as a structured FHIR resource, rather than requiring a human to log into a LIMS and export a spreadsheet — is the technical mechanism that converts findable, accessible CMC data into genuinely interoperable data. An API layer built as read-only export, where data is still entered through front-end forms and batch-exported through a reporting interface, creates a synchronization risk: the export is a point-in-time snapshot, not a live representation of the data record. When that export is the basis for a regulatory submission, any subsequent data correction in the source system requires a new export and a new manual reconciliation step, which is precisely the kind of uncontrolled manual intervention that creates data integrity risk under GAMP 5 data governance requirements.

Provenance tagging — ensuring that each data record carries metadata identifying the creator, the creation method, the method version, and the instrument with its calibration status at the time of measurement — addresses the reusability dimension of FAIR directly. A stability result without provenance metadata is findable and accessible, but it cannot be verified as fit for regulatory reuse without manual investigation of paper records or LIMS audit trails. At scale, across a development portfolio with multiple products, multiple manufacturing sites, and years of accumulated stability data, the absence of systematic provenance tagging means that every regulatory submission requires a manual data integrity verification exercise that a properly implemented FAIR program would have made unnecessary.

The CMC FAIR Data Implementation Roadmap: Practical Steps From Principles to Infrastructure

The XGene FAIR CMC Data Transformation Program provides a structured, phased implementation pathway that moves a pharmaceutical organization from FAIR maturity Level 1–2 to Level 3–4, anchored to PQ-CMC structured submission requirements as the primary FAIR implementation driver.

Step 1 — CMC Data Inventory and FAIR Maturity Baseline Assessment: Identify every CMC data object type in the organization’s portfolio — specifications, batch records, stability results, validation reports, reference standard certificates — document their current storage locations and data formats, and score each against the GO FAIR Maturity Indicators to establish a documented baseline that defines the gap to PQ-CMC compliance.

Step 2 — Identifier Assignment and Controlled Vocabulary Alignment: Assign persistent, unique identifiers to every CMC data object class (substance UNII, structured batch number format, method identifier, specification version identifier), and audit all CMC terminology against formal controlled vocabularies — test names to PQ-CMC coded terminology, units to UCUM, storage conditions to ICH Q1A codes, dose forms to EDQM Standard Terms — producing a vocabulary gap register and a remediation schedule for legacy data.

Step 3 — Metadata Schema Design and Provenance Tagging Protocol: Define the complete metadata schema for each CMC data type, using the stability result schema as the primary template (batch ID, storage condition in ICH Q1A code, time point in coded units, test name in PQ-CMC vocabulary, analyst ID, instrument ID with calibration status, result value in UCUM units, acceptance criterion, pass/fail, date), and implement provenance tagging requirements for all new data entry workflows and for historical data remediation.

Step 4 — API Layer Implementation and Data Catalog Deployment: Build REST API endpoints for each primary CMC data system enabling programmatic data retrieval by structured identifier and returning responses as FHIR-structured resources, and deploy a searchable CMC data catalog that functions as the operational index for automated PQ-CMC submission generation — enabling the organization to retrieve all submission-relevant data for a product without manual file search or data re-entry.

The output of the XGene FAIR CMC Data Transformation Program is a FAIR-compliant CMC data infrastructure with a documented maturity progression roadmap, quarterly FAIR maturity assessment milestones, and a PQ-CMC submission generation capability that requires no manual data transformation at submission time — not a gap list, but an operating system for CMC regulatory data.

Organizations that defer FAIR CMC implementation until the PQ-CMC submission mandate forces the issue will face a compressed remediation timeline under regulatory pressure — the worst possible conditions for a data model redesign that should take quarters, not weeks. The cost of that compression is not just the engineering cost of an accelerated implementation; it is the submission quality cost of a structured data package built on a data foundation that has not been validated for FAIR compliance, and the inspection readiness cost of an organization that cannot answer a data traceability question during a pre-approval inspection without a manual audit trail review. FAIR CMC data infrastructure is, at its core, a risk management investment — and the organizations that treat it as such, rather than as an IT modernization project, are the ones that arrive at PQ-CMC submission readiness with margin to spare.

Conduct a FAIR maturity spot-check on your drug product release testing data: can you locate all release results for a specific batch using a structured identifier (not a folder path or manual search), can you access those results through an API rather than manual file export, are the test names expressed in controlled coded vocabulary, and does each result carry provenance metadata identifying the analyst, instrument, and method version?