Ask three vendors what "HL7" means and you may get three different answers — and that confusion is exactly why practice administrators keep landing on this question. HL7 and FHIR are not rival standards fighting for market share. They are both published by the same standards body, HL7 International, and understanding how they relate is the fastest way to make sense of vendor claims, integration quotes, and the federal rules now shaping how your practice’s data moves.
HL7 and FHIR Are Family, Not Competitors
HL7 International is an ANSI-accredited organization that has been publishing healthcare data-exchange standards since the late 1980s. When people say "HL7" without qualification, they almost always mean HL7 Version 2 (v2) — a messaging standard first released in 1989 that is still used by an estimated 95% of U.S. healthcare organizations, and in more than 35 countries, mostly to move messages inside a single hospital or health system: admissions, discharges, transfers, lab results, orders. It works, but it was built for point-to-point connections between systems that already trust each other, not for the open, multi-party data sharing patients and regulators expect today.
FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is HL7 International’s newer standard, released in 2014. Rather than sending large, rigid messages, FHIR breaks clinical information into small, reusable "resources" (a Patient resource, a Medication resource, an Observation resource) that can be requested individually over a standard web API, the same RESTful, JSON-based approach used across modern software generally. That single design choice is why FHIR is dramatically easier for a smaller development team, or a smaller practice’s IT vendor, to work with than HL7 v2 ever was.
The Practical Differences
For an administrator evaluating a system or a vendor, the differences that actually matter come down to four things:
| Aspect | HL7 v2 | FHIR |
|---|---|---|
| First released | 1989 | 2014 |
| Format | Proprietary segment-and-delimiter messages | JSON or XML over standard web APIs |
| Typical use | Internal system-to-system messaging within one organization | Exchange across organizations, and with patient-facing apps |
| Integration cost | Higher — specialized interface engines and expertise | Lower — standard web development skills apply |
Why FHIR Is No Longer Optional
FHIR’s shift from "better technical option" to federal requirement happened through a specific sequence of rulemaking. The 21st Century Cures Act directed federal regulators to require standardized, API-based access to health data, and the ONC’s Cures Act Final Rule implemented that by mandating FHIR-based APIs for certified health IT. The CMS Interoperability and Patient Access Final Rule, finalized in 2020, went further: it requires CMS-regulated payers — Medicare Advantage plans, Medicaid and CHIP programs, and Qualified Health Plan issuers on the federal exchange — to expose patient claims and clinical data through FHIR Release 4 APIs, and to publish provider directory data the same way. More recently, the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) extends FHIR-based API requirements specifically to prior authorization, with compliance dates arriving in 2026 and 2027.
The result is that FHIR adoption is no longer confined to large health systems experimenting with new technology. Industry tracking as of 2025 put FHIR support at roughly 92% of EHR vendors and FHIR-enabled APIs at around 90% of health systems, with about 81% of hospitals having patient access APIs live. The Trusted Exchange Framework and Common Agreement (TEFCA), the federal effort to build a single nationwide network for health data exchange, began piloting FHIR-based exchange in 2025 as well. For a practice, that means the question is shifting from "should we support FHIR" to "which of our systems still don’t."
What This Actually Means for a Typical Practice
Most independent and mid-sized practices will never write a line of FHIR code themselves, and they don’t need to. What matters operationally is simpler:
- Your EHR should already support it. Certified EHR technology is required to expose FHIR-based APIs under the ONC rule — if a system genuinely can’t, that is a red flag worth raising with the vendor directly.
- Payer connections are moving to FHIR whether you initiate it or not. Prior authorization, claims status, and patient-access requests are being standardized on FHIR under the CMS rules above, which affects how your billing and RCM workflows will need to connect going forward.
- "Interoperable" is not a single checkbox. A system can be FHIR-capable in one narrow area (say, patient access) and still rely on older HL7 v2 messaging for internal lab or pharmacy interfaces. Ask specifically which resources and workflows a vendor supports, not just whether they "do FHIR."
Finding the Right Vendor for Your Situation
This is where the practical work happens: matching a practice’s actual EHR, billing system, and HIE participation to a vendor that has done that specific integration before, rather than one offering a generic promise of "full interoperability." The right EHR/HIE onboarding partner, or the right revenue-cycle vendor navigating FHIR-based prior authorization, is usually the difference between a smooth transition and months of support tickets. Given the pace of the CMS rules above, practices that get ahead of these connections now — rather than waiting for a compliance deadline — typically spend less to do it.
HL7 v2 isn’t going away overnight, and FHIR isn’t magic. But understanding that FHIR is HL7 International’s answer to the limits of v2 — and that federal rulemaking has now made it mandatory across payers and certified EHRs — gives a practice administrator the vocabulary to ask better questions of every vendor at the table, and to plan interoperability spending around real deadlines instead of vague promises.