
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.