If your radiology team is planning an EHR integration or building a new imaging workflow, you have almost certainly encountered the phrase “FHIR API” by now. Chances are, the conversation started with “we need FHIR support” and quickly stalled on what that actually means in practice. FHIR is not a single plug-in or an on/off capability. It is a structured set of resources and a RESTful API pattern, and understanding which resources matter for imaging is what separates a successful integration from a frustrating one.
This guide focuses on the three FHIR resources that drive medical imaging workflows, how they connect to each other, and what a real implementation sequence looks like from order to report.
The Three FHIR Resources That Drive Radiology Workflows
Before touching any API, your team needs a clear mental model of the FHIR resource structure for imaging. Most “FHIR overview” content glosses over this, leaving radiology IT teams to discover the relationships through trial and error.
ServiceRequest: Where Every Imaging Order Begins
A ServiceRequest in FHIR represents an order for a diagnostic procedure. When a clinician orders an MRI, the ordering system creates a ServiceRequest resource that carries the patient reference, the requested procedure code (typically from LOINC or SNOMED CT), the ordering provider, and the clinical indication.
The ServiceRequest bridges the EHR side of the workflow and the radiology side. In a FHIR-native integration, the RIS or PACS retrieves the ServiceRequest, schedules it, and maps it to a DICOM Modality Worklist (MWL) entry so the scanner can automatically retrieve the accession number and patient demographics. This is the FHIR equivalent of the HL7 v2 ORM (Order Message) that most radiology teams know well.
A key field to get right is the basedOn element in an ImagingStudy resource that links back to the originating ServiceRequest. Without this link, EHRs cannot close the loop between an order and its resulting images.
ImagingStudy: The FHIR Representation of a DICOM Study
The ImagingStudy resource is the backbone of FHIR imaging integration. It maps directly to a DICOM study, exposing study-level metadata (study instance UID, modality, body site, number of series and instances) through a standard REST API without requiring the consuming application to speak DICOM natively.
Each ImagingStudy contains endpoint references pointing to the WADO-RS service URL of the underlying PACS. This means an EHR or clinical decision support tool can query for a patient’s imaging studies via a simple FHIR API call, read the metadata, and construct the WADO-RS URL to retrieve the actual DICOM instances or rendered JPEG images, all without a direct PACS connection.
The key fields your integration team needs to populate correctly:
identifier: the DICOM Study Instance UID, encoded asurn:oid:{uid}in theurn:dicom:uidsystemstatus: must be set toavailableonce images are committed to the PACS archivesubject: references the FHIR Patient resourceendpoint: points to the WADO-RS service URL of the PACSbasedOn: links back to the ServiceRequest that triggered the study
OmniPACS exposes FHIR R4-compatible ImagingStudy resources for every study in the archive, enabling any FHIR-capable EHR to query a patient’s imaging history without a custom point-to-point interface.
DiagnosticReport: Attaching Findings to the Study
DiagnosticReport is the FHIR resource that represents the radiologist’s report. It references both the ImagingStudy (via the imagingStudy element) and the Patient, and carries the report status, conclusion text, and any structured findings as referenced Observation resources.
For most radiology implementations, the DiagnosticReport is generated by the RIS or dictation system after the radiologist signs the report, and pushed to the EHR FHIR server as a completed resource. This is where the RIS PACS integration layer becomes critical: the RIS must be able to resolve the ImagingStudy ID so the DiagnosticReport correctly links the text findings to the image evidence.
A common implementation gap is breaking this link. If the RIS uses a proprietary accession number while the FHIR server uses the DICOM Study UID, the DiagnosticReport and ImagingStudy end up orphaned from each other in the EHR’s record. Establishing a consistent cross-reference between accession numbers and study UIDs early in the integration design prevents this.
The FHIR API Call Sequence for a Radiology Order
Understanding the individual resources is step one. Understanding how they call each other in sequence is what makes an implementation actually work.
Order to Image: The Request Flow
- Clinician places order in EHR. EHR creates a ServiceRequest resource and exposes it on the FHIR server.
- RIS polls or subscribes to new ServiceRequest events (via FHIR subscriptions) and retrieves the order details.
- RIS creates the DICOM MWL entry from the ServiceRequest data. Modality picks up the worklist and proceeds with imaging.
- After the study is complete, PACS creates an ImagingStudy resource with
status: availableand links it to the original ServiceRequest viabasedOn. - EHR queries the FHIR server:
GET /ImagingStudy?patient={patientId}&status=availableand receives the updated ImagingStudy, allowing clinicians to view images directly from the chart.
Report to Chart: The Results Flow
- The radiologist dictates and signs the report in the RIS.
- RIS creates a DiagnosticReport resource, referencing the ImagingStudy and the Patient, with
status: final. - DiagnosticReport is pushed to the EHR FHIR server.
- Ordering clinician’s chart reflects the completed report, with a direct link to the image study.
This flow represents what your medical imaging system integration architecture should look like when built on FHIR. In practice, many environments use a hybrid approach in which the v2 ADT and order messages handle real-time event routing within the hospital network, while FHIR handles the data access layer that external applications and patient portals consume.
SMART-on-FHIR App Launch and FHIRcast Context Sync
Two protocols deserve specific attention for radiology teams building modern viewers and reporting workflows.
SMART-on-FHIR App Launch
SMART-on-FHIR is an authorization framework built on top of the FHIR API that allows third-party applications to launch within an EHR context with single sign-on. For radiology, this means a PACS viewer or AI tool can open directly from a patient’s chart, pre-loaded with the correct study, without a separate login.
The launch sequence works like this: the EHR passes a launch token and FHIR server base URL to the app via a redirect. The app uses these to request an access token scoped to the specific patient and encounter context. From there, the app queries the FHIR server for the relevant ImagingStudy resources and uses the endpoint references to retrieve images via WADO-RS. OmniPACS supports SMART-on-FHIR launching, allowing authorized applications to open studies directly from within compatible EHR environments.
FHIRcast: Keeping Multiple Apps in Sync
FHIRcast solves a specific problem that every radiologist knows: when you have a RIS, a PACS viewer, and a dictation system open simultaneously, switching studies in one application does not automatically update the others. FHIRcast provides a publish-subscribe mechanism built on FHIR events, so that when a radiologist opens a study in the worklist, the PACS viewer and dictation system receive a notification and automatically switch to the same study context.
This matters because the alternative is manual re-selection across three applications per study, which at volume becomes a significant source of workflow friction and occasional context errors. Radiologists working with OmniPACS in multi-application environments benefit from FHIRcast-compatible context synchronization, keeping PACS, reporting, and dictation aligned without manual switching.
FHIR vs HL7 v2: When to Use Each in Radiology
The FHIR adoption conversation in radiology IT is often framed as a replacement question. It is better framed as a routing question: which protocol fits which part of the workflow?
Use HL7 v2 when you need:
- High-volume, event-driven messaging inside a hospital network (ADT events, order creation, result delivery)
- Real-time bidirectional communication with legacy RIS, HIS, or order entry systems that speak v2 natively
- Low-latency triggers where pipe-delimited messages over MLLP are already established and stable
Use FHIR API when you need:
- EHR integration via a standard API (Epic, Cerner, Oracle Health all publish FHIR R4 endpoints)
- Patient portal or mobile access to imaging reports and image links
- Cross-enterprise data sharing where organizations need a common API contract without custom interface engines
- Launching third-party apps (AI tools, second-opinion platforms, telehealth viewers) with contextual access to imaging data
Most mature radiology environments in 2025 and 2026 run both in parallel. The v2 layer handles the internal scheduling and results workflow, where it already works reliably. FHIR sits at the boundary, handling the API access layer for EHR integration, patient-facing access, and modern application launch. The EHR PACS integration challenges that teams encounter most often come from trying to force one protocol into a job for which the other is better suited.
Practical Implementation Patterns
Pattern 1: FHIR-Native New Build
Greenfield implementations targeting Epic or Cerner as the primary EHR should build FHIR-first. This means the PACS must expose ImagingStudy resources on a standards-compliant FHIR server, the RIS must generate DiagnosticReport resources at report sign-off, and both must accept ServiceRequest input for order processing.
OmniPACS is architected for this model: the platform maintains a FHIR R4 resource layer alongside the native DICOM archive, so imaging data is accessible through both the DICOM protocol stack and the FHIR API without running a separate translation service.
Pattern 2: FHIR Wrapper on Existing v2 Infrastructure
Most existing radiology environments have years of stable HL7 v2 messaging. The practical path is not a rip-and-replace but a FHIR facade: an integration engine (Rhapsody, Mirth Connect, Azure Health Data Services) ingests v2 messages and generates FHIR resources from them. Your internal workflow stays on v2; external consumers (EHR APIs, patient portals, third-party apps) interact with the FHIR layer.
This is the pattern that resolves the most common DICOM routing and interface engine questions in hybrid environments: the FHIR layer does not replace DICOM; it provides an API surface that DICOM-unaware systems can consume.
Pattern 3: Incremental FHIR Adoption
For teams not ready for a full FHIR implementation, a practical starting point is to expose read-only FHIR endpoints for ImagingStudy and DiagnosticReport. This satisfies EHR integration requirements for image access and report retrieval without requiring changes to the internal v2 order/scheduling workflow. As the environment matures, ServiceRequest intake can be added to close the loop on the order side.
Frequently Asked Questions
What version of FHIR should radiology teams target?
FHIR R4 is the current stable target for radiology integrations. R4 is the version that Epic, Cerner, and Oracle Health publish as their certified API endpoints, and it is the version required for ONC Certified Health IT interoperability compliance in the US. FHIR R5 is available but not yet required, and most EHR vendors have not fully adopted it.
Does FHIR replace DICOM?
No. FHIR and DICOM are complementary standards. DICOM handles the actual transfer and storage of image data (via WADO-RS, STOW-RS, and QIDO-RS). FHIR provides the metadata and workflow resource layer that connects imaging to the broader EHR ecosystem. The ImagingStudy resource contains endpoint references that point to the WADO-RS service where DICOM data actually lives.
How long does a FHIR radiology integration typically take?
A read-only ImagingStudy integration with a major EHR can be completed in four to eight weeks if the PACS already has a FHIR server. Full bidirectional integration, including ServiceRequest intake and DiagnosticReport output, typically runs three to six months, depending on the complexity of the environment and the EHR’s certification requirements. Teams working with OmniPACS receive integration support for FHIR resource configuration, endpoint setup, and EHR test environment coordination, which considerably compresses the timeline.
What is the difference between FHIR subscriptions and polling?
FHIR polling means your application repeatedly queries the server for new or updated resources (e.g., GET /ServiceRequest?_lastUpdated=gt{timestamp}). FHIR subscriptions use a topic-based model where the server pushes notifications to your application when matching resources change. For radiology order intake, subscriptions are more efficient and lower latency than polling at high order volumes, but both approaches are valid and both are supported in FHIR R4.