Integrating medical imaging: DICOM, PACS, and where it meets HL7 & FHIR
Imaging is its own world with its own standard — DICOM. If you're connecting a radiology or cardiology workflow, the pixels don't travel over HL7 or FHIR; they travel over DICOM, while HL7 carries the order and the report. Here's how the pieces fit.
DICOM is more than a file format
Most people meet DICOM as the .dcm file that holds an image plus a rich header of patient, study, and acquisition metadata. But DICOM is also a network protocol. Devices push and pull studies with operations like C-STORE (send an image), C-FIND (query for studies), and C-MOVE (retrieve them). If you're integrating imaging, you're integrating that protocol — not just parsing files.
PACS, VNA, and the modality worklist
Images live in a PACS (Picture Archiving and Communication System) or, increasingly, a vendor-neutral archive (VNA) that stores studies from many systems in a standard way. Before a scan, the modality (the CT, MRI, or ultrasound) queries a Modality Worklist (MWL) to pull the patient and order details, so the technologist doesn't retype them — which is exactly where a mismatch becomes a mislabelled study.
How orders and results actually flow
A typical loop: the EHR sends an imaging order as an HL7 v2 ORM (or ORU/OMG in newer flows); the RIS turns it into a worklist entry; the modality acquires images and stores them to PACS over DICOM; the radiologist reads and dictates a report; the report comes back to the EHR as an HL7 v2 ORU. The thread tying the HL7 world and the DICOM world together is the accession number — get that mapping right and everything reconciles; get it wrong and reports orphan from images.
DICOMweb: imaging over HTTP
Classic DICOM networking assumes long-lived connections between on-prem devices. DICOMweb brings the same concepts to modern web apps over HTTPS: STOW-RS to store, QIDO-RS to query, and WADO-RS to retrieve. This is what lets a browser-based viewer or a cloud service work with imaging without a heavyweight DICOM stack, and it's how imaging fits into a cloud-hosted architecture.
Where FHIR fits
FHIR doesn't carry pixels either — it references them. The ImagingStudy resource describes a study and points to where the images can be retrieved (typically a DICOMweb endpoint), so an app can present a patient's clinical data and their imaging together. In practice a modern imaging integration often combines FHIR for the clinical context with DICOMweb for the images themselves.
The gotchas worth planning for
- Identity reconciliation — patient and accession matching across EHR, RIS, and PACS is where most imaging bugs live.
- Large payloads — studies can be hundreds of megabytes; plan network, storage, and timeouts accordingly.
- De-identification — sharing images for research or AI means stripping PHI from DICOM headers and burned-in pixel data.
- Character sets and private tags — vendor-specific tags and encodings trip up naïve parsers.
Connecting an imaging workflow? We integrate PACS, RIS, and modalities with EHRs over DICOM, HL7, and FHIR. See our integration work or talk to an engineer →