Cybersecurity: 24/7/365
Cybersecurity: 24/7/365
4MEDNET delivers managed IT, cybersecurity, HIPAA compliance, and AI automation solutions built exclusively for healthcare practices.
HL7 integration services: HL7 v2 interfaces, interface engine work, and HL7 to FHIR migration for healthcare organizations and digital health vendors.
HL7 has moved hospital data since the late 1980s. It is unglamorous, widely misunderstood, and still carries most clinical traffic in American healthcare.
We build and run HL7 interfaces for healthcare organizations and digital health vendors. New builds, rescues of interfaces nobody owns, and HL7 to FHIR migrations.
This page explains how HL7 integration actually works, where FHIR fits, what it costs, and how long it takes.
Health information exchanges still take HL7 v2 ADT
Hospitals also on FHIR — the two run side by side
Typical v2 interface, discovery to go-live
An HL7 integration is a connection that moves a structured HL7 message from one healthcare system to another when something happens.
A patient is admitted, a lab result is finalized, an appointment goes on the schedule. Each event produces a message, and the receiving platform acts on it.
The message itself is plain text in segments separated by pipes. A header names the sender and message type, and the rest carries patient identifiers, clinical data, and the event detail.
Transport is usually MLLP over a persistent TCP connection. The receiver returns an acknowledgement, and that ACK is what tells the sender the exchange succeeded.
Everything hard about HL7 integration lives in mapping and validation, not in transport. Two systems rarely agree on how a field should be filled.
Get the mapping right and clinical and administrative data flows without anyone re-keying it. Get it wrong and you have created a new source of errors.
Not in the way most developers mean the word. HL7 v2 is a messaging standard, not a request-response API.
You do not query an HL7 interface. It pushes messages at you when events happen, and your job is to process what arrives.
FHIR is the HL7 standard that is an API. That distinction causes most of the confusion, because both come from the same standards body.
A modern integration usually uses both. HL7 v2 for the event stream, FHIR APIs for anything that needs to ask a question and wait for an answer.
Slowly, partially, and not everywhere. That is the honest answer.
FHIR is better for anything an application needs to query, and the 21st Century Cures Act pushed every certified EHR to expose FHIR APIs.
But HL7 v2 still carries the high-volume event traffic in most hospitals, and replacing a working interface has no clinical upside.
So HL7 and FHIR coexist. Most healthcare integration work touches both, and the useful skill is knowing which one belongs where.
Fast Healthcare Interoperability Resources solved the developer-experience problem. It did not delete twenty years of installed HL7 interfaces.
Yes, and it will be for a long time.
Interfaces built fifteen years ago still run in production because they work, and because the cost of touching them is real.
Any vendor selling into hospitals will meet HL7 v2. Healthcare applications that only speak FHIR quietly lose deals to products that speak both.
Treating HL7 as one of those legacy systems you can ignore is a planning error. It is infrastructure, and infrastructure outlives fashion.
Most integration work involves a handful of message types. These are the ones that come up in almost every project.
Admissions, discharges, and transfers. The backbone feed almost every other integration depends on.
Orders going out from the EHR to labs, imaging, and pharmacy.
Observation results coming back, including lab values and imaging reports.
Scheduling messages for appointments and resource booking.
Charge and billing detail, so the financial record matches the clinical one.
Documents and Clinical Document Architecture summaries for referrals and transitions of care.
An interface engine sits in the middle, routing and transforming messages between systems that were never designed to meet.
We work inside whichever engine you already run, or stand one up if you do not have one yet.
The most common open-source engine, and the one we see most often in mid-size organizations.
Widely used where reliability and throughput matter most.
Common in larger health systems already invested in the platform.
Long-established in hospitals, often carrying interfaces older than the current IT team.
Popular with vendors who need to stand up connectivity quickly.
AWS or Azure services when there is no existing engine and no reason to buy one.
The common use cases repeat across every healthcare organization we work with.
Feeding an EHR system from a lab, an imaging platform, or a specialty information system so results land in the chart automatically.
Pushing orders out of the EHR to the systems that fulfil them, then returning status and results in real time.
Sending charges to billing so the financial side matches what actually happened clinically.
Populating analytics and reporting platforms, and feeding a health information exchange where regional sharing is required.
Connecting a digital health product to the hospitals that buy it, which is usually what turns a pilot into a contract.
When an old interface becomes unmaintainable, moving it to FHIR is sometimes cheaper than repairing it.
We map HL7 v2 segments to FHIR resources, run both paths in parallel, and cut over only once the outputs agree.
Running in parallel is the step teams skip and regret. Silent divergence between two feeds is how patient data goes wrong quietly.
We also do the reverse. Plenty of FHIR-native products need to emit HL7 v2 because the hospital on the other end expects it.
Ranges assume one interface between two systems. Bundles cost less per interface, because the mapping work and the engine setup are shared.
What moves the number is message volume, how much transformation the mapping needs, and whether the far end cooperates.
One feed between two systems, including mapping, validation, and testing.
Three to eight interfaces sharing setup and mapping work.
Standing up or migrating an integration engine, with monitoring and alerting built in.
Monitoring, alerting, and fixes as the systems on either end change.
A single straightforward interface goes live in four to eight weeks. Bundles and engine migrations run three to six months.
The variable that matters most is not our build time. It is how quickly the other vendor will schedule testing with you.
Every site implements HL7 slightly differently. The standard permits optionality, and vendors use all of it.
Z-segments are the clearest example. They are custom segments carrying data the standard never defined, and they are everywhere.
Patient identity is the second problem. The same person carries different identifiers across systems, and reconciling them is real work rather than a lookup.
Third, interfaces fail quietly. A feed that stops at 2am without alerting gets discovered when a clinician notices missing results.
That is why we monitor what we build. A reliable HL7 interface is one that tells you it broke before anyone else notices.
HL7 messages carry protected health information in plain text, so everything around the message does the protecting.
We use TLS, restrict connections by IP address, and keep secure data exchange inside private networks wherever the architecture allows.
Audit logging captures every message, access control governs who can touch the engine, and a business associate agreement is signed before real data moves.
HIPAA compliance here is mostly operational discipline. Encrypted transport, least privilege, retention limits, and knowing where every copy of a message lives.
Healthcare providers come to us when a new system will not talk to the EHRs they already run.
Digital health vendors come when a hospital deal depends on an interface they have never built before.
Larger organizations come when nobody owns the interfaces any more, because the person who did has moved on.
In every case the goal is the same. Make the electronic health record and everything around it exchange data without a human retyping anything.
We work directly with the vendor on the far end too. Half of any interface project is coordination with someone else engineering team.
An HL7 implementation is more coordination than code.
You agree the message types, then you agree how every field gets filled, then you test against a system you do not control.
Deciding to use HL7 rather than an API is usually not a choice at all. It is whatever the far end supports.
We implement HL7 in whichever direction the project needs, inbound or outbound, and we document the mapping so the next person can maintain it.
Most HL7 data problems trace back to a mapping decision nobody wrote down at the time.
A modern healthcare integration rarely relies on one interoperability standard by itself.
HL7 FHIR handles the queries and the app launches. SMART on FHIR puts your application inside the chart with the patient already in context.
FHIR integration and HL7 v2 feeds usually run side by side, and EHR integration projects increasingly need both from the first sprint.
We build the whole set rather than treating them as separate disciplines. In practice they share the same mapping and patient identity problems.
Choosing between them is an engineering decision, not a philosophical one. Use whichever moves the data correctly with the least fragility.
The reason to integrate is almost always workflow.
Every unintegrated system creates duplicate data entry, and every duplicate entry is another chance to get something wrong.
A good interface removes the retyping and gives the clinical workflow back its continuity.
When healthcare data exchange works properly, staff stop thinking about the systems and get on with the patients.
That is the real return on an interface. Not the technology, but the hours and errors it takes out of the day.
Most HL7 traffic is real-time. A result that arrives an hour late is a result the clinician has already worked around.
We build integration solutions that deliver in seconds and alert loudly when they do not.
An interoperability solution without monitoring is a liability. Feeds fail, and the only question is whether you find out before your users do.
Healthcare data moving reliably is the actual product here. Everything else is plumbing around it.
We instrument message counts, acknowledgement failures, and latency, then route alerts somewhere a human will actually see them.
Connections that move structured HL7 messages between healthcare systems when clinical or administrative events happen. An admission, a lab result, or a charge each produce a message the receiving system acts on.
HL7 v2 is a messaging standard rather than a request-response API. FHIR is the HL7 standard that is an API. Most real integrations use both.
FHIR is taking over the query-style work, pushed along by the 21st Century Cures Act. It is not replacing HL7 v2 event feeds in hospitals, and both will run side by side for years.
Very. It carries most clinical traffic in American hospitals, and any product selling into that market has to speak it.
A single interface runs $12,000 to $30,000. Bundles of three to eight interfaces are $30,000 to $90,000, and engine setup or migration is $25,000 to $75,000. Managed support starts at $1,800 a month.
Four to eight weeks for a straightforward interface. Bundles and engine migrations run three to six months, and the pacing item is usually the other vendor testing schedule.
Yes, and it is a common request. We document what exists, add monitoring so failures surface immediately, then fix and modernise from there.
Yes. We work in Mirth, Rhapsody, InterSystems, Cloverleaf, and Iguana, or in cloud-native pipelines where no engine exists.
That is most of the job. We standardize codes and identifiers in the mapping layer so downstream systems get consistent data even when the sources never will.
Yes, and most projects need both. HL7 v2 carries the event feeds while FHIR handles queries and in-chart app launches. We treat them as one integration problem.
Yes. Adding monitoring and alerting to existing interfaces is often the highest-value first engagement, because it surfaces failures nobody currently sees.
Bring us the systems you need to connect and what has to move between them. We'll come back with an interface plan, a timeline, and a fixed range — before anyone signs anything.
Book a scoping call or send us the details. If you also need the practice-side work, our managed IT and HIPAA compliance services cover it.
Managed IT, cybersecurity, HIPAA compliance, and AI automation for healthcare practices. We keep your technology secure so you can focus on patient care.
4MEDNET.COM - Copyright 2026. All rights reserved.