HL7 for Busy Professionals

by Rahul Bhagat

  Error Segment (ERR)

  The ERR segment is included in an acknowledgement message when there is an error to report. This segment is used to provide more details about the error condition.

  For each error condition, a separate ERR segment is created. In the example, we have two ERR segments, which implies there were two issues in the message.

  ERR||PID^5|101^Required field missing|E

  ERR||PID^7|102^Data type error|E

  There are twelve fields in this segment. Two are required and the rest are optional.

  ERR-2: Error Location

  This is an optional field but it almost always has a value. It identifies the segment and field where the error happened.

  In our example, for the two ERR segments, the values are PID-5 and PID-7. This means there was a problem with the “Patient Name” (PID-5) field and the “Patient Date of Birth” (PID-7) field. It looks like we are missing the patient name and the date of birth was sent in the wrong format.

  ERR-3: HL7 Error Code

  This is a required field that contains a three-digit error code. HL7 defines a table of general error conditions (in HL7 spec) with a code number for each condition. The value in our example is from that table. For example, if a required field is missing in the message, then the value in ERR-3 is 101.

  ERR-4: Severity

  This is another required field, which contains a single character, for the “error severity” code. There are only three values for this field, I (Information), W (Warning) and E (Error). Usually, if we are sending error information, it is because there was an error. No one bothers with information and warning messages. The value here is almost always E.

  9. Data Segments

  Now we come to the meat and potatoes of HL7 messaging. Data segments form the body of an HL7 message. They carry patient and clinical data, the thing that matters the most. Rest of the message is just the box, styrofoam packaging and the shipping label.

  The main purpose of a data segment is to group together similar data in one place. For example, all the information about a patient is grouped together in a segment called PID (Patient Identification segment). Actually, there are so many data fields about the patient that there is one more segment, PD1, for additional patient data.

  Similarly, all patient visit information is in PV1, allergy info is in AL1, insurance information is in IN1 and so on. Each segment is described in detail in the HL7 spec.

  There is another kind of data segment that you will occasionally come across in a message. These are locally defined segments or what we call Z segments. HL7 allows users to define their own segment if they want to send additional information for which there is no field defined by HL7. Unfortunately, this is a much abused privilege. I have come across messages where you have the bare minimum mandatory segments, followed by rows of Z segments with the actual data.

  In this chapter, we will look at some of the most commonly used data segments.

  There are close to 150 data segments defined in the HL7 spec. Not even the experts are expected to know about all of them. It is always a good idea to keep the HL7 specs handy so whenever the need arises, you can quickly look up a particular segment and its details.

  For a general understanding, you only need to know about a few of these data segments. The 80-20 rule applies to data segments too. Only about twenty percent of data segments are actually used in eighty percent of messages. So for a busy professional like you, it makes sense to invest the limited time you have, in that twenty percent.

  There are three message types that account for most of that twenty percent.

  • ADT (Patient Administration – Chapter 3)

  • ORM (Order Entry – Chapter 4)

  • ORU (Observation Reporting – Chapter 7)

  If you get a good handle on these, I’m sure you can handle any exotic message that gets thrown at you. The HL7 spec is your friend and don’t forget to ask the vendor for their interface spec. Between these two documents, you can figure out almost any HL7 message.

  ADT (Patient Administration)

  Patient Administration messages are at the heart of HL7 messaging. I am not sure how they came to be known as ADT messages, probably it is a reference to three commonly occurring trigger events – Admit, Discharge & Transfer.

  This message type is all about the patient. Its primary use is to make sure various systems in a healthcare organization are in sync with patient info, such as the patient status in the hospital, contact info, medication, allergies, etc.

  In a typical healthcare organization, there is usually an EMR or a registration system that manages patient records and updates other ancillary clinical systems through HL7 ADT messages. It is through these messages that a patient’s status and information is kept synchronized across the organization and beyond.

  From the moment a person starts interacting with the hospital, HL7 messages start getting generated in response to real world events (trigger events). This is how other systems always have the latest information about a patient.

  Let’s consider an example. A person walks into the outpatient unit of a hospital. The first thing that happens is patient registration at the front desk. This real world event is a trigger event, Event A04 (Register a Patient). When it happens, the system automatically generates an ADT^A04 message to let other systems know that a new patient has been registered with the hospital.

  Let’s say all is not looking well for the patient and the doctor decides to keep him in the hospital for observation. This means the person is getting admitted to the hospital. This is another trigger event, Event A01 (Admit/Visit Notification). This event will cause another HL7 message, ADT^A01, to be generated. If the patient is getting admitted to the hospital, it means he will need a bed, a nurse will be assigned for care and medication will have to be ordered. All the ancillary systems, nursing, bed management, pharmacy, finance, food services etc. will receive the ADT^A01 message, so that they know about this new patient and any necessary follow-up action can be taken by them.

  The next day, the patient is doing much better and the doctor says he is free to go home. He is given his medication, someone arrives to take him home and he is discharged by the administration system. This is another trigger event, Event A03 (Discharge/End Visit). This trigger event generates an HL7 message, ADT^A03, so that other systems can update their records and close the patient account. We don’t want a situation where someone is ordering controlled drugs from pharmacy on behalf of a patient who has already been discharged!

  This was a simple example. In real life, between registration and discharge, a patient’s record can undergo a lot of changes. The doctor could change, the patient could get transferred to another unit/bed or the patient’s contact could change. All these changes have corresponding trigger events that generate HL7 messages. In fact, there are over sixty different ADT trigger events, everything from cancel visit to delete record. But there is no reason to be alarmed, most of these trigger events are barely used. The 80-20 cornucopia keeps on giving. There are only a handful of ADT trigger events that are commonly used.

  After Registration (A04), Admit (A01) and Discharge (A03), the next important ADT trigger event is A08 (Update Patient Information). This event is triggered whenever there is a change in the patient record. An “A O Eight” (that’s how insiders pronounce A08) is a very heavily used ADT message.

  Then there are other ADT trigger events worth knowing - transfer patient (A02), cancel admit (A11), cancel discharge (A13) and pre-admit (A05) are some of the examples.

  One very important ADT trigger event is a merge event. This occurs in situations where, by mistake, two patient records have been created for the same person and the records have to be merged into one. Merge is a complex topic so we will address it separately in the next chapter.

  Although each ADT trigger event generates a slightly different message, if you look at their message structure, you will notice that most ADT messages follow a common pattern.

