James Allman / JA Technology Solutions LLC
2026-04-13
HL7 vs FHIR: What You Need to Know
A practical guide to healthcare data exchange standards — what works, what's changing, and how to make smart integration decisions.
The Healthcare Data Exchange Problem
Healthcare runs on data exchange. Every time a patient is admitted, a lab result is filed, a prescription is written, or a referral is sent, information needs to move between systems. The problem is that healthcare organizations rarely run a single system. Hospitals, clinics, labs, pharmacies, payers, and public health agencies all operate their own platforms, built by different vendors, on different technology stacks, across different decades.
Without agreed-upon standards, every connection between two systems becomes a custom project. Two standards dominate the conversation today: HL7 v2.x, the workhorse that has powered healthcare integration for over 30 years, and FHIR (Fast Healthcare Interoperability Resources), the modern standard designed to bring healthcare data exchange into the era of web APIs.
HL7 v2.x: The Standard That Built Healthcare Integration
HL7 version 2 was first published in 1987 and has gone through several revisions, with v2.3, v2.5, and v2.5.1 being the most widely deployed. It uses a pipe-delimited text format organized into segments, each identified by a three-character code. An ADT message starts with an MSH segment containing message metadata, followed by a PID segment with patient demographics, a PV1 segment with visit information, and so on.
The message types are well-defined for common healthcare workflows. ADT messages handle patient movement. ORM and OML messages manage orders. ORU messages carry results. Each message type has a defined set of segments and fields, and the standard specifies which are required, optional, and repeating.
HL7 v2.x messages are typically exchanged point-to-point over TCP connections using the MLLP (Minimal Lower Layer Protocol) transport. An integration engine usually sits in the middle, receiving messages from source systems, transforming them as needed, and routing them to destination systems.
Why HL7 v2.x Is Everywhere
HL7 v2.x is the most widely implemented healthcare integration standard in the world. Virtually every EHR, lab system, radiology system, pharmacy system, and hospital information system supports it. Billions of messages are exchanged every day across tens of thousands of healthcare organizations.
The reason is straightforward: it works. Over three decades, organizations have built, tested, and refined their HL7 v2.x interfaces. Those interfaces represent significant institutional investment — not just in technology, but in the business rules, exception handling, and operational knowledge embedded in them.
There is also a practical momentum effect. When a new system needs to connect to an existing ecosystem, HL7 v2.x is almost always the path of least resistance. The sending system supports it. The receiving system supports it. The integration engine knows how to handle it.
Where HL7 v2.x Falls Short
For all its success, HL7 v2.x has real limitations. The standard is loose by design. Many fields are optional, data types are flexible, and the specification leaves room for interpretation. Two systems claiming to send the same message type can produce messages that look quite different in practice.
Z-segments compound the problem. The standard allows organizations to define custom segments prefixed with "Z" for data that does not fit the standard structure. In practice, Z-segments are everywhere, carrying critical data but requiring custom mapping on every new interface.
The pipe-delimited format is not self-describing. Without the specification document, a raw HL7 v2.x message is difficult to interpret. Modern developers accustomed to JSON or XML find the format unintuitive.
Transport is another gap. MLLP over TCP provides no built-in security, authentication, or message queuing. Organizations have layered VPNs and TLS on top, but none of that is part of the standard.
FHIR: A Modern Approach to Healthcare Data
FHIR, reaching its first normative release (R4) in 2019, takes a fundamentally different approach. Instead of message-oriented exchange, FHIR is built around resources — discrete, well-defined data objects like Patient, Observation, MedicationRequest, Encounter, and Condition. Each resource has a defined structure with required and optional fields, clear data types, and built-in terminology bindings.
FHIR resources are represented in JSON or XML. Exchange happens over RESTful HTTP APIs using standard verbs: GET to read, POST to create, PUT to update, DELETE to remove. Search parameters are defined per resource type.
The resource model is granular by design. Rather than packaging everything into a large message, FHIR lets you request exactly the data you need. A mobile app showing a medication list can fetch just MedicationRequest resources. This granularity maps well to how modern applications consume data.
What FHIR Gets Right
FHIR's greatest strength is accessibility. A developer who has built REST APIs in any domain can pick up the FHIR specification and start building within hours. JSON is readable, parseable by every programming language, and supported by every API testing tool.
The SMART on FHIR authorization framework gives FHIR a real security model — OAuth 2.0-based app launch and authorization absent from the v2.x world. This is what makes patient-facing apps possible.
FHIR also benefits from strong regulatory tailwinds. The 21st Century Cures Act and ONC information blocking rules require healthcare organizations to make patient data available through standardized APIs. FHIR R4 is the designated standard.
The ecosystem is maturing rapidly. Major EHR vendors — Epic, Cerner (now Oracle Health), MEDITECH — all expose FHIR APIs. Cloud platforms from Microsoft, Google, and AWS offer FHIR-native data stores.
Where FHIR Still Has Gaps
FHIR is not a finished product. While the core resources are normative and stable, many resources remain at lower maturity levels. Workflow patterns for complex clinical processes are still evolving.
Adoption is uneven. FHIR APIs are widely available for patient access use cases, driven by regulation. But for system-to-system clinical workflows, HL7 v2.x still dominates. Many FHIR implementations today are read-only APIs layered on top of systems whose internal integration still runs on v2.x messages.
Performance is a practical consideration. HL7 v2.x over MLLP is lightweight and high-throughput. FHIR's RESTful model adds HTTP overhead, and querying large datasets through paginated API calls is slower than receiving batch messages over a persistent TCP connection.
There is also implementation variability. Vendors expose different subsets of resources. Extensions create custom mapping work similar to Z-segments in v2.x. The standard is more consistent than v2.x, but it is not plug-and-play.
When to Use Which
The choice between HL7 v2.x and FHIR is practical, not ideological. For existing ADT feeds, lab result interfaces, and order workflows already running on v2.x, there is rarely a compelling reason to rewrite them.
FHIR is the right choice for new patient-facing applications, third-party app integrations, payer interoperability, and any scenario where regulatory mandates require standardized API access.
For new system-to-system integrations, the answer depends on context. If both systems have mature FHIR support for the relevant resources, FHIR may make sense. If one or both primarily support v2.x for that workflow, v2.x is likely the more pragmatic choice.
Migration Is Not Replacement
One of the most common misconceptions is that FHIR replaces HL7 v2.x. It does not. You do not rip out working v2.x interfaces and rebuild them in FHIR.
The practical migration path is additive. You continue to operate existing v2.x interfaces. When new requirements arise — a patient access API, a payer data exchange — you build those on FHIR. Over time, some workflows may naturally migrate. But it happens incrementally, driven by real requirements.
A well-designed integration architecture supports both standards. Your integration engine should be able to receive v2.x messages while also exposing that same data through a FHIR API. The two standards coexist, often for years, and that coexistence is a feature.
Tools for Working with Both Standards
Working with healthcare data standards is easier with the right tools. The free HL7 Explorer parses HL7 v2.x messages into segments and fields with human-readable labels. The FHIR Explorer does the same for FHIR JSON resources with structured, navigable views and field descriptions. Both tools run entirely in your browser with no data sent to any server.
When to Bring in Help
Healthcare integration is a specialized discipline. The standards are complex, the implementations vary, and the stakes — patient safety, regulatory compliance, operational continuity — are high.
I have spent over 35 years building enterprise integrations, including healthcare data exchange systems that handle HL7 v2.x and FHIR across multiple platforms. If you are facing a healthcare integration challenge, reach out — I am happy to discuss your situation and see how I can help.