DICOM — medical imaging standard and FHIR ImagingStudy

1. What is DICOM? Definition and history

DICOM stands for Digital Imaging and Communications in Medicine. It is the international standard that governs how medical images and their accompanying metadata are stored, transmitted, and described. The question what is DICOM can be answered in one sentence: it is the body of technical conventions that lets a Siemens CT scanner talk to a GE reading workstation, a Carestream PACS, or an open-source viewer such as OHIF — regardless of vendor.

The first version of the standard appeared in 1985 under the name ACR-NEMA, jointly led by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA). DICOM 3.0 was released in 1993 and remains the foundation in use today. NEMA continues to act as Secretariat for the DICOM Standards Committee, publishing updates several times a year under identifiers such as 2026a, 2026b, and so on. DICOM is referenced in the ISO 12052 standard and underpins almost every diagnostic imaging system worldwide.

Unlike HL7 v2, which focuses on administrative and clinical messaging, DICOM focuses on pixel data and the metadata attached to each slice. A DICOM file does not just carry an image: it also carries the full patient record, the technical parameters of the acquisition, modality calibration, and unique identifiers that persist throughout the image's lifecycle. This is why DICOM stands on its own and is hard to displace with general-purpose image formats such as JPEG or PNG.

2. Three components: file, DIMSE, DICOMweb

When discussing DICOM, integration engineers must distinguish three distinct layers, all described together in the 22-part standard from PS3.1 through PS3.22.

The .dcm file format

A DICOM file is a binary structure with a tag-based header. Pixel data and metadata are packaged into the same file and cannot be separated. The header uses (Group, Element) pairs to describe attributes, alongside a VR (Value Representation) code that indicates the data type. Images may be compressed using JPEG Baseline, JPEG Lossless, JPEG-LS, JPEG 2000, or RLE; each compression scheme corresponds to a Transfer Syntax UID.

The DIMSE network protocol

DIMSE (DICOM Message Service Element) runs over TCP and defines the set of operations that two AEs (Application Entities) use to exchange data: C-STORE to send an instance, C-FIND to query, C-MOVE to ask a third party to forward images, C-GET to pull directly, and C-ECHO to verify connectivity. Each operation is bound to a SOP Class — for example CT Image Storage or Modality Worklist.

DICOMweb — the RESTful HTTP layer

From 2011 onward, the DICOM committee extended the standard to HTTP with DICOMweb, specified in PS3.18. The four core services are WADO-RS for retrieval, QIDO-RS for queries, STOW-RS for storage, and UPS-RS for unified worklist. DICOMweb does not replace DIMSE; it is a parallel channel, and many modern PACS expose both endpoints simultaneously.

3. Anatomy of a DICOM file — Tag, VR, SOP Class UID

A DICOM file is organized into modules of attributes, but the actual tags are defined in the PS3.6 Data Dictionary table. Below are the tags FHIR engineers should remember when mapping to ImagingStudy:

File Meta Information   (Group 0002)         — header, transfer syntax
PatientName             (0010,0010)          — patient full name
PatientID               (0010,0020)          — patient identifier (MRN)
PatientBirthDate        (0010,0030)          — date of birth
StudyInstanceUID        (0020,000D)          — Study UID
SeriesInstanceUID       (0020,000E)          — Series UID
SOPInstanceUID          (0008,0018)          — UID of each image instance
SOPClassUID             (0008,0016)          — Service-Object pair type
StudyDate               (0008,0020)          — acquisition date
StudyDescription        (0008,1030)          — study description
Modality                (0008,0060)          — CT, MR, US, CR, DX, MG…
PixelData               (7FE0,0010)          — binary pixel data

Each data element has four parts: the (Group, Element) tag pair, a VR code (PN for person name, UI for UID, DA for date, OW/OB for pixel data, and so on), a length field, and the actual value. This structure makes a DICOM file self-describing: a parser does not need to know the layout in advance because it can read sequentially using VR and length.

The triple StudyInstanceUID — SeriesInstanceUID — SOPInstanceUID forms a three-level identifier tree for every instance worldwide. A patient may have multiple Studies (for example, a chest CT and a brain MRI); each Study has multiple Series (axial, coronal, sagittal, or different contrast phases); each Series contains multiple Instances (typically one per slice). UIDs never collide across systems because they are generated using global OIDs, for example 1.2.840.113619.2.5.1762583153.215519.978957063.78.

SOP Class UID — short for Service-Object Pair — identifies the combination of service and object type. When a CT modality sends an image to PACS, it uses the SOP Class CT Image Storage (1.2.840.10008.5.1.4.1.1.2); when RIS queries a worklist, it uses Modality Worklist Information Model FIND. The two parties must negotiate the SOP Class during the association request; if they do not agree, the connection is rejected.

4. Modality and hospital workflow

A diagnostic imaging episode usually flows through four systems: HIS (the hospital information system holding the medical record), RIS (the radiology information system), the modality (the scanner itself), and PACS (the image archive). DICOM connects the last three of these links, while HL7 v2 or FHIR handles the exchange with HIS.

