 |
| This looks like a nice image, but the metadata could be totally incorrect or corrupted |
If you would take a snapshot of any DICOM archive and check
the image headers for correctness, I would argue that there are quite a few
hidden problems that you might not know about.
Errors in a DICOM header can cause images to be incorrectly
displayed, incorrectly added to the database, or being flatly rejected by the
PACS. By DICOM errors, I don’t mean an incorrect Accession Number of patient
name, or duplicate ID, but rather a violation of the rules defined in the DICOM
standard for a particular field entry.
These errors are typically categorized as length errors (exceeding
the maximum allowed length for a particular field), invalid characters, or a
value that does not match the defined list of terms for a particular field. A
typical example of a length error would be the value of the station name
exceeding the maximum allowed 16 characters, an invalid character would be
using a backslash “\” as part of a patient field (note that the “\” is defined
as a control character in DICOM), and an example of an invalid term would be
the value of “U,” for “Unknown” in a patient sex field.
How and where do these problems occur? There are several
potential sources. One is user input errors. I remember that my developers once
spent about a week figuring out why certain images were intermittently
rejected. Eventually the source was traced to a user who sometimes by accident
used disallowed control characters. A robust user interface will filter these
out and/or warn the user that the entry is incorrect. However, when the data is
generated as part of the order, which is entered by a data entry person and
creates a HL7 message, it might not be noticed, as HL7 has a different set of
allowable control characters than DICOM. A robust mapping from HL7 to DICOM
should convert and/or filter out these incorrect characters.
This gets us to the second source of potential problems:
incorrect mapping by an interface engine, modality worklist (MWL) provider, or
broker. HL7 has different lists of defined terms, such as the case for “U” for
sex, and different length specifications for the fields. A robust MWL provider
should take care of most mapping errors.
Some modalities might create invalid headers as well. One such
common problem is having a leading zero (0) in one of the segments of a Unique
Identifier. Some UID generators do not always check for that, and these headers
are typically rejected by the PACS.
Last but not least, one might have invalid images on a CD
that need to be imported, which were created by some unknown modality. I had
that issue when I tried to import and view images of my dog in my DICOM viewer,
which were rejected as these images were missing a Patient ID.
To troubleshoot these problems, in many cases a visual
inspection will do as the errors are relatively common and easy to spot. One
can import the image into a DICOM viewer and use the DICOM header dump feature.
When the problem is not that easy to see, one would use a DICOM validator,
which tests the header against the DICOM specifications. A demonstration of the
visual inspection and how to perform a validation can be seen here.
After diagnosing the problem, one can either fix the header
and resubmit it to the PACS, assuming it is a one-time issue, or if it is recurring,
one should go back to the source, for example the modality worklist provider,
or modality manufacturer to get this fixed.
I strongly recommend running the image through the validator
for every modality, especially prior to purchasing a new device. Remember that
potential issues might not bite until later, as your current PACS might be more
forgiving and not reject certain attributes in the header, but when the time
comes to migrate the data, these problems might resurface and prevent proper
viewing or even storage.
In conclusion, image header encoding problems due to
incorrect DICOM encoding are easy to see and/or validate using open source
tools. It is highly recommended to check your data.
