DICOM — Digital Imaging and Communications in Medicine — is the standard that makes a modern imaging department possible. It is the reason a scanner from one manufacturer can send a study to an archive from another, and a radiologist can open it on a workstation from a third.
It is often described as "the medical image format", which undersells it considerably. DICOM defines both how imaging data is structured and how systems exchange it over a network. Understanding that dual nature is the key to understanding why integration projects go the way they do.
Two things in one standard
A data model and file format
A DICOM object is not just pixels. It carries the image together with structured metadata describing everything about it — who the patient is, what equipment produced it, what parameters were used, and where it sits within a larger study.
That metadata travels with the image rather than in a separate database. Move the file and the context moves with it, which is fundamental to how imaging data stays reliable as it passes between systems.
A network protocol
DICOM also defines how devices talk to each other. The classic service layer is known as DIMSE, and the operations it provides are the vocabulary of every imaging department:
- C-STORE : send an image or study to another system
- C-FIND : query for studies matching given criteria
- C-MOVE : request that studies be transferred to a destination
- C-ECHO : a connectivity test, universally called "DICOM ping"
- Modality Worklist : a scanner queries for its list of scheduled patients
- Storage Commitment : the archive confirms it has taken responsibility for storing a study
The information hierarchy
DICOM organises data in a four-level hierarchy, and this structure appears in every system that touches imaging:
- Patient : the person
- Study : one imaging examination, identified by a Study Instance UID
- Series : a set of images acquired together, such as one sequence or one view
- Instance : a single image or object
Each level carries a globally unique identifier. Those UIDs are what allow a study to be moved, copied and referenced across systems and years without ambiguity.
Attributes and the data dictionary
Every piece of metadata is an attribute identified by a tag — a group and element number, written like (0010,0010) for Patient Name. The DICOM data dictionary defines thousands of these, and each carries a Value Representation specifying its data type.
This is what makes DICOM machine-interpretable rather than merely structured. Software does not need to guess what a field contains, because the standard has already defined it.
Modality-specific definitions
Different imaging types have genuinely different requirements, and DICOM handles this through Information Object Definitions — separate specifications for CT, MR, ultrasound, digital radiography, mammography and others.
Mammography is a good illustration. It has particular requirements around laterality, view position and image presentation that a general radiography definition does not cover adequately, so it has its own. Systems handling mammography must implement those specifics correctly, not merely handle "an X-ray image".
Conformance statements
Here is the practical part that catches teams out. DICOM is a large standard, and no product implements all of it. Every conformant product publishes a Conformance Statement declaring exactly which services, roles, information objects and transfer syntaxes it supports.
The single most useful habit in imaging integration: read both conformance statements before assuming two systems will work together. "Both are DICOM compliant" does not mean they are compatible — it means they each implement some subset of a very large standard, and those subsets may not overlap where you need them to.
Why it matters
Interoperability
Without a common standard, every scanner would need a bespoke integration with every archive and viewer. DICOM is what makes a multi-vendor department practical.
Clinical safety
Because identifiers and context travel with the image, the risk of a study being attributed to the wrong patient during transfer is dramatically reduced.
Longevity
Imaging records must remain readable for many years. A documented, stable standard means a study archived today can still be opened long after the system that produced it has been retired.
Regulatory expectation
In practice, DICOM support is a baseline requirement for imaging equipment entering clinical use. A device that cannot participate in a DICOM workflow does not fit into a hospital, whatever its other merits.
Where teams typically struggle
- Transfer syntax mismatches : two systems support DICOM but not a common compression, so transfers fail or require conversion
- Incomplete worklist implementation : forcing manual patient entry at the modality, which reintroduces transcription errors
- UID handling : generating or modifying UIDs incorrectly, which breaks study relationships in ways that surface much later
- Character set handling : patient names in non-Latin scripts displaying incorrectly downstream
None of these are exotic. They are the ordinary substance of imaging integration work, and they are why conformance statements matter more than marketing claims.