If you’ve spent more than a few minutes around digital health teams, you’ve probably heard the term FHIR tossed around, often with both excitement and frustration. But what exactly is FHIR? Why was it created? And is it really the answer to healthcare interoperability?

Let’s rewind: Where FHIR fits in the world of standards

Health data standards help systems understand and exchange information. Some standards define what data means (like SNOMED CT or LOINC), others define how data is structured or exchanged (like FHIR), and still others define how data is stored over time (like openEHR).

FHIR sits in the data exchange layer. It defines how systems can request and share healthcare data using modern web technologies. But FHIR didn’t appear out of nowhere.

From HL7 v2 to FHIR: Why a new standard was needed

FHIR was developed by HL7 (Health Level Seven International), the non-profit standards organization behind some of the most widely used healthcare data formats. Since the 1980s, HL7 has worked to improve how health systems exchange information.

The first major version, HL7 v2, allowed hospitals to send messages like lab orders or admissions between systems. It worked, but it was messy: the format was loosely structured and implemented differently at nearly every hospital. Then came HL7 v3, an attempt to bring rigor and structure. But it ended up being too rigid, too complex, and ultimately too hard to adopt. HL7 CDA (Clinical Document Architecture) was another attempt, focused on full clinical documents like discharge summaries. It saw more success, but it wasn't built for real-time, API-based interactions.

Out of all this came FHIR: a new standard combining the best ideas from HL7 v2, v3, and CDA, but built for the modern web.

Meet FHIR - Fast Healthcare Interoperability Resources

FHIR (pronounced "fire") was created by HL7 as a fresh approach to health data exchange. It uses familiar tools like REST, JSON, and XML, making it far more accessible to developers.

Rather than defining massive documents, FHIR organizes health information into smaller, modular units called resources. Each resource represents a specific concept in healthcare, such as a patient, a lab result, a clinical encounter, or a prescribed medication. What makes FHIR especially adaptable is that these resources follow a consistent structure and are grouped into broader modules depending on their function.

For instance, the base module includes key entities like patients and practitioners, grouped under a category called individuals. The clinical module covers essential healthcare content such as observations, conditions, and procedures. Additional modules focus on administrative, financial, and workflow aspects of care, from billing data to scheduling and care plans. Each resource contains standard fields for things like identifiers, status, timing, and references to related resources, making the format both machine-readable and easy to work with via API.

Because FHIR is built on modern web standards, these resources can be accessed or exchanged using simple RESTful calls and JSON payloads.

Let’s look at an example

Suppose a health app wants to display a patient’s recent blood pressure readings. Using FHIR, the app could combine a Patient resource with an Observation resource, coded using LOINC (e.g. 85354-9 for a blood pressure panel), and retrieve it with a request like:

GET /Observation?patient=123&code=85354-9

…and get a clean, structured response. In theory, this should look similar across all systems that implement FHIR properly.

So is FHIR the answer?

FHIR has become the leading standard for health data exchange, particularly in the United States, where regulations like the 21st Century Cures Act mandate that EHR systems expose FHIR APIs. But its reach extends far beyond North America. Countries like the UK, Germany, Australia, and Canada have adopted national programs or implementation guides based on FHIR, and its footprint continues to grow in Asia and parts of Latin America.

Yet while FHIR offers a modern, API-driven approach to interoperability, adopting it in practice is rarely straightforward. Many EHR vendors support only a narrow slice of the specification, or implement resources in slightly incompatible ways. Lab results, for instance, may follow the same general FHIR structure but differ in coding systems, field usage, or even endpoint naming conventions, making integration less seamless than it appears on paper.

Globally, the barriers to FHIR adoption vary. In Europe, cross-border healthcare and regulatory diversity complicate alignment. In Asia-Pacific and Latin America, infrastructure and training gaps slow implementation. Smaller providers everywhere face resource and staffing challenges, and even well-funded systems must grapple with privacy, data governance, and consent management, all of which can be interpreted differently across regions. While FHIR includes security standards, how those are enforced depends on national frameworks and technical capacity.

In short: FHIR is a strong foundation. But turning it into reliable, real-world interoperability still takes thoughtful implementation, local adaptation, and often, additional tooling to bridge the last mile.

How Leyr makes FHIR usable in the real world

At Leyr, we don’t assume that “FHIR support” means consistency.

Some EHRs offer only partial FHIR implementations. Others don’t use FHIR at all. Lab results might be coded in LOINC, SNOMED, or something proprietary. Authentication flows vary wildly.

That’s why Leyr acts as a smart translation layer:

• Normalizes key data across EHRs, FHIR-based or not

• Handles authentication and token flows per EHR

• Maps and reshapes resources to give a consistent developer experience

In other words, Leyr abstracts away those variations, so developers don’t have to wrestle with the details of each EHR.

To conclude, FHIR is a major step forward. It brings healthcare data exchange into the web-native era, using standards modern developers actually want to work with. But no standard, not even FHIR, solves interoperability alone. The messy details of implementation, variation, and legacy still require effort. Leyr bridges that last mile, making FHIR (and non-FHIR systems) usable through a unified, developer-friendly interface. So your product can focus on improving care, not wrangling formats.