11 Sep
A clinical AI team finishes a strong pilot demo. The sample data was clean FHIR, pulled straight from a sandbox, and the model performed exactly as expected. Three weeks later, the hospital partner turns on a live data feed and the pipeline breaks. What arrives isn’t FHIR. It’s HL7 v2: pipe-delimited segments, local Z-segments the vendor added a decade ago, and message types the engineering team has never parsed before.
This is not a rare failure. It’s the default. Most AI teams building for healthcare discover their first production data feed will speak an entirely different language than their demo did, and the discovery usually happens after the contract is signed, when the integration timeline is already public and the client is already watching.
What data will actually land in your AI pipeline?
HL7’s own Version 2 Product Suite documentation calls Version 2.x “the workhorse of electronic data exchange in the clinical domain,” and independent industry surveys consistently put its footprint at roughly 95 percent of U.S. healthcare organizations, with adoption across more than 35 countries (HL7 International, Version 2 Product Brief). FHIR is the standard every 2026 mandate is written around, but it isn’t what’s flowing out of most hospital systems today. The two standards run side by side: FHIR at the edges for patient apps and external sharing, HL7 v2 underneath for the transactions that actually keep a hospital running.
An ADT message announces a patient admission, transfer, or discharge. An ORU message carries a lab result. An ORM or ORC message represents an order. An SIU message handles scheduling. These message types move constantly, and they are almost certainly what a new AI integration will see first, regardless of what the sales deck promised.
Why does HL7 v2 break more than just your parser?
The technical challenge isn’t that HL7 v2 is old. It’s that it’s inconsistent. The standard allows optional segments and custom Z-segments, and vendors and health systems have spent decades filling those in with local variations. Two ADT feeds from two different hospitals, both claiming full HL7 v2 compliance, rarely look identical field for field.
For a model trained on clean, structured input, that inconsistency is the problem. A missing or misplaced field doesn’t throw a clean error. It produces malformed context, and a model working from malformed context is the kind of setup that produces confident, wrong output rather than an obvious failure. Teams that assume “HL7 v2 compliant” means “consistent” are the ones who find out otherwise in front of a client.
Why does the usual integration fix stall?
The usual response is to hire an integration engineer, or pull a backend engineer off product work to write a custom v2 parser. It’s a reasonable instinct, and it’s also how a six-week integration turns into a two-quarter distraction. Every new hospital partner brings its own local variations, so the parser needs ongoing maintenance, not a one-time build. Few early-stage AI teams have the headcount to treat that as a permanent function.
| HL7 v2 message type | What it carries | Typical FHIR R4 target |
|---|---|---|
| ADT (A01, A02, A03…) | Admit, transfer, discharge events | Patient, Encounter |
| ORU | Observation and lab results | Observation, DiagnosticReport |
| ORM / ORC | Orders and order control | ServiceRequest |
| SIU | Scheduling events | Appointment |
| MDM | Document management notifications | DocumentReference |
How do you know your integration debt is already costing you?
- A pilot that ran on sample FHIR data has no plan for what happens when the live feed turns out to be HL7 v2.
- Nobody on the team can name which ADT trigger events (A01, A04, A08…) the partner’s system actually sends.
- Z-segments show up in a sample message and get ignored rather than mapped.
- The only data quality check is whether the pipeline throws an error, not whether the resulting FHIR is structurally complete.
- Engineering time on the integration is scoped as a one-time project rather than an ongoing maintenance line.
How do you test the conversion before it touches your model?
The way to find out whether an integration will hold up isn’t to wait for the first live feed. It’s to run a real HL7 v2 message, built from synthetic or de-identified data, through a converter and look at the resulting FHIR bundle before any partner data is involved. Hgear’s free HL7 to FHIR Converter does exactly that: it takes v2 messages such as ADT, ORU, and ORM and returns validated FHIR R4 resources, so a team can see precisely which fields map cleanly and which don’t, without touching production patient data or standing up an integration engine.
That’s the right order of operations, and it’s the same order regulators are pointing toward. CMS-0057-F requires impacted payers to implement FHIR-based Prior Authorization, Provider Access, and Payer-to-Payer APIs by January 1, 2027 (CMS, Interoperability and Prior Authorization Final Rule), which means the FHIR side of these pipelines is only going to matter more. Test the conversion path on synthetic messages, confirm the FHIR output is structurally sound, and only then plan how the model consumes it. Teams that skip this step tend to find their gaps live, in front of the partner whose data exposed them.
What should you check in the converted FHIR before trusting it?
A converted bundle can look correct at a glance and still be missing exactly the fields a model needs. Before wiring any output into a product, check four things in order.
First, resource completeness. An ADT message maps to Patient and Encounter, but only if the source message actually populated the fields those resources require. A conversion tool that silently drops an unmapped PID segment produces a technically valid FHIR resource with a hole in it.
Second, code system bindings. Lab results carried in an ORU message often use local or proprietary codes rather than LOINC, and a conversion that passes those through unchanged will produce an Observation resource a downstream system, or a model, cannot reliably interpret. Confirm the converter is mapping to standard code systems, not just relabeling fields, and spot-check a sample of the mapped codes against the source message by hand.
Third, reference integrity. A Patient resource and an Encounter resource are only useful together if the Encounter correctly references the Patient it belongs to. This is where custom Z-segment handling tends to break quietly, since the reference can end up null or pointing at a placeholder.
Fourth, repeat the check per partner. A conversion pipeline validated against one hospital’s ADT feed does not guarantee the same result against the next partner’s feed, since local segment customization varies by vendor and by site, sometimes down to a single optional field. Run the check again for every new integration rather than assuming the first pass covers the rest.
Want to see it on your own sample messages?
Hgear’s free HL7 to FHIR Converter is built for teams that need to know what their data pipeline will actually look like before a hospital partner’s live feed answers that question for them. Run a synthetic or de-identified HL7 v2 message through it and see the FHIR R4 output directly.
FAQs
Most hospital systems run HL7 v2 as the internal backbone for admissions, lab results, and orders, and replacing that infrastructure is a multi-year undertaking most health systems haven't scheduled. FHIR is the standard behind newer mandates like CMS-0057-F, but it typically sits at the edges of a system, for patient apps and external sharing, while HL7 v2 keeps running the core transactions underneath.
The most common are ADT for admission, discharge, and transfer events, ORU for lab and observation results, ORM or ORC for orders, and SIU for scheduling. Any integration plan that doesn't account for at least ADT and ORU is missing the two message types most likely to arrive first.
Yes, and it's the safer way to evaluate a pipeline before a partner integration goes live. Hgear's free HL7 to FHIR Converter is built for exactly this kind of evaluation using synthetic or de-identified HL7 v2 messages, so a team can see the resulting FHIR R4 output without a BAA or a live data connection in place.
A model trained to expect structured, complete input doesn't fail cleanly when a field is missing or a Z-segment goes unmapped. It fills the gap with a plausible-looking guess instead of flagging an error, which is how malformed input becomes confidently wrong output rather than an obvious break.
Not necessarily. Because vendors and health systems customize v2 with optional segments and local Z-segments, a parser built for one partner's feed often needs rework for the next. A converter that outputs standard FHIR R4 resources, evaluated first against synthetic messages from each new partner, reduces how much custom parsing work has to be repeated per integration.
An ADT message generally maps to Patient and Encounter resources under FHIR R4, while an ORU message maps to Observation and DiagnosticReport resources. The exact mapping depends on which segments and fields the sending system actually populates, which is why checking the converted output matters more than assuming a clean one-to-one translation.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
