DICOM

In one line

DICOM (Digital Imaging and Communications in Medicine) is why a CT from any scanner opens in any workstation: one standard covering the image format, the network services that move studies, and the metadata that keeps them attached to the right patient.

More than a file format

People meet DICOM as the .dcm file, but it's really three standards in one — and that's the point. It defines the object (pixels + metadata), the network services (how studies move between machines), and elements of workflow (worklists, status). Get an image from any vendor's scanner to any vendor's archive and viewer, and DICOM is what made it possible.

The information hierarchy

DICOM organises everything around the patient, in four nested levels (the diagram above):

• Patient → has one or more Studies (an exam, e.g. "CT chest 12 Jan").
• Study → has one or more Series (one acquisition/sequence, e.g. "axial, contrast").
• Series → has many Instances (the individual images/slices).

Each level has a unique identifier (the UID), so an instance always knows which series, study and patient it belongs to. This is why a DICOM image is never an orphan file — the header carries identity and acquisition parameters with the pixels.

The network services

Moving studies is its own protocol family:

Service	Job	Modern REST equivalent (DICOMweb)
C-STORE	send images to the archive	STOW-RS (store)
C-FIND	query for studies	QIDO-RS (search)
C-MOVE / C-GET	retrieve a study	WADO-RS (fetch)
MWL	modality worklist (the schedule)	—

The classic services connect modalities (scanners) to the PACS (Picture Archiving and Communication System). DICOMweb wraps the same operations in REST/HTTP so browsers and cloud systems can participate without the legacy network stack.

Where it shows up in digital health

• Every radiology department on the planet; teleradiology and cloud PACS.
• AI imaging pipelines — consume DICOM in, emit DICOM Structured Reports (DICOM-SR) or annotations out, so results flow back into clinical systems.
• The FHIR boundary — FHIR ImagingStudy references DICOM studies (it doesn't replace them), so the EHR record and the image archive stay linked. DICOM holds the pixels; FHIR holds the clinical context.

De-identification — a real hazard

Removing identity from imaging is harder than from a database: identifiers live across many header tags, and worse, can be burned into the pixels (a patient name rendered onto an ultrasound frame). Proper DICOM de-identification handles both. This is exactly why our labs use synthetic studies only.

Common pitfalls

• Trusting the file name — identity is in the header UIDs, not the filename.
• Forgetting burned-in PHI when sharing images for teaching or AI.
• Treating FHIR ImagingStudy as the image — it's a pointer to the DICOM study, not a replacement for PACS.

Key takeaways

• DICOM = format + network services + workflow for medical imaging, all in one standard.
• The Patient → Study → Series → Instance hierarchy (with UIDs) keeps every image tied to its context.
• DICOMweb brings the same operations to REST/cloud.
• FHIR ImagingStudy links to DICOM; de-identification must cover headers and pixels.