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.
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.