How hundreds of DICOM files become one examination

You are handed a folder called patient_2024_scan/ containing 1,137 .dcm files. There is no index, no manifest, no “volume”. Just files. The folder name does not tell you which objects form one image product, which object is a planning image, or whether the files can be assembled into a valid volume. The first task is therefore not to concatenate files, but to establish what each object represents and which relationships are safe to infer.

DICOM provides an organisational hierarchy for that work. The Composite IOD entity-relationship model, General Study Module, and General Series Module help separate objects that belong to different patients, imaging encounters, Series, and individual Instances, but they do not make every object within a Study one acquisition, one spatial grid, or one clinically interchangeable image. The hierarchy is necessary for interpreting a folder and still not sufficient for constructing an image.

A folder is not an exam

For a classic single-frame CT export, one slice may arrive as one file, often alongside several additional series. That is a common packaging pattern, not a universal definition of a DICOM examination. With nothing but filenames you cannot know which files belong together, which are axial slices versus a 2D scout, or what order they go in. DICOM addresses the belonging problem with a four-level hierarchy; it leaves the ordering problem to geometry, which is developed in the geometry chapter.

The four levels

The hierarchy describes the intended containment relationship, not a promise that every implementation stores one slice in one file. It also makes an important distinction visible: two different reconstruction products can share a Study while remaining separate Series, and each Series can contain many Instances.

The levels are useful as four related questions, but the questions are working handles rather than universal definitions of what an examination, series, or slice must be. At the Patient level, the question is whose data is being described. A PatientID identifies a patient within its assigning authority; when records are matched across systems, the source pairing is PatientID with IssuerOfPatientID rather than treating the character string as globally meaningful.

At the Study level, the question is which imaging encounter the objects are associated with. A useful description for the example is “CT chest with contrast, 2024-03-01”. The objects carry a StudyInstanceUID, along with attributes such as StudyDate, StudyDescription, and the referring physician. That description provides organisational context; it does not by itself prove that all objects in the Study share an acquisition, reconstruction, geometry, or clinical purpose.

At the Series level, the question is which logical DICOM Series an object belongs to. SeriesInstanceUID distinguishes that Series from another Series in the same Study; it does not define a universal acquisition or reconstruction stream. The DICOM information model also does not make Acquisition and Series one-to-one: one Acquisition may yield multiple Series, and a Series may contain Instances from multiple Acquisitions. “Axial 1.25 mm lung kernel” is therefore a useful working label in this example, not a definition supplied by the UID. In a pipeline, a Series may be selected as a candidate image product, but modality, kernel, spacing, and orientation are workflow evidence to inspect rather than a promise that related Series can be combined.

At the Instance level, the question is which individual DICOM object is being handled. In the classic single-frame CT packaging used by the bounded RIDER and TRACE-CT example, one SOP Instance is one image object commonly represented by a file and can correspond to one slice; it has its own SOPInstanceUID, ImagePositionPatient, and PixelData. That relation is a property of this packaging example, not a universal DICOM rule, because a multi-frame SOP Instance can contain multiple frames.

A concrete folder example

Apply that mental model to the folder without assuming that its files are one volume. Grouping by StudyInstanceUID, and then within that context by SeriesInstanceUID, might reveal three series in this explicitly fictional worked example:

Series	Files	What it is
Series A	320 slices × 1.25 mm, sharp lung kernel	the thin lung-kernel volume
Series B	80 slices × 5.0 mm, standard/soft-tissue kernel	the thick soft-tissue volume
Series C	1 image, 2D	the scout/localizer — a planning image, not an axial slice

The third row exposes why grouping is not the same as volume construction. In this CT workflow, an image whose ImageType includes the defined LOCALIZER value is treated as a planning image. That value does not define a universal shape or a complete one-tag filter. It is a perfectly valid DICOM image in the same Study, but concatenating every Instance in that Study into one stack would corrupt the volume. The CT Image Module’s description of LOCALIZER supports this planning role.

An ingestion pipeline therefore needs a rule for selecting the intended image product. In the bounded source workflow, ImageType, ConvolutionKernel, and SliceThickness are selection signals used alongside the object type, SeriesInstanceUID, and geometry; they are not a normative selector list. A robust selection validates those relationships before retaining the axial slices of the chosen Series. The TRACE-CT learning map provides an implementation illustration in load_ct_volume_explicit(), which drops localizers and validates regularity before declaring a stack usable.

Why the hierarchy is necessary but not sufficient

The hierarchy has separated the image products, but it has not told you how to stack the Instances of one Series into a 3D volume. That decision depends on per-instance spatial attributes, including:

• ImagePositionPatient (0020,0032) — the (x, y, z) of the top-left voxel centre in patient coordinates.
• ImageOrientationPatient (0020,0037) — direction cosines of the row and column axes.
• PixelSpacing (0028,0030) — row and column spacing in the image plane.
• SliceThickness — nominal slice thickness; SpacingBetweenSlices, when present, describes centre-to-centre separation. They are not interchangeable z values.

The DICOM Image Plane Module defines the spatial attributes, but instance ordering is a geometric property, not a sequence number. For a selected candidate set, projection of each position onto the slice normal can provide an ordering only after validating consistent orientation, dimensions, PixelSpacing, finite orthonormal direction vectors, unique positions, and regularity. Sorting by InstanceNumber or by filename is only a secondary diagnostic. The construction and validation of this ordering belong to the geometry chapter’s slice-order section, not to the hierarchy itself.

This is why a “DICOM Study” and a “3D volume” are different things. A Study is an organisational unit; a volume is a geometric construct that must be built and validated from the Instances selected from a Series. Treating a Series as a pipeline work unit is useful practice, not a promise that every Series is a regular volume.

Classic single-frame vs Enhanced CT

The one-object-per-image shorthand above is limited to the classic single-frame CT image object used in the bounded RIDER/TRACE-CT workflow discussed here. This packaging is not a universal rule, and the TCIA collection record does not by itself establish how every object in the collection is packaged. Modern DICOM also defines Enhanced CT, a multi-frame object where a single SOP Instance contains many frames, each described by per-frame functional group macros (the same mechanism DICOM SEG uses). The CT Image IOD definitions and Enhanced CT Image IOD make the packaging distinction explicit. Do not leave this chapter believing that “DICOM CT universally means one file = one slice.”

The distinction matters when two candidate Series look alike. Suppose two Series share an identical StudyInstanceUID, the same PatientID, the same ConvolutionKernel, and the same SliceThickness, but have different SeriesInstanceUID values. They may be two exports or reconstructions that happen to share parameters, or one Series split across two acquisitions. Metadata similarity alone is not a safe merge rule. Geometry is necessary but not sufficient: combine distinct Series only when provenance establishes that they are intended components of one logical stack, a shared FrameOfReferenceUID or another explicit spatial relationship makes the relationship legitimate, and the combined geometry is consistent. The geometry still needs validated orientation, dimensions, in-plane spacing, unique positions, and regular centre-to-centre gaps. Without that provenance and spatial relationship, keep the Series separate even if their positions appear continuous. This is a pipeline decision, not a universal DICOM equivalence rule; the Frame of Reference Module provides the relevant spatial boundary.

The hierarchy is therefore an organisational contract, not proof of spatial or clinical equivalence. The decoded pixel values from the preceding section are now associated with a particular object and Series, but packaging still leaves a further identity question: which UID identifies the object itself, and what distinguishes its spatial frame from its organisational membership? The next section follows those identifiers and the difference between an object’s identity and its spatial frame: the identifiers that hold the system together.