OTech Examines
Tools for Testing DICOM Connectivity
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 connec-
tivity problems yourself. This article provides
some troubleshooting basics, and de-
scribes some of the tools that can be used
for DICOM testing. One low cost DICOM test
tool called OT-DICE will be described in de-
tail.
A network sniffer is a
tool which listens in on
network communica-
tions and captures
selected bits of informa-
tion for analysis. An
active tool is one which
participates in network
communications as the
client or server, and
creates log files for
analysis.
The DICOM (Digital Imaging and Commu-
nications in Medicine) Standard made a
Copyright OTech, Inc. Tel: 940.440.9530
By Paul Gihring, consultant, OTech, Inc.
great evolutionary leap in 1992 with the
change to modern networking methodol-
ogy. New implementations for DICOM con-
nectivity 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 ven-
SCANNER Sniffer
DICOM Sniffer
dors have taken advantage of new features
and have developed new products with en-
hanced interoperability. One result of all this
is that clinical users, technical support per-
sonnel 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 communi-
Fax: 940.440.9566
cations and captures selected bits of infor-
mation for analysis. An active tool is one
which participates in network communica-
tions 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 network-
ing problems.
PACS
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 ca-
pable 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 exchang-
ing data over a network while a sniffer lis-
sales@otechimg.com
page 2
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.
tens 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 in-
terpret the data. For this reason sniffer
manufacturers load their products with pro-
tocol interpreters capable of decoding the
most common network protocols and dis-
playing the results in a human friendly for-
mat. The DICOM protocol, as defined in the
DICOM standards, also needs to be de-
coded in order to be understood by any-
one other than the few individuals who
crunch on DICOM for breakfast. A good
DICOM encoder will spell out in plain lan-
guage 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 sniff-
ers is that they can be added onto a net-
work 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 scan-
ner 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
Copyright OTech, Inc. Tel: 940.440.9530
OTech Examines
to capture all communications between the
scanner and the PACS. When the connec-
tion is attempted again the sniffer captures
the messages going between the two sys-
tems, and displays them with DICOM inter-
pretation. 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 inter-
fering 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 connec-
tion 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 com-
mercial 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
SCANNER Active
SCU/SCP
Active DICOM Test Tool
Fax: 940.440.9566
snoop utilities along with DICOM interpre-
tation. Your best bet here is to scan the web
and see what’s available.
Active DICOM Test Tools
An active test tool is one which participates
as a client or server in a network connec-
tion, 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
OT-DICE is very easy to
configure and use. The
results of DICOM asso-
ciations are interpreted
in plain English and
displayed in scrolling
windows.
Class User (SCU) or Service Class Provider
(SCP) as it manages associations and trans-
fers 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 ques-
tion, 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 prob-
lem.
PACS
sales@otechimg.com

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 scan-
ner, and will log the results as it attempts to
connect and send data to the PACS.
One of the big advantages of using an ac-
tive DICOM test tool is that it provides an
independent “expert opinion” on controlling
a DICOM association and sending or receiv-
ing data. It takes one of the unknowns out
of the equation when comparing two
DICOM systems with mismatched imple-
mentations. It can be substituted for each
of the two systems in turn. It is also pos-
sible 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 associa-
tion parameters can be used with a sys-
tem 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 avail-
able 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, as-
suming 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 ser-
vices, 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 dis-
Copyright OTech, Inc. Tel: 940.440.9530
Tools for Testing DICOM Connectivity
played 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 selec-
tor 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-start-
ing the software or re-booting the operat-
ing 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 param-
eters 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 im-
age 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 configu-
ration window gives the user control over
which of the DICOM Storage Classes will be
General Configuration Page
for Local Node (SCP)
Fax: 940.440.9566
page 3
allowed during the association negotiation.
In the illustration below the user has se-
lected only 4 different image types which
will be accepted from a DICOM STORE SCU.
A third configuration page lets the user se-
lect from a similar check list of DICOM Trans-
fer 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.
When the SCP function is enabled, by the
way, OT-DICE will also respond to DICOM
Image Type Configuration Page
for Local Node (SCP)
Verify requests from other nodes on the net-
work. The Verify or ECHO function is a quick
way to find out if a DICOM application is
running and is capable of receiving an as-
sociation request from other nodes.
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 configu-
ration window is similar the SCP configura-
tion we just looked at, but with one added
step. The main SCU configuration window
contains a list of all nodes which have been
sales@otechimg.com
page 4 OTech Examines

