DICOM: the imaging standard and its open source ecosystem

AIHealth

On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.

Discover AIHealth →

Digital Health

Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.

Discover →

Origins

DICOM — Digital Imaging and Communications in Medicine — is the reference standard for the representation, storage and transmission of medical images and associated clinical data. It was born as joint work between ACR (American College of Radiology) and NEMA (National Electrical Manufacturers Association): the earliest ACR-NEMA versions date back to 1985 and 1988, while version 3.0 — the first truly interoperable over TCP/IP networks and still identified as DICOM 3.0 — was published in 1993. The standard is maintained by the DICOM Standards Committee and continuously updated through Supplements and Change Proposals.

Formally, the standard is published as NEMA PS3, split into parts (PS3.1 Introduction and Overview, PS3.3 Information Object Definitions, PS3.4 Service Class Specifications, PS3.5 Data Structures and Encoding, PS3.6 Data Dictionary, PS3.7 Message Exchange, PS3.8 Network Communication Support, PS3.10 Media Storage and File Format, PS3.14 Grayscale Standard Display Function, PS3.15 Security and System Management Profiles, PS3.18 Web Services, PS3.20 Imaging Reports) and more. Each part has a distinct function and can be updated independently.

The information model

At the core of DICOM is the Information Object Definition (IOD): a structure describing a real-world object — a CT image, an MR, a structured report — as a collection of attributes grouped into modules. Attributes are identified by a (Group, Element) pair in hexadecimal: (0010,0010) Patient’s Name, (0010,0020) Patient ID, (0020,000D) Study Instance UID, (0020,000E) Series Instance UID, (0008,0016) SOP Class UID, (7FE0,0010) Pixel Data.

Unique references are built as UIDs (Unique Identifier) in ISO OID format (1.2.840.10008.x.y.z for DICOM-registered UIDs). Every study, series, instance and SOP class has its own UID.

A SOP Class (Service-Object Pair) combines an IOD with a set of services: CT Image Storage (UID 1.2.840.10008.5.1.4.1.1.2), MR Image Storage, Ultrasound Image Storage, Basic Text SR Storage, Encapsulated PDF Storage, and dozens more. Negotiation between two DICOM nodes is about which SOP Classes and which Transfer Syntax they support.

Transfer Syntax

A Transfer Syntax specifies how DICOM attributes are serialised and whether Pixel Data are compressed. The most widespread:

• Implicit VR Little Endian (1.2.840.10008.1.2) — default, VR derived from the Data Dictionary
• Explicit VR Little Endian (1.2.840.10008.1.2.1) — VR explicitly encoded in the stream
• JPEG Baseline (1.2.840.10008.1.2.4.50) — lossy JPEG
• JPEG Lossless (1.2.840.10008.1.2.4.70) — lossless JPEG
• JPEG 2000 (1.2.840.10008.1.2.4.90 and .91) — lossless and lossy
• RLE Lossless (1.2.840.10008.1.2.5) — run-length encoding
• Deflate Explicit VR Little Endian (1.2.840.10008.1.2.1.99)

Each node declares, during Association Establishment, which syntaxes it accepts for each SOP Class.

DIMSE services

DICOM message services are known as DIMSE (DICOM Message Service Elements):

• C-STORE — sending an instance from one node to another (typically from the modality to the PACS)
• C-FIND — searching studies/series/instances on a node (Query, used by the worklist or PACS browser)
• C-MOVE — requesting a node to send a set of instances to a third node (indirect retrieve)
• C-GET — direct retrieve (less used in real environments due to negotiation constraints)
• C-ECHO — connectivity check (the DICOM application-level ping)
• N-SET, N-ACTION, N-EVENT-REPORT — normalized services used, for example, by MPPS (Modality Performed Procedure Step)

The network layer (PS3.8) defines the Upper Layer for TCP with IANA port 104, but in real deployments port 11112 is commonly used. Association between two nodes negotiates Application Entity Title, Presentation Context and Transfer Syntax.

The DICOM file (PS3.10)

A DICOM file (extension .dcm, even though the extension is not normatively required) has a 128-byte preamble followed by the DICM magic and a File Meta Information Header in Explicit VR Little Endian, followed by the actual Dataset in the declared Transfer Syntax. The DICOMDIR format describes the structure of a set of files on removable media (typically CD/DVD), used in patient-to-patient and cross-facility interchange.

Beyond DIMSE: DICOMweb

Work on DICOMweb — RESTful web services that reuse DICOM semantics — started in the early 2000s with WADO (Web Access to DICOM Objects, PS3.18, first version 2003) and evolved towards a more modern interface. The Supplements introducing QIDO-RS (query), WADO-RS (retrieve) and STOW-RS (store) were approved in 2011–2013, bringing DICOM into the domain of HTTP APIs and preparing the ground for integration with contemporary web technologies.

IHE Radiology

DICOM specifications alone are not enough to guarantee practical interoperability between systems from different vendors. The IHE (Integrating the Healthcare Enterprise) framework extends their use with profiles describing complete workflows. The main ones in the radiology domain:

• SWF (Scheduled Workflow) — orchestrates HIS → RIS → modality → PACS → reporting
• PIR (Patient Information Reconciliation) — demographic realignment after execution
• PGP (Presentation of Grouped Procedures) — management of multi-procedure studies
• XDS-I.b — cross-domain image sharing over XDS (integration with the document world)
• IRWF.b (Import Reconciliation Workflow) — import of external CD/DVD studies

In Italy, IHE profiles are the basis of regional PACS tenders and cross-facility exchanges.

The open source ecosystem

A solid and mature open source stack has grown around DICOM:

• DCMTK (OFFIS, Oldenburg) — C++ toolkit available since the 1990s, covering nearly every DIMSE service, with command-line tools (storescu, storescp, findscu, movescu, dcmdump, img2dcm). BSD-style license
• dcm4che — Java toolkit with the dcm4chee Archive server. The 3.x line is the current generation. MPL/LGPL license
• GDCM (Grassroots DICOM) — C++ library by Mathieu Malaterre, BSD, used as the DICOM back-end of ITK and broader imaging projects
• Orthanc — lightweight C++ DICOM server by Sébastien Jodogne (CHU Liège), integrated REST API, available as a standalone cross-platform binary. First public release 2012. GPL
• PixelMed — Java library by David Clunie, used in numerous academic and validation tools

Viewers (OsiriX/Horos, Ginkgo CADx), enterprise archives and processing tools build on these toolkits. In real practice, a laboratory or small department can build a complete DICOM test node — receive, query/retrieve, view, convert — without commercial components.

The Italian landscape

DICOM adoption in Italian hospitals is pervasive: every modality (CT, MR, ultrasound, mammography, digital radiology, nuclear medicine) produces and exchanges images in DICOM. Regional and enterprise PACS dialogue with each other through DICOM and IHE XDS-I, with increasing integration towards the FSE for publication of reports and diagnostic images.

Open challenges are not in the standard itself, but in its application: private Pixel Data and vendor-specific metadata complicate processing, de-identification strategies for secondary use require care (Supplement 142 on Clinical Trial De-identification Profiles and the PS3.15 Annex E tag list are required references), and volume management — a single multi-detector CT study is hundreds of MB — imposes conscious compression and storage choices.

References: DICOM Standard PS3.1–PS3.20, NEMA/MITA. DCMTK (OFFIS). dcm4che. GDCM. Orthanc (CHU Liège). IHE Radiology Technical Framework.