DICOM

DICOM (Digital Imaging and Communications in Medicine) is the international standard for medical images and related information. Maintained by the DICOM Standards Committee under NEMA (National Electrical Manufacturers Association), DICOM defines the formats for medical images that can be exchanged between imaging equipment, PACS, workstations, and other medical devices. The standard is published as PS3.1 through PS3.22, with each part covering a specific aspect of the standard.

Information Object Definitions (IODs)

DICOM Information Object Definitions (PS3.3) specify the attributes and structure of real-world objects relevant to medical imaging. An IOD is an abstract data model that defines the information attributes of a class of real-world objects. IODs are organized into Information Modules, which group related attributes. Composite IODs (like CT Image) include patient, study, series, and image-level information. Normalized IODs represent a single entity (like a Print Job or Worklist item).

Patient Module

Patient name, ID, birth date, sex. Present in all composite IODs.

General Study Module

Study instance UID, study date/time, referring physician, accession number.

General Series Module

Series instance UID, modality, series date/time, body part examined.

General Image Module

Instance number, patient orientation, image type, acquisition date/time.

Image Pixel Module

Rows, columns, bits allocated, bits stored, pixel representation, pixel data.

Frame of Reference Module

Frame of reference UID, position reference indicator for spatial registration.

DICOM Services (DIMSE)

DICOM Message Service Elements (DIMSE, PS3.7) define the operations available between DICOM Application Entities. DIMSE-C services operate on composite SOP Instances (images, documents), while DIMSE-N services operate on normalized SOP Instances (management objects). Services are provided by a Service Class Provider (SCP) and consumed by a Service Class User (SCU).

ServiceTypeDirectionDescription
C-STOREDIMSE-CSCU -> SCPStore a composite SOP Instance (image, document) on a remote Application Entity. The fundamental operation for sending images from modality to PACS.
C-FINDDIMSE-CSCU -> SCPQuery for SOP Instances matching specified attributes at Study, Series, or Instance level (Query/Retrieve Information Model).
C-MOVEDIMSE-CSCU -> SCPRequest that the SCP transfer matching SOP Instances to a specified destination AE via C-STORE sub-operations.
C-GETDIMSE-CSCU -> SCPRequest that the SCP transfer matching SOP Instances back to the requesting SCU on the same association via C-STORE sub-operations.
C-ECHODIMSE-CSCU -> SCPVerify end-to-end connectivity between two DICOM Application Entities (DICOM ping).
N-CREATEDIMSE-NSCU -> SCPCreate a new managed SOP Instance (used in Print Management, Modality Worklist).
N-SETDIMSE-NSCU -> SCPModify attributes of a managed SOP Instance.
N-GETDIMSE-NSCU -> SCPRetrieve attribute values from a managed SOP Instance.
N-EVENT-REPORTDIMSE-NSCP -> SCUReport an event related to a managed SOP Instance to the peer.

Common SOP Classes

A Service-Object Pair (SOP) Class pairs an IOD with the DIMSE services applicable to it. Each SOP Class is identified by a unique UID. The following table lists commonly used Storage SOP Classes.

SOP Class NameModalitySOP Class UID
CT Image StorageCT1.2.840.10008.5.1.4.1.1.2
MR Image StorageMR1.2.840.10008.5.1.4.1.1.4
CR Image StorageCR1.2.840.10008.5.1.4.1.1.1
US Image StorageUS1.2.840.10008.5.1.4.1.1.6.1
DX Image StorageDX1.2.840.10008.5.1.4.1.1.1.1
NM Image StorageNM1.2.840.10008.5.1.4.1.1.20
SC Image StorageSC1.2.840.10008.5.1.4.1.1.7
RT Structure SetRTSTRUCT1.2.840.10008.5.1.4.1.1.481.3
Encapsulated PDFDOC1.2.840.10008.5.1.4.1.1.104.1
Structured ReportSR1.2.840.10008.5.1.4.1.1.88.33

DICOM Networking

DICOM networking (PS3.8) uses TCP/IP with an upper layer protocol that manages Associations between Application Entities (AEs). Before exchanging DIMSE messages, two AEs must negotiate an Association, agreeing on which SOP Classes and Transfer Syntaxes will be used. Key networking concepts:

  • Application Entity (AE) -- A DICOM endpoint identified by an AE Title (up to 16 characters), hostname, and port number
  • Association Negotiation -- A-ASSOCIATE request/response exchange that establishes supported Presentation Contexts (SOP Class + Transfer Syntax combinations)
  • Transfer Syntax -- Defines encoding for data elements (e.g., Implicit VR Little Endian, Explicit VR Little Endian, JPEG Baseline, JPEG 2000)
  • Presentation Context -- A pairing of an Abstract Syntax (SOP Class UID) with one or more Transfer Syntaxes, negotiated during association
  • PDU (Protocol Data Unit) -- The transport-level data structure. Maximum PDU size is negotiated during association (commonly 16 KB to 64 KB)

Conformance Statements

PS3.2 defines the structure of DICOM Conformance Statements, which vendors must publish for their DICOM-compliant products. A conformance statement documents which SOP Classes a product supports as SCU and SCP, which Transfer Syntaxes are supported, networking configuration, and any implementation-specific behavior. Conformance statements are critical for integration planning -- they allow site administrators to determine whether two DICOM systems can communicate before attempting to connect them.

Key Sections in a Conformance Statement

  • Implementation model (AE roles, real-world activities)
  • AE specifications (supported SOP Classes, Transfer Syntaxes per SOP Class)
  • Communication profiles (TCP/IP settings, PDU sizes, timeouts)
  • Extensions and private SOP Classes or attributes
  • Configuration and deployment parameters
  • Support for character sets and internationalization

Official Specification

The authoritative DICOM standard is published by NEMA at dicomstandard.org. The standard is freely available and updated regularly through supplements and correction items approved by the DICOM Standards Committee. For implementation guidance, see the DICOM Cookbook maintained by the European Society of Radiology (ESR).