During the 2013 Society for Imaging Informatics in Medicine (SIIM) annual conference, there was an overriding message to healthcare imaging and IT professionals that they should learn more about HL7, especially as image-enabling the electronic medical record (EMR) is becoming a very hot item.
HL7 is not rocket science, and like any other standard, being able to "talk" HL7 is just a matter of knowing the most common terms and where to look for what information.
Most healthcare imaging and IT professionals don't really have to be experts; 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.
Herman Oosterwijk of OTech.First of all, even though the HL7 standard is extensive and covers many domains, ranging from billing to housekeeping and dietary to genomics, we are only concerned with a small subset 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 exam might be placed in a computerized physician order-entry (CPOE) system, which in many cases is part of the EMR. This triggers an order message, which is called ORM. Each HL7 message has an event code embedded, of which there are no less than 130 defined. Again, we only use a couple, in this case 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) message 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 CT technologist selects the patient from a list, the images are created during image acquisition and the DICOM header contains the information copied from the worklist.
Images are sent to a PACS 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's 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.
An HL7 message contains so-called segments that have a three-character segment ID and are delimited by a carriage return. In our sample message, we can recognize the first segment ID, i.e., the MSH; it contains general information about the message itself such as the initiator, receiver, date and time of message, and version number, in this case version 2.3.1.
The following segments are the PID, which contains patient identification information; PV1, which holds the patient visit information; ORC, which has 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 which have a fixed location and are separated by the control character "|". The message content uses ASCII 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 want the referring physician, we need to go back to the interface specification to find out which of the MDs identified in the ORC segment is the referring physician, who is the performing physician, 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, "If you have seen one HL7 interface, you've 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 that can cause issues. The HL7-related problems that I have experienced and expect are common are described below.
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 IDs" attribute. HL7 has quite a few patient ID fields -- i.e., a patient internal ID, external ID, medical record number, and 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 it could be done at the interface engine level as well. Mapping errors often occur as a result of software changes, or when upgrades affect these mappings.
Mapping errors from the appropriate HL7 subcomponent 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 affect the retrieval of the appropriate prior studies to be prefetched for comparison. I have seen mapping errors where the DICOM procedure code contained the full description versus 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." Based on the procedure code, the broker determines what modality to use in the worklist; for example, it knows that a "CT head with and without contrast" is performed at a CT unit, and a "right shoulder x-ray" is performed at a CR unit.
However, to make sure that the worklist in the intensive care unit (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 outpatient CT instead of the one in the ER, there is more granularity needed in the HL7 messages, such as department, inpatient or outpatient, 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 "\", such as 345\56\6874.
In DICOM, the "\" character is a control character used to separate different components within an attribute, and, as a result, it 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 they 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 issues appear years after the fact, when images are migrated to another PACS, where the second PACS complains about invalid lengths that 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 affect the workflow, efficiency, and data integrity of the PACS. 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. And if you really want to be an expert, you can even become certified as an HL7 interface specialist.
Herman Oosterwijk is president of OTech, a healthcare imaging and IT company specializing in EMR, PACS, DICOM, and HL7 training.
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnieEurope.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group.
