PACS troubleshooting tips and tricks series (part7): DICOM header errors.

The last set of blog posts in this series discussed dealing with communication errors and causes for an

image to be Unverified. This post will discuss the errors that might occur caused by incorrect DICOM header encoding.

The PACS will typically only check for information in the header to be correct for those data elements that directly impact data integrity, i.e. impacting the correct indexing and subsequent retrieval of the DICOM files. Those data elements are about 10-15 elements such as Name, ID, sex, etc. There could be other errors in the data that impact future retrieval and processing which would not necessarily cause an image to be Unverified.

The most common DICOM header issues I have experienced are as follows:

·        Old date and time format – The first version of the DICOM standard had a different encoding for the date and time, it separated them with a period, “.” for example, instead of the encoding YYYYMMDD (20180821) it would encode it as follows – YYYY.MM.DD (2018.08.21). A DICOM editor would need to be used to change this.

·        Padding using spaces and null’s – There could be problems with “padding” i.e. adding spaces and/or a null (an ACSII control character indicating “0”) either before or after a data element. Some of the data elements allow for padding before and after (e.g. the Accession Number), some only after (e.g. the Person Name). That means that a space before a Name (.spSmith) is significant, and a search on Smith (without space) will not match and not provide any results. The space before the Accession Number is not significant and therefore a search with or without a space should result in a match.

Part of this problem is self-inflicted as the DICOM standard requires each data element to have an even number of characters/bytes, and therefore, if a data element being odd (e.g. Smith having 5 characters) it is padded (Smith.sp) to change its length from 5 to 6 bytes. To make it even more complex, the Unique Identifier (UID) has to be padded with a “null” instead of a space, in case it has an odd number of characters. Most DICOM toolkits are aware of this and will strip them off and/or add them when providing these data elements to the application, but there could be “rogue” implementations that incorrectly do this. In my own experience, I have seen a DICOM router not sending images to a particular physician because the physician’s name (Smith.sp) in the header did not match the routing table (Smith).

·        Person Names – Patient and Physician names are encoded somewhat differently in the HL7 orders. For example, the physician name in HL7 is typically preceded with an alphanumeric code that refers to the physician registry to properly identify Dr. Smith. The sub-components are in a different order, i.e. the name suffix and prefixes are reversed in the DICOM data format, in addition to the fact that the name in HL7 can have up to 14 (!) components in the latest version, while DICOM only allows for 5 (Last, First, Middle, Prefix, Suffix).

Patient names can also be incorrect due to incorrect user input. Imagine an input clerk entering “John Smith” in the Last name field instead of entering these in the last/first name fields, this record will not match the name “Smith” upon searches. If detected, a user can update the patient name, which will cause a HL7 Update message to be sent to all interested parties. If not detected, it can create issues later on.

·        Escape and control characters – One of the most important control characters in DICOM is the “\” which is used to separate among different multiple valued components in a data element. For example, if the patient was identified in the past with her maiden name, or name of her first husband, one could encode this using Smith\Jones. The “\” is NOT a control character in HL7 which contains the order and patient demographic information, therefore, any HL7 to DICOM mapping is supposed to filter out these characters, and if essential, possibly replace with a non-DICOM control character, e.g. a “/” to prevent the software from becoming confused.

These are some of the most common errors, there are several more. The problem is that they might be undetected and can create issues later, for example when trying to migrate this data to another PACS or creating a CD that is read by another PACS. As a typical header has sometimes a hundred or more data elements, it is hard to detect these issues visually, and the use of a header validator is the only manner to detect any issues.

There are a couple of tools available for free that I use, DVTK, which you can see here for a video demo on how to use it. I recommend using that if there is an issue, e.g. when trying to read an image from a CD that is rejected or produces problems with the display. It is also a good idea to run this validator against any new modality, you’ll be surprised how many problems you’ll find, some of them might be insignificant, but some can be important.

Another resource to use is the OTech reference guide, which lists all of the data types (VR’s) for both DICOM and HL7 in case you need to check for the validity of data elements. We also spend quite a bit of time in our DICOM training sessions going over the testing and validation process.

The next post we’ll talk about the most common image display issues and validating the image display pipeline.