HL7 FHIR has become the dominant standard for health data exchange APIs, and for good reason: it provides a practical, REST-based mechanism for exchanging clinical data between systems using standardised resource types — Patient, Observation, Condition, MedicationRequest, and dozens of others. Regulators in multiple jurisdictions are mandating FHIR-based APIs for health data access. For pharmaceutical organisations, FHIR creates an unprecedented opportunity to access structured real-world clinical data at scale. But FHIR alone does not make that data semantically comparable across sources.
Where FHIR Stops and Ontologies Begin
A FHIR Observation resource has a defined structure: it contains a code identifying what was observed, a value representing the observation result, and a reference to the patient. The code is typically drawn from a coding system — LOINC for laboratory observations, SNOMED CT for clinical findings. But FHIR does not define the semantic relationships between those codes: it does not know that LOINC code 2160-0 (creatinine in serum) is a measure of renal function, or that an elevated creatinine value is a potential adverse drug reaction indicator for nephrotoxic compounds. That relational context is provided by the ontologies that govern the coding systems bound to FHIR elements — and making it available for pharmaceutical analytics requires a semantic layer that interprets FHIR data in terms of those ontologies.
Ontological FHIR Profiles for Pharmaceutical Use Cases
The most effective approach for pharmaceutical real-world evidence applications is to define FHIR profiles — constrained resource specifications that require specific coding system bindings and specific terminology value sets — for each type of clinical data element that the programme needs to collect. A FHIR profile for an adverse event Condition resource might require SNOMED CT coding at a specific ontological depth, with a mandatory severity coding using a defined value set. When participating data sources conform to these profiles, the resulting data arrives pre-aligned with the pharmaceutical ontological reference model, requiring minimal transformation before entry into the knowledge graph.
Challenges in Practice
Real-world FHIR implementations frequently deviate from the profiles that pharmaceutical organisations need. Coding quality varies widely — the same clinical event may be coded at the disorder level in one system and at the finding level in another. Null flavours are used inconsistently. Local extensions that do not translate to standard ontologies appear in fields that were intended to carry standardised codes. Building robust FHIR ingestion pipelines for pharmaceutical knowledge graphs requires explicit handling of these deviations, including automated code normalisation against the target ontology and flagging of observations that cannot be reliably interpreted.
