Skip to content
Imaging Evidence Path

Which identifiers hold the system together

Tonight · ~25 min · read · energy: low · setup: none

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. This lesson is the durable reference for those identifiers — but it is worth meeting them through the workflows that use them, not as a bare table.

The anchor: a SEG needs to name its source

When you segment a tumour on a CT and save it as a DICOM SEG, the segmentation must record which CT it was drawn on. Otherwise it is an orphan mask floating in no coordinate system. The mechanism is a chain of UIDs: the SEG cites the series it belongs to and, per frame, the SOP instances (slices) it was derived from. Read the identifiers below as the vocabulary that makes that chain possible.

Two different kinds of identity

The subtlety that bites people is that DICOM has two separate identity questions, and they use different UIDs:

  • Object identity — which object is this, and which ones belong together? Answered by StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID. These are the spine of grouping and cross-referencing.
  • Spatial identity — which patient coordinate frame are this object’s coordinates expressed in? Answered by FrameOfReferenceUID. This decides whether two objects claim to share a coordinate system.

Conflating them is the error. Two objects can share a Study (same exam) and still sit in different frames of reference (e.g. a pre-contrast series and a registered post-contrast series). Conversely, two objects in the same frame of reference are not necessarily the same study. Keep “what belongs together” and “what shares a coordinate frame” as separate questions.

The identifiers, through their jobs

Tag UID Job Used when…
(0020,000D) StudyInstanceUID “this exam” grouping all series of one study; the PACS query key
(0020,000E) SeriesInstanceUID “this acquisition/reconstruction” your unit of work for a volume; what a SEG cites as its source series
(0008,0018) SOPInstanceUID “this slice/object” the join key a SEG uses to reference its source slices
(0020,0052) FrameOfReferenceUID “this coordinate frame” deciding whether overlay/comparison is geometrically legitimate
(0010,0020) PatientID “this patient (within an authority)” grouping a patient’s data; pair with IssuerOfPatientID across sites

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

A SOP (Service-Object Pair) Class is a DICOM type: an Information Object Definition plus a set of services. SOPClassUID (0008,0016) answers “what kind of object is this file?”. Three you will meet constantly:

  • 1.2.840.10008.5.1.4.1.1.2 — CT Image Storage (a single CT slice).
  • 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 SEG says “I was derived from slice X”, it cites X’s SOPInstanceUID. Get comfortable matching these UIDs as strings — they are the spine of CT↔SEG linkage.

Modality — a one-tag filter

Modality (0008,0060) is the quickest filter in any pipeline: CT, SEG, MR, OT. TRACE-CT’s preflight classifies every object by SOPClassUID/Modality before doing anything else, so SEGs and CTs are handled by the right code paths.

FrameOfReferenceUID: permission, not 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:

  • Matching FoR → the objects claim the same patient frame. This is permission to compare geometry directly — but it does not prove identical grids (origin/spacing/direction can still differ).
  • Differing FoR → do not overlay blindly. The objects may still be spatially related, but only through an explicit registration that maps one frame to the other.
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

This is the rule that keeps a mask from silently landing one slice off the anatomy. We will return to it in force in Chapter 2, lesson 5, where geometry — not the UID — decides whether a SEG and CT truly coincide.

Stop and think — then reveal

You have a CT series and a DICOM SEG. The SEG’s ReferencedSeriesSequence cites the CT’s SeriesInstanceUID, and per frame it cites the source SOPInstanceUIDs. Their FrameOfReferenceUIDs match. Is it now safe to treat the SEG’s mask as sitting exactly on the CT grid?

Not yet. A matching FoR and correct source references are permission to compare geometry, not proof of 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 Chapter 2 does in detail — is to compare the actual geometry (origin/spacing/direction and per-frame positions) and classify the pairing as EXACT_GRID, RESAMPLING_REQUIRED, or INCOMPATIBLE, exactly as TRACE-CT’s classify_transfer_pair() does. Trust the references; verify the geometry.

What to retain

  1. Two identity questions, two UID families: object identity (Study/Series/SOP) vs spatial identity (FrameOfReferenceUID). Do not conflate them.
  2. StudyInstanceUID = exam, SeriesInstanceUID = acquisition/reconstruction (the volume unit), SOPInstanceUID = one slice/object (the join key SEGs cite).
  3. SOPClassUID tells you what kind of object a file is before you parse it; Modality is the one-tag filter.
  4. FrameOfReferenceUID is a fast rejection test and a slow acceptance test: matching FoR lets you proceed to verify geometry; it does not prove alignment.

Next: stop reading about CT and open one. A hands-on pass with pydicom, a RIDER slice, and a 3D Slicer cross-check.