HL7 integration services · United States
HL7 v2 interfaces for hospitals, labs and health tech products: admissions, orders, results, scheduling, documents, charges and immunizations, delivered over MLLP, mapped to your data model or to FHIR R4, and monitored from the first message.
An event fires an HL7 v2 message: ORU^R01 when a result is released.
Receive over MLLP, validate, map codes to LOINC, route and send the ACK.
Store once, handle corrections and alert when the feed goes quiet.
The short answer
Nirmitee builds and runs HL7 v2 interfaces for US hospitals, labs, health systems and the health tech products that sell to them. We scope each feed with the hospital's interface team, build the MLLP listener, parser, mapping and acknowledgement logic on the engine you run (Mirth Connect, Open Integration Engine, Rhapsody, Cloverleaf, Corepoint or our own Interoply platform), test every failure path and switch on monitoring the day the feed goes live. You get an interface your product can trust: every admission, order and result arrives once, in order, mapped to your data model or to FHIR R4, with an alert the moment a feed goes quiet.
HL7 message types
These are the message types that products and hospitals build on. Your customer's interface team will use these exact codes, so the specification uses them too.
| Message | Trigger events | What it carries | What we design for |
|---|---|---|---|
| ADT | A01 admit, A02 transfer, A03 discharge, A04 register, A05 pre-admit, A06 and A07 class change, A08 update, A11, A12 and A13 cancels, A31 person update, A40 merge | Demographics (PID), visit (PV1), next of kin (NK1), insurance (IN1), allergies (AL1), diagnoses (DG1) | Event ordering, cancels that undo earlier events, A08 floods and A40 merges that re-point every record to the surviving MRN |
| ORM and OML | ORM^O01 general order; OML^O21 laboratory order in newer v2 profiles such as the HL7 LOI guide | Placer and filler order numbers (ORC, OBR), ordering provider, priority, specimen | New, change and cancel control codes in ORC-1, and order numbers that tie every result back to its order |
| ORU | R01 unsolicited observation result | Results in OBR and OBX, LOINC-coded tests, units, reference ranges, abnormal flags, result status | Preliminary, final and corrected results (OBX-11 P, F and C) and pathology or microbiology reports sent as text |
| SIU | S12 new booking, S13 reschedule, S14 modify, S15 cancel, S26 no-show | Appointment (SCH) and resources (AIS, AIG, AIL, AIP) | Slot, provider and location identifiers that differ in every scheduling system |
| MDM | T02 new document, T04 status change, T08 edit, T11 cancel | Notes, discharge summaries and reports (TXA with OBX), often base64 PDF or RTF | Document versioning and large payloads that exceed default size limits |
| DFT | P03 post detail financial transaction | Charges (FT1) with CPT or HCPCS codes, ICD-10-CM diagnoses, quantities, performing provider | Duplicate charges on resend, credits and reversals |
| VXU | V04 unsolicited vaccination record update | Immunizations (RXA) with CVX and MVX codes, lot numbers and VFC eligibility | The CDC HL7 2.5.1 immunization guide plus each state registry's local rules and ACK behavior |
| ACK | Original mode AA, AE and AR; enhanced mode CA, CE and CR | MSA segment with the control ID of the message it answers | Timeouts, NAK storms and whether the sender retries or holds its queue |
Also in scope when your workflow needs them: MFN master files, QBP and RSP queries, RDE and RAS pharmacy messages, and BAR billing account messages.
One site sends GLUC-F, the next sends FBS, a third sends “Glucose, fasting (serum)”. Same test. Until those become one thing in your product, you have data you can store but can't act on: no alerting, no trending, no analytics that hold up.
A mapping is confirmed by a human once, then applied automatically to every message from that hospital. The AI removes the searching, not the judgement.
Their fields to your model, written down before code is written. You see exactly what maps, what's missing, and what needs a new field on your side.
Local codes resolved to the standards the rest of healthcare uses: LOINC for tests, SNOMED CT for problems, RxNorm for medicines, ICD-10 for billing.
A model proposes candidates and ranks them; a person confirms. Thousands of local codes stop being a six-week manual slog, without a machine silently deciding clinical meaning.
Hospitals add codes without telling anyone. Anything unrecognised is flagged for review rather than dropped, so your coverage doesn't quietly rot.
Whether the hospital sends HL7 or offers a newer FHIR connection is their choice. It doesn't change what your product receives.
What data you need, which hospital, and whether your date is realistic.
Submitted immediately, because their queue is the clock you can't compress.
Against sample data, while their access request moves.
Run with the hospital's team, not around them. We handle the correspondence.
Monitoring switched on the same day, not added later.
A checklist your team can run, not another project.
None of them are exotic. All of them are why something that passed testing falls over a month after go-live.
Access and a testing slot come from their team, on their schedule. Discovered in week three, it costs you the date.
A code nobody mapped arrives, and the record is stored but invisible to your alerting. Nothing errors.
A result you already showed a clinician gets amended. Most integrations show the first value forever.
Hospitals merge duplicate patients. If your side ignores it, one person's history splits in two.
A connection stops and raises no error. Your customer finds out before you do.
One hospital's quirk hard-coded, then another's. By site eight, nobody will touch the file.
Connect everything to everything and the work multiplies. Route it through one shared model and it adds.
Add one more hospital system and the left goes 12 → 15. The right goes 7 → 8. At twenty customers, that gap is a headcount.
We've had all of them. Pick the one that sounds like your week. Each shows where to start, what we need from you and what tends to go wrong.
Sales committed, the hospital expects something, and nobody internally can say what it involves.
Confirm whether an existing feed can be reused or whether the hospital needs interface configuration or new work. Your side of the line is receiving and handling their data correctly.
Technically yes: none of it is exotic. The real problem is that it's interrupt-driven work with a hard external dependency. Most teams can build it. Fewer can build it and ship their roadmap in the same quarter.
Not the code. It's finding out in week three that the hospital's testing slot is eight weeks out, or that what they send is missing a field your product assumes. Resolve both dependencies before committing to a go-live date.
The date is external, and moving it costs you credibility. So the only question is what gets you there.
One feed, one direction, one hospital, admissions first. It's the feed hospitals switch on most readily and it unlocks the most product behavior. Launching all four at once is the most common reason these dates slip.
You'll hear it in week one, with the reason, while it's still a conversation with your customer rather than an apology. We'd rather lose the work than have you find out in week five.
This is where integration stops being an engineering question and becomes a margin question.
Every hospital sends slightly different data. If those differences live in your code, each new customer is a development project. The fix is that they become settings, not code.
Before hospital three. It's a normal amount of work to design in, and an expensive one to retrofit once several sites are live and each has its own quiet exceptions.
Wire everything directly and connections multiply as you grow; route them through one shared model and they add. At four systems that's 12 versus 7, and the gap widens with every hospital you sign. There's a picture of this below.
Nobody wants to touch it, it breaks unpredictably, and it's quietly become a risk rather than a feature.
Usually you wouldn't: your customer would tell you. A feed that stops raises no error at all; it just goes quiet. Alerting on absence is the cheapest fix with the biggest effect.
Not until it's mapped, which is why we never start by changing things. You get a written picture of what's running, what still has a consumer, and what's been dead a year. Often the first useful move is deleting something safely.
Yes, including the pager. We watch it and deal with the hospital's IT team directly. The code and documentation stay yours. Teams do take it back in-house, and that's a fine outcome.
None of these sound like you? Say so on the call and we'll tell you where we would start.
What we build
Each workstream ships with a specification, tests and an owner. Pick the ones your workflow needs.
ADT, ORU, SIU and MDM delivered into your API or database with idempotent writes, ordering by MSH-7 and PV1 visit number, and duplicate suppression on MSH-10.
ADT^A01 to A40 · ORU^R01 · SIU^S12 to S26 · MDM^T02
HL7 ADT event processing →ORM or OML orders to reference labs, ORU results from your device or lab product, DFT charges to hospital billing and VXU updates to state immunization registries.
ORM^O01 · OML^O21 · ORU^R01 · DFT^P03 · VXU^V04
Laboratory integration services →TCP listeners and senders with MLLP framing (0x0B start, 0x1C 0x0D end), site-to-site VPN or TLS, original or enhanced ACK modes set by MSH-15 and MSH-16, and agreed retry and hold rules.
MLLP · TLS · IPsec VPN · MSA · ACK/NAK
What is an HL7 interface? →Custom Z-segments such as ZPI or ZPV parsed into named fields, and every hospital's quirks kept in a per-site profile so the next site is configuration, not a code fork.
Z-segments · conformance profiles · site config
How HL7 integration works →Mappings based on the HL7 v2-to-FHIR implementation guide: PID to Patient, PV1 to Encounter, OBR and OBX to DiagnosticReport and Observation, RXA to Immunization, validated against US Core 6.1.0.
FHIR R4 · US Core 6.1.0 · LOINC · SNOMED CT · RxNorm
FHIR integration services →Message-level regression suites, NIST validation where a guide applies, replay tooling, and production alerts on queue depth, error rate, ACK latency and silence.
Regression suites · replay · no-message alerts
Integration monitoring and support →Buyer decisions
The engine is a real buying decision. We build on all of these, so the recommendation follows your team, volumes and budget.
| Option | Best fit | Licensing in 2026 | What to plan for |
|---|---|---|---|
| Mirth Connect 4.6 or later | Teams that already run Mirth and want vendor support | Commercial license from NextGen Healthcare since version 4.6 (March 2025) | License budget, Java 17 and regression testing of every channel on upgrade |
| Open Integration Engine | Teams that want to stay open source after Mirth 4.5.2 | MPL 2.0 community fork; v4.6.0 released July 2026 | You own patching and on-call, or contract a team that does |
| Rhapsody or Corepoint | Health systems with high volumes and a formal integration team | Commercial license from Rhapsody | Specialist skills; strong built-in monitoring and high availability |
| Infor Cloverleaf | Large hospitals with long-standing Tcl-based interfaces | Commercial license from Infor | Tcl skills; migrations run thread by thread |
| Interoply (our platform) | Product companies that want HL7, FHIR and X12 behind one API | Deployed per customer, in your cloud or ours | Fit with your hosting and data residency rules |
| Build in-house with HAPI or NHapi | A single narrow feed and a strong engineering team | Open-source libraries | You build queueing, replay, monitoring and ACK logic yourself |
The right engine is the one your team can operate at 2 a.m. when a hospital's feed stops.
Integration boundaries
Most delays come from unclear ownership, so we write it down before the build starts.
Enables the feed in Epic Bridges, Oracle Health, MEDITECH or their own engine, opens VPN or firewall access and schedules testing. We file the access request on day one and run that correspondence.
Owns the data model and the clinical workflow the data lands in. We list every field that has no home yet so you decide before code is written.
Listener, parsing, validation, mapping, routing, ACKs, retry, replay, audit logging and alerts. Defects in this layer are ours to fix.
Traffic runs over VPN, TLS-wrapped MLLP or SFTP. We sign a BAA, work inside our ISO 27001:2022 certified management system and use de-identified messages until production.
Local codes map to LOINC, SNOMED CT, RxNorm, CVX and ICD-10-CM with a named reviewer on each mapping. Your clinical lead confirms clinical meaning.
Deliverables
Everything below lands in your repository and your runbook, not ours.
Message types, trigger events, segment and field mapping, Z-segments, ACK mode and annotated sample messages.
Versioned engine configuration or services, with per-site settings kept out of the code.
Happy path plus malformed, duplicate, out-of-order, cancel, merge and corrected-result cases, with results.
LOINC, SNOMED CT, RxNorm and CVX maps with reviewer sign-off and a queue for new local codes.
Queue depth, error rate, ACK latency and no-message alerts routed to your on-call.
Cutover plan, replay procedure, hospital contacts and a checklist for onboarding the next hospital.
Delivery phases
A single inbound feed at one hospital typically takes 6 to 12 weeks end to end. The hospital's queue sets most of that date, so we request access in week one and build while it moves.
Weeks 1 to 2
Draft interface specification, access request filed, sample messages collected
Weeks 2 to 6
Channels, mappings and terminology tables built against sample and synthetic messages
Weeks 5 to 10
Connectivity proven, test scripts run with the hospital team, defects closed
Weeks 8 to 12
Cutover, two weeks of hypercare, monitoring live and runbook handed over
Cost drivers
You get a fixed scope and price after one scoping call. These are the factors that move it.
An inbound ADT feed is the smallest unit. Bidirectional orders and results need the hospital to test writes into its system.
Each hospital sends its own Z-segments and local codes. Configuration-driven design keeps the second site cheaper than the first.
A lab compendium with thousands of local test codes is its own workstream.
Engine licensing, cloud or on-premise hosting, VPN setup and high availability.
Some interface teams run formal scripts over several weeks; others sign off in a day.
Mapping to FHIR R4 and US Core adds profile validation. Ongoing monitoring and on-call are priced per connection.
Proof
Client names are withheld. The code and write-ups linked here are public.
Our integration team has built more than 350 interfaces on Mirth Connect across admissions, orders, results, documents and charges.
Public channels and transformers: ADT^A01 to a FHIR R4 transaction bundle, ORU^R01 to DiagnosticReport and Observation, SIU^S12 to Appointment, and an importable MLLP listener channel.
View the cookbook on GitHub →Our open-source operations layer for Mirth Connect and Open Integration Engine: web administration, clinical observability and channel CI/CD.
View OpenMirth on GitHub →Our platform runs HL7 v2, FHIR and X12 connectors behind one API, with monitoring, replay and per-site configuration built in.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
HL7 integration services connect clinical systems that exchange HL7 v2 messages, such as an EHR, a lab system or your product. The work covers the interface specification, the transport (usually MLLP over VPN), parsing and validation, field and terminology mapping, acknowledgements, testing with the hospital's interface team, go-live and production monitoring.
ADT (A01 to A13, A31 and A40 merges), ORM and OML orders, ORU^R01 results, SIU scheduling (S12 to S26), MDM documents (T02, T04, T08, T11), DFT^P03 charges and VXU^V04 immunization updates, plus MFN, QBP and RSP, RDE and BAR when a workflow needs them.
MLLP (Minimal Lower Layer Protocol) is the TCP framing HL7 v2 uses: a 0x0B byte before each message and 0x1C 0x0D after it. MLLP has no encryption of its own, so hospitals usually require a site-to-site IPsec VPN or MLLP wrapped in TLS. Some partners accept SFTP batches or HTTPS instead.
The receiver answers each message with an ACK whose MSA segment carries AA (accepted), AE (error) or AR (rejected) in original mode, or CA, CE and CR as commit acknowledgements in enhanced mode. MSH-15 and MSH-16 set which mode applies. We agree with the hospital when to retry, when to hold the queue and who gets alerted on repeated errors.
Z-segments are site-defined segments whose names start with Z, such as ZPI or ZPV, used for data the standard does not cover. We document each one in the interface specification, parse it into named fields and keep it in a per-site profile so it never leaks into shared code.
Use HL7 v2 when you need real-time event feeds from a hospital: admissions, orders, results and charges are still sent this way by most US EHRs. Use FHIR R4 APIs for on-demand reads and writes, patient apps and payer exchange. Many products need both: v2 for events and FHIR for queries.
Yes. We map v2 segments to FHIR R4 resources using the HL7 v2-to-FHIR implementation guide as the baseline: PID to Patient, PV1 to Encounter, OBR and OBX to DiagnosticReport and Observation, RXA to Immunization. Bundles are validated against US Core 6.1.0 and bound to LOINC, SNOMED CT and RxNorm.
It depends on your team and volumes. Mirth Connect 4.6 and later needs a commercial license from NextGen; Open Integration Engine is the open-source fork; Rhapsody, Corepoint and Cloverleaf suit large integration teams; Interoply suits product companies that want HL7, FHIR and X12 behind one API. We build on all of them.
A single inbound feed at one hospital typically takes 6 to 12 weeks, and most of that is the hospital's access and testing queue. A full site with several bidirectional feeds takes longer. Each hospital after the first is faster when site differences live in configuration.
Cost depends on the number of message types and directions, how much each site varies, terminology volume, engine licensing and hosting, the hospital's testing process and the support level you need. We give a fixed scope and price after one scoping call, before you commit.
Before go-live we run regression suites covering malformed, duplicate, out-of-order, cancelled, merged and corrected messages, and validate against NIST tools where a guide applies. In production we alert on queue depth, error rate, ACK latency and on silence, because a feed that stops raises no error on its own.
Yes. We sign Business Associate Agreements and work inside our ISO 27001:2022 certified management system. Interfaces run over encrypted transport, access is logged, development uses de-identified or synthetic messages, and retention follows your policy.
Next step
Tell us the hospital, the feeds and your date. An integration engineer replies with what the hospital will ask for, what could move the date and a fixed scope.
You'll get a straight answer on whether your date is realistic, roughly what it costs, and what we'd do first, before anyone talks about a contract.
Iselin,
NJ 08830
Baner, Pune,
Maharashtra 411045
You'll hear back within one business day, from someone who has done this before.
