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

The illustrative model below has four system roles: HIS, RIS, modality, and PACS. A site may combine or split those roles. DICOM commonly supports modality/PACS flows; the HIS interface may use HL7 v2, FHIR, or another contract advertised by the participating systems.

[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 information such as patient ID, procedure, and Accession Number to reduce re-entry; correct matching still requires validation and reconciliation. After acquisition, the modality may send instances to PACS with C-STORE. 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

DICOMweb lets web clients use HTTP(S) without implementing DIMSE directly in the browser. Whether plugins, proxies, or separate ports are needed still depends on the viewer, PACS, topology, and security policy. OHIF and Cornerstone3D support DICOMweb, but actual capability must be verified from the deployed configuration.

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.

One common integration pattern is for PACS to store DICOM objects 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. In this pattern FHIR is the metadata/index layer and DICOM is the imaging-object layer; not every site uses FHIR as a cross-hospital index.

8. ImagingStudy and ImagingSelection

ImagingStudy is available in FHIR R4 to represent information about an imaging study. 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

When reviewing modality/PACS deployments in Vietnam, the relevant evidence is not a “DICOM 3.0” label or vendor name but the DICOM Conformance Statement, SOP Classes, transfer syntaxes, security profiles, and actual site configuration. DICOM is maintained as an international standard; a deployment may still need local conventions for identifiers, workflow, terminology, and access control.

One HIS-RIS-PACS pattern uses HL7 v2 for orders/reports and DICOM for worklists and images; another may expose FHIR at a metadata/API boundary. VN Core (canonical http://fhir.hl7.org.vn/core) may profile ImagingStudy when a defined imaging-interoperability use case enters scope. Production capability must still be declared in a CapabilityStatement and demonstrated by site testing; Circular 13/2025/TT-BYT does not itself prescribe FHIR ImagingStudy or one HIS-PACS architecture.

Circular 13/2025/TT-BYT sets 30/09/2025 for hospitals and 31/12/2026 for other healthcare examination and treatment facilities within its rollout scope. It does not create a blanket rule that every record contains diagnostic images or that FHIR must be used. Where imaging belongs to the use-case record, an architecture may retain DICOM objects in PACS and use ImagingStudy/Endpoint for metadata, but that choice requires its own integration contract, security design, and tests. For more on the EMR and related FHIR resources, see the core FHIR Resources overview.

11. Frequently asked questions

How large is a typical DICOM file?

Study size varies widely with modality, protocol, series/instance count, resolution, bit depth, and transfer syntax. Measure the real workload before sizing storage, bandwidth, cache, or retrieval times; do not use one generic MB/GB range as a baseline.

Is the DICOM standard free?

The DICOM standard is available for access without charge at dicomstandard.org/current, but it remains NEMA material and its terms, trademarks, and any third-party rights still apply. PACS, viewer, modality, testing, and operational costs are separate.

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?

FHIR does not specify DICOM pixel structures, transfer syntaxes, or the VR/tag model. For a DICOM imaging use case, FHIR commonly complements the image objects with metadata or workflow rather than replacing them. The roadmap must follow image types, modality/PACS capabilities, and the contract; not every EMR is required to use one identical DICOM architecture.

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