DICOM

An IOD is an abstract data model that specifies the attributes required to describe a specific type of real-world medical image or object. It serves as the blueprint for data structure.

• Normalized IODs: Represent a single entity, like a patient or a visit.
• Composite IODs: Combine multiple entities into one object, such as a CT Image IOD, which includes patient, study, series, and pixel data attributes.
• Core Function: Defines exactly which DICOM Tags (e.g., Patient Name, Slice Thickness) are mandatory, optional, or conditional for a given SOP Class, ensuring a CT scanner from one vendor generates data a PACS from another can parse.

Service classes define the specific operations that can be performed on IODs, formalizing the roles of devices in a network transaction.

• Storage Service Class: Uses the C-STORE command to push images from a modality (SCU) to an archive (SCP).
• Query/Retrieve Service Class: Uses C-FIND to search a database and C-MOVE or C-GET to retrieve images based on hierarchical Query/Retrieve Levels (Patient, Study, Series, Image).
• Verification Service Class: Uses the C-ECHO command to test network connectivity and basic DICOM compliance between two Application Entities.

The Transfer Syntax defines the set of rules for serializing the abstract IOD data into a concrete byte stream for transmission or file storage. It is negotiated during Association Negotiation.

• Byte Ordering: Specifies Little Endian or Big Endian encoding for multi-byte data values.
• Compression: Supports lossless (e.g., JPEG-LS) and lossy (e.g., JPEG 2000) compression schemes to reduce storage and transmission bandwidth for large pixel data.
• Encapsulation: Defines how compressed pixel data is fragmented into frames within a DICOM data set, distinct from the native uncompressed format.

DICOM relies on a globally unique identification system based on the ISO 8824 standard to ensure no two objects or concepts are ever confused across the entire healthcare enterprise.

• SOP Instance UID: A unique identifier for every single image, report, or other DICOM object ever created, preventing duplicate records.
• Study Instance UID: Groups all images and objects belonging to a single diagnostic exam.
• Transfer Syntax UID: Unambiguously identifies the encoding rules used to compress and serialize the data, ensuring the receiver can correctly decode the byte stream.

The physical file format standardizes how DICOM data is stored on removable media or in a file system, ensuring portability beyond network transactions.

• File Meta Information: A mandatory header containing the File Preamble (128 bytes), the 'DICM' prefix, and critical elements like the Media Storage SOP Class UID and Transfer Syntax UID.
• Data Set: The body of the file, containing a sequential list of DICOM Data Elements, each with its Tag, Value Representation (VR), Value Length, and Value.
• Purpose: Allows a DICOM file to be self-describing, so any compliant reader can parse it without prior knowledge of its contents.

A modern extension to the standard (Part 18) that enables web-based access to medical images using HTTP protocols, replacing legacy DIMSE commands for cloud and web application environments.

• STOW-RS (Store Over the Web): Uses an HTTP POST with a multipart/related body to store DICOM instances.
• WADO-RS (Web Access to DICOM Objects): Uses an HTTP GET to retrieve individual instances, frames, or metadata in formats like application/dicom+json.
• QIDO-RS (Query Based on ID for DICOM Objects): Uses an HTTP GET with query parameters to search for studies, series, or instances, returning results as JSON.