HL7 Reference | Innovar Healthcare

Working with HL7 version 2

A plain-language guide to the messaging standard that moves clinical data between hospital systems, and how to read it, build it, and route it through BridgeLink.

HL7 version 2 is the most widely deployed messaging standard in healthcare. It defines how systems such as a registration desk, a lab analyzer, a pharmacy, and an electronic health record exchange events like an admission, an order, or a test result. A message is plain text: lines of fields separated by a small set of delimiter characters. That simplicity is why the standard has survived since the late 1980s and still carries the majority of interface traffic in most hospitals today.

The sample below is a typical result message. Each line is a segment; the characters between values are the delimiters that separate one field from the next.

MSH|^~\&|LAB|EASTSIDE|EHR|MAIN|20260611103200||ORU^R01|MSG00021|P|2.5.1
PID|||900418^^^EASTSIDE||RIVERA^MARIA||19840502|F
OBR|1||L24-5567|CBC^Complete Blood Count
OBX|1|NM|WBC^White Blood Cells||6.4|10*3/uL|4.0-11.0|N

You don't have to memorize the layout, the rest of this reference breaks it down. Start with message structure to learn how segments, fields, and delimiters fit together.

All content here is written from the published HL7 v2.x standard, which describes a public interoperability specification. HL7® and Health Level Seven® are trademarks of Health Level Seven International; BridgeLink is independent and not affiliated with or endorsed by HL7 International.

How an HL7 message is put together

Every HL7 v2 message is built from the same four layers: segments, fields, components, and subcomponents, held together by five delimiter characters.

Segments and the line structure

A message is a sequence of lines, and each line is a segment. A segment begins with a three-character identifier that names its purpose: MSH for the message header, PID for patient identification, OBX for a single observation, and so on. Segments appear in an order defined by the message's grammar, and some may repeat. In transmission each segment ends with a carriage return.

The five delimiters

Within a segment, data is separated by delimiter characters rather than fixed column positions. The standard reserves five of them, and they are declared at the very start of every message so a receiver knows how to take it apart:

Delimiter	Default	Separates
Field	\|	One field from the next within a segment
Component	^	Pieces of a single field (e.g. last vs. first name)
Repetition	~	Repeated values in one field
Escape	\	Marks an escape sequence for reserved characters
Subcomponent	&	Pieces within a component

So a field can carry structure of its own. A patient name field might read RIVERA^MARIA^J, family name, given name, and middle initial as three components. An empty value is simply nothing between two delimiters, which is why you often see runs like ||| where intermediate fields are not populated.

Reading a field address

Fields are referred to by segment and position. PID-5 means the fifth field of the PID segment (the patient name); PID-5.1 drills into its first component. The field separator that follows the segment name counts as the boundary of field 1, which leads to one famous quirk in the header, below.

The MSH header

Every message opens with an MSH (Message Header) segment. It is the envelope: who sent the message, who should receive it, what kind of message it is, and which version of the standard it follows. MSH is also where the delimiters are declared, which makes its first two fields special.

MSH|^~\&|LAB|EASTSIDE|EHR|MAIN|20260611103200||ORU^R01|MSG00021|P|2.5.1

Field	Name	In the example
MSH-1	Field separator	The \| right after MSH is the value
MSH-2	Encoding characters	`^~\&`, the other four delimiters
MSH-3	Sending application	LAB
MSH-4	Sending facility	EASTSIDE
MSH-5	Receiving application	EHR
MSH-6	Receiving facility	MAIN
MSH-7	Date/time of message	20260611103200
MSH-9	Message type	ORU^R01
MSH-10	Message control ID	MSG00021, unique per message
MSH-11	Processing ID	P (production)
MSH-12	Version ID	2.5.1

Because MSH-1 holds the field separator itself, the field count in MSH is offset by one compared with every other segment. It is the single most common source of off-by-one bugs when people first parse HL7 by hand.

Data types

