Digital Imaging and Communications in Medicine (DICOM)

12.1 DICOM Conformance 263
Chapter 12
Incompatibility of Compatible
“If you are not thoroughly confused,
you have not been thoroughly informed”
Murphy’s Law
Remember the question of “DICOM 2003 support” from Chap. 4? Another
question, which I have heard even more frequently, is “Does your software
support Siemens (GE, Agfa, Philips, and so on) DICOM?” First of all, there
is nothing but DICOM 3.0, which any manufacturer is supposed to support.
Manufacturers are only allowed to add their private attributes for something
they do not find in the standard DICOM Data Dictionary. However, this question
brings us back to the main challenge of DICOM: making digital medicine
provider-independent. Has this goal been achieved?
Practically speaking, about 90% has been realized. After nearly 10 years
of solving the provider compatibility issues, I can attest to our greatest relief
that DICOM 3.0 can indeed be used as a common denominator, and any two
DICOM 3.0 devices can be practically integrated into a functional clinical network.
Sometimes it comes seamlessly, but sometimes interfacing DICOM units
from different manufacturers can turn into a headache for you and into a very
revealing experience for your DICOM providers.
Let’s take a simple scenario and see what could go wrong. Let’s say that you
have purchased an MRI unit from company X, and a DICOM server from company
Y. All you want to do is to store images from your X MRI on the Y server.
Chances are, you can connect the two units as prescribed and everything will
start working just as expected. But what if it doesn’t?
12.1
DICOM Conformance
Remember how we discussed the abstractness of the DICOM language? SOPs,
IOD, VRs, AEs, dwelling in their pure world of DICOM definitions never refer
to any particular implementation. On one hand, this has become one of the
most important and carefully designed advantages of the standard, making it
truly universal and device-independent. But the abstractness inevitably leads