DICOM Explained: How Medical Images Are Stored, Moved and Shared in 2026

Feb 10, 2010 | Updated on Sep 12, 2026

Introduction

This is the opening article of my series on the DICOM standard. I first wrote it in 2010 around screenshots of a Mac-only viewer, which made sense at the time and has made progressively less sense every year since. This is a full rewrite for 2026: no tool dependencies, the same fundamentals, and the context you need to work with medical imaging today - including the parts of the standard (DICOMweb, cloud archives, structured and AI-generated objects) that did not exist or did not matter when the original was written.

Who this is for: software developers, integration engineers, architects and analysts who are about to work with medical images for the first time - building or connecting a PACS, a viewer, a modality, an AI pipeline, a research archive, or an interface between imaging and the rest of the hospital. No radiology background is assumed. If you already know HL7 v2, you will find the two standards are complementary and are almost always deployed together.

The short version

DICOM is both a file format and a network protocol. The same standard defines what a CT slice looks like on disk and how a scanner sends it to an archive.
Every image carries its own metadata - patient, study, equipment, acquisition parameters, pixel encoding - as tagged data elements. There is no separate database record; the file is self-describing.
Images are organized in a fixed hierarchy: Patient → Study → Series → Instance, each level identified by a globally unique identifier (UID).
Systems talk to each other as service class users and providers (SCU/SCP) using a small set of operations: C-STORE to send, C-FIND to query, C-MOVE/C-GET to retrieve, plus worklist and status services for workflow.
DICOMweb exposes the same data over HTTP/REST (QIDO-RS, WADO-RS, STOW-RS) and is how modern viewers, cloud archives and AI services connect.
DICOM handles images and imaging workflow. Orders, demographics, billing and reports outside radiology are HL7 v2 and FHIR; IHE profiles specify how the three fit together.

“We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” ~ Frank Tibolt

What DICOM Is

DICOM stands for Digital Imaging and Communications in Medicine. It was created jointly by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) to solve a problem that will sound familiar if you have read about HL7: by the early 1980s every scanner vendor stored and transmitted images in its own proprietary format, so a hospital that bought a GE CT and a Siemens MRI could not view both on the same workstation, let alone archive them together. The first joint standard, ACR-NEMA 300, was published in 1985; the version we use today, DICOM 3.0, arrived in 1993 and has been continuously revised since - the standard is now republished several times a year, and the "3.0" is never incremented.

Today DICOM governs essentially every clinical image produced anywhere in the world: CT, MRI, ultrasound, X-ray (CR/DX), mammography, nuclear medicine, PET, angiography, endoscopy, ophthalmology, dermatology, digital pathology whole-slide images, radiotherapy planning data, ECG waveforms, and the reports, annotations, measurements and segmentations derived from them. If a hospital owns it and it produces a picture, it speaks DICOM.

The standard is big, but you only need a few parts

The standard is published as a set of numbered parts, "PS3.1" through "PS3.22" (two are retired), and the total runs to several thousand pages. That intimidates newcomers unnecessarily. In practice, a developer lives in five of them:

Part	Title	What you use it for
PS3.3	Information Object Definitions	Which attributes a CT image (or MR, SR, RT Plan…) must, should, or may contain
PS3.4	Service Class Specifications	How C-STORE, C-FIND, worklist, storage commitment etc. behave
PS3.5	Data Structures and Encoding	How data elements, value representations and transfer syntaxes are encoded on the wire and on disk
PS3.6	Data Dictionary	The master list of every tag: (0010,0010) is Patient’s Name, and so on
PS3.18	Web Services	DICOMweb: QIDO-RS, WADO-RS, STOW-RS, UPS-RS

PS3.7 and PS3.8 (message exchange and network support) matter if you are writing a DICOM toolkit from scratch, which you should not; PS3.10 covers the file format and media; PS3.15 covers security and de-identification profiles; PS3.2 tells you how to read and write a conformance statement. Everything is freely available online, and the HTML edition is searchable - bookmark it.

One Imaging Workflow, End to End

The easiest way to understand what the standard does is to follow a single patient through a scan and watch which system talks to which, and using what. A patient arrives at the emergency department with chest pain; the attending physician orders a CT of the chest.

