Tuesday, July 17, 2012

Is your PACS ready for DICOM 4.0?


Despite the title of this article, DICOM does not have any version indicator; as a matter of fact, the DICOM standardization committee, looking back, regretted that they called the newly established version DICOM 3.0 to indicate its relationship with the preceding ACR-NEMA versions.

However, the DICOM standard is continuously expanded: as I always tell my DICOM students, the standard is never more than two months old, as that is the frequency with which the standardization committee approves and finalizes new additions. Why then call this 4.0? Well, to indicate that the current data format specifications look quite different than the original version, which was defined and became popular in the late 1990’s. As a matter of fact, a gradual and silent transition has taken place over the past 15 or so years.

The change began with the new DICOM DX SOP Class, which is meant to be used for not only digital X-ray (DR systems) but also for computed radiography (CR) systems. The main reason for this new SOP Class was the need for a stricter header definition and encoding of pertinent information to benefit the definition of hanging protocols. For example, body part and view are now encoded, so instead of “head” for body part, the SNOMED code T-D1100 would be used to identify the anatomic region, and instead of LAT view, it would specify the code of R-102CD. In addition, there was a need to exchange both unprocessed, raw data and viewable data that can be presented “as-is,” hence the creation of two different SOP Classes for digital X-ray modalities, “For Processing” and “For Presentation.” The For Processing images are typically used as an input for a CAD device as it is the raw, unfiltered full dataset. The For Presentation images produce the view used by the radiologist.

The next major change included the new definition of objects for MRI and CT, which are called “enhanced SOP Classes.” The major change was the definition of “dimensions”, which can be unlimited. This was needed because the traditional linear, simple hierarchy that existed in the standard, whereby a patient can have multiple studies, which can include multiple series of images, was insufficient to cover the many variances and changes in image acquisition. Every vendor has created many private attributes to describe these various acquisitions, which works great if these are displayed on the same vendor workstation, but becomes a problem when displayed on another vendor’s workstation.
 
In addition, in order to reduce overhead when sending thousands of images as single slices, each requiring an acknowledgement by the receiver, these objects are now grouped in a single multi-frame CT or MRI object. This new SOP Class structure, which allows for stricter encoding of all header parameters and the ability to define multiple dimensions, has become the de-facto basis for all new SOP Classes such as the new classes for new cardiology and fluoroscopy, ophthalmology, pathology, and the new mammography tomosynthesis studies.

Another major change was the creation of Structure Reports (SR), which was driven by the need for ultrasound devices to exchange measurements in a standard, coded manner, using well defined templates. Most of the common ultrasound procedures, especially for cardiology but also OB/GYN and others, now have a well defined template, which can be stored in the PACS as it follows the DICOM protocol, and is interpreted by reporting systems, eliminating a lot of duplication by radiologists. In addition, the SR are also very well suited for presenting key images in a standard manner. Other well supported applications are the use of SR for CAD, and, most recently, for dose reporting, which has become a major issue, especially in California, which is requiring this reporting.

Presentation states also have been slipped in as an enhancement, whereby radiologists can save their annotations and measurements from a workstation in a standard manner, instead of in private header attributes or database records. Many of the current PACS systems now support this feature, albeit some of them in a somewhat awkward and user-unfriendly manner, which hopefully will be taken care of in future release upgrades.

So, are you ready for all DICOM 4.0? Most likely not; except for some special applications such as cardiology, which is embracing SR big time, most radiology systems and reporting systems are still struggling with SR support. Enhanced CT and MR support is still very limited, keeping the status quo of having to use modality and vendor specific workstations for specialized processing. Dose SR are also still in their infancy. It is therefore critical to plan for these enhancements, especially as they will provide major efficiency improvements and better visualization capabilities.

One should also be aware that even if a vendor specifies support for these new extensions, support for these new objects at a workstation might lack serious functionality. Case in point is a vendor that supports the new enhanced CT but merely organizes the images in a single large stack instead of interpreting the rich header definition. Also remember that the only way vendors will be implementing these improvements is by user pressure and education.


6 comments:

  1. True, there are many additions, but the reason for the poor adoption rate is not laziness from the vendors. All these new objects are simply way to complicated. SR's and enhanced multi-frames are just nightmare to implement. Moreover, the gain from implementing them is yet to be seen. It's classic over-engineering examples. This is something DICOM commity should take into consideration if they don't want to be in the same position as HL7 found themselves with HL7 3.0

    ReplyDelete
  2. SR is a fantastic thing. We've been using it for over 4 years now and with better than average success. However, I will go as far to say that the standard may need more work as far as confining further the strucure and types of information required. We have multiple vendors (albeit older software versions) that have still different philosophies as to what information makes it into an SR file and what does not. In addition the methodoligy for handling muliple measurements is far from standard.

    Matt H. CIIP

    ReplyDelete
  3. Great post Herman, it does beg the question, shouldn't a customer invest in some infrastructure that is flexible and can help with the newer objects yet encode the data for devices that aren't quite ready. For example convert standard CT to enhanced CT and back depending on the device it is connected to?

    I for one am pleased to see DICOM continue to push ahead, be it standard transfer techniques such as you highlight here (SOP/TS) or newer/enhanced web based methods such as DICOM Web Services (WG-26 I believe).

    Regards,
    Shannon Werb
    Acuo Technologies

    ReplyDelete
  4. Hi Shannon,
    it is actually not possible to convert from "old" to "new" as the new SOP Classes have much more required info. The other way around is OK, but it goes way beyond "tag morphing" though as it also requires a conversion from multifram to single frames, so it is rather involved.

    ReplyDelete
  5. Hi Shannon,

    Herman is right, it is not possible to simply convert "old" to "new", newer devices should be implementing the much richer "enhanced" objects. This will take time...

    But there is DICOM Standard's work in progress to facilitate the conversion of "legacy" to "enhanced" (but only for some limited "pragmatic" use cases). See DICOM Supplement 157 (I'm quoting from Scope section):

    This Supplement defines IODs and SOP Classes for storage, query and retrieval of legacy single frame images converted into enhanced multi-frame Images.

    ...

    This supplement addresses the practical aspects of conversion of single-frame legacy instances into enhanced multi-frame instances to enable use of the advantages of attribute and bulk pixel data consolidation and access facilities that are already present in the standard.

    The use-cases within the scope of the supplement include:

    • modality to PACS transfers via conversion to multi-frame by a third-party device,

    • PACS to modality, display, workstation or analysis system transfers (whether via DICOM or web services, local or remote) after conversion to multi-frame within the PACS, and

    • PACS to PACS (or other archive) transfers, either after conversion to multi-frame within the source PACS or by a third-party device.

    It is NOT the expectation that modalities will generate Legacy Converted Enhanced Image Storage SOP Instances; rather, they should create True Enhanced Image Storage SOP Instances fully populated with the appropriate standard attributes and codes.

    This Supplement defines new Image Storage SOP Classes and an extended negotiation option for the C-FIND, C-MOVE and C-GET SOP Classes to allow querying and retrieving a “view” of a study that is restricted to the converted multi-frame rather than the legacy
    single frame images, and corresponding modifications to the frame-level retrieval SOP Class.

    ReplyDelete
  6. Decent post. That was interesting to read. I also advise you to use the following app to catch a cheater.

    ReplyDelete