Skip to content
Imaging Evidence Path

How hundreds of DICOM files become one examination

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

You are handed a folder called patient_2024_scan/ containing 1,137 .dcm files. There is no index, no manifest, no “volume”. Just files. Your task is to rebuild the actual examination from them. This lesson is the mental model DICOM uses to make that possible — and the reason it is necessary but not sufficient.

The anchor: a folder is not an exam

A single CT study arrives as one file per slice (in the classic model), often plus a few extra series. With nothing but filenames you cannot know which files belong together, which are axial slices vs a 2D scout, or what order they go in. DICOM solves the belonging problem with a four-level hierarchy; it deliberately leaves the ordering problem to geometry, which is Chapter 2.

The four levels

flowchart TD
    PAT["Patient<br/>PatientID"]
    STU["Study<br/>StudyInstanceUID"]
    SER["Series<br/>SeriesInstanceUID"]
    INS["Instance (one slice)<br/>SOPInstanceUID"]
    PAT --> STU
    STU --> SER
    SER --> INS
    SER --> INS2["Instance …"]
    STU --> SER2["Series 2<br/>(different recon)"]
    SER2 --> INS3["Instance …"]

Think of each level as a question:

  • Patient — whose data is this? One PatientID. (Across sites, PatientID is only meaningful within its assigning authority — pair it with IssuerOfPatientID when matching across systems.)
  • Study — which exam? Best read as one imaging encounter: “CT chest with contrast, 2024-03-01”. One StudyInstanceUID. Carries StudyDate, StudyDescription, referring physician.
  • Series — which acquisition/reconstruction stream? Best read as one contiguous acquisition or reconstruction: “axial 1.25 mm lung kernel”. One SeriesInstanceUID. This is where geometry and reconstruction live — modality, kernel, spacing, orientation are per-series.
  • Instance (a.k.a. SOP Instance) — which single image/slice? One SOPInstanceUID. Carries its own ImagePositionPatient, PixelData, etc.

Walk the folder

With that hierarchy, the 1,137 files resolve cleanly. You group by StudyInstanceUID (one exam), then within it by SeriesInstanceUID. Suppose you find three series:

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

Notice the trap hiding in row C. A localizer (scout) is a 2D projection acquired to plan the scan range. It is a perfectly valid DICOM image in the same study, but if you naively concatenate every instance in the study into one stack, the localizer corrupts the volume. Real ingestion pipelines filter on ImageType, ConvolutionKernel, and SliceThickness to keep only the true axial slices of the series you intend. TRACE-CT’s load_ct_volume_explicit() does exactly this — it drops localizers and validates regularity before declaring a stack a usable volume.

Why the hierarchy is necessary but not sufficient

The hierarchy tells you what belongs together. It does not tell you how to stack the slices of one series into a 3D volume. For that you need, per instance:

  • 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) — in-plane spacing.
  • SliceThickness / SpacingBetweenSlices — z information.

Key mental model: instance ordering is a geometric property, not a sequence number. Sorting slices by InstanceNumber or by filename is unreliable; the safe ordering is the projection of each slice’s position onto the slice normal. That is the central operation of Chapter 2, lesson 4.

This is also why “DICOM study” and “3D volume” are different things. A study is an organisational unit; a volume is a geometric construct you must build and validate from a single series’ instances.

Classic single-frame vs Enhanced CT

The “one instance = one slice” model above is the classic single-frame CT object (CT Image Storage), and it is what RIDER and TRACE-CT use. 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 geometry concepts are identical; only the packaging differs. Just do not leave this chapter believing “DICOM CT universally means one file = one slice.”

Stop and think — then reveal

You group all instances in a study by SeriesInstanceUID and find two series that share an identical StudyInstanceUID, the same PatientID, the same ConvolutionKernel, the same SliceThickness, but different SeriesInstanceUID. What is the most likely explanation, and is it safe to merge them into one volume?

Most likely they are two exports/reconstructions that happen to share parameters, or one series split across two acquisitions. It is not safe to merge them on metadata similarity alone: a merge is only valid if the combined slices form a single regular geometric stack (consistent orientation/spacing, monotonic, non-overlapping positions along the slice normal). Merge on verified geometry, never on metadata resemblance. Two series with identical metadata can still sit in different physical space.

What to retain

  1. DICOM organises with Patient → Study → Series → Instance; geometry and reconstruction live at the Series level.
  2. A study is an exam; a series is one acquisition/reconstruction; an instance is one slice (classic model). A folder of files resolves by grouping on these UIDs.
  3. The hierarchy solves belonging; it does not solve ordering — that needs geometry (Chapter 2).
  4. Beware the localizer/scout: a valid series in the study that is a 2D planning image, not an axial slice. Filter, do not blindly concatenate.

Next: which UIDs actually hold this structure together, and what is the difference between an object’s identity and its spatial frame? The identifiers that hold the system together.