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
|