This is an interesting review - from the point of Imaging Specialists wanting to grasp some HL7 basics.
What do I need to know about HL7?
Herman Oosterwijk, AuntMinnie.com contributing writer
July 25, 2013 -- During the recent 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.
July 25, 2013 -- During the recent 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.
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.
Click link to see image.
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.
Lots more here:
Worth a browse for the basics and to see how HL7 and DICOM interact and can be interfaced.
David.
0 comments:
Post a Comment