Each field has a defined data type that tells you how to interpret its components. A few you will see constantly: ST (string), NM (numeric), TS or DTM (timestamp), XPN (person name), XAD (address), CX (identifier with an assigning authority), and CE/CWE (a coded value paired with its code system). The data type is what justifies the component breakdown: an XPN name expects family and given names in specific component slots.

The message families you'll meet most

MSH-9 names the message type and trigger event, for example ADT^A01. The type is the broad category; the trigger event is the specific real-world thing that happened. Open any family for its typical structure, trigger events, key segments, and a worked example message.

ADT: Admit, Discharge, Transfer

Communicates patient demographics and movement through a facility, the most pervasive feed in healthcare integration.

Almost every clinical system needs to know who the patient is and where they are, so ADT drives registration, bed management, results routing, and billing. The trigger event in MSH-9 states exactly what happened.

Typical structure

MSH  # header, ADT^A01
EVN  # event type and timing
PID  # patient identity
PD1  # additional demographics (optional)
NK1  # next of kin (repeats)
PV1  # visit
PV2  # visit detail (optional)
AL1  # allergies (repeats)
DG1  # diagnoses (repeats)
IN1  # insurance (repeats)

Trigger events

Event	Meaning
A01	Admit / visit notification
A02	Transfer a patient
A03	Discharge / end visit
A04	Register a patient (outpatient)
A05	Pre-admit a patient
A08	Update patient information
A11 / A12 / A13	Cancel admit / transfer / discharge
A40	Merge patient identifier list

Key segments

Segment	Purpose
EVN	Event type and timing
PID	Patient identity and demographics
PV1	Visit: class, location, attending
PV2	Admit reason, expected dates
NK1	Next of kin and contacts
AL1 / DG1	Allergies and diagnoses
GT1 / IN1	Guarantor and insurance

Example: ADT^A01 (admit)

MSH|^~\&|ADT|MERCY|EHR|MAIN|20260611120000||ADT^A01|MSG0001|P|2.5.1
EVN|A01|20260611120000
PID|1||5598^^^MERCY||DOE^JOHN^A||19780212|M|||123 MAIN ST^^MOBILE^AL^36604
NK1|1|DOE^JANE|SPO||(251)555-0143
PV1|1|I|3W^312^A||||SMITH^ROBERT|||MED||||ADM|||||V100
DG1|1||I10^Essential hypertension^I10C|||A
IN1|1|BCBS01|BCBS|Blue Cross Blue Shield||||GRP12345

ORU: Observation Result

Reports observations (lab values, vital signs, and imaging or report narratives), usually unsolicited.

The common trigger is R01. An OBR describes the battery that was performed and each OBX carries a single result with its units and reference range. Results for several orders can appear in one message as repeating OBR/OBX groups.

Typical structure

MSH  # header, ORU^R01
PID  # patient identity
PV1  # visit (optional)
OBR  # the order / battery
OBX  # result value (repeats)
NTE  # comment (optional)

Key segments

Segment	Purpose
PID	Patient identity
OBR	The ordered test or battery and its status
OBX	One observation value, units, range, flags
SPM	Specimen detail (where relevant)
NTE	Free-text comments

Example: ORU^R01 (CBC results)

MSH|^~\&|LAB|EASTSIDE|EHR|MAIN|20260611103200||ORU^R01|MSG0021|P|2.5.1
PID|1||900418^^^EASTSIDE||RIVERA^MARIA||19840502|F
OBR|1||L24-5567|CBC^Complete Blood Count|||20260611100500
OBX|1|NM|WBC^White Blood Cells||6.4|10*3/uL|4.0-11.0|N|||F
OBX|2|NM|HGB^Hemoglobin||13.8|g/dL|12.0-16.0|N|||F
OBX|3|NM|PLT^Platelets||95|10*3/uL|150-400|L|||F

ORM / OML / OMG: Orders

Places, changes, or cancels an order for a lab, pharmacy, imaging, or procedure service.

Older interfaces use the general ORM^O01; newer ones use domain-specific types such as OML^O21 (lab) and OMG^O19 (general clinical). Every order is anchored by an ORC (common order) whose ORC-1 control code says what to do, paired with a detail segment such as OBR.

