The last set of blog posts in this series discussed dealing
with communication errors and causes for an
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).
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.
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.
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.
