Start here

What is DICOM?

DICOM — Digital Imaging and Communications in Medicine — is the universal standard for how medical images are stored, transmitted, and displayed. Every modern CT scanner, MRI, X-ray machine, ultrasound system, and PACS speaks DICOM. It is both a file format and a network protocol, and that dual nature is the single most important thing to understand about it.

The two faces of DICOM

When someone says "a DICOM file" they usually mean an individual .dcm file on disk. When someone says "DICOM communication" they mean the TCP/IP network protocol that one device uses to send those files to another. The same standard governs both, and the same data elements appear in both — which is why understanding DICOM means understanding the shared vocabulary first, and the file-vs-network distinction second.

File side: a dataset of data elements, each identified by a group/element pair like (0010,0010) for Patient's Name, wrapped around the pixel data.

Network side: a negotiated association between two devices (Service Class User + Service Class Provider) that exchanges those same data elements over TCP, framed by DICOM Upper Layer + DIMSE messages.

Why DICOM exists

Before DICOM, every imaging vendor used a proprietary format. A GE CT couldn't send images to a Siemens workstation without a custom translation layer. Hospitals ended up locked into single-vendor ecosystems at enormous cost. The American College of Radiology and the National Electrical Manufacturers Association (NEMA) co-founded what would become DICOM in 1983, published ACR-NEMA 1.0 in 1985, and reached the modern DICOM 3.0 form in 1993. Since then it has been a living standard, versioned annually (the current edition is NEMA 2025a), maintained by committees of vendors, clinicians, and researchers.

DICOM's practical effect: a radiology department can buy a CT from one vendor, a PACS from another, and a specialty viewer from a third, and expect them to interoperate with minimal custom code. "Minimal" — never zero, because conformance is a spectrum. That spectrum is why integration engineers still have jobs, and why our spec browser lists 4,800+ attributes across 174 CIODs.

What's inside a DICOM file

A DICOM file is much more than its pixel data. Open one and you'll find hundreds of tags describing the patient, the study, the series, the equipment, and the acquisition parameters — the metadata that lets a clinician trust the image they're reading. Pixels alone, without the metadata, are medically useless.

The information is organized into groups by theme:

  • Patient — name, ID (MRN), date of birth, sex (group 0010)
  • Study — Study Instance UID, date, time, description, referring physician (group 0008 + 0020)
  • Series — Series Instance UID, modality, body part examined (group 0020)
  • Image — SOP Instance UID, pixel spacing, rows/columns, bits allocated (group 0028)
  • Pixel Data — the actual image samples (group 7FE0)
  • Equipment — manufacturer, model, software version (group 0008)

Each tag has a Value Representation (VR) that dictates how it's encoded — dates are DA, person names are PN, UIDs are UI, pixel data is OB or OW. If you're mapping DICOM into any other system, VRs are what you parse against.

Browse the full data dictionary: all 4,818 DICOM tags →

How DICOM devices talk to each other

The network side of DICOM uses a handful of service classes — each a defined way one device can ask another to do something:

  • C-STORE — "Here is an image, please store it." The workhorse: modalities send images to PACS this way.
  • C-FIND — "Show me all studies matching these criteria." Workstations use this to query PACS.
  • C-MOVE — "Send these studies to this AE Title." How a workstation pulls prior studies from archive.
  • C-GET — Alternative to C-MOVE that avoids the firewall/routing complexity of C-MOVE at the cost of needing the same association open.
  • C-ECHO — "Are you there?" The DICOM equivalent of ping.

Deep-dive: service classes → and query/retrieve →

DICOM vs JPEG vs other image formats

A DICOM file can internally use JPEG, JPEG 2000, RLE, or uncompressed encodings for its pixel data — these are called transfer syntaxes. But DICOM is not a replacement for JPEG any more than MP4 is a replacement for WAV: it's a container standard that wraps image data plus the metadata, provenance, and patient context that medical imaging demands. Rename a .dcm to .jpg and you'll confuse your operating system; you won't produce a viewable image.

DICOM and PACS — not the same thing

PACS (Picture Archiving and Communication System) is an architecture; DICOM is the language that architecture speaks. A PACS is the archive and distribution layer: it receives images from modalities, stores them, and serves them to workstations. DICOM is how those transactions happen on the wire. You can't have a modern PACS without DICOM, but you can have DICOM without PACS — for example, a direct modality-to-workstation connection, or a DICOM-to-cloud gateway like AWS HealthImaging.

Separate explainer: PACS and VNAs →

DICOM and FHIR — complementary, not competing

FHIR is HL7's modern healthcare API standard and it has an ImagingStudy resource that references DICOM studies by their Study Instance UID. Rather than replacing DICOM, FHIR typically wraps it: a FHIR server carries the administrative metadata and pointers; the actual pixel data stays in a DICOM archive (retrieved via DICOMweb — WADO-RS / QIDO-RS / STOW-RS — which is DICOM over HTTP). The mapping is well-defined.

Full mapping: DICOM ↔ FHIR ImagingStudy →

Who maintains DICOM

The DICOM Standards Committee, housed at NEMA, maintains the standard. Updates ship roughly annually; each edition carries a year + letter suffix (2024a, 2024b, 2025a…). New content arrives via Supplements (major additions, e.g., Enhanced CT Image Storage in Sup 11) and Change Proposals (CPs; bug fixes and clarifications). You can download the full standard from dicomstandard.org as a set of XML and PDF files organized by Part.

Learn more: DICOM standard parts →

Explore further