The order. The physician places the order in the hospital information system (HIS) or EHR. It reaches the Radiology Information System (RIS) as an HL7 v2 order message. Nothing DICOM has happened yet.
The worklist. When the technologist at the CT scanner is ready, the scanner asks the RIS "what is scheduled for me?" using the Modality Worklist service. The RIS returns the patient's name, ID, date of birth, the accession number and the requested procedure. The technologist selects the entry and every image acquired from that point on is stamped with those identifiers automatically - no retyping, no transposed digits in the MRN. This one service eliminates the single largest source of wrong-patient errors in imaging.
Procedure status. As scanning starts and finishes, the scanner tells the RIS via Modality Performed Procedure Step (MPPS): "I have started", then "I am done, here is what I acquired, here is the radiation dose". The RIS can update the schedule and billing can begin.
Storage. The scanner reconstructs the raw data into a study of several hundred images and pushes each one to the Picture Archiving and Communication System (PACS) - or its enterprise-wide cousin, the Vendor Neutral Archive (VNA) - using C-STORE.
Commitment. The scanner has limited local disk. Before it deletes its copy, it asks the PACS to commit: "confirm you have durably stored these specific instances." Only after the PACS confirms does the scanner free the space.
Reading. The radiologist's workstation queries the PACS for the study (C-FIND) and retrieves it (C-MOVE or C-GET), often together with prior studies for comparison.
Results. The radiologist's measurements, annotations and key images go back to the PACS as DICOM objects - a Structured Report, a Presentation State, a Key Object Selection.
The report. The narrative report is dictated, signed in the RIS, and sent to the EHR as an HL7 v2 result message, where the ordering physician reads it - with a link that opens the images in a viewer, usually over DICOMweb.

Keep this workflow in mind; every service in the rest of this article exists to make one of these steps work. Marc Kohli's video walks through the same workflow from a radiologist's point of view and remains the clearest introduction I know of.

The Information Model: Patient, Study, Series, Instance

DICOM organizes everything into a four-level hierarchy. You will meet it in file directories, in queries, in every viewer's browser panel, and in the design of every archive:

A study corresponds to one order - the CT chest. It might contain several series: the scout image, the axial slices at 1 mm, a coronal reconstruction, a bone-window reconstruction of the same raw data. Each series is a set of instances that belong together and share acquisition parameters; for a CT that is one instance per slice. A single modern CT study can be 1,000-3,000 instances; a digital pathology whole-slide image can be a single multi-gigabyte instance. Since 2010 the standard has been steadily moving toward enhanced multi-frame objects, where an entire series is one instance containing many frames - which is much more efficient but which many older systems still cannot read, so the classic one-file-per-slice form remains the most common thing you will encounter.

UIDs

Study, series and instance are each identified by a Unique Identifier (UID): a string of numbers and dots, at most 64 characters, that must be globally unique for all time - not unique within your system, unique in the world. The format is an ISO object identifier: an organization root you own (registered, or the 2.25. UUID-derived form that anyone may use) followed by a suffix your software generates. For example:

2.25.313883226845173485927643140962784351   (a Study Instance UID)
1.2.840.10008.5.1.4.1.1.2                   (a well-known UID: the CT Image Storage SOP Class)

Every UID beginning 1.2.840.10008 is defined by the standard itself - SOP classes, transfer syntaxes, well-known frames of reference. Everything else was minted by a vendor's or a hospital's software. Two rules save enormous pain: never generate UIDs by hand or by copy-paste, and never change an instance's UID unless you have changed its content (then you must). Archives use them as primary keys, and duplicated UIDs are the cause of a large fraction of "the images disappeared" incidents.

Inside a DICOM File