Typical structure

MSH  # header, ORM^O01
PID  # patient identity
PV1  # visit (optional)
ORC  # common order: control, identifiers
OBR  # order detail (repeats per order)
NTE  # comment (optional)

Common order-control codes (ORC-1)

Code	Meaning
NW	New order
OK	Order accepted
CA	Cancel order
DC	Discontinue order
XO	Change order
HD / RL	Hold / release order

Key segments

Segment	Purpose
ORC	Order control, placer/filler numbers, ordering provider
OBR	What is being ordered and when
NTE	Order comments and instructions

Example: ORM^O01 (new lab order)

MSH|^~\&|EHR|MAIN|LAB|EASTSIDE|20260611095500||ORM^O01|MSG0044|P|2.5.1
PID|1||900418^^^EASTSIDE||RIVERA^MARIA||19840502|F
ORC|NW|PO-7781|||||||20260611095500|||SMITH^ROBERT
OBR|1|PO-7781||CBC^Complete Blood Count|||20260611095500

ACK: Acknowledgment

Confirms that a message was received, and whether it was processed, errored, or rejected.

An acknowledgment is a small message: an MSH plus an MSA that echoes the original message's control ID and reports a code. An ERR segment is added when something went wrong.

Typical structure

MSH  # header, ACK
MSA  # ack code + original control ID
ERR  # error detail (only on failure)

Acknowledgment codes (MSA-1)

Code	Meaning
AA / CA	Accept: processed (AA) or received (CA)
AE / CE	Error: a problem occurred
AR / CR	Reject: message refused

The C* codes appear only in enhanced acknowledgment mode, at the accept (commit) layer; the A* codes carry the application result in both original and enhanced mode.

Example: ACK (accept)

MSH|^~\&|EHR|MAIN|ADT|MERCY|20260611120002||ACK^A01|ACK0001|P|2.5.1
MSA|AA|MSG0001

Example: ACK (error)

MSH|^~\&|EHR|MAIN|ADT|MERCY|20260611120002||ACK^A01|ACK0002|P|2.5.1
MSA|AE|MSG0001
ERR|||207^Application internal error^HL70357|E

MDM: Medical Document Management

Moves transcribed documents (notes, reports, summaries) together with their status.

A TXA segment carries the document header (type, identifiers, completion status) and OBX segments carry the content. The trigger event states what happened to the document: created, edited, replaced, or cancelled.

Typical structure

MSH  # header, MDM^T02
EVN  # event timing
PID  # patient identity
PV1  # visit (optional)
TXA  # document header
OBX  # document content (repeats)

Trigger events

Event	Meaning
T01	Original document notification
T02	Original document notification and content
T03	Document status change
T05 / T06	Addendum (notification / with content)
T07 / T08	Edit (notification / with content)
T09 / T10	Replacement (notification / with content)
T11	Cancel notification

Key segments

Segment	Purpose
EVN	Event timing
TXA	Document type, IDs, completion status
OBX	The document body (often text or base64)

Example: MDM^T02 (document with content)

MSH|^~\&|TRANSCRIPT|MERCY|EHR|MAIN|20260611131500||MDM^T02|MSG0099|P|2.5.1
EVN|T02|20260611131500
PID|1||5598^^^MERCY||DOE^JOHN^A||19780212|M
TXA|1|CN^Consult Note|TX||||20260611130000|||||DOC-55012|||||AU
OBX|1|TX|11488-4^Consultation note^LN||Patient seen in cardiology for evaluation of hypertension...||||||F

DFT / BAR: Financial

Reports charges and other financial events (DFT) and establishes the billing accounts they attach to (BAR).

DFT^P03 carries one or more FT1 financial-transaction segments: the charges, credits, and adjustments posted against a visit. BAR messages manage the billing account itself (P01 adds a patient account, P05 updates one), including guarantor and insurance.

Typical structure (DFT^P03)

MSH  # header, DFT^P03
EVN  # event timing
PID  # patient identity
PV1  # visit (optional)
FT1  # financial transaction (repeats)