>   After the control segments (MSH, EVN etc.) in the head of the message, the body starts with patient identification and related information (PID, PD1, NK1). This is followed by information about patient visit (PV1, PV2) and then you have all kind of other segments for allergy, diagnosis, procedure, insurance etc.

  Of all the segments in ADT messages, PID (Patient Identification) and PV1 (Patient Visit) are the two most important data segments. These segments have a lot of fields between them but then again, the 80-20 rule is there to help. Only a small subset of fields in these segments is commonly used.

  PID – Patient Identification Segment

  The PID segment, as the name implies, carries information about the patient. It is one of the most frequently used segments and usually appears right after the control segments.

  If you have a raw HL7 message and you want to find out the details of the patient, you look in the PID segment. This is where the patient’s name, age, address and other demographic information is. There is another segment, PD1 (Patient Additional Demographic segment), for additional patient information but that segment is rarely used, if ever.

  Let’s parse the PID segment from our example message and look at its fields.

  PID|1||PAT416^^^HEALTH_ID||SEBELUS^KANSAS||194801150600|M|||123 SESAME ST^^TORONTO^ON^A1A 2B2^CANADA||(416)888-8088||ENGLISH|M||PAT_AC_721914

  PID-1: 1 (Sequence Number)

  PID-2:

  PID-3: PAT416^^^HEALTH_ID (Patient Identifier List)

  PID-4:

  PID-5: SEBELUS^KANSAS (Patient Name)

  PID-6:

  PID-7: 194801150600 (Date/Time of Birth)

  PID-8: M (Administrative Sex)

  PID-9:

  PID-10:

  PID-11: 123 SESAME ST^^TORONTO^ON^A1A 2B2^CANADA (Address)

  PID-12:

  PID-13: (416)888-8088 (Phone Number – Home)

  PID-14:

  PID-15: ENGLISH (Primary Language)

  PID-16: M (Marital Status)

  PID-17:

  PID-18: PAT_AC_721914 (Patient Account Number)

  PID segment has thirty nine fields but only two are mandatory, PID-3 (Patient ID) & PID-5 (Patient Name). All the other fields are optional. In the example segment we chose not to send any information after field eighteen. That’s why the segment ends at PID-18 and implies that the remaining fields are empty.

  PID-2/PID-3/PID-4: Patient Identifier Fields

  Patient identifier is a very important field for healthcare applications. Usually, the field holds the MRN (medical record number), which is assigned to a patient at the time of registration. But there are other identifiers, such as billing account number, health card number or SSN that can be used to uniquely identify a patient.

  There are three fields for patient identifier in the PID segment but only one, PID-3, is commonly used. Both PID-2 and PID-4 are deprecated, meaning they continue to exist only to support older versions of HL7. So you will see a value in PID-2 or 4 only for applications that were implemented in the past.

  PID-3 is an important field. It is mandatory, so you can’t leave this one empty. It is also a repeating field, meaning you can send multiple patient identifiers in PID-3. Of course, the identifiers will have to be separated by the repetition delimiter (~). An example would look something like this: PAT416^^^HEALTH_ID~999-99-9999^^^SSN.

  Another thing to know about this field is that it is a compound field. There can be up to ten components in this field but we don’t have to worry about that. Usually only component 1 (ID number) and 4 (Assigning Authority) are valued. That’s why the value in the example looks like PAT416^^^HEALTH_ID. Component 1 (ID) is PAT416 and component 4 (assigning authority) is HEALTH_ID. This is the health card number of the patient.

  PID-5: Patient Name

  This is another mandatory field and a compound field that has way too many components. HL7 went overboard here. In addition to the usual first, middle and last names, they have defined components for prefix, suffix, degree, surname from partner… it’s a long list.

  In practice, we only populate the first three components, last name, first name and the middle name. In our example, we have only populated the first two, last and first name. It is not uncommon to add MD or whatever other degree a doctor has, to her name. Degree is the sixth component so there will be a lot of carets in the field, something like PAYNE^TRACY ^^^^MD.

  PID-7/PID-8: Patient Date & Time of Birth and Sex

  Although these fields are optional, they almost always have a value. PID-7 (Date & Time of Birth) is in the TS (timestamp) format so the field value is sent as YYYYMMDDHHMM. If time is not available, only the date of birth (YYYYMMDD) is sent.

  PID-8 represents the sex of the person. This field can only have one character. M is for male, F for female and U is for unknown. If sites want to define their own codes, they are free to do so but they will have to make sure that both the sending and the receiving systems are referring to the same set of codes. Otherwise, there will be a message failure and a big headache for implementers.

  PID-11/PID-13/PID-14: Patient Address & Phone Number

  These fields hold the contact information of the patient and are usually populated. All three are repeating fields so there can be multiple addresses and phone numbers.

  In the example above, we also have values in the PID-15 (Primary Language) and PID-16 (Marital Status) fields. These fields are used to send additional demographic information about the patient. It all depends on the information collected by the healthcare facility and varies from one organization to the next.

  PID-18: Patient Account Number

  Although this field is defined as optional, in my experience, this field is always populated. This is the financial/billing account number to which all expenses and charges for patient care are assigned. Even in jurisdictions where you have universal healthcare (like in Canada), the patient account number is populated and used for reporting and tracking expenses.

  PV1 – Patient Visit Segment

  This is another very important and extensively used data segment. It carries information about a patient’s visit to a healthcare facility (which clinicians refer to as an encounter). Fields in this segment include type of patient (inpatient/outpatient), admitting doctor, date of admission, location of bed etc. In all, there are fifty two fields in this segment.

  PV1 follows PID in the body of the message and is usually a mandatory segment. Let’s parse PV1 from the example message and look at some of the important fields.

  PV1|1|O|ROOM10^BED12^OUTPATIENT|ELECTIVE|||S21195^DRIKOFF^FRANCIS^^^DR^ MD||C90023^PAYNE^TRACY^^^DR^MD|SUR||||1|||S21195^DRIKOFF^FRANCIS^^^DR^ MD||37323|SELF||||||||||||||||||||||||201310201500

  PV1-1: 1 (Sequence Number)

  PV1-2: O (Patient Class)

  PV1-3: ROOM10^BED12^OUTPATIENT (Assigned Patient Location)

  PV1-4: ELECTIVE (Admission Type)

  PV1-5:

  PV1-6:

  PV1-7: S21195^DRIKOFF^FRANCIS^^^DR^MD (Attending Doctor)

  PV1-8:

  PV1-9: C90023^PAYNE^TRACY^^^DR^MD (Consulting Doctor)

  PV1-10: SUR (Hospital Service)

  PV1-11:

  PV1-12:

  PV1-13:

  PV1-14: 1 (Admit Source)

  PV1-15:

  PV1-16:

  PV1-17: S21195^DRIKOFF^FRANCIS^^^DR^MD (Admitting Doctor)

  PV1-18:

  PV1-19: 37323 (Visit Number)

  PV1-20: SELF (Financial Class)

  PV1-21:

  . . . .

  PV1-44: 201310201500 (Admit Date/Time)

  PV1-45:

  PV1-46:

  . . . .

  There is only one required field in this segment, PV1-2. But a number of other fields are usually populated. Fields populated in the example above are a good approximation of real life messages. There could also be one-off cases, where a rarely used field is populated.

  Once, I came across a message where PV1-16 was valued and I didn’t know what it was
