What Is DICOM? A Complete Guide to the Medical Imaging Standard and File Format

DICOM (Digital Imaging and Communications in Medicine) is the international standard that defines how medical images and associated patient data are stored, transmitted, and exchanged among imaging devices, picture archiving and communication systems (PACS), and electronic health records. The standard governs both the file format that holds medical image data (the .dcm file you might receive on a CD or USB drive after an imaging study) and the network protocols that move those files between systems. DICOM was first introduced in 1985 and remains the universal standard for medical imaging across CT, MRI, X-ray, ultrasound, mammography, and every other clinical imaging modality used worldwide.

What is DICOM? The medical imaging standard explained

DICOM is two things in one. As a file format, it’s a structured container that holds medical image pixel data, along with patient demographics, study details, modality information, and acquisition parameters needed for clinical interpretation. As a communications protocol, it’s the standardized way that imaging devices, archives, and viewing workstations exchange those files across hospital networks. The standard exists because medical imaging needs to work the same way regardless of which manufacturer made the scanner, which vendor runs the PACS, or which software the radiologist uses to read the study.

The standard is maintained by the Medical Imaging and Technology Alliance (MITA), a division of the National Electrical Manufacturers Association (NEMA). It develops through a multi-stakeholder process involving imaging equipment manufacturers, software vendors, clinical professional societies, and healthcare institutions. New parts of the standard get added as imaging technology evolves, and existing parts get refined as the community identifies gaps or ambiguities. DICOM is published in over 20 parts covering different aspects of the standard, from data structures to network communications to media exchange.

Three core concepts define how DICOM works in practice.

• First, every piece of information in a DICOM file is identified by a unique tag (a Group-Element pair, such as (0010,0010) for patient name), which allows software to locate and read specific data fields without parsing the entire file.
• Second, DICOM defines a set of Information Object Definitions (IODs) that specify the data required for each imaging study type (a chest CT IOD differs from a mammography IOD).
• Third, DICOM specifies Service Classes (the network operations) that move imaging data between systems, including Store (sending a study to PACS), Find (querying for studies), and Move (retrieving studies from an archive).

Every modern imaging modality outputs DICOM. CT scanners, MRI machines, X-ray units, ultrasound systems, mammography units, PET scanners, nuclear medicine cameras, fluoroscopy units, and digital radiography systems all produce DICOM files as their native output format. This universality is what makes DICOM the practical backbone of medical imaging — a radiologist can read a study acquired on any vendor’s scanner using any compatible viewer, because the underlying data format is identical.

The DICOM file format explained

A DICOM file uses the .dcm file extension and contains two main sections: a header that holds metadata about the study, and the pixel data that contains the actual image. Unlike standard image formats (JPEG, PNG, GIF), which contain only visual data and minimal metadata, a DICOM file embeds extensive clinical and technical context directly within the file. This is what allows a DICOM file to travel between systems without losing the patient identity, study context, and acquisition parameters that are essential for diagnostic interpretation.

The DICOM file structure follows a defined sequence. The file begins with a 128-byte preamble (typically all zeros, used by some operating systems for file type identification), followed by the four-character DICOM magic number “DICM” that identifies the file as DICOM-formatted. After the magic number comes the File Meta Information (which describes the file itself—what transfer syntax it uses and what software wrote it), followed by the dataset containing the actual study data. The dataset is structured as a sequence of data elements, each consisting of a tag, a value representation (VR), a value length, and the value itself.

DICOM file sizes vary dramatically by DICOM modality. A single intraoral dental X-ray might be 1-3 MB. A standard chest X-ray runs 5-15 MB. A CT scan with several hundred slices reaches 100-500 MB. An MRI study with multiple sequences can exceed 1 GB. A cone beam CT or modern OCT volume sits in the 100-500 MB range. The cumulative storage burden across a busy imaging center generates terabytes of DICOM data annually, which is the primary driver behind cloud-native PACS adoption.

DICOM tags are organized into Groups and Elements, written in hexadecimal format, such as (0010,0010) for the patient name or (0008,0018) for the unique study instance UID. Each tag has a defined data type (Value Representation or VR) that tells software how to interpret the value — PN for person name, DA for date, UI for unique identifier, OB for other byte string (often used for pixel data), and so on. The DICOM standard publishes a complete data dictionary that maps every standardized tag to its VR, name, and meaning.

