DICOM: not just a file format for medical images

A standards literacy problem, not a data quality problem

A team gets funding to build a model that reads chest radiographs. Week one goes well: someone downloads a public dataset, pydicom opens the files, and a CNN starts training.

Week six is where the trouble starts. The hospital's images do not look like the public ones. Half the studies arrive with the anatomy inverted. The pixel values in one vendor's CT are not the same physical quantity as another's. Nobody can say which of the 400 files in a folder belong to the same acquisition. And when the model finally produces an output, there is no obvious way to put it back where a radiologist will ever see it.

None of this is a data quality problem. It is a standards literacy problem. DICOM answers every one of those questions precisely, and has done for thirty years. The answers are simply spread across roughly four thousand pages that nobody reads front to back.

Four layers, and only one of them is a file format

DICOM is published by NEMA as PS3 and internationally as ISO 12052. It is not one specification. It is twenty interlocking parts that, taken together, define four different things.

The most common misconception is that DICOM is a file format with an unusually annoying header. It is more useful to think of it as a stack. A chest radiograph passes through all four layers on its way from the detector to a screen, and a project that only understands the bottom one will fail at the top three.

That bottom band alone is a file format. Most integration failures happen in the other three.

Three myths worth killing early

• A DICOM file is one image. A single instance can hold one frame, a hundred frames of a cine loop, a whole 3D volume, a segmentation mask, a waveform, a PDF or an STL mesh. Conversely, one CT scan is normally hundreds of separate files that only a shared Series Instance UID binds together.
• DICOM tells me what a good imaging system should do. It does not. DICOM specifies the syntax and semantics of what is exchanged, and deliberately leaves application behaviour, feature sets and validation procedures out of scope. Two products can both be perfectly conformant and still refuse to work together.
• Pixel values are pixel values. The number stored in a CT is not a Hounsfield unit until you apply the rescale slope and intercept, and it is not a displayable grey level until you apply a window. Skip either step and your model trains on the wrong physical quantity.

The hierarchy lives inside every object

Everything in DICOM hangs off four levels. Learn them and half the standard stops being mysterious.

The critical property is that the hierarchy lives inside every object. There is no manifest file and no database schema you are handed. Each instance independently carries its patient, study and series identity, which is why you can drop a thousand loose files into a folder and reconstruct the whole exam correctly. It is also why a single mis-set UID silently splits one study into two.

That has a direct consequence for anything you build. Your model's output belongs in a new series inside the same study, not in a PNG in a storage bucket. Written back as a Segmentation instance it is discoverable by every viewer in the hospital; written beside the pipeline it is invisible to clinical care.

The rule that will bite you

A SOP Instance UID identifies that exact object, forever. If you change so much as one pixel or one attribute, you must issue a new UID.

Re-using an existing UID for altered content is the single most damaging thing an imaging pipeline can do. Archives deduplicate on UID, so the altered object is silently discarded, or worse, silently replaces the original. De-identification tools that keep the UIDs the same for traceability have caused real clinical incidents.

Stored values are not pixels

This is the part that saves the most time, because getting it wrong produces results that look plausible and are quietly meaningless. The numbers in PixelData are stored values. They are not physical quantities and they are not display intensities. Two transformations stand between them and a picture, and both are described by attributes in the object.

The Modality LUT, meaning rescale slope and intercept, converts stored values to a real-world quantity such as Hounsfield units. The VOI LUT, the window centre and width, converts that to a display value. Worked through on a soft-tissue CT: stored 1074, slope 1, intercept -1024 gives 50 HU, and a centre of 40 with a width of 400 puts it at mid-grey.

Six things to check before you touch a pixel array:

• Rescale. Apply RescaleSlope and RescaleIntercept. For CT this converts to Hounsfield units. For PET the correct transformation is more involved and usually needs a Real World Value Mapping.
• Signedness. PixelRepresentation tells you whether the samples are unsigned or two's-complement. Guessing produces images that look like photographic negatives in the dark regions.
• Bit depth. BitsAllocated is the container, usually 16. BitsStored is how many bits are meaningful, often 12. The unused ones are not always zero.
• Polarity. MONOCHROME1 means the minimum value renders as white. It is common in mammography and older CR. Ignore it and your image is inverted.
• Geometry. Sort a CT stack by filename and you will get the slices in the wrong order. Sort by ImagePositionPatient projected onto the slice normal and you will not.
• Frame of reference. FrameOfReferenceUID is what lets a mask produced from one series be overlaid on another without registration. Preserve it in every derived object you create.