for. This field is for flagging VIP patients. It is there for health records of famous people and situations where the clinical staff might have more than a professional level of interest in the patient’s medical history.

  Remember when George Clooney had a motorcycle accident in New York and showed up at a local hospital. A lot of staff, especially women, were concerned about this patient in emergency, and were checking his records to make sure everything was all right. God knows why the media started screaming about breach of privacy.

  PV1-2: Patient Class

  This is the only required field in the PV1 segment. It contains a single letter, the code for the type of patient.

  HL7 doesn’t define a standard list of codes for the type of patient, although, there is a suggested list. A facility can use this suggested list or create its own custom list and share it with systems receiving the message.

  Some commonly used codes are - I (Inpatient) for patients staying at the hospital, O (Outpatient) for patients who are just visiting for a consultation, dialysis or checkup but are not going to spend the night at the hospital and E (Emergency) for patients who came through the emergency department.

  PV1-3/PV1-6/PV1-11: Patient Location

  These fields contain a patient's location in the hospital. For outpatients, the field stays empty but for those who are inpatients, PV1-3 contains their current location in the hospital. If the patient was moved from another location, that prior location is in PV1-6 and if the patient is in a temporary bed, then that goes in PV1-11. Not all fields are always populated. Usually only PV1-3 is valued (current location).

  These location fields are large and complicated. Each one is made up of eleven components and some of the components themselves are made up of subcomponents. However, the 80-20 rule is here to save us. Usually, only the first four components are valued. The first component is for the nursing station/unit, the second component is for the bed, the third component is for the room and the fourth one is for the facility/site. Together they are enough to pinpoint a patient's location in a hospital.