Common DICOM file operations include opening (using a DICOM viewer or compatible imaging software), converting (to standard formats like PNG or JPEG for non-clinical use, though this loses the metadata), anonymizing (removing or replacing patient-identifying tags before sharing for research or teaching), and validating (checking that the file conforms to the DICOM standard). Anonymization is particularly important in clinical research and educational contexts where DICOM files need to be shared without disclosing patient identity. Specialized tools and viewers handle anonymization by replacing or removing the patient demographic tags while preserving the imaging data and study context.

For practical viewing of DICOM files, see Medicai’s best DICOM viewers comparison covering free desktop viewers, web-based viewers, and diagnostic-grade clinical viewers.

How the DICOM standard works: services, protocols, and network

The DICOM standard goes beyond file format to define how imaging systems communicate with each other. The network communication layer is what allows a CT scanner in one department to send images to a central PACS, a radiologist’s workstation to query the PACS for prior studies, and a teleradiology platform to receive studies from a remote hospital — all using the same standardized protocols regardless of which vendors made each system.

DICOM services define the operations that imaging systems perform on each other. Storage services (C-STORE in classic DIMSE protocols) handle the transfer of a study from one system to another, typically from a modality to PACS. Query services (C-FIND) allow one system to search another for studies that match specific criteria— such as patient name, date range, modality, and accession number. The Retrieve services (C-MOVE and C-GET) allow one system to request that another send specific studies. Print services handle sending images to DICOM-compatible printers and film recorders. Modality Worklist (MWL) services let imaging devices query the hospital information system for the patient and study context of a scheduled exam, eliminating manual data entry at the scanner.

The classic DICOM communication protocols run over dedicated TCP ports (typically 104 or 11112) using DIMSE (DICOM Message Service Element) services. Each DICOM-capable device maintains an Application Entity (AE) Title that identifies it on the network — a CT scanner might have an AE Title of “CT_SCANNER_1,” a PACS might be “MAIN_PACS,” and so on. Devices establish associations between AE Titles to perform DICOM services on each other. This architecture worked well for traditional hospital networks where every device sat on the same internal network, but it doesn’t translate cleanly to cloud-based or multi-site architectures.

DICOMweb (also known as Web Services for DICOM) is the modern evolution of DICOM communication. Introduced in DICOM Part 18, DICOMweb implements the same conceptual services over standard HTTPS rather than DIMSE — WADO-RS replaces classic retrieval, QIDO-RS replaces classic query, and STOW-RS replaces classic store. The advantages are significant: DICOMweb operates over standard web protocols, traverses firewalls cleanly, supports REST-based queries that integrate naturally with modern cloud architectures, and enables browser-based viewers without the network engineering overhead required by DIMSE. New DICOM deployments increasingly default to DICOMweb, while legacy DIMSE remains common in established systems for backward compatibility.

For deeper coverage of how DICOM integrates with PACS workflows, see Medicai’s PACS integration and workflow guide.

DICOM tags and metadata: what’s inside a DICOM file

DICOM tags are the structured metadata fields inside every DICOM file. Each tag carries a specific piece of information about the patient, the study, or the imaging acquisition, and software reads tags to display, route, archive, or process the file appropriately. There are over 4,000 standardized tags defined in the DICOM data dictionary, plus vendor-specific private tags that imaging manufacturers add for proprietary use.

Patient-level tags identify who the imaging study belongs to. Patient name (0010,0010), patient ID (0010,0020), patient birth date (0010,0030), and patient sex (0010,0040) are the most commonly referenced patient tags. These tags are the ones that get replaced during anonymization for research or teaching use, since they directly identify the patient.

Study-level tags describe the imaging study as a whole. Study instance UID (0020,000D), the unique identifier for the study; study date (0008,0020), the study date; study description (0008,1030), the study description; accession number (0008,0050), linking the study to the hospital information system order; and referring physician name (0008,0090), all study-level tags. These tags help systems track the study across its lifecycle from ordering through reading to the archive.

Series-level and image-level tags describe the imaging acquisition itself. Series description (0008,103E), modality (0008,0060) identifying CT, MRI, X-ray, ultrasound, and so on, manufacturer (0008,0070), institution name (0008,0080), body part examined (0018,0015), and the various acquisition parameters specific to the modality (slice thickness, kilovoltage, exposure time, magnetic field strength, repetition time, echo time) all live at this level. These tags carry the technical context that determines how the radiologist interprets the image.

Pixel data is stored in a special tag (7FE0,0010) at the end of the dataset. Unlike other tags that hold structured metadata values, the pixel data tag contains the raw image data — typically encoded with a transfer syntax that may apply compression (JPEG, JPEG 2000, JPEG-LS, RLE) or store the pixels uncompressed. The pixel data is the actual diagnostic content; everything else in the DICOM file provides the context needed to interpret it correctly.

