What Is DICOM?

DICOM is a file format and network protocol used to store and transport medical images. All modern medical imaging systems such as x-ray, ultrasound, CT, and MRI use it for their data.

Digital Imaging and Communications in Medicine (DICOM) is a software integration standard used in Medical Imaging. It's a set of specifications and interfaces to provide a diagnostically accurate representation of medical imaging data and includes tools to transfer, store, and display the information.

First published in 1993, DICOM is used in almost every radiology, cardiology imaging, and radiotherapy device currently on the market. In addition to providing the backbone of digital imaging workflows, it is also used in other medical disciplines that work with structured medical data such as ophthalmology, dentistry, dermatology, and pathology. Remarkably versatile, DICOM is capable of handling a wide variety of data types including 2D and 3D image sets; radiation records; physiological waveforms; and 3D volumetric datasets used in additive manufacturing, virtual reality (VR), or augmented reality (AR). If you work with radiology systems or build software to consume medical imaging data, you will need to process DICOM files and may need to communicate with DICOM servers.

This article provides a high-level overview of DICOM, its components and terminology, and how the tools within the Sonador platform can be used to work with two and three-dimensional DICOM data for building healthcare software applications.

Because this article focuses on the Sonador platform (a cloud-native set of programs used to build medical imaging applications), DICOM concepts will be illustrated using Orthanc; the Open Health Imaging Foundation (OHIF) Viewer; and related tools such as MONAI, SonadorAI, and Sonador3D.

Where Is Dicom Used?

Software systems that use DICOM are split into three types:

Modalities

Systems used to acquire medical images such as ultrasound machines or CT/MRI scanners.

Digital Image Archives

Digital Image Archives (sometimes referred to as PACS -- Picture Archiving and Communications Systems): used to store and query medical imaging data.

Workstations / Viewers

Used by radiologists, other healthcare professionals, and scientists to review the medical imaging data for diagnostic or other purposes.

The DICOM standard provides an integrated set of technologies to enable the diagnosis, management, and treatment of disease. It is the foundation of advanced technologies such as AI, surgical robotics, and patient matched (3D printed) solutions.

Sonador Medical Imaging Platform

File Format and Network Protocol

When new developers begin working with DICOM, one of the points that can often be confusing is that "DICOM" refers to multiple things. It is both a file format, the messaging protocol that modalities and PACS used to communicate, and the transfer protocol used to send and receive DICOM files. DICOM has become an all-encompassing standard that attempts to describe nearly every aspect of digital imaging.

In its most recent release (PS3.1 2021a), the DICOM standard includes twenty-two parts. The sections most relevant to medical software development are Parts 1 (Overview), 5 (Data Structures and Encoding), 7 (Message Exchange), 8 (Network Communication), and 10 (Storage). Part 10 covers the structure of DICOM files, and provides granular details on how to metadata should be encoded' while Part 8 describes the communications between DICOM servers and clients.

Within the Sonador platform, DICOM storage and transfer is handled by Orthanc. Orthanc is an open-source server for working with medical files that can be used as an image database. It provides DICOM PACS, DICOMweb, and REST interfaces for uploading and retrieving data.

Orthanc is used in hospital, medical image processing, and research environments. It has a modular architecture with a "core" system that handles storage and data and "plugins" that implement specific features such as cloud storage, whole slide microscopy, and modality work lists. When properly configured, individual Orthanc instances are capable of working with large datasets that have hundreds of thousands of patients and scores of terabytes of data. Sonador is able to coordinate the work of many Orthanc instances, allowing the overall storage capacity of the platform to scale to millions of patients.

DICOM refers to both a file format (DCM) and a network protocol (DIMSE).

DICOM File Format

DICOM files, like other formats such as JPEG and PNG, encode two types of information -- key/value metadata and pixel intensities -- and are comprised of a preamble, a prefix, a header, and a body. The two most important parts of the file are the header and the body.

The header contains metadata about a patient, acquisition parameters, dimensions, matrix size, color space and encoding, and a broad set of additional parameters. The structure, encodings, and representations of these values are described by Part 10 of the DICOM standard and are known as "standard data elements" (tags). DICOM also allows for the creation of user-defined (or private) tags.