One distinction comes before all of that. Digital radiography and mammography ship two SOP classes for the same acquisition. For Processing is the raw detector output, which is generally what an algorithm should consume. For Presentation has been through the vendor’s enhancement pipeline and is what the radiologist sees. They are different SOP class UIDs, they look different, and a model trained on one will not transfer cleanly to the other.

Where model output belongs

DICOM has well specified, widely implemented object types for the things models produce. Use them.

What does not exist is a DICOM object for a model. As of the 2026c edition there is no IOD, SOP class or supplement for storing weights, architectures, ONNX artefacts or model cards, and no supplement in public comment or ballot proposes one. What the standard does offer is provenance on the output: the Algorithm Identification Macro, the Contributing Equipment Sequence, and the referenced-instance mechanisms that record exactly which images an output was derived from. Populate all three. An unattributed segmentation in a patient’s record is a liability.

The single most common architectural mistake is writing model output as a Secondary Capture image, a burned-in flattened screenshot of the overlay. It is the path of least resistance and every DICOM library makes it easy. It is also non-interoperable: nothing downstream can toggle it, measure it, recompute it, or tell which pixels are the finding. The standard permits it. The professional profiles exclude it.

Worth naming, because it is widely misused: AI Results is an IHE profile, not a DICOM object. It constrains which DICOM objects an AI application should produce, and it excludes Secondary Capture explicitly.

What changed since 2020

Most DICOM introductions on the internet were written between 2010 and 2018 and have not been touched since. Four changes since then are the ones most likely to affect a project starting today.

• HTJ2K is the compression target. High-Throughput JPEG 2000 arrived in 2023 with three true codecs. It is dramatically faster to encode and decode than classic JPEG 2000, and the RPCL variant orders the codestream so a thumbnail can be produced by decoding a fraction of the bytes. At least one major cloud provider transcodes to it losslessly on ingest by default.
• The web API was rebuilt underneath you. In 2019 PS3.18 was re-documented from a list of ad-hoc services into a uniform resource-and-transaction model, and every section number changed. The inventory has since grown to thumbnails, rendered resources, server-side volume rendering, storage commitment over HTTP and RESTful procedure-step services.
• Your TLS configuration guide is wrong. A 2022 supplement retired three TLS profiles at once, after two others had already gone in 2018. What remains is PS3.15 Annex B.12: TLS 1.2 minimum with 1.3 preferred, null ciphers prohibited, servers required to support mutual authentication. A runbook telling someone to enable the Basic TLS profile is describing something the standard has not defined for eight years.
• Petabyte archives got a real answer. Classic Query/Retrieve was never intended to enumerate an entire archive, and its behaviour when results exceed limits is undefined. A 2022 supplement added Repository Query and an Inventory object: a persistent, storable listing of an archive’s complete content, produced asynchronously. The named use cases include PACS migration, audit, and assembling machine-learning datasets.

One honest clarification, because it is widely assumed otherwise. DICOM does not standardise authorization for web services. PS3.18 explicitly places access control, authorization and auditing out of scope. In practice DICOMweb authorization comes from IHE’s Internet User Authorization profile or from your cloud provider’s IAM. Plan for it; do not expect the standard to hand it to you.

Where DICOM stops

Everything above describes a language: characters, words, grammar. What it does not describe is a conversation.

DICOM tells you that a Modality Worklist entry exists and what attributes it may carry. It does not tell you which of them a scanner must copy into the images it produces, or what to do when a patient arrives without an order, or how the accession number should flow from the order system through the worklist to the performed procedure step to the stored image so that a report can find its images six months later. Two vendors can implement every relevant SOP class perfectly and still produce a department where studies go missing.

That gap is where most integration cost actually lives, and closing it is what IHE exists to do. Part 2 of this series walks through the profile that runs almost every radiology department on earth.

The full 32-page paper goes further in every direction: association negotiation read from a real service log, the DICOMweb resource model, digital pathology, how to read a conformance statement, and nine mistakes that are cheaper to avoid than to discover in validation.