NEMT Entrepreneur provides expert insights, strategies, and resources to help non-emergency medical transportation professionals grow their businesses. Get industry-leading advice to succeed in NEMT.
Featured articles
If I had to sum it up in one line: HL7 v2 sends the alert, and FHIR gets the details.
If you work in NEMT, that split matters fast. A hospital discharge can trigger a same-day ride, but booking-dispatch integration also needs patient info like pickup location, mobility needs, and coverage data. The article’s main point is simple: HL7 v2 and FHIR are not direct replacements for each other. In many cases, you need both.
Here’s the short version:
- HL7 v2 is an older message standard used by many U.S. hospitals for event feeds like admissions, transfers, and discharges.
- FHIR is an API standard that lets systems request data on demand using web tools like JSON, HTTPS, and OAuth 2.0.
- HL7 v2 works best for triggers such as an ADT discharge alert.
- FHIR works best for structured follow-up data such as patient demographics, coverage, encounter data, and transport orders.
- HL7 v2 still handles about 85% of real-time clinical traffic in U.S. hospitals as of 2026.
- FHIR R4 APIs are required in certified EHRs under U.S. rules, so hospital and HIE connections now often involve both standards.
- If a NEMT company builds around only one side, teams can still end up with manual entry, missed updates, and claim issues.
HL7 v2 vs. FHIR R4: Healthcare Data Standards Compared
HL7 vs FHIR: What’s the Difference? (Full Comparison)
sbb-itb-cef70f4
Quick Comparison
| Criteria | HL7 v2 | FHIR R4 |
|---|---|---|
| Main job | Sends event messages | Shares data through APIs |
| Common use | ADT alerts, lab and order feeds | Patient, coverage, encounter, and order lookup |
| Data format | Pipe-delimited text | JSON, XML, RDF |
| Transport | TCP/MLLP | HTTPS/REST |
| Data flow | Push | Pull, plus subscriptions in some setups |
| Query support | No standard query method | REST search with parameters |
| Security model | Outside layers like VPN/TLS wrappers | OAuth 2.0 and SMART on FHIR |
| Best NEMT use | Triggering rides after discharge | Pulling trip details and patient context |
The bottom line: if your partner only offers legacy interfaces, I’d use HL7 v2. If they offer EHR APIs, I’d use FHIR R4 for structured record access. If both are available, I’d use a hybrid setup - HL7 v2 for the trigger, FHIR for the follow-up data.
That’s the core takeaway from the article, and it frames the rest of the discussion.
HL7 v2 basics: message-based data exchange still common in hospitals
HL7 v2 is still the default event-feed standard in many hospitals, especially for admission, transfer, and discharge alerts. It was built to send patient events automatically, with no manual step in the middle. That matters when a discharge alert needs to kick off a same-day pickup. This event-driven setup made HL7 v2 a good fit for hospitals trying to keep many internal systems aligned.
HL7 v2 still carries most real-time clinical traffic in U.S. hospitals and stays deeply built into core workflows. To see why it remains so common, it helps to look at the message format itself.
How HL7 v2 messages are structured
An HL7 v2 message is plain text made up of segments separated by carriage returns. Each segment begins with a three-letter code that tells you what kind of data it contains. The MSH segment is the message header. It identifies the sender, receiver, and message type. The PID segment holds patient demographics such as name, date of birth, and medical record number. Inside each segment, fields are split by pipe characters (|), and subfields are split by carets (^).
HL7 v2 messages are compact and fast to send, which makes them a strong fit for high-volume event feeds such as ADT messages that trigger ride actions on admission, transfer, or discharge. For example, an ADT A03 signals a discharge.
Where HL7 v2 works well and where it falls short
HL7 v2 does a good job pushing structured updates the moment a clinical event happens. For real-time discharge alerts, lab results, and order notices, it is fast, reliable, and widely supported.
But there are trade-offs. The standard was made to be flexible, and that helped it spread fast. At the same time, that flexibility led to variation from one site to another. Hospitals often add Z-segments - custom data fields not defined in the official standard - so almost every interface needs custom mapping. What works at one hospital may break at the next.
Transport is another pain point. Most HL7 v2 messages move over MLLP (Minimum Lower Layer Protocol), a TCP/IP-based protocol with no built-in encryption or authentication. So outside security layers are often required, such as a VPN or TLS wrapper, to meet HIPAA rules. And unlike FHIR, HL7 v2 does not include a standard query mechanism. Connected systems can receive events, but they cannot request specific data on demand.
For NEMT providers, that creates a gap. HL7 v2 can tell them that something changed, but it cannot always provide the full record they need right when they need it. That gap is what pushed the move toward FHIR's resource-and-API model.
FHIR basics: web APIs and resource-based interoperability
FHIR (Fast Healthcare Interoperability Resources) is HL7’s API-based standard for healthcare data exchange, built on HTTP, JSON, and REST. In plain English, it lets web developers work with healthcare data using tools they already know. That’s a big shift from older HL7 patterns, and it makes FHIR a better fit for on-demand record retrieval instead of event-only messaging.
How FHIR resources and APIs work
FHIR breaks patient data into modular building blocks called resources. Each resource stands for one type of clinical or administrative data. For example, Patient covers demographics, Encounter covers a visit, Observation covers a lab result or vital sign, and ServiceRequest covers an order, including a transport order.
These resources can be queried, updated, and linked through URLs. Apps can query, create, and update them through standard API calls. For NEMT, the ServiceRequest resource matters a lot because it can represent a transport order with structured fields for pickup and drop-off locations, requested times, and patient mobility needs.
FHIR usually uses JSON, which is much easier for web developers to handle than HL7 v2 messages. For NEMT, that means transport orders are simpler to request and track across systems.
FHIR adoption, benefits, and current limits
FHIR adoption is growing because U.S. rules now require FHIR R4 support in certified health IT and FHIR-based prior authorization APIs for payers. FHIR also handles security through OAuth 2.0 and the SMART on FHIR framework. That setup allows scope-based access control, so an app can get read-only access to one patient’s observations without touching anything else.
Still, FHIR has limits that matter in practice. Epic, Oracle Health, and athenahealth expose FHIR in different ways, so one connector usually doesn’t work everywhere. Real deployments also mean following complex Implementation Guides (IGs), such as US Core or Da Vinci. These guides add much more detail, but they also add complexity. The standard defines the data. Implementation Guides define the required profile. Those differences shape the real HL7-vs.-FHIR trade-offs in HIE integration.
HL7 vs. FHIR: key differences for HIE integration and NEMT workflows
The main gap between HL7 v2 and FHIR comes down to one thing: HL7 v2 is event-driven, while FHIR supports request/response access and, in some setups, subscriptions. That difference affects how teams build integrations and how fast a NEMT dispatcher learns that a patient is ready for pickup.
| Aspect | HL7 v2 | FHIR R4 |
|---|---|---|
| Data Model | Message-centric (segments/fields) | Resource-centric (modular resources) |
| Format | Pipe-delimited text | JSON, XML, RDF |
| Transport | TCP/MLLP | HTTPS/REST (web APIs) |
| Paradigm | Event-driven "push" | Request/response "pull" + subscriptions |
| Querying | None; you wait for the feed | REST search with parameters |
| Security | Network-level controls such as VPN/TLS wrappers | Native OAuth 2.0 / SMART on FHIR |
For NEMT, the big question is straightforward: which standard sends the trigger, and which one supplies the details?
Data structure, transport, and developer workflow
HL7 v2 sends flat, pipe-delimited text segments over MLLP (Minimum Lower Layer Protocol), a TCP-based channel built for hospital networks. It's fast and lightweight. A typical ADT message is only 1–10 KB, which makes HL7 v2 a strong fit for high-volume feeds. The tradeoff is that it often needs specialized interface engines and custom mapping at each site. And there is no built-in query feature. You get what the hospital sends, when it sends it.
FHIR runs over HTTPS with standard REST calls and JSON. For web developers, that feels much more familiar. They can use the same REST and JSON tools they already know. That lowers the barrier to entry, although Implementation Guides and EHR-specific differences still need close attention.
Best-fit use cases: event feeds vs. on-demand records access
HL7 v2 stands out for real-time event triggers. When a hospital finalizes a discharge order, an ADT message fires right away. That immediate signal is exactly what NEMT dispatch needs to simplify scheduling to cut patient wait times. No polling. No manual dispatch and scheduling checks. The event sends the notice out on its own.
FHIR is better for structured, on-demand data retrieval. After a discharge trigger comes in, FHIR lets a NEMT platform request the exact details it needs: mobility requirements, insurance coverage, pickup location, and prior authorization status. That's the kind of context HL7 v2 does not handle cleanly by itself.
| Feature | HL7 v2 (Event Feeds) | FHIR (On-Demand Access) |
|---|---|---|
| Deployment complexity | High - requires interface engines and custom mapping | Moderate - uses standard web tools, but Implementation Guides add complexity |
| Data granularity | Full message segments (for example, PID and PV1); no selective retrieval | Selective resource queries, such as coverage or encounter details |
| Hospital compatibility | Universal in hospitals | Growing - mandated for payers and certified EHRs, not yet universal |
| Developer effort | High - requires specialized interface and parsing knowledge | Moderate - uses familiar web skills |
| NEMT business value | Triggers rides the moment a patient is cleared | Delivers mobility and insurance details automatically |
Why many organizations use both standards together
Most U.S. health systems are layering FHIR on top of existing HL7 v2 infrastructure instead of replacing it outright. One common setup, sometimes called a "FHIR Facade," adds a middleware translation layer between the legacy HL7 v2 backend and modern API consumers. Inside the hospital, systems keep sending pipe-delimited messages. Outside the hospital, apps - including NEMT platforms - get clean FHIR resources without forcing the hospital to rebuild its stack.
For NEMT, this hybrid model is often the most practical path. HL7 v2 ADT messages handle the trigger that a patient has been discharged. FHIR ServiceRequest, Patient, and Coverage resources then carry the extra context needed to send the right vehicle for that patient's needs.
"The EHR knows the patient is ready to move. The dispatch system doesn't, because nothing connects the two. Most of what is slow, error-prone, and expensive about NEMT traces back to that missing connection." - Arun Badole, VP of Engineering, Mindbowser
That hybrid pattern often decides whether a NEMT business should use HL7, FHIR, or both.
Choosing the right approach and next steps for NEMT businesses
When to choose HL7, FHIR, or a hybrid integration model
Once you understand the difference between HL7 and FHIR, the next move is pretty simple: pick the interface your partner already supports.
Start by asking your hospital or HIE partner what they have in place. If they support only legacy interfaces, HL7 v2 is the practical option. It works well for event feeds like discharge notifications. If they offer modern EHR APIs, go with FHIR R4 for structured data like demographics, coverage, and transport orders. For many NEMT workflows, the best setup is a mix of both: HL7 v2 for the trigger, FHIR for the details.
Here’s a simple way to choose your starting point:
| Situation | Recommended Approach |
|---|---|
| Hospital exposes only legacy interfaces | HL7 v2 - required for discharge triggers (ADT) |
| Hospital offers modern EHR APIs | FHIR R4 - for patient demographics, coverage, and transport orders |
| Both interfaces available | Hybrid - HL7 v2 for event triggers, FHIR for structured data retrieval |
Planning integration work without disrupting operations
After you choose the standard, keep the first rollout narrow. Start with one EHR connection and one discharge-to-request flow. That keeps the work easier to test and less likely to disrupt day-to-day operations.
If you're moving from v2 to FHIR, a smart first step is a FHIR read layer populated from v2 feeds before you shift into write operations. Also, handle the BAA and security review early. Those steps can take 30 to 180 days, and they often slow projects down more than teams expect.
Start with one discharge-to-request flow. Expand only after it runs cleanly.
Key takeaways for NEMT leaders
HL7 v2 still carries about 85% of real-time clinical traffic in U.S. hospitals as of 2026, so it's not disappearing anytime soon. FHIR is the standard used for modern app development, on-demand data queries, and compliance-driven workflows.
For most NEMT businesses, this isn’t an either-or call. HL7 v2 handles triggers. FHIR handles data access. In practice, most NEMT teams need both. NEMT Entrepreneur aka NEMTreprenuer offers practical NEMT guidance for teams planning interoperability work.
FAQs
Do I need both HL7 v2 and FHIR?
Yes. Most healthcare settings still need both HL7 v2 and FHIR.
HL7 v2 is still the go-to format for real-time, asynchronous messaging, especially for things like ADT notifications. It’s deeply built into hospital systems, so it’s not going away anytime soon.
FHIR, on the other hand, is usually the top pick for new projects, query-based data access, and external APIs. It works well when systems need to request specific data, not just receive message updates.
That’s why many organizations support both at the same time. A common setup is to use integration middleware as the bridge: keep HL7 v2 in place for legacy compatibility and clinical messaging, while using FHIR for new integrations.
Can FHIR replace HL7 v2 today?
No. FHIR does not fully replace HL7 v2 today.
FHIR is the newer standard for APIs, patient access, and payer-provider workflows. But HL7 v2 still runs much of the real-time clinical messaging used every day, especially admissions, discharges, and transfers.
That’s why most production environments use both. In practice, a hybrid setup is often the way things work.
How do I choose between HL7 v2, FHIR, and a hybrid setup?
Choose based on the workflow, not as an either-or call. HL7 v2 works best for real-time, event-driven traffic such as ADT messages and lab results. FHIR works best for modern API-based workflows, including patient-facing apps, portals, compliance needs, and on-demand data queries.
A hybrid setup often makes the most sense. It uses an integration engine to keep steady HL7 routes in place for core operations while translating selected data into FHIR resources.
Start with what your EHR and peer systems can support, then use the standard they already handle.
