DICOM White Paper
 
Tools for Testing DICOM Connectivity

By Paul Gihring, consultant, OTech, Inc.

 

 

Taking the Mystery Out of DICOM Troubleshooting

Almost all medical imaging equipment made today can be networked together thanks to the DICOM standard. However, getting all this equipment to interoperate seamlessly has been a major problem. By using some simple test tools, and with a little bit of training, you can go a long way towards analyzing and solving the connectivity problems yourself. This article provides some troubleshooting basics, and describes some of the tools that can be used for DICOM testing. One low cost DICOM test tool called OT-DICE will be described in detail.

The DICOM (Digital Imaging and Communications in Medicine) Standard made a great evolutionary leap in 1992 with the change to modern networking methodology. New implementations for DICOM connectivity have increased exponentially since that time. The comprehensiveness and complexity of the DICOM standard, and its continuing evolution have caused many equipment vendors to implement only the most basic of its features. But other vendors have taken advantage of new features and have developed new products with enhanced interoperability. One result of all this is that clinical users, technical support personnel and vendors alike find themselves trying to solve connectivity issues every time new DICOM equipment is installed.

Looking at the Options

There are basically two different kinds of test tools for DICOM network testing: Sniffers and Active Test Tools. A network sniffer is a tool which listens in on network communications and captures selected bits of information for analysis. An active tool is one which participates in network communications as the client or server, and creates log files for analysis. Each of these tools has some advantages in given situations. We will look at each of these in turn, describing how they are used to solve DICOM networking problems.

DICOM Sniffer

DICOM Sniffers: Powerful but Expensive

Network sniffers have been around since the dawn of the Networking Age. A sniffer is typically a small computer which is capable of reading packets of information as they are being sent between other systems on the network. Network packets always carry source and destination addresses, so by using filtering techniques it is possible to read all packets being sent to and from particular devices using the network. As an example, a client and server are exchanging data over a network while a sniffer listens in. The sniffer copies all of the packets as they are sent between the client and the server, and streams them onto a disk. The client and server systems are not aware that their conversation is being wiretapped and recorded.

The packets captured by a sniffer would make a virtually worthless stream of bits and bytes if the sniffer were not able to interpret the data. For this reason sniffer manufacturers load their products with protocol interpreters capable of decoding the most common network protocols and displaying the results in a human friendly format. The DICOM protocol, as defined in the DICOM standards, also needs to be decoded in order to be understood by anyone other than the few individuals who crunch on DICOM for breakfast. A good DICOM encoder will spell out in plain language all of the association control steps and all of the data elements as connections are made and data is exchanged. DICOM protocol interpreters need to be kept up to date as new functionality is added to the DICOM standard.

One of the big advantages of DICOM sniffers is that they can be added onto a network to do their work without making any changes to the systems being investigated. For example, a DICOM scanner has a set of images which are ready to be sent to a PACS in the same department. The scanner tries to open an association with the PACS, but the connection fails, and the scanner gives the operator a meaningless error message or no message at all. A DICOM sniffer is connected and configured to capture all communications between the scanner and the PACS. When the connection is attempted again the sniffer captures the messages going between the two systems, and displays them with DICOM interpretation. Now it becomes clear that the PACS cannot accept the data because the image type is not recognized.

A more difficult example would be when a set of individual images are being sent, and the association is cut off before all of the images arrive. Who closed the association, and why? A sniffer can watch without interfering with the connections, and save the results for analysis. With some training and experience you should be able to review the results and determine why the connection was terminated early.

Where can you get a DICOM sniffer, and what will it cost? Network sniffers of all kinds are available on the market, but a sniffer which interprets DICOM seems to be a rare beast. There seems to be only one commercial product out there so far, but it has a good track record. The product is called Observer, and is available from several sources. Check out the web site at the end of this article for more information. The price tag is in the thousands of dollars category, but could be well worth it for professional level troubleshooting.

Another option, if you are willing to do more work, is to build your own sniffer software using DICOM toolkit software available from a number of sources. If you work in the UNIX world, you can get software, some of it freeware, which allows you to use UNIX snoop utilities along with DICOM interpretation. Your best bet here is to scan the web and see what’s available.

Active DICOM Test Tool

 

Active DICOM Test Tools

An active test tool is one which participates as a client or server in a network connection, and logs activity in a file as it carries out particular functions. In a DICOM network the active test tool will function as a Service Class User (SCU) or Service Class Provider (SCP) as it manages associations and transfers data. In the typical scenario where a scanner is not able to send data to a PACS, the active test tool is configured as a DICOM Store SCP to stand in for the PACS in question, and now the user can try sending the same data to the test tool. The test tool records the association parameters sent by the scanner, responds, and accepts the data. The log file from the test tool should give clues leading to discovery of the problem.

