Interoperability between imaging devices from different vendors depends less on the .dcm file format and more on the semantics of the network services DICOM defines: a file exchanged badly between two nodes that negotiate incompatible transfer syntaxes is as useless as an image that is not there. Anyone connecting a modality to an archive discovers this before anything else.

DICOM — Digital Imaging and Communications in Medicine — is the standard NEMA publishes as the PS3 series, the result of joint work begun in the 1980s by ACR (American College of Radiology) and NEMA (National Electrical Manufacturers Association). The 1985 and 1988 ACR-NEMA editions precede version 3.0 of 1993, the first to define transport over TCP/IP and still referred to as DICOM 3.0. The standard has no single version number: it is a set of parts updated independently through Supplements and Change Proposals approved by the DICOM Standards Committee.

Context: an object model, not an image format

Reading DICOM as “a JPEG with clinical metadata” is the most common mistake. At its centre sits an information model. An Information Object Definition (IOD) describes a real-world entity — a CT image, an MR scan, a structured report — as a set of attributes grouped into modules.

Each attribute is identified by a hexadecimal (Group,Element) pair: (0010,0010) Patient’s Name, (0020,000D) Study Instance UID, (0008,0016) SOP Class UID, (7FE0,0010) Pixel Data. The unique identifiers are UIDs built as ISO OIDs; the ones DICOM assigns are rooted at 1.2.840.10008. Study, series, instance and class each hold their own UID, and every query and retrieve operation rests on them.

A SOP Class (Service-Object Pair) binds an IOD to a set of services. CT Image Storage is 1.2.840.10008.5.1.4.1.1.2; analogous classes exist for MR, ultrasound, structured text reports (Basic Text SR), encapsulated PDF. When two nodes talk to each other, they negotiate exactly which SOP Classes and which serialisations they accept.

Architecture: DIMSE and transfer syntaxes

The messaging services are the DIMSE (DICOM Message Service Elements). The ones you meet every day:

  • C-STORE — sending an instance from one node to another, usually from the modality to the archive
  • C-FIND — querying studies, series or instances on a node
  • C-MOVE — asking a node to send a set of instances to a third node (indirect retrieve)
  • C-GET — direct retrieve, rare in real deployments because of the negotiation constraints it imposes
  • C-ECHO — application-level connectivity check
  • N-SET, N-ACTION, N-EVENT-REPORT — normalized services underlying, for instance, MPPS (Modality Performed Procedure Step)

The network layer (PS3.8) defines an Upper Layer over TCP, IANA port 104; in practice you often meet 11112. The association between two nodes negotiates Application Entity Title, Presentation Context and Transfer Syntax.

The Transfer Syntax is where interoperability breaks most often. It sets how attributes are serialised and whether Pixel Data are compressed. The most recurring ones:

  • Implicit VR Little Endian (1.2.840.10008.1.2) — default, VR inferred from the Data Dictionary
  • Explicit VR Little Endian (1.2.840.10008.1.2.1) — VR written into the datastream
  • JPEG Baseline (1.2.840.10008.1.2.4.50) — lossy compression
  • JPEG Lossless (1.2.840.10008.1.2.4.70)
  • JPEG 2000 (1.2.840.10008.1.2.4.90 and .91)
  • RLE Lossless (1.2.840.10008.1.2.5)

A node that receives instances in JPEG 2000 but does not declare it among its presentation contexts rejects the transfer syntax at association time: the C-STORE fails before it ever touches the pixels. To diagnose these rejections you read the association log, not the file.

The file and its limits (PS3.10)

A PS3.10-conformant file has a 128-byte preamble, the DICM magic, a File Meta Information Header in Explicit VR Little Endian, then the Dataset in the transfer syntax declared at the head. The .dcm extension is a convention, not a normative requirement. The DICOMDIR describes a set of files on removable media, a format meant for CD/DVD interchange still common between sites.

File transport runs up against its own granularity: a single multidetector CT study reaches hundreds of MB spread over thousands of instances. Moving that state between systems on physical media, or even via C-MOVE, lends itself poorly to web integrations, where a resource is addressed by a URL.

The critical point: the move to REST services

For about a decade DICOM has also exposed its objects over HTTP. The first step is WADO (Web Access to DICOM Persistent Objects, PS3.18), which retrieves a known instance through an HTTP request carrying its UIDs as parameters. It is a read-only, single-instance service, meant for embedding in clinical pages.

More recent work brings DIMSE semantics onto a coherent RESTful interface, approved as Supplements in 2011:

  • WADO-RS (Supplement 161) — retrieve of studies, series or instances and their metadata
  • STOW-RS (Supplement 163) — Store Over the Web, the HTTP equivalent of C-STORE
  • QIDO-RS (Supplement 166) — Query based on ID for DICOM Objects, the equivalent of C-FIND

The difference from DIMSE is not only transport. A QIDO-RS query is a GET with parameters in the URL and a JSON or XML response; a WADO-RS retrieve addresses /studies/{uid}/series/{uid}/instances/{uid} like any web resource. At that point an image archive can be queried even by code that knows nothing of the DICOM association, its transfer syntaxes or port 11112 — at the price, today, of still uneven vendor support and of parts of the standard that change fast.

What you build with the Open Source toolkits

The Open Source stack around DICOM is by now mature: a complete test node goes up without a single commercial component.

The tools I lean on:

  • DCMTK (OFFIS, Oldenburg) — C++ toolkit with command-line tools (storescu, storescp, findscu, movescu, dcmdump, img2dcm), BSD-style licence
  • dcm4che — Java toolkit, 3.x generation, with the dcm4chee archive; MPL/LGPL licence
  • GDCM (Grassroots DICOM) by Mathieu Malaterre — BSD C++ library, the DICOM backend of ITK
  • Orthanc by Sébastien Jodogne (CHU Liège) — lightweight C++ server with a built-in REST API, a standalone cross-platform binary, first public release in July 2012, GPL licence
  • PixelMed by David Clunie — Java library used in many validation tools

Viewers such as OsiriX and Ginkgo CADx sit on top of these. With DCMTK and Orthanc on a single machine you rebuild the whole cycle: reception via C-STORE, query/retrieve, REST exposure, dataset inspection with dcmdump.

Limits

The standard describes the syntax; real interoperability requires agreeing on the workflow. That is the job of the IHE (Integrating the Healthcare Enterprise) profiles — Scheduled Workflow, Patient Information Reconciliation, XDS-I.b for cross-domain sharing — which fix how DICOM services compose into a clinical path. Private Pixel Data and vendor-specific metadata fall outside the standard, and so onto the integrator, as do de-identification strategies for secondary use, for which the references are Supplement 142 and the attribute list in PS3.15 Annex E. The software names the UIDs; whoever integrates must verify that the two sides really negotiate the same ones.

Cover image: Grid of 34 grayscale axial slices from a computed tomography scan of the brain, from skull base to vertex — photo by Department of Radiology, Uppsala University Hospital, CC0 — https://commons.wikimedia.org/wiki/File:Computed_tomography_of_human_brain_-_large.png