Glossary

SOP Class

A DICOM SOP Class is the fundamental unit of interoperability, defined as the union of a specific Information Object Definition (IOD) and a DIMSE Service Group, such as a CT Image Storage SOP Class.

Get in touch Learn more

Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.

FUNDAMENTAL UNIT OF INTEROPERABILITY

What is a DICOM SOP Class?

A DICOM SOP Class is the atomic unit of DICOM interoperability, formally defined as the union of a specific Information Object Definition (IOD) and a DIMSE Service Group.

A DICOM SOP Class is the fundamental building block of DICOM interoperability, combining a specific Information Object Definition (IOD)—which models a real-world data object like a CT Image—with a DIMSE Service Group—which defines the operations that can be performed on it, such as Storage or Query/Retrieval. This pairing creates a standardized contract that ensures two devices from different vendors can successfully exchange and process a specific type of medical data.

For example, the CT Image Storage SOP Class uniquely defines how a CT scanner (acting as an SCU) sends a CT image dataset to a PACS archive (acting as an SCP). During Association Negotiation, devices exchange lists of supported SOP Class UIDs to establish a common language. This mechanism allows a workstation to query only for the studies it can display, making SOP Classes the critical mechanism for achieving plug-and-play integration in medical imaging networks.

DICOM INTEROPERABILITY FOUNDATION

Key Characteristics of an SOP Class

An SOP Class is the atomic unit of DICOM interoperability, formed by the precise union of an Information Object Definition (IOD) and a DIMSE Service Group. It defines both the data structure and the operations permitted on that data.

The IOD + Service Group Union

An SOP Class is formally defined as the combination of one IOD and one DIMSE Service Group. The IOD specifies the data attributes (e.g., Patient Name, Pixel Data), while the Service Group defines the allowed operations (e.g., Storage, Query/Retrieve).

Normalized SOP Classes pair a single data element with an operation
Composite SOP Classes pair a complete information model with an operation
Example: CT Image Storage SOP Class = CT Image IOD + Storage Service Group

Composite

Most Common Type

Unique Identification via SOP Class UID

Every SOP Class is assigned a globally unique identifier called the SOP Class UID. This UID is registered according to ISO 8824 standards and is the critical token exchanged during Association Negotiation.

The UID definitively identifies the exact version and type of the SOP Class
Example UID for CT Image Storage: 1.2.840.10008.5.1.4.1.1.2
No two different SOP Classes can share the same UID
UIDs are used in the DICOM File Meta Information header to identify the file's content

Service Class User (SCU) and Provider (SCP) Roles

Within an SOP Class, an Application Entity assumes one of two roles: SCU or SCP. The SCU initiates the operation, and the SCP performs it.

Storage SOP Class: The modality (CT scanner) is the SCU; the PACS archive is the SCP
Query/Retrieve SOP Class: The workstation is the SCU; the PACS server is the SCP
A single device can be an SCU for one SOP Class and an SCP for another
These roles are explicitly declared in the DICOM Conformance Statement

Normalized vs. Composite SOP Classes

DICOM defines two fundamental categories of SOP Classes with distinct architectural purposes.

Normalized SOP Classes: Operate on individual attributes of a remote entity. Used for system management (e.g., Detached Patient Management)
Composite SOP Classes: Operate on a complete, self-contained information object that includes patient, study, and equipment context. Used for image exchange (e.g., MR Image Storage)
Composite classes are overwhelmingly dominant in clinical workflows
The distinction affects how data is modeled and transmitted across the network

Association Negotiation and Abstract Syntax

During the Association Negotiation handshake, SOP Classes are presented as Abstract Syntaxes. Each proposed Abstract Syntax is paired with one or more Transfer Syntaxes to form a Presentation Context.

The SCU proposes a list of SOP Class UIDs it wants to use
The SCP accepts or rejects each proposed Abstract Syntax
A single association can support multiple SOP Classes simultaneously
This negotiation ensures both peers agree on the exact data structures and encoding rules before any data is exchanged

Specialized SOP Class Examples

