HL7 v2 to FHIR: What Actually Changes When You Leave BizTalk

There is a version of the healthcare integration conversation that goes: BizTalk is ending, FHIR is the future, so we migrate from HL7 v2 to FHIR and modernise in one move.

It is a tidy story and it is wrong in a way that costs projects real time. HL7 v2 is not going anywhere. Your ADT feed from the EHR, your lab results from the LIS, your radiology orders — these are v2 over MLLP, and the vendors on the other end have no plan to change that inside your migration window.

The realistic end state is both standards, running side by side, for years. Planning for that from the start is the difference between a healthcare migration that lands and one that discovers in month five that the “FHIR modernisation” still needs a v2 interface engine underneath it.

Here is what actually changes.

MLLP is the first real problem

HL7 v2 travels over Minimal Lower Layer Protocol: a raw TCP socket with start and end block characters framing each message. It is not HTTP. It has no native cloud connector.

BizTalk handled this with an MLLP adapter, and if you have the BizTalk Accelerator for HL7 you also had party configuration, acknowledgement handling, and batching built in.

Azure has no managed MLLP listener. Your options:

• A containerised MLLP listener — Azure Container Apps or AKS terminating the socket, validating framing, and handing the message onward to Service Bus or a Function. Most common, and you own it.
• An on-premises listener bridging to Azure — often necessary anyway, because the clinical systems sending you v2 usually live inside the hospital network and are not going to open a socket to the internet.
• A third-party or purpose-built interface engine that provides MLLP as a managed capability.

Whichever you choose, note the constraint that surprises cloud-first teams: a TCP listener needs a stable, reachable, low-latency network path from clinical systems. That frequently means a hybrid topology, and it should be in the architecture from week one rather than discovered during build.

ACK semantics are stricter than most people remember

An HL7 v2 sender expects an acknowledgement on the same connection, typically within seconds. Miss the window and the sending system’s behaviour ranges from retry, to queue-and-alarm, to — in older interfaces — dropping the message and logging an error nobody reads.

Two distinctions matter:

Original versus enhanced acknowledgement mode. In original mode, the ACK means “processed.” In enhanced mode, an initial commit-level ACK means “received” and an application-level ACK follows. If BizTalk was doing enhanced mode with a particular sender and the new platform does original mode, you have changed the contract with a clinical system.

AA, AE, and AR are semantically different. Application Accept, Application Error, and Application Reject drive different behaviour on the sending side. A new platform that returns AA for everything it successfully received — rather than successfully processed — has quietly converted downstream failures into silent data loss.

Export the ACK mode and expected latency per interface from the existing configuration and treat it as an acceptance test. This is the healthcare equivalent of the EDI control-number trap: small, easy to skip, expensive to miss.

Z-segments are where your local knowledge lives

Every real HL7 v2 deployment has custom Z-segments, and every one carries something the standard does not accommodate — a local patient identifier, a consent flag, a departmental code that a downstream system branches on.

They are almost never documented, and they will not appear in a schema-driven rebuild. Grep the existing maps and custom components for Z segment handling and produce a list with, for each one, the answer to: which downstream system reads this, and what happens if it is absent?

Some of those answers will be “nothing, it has been dead since 2019.” Good — that is scope you just removed. The others are requirements.

Where FHIR genuinely fits

None of the above is an argument against FHIR. FHIR is materially better for a specific set of use cases, and if you are migrating anyway it is the right time to add it:

• Patient and provider record access — a RESTful Patient or Practitioner read is dramatically easier to consume than parsing an ADT feed.
• App and portal integration — SMART on FHIR is the actual ecosystem for patient-facing and clinician-facing apps.
• Regulatory interoperability — US interoperability requirements are expressed in FHIR, and that direction of travel is settled.
• Analytics and downstream data platforms — a resource model is a far better source for a data platform than a stream of pipe-delimited messages.

Azure Health Data Services provides a managed FHIR service plus a v2-to-FHIR conversion capability, which is the piece that makes coexistence practical: keep ingesting v2 over MLLP, persist to FHIR, and let modern consumers read resources while legacy senders keep sending exactly what they always sent.

The mapping is lossy in both directions

Worth being blunt about, because it shapes expectations.

v2 to FHIR is not a field rename. An ADT^A01 becomes several FHIR resources — Patient, Encounter, Location, possibly Coverage — with references between them. Which means:

• Identity resolution becomes explicit. v2 carries identifiers in PID segments and lets each consumer figure it out. FHIR needs actual resource references, so you must decide how to resolve a patient to a single Patient resource. This is a data-governance decision masquerading as a mapping task, and it is where these projects lose the most time.
• Some v2 content has no FHIR home. Z-segments, local codes, and free-text fields end up in extensions — which is legitimate FHIR, and also means any consumer must understand your extensions.
• Ordering and grouping semantics differ. v2’s message-level sequencing does not translate to resource updates. If a downstream process depends on message order, that logic needs somewhere new to live.

Plan the conversion as a design activity with clinical input. A team mapping ADT to FHIR resources without a clinical informaticist in the room will produce something technically valid and clinically wrong.

A sequence that works

1. Stand up the v2 path first. MLLP listener, ACK handling, Z-segment logic, running in parallel with BizTalk. Nothing changes for any clinical system.
2. Reconcile in parallel on message counts, ACK types, and ACK latency — including a full month, because clinical volume is seasonal and the odd messages appear at the edges.
3. Cut over v2 interfaces in waves, lowest clinical consequence first. Lab result feeds to a research database before ADT feeds to the bed-management system.
4. Add the FHIR layer once v2 is stable, as an additional consumer of the same ingested data rather than a replacement path.
5. Then move new development to FHIR. New apps and analytics consume resources. Existing v2 senders keep sending v2, indefinitely, and that is fine.

The temptation is to invert steps 1 and 4, because FHIR is the interesting part. Don’t. The v2 path is what carries clinical traffic today, and it is where the patient-safety risk sits.

Why the BizTalk background matters here

Healthcare integration has an unusually high cost of quiet failure. A dropped lab result does not throw an exception in a dashboard — it becomes a result that never arrived, discovered by a clinician.

Cerebrum City has run HL7 integration in enterprise production for two decades, including for Humana, as a Microsoft V-TSP–recognized BizTalk specialist. The value of that in a migration is specifically the silent-failure patterns: knowing that the ACK looked fine but the application-level processing failed, or that a Z-segment nobody documented was carrying a consent flag.

Our HL7 and FHIR practice covers this work. If you want your clinical interface estate inventoried, mapped, and sequenced by clinical consequence, book an assessment or call (678) 203-0800.

---