Wednesday, June 19, 2013

What do I need to know about HL7?

During the recent SIIM conference in Dallas, there was an overriding message to healthcare imaging and IT professionals that they should learn more about HL7 especially as image-enabling the EMR is becoming a very hot item. HL7 is definitely not rocket science and like any other standard, being able to “talk” HL7 is just a matter of knowing the most common terms and knowing where to look for what information.

Most health care imaging and IT professionals don’t really have to be experts as there are enough of those within an institution.  However, the problem is typically how to communicate with vendors and the HL7 experts and know enough to visualize any issues and bring them to the surface. By the way, we are concentrating on version 2.x, as version 3 is a completely different story and will be covered elsewhere.

First of all, even though the HL7 standard is very extensive and covers many domains, ranging from billing to housekeeping, and dietary to genomics, we are only concerned with a small subset of that in the case of imaging. Therefore, instead of the more than 70 different messages, we are only concerned with three specific to our domain, patient admission, order, and result management.

In a typical scenario, an order for a CT might be placed in a CPOE (computerized physician order entry) system, which in many cases is part of the EMR. This triggers an order message, which is called ORM (“Order Message”).  Each HL7 message has an event code embedded, of which there are no less than 130 defined, of which again we use only a couple, which in this case is called the O01 (order). If this concerns an outpatient, the actual order would not trickle down to a modality for the study to be performed until the patient arrives. A clerk or receptionist will register the arrival, which triggers an arrival message that is encoded as an ADT (Admission,Discharge,Transfer) with a trigger event code A01. This will cause the requisition to become an active work item that will appear on the worklist for the CT modality upon request by the CT technologist.

The worklist is created by mapping the HL7 order information into a DICOM worklist item, which is exchanged using a modality worklist query. After the selection of the patient from a list by the CT technologist, the images are created during image acquisition and the DICOM header contains the information copied from the worklist. Images are sent to a PACS system and, upon completion of the exam, they appear on a workstation for a radiologist to read. 

The order was also sent to a reporting system, which is typically a voice recognition system, so that when the radiologist selects a new patient from the list, the information needed to identify the report is available and automatically displayed on the report screen. A report is created, signed off, and exchanged by the reporting system with the EMR or radiology information system using an ORU (observation result) transaction.
Let’s look at a typical HL7 message and we’ll see that it is really not that hard to interpret these messages as long as you know how to read them. The message below is a sample order message.

OBR|||GG3234093|71099.99^RIGHT SHOULDER X-RAY^CPT4|||||||||||| 67890^GRAINGER^LUCY^X^^^MD^^^UAMC^L|||||||||||

A HL7 message contains so-called segments, which have a three-character segment ID and are delimited by a carriage-return. In our sample message, we can recognize the first segment ID’s, i.e. the MSH, it’s the segment containing general information about the message itself such as the initiator, receiver, date/time of message, and version number, in this case version 2.3.1. The next segment is the PID segment containing patient identification, the PV1 segment holds the patient visit information, ORC with common order information and OBR, which contains information about the details of an exam, diagnostic study/observation, or assessment that is specific to an order or result. 

The transaction has many different components, all of them having a fixed location and are separated by the control character “|”. The message content uses ACSII text encoding, therefore, it is not hard to interpret what it says in the OBR. In this case it says that a right shoulder X-ray is scheduled for the Patient Barry identified in the PID. However, if we need to figure out who is the referring physician, we need to go back to the interface specification to find out who of the MD’s identified in the ORC segment is the referring, who is the performing, and who is the attending physician.

What are the most common issues that we encounter in the imaging area related to HL7? First of all, the saying goes that “if you have seen one HL7 interface, you have seen one HL7 interface,” meaning that no two are alike. Each institution has its own customizations and many vendors make changes to their interfaces. Because of the variability, we use interface engines to map messages and make our HL7 to DICOM convertors (brokers) very flexible and configurable. In addition, there are inconsistencies and differences between the HL7 and DICOM protocol encoding which can cause issues. The HL7 related problems that I have experienced and expect are common, are as follows:

  • Mapping errors from the appropriate HL7 element into the right DICOM field:
DICOM has a single, primary patient identifier, although it is possible to dump all of the ones you like to carry along in the image header into the so-called “other patient ID’s” attribute.  HL7 has quite a few patient ID fields, i.e. a patient internal ID, external ID, Medical Record Number, Social Security Number, and it has the capability to indicate the patient ID issuer as well. Therefore, finding the patient identifier you want to use in the imaging domain requires the selection of the appropriate ID and mapping it accordingly. The same applies for the many physician names in the order, in the DICOM header we typically carry only the referring physician forward, therefore we need to make sure we map the correct field. Mapping is typically done at the broker, but could be done at the interface engine level as well. Mapping errors often occur as a result of software changes, or when upgrades impact these mappings.

  • Mapping errors from the appropriate HL7 sub-component into the right DICOM field:

The procedure description that is contained in the worklist might have two components, both the full description and a mnemonic. Having the correct information in the worklist and eventually in the DICOM header is critical as it often determines the appropriate image hanging protocol, i.e. the way the images are displayed on the workstation. In addition it could impact the retrieval of the appropriate prior studies to be pre-fetched for comparison. I have seen mapping errors where the DICOM procedure code contained the full description vs. the abbreviated one, which is a simple error to fix in the broker.
  • Missing granularity:

One of the identifiers that is used in a worklist query at a modality is the so-called “modality field.” A typical value could be “CT, MR, or CR.” The broker determines, based on the procedure code, what modality to use in the worklist, for example, it knows that a “CT head with and without contrast” is performed at a CT, and a “Right shoulder X-ray” is performed at a CR unit. However, to make sure that the worklist in the ICU only shows the orders done at the portable CR unit at the ICU floors or to determine that certain patients are to be imaged at the out-patient CT instead of the one in the ER, there is more granularity needed in the HL7 messages, such as department, in-out patient, etc. to determine the station name where the exam is to be performed. Filtering the worklist takes a little bit of research to determine this mapping by looking for what information is available in the HL7 message. Lacking this information could result in having far too many orders on the worklist, which is prone to operator error by potentially selecting the wrong patient.
  • Invalid control characters:

HL7 and DICOM use different control characters. For example, a patient ID in HL7 could contain several components, separated by the character “\”, e.g. it could be 345\56\6874. In DICOM, the “\” character is a control character used to separate different components within an attribute, and therefore cannot be used as part of an identifier or name attribute. If the DICOM worklist provider maps these fields with their contents “as-is,” without filtering those out, a problem occurs when these are parsed on the PACS side. One solution I have heard is to replace all “\” characters with “/” which are legal.
  • Invalid lengths:

DICOM has strict definitions about the maximum length of its attributes. In HL7, the length limitation is not at the same attribute level, therefore an attribute can be mapped into a field exceeding the length of that field. A PACS might or might not complain about the length of a field to meet the maximum length, which is a problem by itself. I have seen problems appear years after the fact when images are migrated to another PACS system, where the second PACS system complains about invalid lengths, which initially did not cause any problems with the first PACS.

In conclusion, as an imaging professional you will have to know about HL7 because this information will eventually end up in image headers and impact the workflow, efficiency and data integrity of the PACS system. You should be able to sit together with an HL7 specialist, who can either be internal or from the vendor side, and troubleshoot issues due to incorrect mapping, length and encoding issues. HL7 is not rocket science, there are good references (see the HL7 textbook) e-learning classes, and hands-on training classes available (see schedule). And if you really want to be an expert there is even an opportunity to get certified as an HL7 interface specialist (see studyguide).