Glossary

DICOM UID

A globally unique identifier registered with an ISO 8824 object identifier tree that is used to definitively reference a specific SOP Instance, Study, or other DICOM entity.

Get in touch Learn more

Strategy consultant facilitating AI use case discovery workshop, sticky notes on glass wall, casual corporate meeting.

UNIQUE IDENTIFIER

What is DICOM UID?

A DICOM UID is a globally unique, permanent identifier used to definitively reference a specific entity, such as a medical image, study, or information object class, within the DICOM standard ecosystem.

A DICOM UID (Unique Identifier) is a string of numbers and periods registered according to the ISO 8824 standard to guarantee global uniqueness across all vendors, modalities, and institutions. It is the primary key for every DICOM object, ensuring that a specific SOP Instance, Study, or Series can never be confused with another, even when data is exchanged between disparate healthcare systems.

UIDs are constructed from a registered root, typically 1.2.840.10008 for the DICOM standard itself, followed by a suffix that identifies the specific entity type, such as a Transfer Syntax or a SOP Class. A critical operational rule is that a UID must never be reused; once assigned to an image instance, it is permanently bound to that data, forming the backbone of reliable medical record integrity and DICOM network retrieval.

UNIQUE IDENTIFIER ANATOMY

Key Characteristics of a DICOM UID

A DICOM UID is a globally unique, persistent identifier used to definitively reference every entity within the DICOM standard, from study instances to transfer syntaxes. Its structure is governed by ISO 8824 to guarantee universal interoperability.

Global Uniqueness via Registration

A DICOM UID guarantees global uniqueness by adhering to the ISO 8824 Object Identifier (OID) tree. Organizations must register for a unique root, typically an ISO 1.2.840.10008 prefix for DICOM-defined entities or a privately assigned branch from a national standards body. This prevents any two entities in the world from ever having the same identifier, which is critical for merging data across different healthcare systems.

ISO 8824

Governing Standard

Strict Hierarchical Structure

UIDs are constructed as a series of numeric components separated by periods, forming a hierarchical tree. Each component must be a non-negative integer, and the path defines a unique node. For example, the UID for a CT Image Storage SOP Class is 1.2.840.10008.5.1.4.1.1.2. The structure is machine-parseable, allowing systems to validate the organizational origin and entity type by analyzing the prefix.

EXPLORE

Immutable and Persistent

Once assigned to a specific SOP Instance, Study, or Series, a DICOM UID must remain permanently immutable. It serves as the definitive key for referencing that entity throughout its entire lifecycle. If a study is copied or an image is derived, a brand new UID must be generated. This persistence is essential for maintaining data integrity in long-term archives and legal medical records.

UID Encoding Rules

The DICOM standard defines a specific Value Representation (VR) of 'UI' for UIDs. The encoding rules are strict:

Maximum length: 64 characters total.
Allowed characters: Only digits 0-9 and the period (.) separator.
Trailing padding: If a UID is shorter than its field, it must be padded with a single NULL character (0x00), not spaces.
Leading zeros: Each numeric component must be treated as an integer, meaning 1.2.3 and 01.02.03 are semantically identical.

Private vs. Standard UIDs

UIDs are categorized by their root to distinguish their origin:

DICOM-Defined UIDs: Reserved for standard entities like SOP Classes and Transfer Syntaxes, always starting with the root 1.2.840.10008.
Privately-Defined UIDs: Generated by vendors for instances like patient images. These must use a registered private root, such as an organization's assigned OID branch. Using an unregistered or fabricated root risks catastrophic collision when data is exchanged.

UID as a Referential Key

UIDs are the relational glue of the DICOM information model. A DICOM image does not contain patient data in isolation; it references other entities via UIDs:

Study Instance UID (0020,000D): Groups all series belonging to a single exam.
Series Instance UID (0020,000E): Groups images acquired in a single scan sequence.
SOP Instance UID (0008,0018): Uniquely identifies the individual image or report object. This referential integrity allows a PACS to reconstruct a complete study from its component parts.

DICOM UID ESSENTIALS

Frequently Asked Questions

A DICOM UID is the backbone of medical imaging interoperability, ensuring every image, study, and report is uniquely identifiable across the global healthcare ecosystem. The following answers address the most critical technical questions engineers face when implementing UID generation and parsing.

