Integration
HL7 vs FHIR vs X12: A Field Guide for Leaders Who Inherit an Integration
You have inherited an integration. It came with a new role, an acquisition, or a vendor who stopped returning calls. Somewhere a registration or scheduling system sends messages, a billing system turns charges into claims, and a health plan sends payment back. The first question on the table is often HL7 vs FHIR: which one are we on, and should we move to the modern one?
That framing hides more than it answers. HL7 version 2, FHIR and X12 are not three generations of one standard. HL7 International publishes both v2 and FHIR, and both mostly carry clinical and administrative data between provider systems. X12 is a separate family of standards that carries claims, remittances and eligibility between providers and payers. One revenue workflow can touch all three, and an interface nobody can describe is a risk whichever standard it uses.
Below: what each standard is for, how messages move, why FHIR projects stall, and a checklist that splits what you have confirmed from what you are inferring.
Three Standards, Three Jobs
| HL7 v2 | FHIR | X12 (HIPAA transactions) | |
|---|---|---|---|
| Who usually talks | Provider systems: registration, scheduling, clinical, billing | Provider systems, apps, and health plans exposing data through APIs | Providers, billing services, clearinghouses and health plans |
| What moves | Events: a patient admitted, an appointment booked, a charge posted | Resources such as Patient, Encounter and Appointment, read and written over an API | Claims (837), payments and remittance advice (835), eligibility (270/271), claim status (276/277), prior authorization (278) |
| What it looks like | Pipe-delimited segments: MSH, PID, PV1, FT1 | JSON or XML resources | X12 segments inside an interchange envelope |
| How it usually moves | MLLP over a TCP connection; sometimes HTTPS or files | A RESTful HTTP API | Batch files or real-time exchange, directly or through a clearinghouse |
| Where the version is written | MSH-12 in every message | fhirVersion in the server’s CapabilityStatement | The file envelope, and the implementation guide your partner names |
The last row matters most. Each standard records its version somewhere you can read, and until someone has read it off real traffic, the version is a belief, not a fact.
HL7 v2: The Interfaces You Probably Already Have
HL7’s Version 2 messaging standard was first released in 1987. HL7 also published a Version 3 family, including the Clinical Document Architecture for clinical documents, but this guide stays with the v2 event feeds that pass between provider systems.
A v2 message is a stack of segments, one per line, each a row of pipe-delimited fields. Every message opens with an MSH header, and two of its fields come first in any inventory. MSH-9 names the message type and trigger event, such as ADT^A01. MSH-12 carries the version of HL7 the sender used to build the message.
Three message types line up with a scheduling-to-billing workflow. Their trigger events are defined in HL7 Table 0003:
- ADT (admit, discharge, transfer). A01 is an admit or visit notification, A02 a transfer, A03 a discharge or end of visit, A04 a patient registration, and A08 an update to patient information. ADT messages typically include the PV1 patient visit segment, which holds the visit’s details, such as patient class, location and attending doctor.
- SIU (scheduling). S12 announces a new appointment booking, S14 a modification, and S15 a cancellation.
- DFT (detail financial transaction). P03 posts detail financial transactions. Each charge rides in an FT1 segment, which carries the transaction date, type, code, quantity and amounts.
Each message type names an upstream owner. If your system receives SIU messages, another system owns the appointment. If it receives DFT messages, charge capture happens somewhere else, and that system decides what a charge is. Every one of those owners needs a named contact in your inventory.
Here is the first place inference creeps in. Seeing ADT, SIU and DFT messages is good evidence that a feed speaks v2. It does not tell you which 2.x version, and different senders can use different versions on different feeds. That answer lives in MSH-12 of captured messages from each feed, not in an interface document written years ago.
Transport: MLLP, HTTP, or a File Drop
Message format and transport are separate questions, and inherited documentation often answers only the first.
The traditional transport for v2 is MLLP, the Minimal Lower Layer Protocol: a thin framing on a TCP connection that starts each message with the byte 0x0B and ends it with 0x1C followed by a carriage return. HL7’s MLLP transport specification notes that MLLP has a long history of use in the HL7 community but has never been formally part of the HL7 standard. MLLP itself is only framing: it adds no encryption and no authentication. So for every MLLP connection, find out what protects it: a VPN, a TLS tunnel, a private circuit, or nothing.
Some interfaces carry the same v2 payload over HTTPS or as files on a server: the same message, with different failure modes, monitoring and security. For each feed, write down who opens the connection, on what address and port, which acknowledgment the sender waits for, and what happens to messages while the receiver is down.
X12: How You Talk to Payers
A workable rule of thumb: HL7 is how provider systems talk to each other, and X12 is how providers talk to payers.
Under HIPAA, the adopted standards for administrative transactions are X12 transactions for everything except pharmacy transactions, which use NCPDP standards: the 837 for claims, the 835 for claim payment and remittance advice, 270/271 for eligibility, 276/277 for claim status, 278 for prior authorization and referrals, 834 for plan enrollment and 820 for premium payments. The 837 carries claim or encounter information from providers to payers, directly or through billing services and clearinghouses. The 835 carries payment and remittance advice from the health plan back to the provider.
Versions matter here too. HHS’s 2009 modifications rule adopted X12 Version 5010 to replace 4010 and 4010A1, with compliance required from January 1, 2012. If someone tells you a feed is “4010,” treat it as a question: an old system, an exchange outside HIPAA, or a memory? X12 keeps publishing newer guides (the 835 now exists in an 008060 edition, for example), but a newer release existing does not mean your trading partners use it. Read the version from the envelope of real files and the companion guide each payer or clearinghouse publishes.
The HL7 and X12 lanes meet in billing. A charge posted in an FT1 segment becomes a line on an 837, and the 835 that comes back has to be matched to the claim it pays. When nobody can explain how that matching works, that is the part of the integration to understand first.
FHIR: Why the Modern Option Stalls
FHIR is built from resources (Patient, Encounter, Appointment and so on) represented in JSON or XML. It is described as a RESTful specification, so the usual exchange is an HTTP API, though the overview notes that you do not have to use REST to use resources.
The release matters as much as the v2 version does. R4 was published in December 2018 as the first release with normative content, with technical corrections as 4.0.1 in October 2019. R4B followed in May 2022 and R5 in March 2023. A “FHIR integration” with no release number attached is unconfirmed. The confirmed answer is the fhirVersion a server declares in its CapabilityStatement, together with the implementation guide both sides agreed to.
On the payer side, CMS’s 2020 Interoperability and Patient Access final rule requires Medicare Advantage organizations, Medicaid and CHIP programs, and qualified health plan issuers on the federally facilitated exchanges to offer a Patient Access API that meets HL7 FHIR Release 4.0.1. That is an API for patients and the apps they choose. It does not replace the 837 and 835 for claims.
Building a FHIR endpoint is the easier half of a FHIR project. An exchange also needs a partner who can send or accept the same resources, at the same release, under the same profiles and authorization. If your organization tried FHIR before and stopped, find out why before starting again. If the answer is that the trading partners were not ready, rewriting your side will not change it, and the honest plan keeps v2 and X12 at the edges while partners move one at a time.
Confirmed vs. Inferred: The Inventory Checklist
The most useful document a new owner can produce is an inventory with two columns. An inference is still worth writing down; seeing ADT, SIU and DFT messages is fair evidence of v2. It just has to be labeled, so nobody builds on it as fact.
| Question, per interface | Confirmed when | Still an inference when |
|---|---|---|
| Which standard it uses | You hold captured messages or files from that interface | Someone says “it’s HL7” |
| Which v2 version | You have read MSH-12 on live traffic from each sender | The message types point to 2.x |
| Which FHIR release | The server’s CapabilityStatement or the partner’s specification names it | The project plan says “FHIR” |
| Which X12 version | Real file envelopes and the partner’s companion guide agree | “Everyone is on 5010” |
| How it moves | Network configuration or connection logs show it | The original design document says so |
| Who the partner is | A named owner on their side has answered you | A name appears in an old email |
| What it carries, and how much | Logs show message types and counts over a normal week | The system “should” receive it |
| How it maps inside | The mapping from each inbound message to your internal record is written down | The field names look similar |
Inventory per interface, not per system. When nobody can say which standard a platform uses, the honest answer is sometimes all three, one per feed. That is not a failure. It is the starting point.
The Decision the Inventory Sets Up
Many integration layers normalize inbound messages into an internal record of their own, such as a JSON encounter or charge object, with no one-to-one equivalent in any HL7 message. That is a reasonable design, but it means the mapping is the real contract. If it is not written down, it is the first thing to write down.
With the inventory in hand, the real choice comes into view. You can shape the new platform around the contracts you already have, keeping v2 and X12 at the edges and translating at the boundary. Or you can build around a model of your own and give each trading partner a migration path. Both can work. What does not work is choosing before you know which partners can move. For the incremental route in general, see modernizing legacy systems without a rewrite, and for keeping compliance intact while you do it, modernizing healthcare software without breaking compliance. For the wider picture of how EMR, practice management and payment platforms connect, read our guide to healthcare systems integration across multiple platforms.
Frequently Asked Questions
Is HL7 the same as FHIR?
No. HL7 International publishes both, but in conversation “HL7” usually means v2: pipe-delimited messages, often over MLLP. FHIR is built from resources and usually exchanged over an HTTP API.
Do we need FHIR to exchange claims with payers?
Claims, remittance advice, eligibility and claim status under HIPAA use X12 transactions such as the 837 and 835. Some payers must also offer FHIR APIs, such as the Patient Access API, but those sit beside the X12 exchange rather than replacing it.
How do I find out which HL7 v2 version we use?
Capture real messages from each feed and read MSH-12. Do it per sender, because different feeds can use different versions.
Where to Start
If you have inherited integrations and cannot fill in the checklist yet, the inventory comes before any migration plan. We work alongside IT teams to build it: capturing real traffic, confirming what can be confirmed, labeling what cannot, and laying out the options the answers leave you. Read how we approach custom healthcare software development and the healthcare systems we work on, see what it looks like to have an engineering partner your IT team does not have to babysit, or book a discovery call to talk through what you inherited.
Newsletter
Subscribe to newsletter
Subscribe to receive the latest blog posts to your inbox every week.
