FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare data electronically between different systems. Developed by the standards organization HL7, it gives hospitals, insurance companies, apps, and other health technology a common language so they can share patient information reliably. Think of it as the format that lets your doctor’s system talk to your pharmacy’s system, your insurance company’s database, or a health app on your phone.
Why Healthcare Needed a New Standard
Before FHIR, healthcare already had data standards, but they were notoriously difficult to work with. The older HL7 v3 standard, for example, required deep knowledge of a complex abstract model just to get started. Worse, it allowed wildly different ways to represent the same basic concept. At the international level alone, there were 10 different model templates just for “Patient,” each with its own structure, element names, and constraints. Organizations implementing the standard locally created even more variations. The result was a fragmented landscape where “interoperable” systems still struggled to understand each other.
FHIR was designed to fix this. There is one Patient resource in FHIR. Organizations can customize it through profiles, but every profile uses the same underlying structure and format. You can implement FHIR with no knowledge of the older abstract models that made previous standards so inaccessible. The learning curve dropped dramatically, which meant faster adoption.
How FHIR Actually Works
FHIR organizes health data into building blocks called “Resources.” Each Resource represents a familiar healthcare concept: a patient, a medication, a lab result, an immunization record. Resources are self-contained units of data that can be requested, updated, or searched independently. This is a major shift from older standards, where data was bundled into large messages and couldn’t easily be accessed piece by piece.
The exchange happens through APIs, the same web technology that powers everyday services like maps and weather apps. FHIR uses a style of API called RESTful, which is the dominant approach on the modern web. A system requesting data sends simple commands: one to read a record, one to create a new record, one to update, one to delete. A basic request might ask for a single Patient resource and get back that patient’s demographic information in a structured, predictable format.
The data itself can be represented in JSON, XML, or a format called Turtle. JSON is the format most web developers already work with daily, which is part of why FHIR gained traction so quickly compared to older healthcare standards that relied on specialized formats. Every Resource also includes a human-readable text version alongside the structured data, so the information is usable by both software and people.
Common Resource Types
FHIR Resources are grouped by purpose: individuals, diagnostics, billing, medications, and more. Some of the most frequently used include:
- Patient: Demographics and identifying information for a person receiving care.
- Observation: Lab results, vital signs, and other clinical measurements.
- MedicationRequest: A prescription, including the drug, dose, timing, route, and the reason it was prescribed. Covers both hospital and community settings.
- MedicationDispense: A record of the actual product provided to the patient, including the dosage to be taken.
- MedicationAdministration: Documentation that a patient actually received or consumed a medication.
- Immunization: Current and historical vaccine administration records.
- ImmunizationRecommendation: A personalized forecast of which vaccines a patient is eligible for based on published schedules.
This granularity matters. Rather than pulling an entire medical record, an app can request exactly the Resources it needs. A pharmacy system might only need MedicationRequest data. A vaccine tracker only needs Immunization records. This keeps data exchanges efficient and limits unnecessary exposure of sensitive information.
FHIR Is Now a Federal Requirement
FHIR moved from a voluntary standard to a regulatory mandate in 2020. The Office of the National Coordinator for Health IT (ONC) published its final rule under the 21st Century Cures Act, establishing FHIR Release 4 (R4) as the required standard for health IT certification. That same year, CMS published its Interoperability and Patient Access final rule, requiring Medicare Advantage plans, Medicaid, the Children’s Health Insurance Program, and qualified health plans on federal exchanges to implement FHIR-based APIs.
These rules were designed to do two things: give patients electronic access to their own health data and enable smoother data exchange between payers and providers, and between payers themselves. The regulatory backing transformed FHIR from a promising technical standard into the foundation of U.S. health data infrastructure.
FHIR R4: The Current Baseline
FHIR Release 4, published in 2019, was the first version to include “normative” content, meaning it was accepted by the American National Standards Institute (ANSI) as an official American National Standard. Two core clinical Resources, Patient and Observation, reached normative status in this release, along with the RESTful API itself, the JSON and XML formats, and nine additional Resources. Normative status is significant because it signals stability. Developers building on normative content can trust that it won’t change in ways that break their systems.
R4 is the version referenced in federal regulations, making it the practical baseline for healthcare organizations in the United States today. A newer version, R5, has been released, but R4 remains the regulatory standard.
Third-Party Apps and Security
One of FHIR’s most practical impacts is enabling third-party health apps to connect securely to electronic health records. A framework called SMART on FHIR makes this possible by combining the FHIR data layer with industry-standard security protocols for authentication (verifying who you are) and authorization (verifying what you’re allowed to access).
This is what allows a patient-facing app on your phone to pull your lab results directly from your hospital’s system, or lets a clinical decision support tool plug into a provider’s electronic health record. The app doesn’t need a custom integration for every hospital. If both sides support FHIR and SMART, they can connect using the same open standards. Security is handled through established protocols that control which users and applications can access which data, with each request scoped to specific permissions.
What FHIR Means for Patients
For most people, FHIR works invisibly in the background. But its effects are increasingly visible. If you’ve used a health app that pulls your medical records from multiple providers into one place, FHIR is likely the standard making that possible. If your insurance company offers an app where you can view claims, medications, and care history, it’s probably built on a FHIR API that federal rules now require.
The core promise is straightforward: your health data should be portable and accessible to you, not locked inside one hospital’s proprietary system. FHIR is the technical infrastructure that makes that promise enforceable at scale.