DICOM and FHIR: Why you need both, not one or the other

By Remco Leemans, Radiology Systems Specialist at Interoplab

There’s a persistent myth in healthcare IT: FHIR® replaces DICOM.

It doesn’t. And understanding why is critical for anyone building modern interoperability infrastructure.

What DICOM does

DICOM (Digital Imaging and Communications in Medicine) handles images and their associated metadata. When a radiologist takes an X-ray, DICOM describes:

• The image itself (pixel data, compression, quality)
• How it was acquired (modality, exposure settings, timestamp)
• Who it’s for (patient ID, accession number)
• Quality assurance metadata (calibration, dose tracking)

DICOM is format-agnostic for the image data itself — it’s pure binary. The standard defines how to package and transmit that binary with structured metadata.

DICOM has been the standard for medical imaging for 30 years. It’s deeply embedded in imaging equipment (CT scanners, ultrasound machines, X-ray systems), PACS systems, and radiologist workflows.

What FHIR® does

FHIR (Fast Healthcare Interoperability Resources) is about data exchange in a web-friendly format. When an HIS (hospital information system) needs to tell a radiology system “here’s the patient, here’s the referral, here’s the clinical context,” FHIR® is the language.

FHIR Resources like:

• Patient: Demographics and identification
• Observation: Results and measurements
• ImagingStudy: Reference to imaging and how it relates to the patient journey
• ServiceRequest: The clinical request that triggered the imaging

FHIR is structured, queryable, and integrates naturally with web services and modern healthcare applications.

Where they meet: ImagingStudy

The bridge between FHIR® and DICOM is the FHIR® ImagingStudy Resource.

An ImagingStudy doesn’t contain the image itself — it references DICOM images and organizes them hierarchically:

ImagingStudy (e.g., "Chest X-ray on 2025-01-15")
├── Series (e.g., "PA view")
│   ├── Instance 1 (the actual DICOM file)
│   ├── Instance 2 (secondary capture)
│   └── Instance 3 (archived version)
└── Series (e.g., "Lateral view")
    └── Instance 1 (the actual DICOM file)

The ImagingStudy provides clinical context (why was this study done?), workflow information (who ordered it?), and references to the DICOM images themselves.

A practical example

Let’s trace an imaging workflow:

Traditional (DICOM-only):

1. HIS sends accession number and patient ID to PACS
2. Radiologist pulls images in PACS
3. Radiologist reviews and signs off
4. PACS sends results back to HIS
5. HIS displays results to clinician

Problems:

• Limited context in the imaging system about why the study was ordered
• Results routing is fragile (if the HIS can’t match the accession, the result is lost)
• Clinical alerts (e.g., “critical finding”) are manual workarounds
• No standardized way to access imaging from external systems

Modern (FHIR + DICOM):

1. HIS creates a ServiceRequest (FHIR) for “Chest X-ray, rule out pneumonia”
2. PACS receives the ServiceRequest via FHIR
3. Technologist confirms patient in PACS, acquires images (DICOM)
4. PACS creates an ImagingStudy (FHIR) linking the clinical request to the images
5. Radiologist reviews images, creates an Observation (FHIR) with the report text
6. External systems can query the patient’s imaging history via FHIR
7. Clinical alerts are part of the structured Observation — not manual notes

Benefits:

• Clinical context is always present
• Workflow is automated and less error-prone
• Results are findable from any system
• Integration with clinical decision support systems is straightforward

The technical reality

If you’re building healthcare systems in 2025:

You cannot ignore DICOM. Imaging equipment speaks DICOM. PACS systems store and retrieve DICOM. Decades of clinical workflows and best practices are built on DICOM.

You need FHIR® for the surrounding context. Patient data, clinical requests, results, orders, and clinical context flow through FHIR.

Your architecture should use both. DICOM for imaging, FHIR® for everything else. The ImagingStudy Resource is your integration point.

Common misconceptions

“We’ll replace DICOM with FHIR.” You can’t. FHIR® can’t replace DICOM’s efficiency for transmitting gigabytes of pixel data. DICOM isn’t going anywhere.

“ImagingStudy is optional.” If you’re building modern imaging systems, it’s not. ImagingStudy is how you make imaging discoverable and clinically integrated.

“We can ignore imaging if we’re not a radiology vendor.” Even if you’re building an EHR, a care management system, or a patient portal, you’ll need to display, reference, or integrate imaging at some point. ImagingStudy is how you do that.

“DICOM and FHIR® will eventually merge.” They won’t, because they solve different problems. DICOM will evolve. FHIR® will evolve. But they’ll remain complementary, not competitive.

Building for interoperability

If you’re designing healthcare systems for 2025 and beyond:

1. Use DICOM for images. It’s efficient and universal.
2. Use FHIR® for clinical context. It’s modern and integrable.
3. Map imaging to ImagingStudy. This is how you make imaging part of the patient record.
4. Test with both standards. Validate that your DICOM transmits correctly and that your ImagingStudy is semantically valid.

---

Building imaging interoperability? Let’s talk →