HL7 Message Types – Converting and Standardizing Patient Data to an API Payload

HL7 Message Types & Structure

HL7 version 2 is a messaging protocol that allows different software applications in healthcare to communicate with one another. The HL7 message type defines the high-level purpose and grouping of the message. Here are some commonly used HL7 message types:

ACK – General acknowledgment
ADT – Admit, Discharge, Transfer
BAR – Add/change billing account
DFT – Detailed financial transaction
MDM – Medical document management
MFN – Master files notification
ORM – Order (Pharmacy/treatment)
ORU – Observation result (unsolicited)
QRY – Query, original mode
RAS – Pharmacy/treatment administration
RDE – Pharmacy/treatment encoded order
RGV – Pharmacy/treatment give
SIU – Scheduling information unsolicited
VXU – Unsolicited vaccination record update

HL7 defines quite a few message types. You can check out the complete list here. Comparisons can be made between HL7 message types and HL7 FHIR resource categories.

HL7 message types are combined with a trigger event, which initiates writing and sending the message. The message type and trigger event format is: {messageType_triggerEvent}. This data will be present in every HL7 message in MSH-9 (the MSH segment, field position 9).

HL7 messages are constructed with a predefined sequence of required and optional message segments. Message segments also have defined fields that are required and optional and appear in a specified order.

HL7 PID Segment

The PID (patient identification information) segment is present in most HL7 message types and contains permanent identifying and demographic information that, for the most part, will not frequently change. The segment is critical and the primary means of communicating patient identification information.

MSH|^~\&|INTELY|INTELY|CONNECT||20210527135249||ADT^A05|Q292942960T328585861|P|2.3||||||8859/1
EVN
PID|1|8675309^^^MRN^MRN|8338178675309^^^MRN^MRN||PatientLname^PatientFname^^^^^Current||20000101|F|||123^^Health Level Seven Ln^FL^33578^USA^home^^Tampa|||(999)999-9999^Business^TEL|English|||19098765439^^^FIN^FIN|||||||0
PV1|1|P|CLINIC^^^HS1^^Ambulatory(s)^CLINIC|EL|||1099999999^Ross^Bob^B^^MD|||COV||||1|||1099999999^Ross^Bob^B^^MD|PR||HM|||||||||||||||||||HS1||FL

Many healthcare software providers require utilizing HL7 v2 to integrate and automate data workflows fully. The task of setting up these integrations is no minor feat. It requires engineers with a specialized skillset and often more troubleshooting than anticipated. Check out the benefits of partnering with an interoperability platform with out-of-the-box HL7 interfaces.

FHIR Resources

HL7 FHIR (Fast Healthcare Interoperability Resources) is a newer interoperability standard based on REST, which describes how individual transactional units (FHIR Resources) can be easily shared between systems. You may have already discovered that Intely can convert HL7 v2 to FHIR with sophisticated mapping and transformation.

Here are some common HL7 FHIR Resources:

Patient
Practitioner
Organization
Location
Appointment
Encounter
Condition
AllergyIntolerance
Observation

You can check out a complete list on HL7 FHIR’s website here.

FHIR Patient Resource

The HL7 FHIR Patient resource contains demographic, administrative, and other identifying information about an individual receiving healthcare services. It covers the “who” information about the patient.

Since HL7 segments loosely relate to HL7 FHIR resources, we can deduce that the PID segment in many HL7 message types can be mapped pretty closely to the HL7 FHIR Patient resource.

The FHIR Patient resource is significantly easier to use as a method of communication between systems for a few reasons:

1. The FHIR Patient resource is an individual transactional unit of information instead of a PID Segment, which is contained within an HL7 Message with many other segments.
2. HL7 FHIR uses HTTP, a significantly easier protocol than MLLP (Minimum Lower Layer Protocol), which is what HL7 version 2 uses to share messages.
3. The FHIR Resource is in JSON or XML format and can be easily sent through a request payload of an API.

Interested in learning more about converting healthcare data standards? Request a demo of Intely’s Connect and Data Mapping solution today.