Medical imaging runs on standards that are decades old, deeply entrenched, and unforgiving of shortcuts — for good reason. A CT scanner, a PACS archive, a radiology worklist, and an EHR all have to agree on what a study is, who the patient is, and where the images live. Getting them to interoperate cleanly, without leaking protected health information, is precise work. Here's the shape of it.
DICOM: the language of images
DICOM is the standard for medical images and everything attached to them. It's not just a file format — it's a network protocol and a data model that encodes the image, the acquisition parameters, and the patient and study context together. Modalities (CT, MR, ultrasound, X-ray) produce DICOM; PACS systems store and serve it; viewers consume it.
DICOMweb is the modern, web-friendly face of DICOM — RESTful services for the operations that used to require heavyweight protocols:
- WADO-RS to retrieve images and metadata
- QIDO-RS to search for studies and series
- STOW-RS to store new instances
If you're building anything that touches imaging from a modern application — a web viewer, an AI pipeline, a cloud archive — DICOMweb is usually how you do it without reimplementing legacy plumbing.
HL7 and FHIR: the clinical context
Images don't exist in isolation. Orders, patient demographics, and results flow through the rest of the hospital in HL7 — the long-standing v2 messaging standard that still moves most clinical data — and increasingly FHIR, the modern, resource-oriented, API-friendly standard. A working imaging integration bridges both worlds: the imaging side (DICOM) and the clinical side (HL7/FHIR), so an order becomes a worklist entry, a completed study becomes a result, and the EHR and PACS stay in agreement about reality.
IHE: the workflows that tie it together
Standards define the vocabulary; IHE profiles define how to actually use them together for real clinical workflows — scheduled procedure steps, consistent patient identity across systems, results reconciliation. Aligning to IHE is what keeps a multi-vendor environment coherent instead of a pile of technically conformant systems that still don't cooperate.
PHI is the constraint that shapes everything
Imaging data is protected health information, and that's not a feature you add at the end — it's a constraint that shapes the whole design:
- De-identification for research, AI training, or any use outside direct care — and done correctly, because DICOM hides identifying data in more places than people expect, including burned into pixels.
- Access control and audit so every access to a study is authorized and logged.
- Encryption in transit and at rest, with key management that holds up.
- Minimal movement. The safest PHI is the PHI you didn't copy. Architectures that keep identified data in one controlled place, and move de-identified derivatives instead, are easier to secure and to defend.
Building HIPAA-consciously means these are designed in from the first diagram, not bolted on before an audit.
Where the projects get hard
The trouble usually isn't any single standard — it's the seams. A modality that implements DICOM slightly differently. An HL7 feed with local quirks. Patient identity that doesn't quite match across PACS and EHR. De-identification that missed a field. These are the details that decide whether an imaging platform is trustworthy, and they're exactly the kind of thing that's invisible in a demo and expensive in production.
If you're integrating modalities, PACS, and clinical systems — or building a de-identified pipeline to feed imaging AI — that's specialized work where the standards and the safety both have to be right. A scoped assessment is a good way to map the integration and the PHI boundaries before anyone writes the first adapter.