DICOM and FHIR in the Same System: Integration Patterns for Imaging-Heavy Platforms

DICOM and FHIR are two healthcare standards that address different problems and increasingly need to work together in the same system: DICOM (Digital Imaging and Communications in Medicine) encodes and transmits medical images, while FHIR (Fast Healthcare Interoperability Resources) exchanges clinical and administrative data via a RESTful API. An imaging-heavy platform needs both, and making them coexist is a specific engineering problem rather than a matter of adopting one or the other.

The two standards were designed decades apart for different worlds. DICOM has governed medical imaging since the 1990s and models the structure of pixel data at the study, series, and instance levels. FHIR is the modern API standard that unifies labs, medications, notes, and patient records. Plenty of content explains each standard on its own; very little explains how to make them coexist, which is the actual work when you build a platform that has to show images alongside the rest of the clinical record. This guide covers the integration patterns: the division of labor between the two, the FHIR ImagingStudy bridge, DICOMweb retrieval, and the difference between data synchronization and context synchronization, two patterns that are constantly confused.

Atta Systems builds medical device software under its own ISO 13485-certified quality management system and has built the Medicai cloud imaging platform, which exposes imaging through a DICOM-standard backend and an imaging API, compliant with HL7 and FHIR, to surrounding clinical systems.

The division of labor: what each standard owns

DICOM owns the images, and FHIR owns the clinical context, and the first step in any integration is to keep that division clear rather than trying to make one standard do the other’s job. DICOM handles the acquisition, encoding, storage, and transfer of pixel data and its imaging-specific metadata, and it is the language that modalities and a cloud PACS architecture speak. FHIR handles the patient, the order, the encounter, the report, and the rest of the clinical record, and it is the language the EHR and modern applications speak.

The integration exists precisely because each standard is weak where the other is strong. FHIR cannot store or serve the pixels, and DICOM is awkward to query as part of the wider clinical record. So the pattern is not to convert one to the other, but to let each do its job and build a bridge between them.

The bridge: the FHIR ImagingStudy resource

The FHIR ImagingStudy resource is the bridge between the two standards: it represents a DICOM study inside the FHIR model without holding the images themselves. It captures the study, series, and instance metadata and references the images by their DICOM identifiers, so a system with FHIR access can find a patient’s imaging history alongside their labs and notes through the same API. This article describes ImagingStudy as it stands in FHIR R4, the version most production systems run on; the resource differs somewhat in R5, as noted below where it matters.

What an ImagingStudy resource actually holds:

• The DICOM identifiers. The StudyInstanceUID, and the series and SOP instance Unique Identifiers (UIDs), which uniquely identify the study, its series, and its individual images in the DICOM world.
• The clinical links. References to the FHIR Patient, ServiceRequest (the order), and Encounter, which is what places the imaging in the clinical record.
• The study metadata. Modality, number of series and instances, body site, and description, mapped from the DICOM header into FHIR fields.
• An Endpoint reference, not the pixels. An ImagingStudy points to a FHIR Endpoint resource that provides the DICOMweb address where the actual images are stored. The images are never copied into FHIR; the resource references where to retrieve them.

This last point is the one teams most often get wrong. FHIR does not store or replace DICOM images. The ImagingStudy resource serves as an index and reference, while the pixels remain in the PACS or VNA and are retrieved via DICOMweb. For frame-level or region-of-interest references, FHIR R5 added the ImagingSelection resource, which points to a subset of a study rather than the whole thing; a team on R4 does not have it and works at the study, series, and instance level.

Retrieval: DICOMweb is how the pixels actually move

DICOMweb is the retrieval layer that turns an ImagingStudy reference into actual images: once a system has found a study through FHIR, it uses DICOMweb to fetch the pixels over HTTP. The FHIR Endpoint on the ImagingStudy resource points to the DICOMweb service, and the three DICOMweb operations do the work.

• QIDO-RS to search. Query based on ID for DICOM Objects lets a system search studies and series without downloading anything, which is how an application confirms what is available before retrieving it.
• WADO-RS to retrieve. Web Access to DICOM Objects lets a system fetch specific DICOM instances over HTTP, so an application can pull exactly the images it needs on demand rather than moving whole studies.
• STOW-RS to store. Store Over the Web handles sending new instances into the archive over HTTP.

