An admission message leaves a hospital registration system as a few lines of pipe-delimited text, and the radiology system receiving it has to work out what each position means. That exchange is what most engineers mean when they ask “what is HL7”. The name also belongs to the organization that publishes the format, and to several other standards families that organization maintains. Which of those a partner means by HL7 support is the first thing a product team has to establish.
What Is HL7? Two Different Things Share the Name
Health Level Seven International, HL7, was founded in 1987. It describes itself as “a not-for-profit, ANSI-accredited standards developing organization dedicated to empowering interoperability of healthcare data globally.” The name itself is worth knowing: “Level Seven” refers to the application layer, the seventh and top layer of the OSI networking model. That is the layer where two systems agree on what data means, rather than how it physically travels.
HL7 the organization publishes several distinct standards families, not one. Its own standards page groups them by section: Clinical Document Architecture, electronic health record profiles, FHIR, Version 2, Version 3, and others. On its About page, HL7 states directly that “HL7 standards deliver solutions for health information technology, including HL7® Fast Healthcare Interoperability Resources (FHIR®), Version 2 (V2) and Clinical Document Architecture (CDA®).”
For a product or engineering lead evaluating a partner’s claim of HL7 support, the practical question is which of these families is meant. In imaging and clinical messaging specifically, “HL7” almost always means HL7 Version 2, known as V2. That is the standard this article is about, and the one that still carries most production clinical interfaces.
V2 itself dates to October 1987, the same year HL7 the organization was founded. HL7’s own product brief for Version 2 states it “was first released in October 1987 as an Application Protocol for Electronic Data Exchange in Healthcare Environments.”
Inside a Version 2 Message: Segments, Fields, and Components
An HL7 V2 message is plain text in its usual encoding, structured with a small set of nested delimiters, not XML or JSON. It is triggered by something happening rather than sent on a fixed schedule: a sending system builds a message the moment an event occurs, instead of exposing data for another system to query on demand. That structure breaks into four levels.
- A message is one complete transmission, made of one or more segments.
- A segment is one line of the message, identified by a three-character code such as PID for patient identifying information or PV1 for visit information. A pipe character is the standard separator between fields inside a segment.
- A field is one piece of data inside a segment, such as a patient’s last name or an order number.
- A component breaks a single field into further parts when that field has its own internal structure, such as a name split into family and given components.
Three segments of an admission message look like this. The data is invented, the shape is not.
MSH|^~\&|REGADT|RIVERSIDE|RADIOLOGY|RIVERSIDE|20260924083000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
PID|1||100457^^^RIVERSIDE^MR||PATIENT^EXAMPLE||19610615|F
PV1|1|I|3N^305^01Read the pipes as column boundaries and the structure resolves. The first line announces who sent the message, who it is for, that it is an A01 admission, and which version of the standard it follows. The second carries the patient: a medical record number in PID-3, a name in PID-5 split into family and given components by the caret. The third places the visit, an inpatient class in PV1-2 and a ward, room and bed in PV1-3.
Empty fields between the pipes are not errors. They are positions the sender had nothing to put in, which is the optionality this article returns to below.
One segment always comes first: MSH, the message header. MSH-1 and MSH-2 are the delimiters themselves, the field separator and the encoding characters the rest of the message uses to punctuate itself. Later fields in MSH carry the sending and receiving application, the message type, the specific trigger event, and a unique message control ID.
That header is dense enough to deserve its own field-by-field treatment. What matters here is that MSH is where a receiving system learns what kind of message just arrived and what it is expected to do with it.
Event-Driven Messages: What ADT and ORM Trigger
V2 messages fire because something happened, not on a schedule. HL7’s own trigger-event code system exists for exactly this purpose: it is “used in HL7 Version 2.x messaging in the MSH segment” to name the event behind a given message.
The two families a product team runs into most often in a clinical or imaging deployment are ADT and order messages.
ADT stands for admit, discharge, transfer, and its trigger events cover a patient’s movement through a facility and the changes to their record along the way. A few of the most common: A01 for an admission, A02 for a transfer, A03 for a discharge, and A08 for updating patient information already on file. Each is a separate trigger event, carried in the same segment structure, distinguished only by what MSH says happened.
Order messages carry what was ordered and for whom. The classic, general-purpose order message is ORM, historically triggered as ORM^O01. Current HL7 tables mark that general form deprecated in favor of more specific order types split by department, such as OMG for a general clinical order and OMI for an imaging order. In practice, plenty of production interfaces still speak the older, broader ORM message, because a deprecated status in a standard does not mean a message type has disappeared from the field.
A third family, SIU, carries appointment scheduling notifications rather than admissions or orders: a new booking, a reschedule, a cancellation. It runs on the same segment-and-trigger-event pattern as ADT and ORM.
Why Optionality Means “HL7 Compliant” Promises Less Than It Sounds
V2’s greatest strength doubles as its most common source of failed integrations: almost everything in it is optional, and whatever the standard leaves out gets settled locally between the two parties. HL7’s own V2 product brief lists that second half among V2’s benefits, that it “provides a framework for negotiations of what is not in the standard.”
That framework leaves real gaps for two systems to fill differently. A field the standard marks optional might be populated by one system and left blank by another. A message can also carry a Z-segment, a locally defined extension outside the standard entirely, used to carry a field neither system’s original vendor anticipated.
Two systems can each honestly claim to be HL7 compliant and still fail to exchange a usable message on the first try. Compliance describes the shape of a message, not what every field inside it actually contains.
That gap shows up as a real integration cost, not an abstract one. HIS and RIS Do Two Different Jobs covers another version of it, patient identity that does not reconcile between the two systems. RIS platforms and the integration engines in front of them do not all speak the same HL7 version, or the same local dialect of it. Reconciling that is ordinary integration work, not an edge case.
The practical response is to treat “we support HL7” as an opening question, not a finished answer. Which version, which trigger events, which segments are populated versus left as local extensions, and whether sample messages exist to compare against, are the specifics that turn a general claim into something testable.
Where FHIR Fits
FHIR shares a publisher with V2 but is a different kind of standard: a resource-and-REST model built for modern web APIs, rather than a message format. The two typically run alongside each other inside the same organization; neither replaces the other. FHIR in Plain Terms: How the Standard Models Clinical Data covers what a FHIR resource is, how it differs structurally from a V2 segment, and where the two standards’ responsibilities split.
HL7’s Boundary With DICOM
HL7 and DICOM solve different problems, and neither substitutes for the other. HL7 carries the clinical and administrative messages: who the patient is, what was ordered, what happened to their visit. DICOM carries the images themselves, along with the network services that move, store, and query them.
The two meet at a specific, well-documented seam in a radiology deployment, and it is worth stating precisely because it gets mis-scoped often. An order reaches a RIS as an HL7 message. From that point forward, the RIS, or a broker in front of it, exposes the scheduled procedure as a DICOM Modality Worklist entry, and the scanner queries that worklist directly over DICOM.
The HL7 side of that sequence stops at the RIS. Where a Radiology Information System Ends and PACS Takes Over walks through that handoff and the failure modes that show up around it.
That boundary matters for anyone scoping an integration. Asking whether a system speaks HL7 answers the administrative side of a deployment. It says nothing about the DICOM side, which is a separate protocol, a separate set of services, and frequently a separate vendor’s responsibility entirely.
Frequently Asked Questions
What is HL7 and how is it used?
HL7 is a family of healthcare data standards published by Health Level Seven International. In clinical and imaging deployments, “HL7” almost always means Version 2, the message-based standard that carries admissions, orders, and appointment updates between systems like a RIS, an EHR, and a laboratory system.
Is HL7 a programming language?
No. HL7 is a data and messaging standard, not a programming language. It defines how a message is structured, in segments, fields, and delimiters, and what triggers one, not how to write software. Any programming language can build or parse an HL7 message once it follows that structure.
What is an example of HL7 in healthcare?
A common example is an ADT admit message, triggered the moment a patient is registered. It carries the patient’s identifiers, the admitting provider, and the encounter details in a structured, pipe-delimited format, and a receiving system such as a RIS updates its own record the moment the message arrives.
Is HL7 a type of API?
Not in the REST sense. Version 2 is message-based: one system pushes a message to another rather than exposing endpoints to query on demand. FHIR, published by the same organization, is built around a RESTful API model instead, which is the more common source of confusion between the two standards.
Turning a Claim of HL7 Support Into Something Checkable
A vendor’s or partner’s claim to support HL7 is a starting point for due diligence, not a finished answer. Where that diligence lands depends on who owns which half of the deployment. HL7 gets the order to the department; DICOM carries the study from there.
The supported integration surface for EBM mAIn PACS® is built on native DICOM services: C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment, documented on the integrations page. HL7 messaging is not part of what EBM offers in this market today. A partner whose product needs the ADT and order messages upstream of the worklist scopes that half itself, against the RIS or integration engine the deployment already runs. EBM Fabric™ is the partner platform behind EBM mAIn PACS® that carries the finished product to market under the partner’s own brand.
On the HL7 half, a short list of questions turns a general claim into something checkable:
- Which HL7 version, specifically, and is that the version currently deployed or an older one still in production?
- Which trigger events are actually implemented: the full ADT and order sets, or a narrow subset chosen for one use case?
- Which fields and segments are populated by default, and which are left to local negotiation or a Z-segment?
- Can the vendor produce sample messages to compare against, rather than a general statement of conformance?
Ask them in that order. The version number narrows what every later answer can mean, and the sample messages are the one item on the list a brochure cannot supply.