HL7 FHIR
Also known as: FHIR, Fast Healthcare Interoperability Resources
HL7 FHIR (Fast Healthcare Interoperability Resources, pronounced 'fire') is a standard for exchanging health information between systems using modern web technology.
It breaks health data into building blocks called resources, such as Patient, Observation, and MedicationRequest, that apps can read and write through APIs. While FHIR has become the default for new health data exchange, having a standard isn't the same as having connected care: vendors, rules, and incentives still decide whether data actually flows.
HL7 FHIR, explained at three levels
At home
Think of FHIR as a set of standard forms that every health office agrees to use. If every clinic writes allergies, lab results, and prescriptions on the same form, any other office can read them. FHIR does this for computers: it defines a common structure for each type of health record, so your doctor's system, the hospital, the lab, and an app on your phone can request and understand each other's data.
At work
FHIR is a standard that defines how health data is structured and how systems ask for it over the web. Instead of building a custom interface for every pair of systems, a clinic or vendor exposes standard APIs that any compliant app can call. For a business, that means faster integrations, lower interface costs, and less lock-in, because new tools can plug into the same data without starting from scratch.
At home
FHIR breaks your health record into small building blocks called resources. A Patient resource holds your name and birth date, an Observation holds a single reading such as a blood pressure, and a MedicationRequest holds a prescription. Each resource has a web address, so an app asks for it the way a browser asks for a page, and gets back a structured file, usually in JSON. Resources link to each other, so an Observation points back to the Patient it belongs to.
At work
A FHIR server exposes resources through RESTful operations: read, search, create, and update over HTTPS. Third-party apps connect through SMART on FHIR, which uses OAuth 2.0 so a user or organization grants scoped access. Profiles constrain the base resources for a country or use case, such as CA Core+ in Canada or US Core in the United States, fixing which fields are required and which code systems apply. Bulk FHIR exports whole populations as files for analytics rather than one record at a time.
At home
FHIR's base resources are deliberately loose: most fields are optional, and a diagnosis can be coded in several terminologies. That flexibility helped adoption, but it means two systems can both claim FHIR support and still disagree on what a record contains. Profiles and shared code systems, such as SNOMED CT for conditions and LOINC for lab tests, close that gap. While FHIR gets the credit, in my view the profiles and terminologies do most of the real work of making data understandable.
At work
In a typical hospital, FHIR sits as a facade over older systems: an interface engine translates HL7 v2 messages and database records into FHIR resources on request. That mapping is where projects fail, through lost detail, inconsistent codes, and slow queries against legacy back ends. Security depends on SMART scopes, token lifetimes, and app vetting. Consent rules differ by province, so access logic cannot live in the standard alone. Plan for years of FHIR and v2 coexistence, and test vendors against named profiles, not general claims.
Real-world examples
At home
Marcus switched family doctors in Nova Scotia and was frustrated that his records didn't follow him. Reading about FHIR, he learned that the clinics' systems could exchange data in a standard way, but that this depends on each vendor and province enabling it.
At work
Nadia is an integration architect at a Toronto hospital network. Her team built a FHIR API so a remote monitoring app could send patients' home blood pressure readings straight into the hospital's records, replacing faxed summaries.
How it compares
| feature | HL7 FHIR | HL7 version 2 |
|---|---|---|
| Technology | Web APIs, JSON or XML | Pipe-delimited messages |
| Ease of use for developers | High | Low, needs specialists |
| Typical use | Apps, patient access, new integrations | Internal hospital system messaging |
| Adoption | Rapidly growing | Still dominant inside hospitals |
FHIR is the modern web standard. HL7 v2 is the workhorse it's slowly replacing.
For analysts
When buying health software, I'd ask vendors which FHIR resources and profiles they support for both reading and writing, and whether there are extra fees for API access. 'FHIR-enabled' on a brochure can mean very little.
History & origin
Health Level Seven International, founded in 1987, created the HL7 version 2 messaging standard that still runs inside most hospitals, along with the more complex version 3 and CDA documents. Australian developer Grahame Grieve proposed FHIR in 2011 as a simpler, web-friendly alternative. FHIR Release 4, published in 2019, included the first 'normative' parts that wouldn't change. US rules under the 21st Century Cures Act required certified health records to offer standardized FHIR APIs to patients, and Apple Health Records used FHIR to pull hospital data onto iPhones. In Canada, the federal government reintroduced its Connected Care for Canadians Act as Bill S-5 in February 2026 to require health IT vendors to support interoperability standards and stop data blocking; the Senate passed it that May. In my view, FHIR solved the technical problem faster than the health system solved the business problem.