DICOM in clinical workflows: PACS, EHR, and modality integration

DICOM operates as the connective tissue of clinical imaging workflows. From the moment a clinician orders an imaging study to the moment the final report appears in the patient’s chart, DICOM is moving data between systems at every step.

The workflow typically starts when a referring clinician orders an imaging study in the electronic health record (EHR). The EHR sends an HL7 order message to the radiology information system (RIS), which schedules the study and sends a DICOM modality worklist entry to the appropriate imaging device. When the patient arrives for their scan, the technologist selects the patient from the worklist, the modality acquires the imaging study, and the resulting DICOM files are pushed to the PACS via DICOM C-STORE or DICOMweb STOW-RS. The radiologist opens the study on their PACS workstation, dictates the report, and the finalized report flows back to the EHR via an HL7 ORU result message or a FHIR DiagnosticReport resource.

PACS (Picture Archiving and Communication System) is the central DICOM archive — the storage and retrieval layer that holds all the imaging studies a facility has acquired and supports the workflow tools that radiologists use to read them. Modern PACS handles both classic DIMSE services for legacy device compatibility and DICOMweb for cloud-native workflows. The PACS connects to the imaging modalities (which send studies in), the radiologist workstations (which retrieve studies for reading), the RIS (which provides ordering and scheduling context), and the EHR (which surfaces imaging results in the patient chart).

Vendor-neutral archive (VNA) architecture has emerged as a structural evolution of traditional PACS. A VNA decouples the imaging storage layer from the PACS reading software, allowing a single archive to serve multiple imaging vendors, multiple reading workflows, and multiple sites. The 2026 Best in KLAS VNA winner is AGFA HealthCare Enterprise Imaging at 89.8 percent satisfaction. For deeper coverage of VNA, see Medicai’s vendor-neutral archive guide.

The integration between DICOM imaging and the broader healthcare data ecosystem happens through HL7 (the traditional healthcare messaging standard) and FHIR (the modern API-based healthcare standard). HL7 v2 messages carry patient demographics, orders, and results between the imaging systems and the EHR. FHIR APIs increasingly handle the same workflows in cloud-native deployments, with FHIRcast and similar integration frameworks bridging DICOM imaging with FHIR-based clinical workflows. For modern cloud-based imaging deployments like Medicai’s cloud PACS platform, DICOMweb and FHIR are the default integration protocols.

The history and evolution of DICOM

DICOM has a 40-year history that traces the evolution of digital medical imaging from its earliest days to the cloud-native present. The standard predates most modern healthcare interoperability efforts and has outlasted many competing approaches.

The origin story begins in 1983 when the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee to develop a standard for digital medical imaging. The driver was practical: early CT and MRI scanners produced digital images, but each manufacturer used proprietary file formats and communication protocols. A radiologist couldn’t transfer a study from a Siemens scanner to a GE workstation without manufacturer-specific conversion tools. The interoperability problem was blocking the broader adoption of digital imaging in clinical practice.

ACR-NEMA Version 1.0 was published in 1985 as the first version of what would become DICOM. Version 2.0 followed in 1988 with refinements. The breakthrough was Version 3.0 in 1993, which restructured the standard around object-oriented Information Object Definitions and added comprehensive network communication services. Version 3.0 also adopted the DICOM name (Digital Imaging and Communications in Medicine), replacing the original ACR-NEMA label. The structural decisions made in DICOM 3.0 remain the foundation of the current standard.

The standard has continued evolving through annual revisions ever since. Major additions over the years include DICOM Structured Reporting (DICOM SR) for structured findings data, DICOMweb for HTTPS-based communication, support for newer modalities (digital mammography, breast tomosynthesis, optical coherence tomography, photon-counting CT), and integration with adjacent standards such as HL7 and FHIR. The current version is updated multiple times per year as new supplements are incorporated.

The longevity of DICOM is uncommon in healthcare technology. Most standards introduced in the 1980s have been replaced multiple times by successor standards. DICOM has instead absorbed new capabilities while maintaining backward compatibility with files produced decades ago. A DICOM file written by a CT scanner in 1995 can still be opened and read correctly by a 2026 DICOM viewer. This stability is what allows hospitals to retain decades of imaging studies in their archives without migration or conversion concerns.

DICOMweb and the future of the DICOM standard

