Why Does the DICOM Standard Exist?

by David Giese on May 15, 2020

The DICOM standard’s purpose is to facilitate interoperability between medical imaging systems from different vendors. The standard defines a file format for storing medical images, protocols so applications can exchanging them, and a conformance format so buyers can determine which systems can (hopefully) interoperate. But perhaps most importantly, DICOM provides a standardized model of reality. This information model is the foundation on which interoperability is laid.

This article is the first in a series. If you are new to DICOM, we hope this series will help you get started quickly. If you have used DICOM before, we hope it provides some interesting new perspectives on the standard.

What is DICOM?

The DICOM standard document has a succinct presentation of its scope in section 1.1 :

DICOM facilitates interoperability in two senses. First, it facilitates a technical “syntactical” interoperability:

• whether you use big endian or little endian
• how to indicate data compression
• the order to send bits across the network
• a JSON format for an image with its meta data.

Developing software that follows these technical details precisely can be challenging. Fortunately, there are several decent libraries out there to assist a lot with this.

Beyond a purely technical interoperability, DICOM also facilitates a “semantic” interoperability.

Semantic Interoperability

By “semantic” interoperability we mean ensuring that vendors use and require metadata in a consistent manner. Given the breadth of the medical imaging field, you can imagine how challenging this is! How does DICOM do this?

DICOM facilitates semantic interoperability by providing a consistent model of reality across vendors.

Here is a diagrammatic representation of the core part of DICOM’s model of reality:

This shared model of reality facilitates interoperability, because without it, different vendors would likely have subtly (or drastically) different models of reality, making it difficult to interoperate.

For example, one vendor may not bother including a “Study” object in its model of reality, and another vendor may require certain pieces of data that another vendor omits. In both cases, integrating equipment and software from these two different vendors would be more complicated, and in some cases impossible.

The fundamental problem is that reality is complicated!

It is difficult to model it accurately, and depending on your application, it may or may not make sense to include certain details in your model. There is a tradeoff between accuracy and simplicity.

In fact, DICOM itself recognizes that its model is not perfect.

This information model is a simplification of the real world concepts and activities of medical imaging; for acquisition modalities, a Study is approximately equivalent to an ordered procedure, and a Series is approximately equivalent to a performed data acquisition protocol element. In other domains, such as Radiotherapy, the Study and Series are less clearly related to real world entities or activities, but are still required for consistency. This simplified model is sufficient for the pragmatic needs of managing imaging and related data collected in routine practice.

Thankfully, despite these simplifications, DICOM’s model is pretty good. And in our opinion, it is much better to have one flawed model than dozens of flawed models—one for each vendor!

Of course, DICOM doesn’t completely eliminate integration problems for a few reasons:

1. Applications don’t properly implement the standard
2. Applications implement different versions of the standard
3. A lot of meta information is optional (so an application may choose not to provide it)
4. The standard is ambiguous.

Once again, DICOM is aware enough to inform you of its own limitations in case you couldn’t deduce it yourself:

This Standard facilitates interoperability of systems claiming conformance in a multi-vendor environment, but does not, by itself, guarantee interoperability.

Conclusion

The DICOM standard’s goal is to facilitate interoperability between medical imaging systems from different vendors. It does this by standardizing technical networking and storage implementation details, but perhaps more importantly by providing a consistent model of reality.

In our next article, we will introduce you to some of the DICOM lingo and will give you some guidelines for reading the DICOM standard more effectively.

Innolitic’s DICOM Expertise

Innolitics has considerable experience with DICOM. In addition to developing DICOM-conformant software for our clients, we have built several tools:

• Our DICOM Standard browser is used by 10,000s of developers and radiologists around the world.
• Our DICOM standard parser extracts key information from the standard into a JSON format, which can be used.
• Our dicom-numpy Python library simplifies the process of forming a 3D numeric array from a set of DICOM files.
• Our PACSMAN Python library providers a high-level API for common PACS communcation operations. It also includes a file-system backend for use during development.

DICOM Part 1 © NEMA. The DICOM Standard is under continuous maintenance, and the current official version is available at http://dicom.nema.org/.