AnpherosAnpheros PlatformDevelopers

DICOM vs FHIR: imaging data and clinical data

DICOM carries medical images, FHIR the clinical data around them: what each covers, how ImagingStudy and DiagnosticReport connect, and what to store where.

DICOM and FHIR are not competitors: DICOM is the standard for medical images — the pixels and the technical metadata of an X-ray, CT or MRI — while HL7 FHIR is the standard for clinical data around them, such as the order, the radiologist's report, the findings and the patient they belong to. A typical imaging workflow uses both: the scanner and the PACS speak DICOM, the hospital and patient apps speak FHIR, and FHIR resources point to the DICOM study rather than copying it. This page explains where each standard starts and stops, how they connect, and what a FHIR backend such as Anpheros should and should not store.

The short answer

DICOM HL7 FHIR R4
What it carries Images and their metadata (modality, body part, slice spacing, device, UIDs) Clinical data: patients, orders, reports, observations, medications…
Typical size Megabytes to gigabytes per study Kilobytes per resource
Unit of data Study → Series → Instance, identified by globally unique UIDs Resources (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) with references
Transport DIMSE network services (C-STORE, C-FIND, C-MOVE) and DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS) REST over HTTPS with JSON or XML
Stored in PACS or vendor-neutral archive (VNA) EHR, FHIR server, health data platform
Read by Radiology viewers, AI image models, modalities Clinical apps, patient apps, analytics, AI working on text and values

What DICOM is for

DICOM (Digital Imaging and Communications in Medicine) defines how an image is encoded and how imaging equipment exchanges it. Every image file carries a header with hundreds of attributes — patient and study identifiers, modality (CT, MR, DX, US…), acquisition parameters, pixel spacing — next to the pixel data. Images are grouped as instances inside series inside a study, each with a UID such as 2.25.181945…, so the same study can be found again in any archive.

DICOMweb brought DICOM to HTTP: QIDO-RS to search for studies, WADO-RS to retrieve them, STOW-RS to store them. That makes images reachable from web viewers and cloud services, but the payload is still DICOM.

What DICOM does not do well is the clinical story: why the study was ordered, what the radiologist concluded, which problem it relates to, and how it fits with lab results and medications. That is FHIR's job.

What FHIR does around imaging

FHIR R4 has resources for each step of an imaging workflow:

An ImagingStudy that points to a study in a PACS (valid FHIR R4 structure):

{
  "resourceType": "ImagingStudy",
  "status": "available",
  "subject": {"reference": "Patient/example"},
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
  "started": "2026-10-03T10:20:00-05:00",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
  "numberOfSeries": 1,
  "numberOfInstances": 2,
  "endpoint": [{"reference": "Endpoint/pacs-wado"}],
  "series": [{
    "uid": "2.25.30584718293846127394857102938475",
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 2,
    "instance": [{"uid": "2.25.11223344556677889900112233445566",
                  "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
  }]
}

The report on the same study, as a DiagnosticReport (it passes the FHIR R4 validator):

{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
  "subject": {"reference": "Patient/example"},
  "effectiveDateTime": "2026-10-03T10:20:00-05:00",
  "issued": "2026-10-03T15:05:00-05:00",
  "performer": [{"display": "Springfield Imaging Center"}],
  "conclusion": "No acute cardiopulmonary abnormality.",
  "presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}

How the two connect

 modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
                                         ▲
                     ImagingStudy.endpoint│ (where the images are)
                                         │
 order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
                                                                       │
                                     patient app, clinic system, AI assistant (text and values)

The rule that keeps systems simple: images stay in the imaging archive; the clinical record keeps the report, the findings that matter and a pointer to the images. Copying DICOM studies into a clinical database multiplies storage and privacy risk without making the record more useful to most of its readers.

Other standards fill the gaps between hospitals: IHE profiles such as XDS-I for sharing imaging documents across organisations, and FHIRcast for keeping a radiology viewer and a reporting application on the same patient and study.

Imaging, interoperability and AI

AI on medical images (detection, segmentation, triage) works on DICOM pixel data, usually inside the imaging department or a specialised platform. AI that helps a patient or a doctor reason about the whole record — "what did the last chest X-ray show, and how does it relate to the cough and the antibiotics?" — works on the report, the findings and the rest of the clinical data, which is what FHIR carries. Both kinds of AI need the same thing from infrastructure: data with codes, times and a recorded origin.

Where Anpheros fits

Anpheros stores each patient's record as HL7 FHIR R4. For imaging that means:

In the Anpheros Daily app, a patient can photograph or upload an imaging report and keep it in their documents next to the rest of their record. For a developer building an app or a clinic integration, the practical split is: keep images in your imaging system, write the report and the findings to the patient's FHIR record. How to integrate clinic systems with a FHIR backend shows how to write a visit and its documents in one transaction, and the DiagnosticReport example shows the structure of a report.

Frequently asked questions

What is the difference between DICOM and FHIR?

DICOM encodes and exchanges medical images and their technical metadata; FHIR exchanges clinical data such as orders, reports, observations and medications. In practice FHIR resources describe and reference imaging studies, while the images themselves stay in DICOM.

Can FHIR store medical images?

FHIR can carry small images as attachments (a key image in a DocumentReference or Media), but it is not designed for full diagnostic studies. The ImagingStudy resource describes a DICOM study and points to where it can be retrieved; the pixels stay in a PACS or archive.

What is DICOMweb?

The RESTful part of the DICOM standard: QIDO-RS to search, WADO-RS to retrieve and STOW-RS to store studies over HTTP. A FHIR ImagingStudy can point to a DICOMweb endpoint.

Which FHIR resource holds a radiology report?

DiagnosticReport, with a radiology category, a LOINC code for the exam, a conclusion and, if needed, the original report as a PDF in presentedForm. Measurements that must be searchable become separate Observations.

Does Anpheros support DICOM?

No. Anpheros stores the clinical side of imaging — reports, findings, documents and orders — in the patient's FHIR R4 record. It does not store, serve or interpret DICOM images and does not support ImagingStudy today.

Related