DICOM Basics - FHIR and DICOM

Introduction

This is part of my series of articles on the DICOM standard. In this article, we'll explore how FHIR (Fast Healthcare Interoperability Resources) and DICOM work together to enable modern healthcare interoperability. As healthcare moves toward cloud-based and web-friendly solutions, understanding the integration between these two standards is increasingly important.

FHIR provides a modern, RESTful approach to healthcare data exchange, while DICOM remains the gold standard for medical imaging. Together, they enable comprehensive healthcare applications that can handle both clinical data and medical images.

FHIR and DICOM: Different but Complementary

FHIR and DICOM serve different purposes but are designed to work together:

AspectFHIRDICOM
FocusClinical data exchangeMedical imaging
ArchitectureRESTful web servicesNetwork protocols + file format
Data FormatJSON, XMLBinary with metadata
TransportHTTP/HTTPSDIMSE or DICOMweb
Resources150+ clinical resourcesImages, structured reports

The ImagingStudy Resource

FHIR's `ImagingStudy` resource is the primary bridge between FHIR and DICOM. It represents a DICOM study and provides references to the actual imaging data:

{
  "resourceType": "ImagingStudy",
  "id": "example",
  "status": "available",
  "subject": {
    "reference": "Patient/example"
  },
  "started": "2025-01-21T09:30:00Z",
  "numberOfSeries": 1,
  "numberOfInstances": 10,
  "series": [
    {
      "uid": "1.2.840.113619.2.21.848.34082.0.2025012109300564",
      "modality": {
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "CT"
      },
      "numberOfInstances": 10,
      "instance": [
        {
          "uid": "1.2.840.113619.2.21.848.34082.0.2025012109300565.1",
          "sopClass": {
            "system": "urn:ietf:rfc:3986",
            "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"
          }
        }
      ]
    }
  ],
  "endpoint": [
    {
      "reference": "Endpoint/dicom-wado-rs"
    }
  ]
}

Key ImagingStudy Attributes

The ImagingStudy resource maps DICOM concepts to FHIR:

FHIR ElementDICOM Source
subjectPatient reference
startedStudy Date/Time
series.uidSeries Instance UID
series.modalityModality (0008,0060)
instance.uidSOP Instance UID
instance.sopClassSOP Class UID
endpointDICOMweb server URL

Accessing Images via FHIR

FHIR provides several ways to access DICOM images:

1. ImagingStudy with DICOMweb Endpoint

The ImagingStudy resource can include an Endpoint reference pointing to a DICOMweb server:

{
  "resourceType": "Endpoint",
  "id": "dicom-wado-rs",
  "status": "active",
  "connectionType": {
    "system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type",
    "code": "dicom-wado-rs"
  },
  "address": "https://pacs.example.com/dicom-web"
}

2. Binary Resource

FHIR can store images as Binary resources, though this is less common for large imaging studies:

{
  "resourceType": "Binary",
  "contentType": "application/dicom",
  "data": "base64-encoded-dicom-data..."
}

3. DocumentReference

For encapsulated documents or rendered images:

{
  "resourceType": "DocumentReference",
  "content": [
    {
      "attachment": {
        "contentType": "image/jpeg",
        "url": "https://pacs.example.com/rendered/study/123/image.jpg"
      }
    }
  ]
}

DICOMweb and FHIR Integration

DICOMweb provides RESTful services that align well with FHIR's architecture:

DICOMweb ServicePurposeFHIR Integration
QIDO-RSQuery for studiesComplements ImagingStudy search
WADO-RSRetrieve imagesReferenced from Endpoint
STOW-RSStore imagesStore workflow

A typical integration pattern:

1. FHIR Server stores ImagingStudy resources
2. ImagingStudy references DICOMweb Endpoint
3. Client queries FHIR for imaging studies
4. Client retrieves actual images via DICOMweb WADO-RS

The ImagingSelection Resource (FHIR R5+)

Starting with FHIR R5, the `ImagingSelection` resource is available for referencing specific images or frames within a study. Note that this resource is not available in FHIR R4; it was introduced in R5:

{
  "resourceType": "ImagingSelection",
  "status": "available",
  "subject": {
    "reference": "Patient/example"
  },
  "studyUid": "1.2.840.113619.2.21.848.34082.0.2025012109300564",
  "seriesUid": "1.2.840.113619.2.21.848.34082.0.2025012109300565",
  "instance": [
    {
      "uid": "1.2.840.113619.2.21.848.34082.0.2025012109300565.1",
      "sopClass": {
        "system": "urn:ietf:rfc:3986",
        "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"
      },
      "imageRegion2D": [
        {
          "regionType": "POINT",
          "coordinate": [0.5, 0.5]
        }
      ]
    }
  ]
}

IHE Profiles for FHIR-DICOM Integration

IHE defines profiles for FHIR and DICOM integration:

ProfilePurpose
MHD (Mobile Access to Health Documents)Document sharing via FHIR
IMR (Interactive Multimedia Report)Multimedia radiology reports
IID (Invoke Image Display)Launch image viewer from FHIR app

Practical Integration Patterns

Pattern 1: FHIR as Index, DICOMweb for Images

Pattern 1: FHIR as Index, DICOMweb for Images saravanansubramanian.com FHIR ImagingStudy carries an Endpoint reference; the client fetches pixels from DICOMweb Client / Viewer EHR, mobile, radiology app FHIR Server metadata / index of studies DICOMweb Server pixel data via WADO-RS 1 GET ImagingStudy FHIR search by patient / accession 2 Return ImagingStudy resource includes Endpoint reference to WADO-RS base 3 Client follows Endpoint resolves study, series, instance UIDs on DICOMweb 4 WADO-RS Retrieve stream DICOM instances or rendered frames

Pattern 2: FHIR Clinical + DICOM Imaging

Pattern 2: FHIR Clinical + DICOM Imaging saravanansubramanian.com EHR splits responsibilities between FHIR for clinical data and DICOMweb for pixels EHR Application clinical workflow surface FHIR clinical / metadata plane Patient demographics DiagnosticReport Observations ImagingStudy metadata DICOMweb image / pixel plane Actual image retrieval (WADO-RS) Rendered thumbnails Full resolution frames

DiagnosticReport with Imaging

A radiology report in FHIR can reference both the ImagingStudy and key images:

{
  "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": "24627-2",
        "display": "Chest CT"
      }
    ]
  },
  "subject": {
    "reference": "Patient/example"
  },
  "imagingStudy": [
    {
      "reference": "ImagingStudy/chest-ct-study"
    }
  ],
  "conclusion": "No acute cardiopulmonary abnormality."
}

Note: The DiagnosticReport.imagingStudy element shown above is present in FHIR R4 but was renamed to DiagnosticReport.study in FHIR R5 so it can also reference GenomicStudy resources — not just imaging studies. If you need to reference specific images or frames rather than a whole study, use the new ImagingSelection resource (also introduced in R5).

Benefits of FHIR-DICOM Integration

  • Unified API: Access clinical and imaging data through consistent REST APIs
  • Modern Architecture: Web-friendly, mobile-ready applications
  • Interoperability: Connect imaging with broader healthcare ecosystem
  • Flexibility: Choose best-of-breed components for each domain
  • Cloud-Ready: Both FHIR and DICOMweb work well in cloud environments

Challenges and Considerations

  • Data Volume: Imaging data is much larger than typical FHIR resources
  • Performance: Need efficient caching and CDN strategies for images
  • Consistency: Keep FHIR ImagingStudy in sync with PACS
  • Security: Different authentication models may need bridging

Conclusion

FHIR and DICOM are increasingly used together to build comprehensive healthcare applications. FHIR provides the modern, RESTful architecture for clinical data, while DICOM (especially DICOMweb) handles the specialized needs of medical imaging. The ImagingStudy resource serves as the bridge, providing metadata and references to the actual imaging data.

As healthcare moves toward cloud-based solutions and patient-centered care, understanding how to integrate these standards effectively is essential for developers working in healthcare IT.