HL7 Message Types Reference

Admit/Visit Notification

Sent when a patient is admitted to a facility (inpatient) or begins a visit (outpatient). This is the first message in a patient encounter lifecycle and triggers downstream actions: bed assignment, order entry enablement, billing account creation, and clinical system access.

Transfer a Patient

Sent when a patient is transferred from one location to another within the facility. It updates the patient's location in all downstream systems that track bed or unit assignments.

Discharge/End Visit

Sent when a patient is discharged from the facility (inpatient) or ends a visit (outpatient). It signals downstream systems to close the patient's active encounter and release associated resources.

Register a Patient

Sent when a patient is registered for an outpatient visit, emergency department encounter, or ambulatory appointment. Unlike A01 (inpatient admission), A04 is used when the patient is not assigned a bed or admitted inpatient.

Update Patient Information

Sent whenever patient demographics or visit information changes for an existing encounter. This is a delta update — the receiving system should update its patient record with the new information without creating a new encounter.

Cancel Admit/Visit Notification

Sent to cancel a previously transmitted A01 (admit) message. It instructs downstream systems to reverse the admit event and remove the patient's active encounter.

Merge Patient - Patient Identifier List

Sent to merge two patient records. The surviving patient (in PID.3) absorbs the information from the prior patient (in MRG.1). All clinical data associated with the prior patient identifier should be reassigned to the surviving patient.

General Order Message

The ORM^O01 is the legacy general order message used to communicate clinical orders from an ordering system to a fulfillment system. It carries the order details, ordering provider, and patient context.

Laboratory Order

OML^O21 is the modern laboratory order message introduced in HL7 v2.5 as the recommended replacement for ORM^O01 in lab ordering workflows. It includes a dedicated SPM (Specimen) segment that explicitly describes the specimen required, making it more precise for LIS-facing interfaces.

General Clinical Order

OMG^O19 is the IHE-recommended replacement for ORM^O01 for general clinical orders including radiology and other ancillary services. It provides a structured message framework aligned with IHE Scheduled Workflow (SWF) and is the preferred order message in new PACS/RIS integration deployments.

Unsolicited Observation Result

The primary message for delivering clinical results: lab values, radiology reports, vital signs, pathology findings, and other observations. It carries the order reference (OBR) and one or more results (OBX segments).

Unsolicited Point-of-Care Observation

ORU^R30 is an unsolicited observation result message specifically designed for point-of-care testing (POCT) devices that push results directly without a prior order. Unlike ORU^R01, it does not require a matching order to exist in the receiving system.

Unsolicited Specimen-Oriented Observation

OUL^R21 is a result message sent by the LIS to report completed lab results organized by specimen. It groups all results for a specimen together under an SPM segment, making it ideal for multi-test panels run from a single specimen collection.

Notification of New Appointment

Sent when a new appointment is booked in the scheduling system. It notifies downstream systems (RIS, procedure areas, room management) of the new appointment details including date, time, service, and patient.

Notification of Appointment Cancellation

SIU^S13 notifies downstream systems that a previously scheduled appointment has been cancelled. It triggers the receiving system (RIS, procedure area) to remove the appointment from the schedule and release associated resources.

Notification of Appointment Modification

SIU^S14 notifies downstream systems that an existing appointment has been modified — for example, rescheduled to a different date/time, changed to a different procedure, or updated with new patient or provider information.

Notification of Appointment Discontinuation

SIU^S15 notifies downstream systems that an appointment or recurring appointment series has been discontinued. It is similar to cancellation but applies specifically to recurring or active appointment slots that are being stopped going forward rather than cancelled retroactively.

Notification of Appointment Deletion

SIU^S17 instructs downstream systems to delete an appointment record entirely. It is a data correction event used when an appointment was created in error and needs to be completely removed from the receiving system's database, not just cancelled.

Notification That Patient Did Not Show Up for Scheduled Appointment

SIU^S26 notifies downstream systems that a patient did not arrive for a scheduled appointment (no-show). It allows clinical and scheduling systems to mark the appointment as a no-show and trigger appropriate follow-up workflows.

Original Document Notification and Content

Used to deliver the actual content of a clinical document along with its metadata. Unlike MDM^T01 (notification only), T02 includes the document text in one or more OBX segments.

Original Document Notification

MDM^T01 notifies downstream systems that a new clinical document has been created, without transmitting the document content. It carries document metadata in the TXA segment, allowing the receiving system to index the document and request the content separately if needed.

Document Cancel Notification

MDM^T11 notifies downstream systems that a previously sent document has been retracted or cancelled. It instructs the receiving system to remove the document from active clinical views and mark it as cancelled in the document record.

Post Detail Financial Transaction

Used to submit detailed financial transactions (charges) from a clinical department to the billing system. It carries the charge code, quantity, and service date.

Add Patient Account

BAR^P01 notifies the billing/financial system that a new patient account has been created for a visit. It carries the patient demographics, visit information, insurance details, and guarantor information needed to open a billing account.

Update Account

BAR^P05 updates an existing patient billing account with changes to charges, diagnoses, or insurance information. It is used throughout the visit lifecycle to keep the billing account current as clinical information evolves.

End Account