Key segments

Segment	Purpose
FT1	A single charge: date, type, code, quantity, amount
PID	Patient the charge belongs to
GT1 / IN1	Guarantor and insurance (in BAR account setup)

Example: DFT^P03 (charge)

MSH|^~\&|BILLING|MERCY|FIN|MAIN|20260611140000||DFT^P03|MSG0120|P|2.5.1
EVN|P03|20260611140000
PID|1||5598^^^MERCY||DOE^JOHN^A||19780212|M
FT1|1|||20260611|20260611|CG|85025^CBC^CPT|||1|45.00

SIU: Scheduling Information

Communicates appointment activity: booking, rescheduling, modifying, and cancelling.

The SCH segment carries the appointment's identifiers, timing, and status, with patient, resource, and location detail in the accompanying RGS and AIS/AIG/AIL/AIP segments. The trigger event says what changed.

Typical structure

MSH  # header, SIU^S12
SCH  # appointment timing and status
PID  # patient identity
PV1  # visit (optional)
RGS  # resource group
AIS  # appointment service / procedure
AIL  # location resource
AIP  # personnel resource

Trigger events

Event	Meaning
S12	New appointment booking
S13	Appointment rescheduling
S14	Appointment modification
S15	Appointment cancellation
S26	Patient did not show

Key segments

Segment	Purpose
SCH	Appointment timing, duration, status
RGS	Groups the resources for the appointment
AIS / AIG / AIL / AIP	Service, general resource, location, personnel

Example: SIU^S12 (new booking)

MSH|^~\&|SCHED|CLINIC|EHR|MAIN|20260611090000||SIU^S12|MSG0200|P|2.5.1
SCH|APT-3321|||||||OFFICE^Office Visit|30|MIN|^^^20260615103000^20260615110000||||||||||||||BOOKED
PID|1||5598^^^CLINIC||DOE^JOHN^A||19780212|M
RGS|1|A
AIP|1||SMITH^ROBERT^MD|D^Physician

VXU: Vaccination Record Update

Sends an unsolicited immunization record, typically to a state or regional registry.

Administered vaccines live in RXA segments, with RXR describing route and site and OBX carrying supporting observations such as VIS dates or funding source. An ORC ties each administration to an order record.

Typical structure

MSH  # header, VXU^V04
PID  # patient identity
PD1  # registry / sharing flags (optional)
NK1  # parent / guardian (optional)
ORC  # order record
RXA  # administered vaccine (repeats)
RXR  # route and site
OBX  # supporting observations

Key segments

Segment	Purpose
RXA	Vaccine administered: code, date, amount, lot
RXR	Route and body site
OBX	VIS dates, funding source, eligibility

Example: VXU^V04 (immunization)

MSH|^~\&|EHR|CLINIC|IIS|STATE|20260611150000||VXU^V04|MSG0301|P|2.5.1
PID|1||7781^^^CLINIC||LEE^EMMA||20200804|F
ORC|RE||PO-9012
RXA|0|1|20260611150000||08^Hep B^CVX|0.5|mL||00^New record^NIP001||||||LOT4821
RXR|IM^Intramuscular|LT^Left thigh

MFN: Master Files Notification

Keeps reference data (test catalogs, charge masters, location and staff dictionaries) in sync between systems.

An MFI identifies which master file is being updated and an MFE entry (with its record-level action) appears for each item, followed by the entity segments that describe it. The receiver replies with an MFK acknowledgment.

Typical structure

MSH  # header, MFN^M01
MFI  # which master file
MFE  # entry + action (repeats)
...  # entity segment(s) per entry

Key segments

Segment	Purpose
MFI	Master file being updated and update mode
MFE	One entry with its action (MAD add, MUP update, MDL delete)
MFK	Acknowledgment returned by the receiver

Example: MFN^M01 (master file update)

MSH|^~\&|LIS|LAB|EHR|MAIN|20260611160000||MFN^M01|MSG0400|P|2.5.1
MFI|CDM^Charge Description Master||UPD||20260611160000|AL
MFE|MAD|||85025^CBC^CPT|CE

