DICOM (Digital Imaging and Communications in Medicine) is the standard that lets a CT, an MR, an ultrasound, and a workstation from four different vendors agree on what a study is. It is a file format, a network protocol, and a data language. One without the others is a pile of pixels with no address, or a protocol with nothing to carry.
If you meant the .dcm file (tags, extension, why it is huge) → what is a DCM file. If you meant read a file in Python → how to read DICOM files. If you meant PACS, the library those files live in → PACS and DICOM. If you meant open a file in a viewer → how to open a DCM file / DICOM viewer software. If you meant DICOM↔NIfTI convert → DICOM to NIfTI. If you meant imaging software to buy → medical imaging software.
DICOM at a glance
| Component | Job | Analogy |
|---|---|---|
File format (.dcm) |
One object: pixels plus the header that names the patient, the study, and the machine | A folder that holds the photo and the chart |
| Network protocol | How a modality sends a study and how a workstation asks for it | The postal rules, not the letter |
| Data structure | Standardized tags — (0010,0010) is always Patient’s Name |
The fields on a form, not free text |
| Conformance | A device publishes which SOP Classes it supports. Two boxes talk only where those lists overlap | A shared grammar, not a handshake by brand |
A JPEG is a picture. A DICOM object is a medical record that happens to contain a picture. The header is not optional decoration.
How it got here
Before a shared standard, every scanner spoke a vendor language. An MR from one company would not open on another company’s station. ACR and NEMA published the first ACR-NEMA standard in 1985. It was point-to-point. DICOM 3.0 in 1993 put the same objects on TCP/IP — the network hospitals already had — and that is the line the industry still stands on. Official docs live at dicomstandard.org.
What is inside one object
A DICOM file is a 128-byte preamble, the four letters DICM, then a list of data elements. Each element is a tag, a value representation, and a value. Pixel data is one of those elements. Everything else is why a radiologist can trust the image is Sarah’s CT from Tuesday, not a nameless PNG.
Studies are not a flat folder of files. DICOM files them as Patient → Study → Series → Image. One patient, many studies; one study, many series (an MR T1 and a T2 are two series); one series, many instances (the slices). That hierarchy is how a PACS answers “show me last year’s chest CT,” not “open every file in Downloads.”
Two more names you will see and then ignore on this page: an IOD (Information Object Definition) is the blueprint for a kind of object — a CT Image is not a Segmentation. A SOP Class pairs that blueprint with a service (store, find, move). Conformance statements list SOP Classes. They are not a reason to write a protocol how-to here.
File and protocol are the same standard
On disk the object is usually a .dcm (sometimes no extension at all). On the wire, DIMSE is how DICOM messages move; C-STORE, C-FIND, C-MOVE, C-ECHO are the verbs. This page names them so the protocol skin of “what is DICOM” has somewhere to land. It does not teach association negotiation or write a C-STORE client. The archive those verbs talk to is PACS and DICOM. The file on disk is what is a DCM file.
DICOMweb (QIDO / WADO / STOW) is the same job over HTTP. A browser viewer is still reading DICOM objects. It is not a second standard.
Scanner to specialist
A patient is on the CT. The scanner writes instances — pixels, demographics, Study Instance UID, pixel spacing — and sends them. The PACS files them against the patient. A radiologist queries and hangs the study. A web viewer does the last mile in a browser. The Modality Worklist exists so a tech does not re-type a name the RIS already has. That handshake is integration, not this definition.
DICOM started in radiology. It now covers cardiology, pathology slides, ophthalmology, dentistry, and more. The object types change. The idea does not: one standard so the image and its context travel together.
FAQ
Is DICOM a file format or a protocol?
Both. The file is how an instance sits on disk. The protocol is how it moves. A .dcm you email and a C-STORE you send to a PACS are the same object model. If you only care about the extension and the tags, use what is a DCM file.
DICOM vs PACS?
DICOM is the language. PACS is the library. You can have DICOM files on a USB stick with no PACS. You cannot have a useful PACS that does not speak DICOM. The systems page is PACS and DICOM.
Why not a JPEG?
A JPEG drops the header — patient, laterality, window, spacing, the UID that says this slice belongs to that series. A photo viewer also cannot apply a CT window. You need a DICOM viewer, or you read the file in Python.
Is this only radiology?
No. Radiology is still the largest pile. The standard’s scope is “any image that has to stay tied to a patient and a procedure.”
PYCAD builds viewers and pipelines on top of this standard. Case studies.