FHIR vs HL7: Why Healthcare Needs Both (But Can't Rely on One Alone)

Understand why healthcare interoperability depends on both HL7 and FHIR — and why knowing both will future-proof your career.

By: Nasir Hussein   |   Published: May 28, 2025

Imagine you're in an emergency room, but the doctor can't quickly access your past medical records because the hospital systems don't communicate. This is healthcare's notorious interoperability problem. In fact, the lack of seamless data exchange costs the U.S. health system over $30 billion every year [1]. Clearly, better data sharing isn't just a technical nicety – it's essential for patient care and efficiency. This is where health data standards come in. Two of the most important standards are HL7 and FHIR. They're often pitted against each other, but as we'll explore, healthcare needs both of them working in tandem to truly connect the dots.

"The lack of interoperability in healthcare data costs the U.S. health system more than USD 30 billion annually." [1]

What is HL7 (and HL7 v2)?

HL7 stands for Health Level Seven International – the standards organization behind many healthcare data formats. When people refer to "HL7" in hospitals today, they usually mean HL7 version 2 (v2), a messaging standard first developed in the late 1980s. Think of HL7 v2 messages like structured electronic telegrams: they're plain text lines with data fields separated by pipes (|) and carets, carrying information like patient IDs, lab results, or billing codes. By the 1990s, HL7 v2 had become the dominant format for hospital system interfaces [2,3]. Even today, it's everywhere – nearly every lab result, admission notice, or billing update inside a hospital is sent via an HL7 v2 message.

How HL7 v2 works: It uses a message-based approach. For example, when a patient is admitted, the registration system sends an "ADT" message (Admission, Discharge, Transfer) to other systems. Labs send "ORU" messages (Observation Result) with test results. Each message is a series of segments (lines) with predefined positions for each piece of data. This rigid structure made it easy for different vendors' software to exchange data – at least in theory.

Current use cases:

• Admissions and transfers: Patient admissions, discharges, and transfers (ADT messages) keep departments in sync.
• Lab results: Labs send results to electronic health records using HL7 ORU messages.
• Billing: Charges and billing info move via HL7 DFT (Detailed Financial Transaction) messages.
• Pharmacy and orders: Medication orders (RXO/RDE messages) and others flow through HL7.

HL7 v2 has been a workhorse and enjoys near-universal adoption in legacy healthcare systems [4,5]. However, it has notable limitations:

• Not web-native: HL7 v2 was designed before the web era. Its plain-text, fixed-format messages don't play well with modern web technologies. Sharing data outside a hospital's firewall (e.g., with a cloud app) is cumbersome with HL7 v2.
• Inconsistency: The standard is very flexible – too flexible. Every vendor and hospital network ended up using "private flavors" of HL7 v2, adding custom segments or slightly tweaking fields. Two labs might both send HL7 results but with different quirks, so interfaces require lots of custom mapping.
• Limited data types: HL7 v2 is great for discrete, transactional data (like "patient admitted" or lab values), but less ideal for complex or multimedia data. Sending a whole clinical document or an image is awkward in HL7 v2.
• No direct API support: HL7 v2 isn't an API; it's a message. You can't query an HL7 v2 interface for "all of patient Jane's allergies" easily – you'd typically request a full document or wait for a message. In the age of apps needing on-demand data, this is a drawback.

To illustrate HL7's continued importance: a 2023 survey found 96% of Health Information Exchanges (HIEs) still receive HL7 v2 ADT messages for patient admissions [6,7]. This old standard remains the backbone for moving data in and between many hospitals. But the industry has also been hard at work on something new – enter FHIR.

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is HL7's modern answer to healthcare integration in the age of the internet. If HL7 v2 is like a structured telegram, FHIR is more like a web service or a JSON payload – API-first and web-friendly from the ground up. Developed in the 2010s and first released around 2014, FHIR uses the technologies that power the web: it represents data as resources (e.g. a Patient, an Observation, a Medication) that are accessed via RESTful APIs and encoded in standard formats like JSON or XML over HTTP.

In simpler terms, FHIR lets software developers work with health data the same way they work with data from any modern web service. Instead of parsing obscure pipe-delimited text, a developer can request GET /Patient/123 and receive a neat JSON object with patient 123's details. This makes it much easier to build healthcare apps for web and mobile. In fact, the shift is so significant that over 80% of U.S. hospitals now use FHIR APIs in some capacity for data exchange, thanks in part to government mandates[8].

Key features of FHIR:

• Resource-centric: Data is broken into resources (Patient, Encounter, Lab Result, Medication, etc.), each with a defined structure. Resources can reference each other (e.g., an Observation resource points to the Patient resource it's about).
• RESTful API: Each resource type typically has a URL endpoint and supports standard HTTP methods – GET (read), POST (create), PUT/PATCH (update), DELETE. This uniform interface is familiar to any web developer.
• Multiple formats: FHIR can use JSON or XML, which are widely-supported, human-readable formats. JSON, in particular, is lightweight and perfect for browser or mobile applications.
• Interoperability & extensibility: FHIR defines core data fields, but also a mechanism for extensions so that local requirements can be added without breaking the standard. It also uses existing code systems (like SNOMED, LOINC) for consistency in clinical meaning.
• OAuth2 friendly: FHIR's API approach means it can leverage modern security/authentication methods (like OAuth 2.0/OpenID Connect) to manage access, something HL7 v2 never had built-in.

Why is FHIR easier for cloud and mobile apps? Because it was built with those in mind. FHIR is essentially an API specification for healthcare. This means a cloud server or a smartphone app can request exactly the data it needs, when it needs it, using standard web protocols. For example, an app could ask for all observations (labs, vitals) for patient 123 in the last month with a simple REST query, rather than receiving a firehose of all data in a big message. This aligns perfectly with how modern applications are designed.

Real-world adoption: Tech giants and health systems alike have embraced FHIR:

• Apple's Health app uses FHIR under the hood – it allows patients to download their medical records from hundreds of hospitals directly to their iPhone[9]. Whenever you see "Connect your hospital to your phone" in Apple Health, that's FHIR APIs at work.
• The NHS in England has been building new integrations with FHIR. For example, their "transfer of care" summaries (discharge summaries shared between hospitals and GPs) use FHIR, even while some other data flows like pathology results still rely on older HL7 v2 formats[10]. This mix-and-match approach shows FHIR is being adopted where it makes sense, alongside legacy standards.
• Major EHR vendors (Epic, Cerner, etc.) and government programs: In the US, the 21st Century Cures Act and associated regulations from ONC require that EHR systems provide a patient-facing FHIR API. As a result, virtually all major electronic health records platforms now have FHIR endpoints. Hospitals can plug in third-party SMART on FHIR apps – like a medication adherence app or a specialized calculator – safely into their systems. SMART on FHIR (an initiative out of Boston Children's and Harvard Medical School) has created an app ecosystem leveraging these FHIR APIs.

All these examples underscore that FHIR's strength is enabling new, innovative uses of data. Whether it's patients accessing their own records on a phone, care providers using smarter clinical decision apps, or health systems exchanging data through cloud services, FHIR opens doors that HL7 v2 finds hard to unlock. It's no surprise that by 2023, surveys showed around 67% of healthcare providers globally were using FHIR APIs at scale[11], and HL7 International reports FHIR adoption has grown over 300% since 2019[12]. The trajectory is clear – FHIR is on fire, so to speak.

HL7 vs FHIR – Why Not Just Replace HL7?

Given FHIR's modern approach, you might wonder: why not simply replace all those old HL7 v2 interfaces with FHIR everywhere? In theory that sounds great – one standard to rule them all – but in practice, it's neither feasible nor even desirable in all cases.

Legacy systems and installed base: Hospitals and labs have decades of investment in systems that speak HL7 v2. These systems (lab analyzers, pharmacy systems, radiology, billing, etc.) are deeply embedded, and they work. Replacing or upgrading every interface to FHIR would be a massive, expensive undertaking and could risk disrupting critical workflows. As the saying goes, "if it ain't broke, don't fix it." A hospital won't rip out a functioning HL7 v2 lab interface just because FHIR is newer.

HL7 v2 excels at certain tasks: HL7 v2 is a tried-and-true solution for real-time event messaging inside clinical environments. For example, ADT admission messages are broadcast instantly to a dozen systems when a patient registers at the front desk. HL7 v2's straightforward push messaging is very effective here. FHIR, on the other hand, was initially more about request/response (queries for data). While FHIR now does have event messaging and subscription capabilities, they're still evolving and not uniformly implemented. So for high-volume, event-driven updates, HL7 v2 remains very efficient. As one integration expert put it, HL7 v2 is like an old reliable pager system – it just keeps pinging updates out – whereas FHIR is more like a smartphone, feature-rich but a bit heavier to constantly ping with every minor event.

Transitional period – co-existence: The reality is we're in a long transition. Both standards co-exist and complement each other. A vivid example is in the UK: as mentioned, the NHS uses HL7 v2 (and even EDIFACT, an older EDI standard) for some messages like pathology results, but uses FHIR for newer flows like care summaries[13]. Similarly, in the US, many internal hospital interfaces remain HL7 v2, while any data leaving the hospital (to health information exchanges or patient apps) is translated to FHIR. Think of it like bilingual communication – inside the house everyone speaks the old dialect (HL7), but when talking to the outside world they switch to the new language (FHIR).

FHIR isn't perfect either: It's worth noting that FHIR is not a magic bullet. It's newer, which means not every use case is fully fleshed out yet. Some complex workflows (like certain types of multi-step clinical workflows) might not have mature FHIR implementations. Also, because FHIR is flexible and still evolving, there can be variability in how different systems implement it (though it's more constrained than HL7 v2 variability). Performance can be a consideration too – pulling lots of data via FHIR might require many API calls, whereas an HL7 message might deliver a bulk chunk in one go. For certain internal high-speed integrations, HL7's "batch dump" approach can be faster.

The bottom line: HL7 v2 and FHIR serve different needs, and healthcare IT environments actually need both. HL7 v2 continues to quietly do its job for intra-hospital communication and some B2B data exchange. FHIR is enabling new connections and patient-facing innovation. Rather than one replacing the other overnight, the industry is weaving them together. For instance, integration engines (like Mirth Connect) often sit in the middle to translate HL7 v2 messages into FHIR resources. Google's Cloud Healthcare API even provides an auto-conversion from HL7 v2 to FHIR on the fly[14,15], which shows the demand for bridging between the two worlds.

What is HAPI FHIR Server?

Now that we've covered HL7 and FHIR, you might be wondering how to get hands-on with FHIR. One popular tool for developers is the HAPI FHIR Server. HAPI FHIR (the name comes from "HL7 API") is an open-source Java implementation of the FHIR standard. In plain terms, it's a ready-made FHIR server that you can run out-of-the-box. Think of HAPI FHIR as a reference engine for FHIR – instead of building a FHIR server from scratch, you can use HAPI FHIR and get a fully functional RESTful API that speaks FHIR.

HAPI FHIR is maintained by the community (with major contributions from Smile Digital Health) and is licensed under Apache 2.0 (free for all uses). It provides both a client library and a server framework for FHIR in Java. Many developers love it for testing and prototyping because it's so quick to set up. For example, you can literally run a one-line Docker command and have a FHIR server up and running locally: docker run -p 8080:8080 hapiproject/hapi:latest. This will launch a HAPI FHIR server that you can then hit with FHIR API calls (using tools like Postman or a web app) to Create, Read, Update, or Delete (CRUD) patient records, observations, etc. No custom code needed to start – it's like getting a blank EHR database with FHIR APIs ready to go.

Key features of HAPI FHIR Server:

• Full FHIR support: It's a complete implementation of the HL7 FHIR standard[16] – meaning it knows all the resource types, validation rules, search parameters, etc. out of the box.
• RESTful API: HAPI FHIR server exposes a REST API for all standard FHIR interactions. You can POST a new Patient resource, search Observations by patient or code, get the history of a record, and so on. All the complexity of the spec (like handling _include or _revinclude in searches, transaction bundles, etc.) is handled for you.
• CRUD and more: As mentioned, you get all CRUD operations. You also get support for batch transactions, conditional updates, and other advanced FHIR features. The server can even be configured to enforce various FHIR validation policies. It includes a built-in web-based tester and a Swagger UI for exploring the API[17], which is great for learning.
• Modular and deployable: HAPI FHIR is Java-based (built on Spring Boot). You can embed it in your own Java application or run it as a standalone server. It's deployable to the cloud or on-premise. For instance, you could run HAPI FHIR on a small AWS or Azure instance, or package it in a Docker container (the project provides a pre-built Docker image). This makes it easy to spin up instances for development, testing, or even production for smaller scale needs.
• Integration-friendly: Because it's open source, HAPI FHIR is often used in integration engines and custom middleware. You can use it alongside tools like Mirth Connect (an interface engine) to do conversions: e.g., Mirth receives an HL7 v2 message from System A, transforms it into a FHIR JSON via HAPI libraries, and then sends it to a HAPI FHIR server or another system's FHIR API. If you're a Python developer building a Django healthcare app, you might not have a FHIR server readily available – but you could deploy HAPI FHIR as the data store and have your Django app communicate with it via REST. It's a quick way to get a "database with an API" without writing tons of backend code.

In summary, HAPI FHIR Server is a fantastic learning and development tool. It's ideal for trying out FHIR queries, developing FHIR-based microservices, or serving as a bridge between old and new systems. For example, a clinic could use HAPI FHIR to aggregate data from various HL7 v2 feeds into one FHIR-compliant data repository, which then a modern web app can use. Many FHIR tutorial sandboxes online are actually powered by HAPI FHIR under the hood. If you're diving into interoperability, it's worth getting acquainted with HAPI FHIR – you can be up and running in minutes, and it's free.

Why Should You Learn FHIR and HL7?

If you're a new developer in clinical IT or a clinician moving into the tech side, you might ask: "Which one should I focus on, HL7 or FHIR?" The honest answer in 2025 is both. Here's why:

Industry demand and job growth: Healthcare organizations are crying out for people who understand interoperability. Jobs like "HL7 Interface Analyst," "Interoperability Engineer," or "FHIR Developer" are increasingly common. In fact, many job listings now explicitly ask for FHIR experience alongside traditional HL7 knowledge. This isn't surprising – a recent HIMSS report found that 78% of healthcare providers using FHIR saw faster care coordination (better data flow between systems)[18], so employers want those skills on board. At the same time, since so many existing systems run on HL7 v2, employers also need people who can maintain and integrate those. If you only know one standard, you're limiting yourself. Being fluent in both is like being bilingual in a region that speaks two languages – it makes you far more versatile and valuable.

Future-proofing your career: The direction is clear: FHIR is the future-facing standard, but HL7 v2 (and related standards like CDA) will stick around for years to come. Gartner research predicts that by 2025, 75% of healthcare organizations will require full interoperability (like FHIR-based APIs) for new technology purchases[19]. That means new projects will likely involve FHIR. But those same organizations have legacy systems generating thousands of HL7 messages per hour. The most successful healthcare IT professionals will be those who can connect the old and the new – for example, implementing a FHIR-based patient portal that still pulls data from an HL7 v2 interface engine in the backend.

Understanding the context: Learning both standards actually helps you understand each better. By seeing the constraints of HL7 v2, you appreciate why FHIR was designed as it was. And by learning FHIR's model, you can more easily map old data into the new formats. This holistic understanding makes you a better problem solver when tackling integration challenges. You'll know when to use the lighter touch of an HL7 message versus when to deploy a full FHIR API solution.

Opportunities for innovation: Knowing FHIR opens up a world of modern health tech innovation – building patient-facing apps, analytics pipelines, AI on top of standardized data, etc. Knowing HL7 v2 gives you insight into the vast troves of data locked in older systems and how to unlock them. For instance, you might innovate a solution that listens to HL7 ADT messages to trigger real-time updates in a FHIR care coordination app. There are numerous initiatives (HIMSS hackathons, government interoperability challenges, HL7 FHIR connectathons) where having both skill sets will let you shine. As interoperability standards continue to evolve (for example, with FHIR expanding and new profiles being added), having the strong foundation of both HL7 and FHIR will enable you to adapt quickly.

Conclusion

Healthcare's interoperability journey is a marathon, not a sprint. HL7 v2 and FHIR might seem like competitors, but in reality they are teammates addressing a complex landscape. HL7 v2, with its decades of use, ensures that critical data keeps flowing within and between healthcare institutions reliably (even if imperfectly). FHIR, as the rising star, promises a more open, accessible, and innovative future for health data exchange. Rather than betting on one standard to conquer all, smart healthcare organizations leverage each where it fits best – and they need professionals who understand both.

For beginners in health IT, mastering HL7 v2 gives you insight into the legacy systems that still power the day-to-day operations in healthcare, while mastering FHIR positions you at the forefront of the industry's future. It's not an either/or choice. As you build your career, you'll find that projects often require bridging between the two: converting messages, synchronizing data, or gradually replacing old interfaces with new APIs. By learning both, you make yourself future-proof – ready to work with today's systems and tomorrow's innovations.

At Nexira Health IT, we believe in empowering the next generation of health IT professionals with the full toolkit for interoperability. Follow us for more insights and hands-on tutorials (yes, we'll be digging into FHIR and even some HL7 v2 message parsing in upcoming posts!). Understanding these standards isn't just about getting a job – it's about contributing to a healthcare system where data flows smoothly, patients get better care, and innovators can build the next great digital health solution. So, keep learning HL7 and FHIR, and you'll be riding the wave of healthcare's digital transformation.

Tags: Healthcare IT, FHIR, HL7, Digital Health, Interoperability