Image data is contained within the body of the file as a single attribute (7FE0) that contains all of the pixel intensities. It is structured as a binary string (zeroes and ones) from which image data is reconstructed using metadata from the header. DICOM is an extremely flexible data format and can be used for a large type of data. As a result, while the data element of a file is most commonly a single image it might also encode multiple frames of a study, a cine (movie) loop, another file (such as a text, PDF, or Word document containing an imaging report), or 3D files such as CAD or OBJ.

The DICOM file format combines patient details (meta) with the medical image data. This means that the file carries its own context. Wherever transferred, DICOM files retain the "who", "what", and "where" of its origin. This ensures that the patient care context can be understood by any system it encounters.

Storage Service Object Pair

Despite a common structure, there can be a great deal of variation between the headers included in different types of DICOM files. The headers for imaging modalities such as CT or MRI differ greatly from those of standard X-Ray or ultrasound. These distinctions can make parsing the files extremely challenging.

To provide more structure and aid in the development of software that read or write DICOM files, the standard attempts to provide guidance on the tags that should be present. For each modality, there is a list of tags called a storage service-object pair (storage SOP) that specify what attributes should be present and their value representation. SOP definitions exist for all common modalities (MRI, CT, Ultrasound, PET, X-Ray, etc), as well as a fair number of variants.

To be a valid DICOM file, each SOP will specify three types of tags:

"type 1" are mandatory tags
"type 2" are mandatory tags that can contain a null value
"type 3" are optional tags

An exhaustive list of the available SOP classes is available from the DICOM website, organized by the SOP "class ID." The SOP class ID is a unique identifier that can be used to determine what type of modality an image was created by.

The structure of the DICOM format allows for the management of nearly any type of data. What is needed to describe an MRI scan is different than what is needed for a x-ray. Storage object pairs help bring clarity.

Orthanc Explorer

Orthanc provides a web user-interface to display and manage DICOM files. It provides a web-based interface for many aspects of the Orthanc API (and Sonador client) and provides tools to upload images, query modalities that are associated with the server, push or pull studies with DICOMweb peers, and inspect tags for images stored by the server.

You can access the Explorer for Orthanc instances managed by Sonador by going to the "Imaging Server" section in the Sonador Administration panel and clicking on the "Admin" link next to the imaging server you wish to access. This will open a new browser window and redirect you to the Orthanc instance.

Pixel Data

The contents of medical images are stored in the PixelData (0x7fe0. 0x0010) tag. Software working with images can parse the binary string available in this attribute and decode it according to the settings specified in the other header tags.

As noted above, the DICOM standard allows for a broad type of PixelData representations. For example, the standard supports:

The image and its contents can be compressed using standard image formats such as JPEG or Lossless JPEG. Generally, lossless compression is preferred to avoid losing data.
- If compression is applied, an associated transfer syntax should be placed within the header to identify the image compression algorithm and facilitate unpacking.
DICOM can be used to wrap around videos encoded using MPEG-2 or H.264 or specialized formats such as 3D models like STL or OBJ.
DICOM images can encode an array of different images. These are called multi-frames and are used to encode uncompressed video sequences or volumetric (and time-series data).

Pixel data in DICOM files represents the actual image information, encoded alongside metadata for a complete medical imaging record.

Because of the broad number of data types supported by DICOM, some DICOM tools support image transcoding which allows for one image format to be converted to another. Orthanc uses the PNG format for its default transcoded image representation (although JPEG is also supported). If transcoding is applied, DICOM details such as the transfer syntax should be updated to specify what transformations (such as compressing or decompressing the image) were performed and how the source data has been modified.

DICOM Resource Models

Because medical imaging data exists within a larger context of clinical care, the DICOM standard includes a framework to model aspects of "real-world" relationships such as patients, studies, equipment, and measurements. The authors of the DICOM standard have such "Real World Objects" (RWO) and Information Objects to provide a foundation for applications that need to manage DICOM data as part of larger workflows.

As DICOM is file-based, the metadata for these relationships are defined within individual DICOM file "instances." Higher level resources such as collections of images (called series), studies, and patients are modeled from the metadata of instances. The figure at right shows how Orthanc interprets the DICOM resource model:

