FHIR Clinical Data Integration: Conditions, Medications, and Diagnostic Reports
A useful clinical picture isn't any single FHIR resource - it's Condition, MedicationRequest, AllergyIntolerance, and DiagnosticReport assembled together, each with its own completeness quirks, into something a person or an AI system can actually use.
The core clinical resources and what each represents
Condition covers diagnoses and problems, each ideally coded (SNOMED CT or ICD-10-CM) with a clinical status (active, resolved, inactive) that matters as much as the diagnosis itself. MedicationRequest covers prescribed medications, including dosage instructions that are often only reliably available as structured data for e-prescribed medications, with older or manually entered prescriptions more likely to carry incomplete structured dosage data. AllergyIntolerance covers allergies and intolerances, safety-critical and worth treating with extra defensive parsing given the consequences of missing or misreading one. DiagnosticReport ties together a set of related Observations (like a full lab panel or an imaging study) with an overall narrative conclusion.
Clinical status fields matter as much as the data itself
A resolved Condition and an active one look structurally similar but mean very different things clinically - integration code that doesn't explicitly check and surface clinicalStatus risks presenting a patient's medical history inaccurately. The same applies to MedicationRequest's status (active, stopped, completed) - a discontinued medication appearing in an active medication list is a genuinely dangerous integration bug, not a cosmetic one.
Assembling resources into a usable clinical picture
These resources are designed to be combined, not read in isolation - a DiagnosticReport typically references the Observations it summarizes, and a full clinical picture for a patient usually means fetching and correlating Condition, MedicationRequest, AllergyIntolerance, and relevant DiagnosticReport/Observation data together, filtered to active/current status where that's what's clinically relevant. This assembly work is exactly the kind of task well suited to a retrieval-augmented (RAG) approach when the end goal is a synthesized summary - see our companion piece on using RAG for clinical documents.
Defensive parsing is non-negotiable for clinical resources
Given the safety stakes, clinical resource parsing should always explicitly check resourceType (rather than assuming a Bundle entry is what you searched for), handle missing or incompletely coded fields gracefully rather than failing silently or guessing, and log enough detail to reconstruct exactly what was received from the source system if a downstream issue is ever traced back to a specific integration. This is a place where the general defensive-integration patterns we apply everywhere matter even more than usual.
FAQ