DICOM Instances, Series, and Studies explained

In medical imaging, DICOM organizes all clinical data into a four-level hierarchy: Patient, Study, Series, and Instance. Every digital X-ray, CT scan, and MRI adheres to this structure.

When software receives a medical exam from a hospital, it does not arrive as a single zip archive or video file. Instead, the exam arrives as dozens, hundreds, or even thousands of separate binary files called instances. To process, store, or display an exam, your application must understand how these individual files relate to each other.

The DICOM Standard Part 3 (PS3.3, Section 7.3) defines this information model to reflect how hospitals care for patients and acquire diagnostic scans.

Patient  (Person receiving care)
  └── Study  (Single clinical exam or imaging encounter)
        └── Series  (Single acquisition sequence or reconstruction)
              └── Instance  (Individual DICOM object, such as a 2D image slice)

Level 1: Patient

The top level represents the human subject of the examination. The patient entity contains demographic and administrative data that remains constant across multiple hospital visits:

• Patient Name (DICOM tag (0010,0010))
• Patient ID (DICOM tag (0010,0020))
• Patient Birth Date (DICOM tag (0010,0030))
• Patient Sex (DICOM tag (0010,0040))

In hospital workflows, patient identification originates in a Master Patient Index (MPI) or Hospital Information System (HIS). A single patient can have many imaging studies performed across months or years.

Level 2: Study

A Study represents a distinct medical imaging event or examination session. A physician orders a study to answer a specific clinical question—for example, “CT Abdomen and Pelvis with Contrast” or “MRI Brain Routine”.

Hospitals track studies using clinical identifiers alongside technical identifiers:

• Study Instance UID (DICOM tag (0020,000D)): The globally unique technical identifier for the study, formatted as a dot-separated numeric string (such as 1.2.840.113619.2...).
• Accession Number (DICOM tag (0008,0050)): A human-readable order number generated by the Radiology Information System (RIS).
• Study Date and Time (DICOM tags (0008,0020) and (0008,0030)): When the exam took place.
• Study Description (DICOM tag (0008,1030)): A clinical summary of the examination.

A patient can have multiple studies, but a study belongs to exactly one patient.

Level 3: Series

A Series represents an individual data acquisition sequence within a study. Diagnostic imaging equipment rarely captures an entire exam in a single exposure. Instead, an operator runs multiple passes, changes scanner angles, applies contrast agents, or reconstructs raw sensor data into different views.

Each distinct technical run forms its own series:

• In an MRI study, one series might capture a T1-weighted axial sequence, while another series captures a T2-weighted sagittal sequence.
• In a CT study, one series captures a pre-contrast scan, a second series captures an arterial phase, and a third reconstructs thin slices for vascular review.

Key series-level metadata includes:

• Series Instance UID (DICOM tag (0020,000E)): The globally unique technical identifier for the series.
• Modality (DICOM tag (0008,0060)): The acquisition equipment type, such as CT, MR, XA, or US.
• Series Number (DICOM tag (0020,0011)): An integer indicating the sequence order on the operator console.
• Series Description (DICOM tag (0008,103E)): A label describing the acquisition parameters or view.

Every series belongs to exactly one study, and all images inside that series share the same acquisition modality.

Level 4: Instance

An Instance is the atomic unit of DICOM storage and transmission. In most cases, an instance is a single 2D image slice. However, an instance can also represent a multiframe cine loop, a radiotherapy plan, an ultrasound clip, or a structured reporting document.

Key instance-level metadata includes:

• SOP Instance UID (DICOM tag (0008,0018)): The globally unique identifier for this specific object. In DICOM terminology, “SOP” stands for Service-Object Pair.
• Instance Number (DICOM tag (0020,0013)): The position of this slice within its parent series (such as slice 45 of 200).
• Image Position and Orientation (DICOM tags (0020,0032) and (0020,0037)): Three-dimensional spatial coordinates that allow viewing workstations to reconstruct cross-sectional volumes.

Because each instance represents a single discrete file, a modern high-resolution CT study can contain 2,000 distinct instances.

How Unique Identifiers (UIDs) bind the hierarchy

In web development, relational models often rely on primary keys or UUID strings. DICOM relies on Unique Identifiers (UIDs), governed by ISO/IEC 8824 and DICOM PS3.5 Section 9.

A DICOM UID is a dot-separated sequence of numeric components with a maximum length of 64 bytes. For example:

1.2.840.113619.2.55.3.604688319.876.1694412345.123

Importantly, every single DICOM instance file is completely self-contained. An instance does not just store its own slice data; it embeds the complete lineage of identifiers pointing up the tree:

Because every instance carries its parent StudyInstanceUID and SeriesInstanceUID, a receiving system can reconstruct the entire four-level tree without consulting a central coordinator.

Why medical imaging arrives as thousands of files

Engineers building healthcare software often ask a practical question: why don’t scanners package an entire study into a single archive before sending it?

There are three operational reasons rooted in physics and clinical workflow:

1. Streaming during acquisition: A full CT or MR scan takes several minutes to acquire. Scanners reconstruct and transmit slices in real time as the patient moves through the gantry. If the scanner waited to package 2,000 slices into one file, radiologists would wait longer to review urgent trauma scans.
2. Independent random access: Radiologists frequently view specific series or slices without downloading gigabytes of unneeded raw data. By keeping instances distinct, storage archives support granular queries and partial retrievals.
3. Transmission resilience: If a network blip interrupts a transfer after 400 slices of a 500-slice series, the sender can resume or retry only the missing instances. In a single-archive model, any failure requires restarting the entire transfer from byte zero.

Understanding this design shapes how you build your ingestion pipeline. When integrating with hospital senders over classic DIMSE or web-based DICOMweb STOW-RS, your service must process a high-volume stream of individual instances and assemble them asynchronously by StudyInstanceUID.

Common integration pitfalls for software teams

When handling DICOM hierarchies in modern cloud architectures, watch for these common failure modes:

• Assuming instances arrive in numerical order: A DICOM sender transmits instances as network resources become available. Slice 12 may arrive before slice 1. Your ingest pipeline should never assume instances arrive sorted by InstanceNumber.
• Declaring a study complete prematurely: DICOM transfer protocols like C-STORE operate instance by instance. Senders provide no native “end-of-study” packet or manifest file. A common mistake is closing out a study after the first pause in traffic, only to receive 300 more slices two minutes later. Resilient architectures use a debounce timeout or listen for formal modality study status messages before triggering downstream processing.
• Keying application records on Patient ID alone: Patient IDs are issued locally by hospital systems. Two different medical facilities can assign the exact same PatientID (12345) to two completely different human beings. Always scope patient records to a verified facility identifier, or rely on StudyInstanceUID for global uniqueness.
• Failing to handle duplicate instances: Modalities frequently retry transfers when associations drop. If a scanner transmits the same slice twice, both instances will share the exact same SOPInstanceUID. Your storage and indexing layer must treat SOPInstanceUID writes as idempotent operations.

To learn more about how DICOM senders transfer instances across networks, read our breakdown of DICOM C-STORE vs DICOMweb STOW-RS. If you need to accept incoming transfers from hospital scanners, see our guide on receiving DICOM deliveries.