[HIS]      — HL7 v2 ORM (order)        →  [RIS]
[RIS]      — DICOM Modality Worklist  →  [Modality (CT/MR scanner…)]
[Modality] — DICOM C-STORE             →  [PACS]
[PACS]     — DICOM C-MOVE / WADO-RS    →  [Viewer / workstation]
[Radiologist] — HL7 v2 ORU or FHIR
                DiagnosticReport       →  [HIS]

When a clinician orders an imaging study, HIS sends an order to RIS. RIS schedules the case and pushes its details onto the worklist queue. When the modality starts the case, it queries RIS via DICOM Modality Worklist and receives the patient ID, procedure name, and Accession Number, ensuring that the metadata attached to the images is correct. After acquisition, the modality compresses the images and sends a C-STORE to PACS. The radiologist opens a viewer to read the study — the viewer uses C-MOVE, C-GET, or DICOMweb WADO-RS to pull the images from PACS, then writes a report and sends it back to HIS as either an HL7 v2 ORU message or a FHIR DiagnosticReport resource.

5. PACS, RIS, Modality Worklist

These three terms appear in nearly every diagnostic imaging technical document, so it is worth distinguishing them clearly:

• PACS — Picture Archiving and Communication System: the centralized DICOM archive. It acts as both a C-STORE SCP server that receives images and a Query/Retrieve SCP that serves viewers. Modern PACS typically also expose a DICOMweb endpoint for web and mobile viewers.
• RIS — Radiology Information System: the operational software for the radiology department. It manages appointments, orders, staffing, reading time, and report issuance. RIS does not store images; it references PACS via the Accession Number and Study UID.
• MWL — Modality Worklist: the DICOM service (Modality Worklist Information Model FIND) that lets a modality pull the day's task list from RIS, avoiding manual entry errors when typing patient details into the modality console.

In many small and mid-size hospitals, the line between RIS and HIS is blurred: HIS doubles as RIS, and the worklist is generated directly from HIS. That deployment pattern is still DICOM-conformant as long as the MWL endpoint exposes the correct SOP Class.

6. DICOMweb — the inheriting REST layer

DICOMweb is how DICOM caught up with the modern web. Instead of staying on raw TCP, the services are expressed as HTTP URLs that return JSON or multipart binary. The three core services are:

• WADO-RS — Web Access to DICOM Objects, RESTful: inherits C-MOVE/C-GET.
• QIDO-RS — Query based on ID for DICOM Objects: inherits C-FIND.
• STOW-RS — Store Over the Web: inherits C-STORE.

GET /studies?PatientID=0123456789
   Accept: application/dicom+json
   → JSON list of matching Studies (QIDO-RS)

GET /studies/{StudyInstanceUID}/metadata
   Accept: application/dicom+json
   → JSON metadata for the entire Study (WADO-RS Metadata)

GET /studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}
   Accept: multipart/related; type="application/dicom"
   → multipart binary for each DICOM instance

POST /studies
   Content-Type: multipart/related; type="application/dicom"
   → STOW-RS: upload a new instance to PACS

The biggest advantage of DICOMweb is that browser-based viewers no longer need plugins or open DICOM ports, and they work across HTTPS proxies. This is why open-source viewers such as OHIF and Cornerstone3D adopt DICOMweb as their default transport.

7. FHIR + DICOM — a complementary relationship

A natural question for FHIR practitioners is: can FHIR replace DICOM? The short answer is no, at least not in the foreseeable future. FHIR and DICOM solve different problems and were designed to complement each other.

The common integration pattern: PACS continues to store DICOM images and serve them over DIMSE/DICOMweb. The FHIR system creates an ImagingStudy resource that references that Study, plus an Endpoint resource carrying the PACS DICOMweb URL. The viewer client reads the ImagingStudy, retrieves the URL from Endpoint, then calls WADO-RS to fetch the pixel data. FHIR plays the role of cross-hospital index and metadata layer; DICOM remains the canonical storage.

8. ImagingStudy and ImagingSelection

ImagingStudy is the FHIR resource introduced in R4 specifically for diagnostic imaging. Each ImagingStudy represents exactly one DICOM Study and uses the urn:dicom:uid identifier system to carry the original StudyInstanceUID.

{
  "resourceType": "ImagingStudy",
  "identifier": [{
    "system": "urn:dicom:uid",
    "value": "urn:oid:1.2.840.113619.2.5.1762583153.215519.978957063.78"
  }],
  "status": "available",
  "subject": { "reference": "Patient/123" },
  "started": "2026-04-15T08:30:00+07:00",
  "modality": [{
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "CT"
  }],
  "endpoint": [{ "reference": "Endpoint/dicomweb-pacs" }],
  "numberOfSeries": 3,
  "numberOfInstances": 240
}

Note that the code system in modality must be the canonical DICOM Controlled Terminology URI, namely http://dicom.nema.org/resources/ontology/DCM. Using a placeholder URI may cause a FHIR server to reject the resource during ValueSet validation.

