DICOM adds new dimension: network management

Anyone involved with making physical changes to PACS components, such as adding a viewing station, replacing a device that has broken, or temporarily rerouting images to another workstation, knows that it can be extremely difficult. The reason is that the developers of the DICOM standard didn't anticipate that a typical system might have tens to hundreds of nodes on a network, several of them wanting to communicate with each other at any given time. They devised only a very simple mechanism for those devices to identify themselves and communicate with one another at the application level. And network configuration and management tools were not really developed in the late 1980s when the DICOM standard was defined.

To understand the issue, let's investigate how a device communicates using DICOM. Imagine a scenario in which a router in a PACS retrieves from an archive the list of previous exams for all patients scheduled for radiology. This typically takes place the night before so that, based on certain rules (always fetch the previous two studies from the same modality, for example), the images can be routed to a specific workstation for comparison with the study to be performed the next day. Under DICOM, the router would specify the so-called AE (application entity) title of the devices that hold the images to be prefetched. Each of the AE titles must be unique or the archive would not know where to send the images. Now suppose a workstation is added; the configuration table of each device that wants to communicate with this workstation must be updated to include this new AE title. This is obviously not a task a service engineer or PACS administrator enjoys, especially when it must be done frequently.

A new DICOM standardization activity is addressing this issue by defining how systems can be configured with minimal manual interaction. It not only handles AE title configuration but also the physical network addressing, such as IP addresses, conformance details, and -- especially important in the light of the upcoming HIPAA regulation -- security information. All these data will be maintained and managed by DICOM's InfoBase.

The following are some situations in which the new standard will help:

Removing a machine from an existing network
When a machine is removed from a network, configuration parameters must be deleted so that other machines do not attempt to contact the removed machine. This information must reach all affected machines before errors occur.

Long-term unavailability
This is similar to removal of a machine, but information needs to be preserved for later restoration.

Adding a machine to a network that is under construction
Under-construction networks pose particular problems when adding new machines, because some or all of the servers needed by the new machine may be unavailable.

Upgrading a machine
This could be a software upgrade, hardware upgrade, or both. The machine should reacquire its previously assigned TCP/IP parameters and AE information.

Replacing a machine
This involves hardware or software replacement. In this event, it may be especially desirable to recover the configuration parameters from the network configuration InfoBase.

Using a mobile machine, such as ultrasound
This applies to a machine that is routinely moved from place to place on the network. It needs to retain its network identity and recover its connectivity whenever it is used at a new location.

Using a truly mobile machine
This refers to a machine capable of operating while in motion and while making significant changes in network location, such as a wireless connection.

Single node power-up
These are the routine actions during machine power-up that allow it to self-configure and acquire adequate configuration information from the network.

Partial or complete power failure recovery
This involves recovery from a power failure that affects part or all of the network. When the power is restored unusual network configurations can occur due to loss of network equipment, changing configurations as nodes recover and changing configurations as machines revert to normal.

Combining two previously separate networks
This situation includes the addition of a previously unconnected clinic or the merger of two large hospital chains. The merger of two networks can have many effects beyond DICOM. TCP/IP parameters are likely to change in many ways. AE titles that were once unique may now be in conflict.

Dial-up and intermittent networks (multi-institution)
These are intermittent connections between different institutions that are subject to different administrations. They raise particular security concerns. Both institutions may wish to restrict visibility of machines across this connection so that only specific, identified machines are available to the other institution.

To implement this new service, the DICOM working group is using common off-the-shelf mechanisms that are commercially available and can be easily extended with the required functionality. Existing network management protocols such as LDAP and DHCP are being considered. This work is still in the definition and specification phase, but there seems to be a push to complete it in a timely manner to accommodate the proliferation of systems connected via DICOM communication. This represents another dimension that the DICOM standard is addressing, in addition to basic image and information management and image quality and integrity. Interested parties, especially those who have experience in this area, are encouraged to contact the DICOM secretary at NEMA (how_clark@nema.org) or the main editor (robert.horn.b@us.agfa.com).

Mr. Oosterwijk has participated in the DICOM standardization process since its inception as member of several working groups. Send questions or concerns to herman@otechimg.com or visit his Web site at www.otechimg.com for more standards news.