By Garrett Seeley, MS, CBET
About one-third of an HTM imaging technician’s service calls will be related to connectivity or DICOM communications. This is part of the reason why the field, in general, advocates strong networking skills for all technicians. I recommend everyone build up these skills to be more successful at their jobs and to help the overall health of society.
For TCP/IP troubleshooting, please refer to previous Networking Notes articles. Keep in mind tools like ping and other command line troubleshooting techniques. For wiring issues, please remember to use a port scanner. Be mindful of the potential for firewall and ACL issues and refer to previous articles for the building blocks of these skills. These techniques will help to repair a communication using non-DICOM related tools. However, these are not the only problems that imaging equipment faces. Unfortunately, these problems can often be non-critical issues, and thereby take a back seat in maintenance to overall operability of the imaging modality. It can be a point of contention that involves not only a radiology department, but information technology, manufacturers, and independent servicers as well as PACS administrators. Therefore, let’s discuss how to tactfully troubleshoot a DICOM issue if there is not a TCP/IP problem.
The first place to look is in the settings. The settings can cause basic communication issues and they can be overlooked or even changed over time. Recall from the previous article that the setup of DICOM requires an IP address, port number and an AE title. Keep in mind that in DICOM, the settings need to be in the right place on both ends. Double-check the settings both at the SCU (source) and SCP (destination). It is amazing how many times these settings change. This happens particularly after another technician has completed a repair, or after an update resets the settings to defaults. I want to caution against finger-pointing if either of these situations is suspected. Just fix the problem and do not look for blame.
When completing a repair, triple-check to make sure a port number or AE title did not mysteriously change. This happens a surprising number of times. Additionally, be aware that there is a setting for what is called a promiscuous mode. In this mode, the SCP is set to not care about the AE title of the SCU. Sometimes this setting gets changed to “on” for security reasons. Again, do not accuse people at this point, simply ask if this change occurred. This can cause an AE title mismatch and the association will be refused. To make matters worse, occasionally both server and client software prefer a reboot. This is usually due to cache memory filling up on either of the ends of the DICOM communication, called an association. Sometimes, turning it off and on again is the answer and there is no clear cause to this issue. These systems may require daily reboots. If the error is related to intermittent failures, check the timeout settings. I suggest a larger timeout setting, for example, 120 seconds for worklists or off-site PACS applications. If the timeout is set too low, it will abort during network congestions. After correcting these settings, remember to always finish a repair with a DICOM echo (also called DICOM ping or DICOM validation). This will verify the solution and it’s one of the easiest things to check.
If these suggestions do not provide a resolution, check the error logs for possible errors. Nearly all server software has a debug mode for logging DICOM data. Some clients will also list the error in their association logs. In such logs, the individual DICOM steps are sometimes observable. Lines that contain “A-” refer to the starting and stopping of an association. Lines with the “C- “statement are commands with data, such as “C-echo”, which is a DICOM validation command. These are the individual protocol data units, or PDUs, of the association. In this way, a complete DICOM error log will show the start, command with data exchange, and the stopping of the association. Advanced troubleshooting is best done by examining such logs. An error of “refused” points to a setting issue with IP, port or AE title. A “timeout” error is usually a firewall or ACL issue, or a timeout set too low. If any log states require header element or syntax errors, I suggest looking up the error in the conformance statement, which is a great troubleshooting tool.
A conformance statement is one of the best resources for advanced troubleshooting of DICOM. It will tell exactly how a device was intended to be used, what type of networking and settings are required, and the header elements needed for a DICOM file to be accepted. A conformance statement is supposed to be available on the web. It is ideally evaluated for compliance with an existing network before purchasing a device, however these statements are usually over 50 pages long. Because of this complexity, some details can be overlooked when installing new devices on a network. There may be a feature that a device was purchased to do that the rest of the devices on the network do not know how to work with. In this situation, a PACS admin will usually have to help resolve the information if it is a PACS system issue. The manufacturer will usually have to help if the problem exists on the SCU side of the association. Keep in mind to avoid assigning blame. The best way to do this is by presenting the documentation both from error logs and from the conformance statements to all relevant parties.
This brings me to my final point. These types of repairs are best documented as they can involve a lot of different servicers from several different organizations. No manufacturer wants to admit that they had a hand in an issue. No in-house HTM tech wants to admit when they are wrong. No admin or engineer wants to cause an issue. However, all these things can happen. Solutions to these conversations are easier with documentation. For that reason alone, I suggest preserving all information. Screenshots (being mindful of PHI), conformance statements, and downloaded logs go a long way in preventing emotional reactions. This is ultimately the spirit of advanced troubleshooting. My suggestion is to use management and better judgment to diplomatically present what these tools will help you find. This will help make a difference in your facility’s operations.