A DICOM UID (Unique Identifier) is a globally unique, character-based identifier registered under the ISO 8824 Object Identifier (OID) tree that definitively references a specific DICOM entity, such as a Study, Series, or SOP Instance. The structure is a hierarchical string of numeric components separated by periods, with a maximum length of 64 characters. Every UID must begin with a registered root, typically 1.2.840.10008 for the official DICOM standard, followed by an organization-specific suffix. For example, a vendor's root might be 1.2.840.113619 (Apple Inc.), appended with a unique instance number. The UID encoding rules strictly limit the character set to the digits 0-9 and the period separator, ensuring no ambiguity in network transmission or file storage.

IDENTIFIER COMPARISON

DICOM UID vs. Other Medical Identifiers

Comparison of DICOM UIDs against other common medical identifier standards used in healthcare interoperability.

Feature	DICOM UID	HL7 OID	FHIR Logical ID
Registration Authority	ISO 8824 Object Identifier Tree	ISO/ITU-T Joint Registration	Server-Specific (No Global Authority)
Uniqueness Scope	Global	Global	Local to FHIR Server
Primary Use Case	DICOM SOP Instances, Studies, Series	HL7 v2/v3 Objects, Organizations	FHIR Resource Instances
Format	Numeric String (e.g., 1.2.840.10008.5.1.4.1.1.2)	Dotted Numeric String (e.g., 2.16.840.1.113883.6.1)	Any Valid String (e.g., "example-patient-1")
Length Limit	64 Characters	64 Characters	64 Characters
Human Readable
Required for DICOM Interoperability
Supports Hierarchical Delegation

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 UID ECOSYSTEM

Related Terms

A DICOM UID is a globally unique identifier that definitively references a specific SOP Instance, Study, or other DICOM entity. Master the related concepts that govern how these identifiers are structured, registered, and used in clinical workflows.

UID Registration Authority

The organizational body responsible for assigning a unique root to an organization, ensuring global uniqueness. Vendors and hospitals must obtain a registered root from an authority like ANSI or the ISO 8824 tree to generate their own UIDs. Without a registered root, generated UIDs risk collision, breaking the fundamental DICOM interoperability contract. The root forms the prefix of all UIDs an organization creates.

ISO 8824

Governing Standard

1.2.840.10008

DICOM Root UID

SOP Instance UID

The most granular UID, uniquely tagging a single Service-Object Pair (SOP) Instance—a specific CT slice, a structured report, or a segmentation object. This is the primary key for every image in a PACS. Key characteristics:

Uniqueness: Must never be reused, even across different patients or institutions.
Persistence: Must remain constant for the lifetime of the object.
Generation: Typically derived by combining the organization's root with a timestamp and a random component.

EXPLORE

Study Instance UID

A UID that groups all SOP Instances acquired during a single requested procedure for a patient. It is the critical identifier for querying and retrieving an entire radiological exam. All images, structured reports, and presentation states from one scan session share the same Study Instance UID. This hierarchical grouping is essential for Query/Retrieve operations at the STUDY level.

Transfer Syntax UID

A UID that identifies the encoding rules used to serialize a DICOM data set into a byte stream. It specifies:

Byte Ordering: Little Endian or Big Endian.
Compression: Whether pixel data is encapsulated using lossless (e.g., JPEG-LS) or lossy (e.g., JPEG 2000) compression.
Explicit vs. Implicit VR: Whether Value Representation is included in the data stream. Negotiating a mutually supported Transfer Syntax UID is the core of the Association Negotiation handshake.

SOP Class UID

A UID that defines the fundamental unit of DICOM interoperability. It is the union of an Information Object Definition (IOD) and a DIMSE Service Group. For example, the SOP Class UID 1.2.840.10008.5.1.4.1.1.2 defines a CT Image Storage operation. When an SCU and SCP negotiate, they exchange lists of SOP Class UIDs to declare their capabilities, ensuring both sides understand the data and the operation to be performed.

UID Collision Prevention

A catastrophic interoperability failure where two distinct DICOM objects share the same UID, causing data corruption or loss in a PACS. Prevention strategies include:

Registered Root: Always use an officially assigned organizational root.
High-Resolution Timestamps: Incorporate millisecond or microsecond precision.
Cryptographic Randomness: Append a strong random number to the suffix.
UID Validation: Implement strict checks in acquisition software to reject duplicate generation.

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.