DICOM
DICOM, an acronym for Digital Imaging and Communications in Medicine, is the international standard for handling, storing, printing, and transmitting information in medical imaging. It enables the secure exchange of medical images and related data across devices, networks, and systems from different manufacturers, supporting a wide range of modalities such as X-ray, CT, MRI, ultrasound, and nuclear medicine.[1][2] Developed through collaboration between the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), DICOM originated in the early 1980s to address interoperability challenges in decoding CT and MRI images from various vendors. The first version, known as ACR-NEMA 300, was released in 1985 for point-to-point image communication, evolving through subsequent updates in 1988 and 1990 before being formalized as the DICOM standard in 1993, incorporating TCP/IP networking and published as NEMA PS3.[3][1] At its core, DICOM organizes data into structured sets containing attributes like patient identifiers, study details, and pixel data for images, which can be compressed using methods such as JPEG, JPEG 2000, or RLE to optimize storage and transmission. It defines key services including Store for sending images to picture archiving and communication systems (PACS), Query/Retrieve for searching and fetching data, Modality Worklist for integrating exam scheduling, and Print for outputting to DICOM-compatible printers, ensuring consistent workflows in healthcare environments.[4][5] Since its inception, DICOM has revolutionized radiology by replacing film-based workflows with fully digital processes, expanding to include support for radiation therapy, endoscopy, structured reporting, and web-based services like DICOMweb introduced in 2013 for RESTful access to imaging data. Managed by the DICOM Standards Committee—a global body of professional societies, manufacturers, and organizations—the standard is continuously updated, with multiple editions released annually to incorporate advancements in medical imaging technology.[3][1][6]Introduction
Definition and Purpose
DICOM, which stands for Digital Imaging and Communications in Medicine, is the international standard for handling medical images and related information.[1] It establishes protocols for the communication, storage, retrieval, printing, processing, and display of medical imaging data, ensuring that these operations maintain the quality and integrity required for clinical use.[2] Developed and maintained by the DICOM Standards Committee under the National Electrical Manufacturers Association (NEMA), the standard addresses the need for consistent data exchange in the field of medical informatics.[5] The primary purpose of DICOM is to promote vendor-neutral interoperability among healthcare imaging systems, allowing devices and software from different manufacturers to communicate seamlessly without proprietary barriers.[5] By defining standardized formats, syntax, and semantics for network and media-based exchanges, DICOM facilitates the integration of diverse equipment, such as scanners, workstations, and picture archiving and communication systems (PACS), across various medical specialties including radiology, cardiology, and radiotherapy.[1] This interoperability is critical in multi-vendor environments, where it supports the efficient sharing of patient data to improve diagnostic accuracy and workflow efficiency in healthcare settings worldwide.[7]Scope and Adoption
The DICOM standard encompasses a broad scope beyond mere image storage, facilitating the communication, management, and interchange of diverse medical data types including images, reports, measurements, waveforms, and structured reporting documents. These elements are encoded as composite service-object pair (SOP) instances, enabling precise linkage of textual annotations, quantitative measurements, and multimodal data to specific images or waveforms for enhanced clinical documentation and analysis. Additionally, DICOM supports both network-based communication through defined protocols for device interoperability and media storage via standardized file formats and application profiles for removable media interchange.[8][5] DICOM has achieved extensive global adoption as the de facto international standard for medical imaging, utilized in the vast majority of modern healthcare facilities and devices worldwide to ensure seamless data exchange across heterogeneous systems.[9] The standard is recognized by regulatory bodies, including the U.S. Food and Drug Administration (FDA) as a consensus standard for medical imaging communication and management, which streamlines premarket reviews for compliant devices.[10] Over its evolution, DICOM has expanded from an imaging-centric protocol to support multimodal data integration, incorporating advancements such as AI and machine learning annotations in recent editions through dedicated working groups and supplements. For instance, AI-generated outputs are handled as secondary capture objects with specific DICOM tags (e.g., Image Type indicating derived nature) and unique identifiers, allowing integration of algorithmic annotations without overwriting original data, as outlined by DICOM Working Group 23 on Artificial Intelligence. This progression facilitates the inclusion of non-image data like predictive models and structured reports alongside traditional modalities, promoting comprehensive enterprise imaging ecosystems, with the 2025 edition continuing to incorporate such advancements.[11][6] DICOM profoundly influences key healthcare information systems, serving as the foundational protocol for interoperability in Picture Archiving and Communication Systems (PACS), Radiology Information Systems (RIS), and Vendor Neutral Archives (VNAs). In PACS, it enables secure storage, retrieval, and distribution of imaging data, reducing silos and supporting clinical workflows; RIS integration via DICOM modalities worklist streamlines patient scheduling and reporting; while VNAs leverage DICOM for vendor-agnostic long-term archiving of both DICOM and non-DICOM content, yielding benefits such as 10-30% cost reductions in storage and improved disaster recovery.[12][13]Historical Development
Origins and Early Standards
In the late 1970s and early 1980s, the medical imaging field underwent a significant transition from traditional film-based systems to digital technologies, including the advent of computed tomography (CT) in 1971 and magnetic resonance imaging (MRI) in 1977, which generated vast amounts of digital data but relied on proprietary formats and interfaces from various equipment manufacturers.[14] This proliferation of vendor-specific systems hindered interoperability, making it challenging for hospitals to integrate devices from different suppliers into cohesive workflows, such as picture archiving and communication systems (PACS).[15] To address these issues, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee in 1983, tasked with developing a standard to promote device-independent communication of digital image information, facilitate PACS expansion, and enable the creation of enterprise-wide diagnostic databases.[15] The committee's first effort resulted in ACR-NEMA Standards Publication No. 300-1985, designated as version 1.0 and released in 1985, which defined a hardware interface for point-to-point connections between imaging devices, specifying data formats for basic image transfer but limited to simple, direct cabling without network support.[15] This version included revisions in 1986 and 1988 to refine command structures and data elements. In 1988, version 2.0 (ACR-NEMA Standards Publication No. 300-1988) was published, incorporating version 1.0 with enhancements such as support for image display functions, a more flexible data dictionary, and an object-oriented hierarchy for grouping related images, while still focusing on point-to-point rather than networked communication.[15] These early standards laid the groundwork for interoperability but faced adoption challenges due to their complexity and the absence of mandatory conformance testing, leading to inconsistent implementations across vendors that often failed to achieve seamless integration.[9] By the early 1990s, the limitations of ACR-NEMA versions 1.0 and 2.0—particularly their lack of support for modern networking protocols like TCP/IP and broader service classes—prompted a major overhaul. In 1993, the committee introduced the Digital Imaging and Communications in Medicine (DICOM) standard as version 3.0, rebranding the effort to reflect its expanded scope beyond ACR-NEMA's origins while maintaining backward compatibility where possible.[15] This version shifted toward a service-oriented architecture, enabling network-based exchanges and offline media storage, which addressed early interoperability gaps by defining stricter conformance requirements, though initial vendor adoption remained uneven due to the standard's increased sophistication.[9]Key Milestones and Versions
The DICOM standard was formally introduced in 1993 as version 3.0, marking a significant evolution from its ACR-NEMA predecessors by adopting an object-oriented model for information representation, defining standardized service classes for operations like storage and query/retrieve, and requiring conformance statements to ensure interoperability among implementations.[15] This version also shifted to a multi-part structure (PS3 parts), encompassing specifications for information objects, protocols, and media storage, which facilitated broader adoption in networked and offline environments using TCP/IP and formats like CD-R.[15] Subsequent supplements expanded the standard's scope in the late 1990s and 2000s, with the PS3 parts providing a modular framework for ongoing enhancements. Key additions included support for mammography through Supplement 50 in 2001, which introduced structured reporting for computer-aided detection results in mammograms.[16] Structured reporting was initially defined in Supplement 23 in 1999, enabling the encoding of clinical observations and measurements in a hierarchical, machine-readable format to improve report precision and integration with images.[17] Further refinements to structured reporting templates occurred in the early 2000s, such as those in Supplement 53 for content mapping resources.[18] Building on Supplement 148's 2011 SOAP-based web services, 2013 supplements including 161 (WADO-RS) and 163 (STOW-RS) introduced DICOMweb's RESTful services for web-based access to imaging data, enabling retrieval and storage via REST APIs.[3][19] Recent milestones include the 2025 editions (2025a through 2025d), which incorporate new information object definitions (IODs) and templates to address emerging clinical needs. These updates feature enhanced segmentation IODs for AI-generated outputs, such as label maps for entity classification in medical images.[20] Specific additions cover fetal ultrasound through structured reporting templates for anatomy surveys and biometry, dermoscopy with a dedicated IOD and storage SOP class for skin lesion imaging, and inventory management via Supplement 223's repository query and Inventory IOD for tracking DICOM instances in archives.[21][20][22] Internationally, the DICOM standard achieved harmonization as ISO 12052 in 2006, adopting the full specification including workflow and data management to promote global interoperability in health informatics.[23] Maintenance remains under the ongoing responsibility of the NEMA DICOM Standards Committee, which issues annual editions and supplements through a continuous development process.[24]Core Technical Framework
Information Object Definitions
In the DICOM standard, an Information Object Definition (IOD) provides an abstract specification of the structure and semantics of a set of attributes that collectively describe a real-world entity relevant to medical imaging and related workflows, such as a patient, study, or image.[25] These IODs form the foundation of the DICOM data model, enabling the consistent representation and exchange of medical data across systems by defining what information must or may be included for each entity.[25] DICOM distinguishes between two types of IODs: composite and normalized. A composite IOD includes attributes drawn from one or more related Service-Object Pair (SOP) Instances, representing a complete set of information about interconnected real-world objects, such as a full imaging study that links patient details with multiple images.[26] In contrast, a normalized IOD contains only attributes inherent to a single SOP Instance, focusing on a discrete entity without referencing external related objects, such as a standalone key object selection.[26] This distinction supports different use cases, with composite IODs typically used for storage and retrieval of persistent data, while normalized IODs facilitate query and management operations on individual entities.[27] The structure of an IOD is organized hierarchically through modules and attributes, mirroring the DICOM information model that progresses from the patient level to study, series, and instance. At the highest level, the Patient entity encompasses attributes like patient identification and demographics; a Study groups related examinations under that patient; a Series organizes images or reports from a specific procedure within the study; and an Instance represents the atomic unit, such as a single image or report document.[28] Modules are logical groupings of related attributes within an IOD—for instance, the Patient Module includes mandatory attributes like Patient Name and Patient ID—allowing for modular extension and reuse across different IODs while ensuring semantic consistency.[25] Attributes are the basic building blocks, each defined with a tag, value representation, and multiplicity to specify their role in describing entity properties.[25] SOP Classes extend IODs by pairing them with specific operations from DICOM service classes, creating Service-Object Pairs that define the allowable actions on an object, such as storing or querying. For example, the CT Image Storage SOP Class combines the CT Image IOD with the Storage Service Class to enable the transfer and persistence of computed tomography images.[29] This pairing ensures that implementations negotiate supported SOP Classes during association, guaranteeing interoperability for targeted workflows. Representative examples illustrate the application of IODs. The Image IOD, a composite type, structures pixel data through modules like the Image Pixel Module, which defines attributes for samples per pixel, photometric interpretation, and rows/columns, alongside the General Image Module for instance numbering and orientation.[30] This allows representation of entities like ultrasound or MRI images as self-contained instances within a series. In comparison, the Structured Report (SR) IOD, also composite, organizes text and measurements hierarchically using a content tree with modules such as the SR Document General Module and Content Sequence, where value types like TEXT for narrative descriptions and CODE for quantitative measurements (e.g., lesion size) are employed to encode clinical findings without pixel data.[31] These examples highlight how IODs adapt to diverse data types while maintaining the hierarchical model for comprehensive entity description.[31]Value Representations and Data Types
In DICOM, the Value Representation (VR) defines the data type and format for the Value field of each Data Element within a Data Set.[32] Each Data Element consists of four components: a Tag (a unique identifier formed by a 16-bit Group Number followed by a 16-bit Element Number), the VR (two single-byte characters in explicit VR encoding, or implicit based on the Tag), a Length field (specifying the byte length of the Value, encoded as 16-bit or 32-bit unsigned integer depending on the VR and encoding type), and the Value field itself (an even number of bytes, padded as necessary to achieve even length).[33] The VR ensures consistent interpretation of attribute values across systems, supporting the modular structure of Information Object Definitions (IODs) where attributes are grouped into modules.[32] DICOM employs specific encoding rules to maintain interoperability, particularly for length, padding, and character sets. Data Elements may have fixed or variable lengths depending on the VR: fixed-length VRs (e.g., US, SS, FL, FD) require exact byte counts without padding beyond the specified size, while variable-length VRs (e.g., AE, CS, LO) allow up to a maximum byte count and are padded only if needed for even length.[34] Padding uses the SPACE character (20H, or 02/00 in ISO 646) for most character string VRs, a single NULL byte (00H) for UI and OB VRs, and is prohibited for certain binary VRs like OW unless specified by the Transfer Syntax.[34] Character sets follow ISO/IEC 2022 standards, with the default being ISO-IR 6 (ISO 646 Basic G0 Set); extended sets (e.g., ISO/IEC 8859, UTF-8, GB 18030) are invoked via the Specific Character Set attribute (0008,0005) for applicable VRs like SH, LO, PN, ST, LT, UC, UT, enabling multi-byte support while preserving backward compatibility.[34] Multi-valued strings use the backslash (, 05/12) as a delimiter, and control characters like CR (00/13) and LF (00/10) represent line breaks in text VRs.[34] DICOM defines 34 primary Value Representations, categorized into strings, numerics, binary data, and composites, each with precise rules for format, multiplicity (single or multiple values), and maximum length.[32] The following table summarizes these VRs, their descriptions, and key constraints:| VR | Name | Description | Max Length | Padding/Notes |
|---|---|---|---|---|
| AE | Application Entity | Title of an application entity; no leading/trailing spaces significant | 16 bytes | SPACE; even length |
| AS | Age String | Age in format nnnD/W/M/Y (e.g., 018M for 18 months) | 4 bytes fixed | SPACE; fixed length |
| AT | Attribute Tag | Tag value as two 16-bit unsigned integers (e.g., (0018,00FF)) | 4 bytes fixed | No padding; fixed length |
| CS | Code String | Coded term from controlled terminology; leading spaces insignificant | 16 bytes | SPACE; even length |
| DA | Date | Date in YYYYMMDD format (e.g., 19930822) | 8 bytes fixed | SPACE; fixed length |
| DS | Decimal String | Decimal number as string; fixed- or floating-point | 16 bytes | SPACE; even length |
| DT | Date Time | Date/time in YYYYMMDDHHMMSS.FFFFFF&ZZXX format | 26 bytes | SPACE; even length |
| FL | Floating Point Single | IEEE 754 single-precision floating point | 4 bytes fixed | No padding; fixed length |
| FD | Floating Point Double | IEEE 754 double-precision floating point | 8 bytes fixed | No padding; fixed length |
| IS | Integer String | Integer as string | 12 bytes | SPACE; even length |
| LO | Long String | Long string of characters | 64 bytes | SPACE; even length |
| LT | Long Text | Long unstructured text | 10240 bytes | SPACE; even length |
| OB | Other Byte String | Octet-stream (e.g., pixel data); length per Transfer Syntax | Undefined/2^32-1 | NULL (00H); even length |
| OD | Other Double | Stream of IEEE 754 double-precision values | 2^32-8 bytes | No padding; even length |
| OF | Other Float | Stream of IEEE 754 single-precision values | 2^32-4 bytes | No padding; even length |
| OL | Other Long | Stream of 32-bit words | Undefined | No padding; even length |
| OV | Other 64-bit Very Long | Stream of 64-bit words | Undefined | No padding; even length |
| OW | Other Word String | Stream of 16-bit words (e.g., audio data) | Undefined | No padding; even length |
| PN | Person Name | Structured name with up to 5 components (e.g., family^given) | 64 bytes/component | SPACE; even length |
| SH | Short String | Short string of characters | 16 bytes | SPACE; even length |
| SL | Signed Long | 32-bit signed integer | 4 bytes fixed | No padding; fixed length, little-endian |
| SQ | Sequence of Items | Nested sequence of Data Elements; delimited if undefined length | Undefined | No padding; uses SQ Delimitation Item |
| SS | Signed Short | 16-bit signed integer | 2 bytes fixed | No padding; fixed length, little-endian |
| ST | Short Text | Short unstructured text | 1024 bytes | SPACE; even length |
| SV | Signed 64-bit Very Long | 64-bit signed integer | 8 bytes fixed | No padding; fixed length, little-endian |
| TM | Time | Time in HHMMSS.FFFFFF format (e.g., 070907.0705) | 14 bytes | SPACE; even length |
| UC | Unlimited Characters | Unlimited-length character string | 2^32-2 bytes | SPACE; even length |
| UI | Unique Identifier | Globally unique ID as dotted numeric string (e.g., 1.2.840.10008.1.2) | 64 bytes | NULL (00H); even length |
| UL | Unsigned Long | 32-bit unsigned integer | 4 bytes fixed | No padding; fixed length, little-endian |
| UN | Unknown | Unspecified octet-stream; used for unknown VR or long values | Undefined | No padding; even length |
| UR | Universal Resource Identifier | URI or URL string | 2^32-2 bytes | SPACE; even length |
| US | Unsigned Short | 16-bit unsigned integer | 2 bytes fixed | No padding; fixed length, little-endian |
| UT | Unlimited Text | Unlimited-length text | 2^32-2 bytes | SPACE; even length |
| UV | Unsigned 64-bit Very Long | 64-bit unsigned integer | 8 bytes fixed | No padding; fixed length, little-endian |