Have you ever noticed how the most interesting features or subjects we see and hear about at the annual meeting of the Radiological Society of North America are rarely available at that time and, sometimes, not even a year later? This observation seems especially true for picture archiving and communications systems (PACS) developments.

Shortly after every RSNA, the brightest and best from the PACS companies head back to volunteer duty on various DICOM and Integrating the Healthcare Enterprise (IHE) planning committees. By April/May of each year, the IHE committees have made their suggested changes or additions to the DICOM standard that will enable specific attributes to work in the real world. Even before the latest changes are ratified, the vendors' engineers are busy trying to determine which of the new DICOM elements merit inclusion in their own product development schedules.

Making that determination requires a somewhat public discussion about the effects that those changes will or will not have on their current PACS product. Not surprisingly, some of those discussion points find their way into Requests For Proposal (RFP) documents or the corresponding RFP responses. Not surprisingly, some of those points find their way into competitive sales presentations. And that is how the rest of us come to hear about new features that will not become available for a year or more.

The latest acronyms added to the DICOM lexicon are GSPS and KON. They were already buzzwords by Sunday afternoon of the 2002 RSNA meeting, though few of the vendors had incorporated them into their product development schedules. Greyscale Softcopy Presentation State (GSPS) is a DICOM service-object pair (SOP) class that allows the preservation and transfer of the way that images are presented on the various types of displays throughout the system. Window/level settings and image overlays created by the radiologist on the diagnostic display can be preserved and transferred to the web viewer station in front of the referring physician. Key Object Notes (KON), actually a specialized form of DICOM Structured Reporting, is a DICOM SOP class that allows the radiologist to mark key images and attach a brief text note to the collection. Both of these tools would greatly assist a referring physician in wading through a 750-slice CT study. GSPS and KON greatly enhance the utility of a PACS, and it would be desirable to have both of these features. If the two features are provided via DICOM, the availability is even more significant, because that would make it possible to transfer changes in GSPS and KON between PACS subsystems provided by different vendors, representing the holy grail of connectivity between PACS systems.

A HOT TOPIC

Since a growing number of imaging departments, as well as multi-department health systems, find themselves having to integrate legacy PACS, teleradiology, and web server subsystems into coherent systems, DICOM support of GSPS and KON is suddenly a very hot topic. Even for an imaging department starting from scratch, support for these two latest DICOM SOP classes is a must, because they are an absolute prerequisite for a multi-vendor system. The mere possibility of integrating the diagnostic display subsystem from one vendor with the archive subsystem from another vendor, and maybe the web server subsystem from a third vendor, is the surest way to achieve the best price/performance package&even if the eventual system ends up coming from a single vendor.

So why are these two SOP classes missing from so many PACS solutions this year? The DICOM and IHE efforts are not out of sync with the vendor's development schedules. Indeed, the standards effort appears to have become an integral part of a vendor's product development cycle. So what is the delay?

While many PACS vendors support GSPS-like and KON-like features in their PACS, the features are not based on DICOM. In many systems, data elements such as window/level, overlay, and key image markers are stored in the vendor's PACS Directory Database, not with the image in the Image Database. As such, they cannot be transferred to the other vendor's system using DICOM operations. Some vendors store these data elements in proprietary fields of their DICOM image header. In these cases, they might be transferred with the image to another vendor's system, but, without a "magic decoder ring," the data elements are not recognized by the receiving system and therefore cannot be utilized.

Unfortunately, the support of the DICOM SOP classes for GSPS and KON in many of the current PACS offerings is going to take some time. Perhaps "DICOM-izing" these operations goes to the heart of how these systems create and manage the data elements, and it takes time to reinvent that wheel. There may be as much competitive pressure resisting open system connectivity as there is for embracing that connectivity.

At this point in time, the potential buyer of any new PACS component needs to understand all of the various connectivity issues before making that purchase. It is important to understand how all of the data elements are managed and moved throughout the system and its subsystems. It is important to understand what subsystem can and cannot be connected to another vendor's subsystem. After all, it is your data, and years from now you are the one responsible for being able to access it&all of it.

Michael J. Gray is president, Gray Consulting, Novato, Calif, graycons@well.com.