Overview
An HL7 interface is a data-exchange connection between two healthcare systems using the HL7 (Health Level Seven) version 2.x messaging standard. HL7 v2 is the most widely deployed healthcare integration standard in the United States, underlying most transactional data flow inside hospitals and across hospital-to-vendor connections. Despite being a legacy standard (first release 1987, major revisions through v2.8 current), HL7 v2 remains the workhorse of healthcare integration.
HL7 v2 messages are pipe-delimited text with positional fields. A message begins with an MSH (Message Header) segment, followed by message-type-specific segments: PID (Patient Identification), PV1 (Patient Visit), OBR (Observation Request), OBX (Observation Result), FT1 (Financial Transaction), and others. Each segment has dozens of fields; each field may have subcomponents. The syntax is compact but highly positional — a misplaced field breaks the message.
Common HL7 v2 message types include ADT (Admit/Discharge/Transfer — patient demographics and movement), ORU (Observation Result Unsolicited — lab or imaging results), ORM (Order Message — orders placed), SIU (Scheduling Information Update — scheduling actions), MDM (Medical Document Management — document events), DFT (Detailed Financial Transaction — charges), and BAR (Billing Account Record — patient billing account info). Each message type has its own structure and field semantics.
HL7 interfaces are typically routed through an integration engine (Mirth, Corepoint, Rhapsody, Cloverleaf) rather than point-to-point. The engine receives inbound messages, applies transformations (version conversion, field mapping, code translation), and routes outbound to the target system. Engine-based routing reduces the N² interface complexity of point-to-point integrations and centralizes monitoring and error handling.
RCM-relevant HL7 flows include ADT feeds for registration and encounter creation, DFT feeds for charge capture from EHR to PMS/billing, SIU for scheduling-to-authorization workflows, and ORU for results-based charge capture in labs and imaging. Every RCM organization with EHR integration has dozens to hundreds of HL7 v2 interfaces in production, and each one is a potential source of revenue leakage if it fails silently.
Mature RCM teams treat HL7 Interface as a lever rather than a report line. The practical move is to set a weekly delta target against the 90-day baseline and make HL7 Interface the headline metric a biller owner is accountable for, with fhir api and ehr integration as the second-tier drivers they report on beneath it. The trap worth naming is denominator drift — a change in payer mix, service line, or even calendar workdays can move HL7 Interface without any operational issue, so the monthly review should always include a volume-normalized cut alongside the raw number. Reviewers also recommend stratifying by top five payers, because a single payer's policy change will frequently distort an all-payer HL7 Interface reading.
Industry benchmark
HL7 v2.x is used in 95%+ of U.S. hospitals for transactional integration. Integration engine monitoring is expected for HIPAA Security Rule compliance and operational reliability.
Worked example
A hospital generates an ADT^A04 (patient registration) message when a patient registers for an outpatient encounter. The message includes patient demographics, insurance, and provider information. Mirth routes the message to the PMS for registration record creation, the pharmacy system for medication history lookup, and the lab for order anticipation. A single ADT event triggers updates in 4–8 downstream systems without manual intervention.
Frequently asked questions — HL7 Interface
What HL7 versions are in production today?
HL7 v2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.8 are all in use depending on vendor and age of integration. FHIR is the modern REST-based standard. HL7 v3 is largely abandoned in favor of FHIR. Most new integrations use FHIR; legacy integrations use v2.
What is an integration engine?
Middleware that receives HL7 messages, applies transformations, and routes to downstream systems. Common platforms: Mirth/NextGen, Corepoint, Rhapsody, Cloverleaf. Engines centralize monitoring, error handling, and version/code translation for large interface portfolios.
Do we need HL7 expertise in-house?
For significant interface portfolios, yes — either in-house staff or contracted integration resources. HL7 engineering work includes message spec interpretation, mapping, transformation, and monitoring. Smaller organizations outsource to integration consultants; larger ones build dedicated integration teams.
Is HL7 v2 going away?
Not soon. FHIR is the new standard for modern integration, but HL7 v2 has enormous installed base. Full replacement across the industry would be a multi-decade transition. Organizations should run both and plan gradual FHIR adoption for use cases where it clearly wins.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.