Digital Imaging and Communications in Medicine (DICOM)

9.10 Point-to-Point Spell 211
The classical example of this limitation is shown in Fig. 69. If, for example,
all your AEs reside on a local area network and have reserved (or static) IP addresses,
you have a classical PACS layout where everything works nicely and
is effectively point-to-point. However, if you decide to do teleradiology and
check your PACS images from home, or from a cozy Internet café, or from a
conference hall, the communication will fail. The reason is clear: your home
(Internet café, conference hall, and so on) computer resides on a totally different
network, and consequently will have a totally new IP address that is not
recognized by your PACS. In fact, you do not even have to go far from your
office to get into trouble. Just bring your laptop to work and plug it into your
local network. Even if your laptop runs the PACS software, more likely than
not you won’t be able to load images on it because its IP address and AET will
be unknown to your PACS: for example, A-Associate-AC from your laptop will
be rejected by PACS because of the unknown calling AET. This leads to a sad
paradox: you can be on a PACS network, but you won’t be able to use PACS.
Real case: point-to-point failure
Point-to-point connections can often be blamed for DICOM network vulnerability.
Soon after hurricane Katrina struck the U.S. Gulf Coast, one of
my customers called me from there with a really bad problem. She was
running an imaging center; they restored the power and, had restarted all
their PACS devices, but they just could not connect to their PACS server.
Moreover, the server was used as a teleradiology backbone and they had to
pay big money for couriers because they could not access the digital images
on the server remotely. Losing time, money, and patience they seriously
suspected that something had failed in the PACS server software we had
provided.
The problem, however, was solved very fast with the help of the local network
support engineer who visited their site. It was discovered that the
local network router, after the hurricane-induced power loss, reset itself to
its factory defaults, essentially changing the IP address and network configuration
of the PACS server. This address change made the server inaccessible
and the entire PACS network dysfunctional, although it was still
perfectly sound as a TCP/IP network. As soon as the IPs were restored, the
entire PACS returned to normal.
Another direct consequence of the limited point-to-point design is a total lack
of data forwarding in DICOM. Any data-receiving device always becomes the
end point of the communication. It cannot be instructed, at least in DICOM
terms, to relay the received data elsewhere. However, in a real medical workflow,
forwarding is extremely important. For example, you might want to push
a study to your PACS archive so that the archive would store the image and
automatically forward a copy to a radiologist for review. Most current PACS/