FHIR and HL7 are both healthcare data standards, but they solve the problem in different ways. HL7 v2 is the older, message-based standard that still moves most data between hospital systems today. FHIR is the modern, API-based standard built for web and mobile apps to exchange healthcare data cleanly. The short version: HL7 v2 is the plumbing already in the walls, and FHIR is the modern interface most new products and US regulations now expect. For most US HealthTech companies, the real work is not choosing one over the other, it is connecting the two.
This matters more than ever because US rules are pushing the whole industry toward FHIR. By 2024, roughly 93% of certified health-IT customers had a FHIR API available (HealthIT.gov), and the CMS-0057-F rule requires impacted payers to run production FHIR APIs by January 1, 2027. Yet HL7 v2 is not going away, because decades of hospital infrastructure runs on it. This guide explains both, the difference, when to use each, and how to bridge them.
What is HL7?
HL7 (Health Level Seven) is a family of standards for exchanging clinical and administrative healthcare data. When people say "HL7" in day-to-day work, they usually mean HL7 version 2 (HL7 v2), the message-based standard that has been in production for over 30 years and still carries most data between hospital systems.
HL7 v2 works by sending structured text messages between systems when an event happens, for example an admission, a lab result or an order. It is reliable, deeply embedded and well understood, which is exactly why it is still everywhere. Its downside is that it predates the modern web, uses a terse pipe-and-hat format that is hard to read, and allows enough local variation that two "HL7 v2" interfaces rarely behave identically.
There is also HL7 v3 and CDA (Clinical Document Architecture), used mainly for document exchange, but for most product teams the live comparison is HL7 v2 versus FHIR.
What is FHIR?
FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a modern HL7 standard for exchanging healthcare data through web APIs. Instead of sending event messages, FHIR represents healthcare concepts as "resources", such as Patient, Observation, Encounter or MedicationRequest, that apps request and update over standard REST APIs, usually as JSON.
FHIR was designed for the way software is built today. It uses familiar web technology, so developers can work with it without deep healthcare-integration experience, and it defines clear, consistent resources so data means the same thing across systems. It also supports SMART on FHIR, which lets an app launch securely inside an EHR with the right permissions. This modern, developer-friendly design is why FHIR underpins nearly every new patient app, digital health product and US interoperability rule.
FHIR vs HL7: what is the difference?
The core difference is that HL7 v2 pushes event messages between systems, while FHIR exposes data as resources through web APIs that apps can query on demand. One is built for system-to-system messaging inside a hospital; the other is built for apps, patients and modern integration.
| Dimension | HL7 v2 | FHIR |
|---|
| Age and maturity | 30+ years, ubiquitous | Modern, rapidly adopted |
| Model | Event-based messages | Resources via REST API |
| Format | Pipe-and-hat text | JSON (or XML) |
| Best for | System-to-system inside a hospital | Apps, patients, mobile, web |
| Developer experience | Specialist, harder to learn | Web-standard, developer-friendly |
| Consistency | Varies by local implementation | Standardised resources |
| Regulatory direction | Legacy backbone | Required by CMS-0057-F and TEFCA |
Neither is simply "better". HL7 v2 is the dependable backbone that already carries hospital data; FHIR is the modern layer that new products and regulators expect. The winning approach is usually to keep HL7 v2 where it works and add FHIR where you need apps, patient access or compliance.
For most US HealthTech companies, success is not choosing HL7 or FHIR. It is bridging the two: keeping HL7 v2 where it works, and adding FHIR where you need apps, patient access and compliance.
When should you use HL7 v2 or FHIR?
Use HL7 v2 when you are integrating with existing hospital systems that already speak it, for example receiving lab results, orders or admission messages from systems built around v2. Use FHIR when you are building patient-facing apps, connecting modern products, launching inside an EHR with SMART on FHIR, or meeting US interoperability rules.
In practice most real projects use both. A common pattern is to receive HL7 v2 messages from legacy hospital systems, transform them into FHIR resources, and expose that clean FHIR layer to your apps and partners. That way you meet the systems where they are while giving your product and any regulators the modern standard they need.
How do you migrate from HL7 v2 to FHIR?
You migrate by adding a FHIR layer on top of your existing HL7 v2 interfaces rather than ripping them out. The goal is a clean FHIR API for modern needs, fed by the v2 data you already receive. Here is the process we use.
- Map your data. Inventory the HL7 v2 messages you send and receive, and identify the FHIR resources they correspond to.
- Design the FHIR model. Choose the FHIR resources and profiles you need, aligned to USCDI where US compliance applies.
- Build a transformation layer. Convert HL7 v2 messages into FHIR resources, handling the local quirks in your v2 feeds.
- Stand up a FHIR server and API. Host the FHIR resources and expose secure REST endpoints, with SMART on FHIR where apps launch in the EHR.
- Validate and test. Check conformance against the relevant implementation guides and test with real data.
- Run both in parallel. Keep HL7 v2 where it works and route modern and regulated use cases through FHIR.
The result is not a risky big-bang replacement. It is a modern FHIR interface layered onto the reliable v2 infrastructure you already trust. This is exactly how we approach EHR and FHIR integration services.
What do US regulations now require?
US regulation is steadily standardising on FHIR. The CMS-0057-F rule requires impacted payers, including Medicare Advantage, Medicaid and ACA plans, to build production FHIR APIs for Patient Access, Provider Access, Payer-to-Payer and Prior Authorization, with core requirements due by January 1, 2027. TEFCA, the national exchange framework, is moving through a multi-year FHIR roadmap, and data must align to the USCDI standard.
The practical takeaway for product teams: if your roadmap touches payers, patient access or national exchange, FHIR is not optional, and the clock is running. HL7 v2 remains the backbone inside hospitals, but the interfaces regulators and partners ask for are FHIR. Building your FHIR layer now is both a compliance move and a competitive one.
What are common HL7 and FHIR mistakes to avoid?
Most interoperability pain comes from a handful of avoidable mistakes. Watch for these.
- Treating an available FHIR API as done. An API being present is not the same as data being mapped, normalised and usable in your workflow.
- Assuming all HL7 v2 feeds are the same. Local variation means two v2 interfaces rarely behave identically; each needs handling.
- Skipping profiles and USCDI alignment. Generic FHIR without the right profiles fails conformance for US compliance.
- Big-bang replacement. Trying to rip out HL7 v2 instead of layering FHIR on top adds cost and risk.
- Ignoring security. FHIR APIs expose health data, so encryption, access control and SMART on FHIR authorisation are essential.
- Underestimating the deadline. CMS-0057-F work is non-discretionary and takes time; late starts get expensive.
The pattern: interoperability rewards careful mapping and a bridge-not-replace approach, and punishes shortcuts.
How do you get started?
Start by mapping what you have and what the rule or product actually requires, then build the FHIR layer where it matters most. Do not try to convert everything at once. Identify the highest-value use case, patient access, a specific integration, or a CMS-0057-F API, and deliver that first.
A practical sequence: inventory your current HL7 v2 interfaces, define the FHIR resources and profiles you need, build a transformation and FHIR API layer for the priority use case, validate against the relevant implementation guides, then expand. If a 2027 deadline applies, work backward from it now. This is the approach we take on EHR and FHIR integration: meet the systems where they are, and give your product and regulators the modern standard they expect.
Conclusion
FHIR and HL7 are not rivals so much as two layers of the same story. HL7 v2 is the proven backbone that already moves hospital data, and FHIR is the modern, API-based standard that new products and US regulations now require. For most US HealthTech companies, success is not picking a side; it is bridging the two, keeping v2 where it works and adding FHIR where you need apps, patient access and compliance.
With roughly 93% of certified health-IT customers already on a FHIR API and CMS-0057-F due in 2027, the direction is clear. The teams that build their FHIR layer thoughtfully now, on top of the HL7 v2 infrastructure they already trust, will move faster and stay compliant while others scramble. If you want help connecting HL7 v2 and FHIR, talk to our team and we will map it with you.
Key takeaways
- HL7 v2 is the 30-year-old, message-based standard that still moves most data between hospital systems.
- FHIR is the modern, API-based HL7 standard built for apps, patients and web integration, using resources over REST.
- The main difference: HL7 v2 pushes event messages; FHIR exposes data as resources apps can query on demand.
- Most real projects use both, often transforming HL7 v2 into a clean FHIR layer.
- US rules are standardising on FHIR: CMS-0057-F requires payer FHIR APIs by January 1, 2027, and TEFCA is FHIR-aligned.
- Migrate by layering FHIR on top of existing v2 interfaces, not by ripping v2 out.
- An available FHIR API is only the start; the value is in mapping, normalising and securing the data.
