Tuesday, January 19, 2021

Common HL7® Order to DICOM Mapping Issues

Most PACS administrators are not that familiar with HL7® , which can be a disadvantage when trying to troubleshoot issues at the PACS backend, as many of the Attributes that are part of the DICOM header are initially created and/or mapped from a HL7 message. HL7 messages are not that hard to interpret as they are encoded in plain ASCII text. A simple browser or even notepad will show you the message allowing you to find out why a PACS system either rejects a DICOM file or decides to store it in the “lost and found” input queue and not making it available for a radiologist at its workstation.

An HL7 order message (ORM) is typically received by a PACS, RIS, or Broker which will add the order to its scheduling database and upon a query request by a digital modality, it will provide a DICOM worklist by mapping the HL7 fields into the DICOM Attributes, which are subsequently copied by the modality in the DICOM header for the images to be sent to the PACS. The most common reasons for rejection by the PACS can be traced back to couple of HL7 to DICOM mapping issues as described below:

1.       Length mismatch – Many of the HL7 fields allow for a larger field length than the DICOM Attributes. When received by the PACS, it might check its length and decide that its database record length is smaller and reject it. As an example, the Person Name data type definition in HL7 (XPN) can be a maximum of 1103 characters long and have 14 subcomponents including items such as name validity range, expiration date, etc. while the DICOM data type definition (PN) is a maximum of 64 characters long with 5 components.

2.       Formatting mismatch – Some of the HL7 fields are encoded with a different order of the components than the DICOM fields. An example would be the order of the name components in the HL7 person name (XPN), which is <last>^<first>^<middle>^<suffix>^<prefix>, for the DICOM it is <last>^<first>^<middle>^<prefix>^<suffix>, note the suffix, prefix reversal.

3.       Contents mismatch – Some of the fields in HL7 have a different set of defined terms. For example, in HL7 V2.1, the set of recommended fields for patient sex is F, M, O, U, in version 2.7 that has been expanded to F, M, O, U, A and N. In DICOM the list of defined terms is F, M, and O. All of the additional HL7 codes except for M and F should be mapped to O, If not done so, the PACS will complain.

4.       Location mismatch – The patient ID in HL7 can be in different fields depending on whether it is the internal ID, external ID, social security number, alternate patient ID or, after version 2.3.1, they could be in a single location as a list that includes the issuer of the patient ID. One needs to select the right ID to be used as its primary ID and map that into the Patient ID field (0010,0020). All others that a PACS wants to carry along in the header should be mapped into the Other Patient ID field (0010,1000). Incorrect mapping might cause issues with patient identification.

5.       Coding issues – Procedures are encoded using its CPT4 code and description as well as abbreviation. Hospitals might use internal code systems, might mix the abbreviation with the full description, etc. causing incorrect procedure selection by the technologist at a modality.

6.       Mapping the procedure to the right modality – An HL7 order does not typically include the modality type (e.g. CT, MRI, etc.). The scheduling application has to map the procedure to the modality based on the procedure code, e.g. it would know what procedure codes are to be performed at a CT, MRI, ultrasound, or other modality. The problem occurs if there are multiple modalities, e.g. an inpatient CT in radiology and an outpatient CT in the ER, as the order might be listed on both. The same applies for having an ultrasound in the delivery, radiology and cardiology departments, mapping all of these procedures to a single modality, e.g. “US”, which would cause the procedures to show up on each US modality. In this case, the scheduler has to look at additional information to determine the patient location, class, etc. and map the order to a particular Scheduled AE-Title that can be used by the modality to request the correct worklist for this device.

7.       User entry errors – These are not necessarily mapping errors, instead these are caused by user data entry input issues, for example, a data entry person might put the last name AND first name in the last name field. The information will be mapped correctly but the meaning of the data is in this case is incorrect.

In conclusion, data integrity of the image data in the PACS or enterprise imaging system is essential. Issues with incorrect, inconsistent or missing information can often be traced back to the source, i.e. the HL7 order that was used to map into a DICOM worklist for retrieval by a modality and subsequently mapped into a DICOM image header. Knowing how to interpret the HL7 transactions will go a long way to troubleshooting these issues when they occur.