HL7 Integration Services: What You're Actually Paying For

A CTO told us, with total confidence, that HL7 wasn't his problem. His platform was FHIR-native. Modern REST APIs, JSON, the works. He'd built it that way specifically to avoid the old stuff.

Two weeks later the hospital's integration team sent over their spec. An ADT feed. HL7 version 2. Pipe-delimited messages over MLLP, which is a transport protocol most developers have never heard of because nothing outside healthcare uses it.

He wasn't wrong about his platform. He was wrong about the hospital, and the hospital was the one with the signature he needed.

Must Read: EHR Integration: What Founders Need to Know Before You Build

First, "HL7" means three different things

Half the confusion here is vocabulary, so let's clear it before anything else.

HL7 is an organization. Health Level Seven International, founded in 1987, the group that writes healthcare data standards. When someone says "we're HL7 certified," this is usually what they're gesturing at, and it usually means less than they think.

HL7 v2 is a message format from 1989. Text, pipe-delimited, segment-based. It is what most hospitals actually use to move data around, today, in 2026.

FHIR is also an HL7 standard. Newer, REST-based, JSON, the thing everyone talks about at conferences. When people say "HL7 versus FHIR," they're comparing two products from the same company.

So when a hospital says "we'll send you an HL7 feed," they almost always mean v2. And v2 is a different animal from the API work your team has done before.

Why a format from 1989 refuses to die

The obvious question: if FHIR is better, why is anyone still sending pipe-delimited text files?

Because the v2 interfaces already work.

A large hospital might be running hundreds of live interfaces. Lab systems, radiology, pharmacy, billing, scheduling, bed management. Each one was built, tested, validated, and signed off, sometimes a decade ago. Each one moves real patient data that clinicians depend on at 3am.

Nobody gets promoted for replacing an interface that works. They get fired for breaking one.

So v2 stays. FHIR gets added alongside it for new use cases, especially patient-facing ones, and the two coexist. Most real integration projects touch both. If your architecture assumed one or the other, that assumption is where your timeline starts slipping.

The part that actually costs money

Here's the thing that surprises people: HL7 v2 is a standard the way a dress code is a standard.

The specification defines segments, and every message starts with MSH, the header. PID carries patient identification. OBX carries an observation result. Fine so far.

But large parts of the spec are optional. Fields can be used differently by different vendors. And v2 explicitly allows custom segments, called Z-segments, where a site can define its own fields for whatever the standard didn't cover. Hospitals use them constantly.

There's a saying in health IT that gets repeated because it keeps being true: if you've seen one HL7 interface, you've seen one HL7 interface.

Two hospitals both running the same EHR, both sending "standard" ADT messages, can send you data that requires different mapping. The patient's ID might be in a different field. A date format might differ. One site stuffs something important into a Z-segment nobody documented.

This is why HL7 integration is priced as project work rather than a plug-in. You're not implementing a spec. You're reverse-engineering one site's interpretation of a spec, then doing it again at the next site.

So what are you actually buying

When a partner quotes HL7 integration services, the work usually breaks into five pieces. Worth knowing which ones are in your quote.

Interface analysis comes first. Someone reads the hospital's interface specification, gets sample messages, and works out what's actually in them versus what the documentation claims. Skipping this is how projects discover in week nine that a required field arrives empty.

Most of the engineering hours then go into message mapping: translating their message structure into your data model, field by field, including the undocumented ones.

Transport and connection setup handles the plumbing. MLLP over TCP, VPN tunnels, firewall rules, certificates. This part is rarely hard, but it involves the hospital's network team, and their calendar is not your calendar.

Error handling and acknowledgements is the piece that separates people who've done this before from people who haven't. HL7 messages expect ACK responses. Messages fail. Systems go down mid-transmission. You need to know what happens to a lab result that arrives while your service is restarting, and the honest answer has to be better than "we'll look into it."

The last piece is testing and validation. Test environment, sample data, then parallel running against live data before anyone trusts it.

If a quote covers mapping and transport but goes quiet on error handling and validation, the project didn't get cheaper. Two phases just moved to an invoice you haven't seen yet.

The interface engine question

At some point someone will ask whether you need an interface engine. These are tools built for exactly this work: Mirth Connect, Rhapsody, Corepoint, Iguana, Cloverleaf.

Rough guidance. One or two simple interfaces, you can reasonably write the handling yourself. Several interfaces, multiple sites, or messages that need routing and transformation between systems, an engine pays for itself quickly in monitoring and error visibility alone.

The mistake is buying the engine first and figuring out the interfaces later. The engine doesn't do the mapping. It gives you a better place to do it.

What moves the number

Effort varies enormously by scope, so treat these as shapes rather than quotes:

| What you're connecting | Typical effort | | --- | --- | | One-way ADT feed (admits, discharges, transfers) | 2 to 4 weeks | | Inbound lab results (ORU) | 3 to 5 weeks | | Bidirectional orders and results (ORM plus ORU) | 6 to 10 weeks | | Several message types across multiple sites | 3 to 6 months |

Two things bend these numbers more than anything technical.

The first is site count. Each additional hospital means new mapping, new testing, new sign-off. Five sites is not five times one site, but it isn't close to one site either.

The second is waiting. Access approvals, network changes, test environments, a clinical stakeholder who's only free on Thursdays. On most projects we've run, the engineering was never the long pole. Scheduling was. You can compress engineering by adding people. You cannot compress a hospital's change control board.

Questions worth asking before anyone quotes

A partner who has done this will bring most of these up first. If they don't, that tells you something.

Which sites, and which systems at each one? Not "the hospital." The named system, and the version.

Which message types, and which direction? Inbound only is a different project from bidirectional, and bidirectional means you're writing into their clinical system.

Can we see real sample messages before you quote? This is the one that matters most. Anyone quoting off the specification alone is quoting a guess.

Who owns the connection and the network changes on their side, and what's the realistic turnaround?

What happens when a message fails at 2am? If the answer isn't specific, there is no answer yet.

The short version

HL7 v2 is a message format older than the web, still running the backbone of most hospital data, and it will outlive several more predictions of its death. FHIR is real and growing, but it hasn't replaced v2 and won't for years, so plan for both.

The cost lives in the gaps between sites. Every hospital reads the standard slightly differently, which quietly turns "one integration" into a run of small projects that are never quite the same twice. Get sample messages early, scope per site rather than per feed, and budget for waiting as seriously as you budget for engineering.

Working out what your integration actually involves? Tell us what you're working on and we'll give you a straight read on scope and timeline. No pitch.

Must Read: EMR vs EHR: The Two Acronyms Quietly Confusing Your Healthcare Build