The Invisible Standard Underpinning Medical Imaging
Every time a radiologist reads a CT scan, every time a cardiologist reviews an echocardiogram, every time a pathologist views a whole-slide image — the data they are looking at almost certainly arrived in their hands via DICOM. It is one of the most pervasive standards in healthcare IT, yet few clinicians or administrators have more than a vague awareness of what it actually is.
DICOM — Digital Imaging and Communications in Medicine — is both a file format and a network communication protocol. It defines how medical images are stored, how they are transmitted between systems, and how associated metadata (patient identity, study details, technical acquisition parameters) is attached to and travels with the image data. Without DICOM, the modern radiology workflow — and by extension, most diagnostic medicine — would not function.
A Brief History
DICOM emerged from a collaboration between the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) in the early 1980s. The original motivation was straightforward: imaging equipment from different manufacturers used entirely proprietary file formats, making it impossible to move images between systems without expensive custom software.
The first standard, ACR-NEMA 1.0, was published in 1985. DICOM 3.0 — the version that remains the foundation of the standard today — was released in 1993. Since then, it has been maintained by the DICOM Standards Committee and updated continuously to accommodate new modalities, new use cases, and new technical requirements.
Today, DICOM is used by virtually every medical imaging device manufacturer globally. It covers modalities including radiography (X-ray), computed tomography (CT), magnetic resonance imaging (MRI), ultrasound, positron emission tomography (PET), mammography, nuclear medicine, endoscopy, ophthalmology, and digital pathology.
How DICOM Works
The File Format
A DICOM file is not simply an image. It is a structured dataset that combines pixel data with a rich set of metadata tags. Each tag is identified by a group number and element number, and the full collection of tags for a given image type constitutes an Information Object Definition (IOD).
A DICOM image of a chest X-ray, for example, contains not only the pixel matrix of the image but also tags encoding the patient's name and ID, the study date and time, the referring physician, the imaging modality, the X-ray tube voltage and current, the radiation dose, the body part examined, and much more. This rich metadata makes DICOM files self-describing — a receiving system can interpret the image and understand its clinical context without needing separate documentation.
SOP Classes
DICOM organises its objects and services into Service-Object Pair (SOP) classes. Each SOP class defines a specific type of DICOM object (such as a CT image, an ultrasound video, or a structured report) and the services that can be performed on it (such as Storage, Query/Retrieve, or Print).
When two DICOM systems connect, they negotiate which SOP classes they both support through a process called presentation context negotiation. This is why DICOM conformance statements — documents published by equipment manufacturers detailing which SOP classes their products support — are essential reading when planning integrations.
The Network Protocol
DICOM defines its own network protocol, built on top of TCP/IP, for transmitting images and commands between systems. The key DICOM network services include:
- C-STORE: Sending images from one system to another (e.g., a CT scanner sending images to a PACS)
- C-FIND: Querying a system for matching studies or series
- C-MOVE: Requesting that a system send images to a third party
- C-GET: Requesting that images be sent back to the requestor
- DICOM Web (DICOMweb): A more modern set of RESTful services (WADO, STOW-RS, QIDO-RS) that enable DICOM interactions over standard HTTP, making integration with web applications and cloud platforms far easier
The shift towards DICOMweb is significant: it allows cloud-native imaging platforms, AI applications, and zero-footprint viewers to interact with DICOM data without requiring traditional DICOM networking infrastructure.
DICOM vs Proprietary Formats
Before DICOM's widespread adoption, every imaging manufacturer had its own proprietary format. Siemens images could not easily be read on a Philips workstation. A hospital that changed CT vendors would lose the ability to display its historical images natively.
DICOM solved this — but only partially. The standard defines a common framework, but implementations vary. Manufacturers can include private tags — custom metadata not defined in the standard — for proprietary features. Some DICOM files produced by certain devices require vendor-specific codecs to decode correctly. And the standard is large and complex enough that no two implementations support exactly the same set of features.
This is why DICOM conformance testing and conformance statement review remain essential steps in any imaging system procurement. "DICOM compliant" is not a single binary certification — it describes a degree of compliance with a large and multifaceted standard.
Integration with PACS, RIS, and EHR
DICOM does not operate in isolation. In a functioning radiology department, it works alongside several other systems:
PACS (Picture Archiving and Communication System) is the central repository for DICOM images. Scanners transmit images to the PACS via C-STORE. Radiologists retrieve images from the PACS using C-FIND and C-MOVE or via a DICOMweb viewer.
RIS (Radiology Information System) manages the workflow around imaging: scheduling, order management, and reporting. The RIS and PACS exchange data using both HL7 messaging (for orders and reports) and DICOM (for worklist management via the DICOM Modality Worklist service, which delivers patient and study information to imaging devices so they do not need to be manually programmed).
EHR integration typically involves attaching DICOM study links or embedded viewers to the patient's clinical record, so clinicians outside radiology can access relevant images in context. Standards such as IHE XDS-I (Cross-Enterprise Document Sharing for Imaging) define how this should work in a standardised way.
Common Challenges in DICOM Deployments
Despite being the universal standard, DICOM deployments regularly encounter significant problems:
Character set and encoding issues arise when patient names contain non-ASCII characters. DICOM supports various character sets, but inconsistent encoding across systems produces corrupted or truncated names — a patient safety risk.
Patient matching across systems is error-prone when patient identifiers differ between the PACS, RIS, and EHR. A patient registered as "Mohammed Al-Rashid" in one system and "M. Alrashid" in another may appear as two different people, with studies potentially linked to the wrong record.
Large file sizes — a single abdominal CT with 1,000 or more slices can run to several gigabytes — create challenges for storage, transmission, and archiving. Long-term DICOM archiving requires a considered strategy for storage tiering (fast storage for recent studies, cheaper nearline or cloud storage for older ones).
Legacy media — old studies stored on CD-ROMs or DVDs in pre-PACS DICOM format — present migration challenges when hospitals move to new platforms. DICOM is backwards compatible, but import workflows for legacy media require careful testing.
Cybersecurity is an increasingly serious concern. DICOM systems have historically operated on closed hospital networks, but the shift towards cloud-based PACS and teleradiology has exposed them to the broader internet. Many older DICOM implementations lack encryption and authentication. Organisations must ensure DICOM traffic is secured appropriately and that PACS systems are included in their vulnerability management programmes.
FZ Consulting LLP provides advisory services for medical imaging IT infrastructure, including PACS procurement, DICOM integration architecture, and teleradiology implementations. Contact our team to discuss your imaging informatics requirements.