Medical Imaging & Interoperability

How PACS Integration Actually Works (and Where It Breaks)

Published July 11, 2026 · Influrion Editorial Team

PACS — a Picture Archiving and Communication System — is the backbone of medical imaging. If you're building or integrating imaging software, "just connect to the PACS" hides a lot of moving parts. Here's how images actually flow, and the specific points where integration projects tend to break.

A medical imaging pipeline: a modality creates DICOM images, which flow to PACS and a vendor-neutral archive, and are reached by viewers and the EHR over DICOMweb or referenced from a FHIR ImagingStudy.ModalityCT · MR · X-rayDICOMPACSstore + viewDICOMVNAvendor-neutral archiveDICOMViewer / EHRcliniciansC-STOREquery/retrieveDICOMweb (WADO)FHIR ImagingStudypoints the EHR to the study
Images move as DICOM from the modality into PACS and a vendor-neutral archive; viewers and the EHR reach them via query/retrieve or DICOMweb, while a FHIR ImagingStudy resource points clinicians to the study.

The pipeline, end to end

  1. A modality creates the study. A CT, MR, ultrasound, or X-ray machine produces images as DICOM — the universal standard for medical imaging, which bundles the pixel data together with rich metadata (patient, study, series, acquisition parameters).
  2. Images land in PACS. The modality sends the study to PACS, usually via the DICOM C-STORE operation. PACS stores it and serves it to reading workstations.
  3. A VNA archives it. Many organizations put a Vendor-Neutral Archive behind (or beside) PACS so images aren't locked into one vendor's format and can be shared across departments and systems.
  4. Viewers and the EHR retrieve it. Radiologists read in a viewer; clinicians see images in the EHR. Retrieval happens via DICOM query/retrieve (C-FIND/C-MOVE) or, increasingly, DICOMweb (WADO-RS/QIDO-RS/STOW-RS) — a modern, HTTP-based way to reach studies.
  5. FHIR points to it. A FHIR ImagingStudy resource lets the EHR reference a study without carrying the pixels — the images stay in PACS/VNA, and the resource is the pointer.

Where PACS integration usually breaks

  • Identifier mismatches. The same patient carries different IDs across the RIS, PACS, and EHR. If Patient IDs, Accession Numbers, and Study Instance UIDs don't reconcile, images attach to the wrong record — or don't show up at all.
  • DICOM tag inconsistencies. Modalities and vendors populate tags differently. Software that assumes a tag is always present, or always formatted a certain way, breaks on real-world data.
  • Old protocols vs new. Some systems only speak classic DICOM query/retrieve; others expect DICOMweb. Bridging the two is common and easy to underestimate.
  • Performance at study size. A single CT or MR study can be hundreds or thousands of images. Naive retrieval and rendering that works in a demo falls over on a full study.
  • Security and access. Imaging carries PHI. Encryption in transit, access control, and audit logging aren't optional add-ons — they belong in the design.

A checklist before you scope an imaging integration

  • Which systems are involved (modality, RIS, PACS, VNA, EHR) and what does each speak — classic DICOM, DICOMweb, or both?
  • How are Patient ID, Accession Number, and Study Instance UID mapped across systems?
  • Do you need to store, query/retrieve, render, or all three?
  • What's the largest realistic study size, and what are the performance expectations?
  • How will PHI be protected in transit, at rest, and in the audit trail?

How we approach it

DICOM, PACS, and HL7 FHIR interoperability is the core of what we do. We design imaging integrations around the messy realities above — identifier reconciliation, tag variation, bridging classic DICOM with DICOMweb, and handling full-size studies without falling over — with HIPAA-aware safeguards built in from the start. If you're planning an imaging platform or a PACS integration, tell us what you're connecting and we'll help you scope it properly.