QBP / RSP: Queries

Lets a system ask for data on demand instead of waiting for an unsolicited feed.

The modern pattern is QBP (query by parameter), answered by RSP (segment-pattern response). The query parameters live in a QPD segment and an RCP controls the response; the reply carries an MSA, a QAK query-acknowledgment, and the requested data segments. Legacy interfaces use original-mode queries such as QRY with responses like ADR or DSR.

Typical structure

MSH  # header, QBP^Q22
QPD  # query parameters
RCP  # response control
# --- response ---
MSH  # header, RSP^K22
MSA  # acknowledgment
QAK  # query status
QPD  # echoed parameters
PID  # returned data (repeats)

Key segments

Segment	Purpose
QPD	Defines what is being asked
RCP	Controls how much is returned and how
QAK	Reports query success and result count

Example: QBP^Q22 and its RSP

MSH|^~\&|EHR|MAIN|MPI|ENTERPRISE|20260611170000||QBP^Q22|MSG0500|P|2.5.1
QPD|Q22^Find Candidates|QRY01|@PID.5.1^Doe~@PID.5.2^John
RCP|I|25^RD
# response
MSH|^~\&|MPI|ENTERPRISE|EHR|MAIN|20260611170001||RSP^K22|MSG0501|P|2.5.1
MSA|AA|MSG0500
QAK|QRY01|OK|Q22^Find Candidates|1
QPD|Q22^Find Candidates|QRY01|@PID.5.1^Doe~@PID.5.2^John
PID|1||5598^^^MERCY||DOE^JOHN^A||19780212|M

A field-level look at the everyday segments

Segments are grouped here the way they tend to appear in real messages (control segments, the patient and visit block, financial segments, and the order/result block), with the fields you'll touch most often. Field positions can vary by HL7 version and local profile, so always confirm against the version in MSH-12.

Control & acknowledgment segments

EVN: Event Type

Records what event triggered an ADT message and when it was logged.

Field	Name	Notes
EVN-2	Recorded date/time	When the event was entered
EVN-4	Event reason code	Why the event occurred
EVN-5	Operator ID	Who entered it
EVN-6	Event occurred	When the event actually happened

MSA: Message Acknowledgment

Field	Name	Notes
MSA-1	Acknowledgment code	AA/AE/AR or CA/CE/CR
MSA-2	Message control ID	Echoes MSH-10 of the original message

ERR: Error

Accompanies a negative acknowledgment to explain a failure: ERR-2 points to the error location, ERR-3 gives the HL7 error code, and ERR-4 the severity.

NTE: Notes and Comments

A general free-text segment that attaches to many others (orders, results, and more). NTE-3 holds the comment text and NTE-2 identifies its source.

Patient & visit segments

PID: Patient Identification

Field	Name	Notes
PID-3	Patient identifier list	The medical record number, with assigning authority
PID-5	Patient name	XPN: family^given^middle
PID-7	Date of birth	YYYYMMDD
PID-8	Administrative sex	Coded value
PID-11	Patient address	XAD: street^^city^state^zip
PID-18	Patient account number	Ties demographics to the visit's billing

PD1: Patient Additional Demographics

Carries longer-lived demographics that aren't visit-specific, such as the patient's primary care provider (PD1-4) and living arrangement. Often sent alongside PID in ADT messages.

PV1: Patient Visit

Field	Name	Notes
PV1-2	Patient class	Inpatient, outpatient, emergency, etc.
PV1-3	Assigned location	Point of care, room, bed, facility
PV1-7	Attending doctor	Provider id and name
PV1-19	Visit number	Identifier for this encounter
PV1-44	Admit date/time	When the visit began

PV2: Patient Visit, Additional Information

Extends PV1 with context about the stay.

Field	Name	Notes
PV2-3	Admit reason	Why the patient is being seen
PV2-8	Expected admit date/time	Planned start
PV2-9	Expected discharge date/time	Planned end
PV2-12	Visit description	Free-text description of the visit