If the PACS is suspect in any way, the active test tool can be also configured as a DICOM Store SCU, this time standing in for the scanner, and will log the results as it attempts to connect and send data to the PACS.

One of the big advantages of using an active DICOM test tool is that it provides an independent "expert opinion" on controlling a DICOM association and sending or receiving data. It takes one of the unknowns out of the equation when comparing two DICOM systems with mismatched implementations. It can be substituted for each of the two systems in turn. It is also possible with an active test tool to build up a library of known good and bad test images to bounce against other DICOM entities. The active DICOM test tool should be configurable such that a variety of association parameters can be used with a system under test. An example would be to set up a SCU test tool to send image data using specific transfer syntaxes, such as Big Endian or Little Endian.

Active test tools are relatively inexpensive. In fact, some testing software is freely available from various sites on the Internet. One newly developed active DICOM test tool will be described here. This is a product named "OT-DICE" which until recently was only available to participants of a DICOM Hands-On Workshop offered by OTech, Inc.

 

OT-DICE: The OTech DICOM Interoperability Checking Entity

OT-DICE is a software package which runs on Windows 95, 98, 2000, and Windows NT/4. The test software makes use of the TCP/IP connection options installed on your PC, for example TCP/IP over Ethernet, assuming you have an Ethernet adaptor. The current version provides the DICOM STORE and ECHO services as both an SCU and as an SCP. The DICOM QUERY and MOVE services, as well as Storage Commitment and JPEG compression will be added in future versions. OT-DICE is very easy to configure and use. The results of DICOM associations are interpreted in plain English and displayed in scrolling windows.

The OT-DICE user interface is convenient to use and very intuitive. All configuration and testing functions are accessed from a main window with drop down menus and selector buttons. The user is not required to edit configuration files or script files. All DICOM configuration parameters can easily be changed, and take effect without re-starting the software or re-booting the operating system.

A good example of how OT-DICE uses pop-up windows for configuration is the local node (SCP) configuration window shown below. Three pages of configuration parameters are selected using the tabs. On the general configuration page the user may set the DICOM Application Entity Title, the listening port number, the maximum PDU (Protocol Data Unit) size for receiving data, and a destination folder for saving the image data file. The user also has the option of saving to disk the data file in the same transfer syntax that was negotiated for the DICOM association, or selecting a different syntax.

The image types page of the SCP configuration window gives the user control over which of the DICOM Storage Classes will be allowed during the association negotiation. In the illustration below the user has selected only 4 different image types which will be accepted from a DICOM STORE SCU. A third configuration page lets the user select from a similar check list of DICOM Transfer Syntaxes which will be allowed for data transfer. The OT-DICE test tool gives the user a large number of combinations for testing against another DICOM entity through these configuration options. Every time the SCP function is started the current configurations are enabled, making for quick and easy changes during testing.

General Configuration Page for Local Node (SCP)

When the SCP function is enabled, by the way, OT-DICE will also respond to DICOM Verify requests from other nodes on the network. The Verify or ECHO function is a quick way to find out if a DICOM application is running and is capable of receiving an association request from other nodes.

Image Type Configuration Page for Local Node (SCP)

As a DICOM Storage SCU test tool, OT-DICE is capable of sending image data to other nodes. It can also send the DICOM Verify request to other nodes. The SCU configuration window is similar the SCP configuration we just looked at, but with one added step. The main SCU configuration window contains a list of all nodes which have been configured by the user. When the SCU is used to send data or to send the ECHO to another node, the user selects a node from this list. The configuration window shown below provides an easy way to add new nodes to the list, edit the node configuration details, or delete nodes from the list.

Main SCU Configuration Window

When adding a new node to the list, or editing an existing node, additional windows are presented to the user for entering all of the required parameters. One configuration page has a checkbox list of transfer syntaxes which will be offered to the remote SCP. This allows the tester to specify one or more transfer syntaxes.

When OT-DICE is being used as a STORE SCU test tool, the user first selects a remote SCP from the nodes list, and then selects data to send. A "Select Files" button brings up a browse window, making it easy for the user to select single or multiple DICOM data files from the local disk. A "Send" button then causes OT-DICE to send the association request to the selected node.

 

Check out the Results

The results of all DICOM network communications between the OT-DICE and other systems is displayed in tab selectable windows. All information sent out by the OT-DICE SCU or SCP is displayed in one window, while all information received is displayed in another window. All of the DICOM messages are interpreted to make them easy to understand. Even the image data is interpreted element by element to show the values for each data item.

In the following example we see the results of our test SCU requesting an association with a remote SCP. In this case we have selected two different images to send, one an ultrasound image, and the other an MR image. The SCU opens the association offering two different DICOM Presentation Contexts, one for the Ultrasound Multiframe Storage SOP Class, and the other for the MR Storage SOP Class. Both Presentation Contexts offer 3 different DICOM Transfer Syntaxes, as seen in the illustration. If any of the proposed Presentation Contexts is accepted by the remote SCP, then the SCU will give the Store command, which is seen at the bottom of the window, and the selected data is sent.

