Which identifiers hold the system together

A segmentation object wants to say “I belong to that CT series”. A PACS query wants to say “give me study X”. A viewer wants to know “are these two images in the same patient frame so I can overlay them?”. All three rely on a handful of UIDs. The identifiers are useful only when their roles are kept separate: one set follows objects through packaging and references, while another describes the patient coordinate frame in which spatial information is expressed.

A SEG can reference its source

When you segment a tumour on a CT and save it as a DICOM SEG, the object can carry references to the source images. ReferencedSeriesSequence lists Series that contain referenced source Instances; it is a source/reference relationship, not the Series to which the SEG itself belongs. Per-frame DerivationImageSequence and SourceImageSequence can identify source SOP Instances. Those Type 2 sequences may be empty, and Common Instance Reference is conditional when the Derivation Image functional group is present. A populated reference therefore improves traceability, but neither its presence nor its absence alone proves identical sampling, extent, or voxel-grid alignment. The DICOM Segmentation IOD, Common Instance Reference Module, and Derivation Image Macro define these conditional relationships.

Two different kinds of identity

The subtlety that causes mistakes is that DICOM has two separate identity questions, and they use different UIDs. The first asks which concrete objects are being grouped or referenced. The second asks which patient coordinate frame their spatial descriptions claim to use. They are related parts of an image contract, but neither answers the other’s question.

Object identity asks, which object is this, and which objects belong together? In this chapter, StudyInstanceUID, SeriesInstanceUID, and SOPInstanceUID provide the spine for grouping and cross-referencing. Their values let a pipeline follow a Study, a Series, or one SOP Instance without confusing the object with another object that happens to have similar descriptive metadata.

Spatial identity asks, which patient coordinate frame are this object’s coordinates expressed in? FrameOfReferenceUID answers that narrower question by stating which frame the object claims to use. It does not replace the actual origin, spacing, direction, or per-frame geometry that must be checked when alignment matters.

Conflating these questions is the error. Two objects can share a Study (the same organisational context) and still sit in different frames of reference, such as a pre-contrast Series and a post-contrast Series with a different frame. Conversely, two objects in the same frame of reference are not necessarily in the same Study. Keep “what belongs together” and “what shares a coordinate frame” separate; the DICOM Frame of Reference Module defines the spatial part of that distinction.

The identifiers, through their jobs

Tag	UID	Job	Used when…
(0020,000D)	StudyInstanceUID	unique Study identifier	grouping objects into a DICOM Study; the Study-level Query/Retrieve unique key
(0020,000E)	SeriesInstanceUID	unique Series identifier	distinguishing one logical Series from another; selecting a pipeline candidate (using a Series as a volume work unit is workflow practice)
(0008,0018)	SOPInstanceUID	unique SOP Instance identifier	identifying one concrete object; a populated SEG source-reference item may cite it
(0020,0052)	FrameOfReferenceUID	unique Frame of Reference identifier	identifying a claimed common patient coordinate frame before geometry comparison or registration
(0010,0020)	PatientID	identifier scoped by its assigning authority	matching a patient’s data; pair with IssuerOfPatientID when authority scope matters

The DICOM Study and Series definitions and Query/Retrieve keys give the first two identifiers their standard identity and query roles. The table’s short job descriptions are deliberately narrower than clinical labels: they identify entities and relationships, while geometry and provenance decide what a pipeline may safely do with them.

SOP Class and SOP Instance — “what is this object?”

A SOP (Service-Object Pair) Class is a DICOM type: the union of a Composite IOD and its applicable services. SOPClassUID (0008,0016) answers “what kind of object is this?”. The SOP Class definition and standard storage-class registry provide the normative context. The following three values are examples used in this chapter:

• 1.2.840.10008.5.1.4.1.1.2 — CT Image Storage (a classic single-frame CT image object).
• 1.2.840.10008.5.1.4.1.1.66.4 — Segmentation Storage (a DICOM SEG).
• 1.2.840.10008.5.1.4.1.1.481.3 — RT Structure Set Storage (RTSTRUCT).

A SOP Instance UID is the unique identity of one concrete object of that class. When a populated SEG source-reference item identifies an image derived from source object X, it cites X’s SOPInstanceUID. Matching these UID strings is what allows a CT-to-SEG reference to point to a particular source object rather than merely to a similarly described image; the reference may be absent from a Type 2 source sequence.

Modality as a routing hint

Modality (0008,0060) is a quick routing signal in a pipeline: CT, SEG, MR, or OT. These are DICOM-defined modality terms. The tag is useful for an initial classification, but it does not replace SOPClassUID or the references and geometry needed to understand an object’s role. TRACE-CT’s preflight illustrates this distinction by classifying each object by SOPClassUID/Modality before routing SEGs and CTs to their respective code paths.

FrameOfReferenceUID: a common-frame boundary, not grid proof

FrameOfReferenceUID names a spatial coordinate system. It is a claim about which patient frame an object’s coordinates are expressed in, not a proof of voxel-level alignment. When two objects or Series have matching FoRs, DICOM says that they claim a common frame and are spatially related. This is a normative boundary, not merely permission, but it still does not establish identical voxel grids: origin, spacing, direction, dimensions, and per-frame geometry can differ. When FoRs differ, do not overlay the objects directly. They may still be spatially related through an explicit registration or other spatial relationship that maps one frame to the other, as described by the DICOM Frame of Reference Module and Spatial Registration IOD.

same FoR      ≠  same voxel grid       (still verify origin/spacing/direction)
different FoR ≠  impossible to relate  (an explicit registration can map them)
different FoR ⇒  do NOT overlay without an explicit spatial relationship

The practical consequence is that a mask can silently land one slice off the anatomy if references are mistaken for alignment. The geometry chapter’s SEG-and-CT section returns to the comparison, where geometry, not the UID, decides whether the objects truly coincide.

Consider a CT Series and a DICOM SEG whose ReferencedSeriesSequence lists the CT’s source Series, whose populated frame references identify source SOPInstanceUIDs, and whose FrameOfReferenceUIDs match. Those facts establish a traceable source relationship and a shared-frame claim, but they do not yet make it safe to treat the SEG’s mask as sitting exactly on the CT grid. The SEG reference definitions describe the source-Series relationship; they do not turn it into a grid identity.

Matching FoR and correct source references establish a common-frame relationship, not identical grids. The SEG could still have been resampled, written on a re-sliced volume, or carry per-frame positions that differ from the CT’s slice positions. The safe next step, which the geometry chapter develops in detail, is to compare the actual geometry: origin, spacing, direction, dimensions, and per-frame positions. That comparison determines whether direct use is valid or whether resampling or incompatibility must be handled. Trust the references; verify the geometry.

Identifiers are contracts for following objects through a dataset: they support grouping, routing, and explicit references. They do not replace geometry checks, and they do not establish clinical equivalence. With object identity and spatial identity kept separate, the next section applies the distinction to one real CT: a hands-on pass with pydicom, a RIDER slice, and a 3D Slicer cross-check.