Introduction to DICOM - Chpater 2 - Why is it this way in DICOM?

Introduction to DICOM
Chpater 2 - Why is it this way in DICOM?
Many times when I explain features and aspects of DICOM I get questions like, “Why do you need DICOM if you have JPEG and XML?”; or, ”why is DICOM so complicated?”. Many variants of this question come up over and over again. These types of questions can be very broad or very specific and relate to all kind of choices that the people who write the standard make and the options that they take.

Here’s an example. In DICOM there’s a command called C-FIND that is used to make queries to another system, to search for images and other entities. You would naturally think of SQL, but in DICOM there’s a different way of doing it.

Let’s continue with the C-FIND example. The DICOM C-FIND command has three variants, each with its own data model. These variants are ‘Patient Root’, ‘Study Root’ and ‘Patient Study Only Root’. I’m always asked why do we need three variants and I really can’t give a simple answer. Luckily, the third model, ‘Patient Study Only Root’ is now obsolete so we are left with only two models.

There are many more examples like the C-FIND Query Model where DICOM just have too many options and redundancies. But as the standard became more and more common and dominant, developers just took care of all the options and degenerate the redundancies. Many PACS implementation simply treat all three models using the same code. My answer to this kind of questions is: "That’s the way it is in DICOM and let’s just get on with it".