We investigate areas in  biomeds can help meet the challenge of connectivity and interfacing.

One of the poll results from a recent Picture Archiving and Communications System (PACS) e-conference hosted by OTech Inc revealed that the greatest challenges associated with a PACS installation are connectivity and interfacing issues. (This was the number one issue for 53% the respondents.) A distant third (13% of respondents) was image quality. Performance was rated as the second-greatest challenge, with a 20% response. For the purpose of this article, we will ignore performance issues, as they seem to be related to improper specification and forecasting of expected image generation. Instead we will focus on the connectivity and interfacing issues, which present the greatest challenges, and are also areas in which biomedical and service-engineering professionals can help.

Imagine that a hospital is connecting a new modality, such as a computed tomography, to a PACS. The PACS will exchange the images and archive them appropriately using the Digital Imaging and Communications in Medicine (DICOM) protocol to communicate to the modality.

There are four connectivity issues to be considered:

  • network
  • intermittent connectivity
  • DICOM association negotiation
  • missing information at the destination

Network Issues
Something as simple as improper cabling, or a malfunctioning connector can cause network issues. Another common problem is the improper configuration of bridges, gateways, routers, and firewalls. Often these problems can be avoided if the network installation is properly checked and audited prior to implementation. The correct setup of the TCP/IP address and network mask at the modality itself is also critical. Incorrect or duplicate addresses can also cause network issues. Using simple network management tools prior to system implementation can go a long way toward avoiding problems.

Configuring a port number at the modality can also cause network issues. A port number is a logical address that binds a software application with the network. The IP address is analogous to a street number and the port number to an apartment number at that address. There is no standard port number for DICOM connections, although port number 104 is recommended. Conflicts can arise, for example, when installing a new DICOM application on a desktop that has another application, such as a public domain viewer, listening to the same port. A simple DOS utility, which displays port numbers (c:NETSTAT –AN), should always be used for checking before configuring.

Figure 1. DICOM test tool.

DICOM addressing in the form of the application entity (AE) title can also be a challenge. If the port number can be viewed as the apartment number, the AE title can be viewed as the person in the household. As in regular households, where there can be either a single person or multiple people residing in the apartment, there also can be single or multiple DICOM AE titles at a device. The most frequently made mistake with regard to AE titles is that they are not uniquely specified. Many institutions do not manage and maintain their uniqueness. A good example of unique specification can be found in the Veterans Affairs system, which typically uses the site number as part of the AE title. This allows facilities to avoid potential conflict when they start to exchange images. Another common mistake is forgetting that AE titles are case sensitive, which means that DICOM would interpret the AE title “WORKSTATION” as being different from “workstation.”

To troubleshoot connectivity issues, use the TCP/IP Ping command to check the basic connectivity, including the network, router, etc. Second, use the DICOM verification, aka Echo, or DICOM Ping command. Unfortunately, these tools are not always supported at every modality. In some cases one needs to hunt for them as tools, or refer to the service manual. One alternative is to use an active DICOM test tool as a simulator. This will be discussed in greater detail later. Several service engineers indicate that 70% of the problems are solved after passing the basic TCP/IP Ping and DICOM Ping.

Intermittent Connectivity Issues
The intermittent network issues need to be diagnosed with a network sniffer. Using a sniffer with a DICOM plug-in so that one can diagnose the TCP/IP packets as well as the DICOM commands and data in the form of the application level packets, that is, protocol data units (PDUs), is important.

DICOM Association Negotiation
After establishing basic network communication, the next hurdle is to ensure that the DICOM applications are negotiating the correct syntax (ie, encoding of the exchanged information) and type of service that is to be used (eg, exchanging CT images, exchanging a scheduling list, printing, etc). An example of a different syntax could be the use of compression, which is rather common for teleradiology connections, or for exchanging large data streams, such as an ultrasound cine loop or cardiology run. The DICOM services are negotiated between the devices as service object pair (SOP) classes, which define the exact type of service. Incompatibilities are not uncommon. For example a PACS might not support compression, ultrasound multiframe images, unprocessed mammography images, or the new MR data that includes spectroscopy. These incompatibilities cause DICOM associations to fail at their initial negotiation, or setup, which then causes the PACS and/or destination to reject it.

Figure 2. DICOM header dump.

By looking at the capabilities of these devices in the DICOM conformance statements, most of these issues can be resolved up front. In some cases, however, these documents are not available (although almost all of them are listed by the vendors online), and/or the correct version and model number of the device is not known until the engineer actually arrives at the site. Not many site administrators know exactly what software version is installed on their devices, and a single digit in a version number can make a big difference in DICOM capabilities. To troubleshoot the association negotiation issue, one can, again, use an active DICOM test tool that allows for selecting different transfer syntaxes, various SOP classes, and determining if there are any differences in the behavior.

Missing Information
We are now 90% live. The connection has been made, a DICOM association is properly established, and images or other information, such as DICOM queries resulting in work lists, etc, can be exchanged. Information is displayed on the screen, but something might be missing, the patient ID, for example. Correcting this requires inspecting the DICOM header. Several devices have DICOM dump utilities, but they are not always accessible. This is a good point at which to discuss an active DICOM test tool.

An active DICOM test tool is a software package that actively participates in the DICOM communication. It can be on a laptop connected to the network, which is actually how most service engineers use it, or, if used by a system administrator, it could be on his or her desktop. The tool can be used either as a service class user (SCU) or a service class provider (SCP), which means that it can either initiate a DICOM association or reply to one. When initiating an association, it can initiate a DICOM Ping or send a known image, with the header exactly specified, to a destination. The first part of the connectivity can also be tested to determine whether the destination supports certain transfer syntaxes, or SOP classes. See Figure 1 for a typical menu that allows the selection of these SOP classes, and provides information about what is supported and what is not.

Responding to an association, an active DICOM test tool takes part of the association, and pulls up the DICOM header for inspection. That is where one can find out about the missing patient ID, a referring physician name, or any other information that might be incorrect or missing. See Figure 2 for an example DICOM header dump. Each header element is displayed and “interpreted” by a DICOM parser to make it easy to identify and to correct certain issues. In the figure, one can clearly see the group and element number, which makes up the DICOM tag. Note that the DICOM protocol is similar to the XML protocol in that each attribute has its defined tag. For example, the referring physician has a tag of 0008,0090. The header also displays the length of each attribute and interprets the value of each field. This is only a partial display; the actual header can be made visible by scrolling down.

In future articles we will focus on advanced DICOM troubleshooting techniques, as well as troubleshooting image quality.

Herman Oosterwijk is president of OTech Inc, Crossroads, Tex, a company specializing in PACS training through publications, e-learning, software, and training seminars.