What are some of the DICOM tools a PACS system administrator (SA) should have deployed in their network? One of the most important DICOM tools is a monitoring tool. A monitoring tool, what I call the "heartbeat" application, should be the centerpiece in your PACS. Basically, every minute or couple of minutes, the program sends and receives a DICOM verification to every DICOM application entity (AE) on your network. If the system—or a part of it—goes down, this application alerts the PACS administrator so they can take remedial action.
Another tool that is very useful is an active test tool. An active test tool is an application that typically participates in the DICOM communication and takes the place of a modality. Because it simulates a modality, one can use it to uncover—through the application's logging and monitoring capabilities—potential problems before they occur.
Another tool that a PACS SA should have on hand is sniffer. This is a device that can listen in on to all the communication that goes between one device and another. Sniffers allow one to filter communications by IP address or by protocol, such as TCP or DICOM.
If you have ever looked at a sniffer’s output, you have seen there is a lot of communication going on among the different devices on a network. For PACS troubleshooting purposes, you generally don’t need to sniff or capture all that information. Most likely, you are going to be primarily interested in the DICOM protocol activity on the network.
There are two widely available open-source sniffer products available on the Internet: Wireshark and DVTK. You can get the Wireshark product at http://www.wireshark.org and DVTK can be downloaded from http://www.dvtk.org. Either of these applications, when connected to a switch, will allow you to capture all communications among devices and a PACS.
Typical sniffer output allows you to look at three main communication elements: the raw hexadecimal bit data, the protocol associated to it and its communication from point to point. If there are any issues, problems or questions about device connection a sniffer is the tool to use to uncover any errors. The nice thing about sniffers is that they are totally non-intrusive, which means that they don’t participate in the communication. This tool is also very useful in cases of intermittent errors or problems.
Five things to remember
- Don’t schedule any new installations on Fridays. When you connect the device, it will always take you a couple of days to configure it properly. Even if it takes one day you want to have some buffer space, because if it doesn’t work you may not have access to the proper support personnel over the weekend.
- Don’t let your service engineer go until every function and feature of the new device has been tested and validated. Use a sign off sheet and make sure that everything is checked off--including the proper functioning of hanging protocols. Make sure that all the proper software is installed on the device, including any applications needed for monitoring and virus protection.
- Do your homework up front. Review conformance statements and get involved with modality integration. You cannot expect that the biomedical or clinical engineering staff will take care of this. You must validate that the device will function properly with your PACS prior to its installation in the production environment.
- Make sure you have the proper tools. You cannot rely on the service engineers to have them. Make sure you have a sniffer available so that if any problems arise, especially after the service engineer has left, you can do your own investigation and troubleshooting.
- Make sure you have a test environment. You want to have a test archive as well as testing tools and a test viewer. These are all free, open-source, public-domain tools you can download and use. Get familiar with these tools prior to an installation. If you encounter a problem during deployment, you will need to have mastery of these tools.