NK1: Next of Kin / Associated Parties

Field	Name	Notes
NK1-2	Name	XPN of the contact
NK1-3	Relationship	Spouse, parent, guardian, etc.
NK1-4	Address	Contact address
NK1-5	Phone number	Contact phone
NK1-7	Contact role	Emergency contact, guarantor, etc.

AL1: Patient Allergy Information

Field	Name	Notes
AL1-2	Allergen type code	Drug, food, environmental, etc.
AL1-3	Allergen code / description	What the patient is allergic to
AL1-4	Allergy severity code	Severe, moderate, mild
AL1-5	Allergy reaction	Observed reaction(s)

DG1: Diagnosis

Field	Name	Notes
DG1-3	Diagnosis code	ICD-10-CM or other coding system
DG1-4	Diagnosis description	Text description
DG1-5	Diagnosis date/time	When diagnosed
DG1-6	Diagnosis type	Admitting, working, or final

Financial segments

GT1: Guarantor

Identifies the party responsible for the bill: GT1-3 guarantor name, GT1-5 address, GT1-6 phone, and GT1-11 the guarantor's relationship to the patient.

IN1: Insurance

Field	Name	Notes
IN1-2	Insurance plan ID	The plan being billed
IN1-3	Insurance company ID	Payer identifier
IN1-4	Insurance company name	Payer name
IN1-8	Group number	Employer or plan group
IN1-16	Name of insured	Policy holder
IN1-36	Policy number	Member / policy identifier

Two companion segments extend it: IN2 (employment and dependent detail) and IN3 (certification / pre-authorization).

FT1: Financial Transaction

Carries an individual charge inside a DFT message: FT1-4 transaction date, FT1-6 transaction type (charge, credit), FT1-7 the transaction code (the charged procedure, supply, or test), and FT1-10 the quantity.

Order & result segments

ORC: Common Order

Field	Name	Notes
ORC-1	Order control	NW (new), CA (cancel), XO (change), etc.
ORC-2	Placer order number	Ordering system's identifier
ORC-3	Filler order number	Performing system's identifier
ORC-5	Order status	Status of the order
ORC-12	Ordering provider	Who placed the order

OBR: Observation Request

Field	Name	Notes
OBR-2	Placer order number	The ordering system's identifier
OBR-3	Filler order number	The performing system's identifier
OBR-4	Universal service ID	What was ordered, as a coded value
OBR-7	Observation date/time	When the specimen/observation was taken
OBR-25	Result status	Preliminary, final, corrected, etc.

OBX: Observation / Result

Field	Name	Notes
OBX-2	Value type	NM, ST, CE, and others (how to read OBX-5)
OBX-3	Observation identifier	What was measured, as a coded value
OBX-5	Observation value	The actual result
OBX-6	Units	Units of measure
OBX-7	Reference range	Normal range for interpretation
OBX-8	Abnormal flags	N normal, H high, L low, and so on
OBX-11	Observation result status	F final, P preliminary, C corrected

SPM: Specimen

Describes the specimen behind a set of results: SPM-2 specimen ID, SPM-4 specimen type, and SPM-17 collection date/time.

Specialized segments you'll also encounter

Segment	Name	Appears in
MSH	Message Header	Every message (see message structure)
TXA	Transcription Document Header	MDM documents
SCH	Scheduling Activity Information	SIU scheduling
RXA	Pharmacy/Treatment Administration	VXU immunizations, med administration
RXR	Pharmacy/Treatment Route	Route and site of administration
RXE	Pharmacy/Treatment Encoded Order	Pharmacy orders
MRG	Merge Patient Information	ADT merge events (A40)
PR1	Procedures	Procedure reporting
ROL	Role	Care-team roles on a patient or order
Zxx	Custom (Z) segments	Site-specific local extensions

Exact field positions and the segments a given message expects vary by HL7 version (2.3, 2.5.1, and 2.8 differ in places) and by each site's local conformance profile. Always confirm against the version named in MSH-12 and the interface's own specification.