DICOM vs. FHIR: What Radiology Software Buyers Actually Need to Know

If you're evaluating a vendor for a radiology or medical-imaging platform, you'll hear "DICOM" and "FHIR" used almost interchangeably in sales conversations. They aren't interchangeable, and confusing them leads to underspecified RFPs and integration surprises six months into a project.

What DICOM actually does

DICOM (Digital Imaging and Communications in Medicine) is the standard that governs how medical images themselves — CT scans, MRIs, X-rays, ultrasounds — are formatted, stored, transmitted, and queried. A DICOM file isn't just pixel data; it carries structured metadata (patient ID, study date, modality, series/instance identifiers) in the same file as the image. DICOM also defines network protocols (like C-STORE, C-FIND, C-MOVE, and the newer DICOMweb/WADO-RS HTTP-based services) that let a PACS (Picture Archiving and Communication System), a modality (the scanner itself), and a viewing workstation talk to each other reliably.

If your software needs to receive, store, display, or move actual imaging studies, you are working with DICOM. There's no substitute for it in this layer — it is the de facto universal standard across every major imaging modality vendor.

What FHIR actually does

HL7 FHIR (Fast Healthcare Interoperability Resources) is a general-purpose standard for exchanging clinical and administrative healthcare data — patient demographics, orders, results, encounters, care plans — using modern, REST-based APIs and JSON/XML payloads. FHIR doesn't know how to store a CT scan. What it does well is describe that an imaging study exists, who it's for, what it's for, and where to find it — using resources like ImagingStudy, DiagnosticReport, and ServiceRequest — so that an EHR, a referring physician's system, or a patient portal can reference and request imaging data without needing to understand DICOM internals directly.

In practice, a modern architecture uses both together: DICOM/DICOMweb handles the actual image bytes and imaging-specific workflow (modality worklists, image retrieval), while FHIR's ImagingStudy resource acts as the clinical-context bridge back to the rest of the patient's record in the EHR.

Where projects go wrong

The most common scoping mistake we see is a buyer asking for "FHIR integration" when what they actually need is DICOM connectivity to a PACS or VNA (vendor-neutral archive) — or the reverse, assuming a DICOM-capable vendor automatically understands how to expose that data cleanly to an EHR via FHIR ImagingStudy resources. These are genuinely separate integration efforts requiring different protocol expertise, and a vendor who's vague about which one they mean for which part of your workflow is worth pressing on specifics before you sign a statement of work.

Questions to ask a vendor

• Which specific DICOM services do you support — C-STORE, C-FIND, C-MOVE, DICOMweb (WADO-RS/QIDO-RS/STOW-RS)? Legacy TCP-based DICOM and modern web-based DICOMweb are not the same implementation effort.
• Do you expose imaging metadata via FHIR ImagingStudy, or only through a proprietary API?
• Is your archive a true VNA (vendor-neutral, standards-based storage) or a proprietary PACS that requires their own viewer/API to access studies?
• What FHIR version (R4, R4B, R5) do you support, and does your EHR/downstream system support the same version?

The bottom line

DICOM is the imaging-data layer; FHIR is the clinical-context and interoperability layer. A vendor who can speak fluently about both — and about exactly where the boundary between them sits in your specific workflow — is a much stronger technical partner than one who treats "healthcare interoperability" as a single undifferentiated buzzword.