Ask why an imaging environment needs three different interoperability standards and you will get three different answers, all correct: because images, workflow messages and modern application data are three different problems. DICOM, HL7 and FHIR were each designed for one of them, and every well-run radiology operation quietly uses all three every day.
This guide explains what each standard actually does, where DICOMweb fits, how the three combine in the journey of a single exam, and what a non-technical buyer should check before signing an imaging IT contract.
Why three standards exist at all
Healthcare data comes in fundamentally different shapes. A CT study is a large, structured bundle of pixel data plus rich technical metadata. An order or a report status update is a short event message flowing between systems. A patient summary consumed by a web or mobile application is a structured resource that developers want to query like any modern API.
No single standard handles all three shapes well, which is why the ecosystem settled into a division of labour: DICOM for imaging objects, HL7 for workflow messaging, and FHIR for modern, web-native data exchange. Understanding the division is the fastest route to understanding any imaging architecture diagram you will ever be shown.
Ignoring the division has a price tag. Architectures that try to force imaging through generic document exchange, or workflow events through image channels, end up with translation layers that must be built, tested and maintained forever — every one of them a future point of failure. The standards landscape looks untidy from a distance; used as designed, it is the cheapest integration strategy available.
DICOM and DICOMweb: the language of images
DICOM (Digital Imaging and Communications in Medicine) defines both the file format for medical images and the network services used to move them. When a CT scanner sends a study to PACS, when a viewer requests priors, when a modality queries the worklist — that is DICOM at work. Every image carries a header of standardised tags: patient identity, accession number, modality, acquisition parameters and much more.
DICOMweb is the modern extension – the same imaging semantics exposed as RESTful web services. Three service families matter — QIDO-RS for searching studies, WADO-RS for retrieving them, and STOW-RS for storing them. DICOMweb is what makes zero-footprint browser viewers, cloud archives and AI integrations practical because web applications can interact with imaging data using ordinary web protocols rather than legacy point-to-point connections.
- What DICOM owns: image encoding, imaging metadata, modality worklists (MWL), performed procedure steps (MPPS), storage and query/retrieve.
- What to check as a buyer: full DICOMweb support (all three service families), conformance statements available on request, and no reliance on private tags for core functionality.
Two practical cautions from the field. First, DICOM conformance is not binary — vendors implement subsets, and the differences surface exactly where budgets hurt: during integration. The conformance statement, a document every serious vendor publishes, is where those subsets are declared; request it and have someone technical actually read it. Second, private tags — vendor-specific metadata fields — are legitimate for extras but dangerous for essentials. When private tags are essential to core workflow, your data is standard in format but proprietary in practice.
HL7 v2: the workhorse of the order-to-report loop
HL7 version 2 is the messaging standard that has connected hospital systems for decades. It carries the events that give imaging its context: a patient is admitted (ADT messages), an exam is ordered (ORM), and a result or report is available (ORU). When the EHR sends an order to the RIS, or a finalised report flows back to the referring clinician, HL7 v2 is almost always the carrier.
It is old, terse and famously tolerant of local variation — which is both its strength and the source of most integration friction. Two systems can both speak HL7 and still disagree about which field carries which identifier. This is why interface specifications and testing matter more than the standard’s name on a datasheet and why IHE profiles (such as Scheduled Workflow) exist: they pin down exactly how the standards should be used together so implementations align.
In most hospitals these messages do not travel point-to-point but through an interface engine – middleware that receives, transforms and routes HL7 traffic between systems. This is worth knowing as a buyer for one reason: when an integration misbehaves, the fix may live in the engine’s mapping rather than in either endpoint. A vendor who asks early about your interface engine and message specifications is displaying experience; one who promises ‘standard HL7, no configuration needed’ is displaying optimism.
FHIR: where healthcare data is heading
FHIR (Fast Healthcare Interoperability Resources) is HL7’s modern successor for data exchange: discrete resources (Patient, ImagingStudy, DiagnosticReport, and ServiceRequest) exposed through REST APIs in JSON or XML. Developers can build against FHIR the way they build against any contemporary API, which is why patient apps, national platforms and analytics tools increasingly assume it.
For imaging specifically, FHIR does not replace DICOM — pixel data stays in DICOM, retrieved via DICOMweb — but FHIR resources describe and reference imaging studies within the wider clinical record. The regulatory direction reinforces this: the European Health Data Space (Regulation (EU) 2025/327) is driving EU-wide exchange formats in which FHIR plays a central role, with medical images and imaging reports becoming a mandatory cross-border exchange category by March 2031. Systems procured now should be assessed with that horizon in mind.
The division of labour is elegant in practice: a FHIR ImagingStudy resource describes the study — patient, procedure, series — and points to the DICOMweb endpoints where the pixel data lives. An application can discover imaging through FHIR alongside the rest of the record, then retrieve and render through DICOMweb. This pairing is the architectural pattern behind modern patient portals, and the reason both standards belong on the same procurement checklist rather than in competition.
One exam’s journey through all three
- Order: a clinician orders a CT in the EHR; an HL7 ORM message carries the order to the RIS.
- Scheduling and acquisition: the scanner pulls patient and exam details via DICOM Modality Worklist, eliminating retyping at the console.
- Storage: acquired images travel to PACS and archive as DICOM objects; status updates may flow as MPPS.
- Reading: The diagnostic viewer queries and streams the study — increasingly via DICOMweb — alongside priors.
- Reporting: the finalised report returns to the EHR as an HL7 ORU message and may also be represented as a FHIR DiagnosticReport referencing the ImagingStudy for portals and apps.
- Patient access: a patient portal presents the study and report through FHIR and DICOMweb interfaces rather than proprietary connectors.
Notice the pattern: DICOM wherever pixels move, HL7 wherever workflow events move, and FHIR wherever modern applications consume the record. An architecture that respects this division tends to be stable; one that fights it tends to generate integration projects forever.
A buyer’s checklist
- DICOM: full conformance statements; MWL and MPPS support; no core dependence on private tags.
- DICOMweb: QIDO-RS, WADO-RS and STOW-RS are all supported — essential for web viewers, portals and AI integration.
- HL7 v2: documented interface specifications; experience with your EHR/HIS; a clear testing methodology.
- FHIR: a published API surface and a credible roadmap aligned with EHDS-era exchange requirements.
- IHE: relevant profile support (Scheduled Workflow and XDS-I where cross-enterprise sharing applies).
- Evidence: reference sites where these integrations run in production, not just capability claims.
Finally, treat every claim on that list as testable. A half-day connectathon-style session — your systems, the vendor’s endpoints, real messages and real studies — will surface more truth than any compliance matrix. Vendors confident in their standards story tend to welcome the exercise; hesitation is itself a data point.
Standards-based by design
The practical payoff of standards fluency is simple: systems that integrate in weeks rather than quarters and data that remain yours as the ecosystem changes. The Evorad platform is built on that principle – DICOM, DICOMweb, HL7 and FHIR-ready interfaces across PACS, viewer, archive and portal – so each component connects cleanly to what you already run.
See how the pieces fit at evorad.com/platform/.
FAQs
Do I need to choose between HL7 and FHIR?
No — you will run both for years. HL7 v2 remains the dominant carrier for orders and results inside hospitals, while FHIR grows around patient access, apps and cross-border exchange. Buy systems that speak both.
Is DICOMweb a different standard from DICOM?
It is part of the DICOM standard — the same imaging semantics delivered over RESTful web services. Think of it as DICOM’s web-native dialect, and treat full support as non-negotiable in new procurements.
What are IHE profiles and why do they matter?
IHE profiles are implementation recipes that specify exactly how standards like DICOM and HL7 should be combined for common workflows. They reduce the local-variation problem that causes most integration pain.
Where does the EHDS fit into this?
The European Health Data Space regulation establishes EU-wide health data exchange, with medical imaging in the second wave of mandatory categories by March 2031. Its technical direction leans on FHIR-based exchange formats, which is a strong reason to weight FHIR readiness in current purchasing decisions.
Can standards compliance be assumed from big vendors?
No. Compliance varies in depth and in the details that matter — private tags, partial DICOMweb implementations, undocumented HL7 variants. Always request conformance statements and test against your real systems.
