PACS troubleshooting tips and tricks series (part3): DICOM file type support errors.

In the last two blog posts in this series I talked about network and addressing issues. Assuming we
are able to connect to another device, the next step is trying to exchange certain information between the two devices using the DICOM protocol. Here is where things can go wrong as well.

Before we discuss details, let’s go over the DICOM protocol steps that include the handshake. There are two separate levels of communication, the first one being the connection management, which can be considered the “session” layer of a protocol, whereby a connection is properly established and released. Establishing the connection includes an agreement of what information will be exchanged and how it is being encoded. The negotiation of the information exchange is a simple “proposed” and either “accepted” or “rejected” step. We’ll discuss the handshake about the filetype to be exchanged first.

There are three terms that are important in this context: the “Presentation Context” which is the set of parameters being proposed by the client device which includes the type of information to be exchanged, such as “CT Images,” a “Dose Report,” an image “Presentation State,” and many others. The second term to know is the “Abstract Syntax” that identifies the information to be exchanged, and the third term is the “SOP Class” identifying the requested service, such as “Store these CT images.” Incompatibility issues are typically reported by the device as “Presentation Context,” “Abstract Syntax,” or “SOP Class” not supported.

These are some commonly encountered issues:

·        The image type that is proposed by the client is not supported. The error that might come back

Example of "Abstract Syntax" not supported log using
Modality Simulator (OT-DICE)

and you’ll see in the log file can be either “Presentation Context,” “Abstract Syntax,” or “SOP Class” not supported. This happens most frequently if a device supports a relatively new image type such as the Breast Tomosynthesis Mammography image, or an Enhanced (multiframe) CT or MR, or some of the specialties that were recently added such as for ophthalmology, digital pathology and others. To diagnose this, you can look at the log files at the sender. If you don’t have access to these log files, you can use a sender-simulator that will allow you to see exactly what is happening. For the simulator, you can use various tools, I mostly use the DVTK toolset, which includes a simulator or OT-DICE (see illustration of the “Abstract Syntax not supported”). The Wireshark DICOM sniffer is also a great diagnostic tool to identify such problems. A solution to this issue is an upgrade of the software of your device, which might be a major undertaking and expensive, using a “fallback” image type which is configurable at the modality such as using the “traditional CT” instead of the “enhanced CT” SOP Class. Some archives allow a configuration change to support a new SOP Class with the understanding that they can be archived but maybe not properly display at the PACS workstation.

·        A non-image file type is not supported by the server (PACS, Workstation). You’ll see the same errors as listed for the file types, but they refer to a non-image file such as a Dose Report, a CAD Structured report for mammography or chest, a Presentation State containing image manipulation and display information, ultrasound measurements, a DICOM encapsulated PDF, and many others. These objects are typically meant to be sent with the images in the same study, and it is likely that the images will make it to its destination, but not the corresponding non-image files, so you probably will get a  “DICOM error.” You’ll use the same tools to diagnose and/or simulate this as for the image type issue.

·        A private image or non-image file is being proposed. Vendors frequently create private or proprietary file types. This is common for some CR vendors, ultrasound, and others. If the images are sent to a PACS from the same vendor, the PACS will most likely support and display them, but subsequent viewers very likely will not. Imagine that a private file is sent from Vendor A modality to a Vendor A PACS successfully, if forwarded to an enterprise archive from Vendor B, it might fail to connect. The same tools apply, to diagnose and simulate

·        A non-appropriate SOP Class is used as an interim solution. Some vendors create a different modality and corresponding image format, e.g. CT instead of mammography, a screen-save (Secondary Capture) instead of an ultrasound, or other SOP Class that was not intended to cover a specific modality. There is not much you can do about this except for upgrading your PACS as soon as you can, and at that time try to convert these anomalies back to the original, intended file type.

·        CD’s are inoperable. Instead of trying to exchange these different file types over a network and being rejected by the intended receiver, you also may experience exactly the same problem when trying to read images from a DICOM CD. After diagnosing the issue, the problem might be harder to solve because you might need to contact the creator of the CD, which is likely not local, to resolve the issue.

Filetype issues are sometimes a little bit hard to diagnose as you might not always be able to or be allowed to use the tools mentioned. You could change that of course, I know of one vendor who installs a modality simulator (OT-DICE) and Wireshark on each of its modalities, just in case you might need them.

The next in this series will be on Transfer Syntax (such as compression) incompatibility issues. 

Additional information can be found in the DICOM textbook, or you can sign up for our on-line or face-to-face PACS and/or DICOM training classes.