R.L. ‘Skip’ Kennedy, MSc

One of the common challenges we all face with deploying a picture archiving and communications system (PACS) is in making correct connections between our modalities and our PACS. When expected DICOM connectivity fails or falls short of what we expect the results to be, our only recourse generally is to attempt to diagnose the incompatibility using the two live systems that we are attempting to connect. This is often a challenge—what would be ideal is to be able to see how our systems act respective to another separate and independent system. In order to do this, a test system is needed that is capable of both receiving and sending DICOM for the services of interest. This is what is often called a testbench in software engineering, or a test bed. Described here are some options for establishing this, and some suggestions for use.

Having a DICOM test bed might seem to be the realm of large corporate PACS laboratories, but it is really something easily devised within the scope of any PACS developer, engineer, or PACS administrator. One or more standard personal computers added to some relatively inexpensive or free software can provide the tools to help work out many of the problems that we face in typical PACS connectivity in the field. It is also an ideal environment for learning about DICOM and trying out options and configurations that would be impractical using a large and expensive radiology modality, such as a CT scanner or CR reader.

Several good and relatively inexpensive commercial solutions exist that can provide general DICOM functions and test and diagnostic features. Also, the public domain Conquest DICOM from the Netherlands Cancer Institute, Amsterdam, provides a complete test PACS with which to test your modalities. David Clunie’s excellent web resources page provides links to many more DICOM resources ( www.dclunie.com ). Finally, the authoritative test bed for DICOM solidly remains the CTN (Central Test Node) from the Mallinckrodt Electronic Radiology Laboratory. This is somewhat more complex to install initially than some of the tools mentioned previously, but provides a wealth of tools, along with being the authority for a reference implementation for DICOM. Developed for the Radiological Society of North America test network, this is what the vendors connect to at RSNA. The effort installing this is well rewarded—no PACS test environment is truly complete without a copy of the CTN.

Once a DICOM test tool has been selected, installed, and put on a network, the first task is to try sending information from one of the modalities to the test bed. This is a good opportunity to learn more about DICOM configuration, including the transmission control protocol/Internet protocol (TCP/IP) addressing, port definitions, and Application Entity (AE) titles that often make DICOM configuration challenging in the field. Often it is much easier to test and experiment using a low-cost test bed than trying to do this with the actual modalities. Also, most DICOM test tools are what is termed promiscuous for DICOM in that they will accept input from any source, and the sources are not required to be preconfigured first. This can be a useful tool for establishing what your modality is actually set to send in DICOM (which perhaps may be different from what the modality field service engineer tells you). Basic DICOM testing tools are available in the public domain as well as commercially at modest cost and can save hours in establishing a new modality to a PACS.

Once DICOM can be captured live from a network, you will want to use some of the features for looking under the hood of DICOM objects. One of the more useful of these is what is called a tag viewer, which allows you to look in detail at DICOM metadata, including the data that is not seen by a typical PACS workstation. (Metadata is typically considered the patient, study, and scanner context for a study or image, as opposed to the pixel data of the images themselves.)

This is an invaluable feature of a good DICOM test tool: while most PACS also allow you to display metadata detail, this assumes that you can, in fact, actually get this data to your live PACS. Many times it is much more effective to test “offline” than to try to send real data to a clinical PACS. Further, several of these tools also allow the user to edit the metadata and resend this later—for example, it is possible to change the patient name, or study description for testing. Since a DICOM test bed can easily run on a laptop, it is also a very good way to check out a new modality before actually connecting to the hospital network. A laptop and small network switch can save time and potential trouble prior to connecting anything to the clinical network that runs your entire hospital.

ADDITIONAL TOOLS

Other items that should be in every tool kit are some general purpose network tools. These can vary from a basic public domain ping scanner, such as the popular Angry IP Scanner, to a dedicated and sophisticated network analyzer and DICOM protocol analyzer. A hardware network analyzer, such as the Fluke NetTool, or an inexpensive tool, such as the PSiber Pinger, will go a long way to resolving lower-level network issues quickly so that you can focus on your DICOM questions and issues. It is a good rule to work from the bottom up with any network issue. What appears to be a DICOM performance issue can in fact be a network duplex problem. Before spending hours testing this at the DICOM level, a basic network diagnostic may reveal that the problem is actually at a lower level.

One option that a test bed also provides is an opportunity to anonymize patient information: in today’s Health Insurance Portability and Accountability Act environment, this becomes a critical tool for protecting patient health information when we wish to share the image information but not the specifics of the patient information. One example is being able to share a problem study with vendor engineers but not share the actual patient information: “Why is this study behaving in this way on our PACS?”

With time, it is possible to collect a full set of software tools for PACS problem solving that best suits the interests, skills, and purposes of the implementer. Every PACS administrator, field service engineer, and DICOM developer will find a different tool kit useful. But having these tools available, and learning to use them effectively, will tremendously enhance success as a PACS grows, and the more these tools are used, the more the user will learn about DICOM.

R.L. “Skip” Kennedy, MSc, is assistant director, radiology informatics, Northern California Kaiser, Kaiser Permanente, TPMG, Roseville, Calif.

References:

  1. Electronic Radiology Laboratory at Mallinckrodt Institute of Radiology Central Test Node. wuerlim.wustl.edu/DICOM/ctn.html
  2. David Clunie’s Medical Image Format Site. www.dclunie.com
  3. Otech. Training materials. www.otechimg.com
  4. Conquest DICOM version 1.4.9. www.xs4all.nl/~ingenium/dicom.html
  5. PACS ping scanner: Angry IP Scanner. www.angryziber.com/ipscan