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.
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 (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.
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.
DICOM: 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.
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.
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.
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).
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.
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.
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:
PatientID (0x0010, 0x0020)
StudyInstanceUID (0x0020, 0x000d)
SeriesInstanceUID (0x0020, 0x000e)
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 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.
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 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.
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.
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.
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).