FHIR ImagingStudy vs DICOMweb: metadata in FHIR, pixels in DICOM, with an example

Short answer: ImagingStudy is a FHIR resource that says this patient had a CT on this date, with these series and these instance UIDs, and the images are over there. DICOMweb is the over there: the REST interface of the archive that holds the pixels. FHIR carries the description and the report; DICOM carries the images. An ImagingStudy references an Endpoint resource whose connectionType is dicom-wado-rs, and a viewer combines the two.

What ImagingStudy contains

A FHIR ImagingStudy resource contains the metadata of one imaging study: the DICOM Study Instance UID as an identifier, a status, the subject Patient, encounter, start time and ordering ServiceRequest, modality codes from the DICOM DCM vocabulary, counts of series and instances, the Endpoint where the images live, and each series with its instances and UIDs. It holds no pixels.

• identifier: the DICOM Study Instance UID, as urn:oid:1.2.840… with system urn:dicom:uid;
• status: registered, available, cancelled, entered-in-error, unknown;
• subject: the Patient; encounter, started, referrer, basedOn (the ServiceRequest that ordered it);
• modality: codes from DICOM's own vocabulary (CT, MR, US, CR, DX…), system http://dicom.nema.org/resources/ontology/DCM;
• numberOfSeries, numberOfInstances;
• endpoint: where to fetch the images;
• series[]: each with its Series Instance UID, modality, body site, instance[] with SOP Instance UID and SOP Class UID.

What it does not contain: pixel data, window settings, the full DICOM header, or the report text. The report is a DiagnosticReport with imagingStudy pointing back.

A valid FHIR R4 example

A valid FHIR R4 ImagingStudy example carries the Study Instance UID as an identifier with system urn:dicom:uid, status available, a CT modality from the DICOM DCM code system, the patient, the start time, series and instance counts, a reference to an Endpoint of connectionType dicom-wado-rs, and series entries with their UIDs, body site and SOP Class UID.

{
  "resourceType": "ImagingStudy",
  "id": "ct-chest-2026-03",
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
  "status": "available",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
  "subject": {"reference": "Patient/example"},
  "started": "2026-03-14T09:12:00+01:00",
  "numberOfSeries": 2,
  "numberOfInstances": 412,
  "endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
  "series": [{
    "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
    "number": 1,
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 410,
    "instance": [{
      "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
      "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
      "number": 1
    }]
  }]
}

The SOP Class UID 1.2.840.10008.5.1.4.1.1.2 is CT Image Storage. The Endpoint looks like this:

{
  "resourceType": "Endpoint",
  "id": "pacs-dicomweb",
  "status": "active",
  "connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
  "payloadType": [{"text": "DICOM WADO-RS"}],
  "address": "https://pacs.example-hospital.org/dicomweb"
}

A viewer builds the retrieval URL from the two: {Endpoint.address}/studies/{StudyInstanceUID}, then calls WADO-RS for metadata and frames.

Who creates ImagingStudy resources

ImagingStudy resources are usually created by a FHIR facade in front of the PACS or VNA, or by an integration engine, when a study is complete, often triggered by the HL7 v2 ORU or the DICOM MPPS message. Some archives generate them on the fly from a QIDO-RS query. The scanner itself does not create ImagingStudy resources.

Usually not the scanner. A FHIR facade in front of the PACS or VNA, or an integration engine, creates the ImagingStudy when the study is complete (often triggered by the HL7 v2 ORU or the DICOM MPPS message) and keeps numberOfInstances in sync. Some archives generate ImagingStudy on the fly from a QIDO-RS query. If your project writes them by hand, the UIDs must match the archive exactly, character for character, or the viewer will show an empty study.

Mistakes that break viewers

The mistakes that break viewers reading a FHIR ImagingStudy are: putting the Study UID in id instead of identifier, using a non-DICOM modality code, pointing an Endpoint with the wrong connectionType at a DICOMweb server, leaving series and instance counts stale after images change, and expecting pixel data in a FHIR Binary instead of a DICOM archive.

• Putting the Study UID in id instead of identifier; FHIR ids are server-assigned and may not be OIDs.
• A modality from SNOMED or a local list instead of the DICOM DCM code system.
• An Endpoint with connectionType hl7-fhir-rest pointing to a DICOMweb server, or the reverse.
• Counting series and instances once and never updating when images are added or deleted.
• Expecting the pixel data in FHIR Binary. The FHIR specification itself says images belong in DICOM, not in Binary.

In an Anpheros record

Anpheros Platform does not host ImagingStudy or DICOM data. Radiology findings arrive as DiagnosticReport or DocumentReference (the report, with its codes and text); where the hospital exposes a viewer link, the DocumentReference can carry it as an attachment URL. The images remain in the hospital's archive under its access rules.

Related pages

• DICOMweb explained
• DICOM tags explained
• DocumentReference vs DiagnosticReport vs Binary
• PACS vs RIS vs VNA
• CT scan report explained
• DICOM vs FHIR for developers

Sources

• HL7 FHIR R4: ImagingStudy
• HL7 FHIR R4: Endpoint
• HL7 FHIR R4: endpoint-connection-type code system
• DICOM PS3.16: DCM controlled terminology (CID 29 Acquisition Modality)
• DICOM PS3.18: Web Services

Frequently asked questions

Can a FHIR server store the images themselves?

Technically a Binary can hold any bytes, but the FHIR specification recommends against it for imaging and no viewer works that way. Images stay in a DICOM archive; FHIR points to it.

What changed in FHIR R5 for ImagingStudy?

R5 keeps the same shape, tidies naming (for example procedure replaces procedureReference and procedureCode) and aligns body site handling. R4 remains the version most archives and national profiles use.

How does the report link to the images?

DiagnosticReport.imagingStudy references the ImagingStudy; DiagnosticReport.media can carry key images as Media resources. The ImagingStudy references the Endpoint for the full study.

Do I need ImagingStudy if I already have DICOMweb?

Only if other FHIR consumers need to know the study exists, for example a patient app, a care plan or a research export. A radiology viewer alone can live on QIDO-RS and WADO-RS.

Anpheros Daily

Try it in Anpheros Daily

Keep your scan and test reports in one place in Anpheros Daily, ready to show at your next visit.

How it works in the app →

iPhone & MacAndroidOpen in your browser →

Written by

The Anpheros team

Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.

About Anpheros →

Anpheros

The more you log, the clearer your record

Your health history in one place, under your control.

Symptom diaryPatterns show over time

Emergency cardQR in your phone's Wallet

All your resultsLabs and reports together

You decideWho sees what, and for how long

Create your free account

Free · Works in your browser · No card