By Herman Oosterwijk
Despite all the benefits of the DICOM standard, it's not perfect. Several idiosyncracies remain in the standard that can cause trouble even in standard PACS deployments.
One of our training class attendees recently e-mailed me to tell me that he had finally figured out what prevented images from being displayed at his workstation for the past three months. It was one of what I call DFTs, or DICOM Frequent Traps.
In his case, the digitized film images were always displayed inverted on his viewer, even though the MR and CT images were displayed correctly. To prevent a radiologist from having to apply this feature for every digitized film image, there is a field in the DICOM header that identifies whether a "zero" value should be interpreted as black or white, the so-called "photometric interpretation" data element.
The software should look at that field and automatically display the image with the correct gray scale. I would estimate, however, that 50% of novice CT/MR viewing software developers that try to accommodate digitized films forget to look at this field.
There are several of these idiosyncracies in the DICOM standard. For example, DICOM queries to the PACS database are case-sensitive. That means that when asking for "Smith," you won’t get all the "SMITH"s back. Nothing is more frustrating than being unable to access images stored in the archive.
These are so-called "orphan images," the equivalent of lost films in the hard-copy world. The lost studies problem is even worse, however, in the PACS domain. With a hard-copy film, you might be able to look through the day's film jackets to find out whether the study was misfiled. This obviously can't be done with a database, since you may not know how to look for the image.
Fortunately, most vendors have now implemented a workaround for this problem. Some incorporate case insensitivity for the query, which was formerly a DICOM standard violation. The DICOM standard was modified last year to incorporate case insensitivity (another reason for vendors to upgrade their software on a regular basis).
Another issue that sometimes impacts the plug-and-play capability of PACS is a lack of specificity in the DICOM conformance statements. A PACS system administrator explained to me recently that he had a problem with viewing ultrasound images on his workstation. Although the workstation's conformance statement clearly indicated support for DICOM ultrasound image storage (so-called SOP Classes in DICOM), it did not display the color Doppler information when connected to the ultrasound scanner.
Even though this workstation software happens to be one of the top-selling viewing software packages in the market, it did not support the color display of the images (independent of whether the actual display was a color monitor or not). Typically, I find that the vendor's product specifications include the limitations of the system about 50% of the time. Not surprisingly, some vendors would rather talk about what a system does than what it does not do.
Another example is a system's support of a modality look-up table. Some computed radiography vendors send the images in a preprocessed format that requires the application of a look-up table to make the images viewable. Although specified in the standard, some vendors don’t support this feature, forcing the images to look really "flat." Again, this problem is diminishing, usually due to user complaints.
In addition to these incompatibilities and missing functionality, there is still proprietary information being exchanged between systems. Several vendors have implemented their own database query language for communication between workstations and archives. This is OK, as long as they support the "standard" DICOM language as an option.
There is also a feature called the reading worklist or folder, which allows a group of radiologists to read from a common pool of examinations. When a radiologist wants to read a new study, he or she picks the next one from the list, while a message is sent to others that have access to this examination to indicate that someone is reading it.
This "locking" mechanism is also communicated in a proprietary manner, because it only has been recently added to the DICOM standard. Adherence to the standard will prevent situations, as I saw recently, at a site where the user had purchased a third-party vendor workstation. Even though the third-party workstation had a richer feature set, it was useless for general reading, because there was no way a radiologist could figure out whether an exam was read, unread, or being read by someone else.
To sum it all up, there are still idiosyncracies between systems that prevent a plug-and-play environment. As vendors upgrade their software and deal with the remaining proprietary communications such as the worklist, these problems will begin to fade away. Progress is being made, but we are not quite there yet.
By Herman OosterwijkAuntMinnie.com contributing writer
March 21, 2001
Herman Oosterwijk is president of OTech, a healthcare technology training and consulting firm based in Aubrey, TX . He participates actively in the DICOM and HL-7 standardization effort. Questions/concerns: [email protected] or www.otechimg.com.
Click here to post your comments about this story in our PACS Digital Community. Please include the headline of the article in your message.
Copyright © 2001 AuntMinnie.com