The value of this split is that the FHIR layer answers “what imaging does this patient have and where is it,” and the DICOMweb layer answers “give me those pixels.” An AI tool, a viewer, or an EHR can find imaging through the standard FHIR API and then retrieve it through standard DICOMweb, without going through a proprietary PACS interface. That is what makes imaging a first-class part of an interoperable platform rather than a walled-off silo.

Data sync versus context sync: DICOMcast and FHIRcast

Data synchronization and context synchronization sound similar and solve entirely different problems, and confusing them is one of the most common mistakes in imaging integration. Data sync keeps imaging data in step between the DICOM and FHIR worlds; the best-known implementation is DICOMcast, a Microsoft capability. Context sync keeps the clinical context in step across the applications a user is working in; it is defined by FHIRcast, an HL7 standard. One is about data; the other is about what is on the screen.

Data sync: DICOMcast, a Microsoft implementation

DICOMcast is Microsoft’s open-source capability in Azure Health Data Services that implements the data-synchronization pattern; it is a specific product, not a standard. It watches the DICOM service’s change feed for new studies, extracts metadata from the DICOM header, maps DICOM tags to FHIR fields, and writes the result to a FHIR server, synchronizing DICOM tags to the Patient and ImagingStudy resource types so that both the patient record and the imaging appear in FHIR. It currently supports FHIR R4. The hard part is the mapping: scanner vendors implement DICOM inconsistently, especially older equipment, so a production adapter needs validation rather than a naive copy. DICOMcast makes this concrete with a setting, EnforceValidationOfTagValues, that refuses to write a change-feed entry to FHIR unless every mapped tag is valid, which is exactly the guard a serious integration needs against bad or missing tags (body site and similar fields are common offenders).

Context sync: FHIRcast, an HL7 standard

FHIRcast is an HL7 standard, a publish-and-subscribe protocol built on HTTP and WebSockets, that keeps applications on the same clinical context in real time. A driving application, such as a PACS or an EHR, acts as a hub. When a radiologist opens a study, the hub broadcasts an event (for example, an ImagingStudy-open event), and the subscribed applications — a viewer, a reporting tool, a dictation app, an AI assistant — follow the same patient and study. Without it, a clinician who switches patients in one application has to manually re-navigate in every other, which is both slow and a patient-safety risk if the applications drift out of sync.

The hard parts, and how to design around them

Making DICOM and FHIR coexist has three recurring failure points, and a platform that plans for them from the start avoids the rework that catches teams who treat the integration as an afterthought.

• Tag-to-field mapping and vendor inconsistency. DICOM headers from different scanners, especially older ones, are inconsistent, so the mapping from DICOM tags to FHIR fields needs validation rather than a naive copy, as DICOMcast’s tag-validation setting enforces. Build the adapter to catch and quarantine bad data rather than trust the header.
• Patient identity across two worlds. The same patient exists as DICOM tags in the images and as a FHIR Patient resource in the record, and the two can disagree. This is why a sync mechanism that writes both Patient and ImagingStudy, as DICOMcast does, still needs a deliberate identity reconciliation step, so that an ImagingStudy attaches to the correct patient rather than creating a duplicate or a mismatch.
• Keeping the index and the pixels consistent. FHIR indexes the imaging data, and DICOMweb serves it, so the ImagingStudy references must remain valid as studies are added, moved, or purged from the archive. A reference that points to images that are no longer where it says is worse than no reference at all.

Atta Systems builds imaging platforms, including Medicai, which integrates with clinical systems via HL7 and FHIR, so the imaging record and the clinical record stay connected, with tag mapping, identity reconciliation, and reference integrity designed in rather than discovered when data drifts.

FAQ about DICOM and FHIR integration

13485-certified quality management system, including the Medicai platform and its cloud PACS architecture, designing the DICOM and FHIR layers to stay consistent from the first version.

Atta Systems focuses on custom medical imaging and healthcare interoperability software, where imaging and clinical data standards are integrated by design, rather than off-the-shelf PACS resale or single-standard tools that leave the DICOM-to-FHIR bridge as someone else’s problem.