nications between the OT-DICE and other

systems is displayed in tab selectable win-
dows. All information sent out by the OT-
DICE SCU or SCP is displayed in one win-
dow, while all information received is dis-
played 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

Main SCU Configuration Window
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 configura-
tion details, or delete nodes from the list.
Check out the Results
The results of all DICOM network commu-
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 of-
fering 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 ac-
cepted by the remote SCP, then the SCU will
give the Store command, which is seen at
the bottom of the window, and the selected

When adding a new node to the list, or

editing an existing node, additional the
dows are presented to the user for enter-
ing all of the required parameters. One con-
figuration page has a checkbox list of trans-
fer syntaxes which will be offered to the re-
mote 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 re-
quest to the selected node.

Local Results for Storage SCU

Copyright OTech, Inc. Tel: 940.440.9530 Fax: 940.440.9566 sales@otechimg.com

 Tools for Testing DICOM Connectivity page 5

you can see from the results illustrated be-

low, only the MR Image Presentation Con-
text was accepted by the SCP. The message
returned by the SCP indicates that the
Multiframe Ultrasound SOP Class is not sup-
ported. 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.

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 dis-
played 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.

When the Echo SCU and Store SCP func-

tions are used, they also produce a detailed
results listings in the scroll windows.
Beginning of the Dataset

data is sent.

A scroll bar, which is not shown in this illus-

tration, 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 dis-

The reality is that some

equipment manufactur-
ers do a much better job
of implementing DICOM
than others.

played 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
Remote Results for Storage SCU

Copyright OTech, Inc. Tel: 940.440.9530 Fax: 940.440.9566 sales@otechimg.com

page 6
When it comes to
troubleshooting DICOM
interoperability, there is
no substitute for experi-
ence. Even with the best
tools possible you need
to get some experience
looking at DICOM con-
nectivity details to be
most successful.
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 es-
sentially a copy of the data stream as trans-
ferred 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, gate-
ways, satellite dishes, and all the other com-
ponents that are used for general network-
ing. At a higher level we have TCP/IP, a uni-
versal networking protocol which can be
shared by DICOM and many other net-
worked applications. The next level up is
the unique DICOM protocols and data for-
mats as defined in the standards. The top
level consists of applications used by clini-
cians and technologists to acquire patient
data, and to view it, save it, find it again,
Copyright OTech, Inc. Tel: 940.440.9530
OTech Examines
forward it, and possibly perform some num-
ber crunching with it. Your approach to test-
ing should be organized along the same
layers.
If we start at the TCP/IP layer we can quickly
determine if a connection is possible be-
tween two DICOM entities. If the TCP ping
command from one end gets a response
from the other end, then the lower two lay-
ers described above should be able to sup-
port DICOM connections. At the DICOM pro-
tocol 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 functional-
ity 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 equip-
ment before spending too much time di-
agnosing 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 oth-
ers. Even when DICOM connectivity is work-
ing 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 an-
other manufacturer’s DICOM implementa-
tion 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 ac-
tive test tool like OT-DICE can be very help-
ful for making an independent evaluation.
Fax: 940.440.9566
Experience is the Key
When it comes to troubleshooting DICOM
interoperability, there is no substitute for ex-
perience. 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 ex-
periment 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 build-
ing your own diagnostic tools if you want to
do the programming yourself. But if you are
really serious about doing DICOM trouble-
shooting it would pay to purchase reliable
test tools and possibly invest in some train-
ing in how to use it.
Downloads
Download OT-DICE for a
30-day evaluation:
http://www.otechimg.com/
Find more news and informa-
tion about DICOM, PACS, Tele-
radiology, Connectivity (DICOM,
HL7) and regulatory topics
related to PACS in OTech Inc.’s
bimonthly publication, OTech
News.
Subscriptions are $49/year ($59
outside the US). Contact
sales@otech.com for a free trial
copy.
sales@otechimg.com