An individual DICOM file represents an instance and is comprised of headers and pixel data
Each series contains a set of instances
Each study contains a set of series
Each patient has a study and may have a set of studies

For software developers working with imaging resources, the DICOM series is one of the most common resources used for visualization or machine learning use-cases. It (usually) represents an imaging scan/acquisition and a cohesive piece of data. For 2D scans (such as a chest x-ray) there will be a single image; while for 3D scans (such as MRI or CT), there will be a stack of images that can be constructed into a volume.

Sonador Interface: CT Scan — A DICOM series is a single imaging scan or acquisition and represents a cohesive piece of data that might be used for visualization or machine learning. A study is a related set of series. The imaging viewer included with Sonador allows for users to review both. The example in the figure above shows two related CT series.

In addition to the structures described above, imaging series might also be structured in a specific way for technical reasons. For example, it is common for a series' pixel data to be split across a large number of DICOM instances. Medical imaging datasets are often very large (with images larger than 4GB being common), and a single image might be split into potentially hundreds of megabyte sized files in order to allow the file to be processed in memory.

For every DICOM resource, there is a module that specifies the set of DICOM tags that comprise the resource. For example, tags such as PatientID, PatientName, and Allergies are part of the patient module; StudyDescription, StudyDate, StudyTime, and RequestingService fall under the study module; and Modality, SeriesDescription, PatientPosition, and AnatomicalOrientationType, fall under the series module.

Identifiers

Each module defines a set of unique identifier (UID) tags that can be used to uniquely identify and aggregate instances that are unique to specific resources:

Patients: PatientID (0x0010, 0x0020)
Studies: StudyInstanceUID (0x0020, 0x000d)
Series: SeriesInstanceUID (0x0020, 0x000e)
Instances: SOPInstanceUID (0x0008, 0x0018)

These tags play an important part in Orthanc's data modeling and provide the foundation for its patient, study, and series APIs. By convention, StudyInstanceUID, SeriesInstanceUID, and SOPInstanceUID are supposed to be globally unique. This means that no two medical image devices generate the same identifiers, even if they come from two different manufacturers. When writing software that will generate DICOMs, you should take care to ensure that these header values will not conflict with data that might be generated by a hardware device.

When working with patient level resources, it is important to emphasize that PatientID is not guaranteed to be globally unique. Many imaging centers will use an identifier such as a medical record number from their EHR solution to help tie imaging data into other information from the electronic chart. Since patients imaged in different locations might share the same record number, software that works with data at the patient level should verify other identifiers (such as the patient name or birth date) to ensure that data comes from the same individual.

When ingesting data, Orthanc uses the resource UIDs to detect duplicates and aggregate information about patients, studies, and series. To be more web friendly, Orthanc creates its own unique identifiers values that are SHA-1 hashes of the study, series, and instance UIDs. The Sonador client uses Orthanc IDs when retrieving resources via the patient, study, or series APIs.

DICOM ensures consistency and traceability through unique identifiers. It uses machine-generated UID tags for precise data tracking and hospital-assigned ID tags for operational use. Any modification to a DICOM file generates a new UID, enabling clear tracking of sources and changes.

DICOM Network Protocol

To this point, we've primarily focused on the file and header structure of the DICOM standard. In the remainder of this article, we'll look at the second major component of the standard, DICOM as a network protocol.

The DICOM protocol is an early example of a web service that allows for devices to:

Test the connection between two systems (C-Echo)
Send images from the local imaging device to a remote device (C-Store)
Search the content of a remote device (C-Find)
Retrieve images from a remote device (C-Move / C-Get)

DICOM connections work across networks using TCP/IP. Systems are identified using network settings such as their IP address (or alternatively the DNS hostname), the port on which the DICOM process is running, and a symbolic name called an application entity title (AET) which identifies the machine. These parameters allow for modalities within a network to locate, connect to, and transfer data. Authentication is achieved by identifying the originating source of a request and checking the provided AET against a list of rules which control access to the system.

The lifecycle of a DICOM request/answer follows a general pattern:

a client, called a service class user (SCU), will initialize a connection
a server, called a service class provider (SCP), will accept the inbound request (command) for processing
the command is sent as an encoded DICOM file
the server will generate an answer to the will include the response and any requested resources

The client of a DICOM service (which might be an imaging workstation or machine learning program) is called a service class user (SCU) and the server is called a service class provider (SCP). Clients send the server a request (which is called a command) and receive answers which contain DICOM files.

A connection established between two DICOM systems is called an association. They begin with a handshake that negotiates the types of commands that can be executed and determines which transfer syntaxes are supported. The result of the negotiation is called a presentation context.

DICOM Network Operations

Most DICOM systems implement the logic needed to act as either client (SCU) or server (SCP). The most common network operations used by DICOM are C-Echo, C-Store, C-Find, and C-Move which allow them to test connectivity, query available data and retrieve imaging series.

C-Echo

C-Echo is used to test the connectivity between two servers. The DICOM Echo service is triggered when the client sends a C-Echo command to the server as its query. The server answers with an empty DICOM.

C-Store

The DICOM Store service is used to send DICOM instances to a remote imaging device. Orthanc implements the logic needed to work both as a client, allowing either device to send or receive DICOM files. Used in conjunction with a C-Find command, Orthanc can be used as a relay server to query files from one modality and queue them to transfer to a second.

C-Find

The C-Find service is used to search a list of DICOM resources that are hosted by a DICOM server. The service is activated when the client queries the C-Find command along with the resource being searched and filters. The server will then respond with an answer that includes a list of the resources that match the query.

C-Move

The DICOM Move service is used to retrieve DICOM files from a remote server. It is typically used alongside C-Find to retrieve queries. The service is activated with C-Find and C-Move together, making it the core exchange mechanism of DICOM files within the institution.

A typical C-Move command involves 3 AETs: the issuer, source, and target:

the issuer issues the command
the source queries the contents
the target receives the contents

It's important to note that an issuer and target do not have to be the same imaging device.

C-Get

C-Get is a simpler alternative to C-Move where the issuer and the target are the same devices.

Network and Security Considerations

DICOM was designed to work in a network context where all of the modalities appear as peers within the same network. In complex networking environments, there can be connectivity issues as systems attempt to negotiate their handshakes.

Routers might block the DICOM protocol between separate subnets. For secure environments, it is common for only the HTTP (80), HTTPS (443), and SSH (22) protocols to be enabled by default.
Firewalls installed on clients or servers might block the transfer port. This is especially true for Microsft Windows firewall and RedHat-based GNU/Linux boxes.
There are duplicate AETs within the DICOM network. Because AETs need to uniquely identify systems and match the IP address and port with which they are associated, mismatches can cause connection issues when modalities are trying to negotiate their association.

Note: After changes to infrastructure that affect the DICOM networking topology, it is important to ensure that modalities are still able to connect to the systems in their modality list using a C-Echo command.

Security

Because the DICOM protocol was designed to target a single institution's Intranet, not the internet or the cloud, additional work is needed to ensure that connections remain secure. To achieve this, encryption should be applied to any connections that might leave the DICOM network firewall. Orthanc supports TLS encryption that can be applied directly to DICOM connections while a second option is to tunnel DICOM connections through a VPN tunnel.

Alternative Protocols

Given the security and connectivity issues of DICOM, it may be necessary to use alternative protocols to insure connections and transfers are robust and secure. Orthanc provides two alternative interfaces (both of which work over HTTP) and can safely be used to transfer data over the Internet or to the cloud:

The Orthanc REST API and peer system. It is possible to configure multiple instances of Orthanc to work in concert as "peers." When configured in this way, systems are able to query their peers, push, and pull DICOM data. Peer operations are triggered by the REST API.
DICOMweb. DICOMweb is an implementation of the DICOM protocol that works over HTTP. It is broadly supported by DICOM viewer tools such as OHIF. Orthanc includes a DICOMweb plugin that allows for querying resources, retrieving images, and retrieving related data (such as annotations such as segmentation).

DICOM was designed to work in a world where modalities are peers within the same network. New versions of the standard advocate alternative protocols to help improve the security and reliability of data connections.