Nuclear medicine tackles DICOM connectivity issues

A group of nuclear medicine cardiologists and others who use nuclear medicine data have formed an ad hoc task force to encourage vendors to improve their DICOM software and work with each other to test their DICOM connectivity.

Members of the task force, which first met in December 2000, represent five professional organizations. Their main concern was that they were not able to exchange nuclear medicine image data in a meaningful way even though they were using equipment that claimed DICOM conformance for nuclear medicine. The task force's challenge to nuclear medicine vendors was to get together and either fix the DICOM standard or fix their software for real interoperability.

DICOM connectivity problems are not uncommon, especially with new equipment. But the problem in this case was not related to new software or additions to the DICOM standards. Nuclear medicine was actually one of the first modalities to implement an "information object" under the new DICOM standards when vendors and users formed an ad hoc National Electrical Manufacturers Association (NEMA) committee in 1990. After several years of work, the NM committee approved a data model that included multiframe image definitions. A short time later, the committee reconvened and added multidimensional capability to better represent all of the NM data types. This version was approved as part of the DICOM standard at the end of 1995 and is still in use.

In response to the task force's challenge, nuclear medicine manufacturers and the Society of Nuclear Medicine's Computer and Instrumentation Council made plans to stage a data exchange demonstration at the 2001 SNM meeting in Toronto. The special task force met again in conjunction with the SNM meeting to review progress and set new goals. As a first big step, the demonstration showed that data exchange worked well with only a few minor difficulties, and that the DICOM standards for nuclear medicine were basically sound. Most vendors were using updated versions of their DICOM software, and the demonstration provided some validation of their work.

How could nuclear medicine get along for so many years without DICOM interoperability being put to the test? One reason has to do with the nature of the DICOM standards. A prevailing misconception about DICOM is that any imaging equipment that claims a DICOM interface will be able to connect and exchange data with any other. In reality, DICOM provides a basic framework for connectivity and functionality, and then defines a large array of modality-specific image formats and a collection of services, such as query/retrieve and print management.

Under the image format specifications for each modality, nuclear medicine for example, some fields are required, but most information is optional. If only minimal image information is included in the data sent out by a NM scanner, a receiving system may be able to display the images but will not have the ability to reprocess the data in any way. So a minimum DICOM implementation, even if done correctly, allows only a limited amount of interoperability. To make matters worse, a few implementations did not strictly follow the rules defined for NM in the DICOM standard. There is also in DICOM a "bypass" type of image called Secondary Capture, which can be used for sending generic images with no modality specific information. This type of data transfer was sometimes used for NM data, thus bypassing the purpose and usefulness of DICOM.

Historically, in typical clinical settings, a nuclear medicine system was used to acquire patient data, process the data, and then review the data. Each vendor had processing software uniquely linked to its acquisition software and review software uniquely linked to its processing software. Many users reluctantly used the software provided by vendors rather than face the challenge of translating data to use on other workstations. Many did not realize that DICOM was capable of providing a high level of interoperability, and that most imaging equipment was using only a small part of that capability. Manufacturers of PACS and viewing workstations were also not making full use of all the information available in nuclear medicine image data.

The DICOM standard definitions for various types of NM image data may be a little confusing to some implementors because of the multiframe format. Consider the fact that even static images are defined as multiframe images. The reason is that a set of static images may be related to each other because they were acquired simultaneously on multiple detectors, or with multiple energy windows, or both. Likewise, dynamic data (time sequenced or cine images) may also be acquired simultaneously from multiple detectors and multiple energy windows.

The NM data definitions in DICOM were designed to accommodate multidimensioned sets of frames, and the exact organization of the framed data is specified for each of the various study types such as multigated, tomographic, and so on. In order to exchange data using DICOM, each nuclear medicine manufacturer had to convert its internal image data formats to match the DICOM specifications.

Manufacturers of PACS workstations typically have the most difficulty accommodating the DICOM image formats for all modalities, because each one has a complete set of definitions including a large number of related attributes. Correct display of all the possible image types requires a detailed understanding for each set of DICOM definitions and a correct software implementation. Purchasers of nuclear medicine systems and PACS workstations need to perform detailed reviews of vendors' DICOM conformance statements, and ask vendors for the results of connectivity tests performed with other equipment.

The data exchange demonstration in Toronto was a first step toward improving NM interoperability. By design, the test data represented only a subset of nuclear medicine data types and did not include "live" DICOM connections. Nuclear medicine manufacturers and users are already planning a more complete test for next year in conjunction with the SNM meeting. The IHE demonstrations (Integrating the Healthcare Environment) at the RSNA and HIMSS (Healthcare Information and Management Systems Society) meetings may be used in the future to provide test opportunities, especially for PACS vendors, to show that NM image data can be exchanged over a DICOM network.

IHE does not perform validation services for DICOM connectivity. What IHE does provide is a strict set of guidelines and neutral testing grounds prior to the demonstration, but it is up to each participating vendor to test its own software.

If vendors discover that changes in the DICOM standards are necessary, they can go to NEMA with recommendations. Changes and additions to the DICOM standard are coordinated through Working Groups that report to the DICOM Standards Committee under NEMA. Working Group 3 (WG3) is responsible for the nuclear medicine portions of the standard. WG3 is in the process of recommending some minor clarifications and the use of standardized nomenclature for NM images. The group is also aware of the work of the ad hoc task force and results of the SNM demonstrations. WG3 does not validate or certify any vendor's software but does provide a forum for members to discuss problems. If members of WG3 feel that changes to the standards are required for interoperability, they will begin the process of writing a proposal and soliciting review and comments from users and vendors.

The DICOM standard has become so large and complex that many users and smaller equipment manufacturers find it difficult to pinpoint the sources of interoperability problems. Consulting companies such as Otech can help with DICOM training and rooting out the causes of connectivity problems. They can also help with writing purchase specifications that put more pressure on vendors to test their DICOM software and write better conformance statements for their products.

For information on IHE, see http://www.rsna.org/IHE

For the official DICOM Web pages, see http://medical.nema.org/dicom.html

For the SNM Computer and Instrumentation Council, see http://www.snm.org/about/new_councils_1.html

For more information on DICOM training, books, and publications, see http://www.otechimg.com