HL7 v2 vs FHIR: When You Still Need the Old Standard

If you're scoping a healthcare integration, you'll hear "HL7" and "FHIR" used as if they're competitors or interchangeable. They're neither. HL7 v2 and FHIR are both standards from HL7 International, they overlap in what they can carry, and in most real hospitals they run side by side. Choosing between them — or knowing when you need both — comes down to what systems you're connecting and how.

What HL7 v2 actually is

HL7 v2 is the messaging standard that quietly runs most of healthcare integration today. It defines pipe-delimited messages — segments like MSH, PID, and OBX separated by | characters — that one system sends to another when an event happens: a patient is admitted (ADT), a lab result is ready (ORU), an order is placed (ORM). Messages typically travel over MLLP through an interface engine that routes and transforms them between systems.

It's decades old, extremely widely deployed, and not going anywhere. If you're integrating with an existing hospital system — a LIS, RIS, or legacy EHR — there's a very good chance the interface it exposes is HL7 v2.

What FHIR actually is

FHIR (Fast Healthcare Interoperability Resources) is the modern, web-native standard. Instead of event messages, it models data as resources — Patient, Observation, Encounter, MedicationRequest, ImagingStudy — exchanged as JSON (or XML) over a RESTful API. You GET /Patient/123 or POST an Observation, using ordinary HTTP.

That makes FHIR far easier to build against with modern tooling, mobile apps, and cloud services, and it's the direction regulators are pushing (for example, US rules increasingly require FHIR-based patient-access APIs). It's the right default for new, app-facing, or patient-facing work.

HL7 v2 vs FHIR at a glance

	HL7 v2	FHIR
Shape	Pipe-delimited messages	JSON/XML resources
Transport	MLLP / interface engine	REST over HTTPS
Style	Event-driven push	Request/response (and subscriptions)
Best for	Existing hospital interfaces	New apps, mobile, patient access
Maturity	Ubiquitous, decades deep	Modern, rapidly adopted

When do you still need HL7 v2?

Reach for HL7 v2 (or accept that you'll be consuming it) when:

• You're integrating with an existing system that only exposes a v2 interface.
• You need real-time event feeds — ADT and results messages — that hospitals already emit.
• The counterparty's interface engine and workflows are built around v2 and won't change for your project.

Reach for FHIR when:

• You're building a new API, a mobile or web app, or a patient-facing feature.
• You need clean, resource-oriented access to specific data on demand.
• You're meeting a regulatory requirement that specifies FHIR.

How they work together

The most common real-world pattern isn't "one or the other" — it's a bridge. An interface engine ingests HL7 v2 messages from existing systems and a FHIR façade exposes that data as resources to modern apps. Your new product talks clean FHIR; the hospital keeps emitting the v2 it always has; a mapping layer translates between them. Getting that mapping right — codes, identifiers, and edge cases — is where integration projects succeed or quietly break.

What to ask before you commit

• Which standard (and version) does each system on both sides actually speak?
• Is there an interface engine already in place, and who owns it?
• Do you need event-driven feeds, on-demand queries, or both?
• How are patient identifiers and terminologies (LOINC, SNOMED, ICD) reconciled across systems?

How we approach it

At Influrion, healthcare interoperability — HL7 v2, FHIR, and the DICOM/PACS imaging side — is our deepest specialization. We treat the standard as an implementation detail in service of the workflow: we map what your systems already speak, bridge v2 and FHIR where it makes sense, and build to the technical safeguards HIPAA and GDPR require from day one. If you're planning an integration and aren't sure which standard you need, tell us what you're connecting and we'll help you scope it.