The DICOM standard is undergoing its largest architectural transition since the introduction of DICOM 3.0 in 1993. The migration from classic DIMSE communications to DICOMweb is reshaping how new imaging systems get architected, while AI integration is changing what DICOM data the standard needs to carry.

DICOMweb implementation is accelerating across new deployments. Cloud-native PACS platforms default to DICOMweb. New medical imaging device firmware increasingly supports DICOMweb alongside or instead of classic DIMSE. Browser-based DICOM viewers that use open-source toolkits such as Cornerstone and OHIF rely on DICOMweb for network communication. The structural advantage is operational simplicity: DICOMweb operates over standard HTTPS, traverses firewalls and load balancers like any web service, and integrates with REST-based development patterns familiar to every modern developer.

DICOM Structured Reporting (DICOM SR) is becoming the carrier for AI-generated structured findings. As AI tools clear FDA approval and deploy clinically, the structured output those tools generate (quantitative measurements, anatomical locations, confidence scores) needs a structured carriage format. DICOM SR has existed since the 1990s but is finally seeing widespread implementation because AI outputs require structured data carriage rather than narrative description. New AI-cleared tools increasingly include DICOM SR support as a baseline capability.

The relationship between DICOM and FHIR is evolving from parallel standards toward integrated workflows. DICOM handles imaging-specific data; FHIR handles general healthcare data exchange. FHIRcast and FHIR ImagingStudy resources bridge the two, enabling launch-in-context viewing where an EHR pulls imaging from a separate PACS with proper patient and study context. The two standards aren’t competitors but complementary layers of the healthcare interoperability stack.

Looking ahead to 2030, DICOM remains the universal medical imaging standard, but its implementation patterns continue to shift. Cloud-native deployments default to DICOMweb. AI integration drives DICOM SR adoption. Browser-based viewers replace thick-client workstations. Multi-site practice consolidation depends on DICOM’s universal interoperability to make centralized imaging archives operationally workable. For broader coverage of where medical imaging is heading, see Medicai’s future of medical imaging analysis.

How to View DICOM Files Smoothly

Imaging files are exchanged daily, making quick access to DICOM studies crucial for efficient workflows and coordinated care. Here’s an overview of the viewing process and how modern tools simplify it.

Using Hospital-Provided CDs or USBs

Many facilities still rely on CDs or USB drives to release imaging to patients or outside clinicians. These drives usually include:

• the DICOM files themselves, and
• a built-in viewer supplied by the scanner manufacturer or PACS vendor

To open these scans, you locate the executable viewer on the CD/USB and launch it. Once it loads, the program displays the study in a basic interface with limited tools.

However, these embedded viewers often create friction.

They are rarely updated, struggle on modern operating systems, and run inconsistently across devices. Professionals frequently face:

• slow loading speeds
• compatibility issues
• missing features like MPR or measurements
• viewer crashes on newer Windows/macOS versions

This results in time lost, especially when imaging is urgently needed for clinical decisions.

Tools like Medicai remove these barriers by offering fast, consistent access to DICOM studies directly through the browser.

Online DICOM Viewers

Online DICOM viewers offer a more convenient workflow. These browser-based tools allow clinicians to upload and view imaging without installing heavy desktop applications.

It provides several benefits, including-

• Immediate access to studies
• No dependency on outdated CD software
• The ability to review imaging from any workstation
• Quick sharing for second opinions or multidisciplinary discussions

For cross-institution consultations, online viewers help eliminate the need for physical media and reduce delays caused by technical issues.

Cloud-Based Platforms

Healthcare is shifting toward fully web-based imaging ecosystems. Cloud viewers represent the next stage of digital radiology, removing the limitations of CDs, USBs, and fixed workstations.

Cloud platforms help to

• open studies instantly from any browser
• access full DICOM toolsets (MPR, windowing, annotations, measurements)
• collaborate across departments or facilities without transferring files manually
• maintain consistent, high-quality visualization across all devices
• ensure secure access aligned with HIPAA/GDPR requirements
• eliminate dependence on legacy media and outdated software

For radiologists, it means faster reading workflows.

For referring clinicians, it means reliable access to patient imaging without technical barriers.

For patients, it means smoother follow-ups and better-coordinated care.

Frequently asked questions about DICOM

Conclusion

The DICOM format makes medical imaging feel less mysterious. These files carry the context, detail, and accuracy that modern diagnosis depends on. With the right viewer, the complexity disappears, and the scan becomes clear and usable.

As imaging moves to the cloud, platforms like Medicai make viewing, sharing, and collaborating faster and far more seamless. Our goal is simple: clearer images, smoother workflows, and better care for every patient.