A DICOM file is a data set: an ordered list of data elements, each identified by a tag, and one of those elements happens to be the pixel data. There is no header in the conventional sense - the "header" people refer to is just every element that is not (7FE0,0010) Pixel Data. Here is what a CT slice looks like when dumped with any toolkit (the format below is DCMTK's dcmdump; every library has an equivalent):

(0002,0010) UI [1.2.840.10008.1.2.1]                       # TransferSyntaxUID (Explicit VR Little Endian)
(0008,0016) UI [1.2.840.10008.5.1.4.1.1.2]                 # SOPClassUID (CT Image Storage)
(0008,0018) UI [2.25.281474976710656123456789012345678]    # SOPInstanceUID
(0008,0020) DA [20260912]                                  # StudyDate
(0008,0050) SH [ACC2026091200042]                          # AccessionNumber
(0008,0060) CS [CT]                                        # Modality
(0008,0070) LO [Example Imaging Corp]                      # Manufacturer
(0010,0010) PN [DOE^JANE^A]                                # PatientName
(0010,0020) LO [MRN123456]                                 # PatientID
(0010,0030) DA [19780415]                                  # PatientBirthDate
(0010,0040) CS [F]                                         # PatientSex
(0020,000D) UI [2.25.313883226845173485927643140962784351] # StudyInstanceUID
(0020,000E) UI [2.25.176589442917735841609587732811849903] # SeriesInstanceUID
(0020,0013) IS [17]                                        # InstanceNumber
(0020,0032) DS [-250\-250\-112.5]                          # ImagePositionPatient
(0028,0002) US 1                                           # SamplesPerPixel
(0028,0010) US 512                                         # Rows
(0028,0011) US 512                                         # Columns
(0028,0100) US 16                                          # BitsAllocated
(0028,1050) DS [40]                                        # WindowCenter
(0028,1051) DS [400]                                       # WindowWidth
(7FE0,0010) OW 0000\0000\0000\0000...                      # PixelData (524288 bytes)

Read one line and you have the whole encoding model:

Tags, VRs and the dictionary

A tag is a pair of 16-bit numbers, (group, element), written in hexadecimal. The data dictionary (PS3.6) maps every standard tag to a name, a value representation (VR) and a multiplicity. The VR is a two-letter data type: PN person name, DA date (YYYYMMDD), TM time, UI UID, LO long string, CS code string, IS integer string, DS decimal string, US unsigned short, OB/OW other byte/word (binary), SQ sequence - a nested list of data sets, which is how DICOM represents structure (a list of referenced images, the items in a structured report). Multiple values in one element are separated by a backslash, which is why ImagePositionPatient above reads -250\-250\-112.5. Person names use ^ between components exactly as HL7 does, because DICOM borrowed the convention.

Transfer syntaxes

The transfer syntax - element (0002,0010) - declares how the data set is encoded: byte order, whether VRs are written explicitly, and how the pixel data is compressed. You will meet these constantly:

Transfer syntax	UID	Notes
Implicit VR Little Endian	1.2.840.10008.1.2	The default every implementation must support. VRs are looked up in the dictionary, not stored.
Explicit VR Little Endian	1.2.840.10008.1.2.1	The most common in practice. VRs stored inline. Required for file meta information.
JPEG Baseline (8-bit lossy)	1.2.840.10008.1.2.4.50	Ultrasound, endoscopy, visible-light photos.
JPEG Lossless	1.2.840.10008.1.2.4.70	Widely supported lossless compression for CT/MR/CR.
JPEG-LS Lossless	1.2.840.10008.1.2.4.80	Faster lossless; common in newer archives.
JPEG 2000 Lossless / Lossy	1.2.840.10008.1.2.4.90 / .91	Common in VNAs and web viewers; supports progressive decoding.
High-Throughput JPEG 2000	1.2.840.10008.1.2.4.201-203	Added in 2021; much faster to decode, increasingly used by cloud archives and web viewers.
RLE Lossless	1.2.840.10008.1.2.5	Simple run-length; older ultrasound and some workstations.

Two consequences for developers. First, any software that receives images must be prepared to transcode - decompress JPEG 2000 into raw pixels for display, or recompress for storage - and the transfer syntaxes it supports are part of the association negotiation described below. Second, "lossy" is a clinical decision, not just a technical one: lossy-compressed images carry a LossyImageCompression flag and many jurisdictions restrict their use for primary diagnosis. I cover the details in the transfer syntax article.

The pixels

Pixel data is described by group 0028: rows, columns, samples per pixel (1 for grayscale, 3 for color), bits allocated/stored, photometric interpretation (MONOCHROME2, RGB, YBR...), and - for CT - a rescale slope and intercept that convert stored values to Hounsfield units, plus a window center/width that says which range of those values to map to the screen. A CT slice is not a picture; it is a 16-bit measurement grid, and how it looks depends entirely on the window applied. That is why the same slice can show lungs, soft tissue or bone. Any viewer you write must implement this pipeline; the making sense of the DICOM file and image extraction articles show how.

Network Services: SCUs, SCPs and SOP Classes

DICOM networking is built on a client/server vocabulary that is worth learning precisely, because conformance statements, configuration screens and error logs all use it.

A Service Class is a group of related operations - Storage, Query/Retrieve, Worklist Management, Print Management.
A Service Class Provider (SCP) performs the service; a Service Class User (SCU) requests it. A PACS is a Storage SCP (it accepts images) and a Query/Retrieve SCP (it answers queries). A scanner is a Storage SCU (it sends images) and a Worklist SCU (it asks for the schedule). Most real systems are both SCU and SCP for different services.
An Information Object Definition (IOD) is the template for one kind of object - CT Image, MR Image, Basic Text SR, Segmentation.
A Service-Object Pair (SOP) Class is one service applied to one IOD: CT Image Storage, Modality Worklist Information Model - FIND, Storage Commitment Push Model. Each has a UID. A SOP Instance is one concrete object - slice 17.
An Application Entity (AE) is a DICOM endpoint, identified by an AE Title (up to 16 characters, e.g. PACS_MAIN), a host and a port. Ports 104 and 11112 are the conventional ones.

The association

Before anything is exchanged, the SCU opens an association with the SCP: a negotiation in which the SCU proposes a list of presentation contexts - "I would like to send CT images in Explicit VR Little Endian or JPEG Lossless; I would like to send MR images in..." - and the SCP accepts or rejects each one. The SCP will also reject the whole association if it does not recognize the calling AE title (most PACS require every peer to be pre-registered), which is the single most common reason a new connection fails. Once the association is open, the operations below run over it, and it is released when done. The association negotiation article goes through this byte by byte; the verification service, C-ECHO, is the "ping" you use to test that two AEs can associate at all.

The operations

Operation	Type	What it does	Where it appears in the workflow
C-ECHO	DIMSE-C	Verification: “are you there and do you speak DICOM?”	Every troubleshooting session
C-STORE	DIMSE-C	Push one SOP instance to the SCP	Scanner → PACS; workstation → PACS; PACS → PACS
C-FIND	DIMSE-C	Query by matching attributes at the patient/study/series/instance level; SCP returns matching identifiers	Workstation queries PACS; scanner queries worklist
C-MOVE	DIMSE-C	”Send these instances to AE title X” - the SCP opens a new association to X and C-STOREs them	Workstation retrieves from PACS (historically dominant)
C-GET	DIMSE-C	Same as C-MOVE, but instances come back on the same association	Retrieval through firewalls/NAT; increasingly preferred
N-CREATE / N-SET	DIMSE-N	Create and update a managed object	MPPS; print jobs
N-ACTION / N-EVENT-REPORT	DIMSE-N	Request an action; asynchronous notification	Storage Commitment
N-GET	DIMSE-N	Read attributes of a managed object	Printer status

The C-MOVE versus C-GET distinction trips up everyone the first time. With C-MOVE, the PACS needs a route back to the destination AE - a configured entry with its IP and port, and a network path to it - so a laptop on a different subnet cannot simply "pull" a study. C-GET avoids this by sending the images back on the connection the client already opened, at the cost of being less widely supported by older archives. My three-part query/retrieve series (C-FIND, C-MOVE, C-GET) covers both with code.

Workflow services

Beyond moving images, three services glue imaging into the department's workflow, and all three are C-FIND or DIMSE-N under the hood:

Modality Worklist - a C-FIND against the RIS that returns scheduled procedure steps. See the worklist article.
Modality Performed Procedure Step (MPPS) - N-CREATE when the scan starts, N-SET to COMPLETED or DISCONTINUED when it ends, carrying the list of instances acquired and dose information. See the MPPS article.
Storage Commitment - N-ACTION with a list of UIDs; the archive answers, asynchronously, with N-EVENT-REPORT saying which it has safely stored. See the storage commitment article.

The newer Unified Procedure Step (UPS) service generalizes worklist and MPPS into a single work-item model and is the basis for AI and post-processing task queues; it is available over both classic DICOM and DICOMweb (UPS-RS).

Beyond Images: The Other Objects You Will Meet

Roughly half of the SOP classes in the standard are not images. The ones you are most likely to be asked to produce or consume:

Object	What it is	Typical producer
Structured Report (SR)	Coded, tree-structured findings and measurements - not free text. Basic Text, Enhanced, Comprehensive (3D), and specialized templates for mammography CAD, radiation dose (RDSR), ultrasound measurements	Workstations, AI algorithms, dose monitoring
Presentation State (GSPS / CSPS)	How to display an image - window, zoom, rotation, annotations - stored separately from the pixels so the original is never altered	Viewers
Key Object Selection (KOS)	A list of “the important images” with a reason code	Radiologists, for the referring physician
Segmentation (SEG)	Labelled pixel/voxel masks over a referenced image set - the standard output of AI models and contouring tools	AI services, 3D workstations
Parametric Map	Per-voxel quantitative values (perfusion, diffusion)	Advanced post-processing
RT Structure Set / Plan / Dose	Radiotherapy contours, treatment plan and computed dose	Radiotherapy planning systems
Encapsulated PDF / CDA	A document wrapped in DICOM so it travels with the study	Reporting systems, scanned consent forms
Waveform	ECG, hemodynamic and audio signals	Cardiology, sleep labs
Whole Slide Image (WSI)	Tiled, pyramidal multi-frame pathology slides, often gigabytes each	Digital pathology scanners

If you are integrating an AI model into a radiology workflow, you will almost certainly be producing SR, SEG or GSPS objects rather than images; I have articles on structured reports and segmentation with code.

DICOMweb: The Same Data Over HTTP

The classic DICOM protocol (formally DICOM Upper Layer over TCP, informally "DIMSE") is stateful, binary, and hostile to web browsers, load balancers and cloud infrastructure. Since 2013 the standard has defined an equivalent RESTful interface, DICOMweb (PS3.18), with three core services and a fourth for worklists:

Service	HTTP	Classic equivalent	Example
QIDO-RS (Query based on ID for DICOM Objects)	GET	C-FIND	`GET /studies?PatientID=MRN123456&ModalitiesInStudy=CT`
WADO-RS (Web Access to DICOM Objects)	GET	C-MOVE / C-GET	`GET /studies/{study}/series/{series}/instances/{instance}/frames/1`
STOW-RS (Store Over the Web)	POST	C-STORE	`POST /studies` with a multipart body of DICOM instances
UPS-RS	GET/POST/PUT	Worklist / MPPS	Work-item queues for AI and post-processing

Metadata comes back as JSON (the DICOM JSON model, which keeps tags and VRs but is otherwise ordinary JSON), and pixels can be requested as raw frames, as JPEG/JPEG 2000/HTJ2K, or as rendered images. Every zero-footprint web viewer (OHIF, Cornerstone-based viewers, the viewers embedded in EHRs), every cloud DICOM store (Google Cloud Healthcare API, AWS HealthImaging, Azure Health Data Services), and most AI inference platforms speak DICOMweb, usually with OAuth 2.0 bearer tokens in front. Inside the hospital, scanners and PACS still speak DIMSE; at the edge, it is DICOMweb. A modern archive offers both. The DICOMweb article in this series shows how to call each service; the older WADO-URI (a single GET with query parameters) still appears in EHR image links.

Security, Privacy and De-identification

Base DICOM has no authentication and no encryption; it was designed for a trusted departmental LAN. In production you should expect one of three things: DIMSE inside a VPN or isolated VLAN, DIMSE over TLS (PS3.15 defines the profiles and most toolkits and PACS support it), or DICOMweb over HTTPS with token-based authorization. AE title checking is an access-control convenience, not a security control.

Because every image carries the patient's identity in its own header, de-identification is a first-class problem - for research, for AI training, for teaching files, and for any data leaving the institution. PS3.15 Annex E defines the Basic Application Level Confidentiality Profile and its options: exactly which of the hundreds of identifying attributes to remove, replace or retain (dates, for instance, can be shifted rather than deleted so that intervals survive). Two traps: private tags (odd-numbered groups) can carry anything the vendor chose to put there, including names; and burned-in annotations - identity rendered into the pixels of an ultrasound or a secondary capture - cannot be removed by editing tags at all. I go into all of this in the anonymization and private tags articles.

Conformance Statements: How to Know What a System Can Do

"DICOM compliant" on its own means almost nothing - the standard is a menu, and each product picks from it. What tells you whether two systems will actually work together is each vendor's DICOM Conformance Statement, a document in the format prescribed by PS3.2 that every serious product publishes. Learn to read one; it is the first thing to ask for on any imaging integration project, and it answers, in order:

Which SOP classes it supports, and for each whether as SCU, SCP or both. If the archive does not list Enhanced CT Image Storage as an SCP and your scanner produces enhanced CT, the images will be rejected.
Which transfer syntaxes it accepts and proposes, per SOP class.
How it handles associations - how many in parallel, the maximum PDU size, timeouts, whether it initiates, whether it validates calling AE titles.
For query/retrieve: which query levels and matching keys it supports - a PACS that cannot match on ModalitiesInStudy or wildcard on patient name will frustrate your viewer.
Which character sets it handles - relevant the moment a patient's name is not ASCII (see the character set article).
Security: TLS support, and any DICOMweb endpoints.

DICOM, HL7, FHIR and IHE

DICOM deliberately stops at the edge of imaging. The order that started the workflow, the patient's demographics, the admission that created the encounter and the report that closes it are all HL7 v2 messages (ORM/OMG, ADT, ORU) - or increasingly FHIR resources (ServiceRequest, Patient, Encounter, DiagnosticReport). FHIR also defines an ImagingStudy resource that mirrors the Study/Series/Instance hierarchy and points at the images via DICOMweb URLs, which is how a patient-facing app or a clinical dashboard gets from "there is a CT" to the pixels; I cover this in DICOM and FHIR.

None of the three standards says how they combine. That is the job of IHE (Integrating the Healthcare Enterprise), whose radiology Scheduled Workflow profile is essentially the diagram at the top of this article written as a formal specification - which HL7 message triggers which DICOM service, with which identifiers copied where. If you are told a system is "IHE SWF compliant", the workflow above is what it promises to support; other IHE profiles cover cross-enterprise image sharing (XDS-I, XCA-I), web-based image access (WIA), and invoking a viewer from an EHR (IID).

Where to Go Next

This article is the map. The rest of the series is the territory, and it splits by language:

Concepts, chapter by chapter: my free 27-chapter DICOM tutorial - history, architecture, services, workflow, DICOMweb, FHIR integration, testing tools, troubleshooting and enterprise PACS issues, with quizzes.
Write code in Java: the DICOM Basics using Java series (PixelMed and dcm4che) - reading and creating files, extracting pixels, viewing, DICOMDIR, C-ECHO, associations, C-FIND/C-MOVE/C-GET, C-STORE, storage commitment, worklist, MPPS, print, SR, transfer syntaxes, character sets, private tags, anonymization, digital signatures, TLS, encapsulated documents, presentation states, segmentation, RT, waveforms and DICOMweb.
Write code in .NET: the DICOM Basics using .NET series (fo-dicom) covering the same ground in C#.
Set up a test server: Orthanc is free, cross-platform, has a web UI and a DICOMweb plugin, and is what the networking examples in this series talk to. Pair it with DCMTK's command-line tools (echoscu, storescu, findscu, dcmdump) and you have a complete lab on a laptop.
The neighbours: HL7 v2, FHIR, IHE, and coded vocabularies (SNOMED CT, LOINC, RadLex), which structured reports depend on.
Test yourself: the DICOM quiz and the medical imaging basics quiz.

If you work with DICOM, HL7 or FHIR and want to compare notes with other engineers doing the same, join the discussion in my LinkedIn group on healthcare interoperability engineering - questions, war stories and conformance-statement horror stories welcome.