Beyond basic Storage, DICOM defines specialized SOP Classes for advanced clinical and research applications.

DICOM Segmentation Object: Encodes binary or fractional segmentation maps as companion objects to source images
DICOM Structured Report: Encodes clinical observations as machine-readable, coded text instead of free-form dictation
DICOM Whole Slide Imaging: Handles gigapixel digital pathology images within standard PACS infrastructure
Secondary Capture: Handles images converted from non-DICOM formats, often lacking full acquisition context

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

DICOM INTEROPERABILITY

Frequently Asked Questions About SOP Classes

The SOP Class is the fundamental contract that guarantees interoperability in medical imaging. It defines exactly what data a device can store and what operations it can perform. Below are the most common questions integration engineers and software architects ask when designing DICOM-compliant systems.

A SOP Class (Service-Object Pair Class) is the fundamental unit of DICOM interoperability, defined as the unique union of an Information Object Definition (IOD) and a DIMSE Service Group. The IOD specifies the data attributes (e.g., pixel data, patient name, slice thickness for a CT image), while the Service Group defines the operations that can be performed on that data (e.g., Store, Find, Move). Each SOP Class is identified by a globally unique SOP Class UID, such as 1.2.840.10008.5.1.4.1.1.2 for CT Image Storage. During Association Negotiation, two Application Entities exchange lists of supported SOP Classes to establish a common operational contract. This mechanism ensures that a CT scanner from one vendor can reliably store images to a PACS archive from another vendor, because both have agreed on the exact structure and behavior defined by the CT Image Storage SOP Class.

INTEROPERABILITY FRAMEWORK

Related DICOM Concepts

The SOP Class is the fundamental contract for DICOM interoperability. These related concepts define how that contract is negotiated, encoded, and executed across a network.

Service-Object Pair (SOP) Architecture

An SOP Class is formally defined as the union of an Information Object Definition (IOD) and a DIMSE Service Group. The IOD specifies the data attributes (e.g., Patient Name, Pixel Data), while the Service Group defines the operations (e.g., Store, Find). This strict pairing ensures that a device cannot request an operation that is semantically meaningless for a given data type, such as querying the pixel data of a modality worklist entry.

Association Negotiation

Before any data exchange, two Application Entities must negotiate a common set of supported SOP Classes. The initiating SCU proposes a list of SOP Class UIDs and Transfer Syntaxes. The responding SCP accepts or rejects each pairing. This handshake establishes the precise operational contract for the session, preventing communication failures caused by unsupported functionality.

EXPLORE

Service Class User (SCU) vs. Provider (SCP)

DICOM assigns asymmetric roles based on the SOP Class. The SCU is the client that invokes an operation, while the SCP is the server that performs it. A single device can act as an SCU for one SOP Class and an SCP for another. For example, a PACS archive is an SCP for the CT Image Storage SOP Class but acts as an SCU when querying a Modality Worklist server.

Transfer Syntax Negotiation

During association, the SCU presents a list of acceptable Transfer Syntaxes for each proposed SOP Class. The SCP selects one, defining the byte ordering (Little/Big Endian) and compression (JPEG, JPEG 2000, etc.). This negotiation allows a CT scanner to send uncompressed data to a local PACS while simultaneously sending a compressed version to a long-term VNA, all using the same Storage SOP Class.

DICOM Conformance Statement

A mandatory document where a vendor explicitly lists every SOP Class their device supports and the role (SCU/SCP) it plays. Integration engineers rely on this statement to verify that two systems share a compatible SOP Class before attempting a network connection. A mismatch in the Conformance Statement is the primary cause of DICOM interoperability failures.

DICOMweb RESTful Equivalents

Modern web protocols map traditional DIMSE SOP Classes to RESTful services. The STOW-RS service replaces the C-STORE command for the Storage SOP Class, while WADO-RS replaces C-GET for retrieval. These HTTP-based equivalents use application/dicom+json media types, allowing standard web tools to interact with medical imaging data without implementing the legacy DICOM Upper Layer Protocol.

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.