When a person comes to a hospital, what matters to them is that the doctor can see their test results, the front desk does not mix up appointments, the insurer receives the necessary information, and none of the examination results get lost. Most of us do not care how exactly these systems exchange data. Yet in practice, everything depends on it.
Hospitals rarely rely on a single all-purpose software system. In most cases, they use an entire set of systems: an electronic health record, laboratory information systems, billing, radiology, scheduling, insurance modules, and more. All of these different data sources must work together. That is exactly why data exchange standards are needed, primarily HL7 and FHIR.
This is where confusion begins. These standards are often described as if one were “old and bad” and the other “new and wonderful.” In reality, things are not that simple. In this article, we will look at what HL7 and FHIR actually do, where each works best, where each falls short, and why modern healthcare still depends on both.
What is HL7?
HL7 is a broad family of standards created for exchanging healthcare information. Without getting into technical details, the idea is very simple: one system sends another a clear message about what has happened.
For example:
- a patient has been registered;
- the patient has been transferred to another department;
- the laboratory has returned a result;
- a physician has placed an order;
- data must be sent to the payment system.
This kind of exchange is especially important inside a hospital, where events happen continuously. HL7 v2 is the most widely used standard for exchanging healthcare information in the United States. In 2024, it was used by 95% of U.S. healthcare organizations and in more than 35 countries.
That is why it would be misleading to say that HL7 is outdated. Many healthcare processes still depend on these standards: admissions, transfers, lab results, clinical reports, scheduling, and billing.
So where did FHIR come from?
FHIR appeared later, when it became clear that older mechanisms were no longer enough for the new digital world. Today, patients expect to see their data in a convenient app, not just inside a provider’s portal or electronic health record system. Developers want to build services that can be connected quickly to an Electronic Health Record. Regulators and healthcare systems increasingly expect medical information to be available in accessible digital form, not on paper and not only after a lengthy request process.
FHIR was created as a more modern way to exchange healthcare data quickly and efficiently, including both clinical and administrative information. It is built on approaches that are familiar to web development, including APIs and standard internet technologies. That does not automatically make it “better.” But it does make it much easier to understand and use when building mobile applications and digital platforms.
What is the difference?
Put as simply as possible, the two standards can be understood like this:
HL7 is the internal service communication layer. It is not especially elegant or fashionable, but it is well established. For years, it has kept information moving inside healthcare institutions.
A full-scale shift from long-established HL7-based workflows to FHIR-based infrastructure is still very difficult. Modern hospitals have dozens of systems, years of accumulated integrations, clinical workflows, security requirements, payment requirements, legacy equipment, vendor constraints, and a strong reluctance to disrupt processes that already work. If an entire operational environment has relied on HL7 v2 for years, no one is going to tear it apart just because a newer standard has appeared on the market. HL7 v2 is still widely used today for messages related to admissions, orders, lab results, scheduling, and billing.
FHIR, by contrast, provides a convenient and understandable entry point for the outside world. Through it, a hospital can securely connect a patient app, a partner service, new analytics tools, an insurance platform, or another digital product.
One of FHIR’s key features is that it breaks healthcare data into clearer, more manageable pieces. In FHIR, the basic element is the resource. A resource is a separate object: a patient, an observation, a prescription, an encounter, a diagnostic report, and so on. Everything that can be exchanged is defined through resources, and those resources can be combined for specific scenarios. For developers, this is often more intuitive than working with older exchange formats that evolved historically alongside hospital workflows.
FHIR relies on familiar web technologies such as JSON, XML, HTTP, and OAuth. This lowers the barrier for developers and makes it easier to build new applications.
Existing systems can also coexist with FHIR. They do not necessarily have to be thrown away and replaced entirely.
In practice, in today’s healthcare environment, HL7 remains the foundation of internal data exchange in many organizations, while FHIR is more often added as a new layer on top of the existing infrastructure.
Where FHIR is especially useful
There are several situations where its advantages are particularly clear.
First, patient-facing services such as portals, mobile apps, and tools for accessing lab results, prescriptions, and discharge summaries. Standardized APIs are exactly what make it possible for people not to depend every time on the closed ecosystem of a particular clinic or vendor.
Second, external integrations. This includes situations where data needs to move beyond the hospital’s internal systems — to an insurer, a partner organization, a telemedicine platform, an analytics service, or another digital product.
Third, new development. If an organization is launching a new product from scratch, a modern API-based approach is usually simpler than trying to build everything around older exchange mechanisms. This does not mean FHIR is free of complications. It is not. But for many teams, the language of the web is simply more familiar.
Where HL7 is still more practical
It remains the better fit for the stable day-to-day operation of a hospital.
Patient registration, transmission of laboratory results, routing of events between internal systems, billing, scheduling — HL7 has handled all of this for a long time, and it does so reliably. That is exactly why it is still so widely used.
And that is why the real-world strategy is usually to keep what already works and gradually add a more modern interface only where it is genuinely needed.
Where each standard falls short
Neither standard is perfect, and that is one reason they continue to coexist. HL7 v2 is deeply embedded in hospital operations, but it can be difficult to work with, especially for modern product teams. Its structure reflects decades of operational needs inside healthcare institutions, not the expectations of today’s app developers. Integrations often require significant customization, and implementation can vary from one organization to another.
FHIR is more developer-friendly. But real-world implementation can still be complex, especially when organizations interpret resources differently, limit access in different ways, or expose only part of the data. Adopting FHIR also does not automatically solve deeper problems such as poor data quality, fragmented infrastructure, or weak governance. A modern API does not eliminate the operational complexity of healthcare.
In its 2025 review, McKinsey notes that there is no single universal path in this area: the right approach depends on a country’s context, the maturity of its digital environment, the resources available, and the infrastructure already in place.
Overall, if the goal is to keep a hospital running smoothly day to day, HL7 still does that job well.
If the goal is to make data easier and safer to use in new digital scenarios, FHIR is often the more convenient option.
And in the real world, they very often work together rather than replacing one another. HL7 is unlikely to disappear anytime soon. It will probably remain the backbone of many internal hospital workflows, while FHIR will keep growing as the easier option for apps, external services, and patient access to data.
The most realistic future is not one standard replacing the other, but both working side by side. Hospitals still need stable internal systems, but they also need data to move more easily between platforms, services, and users. That would mean fewer disconnected systems, easier access to information, and better conditions for digital tools and coordinated care.