In the last set of blog posts in this series I talked about how to deal with communication errors, causes for an image to be Unverified, errors in the image header or display and worklist. In this blog I’ll describe some of the most common issues with orders and results impacting the PACS system.
Orders and results are created in a HL7 format, almost always in a version 2 encoding, with the most popular version being 2.3.1. A generic issue with HL7, which is not restricted to just orders and results but pretty much all HL7 messaging is the fact that HL7 version 2 is not standardized, meaning that there are many different variations depending on the device manufacturer and the institution that also makes modifications and changes to meet local workflow and other requirements.
The IHE Scheduled Workflow Profile provides guidelines on what messages to support and what their contents should be, but support for those profiles have been somewhat underwhelming. Therefore, having an HL7 interface engine such as Mirth or other commercial versions has become a de-facto necessity to map the differences between different versions and implementations, and also to provide queuing capability in case an interface might be down for a short period of time, so it can be restarted. Here are the most common issues I have encountered specifically related to orders and results as well as updates:
· Patient ID mix-ups – There are several places in the HL7 order where the patient ID can reside, i.e. in the internal, external, MRN, SSN, or yet another field. As of version 2.3.1, HL7 extended the external Patient ID field to become a list including the issuing agency and other details. DICOM supports a “primary” Patient ID field and expects all of the others to be aggregated in the “other ID” field. Finding where the Patient ID resides, in which field, or in the list, can be a challenge.
· Physician name – The most important physician from a radiology perspective is the referring physician, which is carried over from the order in the DICOM MWL and image header. For some modalities, however, such as special procedures or cardiology, there can be other physicians such as performing physicians, attending, ordering, and others as well as multiple listings for each category. Even so, despite the fact that the referring physician has a fixed location in the HL7 order, it sometimes might be found in another field and require mapping.
· HL7 and DICOM format mismatch – Ninety-five percent of DICOM data elements have the same formats (aka Value Representations) as the HL7 data types, the 5% differences can create issues when not properly mapped and/or transformed. For example, the Person Name has a different position for the name prefix and suffix and many more components in HL7. There can be different maximum length restrictions possibly causing truncations, and the list of enumerated values can be different causing a worklist entry or resulting DICOM header to be rejected. An example is the enumerated values for patient gender which in DICOM is M, F, O, the list for HL7 version 2.3.1 is M, F, O, U and for version 2.5 it is even longer, i.e. M, F, O, U, A, N (see ). This requires mapping and transformation at the interface engine or MWL provider.
· Report output issues – A report line is included in a so-called observation aka OBX-segment as part of a report message (ORU). There is no standard on how to divide the report, some put for example the impression, conclusion, etc. in a separate OBX, some group them together. In one case, a EMR receiving the report in HL7 encoding (ORU) only displayed the first line, obviously only reading the first OBX. Another potential issue is that a Voice recognition system might use either unformatted (TX) or formatted (FT) text and the receiver might not be able to understand the formatting commands
· Support for DICOM Structured Reports – Measurements from ultrasound units and cardiology are encoded as a DICOM Structured Report. Being able to import those measurements and automatically filling in those measurements into a report is a huge time savings (several minutes for each report) and reduces copy/paste errors. However, not all Voice recognition systems do support the SR import and if so, they might have trouble with some of the SR templates and miss a measurement here and there. Interoperability with SR is generally somewhat troublesome, and implementation requires intensive testing and verification as I have seen some of the measurements being missed or misinterpreted. Some vendors also use their own codes for measurements, which requires custom configuration.
· Document management – For long reports, it might be more effective to store them on a document management server and send the link to an EMR, or, encode it as a PDF if you want more control over the format, and attach this to the HL7 message. In this case, you will need to support the HL7 document management transactions (MDM) instead of the simple observations (ORU)
· Updates/merges, moves – Any changes in patient demographics is problematic as there are many different transactions defined in HL7, depending on the level of change (in the person, patient, visit, etc.) and the type of change, i.e. move patient, merge to records, or simply update a name or other information in a patient record. Different systems support different transactions for these.
In conclusion, HL7 messages vary widely, and interface engines and mapping are necessary evils.
If you would like to create sample HL7 orders or results, you can use a HL7 simulator (parser/sender). The HL7 textbook is a good resource and there are also training options available.