DICOM

DICOM structures data using Information Object Definitions (IODs) , which are abstract data models for real-world medical entities like patients, studies, and images. An IOD specifies the mandatory and optional attributes (data elements) that describe an object. For example, a CT Image IOD includes attributes for pixel data, slice thickness, and KVP. This object-oriented design ensures that data is self-describing and contextually complete, allowing any compliant system to interpret the content without external metadata.

Interoperability is achieved through DICOM Message Service Elements (DIMSE) , which define the commands and notifications that applications use to interact. These services are paired with IODs to form Service-Object Pair (SOP) Classes, the fundamental unit of DICOM conformance. Key operations include:

• C-STORE: Transfers images to a PACS archive.
• C-FIND: Queries a database for studies by patient name or ID.
• C-MOVE: Instructs an archive to send images to a third-party workstation.
• C-ECHO: A simple "ping" to verify network connectivity.

Every entity in the DICOM universe is assigned a globally unique identifier. UIDs are registered via the ISO 8824 standard to prevent conflicts between vendors and institutions. Critical UID types include:

• Study Instance UID: Uniquely identifies a single imaging exam.
• Series Instance UID: Identifies a specific acquisition sequence within a study.
• SOP Instance UID: Uniquely tags every single image or structured report object. This hierarchical identification system is the backbone of reliable data linking and retrieval across an enterprise.

DICOM defines a physical interchange model for offline media like CDs, DVDs, and USB drives. A DICOMDIR file acts as a table of contents, indexing all images on the media without requiring a network query. The media structure mandates a specific directory hierarchy and a DICOM Media Storage SOP Class to ensure that a disc created by one vendor's system can be read by any other. This standard was critical for patient image portability before ubiquitous network access.

Unlike a simple file specification, DICOM requires every compliant device to publish a DICOM Conformance Statement. This document is a detailed technical contract that explicitly lists which SOP Classes the device supports as a Service Class User (SCU) or Service Class Provider (SCP). An integration engineer uses these statements to determine if two systems can interoperate, checking for matching SOP Class UIDs and supported transfer syntaxes before any connection is attempted.

DICOM separates the semantic meaning of an image from its binary encoding. The Transfer Syntax defines how pixel data is compressed and byte-ordered for transmission. A single SOP Class can support multiple transfer syntaxes, negotiated during association establishment. Common examples include:

• Implicit VR Little Endian: The default, uncompressed format.
• JPEG Lossless: For mathematically reversible compression.
• JPEG 2000: For high-efficiency, scalable compression. This negotiation allows a PACS to store images losslessly while sending a compressed preview to a workstation.