Imaging workflows sit at the awkward intersection of FHIR and DICOM, two standards that solve different parts of the same problem. A FHIR integration engine in an imaging context has to handle ImagingStudy and DiagnosticReport resources, link out to the DICOM-served pixel data, and carry the radiologist report content through the rest of the clinical stack. The five engines below hold up in imaging workflows in 2026. The complete guide to FHIR integration engines covers the broader frame.
For more reviews of this kind, the FHIR shortlist archive gathers the rest of the relevant comparisons.
The Five That Suit Imaging Workflows
- InterSystems IRIS for Health. The multi-protocol heritage handles DICOM alongside HL7 v2 and FHIR in the same engine, which suits radiology departments with deep DICOM investment.
- HAPI FHIR with a DICOMweb bridge. The open-source path; HAPI for the FHIR ImagingStudy and DiagnosticReport surface, paired with a DICOMweb server (dcm4che, Orthanc) for the pixel data.
- Google Cloud Healthcare API. Native DICOM and FHIR APIs in one managed service; the cleanest cloud-managed story for an imaging program already on GCP.
- Smile Digital Health. HAPI's commercial distribution with a paid support contract; suits hospital radiology IT that wants the HAPI stack with vendor accountability.
- Microsoft FHIR Server for Azure with DICOM Service. The Azure pair: FHIR Server for ImagingStudy, the DICOM Service for pixel data, both managed by Azure.
What Imaging Workflows Demand
Three patterns separate imaging integration from general clinical integration.
The first is the FHIR-to-DICOM bridge. ImagingStudy and DiagnosticReport resources reference the DICOM-served pixel data via WADO URLs; the engine has to handle the cross-protocol reference cleanly so a downstream clinical viewer can navigate from the FHIR side to the DICOM side without manual stitching. Engines that treat the WADO URL as an opaque string work; engines that resolve and validate the reference work better.
The second is the report-content story. A radiologist's report is structured text with sections (impression, findings, recommendations) that should land as a DiagnosticReport with PresentedForm and a Composition where possible. Engines that handle structured-report content carry the clinical meaning forward; engines that treat the report as a single blob lose it.
The third is the volume pattern. Imaging studies generate large numbers of small FHIR resources (one ImagingStudy per study, one DiagnosticReport per read) on a relatively predictable cadence. Engines that scale linearly with this volume are fine; engines that hit hot-key problems on Patient-keyed queries when the study volume grows quickly are operationally fragile. The top 6 FHIR bulk data servers for ACO reporting review covers a related volume scenario where the same engines often appear.
The Pilot Worth Running
The pilot for an imaging workflow is to run an end-to-end study capture: ingest a synthetic ImagingStudy, link it to the DICOM service, generate a DiagnosticReport with structured sections, and verify that a clinical viewer can navigate from the FHIR side to the DICOM side without manual translation. Engines that complete that round trip cleanly are serious candidates.
For specialty-network integration patterns that share the multi-resource graph pattern, the best FHIR integration engines for behavioral health networks covers a different domain with a similar engine archetype mix. Imaging integrations rarely fail on the FHIR side; they fail at the FHIR-to-DICOM boundary, which is exactly where the pilot has to focus the most attention.
Sources
- DICOM WG-06 review March 2025 - wiki, HL7 Imaging Integration WG, 2025
- Large-Scale Integration of DICOM Metadata into HL7-FHIR - paper, PMC/NIH, 2025
- DICOM SR Measurement Report IG - wiki, HL7 Imaging Integration WG, evergreen
