Healthcare IT teams are often told their systems need to be “interoperable,” but the standards landscape behind that requirement is anything but simple. DICOM, HL7 v2, IHE profiles, and the FHIR standard each play a distinct role, yet they frequently appear in the same conversation, in the same tender documents, and in the same vendor pitches. Knowing what each one actually does, and how they fit together in a real radiology workflow, is the foundation for every integration decision your organization will make.
This reference piece maps all four standards side by side. We will cover what each one owns, where they overlap, and when you reach for which one.
The Four Standards at a Glance
Before going deeper into each standard, a comparison table helps orient the full picture. Medical imaging standards are not competitors. They operate at different layers of the stack and solve different problems.
| Standard | What It Does | Data It Carries | Typical Layer |
|---|---|---|---|
| DICOM | Stores and transmits medical images and image metadata | Pixel data, patient demographics, acquisition parameters | Image acquisition and storage |
| HL7 v2 | Sends clinical orders and results between systems | Patient registration, imaging orders (ORM), reports (ORU), ADT events | Workflow messaging between RIS, HIS, PACS |
| IHE Profiles | Defines how DICOM and HL7 should be applied in specific workflows | Not a data format (a specification for using other standards) | Workflow orchestration and conformance |
| FHIR | Exposes clinical and imaging data via REST APIs | FHIR resources (ImagingStudy, Patient, DiagnosticReport, etc.) | Application integration, patient portals, EHR APIs |
None of these standards replaces the others. A modern imaging environment uses all four simultaneously.
DICOM: The Language of Medical Images
DICOM (Digital Imaging and Communications in Medicine) has been the international standard for storing, transmitting, and displaying medical images since 1993. Its adoption is effectively universal: every CT scanner, MRI machine, X-ray panel, and ultrasound device sold into a clinical environment today is DICOM-compliant.
What DICOM actually defines
DICOM is three things at once: a file format, a network protocol, and a set of services.
As a file format, a DICOM file bundles image pixel data together with a structured header containing patient information, acquisition parameters, modality type, series and instance identifiers, and dozens of other metadata attributes. Unlike a JPEG, a DICOM file is self-describing: any conformant viewer can extract who the patient is, what modality produced the image, and how the image was acquired, without consulting an external database.
As a network protocol, DICOM defines how devices communicate images to each other. The DICOM DIMSE protocol (which runs over TCP/IP) enables services like C-STORE (send an image to an archive), C-FIND (query a PACS for studies), C-MOVE (retrieve images), and C-ECHO (verify connectivity). These are the commands a modality uses when it pushes a completed study to your PACS, and the commands your viewer uses when it retrieves prior studies for comparison.
As part of its set of services, DICOM also defines DICOMweb, a newer RESTful API layer built on top of HTTP that enables image retrieval without requiring proprietary client software. DICOMweb services (WADO-RS, STOW-RS, QIDO-RS) are increasingly important for cloud PACS platforms and browser-based viewers.
Where DICOM ends
DICOM governs the image itself and the metadata attached to it. It does not govern the clinical order that triggered the imaging study, the radiologist’s report resulting from it, or the workflow steps connecting those two events. That is where HL7 comes in.
For teams building or troubleshooting DICOM routing in cloud environments, the DICOM routing in cloud PACS setup guide covers the practical configuration side of DICOM network services in detail.
HL7 v2: The Messaging Backbone of Radiology Workflow
HL7 Version 2 (HL7 v2) is one of the most widely deployed healthcare messaging standards worldwide, despite being developed in the late 1980s. It is the protocol that keeps the RIS, HIS, PACS, and EMR talking to each other throughout the lifecycle of an imaging encounter.
How HL7 v2 messages move through a radiology workflow
An imaging encounter generates a sequence of HL7 messages that each trigger a handoff between systems:
- A patient registration event in the HIS generates an ADT (Admit, Discharge, Transfer) message that propagates patient demographics to the RIS and PACS.
- When a physician orders an imaging study, the EMR sends an ORM (Order Message) to the RIS. The ORM carries the procedure code, the ordering clinician’s details, and the clinical indication.
- The RIS schedules the exam and sends a worklist entry to the modality via DICOM Modality Worklist (MWL), which the modality pulls to pre-populate patient data before scanning.
- When the radiologist signs the report, the dictation or reporting system sends an ORU (Observation Result) message back to the EMR, delivering the final report text.
This is the core order-to-report loop, and HL7 v2 messages are the connective tissue running through it. The RIS PACS integration workflow explains how these message flows are configured in practice between systems.
HL7 v2 limitations
HL7 v2 is robust and ubiquitous, but it carries significant technical debt. Each message segment is pipe-delimited plain text, which means implementations frequently vary between vendors, and the same ORM message can be structured differently by different RIS vendors, requiring custom mapping for each connection. Semantic interoperability, meaning agreement on the meaning of a field rather than just its position, remains inconsistent.
HL7 v2 also lacks a native concept of a REST API, a JSON representation, and alignment with modern web architectures. It was designed for point-to-point connections, not for the many-to-many data exchange patterns that modern health systems require.
IHE Profiles: The Recipe Book That Ties Everything Together
IHE (Integrating the Healthcare Enterprise) is frequently misunderstood as a standards body. It is not. IHE does not create new standards. Instead, IHE Integration Profiles define exactly how existing standards (primarily DICOM and HL7) should be applied to solve specific clinical workflow problems. Think of IHE as a recipe book: the ingredients are DICOM and HL7 messages, and the recipes are IHE profiles.
Key IHE radiology profiles
The IHE Radiology domain has published profiles covering most clinical imaging scenarios. A few are foundational:
Scheduled Workflow (SWF)
Scheduled Workflow is the profile that most radiology environments implement first. It defines the eight-step transaction sequence from patient registration through image availability, mapping which HL7 messages and DICOM services apply at each step, and what must be confirmed before proceeding to the next. If your RIS and PACS both claim SWF conformance, they have committed to implementing the same messages, in the same sequence, with the same field expectations.
Postprocessing Workflow (PWF)
Postprocessing Workflow extends the workflow to cover post-acquisition processing steps such as CAD analysis, image segmentation, and 3D reconstruction. It defines how worklists for these tasks are created, queried, and resolved.
Cross-Enterprise Document Sharing for Imaging (XDS-I)
Cross-Enterprise Document Sharing for Imaging provides a profile for sharing DICOM studies across organizational boundaries, such as between a referring clinic and a hospital radiology department, using a document registry model.
Why IHE conformance matters for procurement
When evaluating PACS or RIS vendors, asking for IHE profile conformance is more precise than asking for “HL7 support.” Any vendor can claim HL7 support. What matters is which profiles they have implemented and tested. IHE Connectathon results (published by IHE International) document which vendors have tested against which profiles, giving procurement teams a verifiable conformance record.
OmniPACS supports the major IHE radiology integration profiles, so connecting OmniPACS to your existing RIS or EMR does not require custom message mapping for core workflow transactions. If you are evaluating PACS platforms, you can Check Out OmniPACS Services for a full breakdown of supported integrations and IHE conformance levels.
FHIR: The API Layer for Modern Healthcare Integration
The FHIR standard (Fast Healthcare Interoperability Resources), developed by HL7 International, represents a fundamental shift in how clinical data is exchanged. Where HL7 v2 is a messaging protocol built for point-to-point connections, FHIR is a REST API framework built for the modern web. It uses JSON or XML representations of standardized resources (Patient, Observation, ImagingStudy, DiagnosticReport, etc.) over HTTPS.
FHIR’s role in medical imaging specifically
FHIR does not replace DICOM for image transport. A CT dataset will continue to be transferred as DICOM objects via C-STORE or STOW-RS, since FHIR is not designed to carry multi-gigabyte image data. FHIR handles the metadata, context, and application integration layer around images.
The ImagingStudy FHIR resource links a clinical encounter to its associated DICOM study, making images discoverable through a FHIR API without requiring DICOM-level access. A clinician portal built on FHIR can query for a patient’s imaging studies, retrieve the report via DiagnosticReport, and launch a DICOMweb viewer for the actual pixel data, all through standard HTTP calls that any developer familiar with REST APIs can implement.
FHIRcast, a derivative protocol, enables real-time context synchronization between applications. When a radiologist opens a case in the PACS viewer, the EMR and the reporting system automatically synchronize to the same patient and study without manual navigation.
The regulatory mandate behind FHIR adoption
FHIR adoption is no longer optional for organizations operating in the United States. The 21st Century Cures Act and CMS interoperability rules require covered entities to expose patient data via FHIR APIs. The HL7 standards documentation covers the full scope of regulatory requirements that apply to FHIR implementations under US law.
The 2025 State of FHIR survey found that over 70% of countries report active FHIR use, and 73% of countries with health data exchange regulations either mandate or encourage FHIR. The EHR integration challenge for radiology teams is increasingly a FHIR configuration problem rather than a DICOM problem. The EHR PACS integration challenges guide covers the practical FHIR and HL7 configuration issues teams encounter most often.
How All Four Standards Work Together in a Real Workflow
The clearest way to understand how these standards interrelate is to follow a single imaging encounter from order to report:
- Patient registers at the front desk. The HIS fires an HL7 v2 ADT message, propagating demographics to the RIS and PACS.
- The referring physician orders an MRI in the EMR. The EMR sends an HL7 v2 ORM message to the RIS. If the EMR is FHIR-capable, it may also create a FHIR ServiceRequest resource.
- The RIS schedules the study and creates a DICOM Modality Worklist entry. The MRI scanner queries the MWL and pre-populates patient and study data before scanning begins.
- The technologist completes the scan. The MRI pushes DICOM image files to the PACS via C-STORE.
- The radiologist opens the study in the PACS viewer. If the facility uses FHIRcast, the reporting system and the EMR automatically synchronize to the same patient context.
- The radiologist dictates and signs the report. The reporting system sends an HL7 v2 ORU message to the EMR with the final report text, and optionally creates a FHIR DiagnosticReport resource.
- The EMR now displays the report and, via the FHIR ImagingStudy resource, can link directly to the images in the PACS viewer for any clinician who opens the chart.
The IHE Scheduled Workflow profile defines the conformance requirements at every step of this sequence. A facility that has deployed SWF-conformant systems can trust that each handoff will work as specified, without custom per-vendor mapping.
For teams looking at how these standards are applied across multi-system environments, the medical imaging system integration guide covers architecture patterns for connecting PACS, RIS, and EHR in practice.
When You Use Which Standard
The standards are not competing options. They are complementary layers. But certain problems map clearly to certain standards:
Use DICOM when you are dealing with images: storing them, moving them between devices, configuring a PACS to receive from a modality, setting up routing rules, or building a viewer.
Use HL7 v2 when you are connecting a RIS to an EMR, a PACS to an HIS, or configuring order and result messaging in an existing on-premises environment. Most deployed systems still use HL7 v2 messaging, and new integrations in legacy environments usually require configuring HL7 interfaces.
Use IHE profiles when specifying integration requirements in a procurement process, testing conformance between vendors, or troubleshooting a workflow involving multiple systems. IHE profile conformance is the correct language to use with vendors when you need integration guarantees, not just “HL7 support.”
Use FHIR when you are building or connecting patient-facing applications, populating a care coordination platform, complying with CMS API mandates, or integrating a modern cloud system with an EHR. FHIR is the right tool for cross-organizational data exchange in modern architectures.
Frequently Asked Questions
Is FHIR replacing DICOM?
No. FHIR and DICOM operate at different layers of the stack and solve different problems. FHIR handles metadata, application integration, and API access to clinical data. DICOM handles image storage, transport, and pixel-level data. In practice, modern imaging workflows use both FHIR for application connectivity and DICOM for image movement.
Is HL7 v2 being phased out?
Not in the near term. HL7 v2 remains deeply embedded in hospital infrastructure worldwide, and many RIS, PACS, and EMR systems will continue running v2 messaging for the foreseeable future. FHIR is the forward-looking standard for new implementations, but HL7 v2 remains the operational reality for most healthcare organizations today.
What does IHE conformance mean in practice?
A vendor that claims IHE Scheduled Workflow (SWF) conformance has committed to implementing a defined set of HL7 and DICOM transactions in a specified sequence. IHE Connectathon results document, which vendors have tested these claims against other vendors, giving buyers a level of integration assurance beyond self-reported compliance.
Does OmniPACS support all four standards?
Yes. OmniPACS is built to participate in complete DICOM, HL7, IHE, and FHIR environments. The platform supports DICOM C-STORE, C-FIND, C-MOVE, and DICOMweb services for image management; HL7 v2 for RIS and HIS messaging; IHE Scheduled Workflow for conformant multi-vendor integration; and FHIR for EHR connectivity and API-based data access. OmniPACS Delivers Scalable Monthly Plans covering all integration tiers, from single-site DICOM-only deployments to full multi-system IHE environments.