A single patient's information may be spread across a clinic's record system, a laboratory system, a pharmacy application and a national immunization registry. When these systems cannot exchange data, clinicians work with an incomplete picture and health programs struggle to measure what is happening.
HL7 FHIR (Fast Healthcare Interoperability Resources) has become the leading standard for addressing this problem. It defines a common way to represent health information and a modern web API for exchanging it.
Resources: the building blocks
FHIR models health information as resources: small, structured units such as Patient, Encounter, Observation, Immunization and Medication. Each resource has a defined set of elements and can reference other resources. An Immunization resource, for example, references the Patient who received it and the location where it was given.
Because resources are exchanged as JSON or XML over standard HTTP APIs, developers can work with them using the same tools they use for any modern web service.
Profiles adapt FHIR to local needs
The base standard is deliberately general. Countries and programs publish profiles and implementation guides that constrain it for specific uses: which elements are mandatory, which code systems to use and how identifiers are formatted. Building to the relevant implementation guide, not just to base FHIR, is what makes systems genuinely interoperable.
Practical steps for a new system
- Identify the systems you must exchange data with and the implementation guides they follow.
- Use established terminologies, such as LOINC, SNOMED CT or ICD, instead of free-text codes.
- Design identifiers carefully; matching records for the same person across systems is often the hardest problem.
- Validate resources automatically against profiles before they are sent.
FHIR and aggregate reporting
Many health programs report aggregate indicators through platforms such as DHIS2. FHIR is well suited to exchanging individual-level records, while aggregate figures can be calculated from those records and published to reporting platforms. Designing both flows together spares health workers from entering the same data twice.
Interoperability is not a feature added at the end. It is a design decision made at the beginning.