Local Results for Storage SCU

A scroll bar, which is not shown in this illustration, is then used to view the remainder of the local results, which in this case is the DICOM dataset which was transmitted to the SCP. The beginning of the dataset is shown in the next illustration. As you can see, every attribute is interpreted and displayed in the sequence it was sent.

When the Remote results tab is selected the user sees the responses which came back from the remote SCP. In this example two different Presentation Contexts were offered by the SCU as it opened the association. As you can see from the results illustrated below, only the MR Image Presentation Context was accepted by the SCP. The message returned by the SCP indicates that the Multiframe Ultrasound SOP Class is not supported. As a result, the SCP sent only the MR image dataset. The results of the Store command are seen at the bottom of the display, showing that the MR image dataset was received successfully.

Beginning of the Dataset

The example we have just looked at shows how OT-DICE is used as an active SCU test tool. Each step of the DICOM association from the request to the final result are displayed in windows, and may be stored on the local disk for later review. The Log tab gives a similar display of the higher level results of the SCU and SCP processes as they are started and terminated by OT-DICE.

Remote Results for Storage SCU

When the Echo SCU and Store SCP functions are used, they also produce a detailed results listings in the scroll windows.

 

DICOM Dataset Files

When the OT-DICE Storage SCP receives DICOM data from another entity, is saves the dataset in a file format known as a "Part 10" file, which gets its name from Part 10 of the DICOM Standard. A Part 10 file is essentially a copy of the data stream as transferred using the DICOM Storage network protocol. Dataset files in this format are commonly exchanged on compact disks, and can often be found on manufacturer’s web sites as sample data. Any Part 10 file can be selected and sent using the OT-DICE SCU function as long as it does not contain any serious errors. When data is received by the OT-DICE SCP it is saved in a Part 10 format on the local hard drive.

 

How to Approach DICOM Testing

The first thing to recognize is that there are several levels to DICOM networking. At the lowest level we have cables, routers, gateways, satellite dishes, and all the other components that are used for general networking. At a higher level we have TCP/IP, a universal networking protocol which can be shared by DICOM and many other networked applications. The next level up is the unique DICOM protocols and data formats as defined in the standards. The top level consists of applications used by clinicians and technologists to acquire patient data, and to view it, save it, find it again, forward it, and possibly perform some number crunching with it. Your approach to testing should be organized along the same layers.

If we start at the TCP/IP layer we can quickly determine if a connection is possible between two DICOM entities. If the TCP ping command from one end gets a response from the other end, then the lower two layers described above should be able to support DICOM connections. At the DICOM protocol level it is almost necessary to have test tools like OT-DICE to see what is going on. At this level we can start with the DICOM ECHO function to see if we get a response. We have seen from the OT-DICE example that the Store functionality is relatively straightforward to analyze. For functionality like DICOM Print, which is not supported by OT-DICE it may be necessary to use a DICOM sniffer.

It is always a good idea to check out the DICOM conformance statements for equipment before spending too much time diagnosing network problems. By comparing the DICOM services, image types, and transfer syntaxes supported you may find that connectivity is not possible, or that some configuration changes are required.

Some of the most difficult problems to solve occur at the application level. Some people have said that there are a lot of different interpretations of DICOM possible. This is a misleading statement. The reality is that some equipment manufacturers do a much better job of implementing DICOM than others. Even when DICOM connectivity is working properly, it is not uncommon to find that clinical applications are having problems because image attributes are missing or possibly encoded incorrectly. When one manufacturer tells his customers that another manufacturer’s DICOM implementation is not providing the correct data, you may find yourself in the position where you need to test the two implementations and look at the DICOM data being sent. An active test tool like OT-DICE can be very helpful for making an independent evaluation.

 

Experience is the Key

When it comes to troubleshooting DICOM interoperability, there is no substitute for experience. Even with the best tools possible you need to get some experience looking at DICOM connectivity details to be most successful. With any tools the best thing to do is get experience working with DICOM equipment that is working properly and experiment with many different combinations until you are sure of yourself. With the OT-DICE tool you can run the SCP and the SCU functions simultaneously, which means you can send data to yourself and review the results of both sides of the connection on the same PC.

Even without spending any money on test tools you can start by looking at DICOM data files and making simple tests. Some of the free DICOM viewers available on the Internet have SCU and SCP capability, and some can create DICOM dump files from datasets. You can also find some free software for building your own diagnostic tools if you want to do the programming yourself. But if you are really serious about doing DICOM troubleshooting it would pay to purchase reliable test tools and possibly invest in some training in how to use it.

Download OT-DICE for a
30-day evaluation.

 

 

White Paper: Tools for Testing DICOM Connectivity, March 2001