Better Than Aspirin: Modality Testing and Troubleshooting

Why does it typically take several days to get a new modality up and running, from a connectivity perspective? Installing a new modality and upgrading existing modalities are recurring events. Some of these installations take just a few hours, but others could take days, or even longer. It is also not uncommon to have to roll back a new modality upgrade. Proper preparation and verification eliminate, in most cases, the potential disruptions and stress. One should also know that it is critical to ensure that any issues that might jeopardize PACS availability or data integrity are identified and dealt with; examples of these data-integrity issues include the possibility that hanging protocols might not work anymore because the series description in the header is suddenly different, as well as the possibility that creating duplicate image unique identifiers will cause database-integrity problems. To prevent these issues, one should follow these steps. Read the fine print. Check all documentation, especially interface specifications and DICOM conformance statements, prior to the installation. Check for any incompatibilities or changes with regard to DICOM image type support and encoding. A good example of an incompatibility is a new Panorex unit that requires the modality IO (Intraoral radiograph) to filter the appropriate entries in a worklist, while the modality worklist provider does not have the capability to sort on anything but CR. Make sure that expected information in the image header will be present, especially information related to hanging protocols. Check the series-description attributes for their values and make sure these are configured at the workstations. Note that every vendor is required to provide a conformance statement, and if everything fails (it wouldn’t be the first time that a salesperson provided the wrong documents), they almost always are available online at the vendor’s website. Get sample images up front. For a new modality, request sample images from the vendor and make sure those sample images can be properly rendered on PACS workstations. A CD is the best exchange mechanism to use for that. Make sure to get all possible image/object types; for example, for an ultrasound study, those might be single images, multiframes for the cine loops, and both color and black-and-white images, as well as uncompressed and compressed encodings. Validate DICOM conformance. Use a public-domain DICOM-validation utility to check the headers of the sample images against the appropriate DICOM standard. This is available from www.dvtk.org and compares the images against the DICOM standard specification, checking for any errors. You will be surprised to see how many bad images there are out there that do not conform to the DICOM standard. You might need to consult an expert to find out what the potential impact is of any of these violations; some of them are benign, and some of them could have a major impact on data integrity. Test and simulate. When the modality arrives, test the modality interface using a test worklist provider to make sure that the proper responses are generated and presented in the worklist. Have an Application Entity title and port preconfigured and ready to go. Use a previously validated modality simulator in parallel to debug any problems. A modality simulator could issue the same queries that the new modality is supposed to perform, so there is a baseline in case there are issues. View images on the test archive using the production worklist. After successfully using the new modality with the worklist simulator, connect the modality to the production worklist provider and generate several test images. Test images should first be sent to a test archive and viewed on a public-domain viewer. If needed, image headers can be inspected here as well. There are at least two commonly used test servers available in the public domain, Conquest and DCM4CH. Many institutions actually have a mini version of their own databases/archives in place, which are also used as backups in case the regular archive fails or needs to be shut down temporarily for some reason. Send tested images to the production archive and verify them. Only after validating test images in a test environment, send the test images to the production archive. Generate test images for each potential body part, acquisition technique, and procedure. Check for proper placement of entries on the radiologists’ worklist, and for proper display sequence and hanging protocol use at the workstation. Keep these test images available and store them in a safe area so you will have a baseline against which you can check any future changes and upgrades. Monitor periodically, ad infinitum. Once a new modality is up and running, it should be periodically monitored. For a PACS and its components, network management monitoring should be extended to the DICOM applications involved. At a minimum, sending DICOM Echo messages at regular intervals can detect basic issues and alert the PACS administrator before problems affect workflow and/or operations. The figure shows a typical PACS test environment that can simulate the key components of a PACS, to be used during the modality installation procedure. The test environment would consist of: a modality simulator (1) that can request a worklist, send images of all applicable DICOM image types and encoding schemes, execute Modality Performed Procedure Step and Storage Commitment, query a PACS database, and retrieve DICOM objects; a modality worklist simulator (2) that allows a modality to retrieve a worklist (ideally, the worklist is populated with test patients); a database/archive simulator (3) that allows images to be routed temporarily to the test environment; test viewers (4) that can display images and can be used to determine whether a specific issue is related to the PACS software or to image encoding; and a DICOM sniffer (5) that captures DICOM communications (including images) and that can be used to diagnose error conditions or timing problems. Most of these components are available as open-source software or for a relatively small cost, especially compared with the cost of a production PACS. Good IT practices prescribe a test environment; in the imaging area, it is not yet common, but most institutions are starting to see the benefits of having these tools available and performing due diligence.