R5 adds a new resource, ImagingSelection, to describe regions of interest (ROIs), bookmarks, or key images — for example, a radiologist marking a CT slice with a tumor for case discussion. ImagingSelection is R5-only, not R4; in IGs based on FHIR R4 (including VN Core), ImagingStudy should remain the primary resource and ImagingSelection should be treated as a forward-looking reference for the eventual R5 upgrade.

9. IHE Radiology profiles

IHE (Integrating the Healthcare Enterprise) publishes profiles that bind DICOM and HL7 into real-world workflows. In the Radiology domain, four profiles come up frequently:

• SWF — Scheduled Workflow: standardizes the order — schedule — perform — store — report flow.
• XDS-I — Cross-Enterprise Document Sharing for Imaging: shares images and reports across organizations via a registry/repository.
• IID — Invoke Image Display: a standard URL convention so HIS can ask a viewer to display a specific Study.
• XCA-I — Cross-Community Access for Imaging: cross-community / cross-region extension for national-scale networks.

When a hospital or hospital group needs to share images across organizational boundaries, IHE profiles save them from reinventing the wheel. They also underpin national PACS hubs in several European countries. See the IHE profiles for healthcare in Vietnam page for a deeper look at applying these profiles locally.

10. Vietnam context

In Vietnam, DICOM is the de facto standard for every imported modality. Most provincial- and central-level hospitals have already deployed PACS — from major vendors such as Carestream, GE Healthcare, Siemens Healthineers, Fujifilm, and Philips, or from local system integrators. Because the standard is international by nature, PACS in Vietnam typically run plain DICOM 3.0 without any country-specific local profile.

The most common HIS-PACS integration pattern still relies on HL7 v2 ORM (to send orders) and HL7 v2 ORU (to receive reports). A handful of hospitals have piloted a FHIR layer in front of HIS, but rolling ImagingStudy into production is still in its early stages. As VN Core FHIR (canonical http://fhir.hl7.org.vn/core) is adopted more widely, ImagingStudy will become the pivot resource for cross-hospital image viewing — a particularly good fit for the EMR model defined in Circular 13/2025/TT-BYT (Ministry of Health).

Circular 13/2025/TT-BYT requires every hospital's electronic medical record (EMR) to be completed by 31/12/2026 at the latest. Diagnostic imaging is a mandatory component of the EMR. Keeping images in DICOM while exposing an additional FHIR ImagingStudy layer is the pragmatic middle path between protecting existing PACS investments and meeting new interoperability requirements. For more on the EMR and the related FHIR resources, see the core FHIR Resources overview.

11. Frequently asked questions

How large is a typical DICOM file?

A standard CT scan produces roughly 500 MB to 2 GB per Study (a few hundred to a few thousand thin slices). MRI is comparable or larger when multi-sequence acquisitions are used. Digital X-ray (CR/DX) takes only 10 MB to 50 MB per image. High-resolution mammography (MG) can exceed 100 MB per view.

Is the DICOM standard free?

The DICOM standard is published free of charge at dicomstandard.org/current, with no license fee — unlike some older HL7 v2 specifications. Real-world cost lies in the implementation: PACS, viewers, modalities, and operations.

If I only work on FHIR, do I need to learn DICOM in depth?

It depends on scope. To integrate ImagingStudy with PACS, FHIR engineers need to grasp the concept of SOP Class UID, the Study/Series/Instance UID triple, and DICOMweb URLs. Going deeper into Transfer Syntax, VRs, or Modality Worklist can wait until you actually need to build a viewer or process images directly.

Will FHIR replace DICOM in the future?

Not in the foreseeable future. FHIR does not specify pixel data structures, has no medical image compression standards, and lacks a VR tag system. The realistic direction is for FHIR to act as a metadata + index layer while DICOM remains the canonical image format. Any EMR roadmap should treat DICOM as a non-removable foundational layer.

12. References and further reading

Primary sources

• Current DICOM Standard — dicomstandard.org/current. All 22 parts (PS3.1 through PS3.22), updated several times per year.
• DICOM Data Dictionary (PS3.6) — dicom.nema.org PS3.6 Chapter 6. The canonical (Group, Element) tag table.
• DICOMweb services (PS3.18) — dicom.nema.org PS3.18. Specifications for WADO-RS, QIDO-RS, STOW-RS, and UPS-RS.
• DICOM Controlled Terminology (PS3.16) — dicom.nema.org PS3.16 Chapter 8. Canonical URI http://dicom.nema.org/resources/ontology/DCM.
• FHIR R4 ImagingStudy — hl7.org/fhir/R4/imagingstudy.html.
• FHIR R5 ImagingSelection — hl7.org/fhir/R5/imagingselection.html.
• IHE Radiology Technical Frameworks — ihe.net/resources/technical_frameworks.
• Circular 13/2025/TT-BYT on electronic medical records — the legal basis for the EMR rollout schedule and imaging integration in Vietnam.

Further reading on hl7.org.vn