BAR^P06 signals the billing system to close and finalize a patient billing account. It marks the end of the financial relationship for that visit and triggers final billing or claim generation processes.

Pharmacy/Treatment Encoded Order

RDE^O11 is sent by the pharmacy system when a pharmacist has reviewed, encoded, and verified a medication order for dispensing. It represents the pharmacist's interpretation of the original prescriber order, including the specific drug product, dose, and dispensing instructions.

Pharmacy/Treatment Dispense

RDS^O13 confirms that a medication has been physically dispensed to the patient or their caregiver. It carries the actual dispensing event details including the drug dispensed, quantity, lot number, and expiration date.

General Acknowledgment

The ACK message is sent in response to any received message to confirm receipt and processing status. It can acknowledge successful processing (AA), indicate an error (AE), or reject the message (AR).

Unsolicited Vaccination Record Update

Used to report vaccination administration to an immunization information system (IIS) or state immunization registry. It carries the vaccine administered, dose details, and patient demographics.

Master File Not Otherwise Specified

MFN^M01 is the generic master file notification message used when a master file is updated and no specific MFN event type (M02-M12) applies. It communicates changes to reference data tables that must be synchronized across systems.

Master File - Staff Practitioner

MFN^M02 synchronizes provider and staff master file data across systems. It carries practitioner demographics, credentials, specialties, and organizational relationships that downstream systems need for ordering provider lookups, result routing, and access control.

Pre-Admit a Patient

Sent when a patient is pre-admitted to the facility before physically arriving. It creates a pending encounter record in downstream systems so that orders, imaging requests, and bed assignments can be prepared in advance of the patient's arrival.

Change Outpatient to Inpatient

Sent when a patient's status changes from outpatient (or emergency) to inpatient. The encounter class is upgraded and the patient is assigned a bed. This combines a change-of-class with a location update in a single message.

Change Inpatient to Outpatient

Sent when a patient's status changes from inpatient to outpatient. This is the reverse of ADT^A06. The encounter class is downgraded and the inpatient bed is released. Used when a full inpatient admission is reclassified as outpatient or observation status.

Patient Departing - Tracking

Sent when a patient temporarily leaves their assigned location — for example, leaving the floor to go to radiology, the OR, or physical therapy. This is a location tracking event, not a discharge or transfer. The patient is expected to return.

Patient Arriving - Tracking

Sent when a patient returns to their assigned location after a temporary absence. This is the counterpart to ADT^A09 (Patient Departing). It confirms the patient is back in their room or unit and location tracking is resolved.

Cancel Transfer

Sent to cancel a previously transmitted ADT^A02 (Transfer) message. It instructs downstream systems to revert the patient's location to the pre-transfer location, effectively undoing the transfer event.

Cancel Discharge/End Visit

Sent to cancel a previously transmitted ADT^A03 (Discharge) message. It re-activates the patient's encounter in all downstream systems, signalling that the patient is still admitted and the discharge was entered in error.

Pending Admit

Sent to notify downstream systems that a patient admission is expected in the near future. This is an advisory notification only — it does not create an encounter record. It alerts bed management, nursing, and ancillary systems to prepare for the incoming patient.

Pending Transfer

Sent to notify downstream systems that a patient transfer is imminent but has not yet occurred. Like A14, this is advisory — it notifies the destination unit to prepare a bed and the nursing team to prepare for the incoming patient.

Pending Discharge

Sent to notify downstream systems that a patient discharge is anticipated. This is an advance notification allowing downstream systems and care coordinators to initiate discharge workflows — medication reconciliation, follow-up scheduling, transport arrangements — before the official discharge (A03) is entered.

Swap Patients

Sent when two patients exchange beds or locations simultaneously. A17 carries information for both patients in a single message — it is one of the few ADT messages that contains PID and PV1 segments for two patients.

Delete a Patient Record

Sent to delete a visit record that was created in error. Unlike A11 (cancel admit), A23 is a hard delete instruction — it signals that the visit never should have existed and should be completely removed from downstream systems.

Add Person Information

Sent to add a new person record to a Master Patient Index (MPI) or downstream system without creating a visit or encounter. It carries person-level demographic information only — there is no PV1 visit context.

Delete Person Information

Sent to delete a person-level record from the Master Patient Index or downstream system. This is a destructive operation that removes the patient's identity record, not just a visit. It should only be used for records created in error.

Update Person Information

Sent to update person-level demographics in the Master Patient Index without visit context. It is the person-level equivalent of ADT^A08 (Update Patient Information) and is used when there is no active encounter.

Merge Patient Information - Patient ID Only

Sent to merge duplicate patient identifiers while retaining the demographics from the surviving record. The prior patient's identifier (in MRG.1) is merged into the surviving patient (in PID.3). Only patient identifiers are merged — visit records remain associated with the surviving patient.

Move Account Information

Sent to move an account (visit/encounter) from one patient record to another without merging the patients themselves. The PID segment identifies the patient the account is moving TO, and the MRG segment identifies the patient the account is moving FROM.

Change Patient Identifier List

Sent when a patient's identifier — most commonly their Medical Record Number (MRN) — is changed. The PID segment contains the new identifier; the MRG segment contains the old identifier that is being replaced. All downstream systems must update their records to use the new identifier.