DICOM explained simply — how medical images are structured and exchanged

TL;DR

DICOM stands for Digital Imaging and Communications in Medicine. It is the standard used to store, transmit, retrieve, process, and display medical imaging information. When a scan is produced by CT, MRI, ultrasound, or X-ray equipment, DICOM gives that data a structured form that other systems can understand and exchange while preserving the information needed for clinical use.

Why DICOM exists

Medical imaging became digital in an environment where scanners, archives, viewers, and post-processing tools were often built by different vendors. DICOM provided the common structure that let those systems interoperate around the same imaging exam. That is the high-level reason it became foundational, and after that point the more interesting question is how it actually represents an imaging study.

DICOM connects imaging modalities with downstream clinical systems through a shared standard.

How a DICOM object is structured

At the technical level, DICOM groups information into data sets. That means a medical image is carried together with structured attributes describing the exam. The DICOM concepts page gives a simple example: a chest X-ray file can contain the patient ID within the file itself, so the image remains tied to the information that identifies and describes it. This is one of the main reasons DICOM is useful in clinical systems. The image does not travel alone as anonymous pixels.

For a beginner, it helps to think of a DICOM object as having two big parts. One part is the descriptive layer: attributes such as patient information, study information, modality, identifiers, and acquisition details. The other part is the payload layer, which may contain the pixel data itself or other imaging-related content. In practice, software working with DICOM spends a lot of time reading and interpreting the descriptive attributes before it even gets to rendering the image. That is why DICOM behaves more like a structured medical object than a simple picture file.

A simplified DICOM file layout

Tags, attributes, and value representations

DICOM data is organized as individual attributes, commonly referred to as tags. Each attribute has a defined meaning in the standard and is encoded with an associated data type, called a Value Representation or VR. Even if a beginner does not yet care about byte-level encoding, this idea is worth understanding early: DICOM is not a loose bag of metadata. It is a standardized attribute dictionary with defined semantics and defined encoding rules, which is one reason different systems can exchange it reliably.

Once you know that, many practical details start to make sense. A viewer is not just loading image bytes; it is parsing known attributes. An archive is not just saving files; it is indexing studies, series, and instances based on standardized identifiers. A server responding to a query is not guessing where the patient or study information lives; the standard already defines that structure.

The hierarchy: study, series, instance

One of the most useful ideas in DICOM is its hierarchy. Imaging data is organized around levels such as study, series, and instance. In the web-services part of the standard, these appear directly as resources and paths such as /studies, /series, and /instances, which makes the hierarchy very explicit.

This hierarchy is important because a medical exam is usually not one image. A study may contain several series, and each series may contain multiple instances. For example, one CT exam may include many slices and possibly several reconstructions or related derived objects. The hierarchy gives systems a stable way to organize that complexity, query the right level, and retrieve exactly the subset they need.

The DICOM hierarchy

DICOM and JPEG

JPEG enters the story at the level of the image pixels themselves. In DICOM, the image is usually carried in the Pixel Data (7FE0,0010) element, and that pixel data can be encoded in two broad ways defined by the standard: Native format, which is uncompressed, and Encapsulated format, which is typically used for compressed pixel streams. So a DICOM image is not automatically compressed. Some DICOM instances store the pixel values directly in uncompressed form, while others store them using a compression transfer syntax.

This is where JPEG fits in precisely. JPEG is not the DICOM object itself; it is one possible way to encode the pixel data inside that object. DICOM explicitly supports encapsulated compression methods including JPEG-family transfer syntaxes, with both lossless and lossy options, as well as other schemes such as JPEG 2000 and related encapsulated syntaxes. In the encapsulated case, the Pixel Data element is carried as a fragmented byte stream, while the dataset around it still follows DICOM encoding rules such as Explicit VR and Little Endian dataset structure for these transfer syntaxes.

That distinction matters because the phrase “compressed DICOM” usually means that the pixel data is compressed, not that the whole file has been turned into a generic image format. There is one notable exception in the standard — DICOM Deflated Explicit VR Little Endian — where the entire dataset is first encoded as ordinary DICOM and then compressed with Deflate. The standard itself notes that this syntax is especially useful for objects without pixel data, such as structured reports, and is not particularly effective as an image-compression method.

In practice, exporting a DICOM image to an ordinary JPEG usually means taking the decoded image and writing out a rendered picture. The visible image may still look fine, but the result is now just a conventional image file. It no longer preserves the original DICOM pixel representation, its transfer syntax, or the full DICOM instance as it existed in the imaging workflow. That is why JPEG is convenient for simple display and sharing, while the original DICOM instance remains the form used for archival fidelity, standardized exchange, and imaging-system processing.

Transfer syntax and why viewers need DICOM-aware software

DICOM does not assume that all image data is encoded the same way. The standard defines multiple transfer syntaxes, including ones for JPEG 2000 compression. That means a DICOM viewer has to do more than open a bitmap. It has to understand the DICOM object, parse the metadata, interpret the identifiers and hierarchy, and decode the pixel data using the negotiated or stored transfer syntax.

This is one of the reasons medical imaging software tends to be specialized. The task is not only to display pixels. The software also has to preserve the structure of the exam, handle study-series-instance relationships, and often support retrieval, rendering, or conversion paths that ordinary image viewers never need to think about.

How DICOM moves between systems

DICOM was designed around exchange between systems, not just local file storage. The official overview states that DICOM is used to produce, store, display, send, query, process, retrieve, and print medical images and derived structured documents, while also managing the related workflow. That broad scope explains why DICOM became central in hospital imaging environments.

In the modern web-oriented form of the standard, DICOMweb exposes these ideas as RESTful resources and transactions. PS3.18 describes DICOM web services for transmitting composite SOP instances, and the standard defines resources such as studies, series, instances, and frames. WADO-RS supports retrieval of studies, series, and instances, while the Store Transaction uses POST to store studies, series, and instances contained in the request payload.

DICOMweb exposing imaging data to web-based viewers

For engineers, this is where DICOM starts to feel much more concrete. A system may expose studies and series over HTTP, allow retrieval of metadata separately from rendered output, and store whole instances through standard web transactions. The underlying data model is still DICOM, but the access pattern becomes much closer to the API style familiar from modern software systems.

Why this structure matters

The real strength of DICOM is that it lets medical images move through a workflow without losing their structure. A scan can be acquired, stored, queried later, retrieved by series or instance, processed into derived objects, and displayed in different forms, all while remaining part of a standardized hierarchy. That consistency is what makes large-scale imaging systems workable across vendors and across time.

Bottom line

After the opening motivation, the most useful way to understand DICOM is to stop thinking of it as a general idea about interoperability and start thinking of it as a technical model: standardized attributes, a study-series-instance hierarchy, defined transfer syntaxes, and standardized exchange services. That is the layer where DICOM becomes interesting, and it is also the layer that explains why it has remained the core infrastructure standard for medical imaging.