PACS Integration: 4 Ways to Connect Your Product to Hospital Imaging (2026)

PACS integration connects a healthcare software product to a hospital's picture archiving and communication system (PACS), the archive that stores CT, MRI, X-ray and ultrasound images, so the product can find the right study, link it to the right patient and open it for authorised users. There are four ways to do it: DICOMweb, an on-site DICOM gateway, a vendor API or viewer launch, and DICOM file import. Which one fits depends on what the hospital's archive supports, not on what your team prefers.

This guide is for product and engineering leaders who need imaging inside their product. It explains the hospital workflow, the six kinds of DICOM integration work, the four connection routes, and the failure cases a buyer should test before go-live. Every claim about behaviour is shown in a 12-minute walkthrough recorded on real public CT images.

Watch the PACS integration walkthrough

The video below shows a working DICOMweb integration between two archives using 62 real chest CT images from the public TCIA NSCLC Radiogenomics collection. It shows a transfer being interrupted and recovered, a patient association put on hold, and an unauthorised image request refused by the server with HTTP 403.

Chapters: 0:00 the buyer problem, 1:25 how imaging works in a hospital, 2:22 six types of DICOM integration, 3:40 four ways to integrate, 4:48 transfer and recovery, 6:49 patient association, 7:37 access and evidence, 8:37 delivery risks, 10:07 images and clinical records, 10:54 what to ask a vendor to deliver. More imaging videos are in the Medical Imaging Integration playlist.

What is PACS integration?

PACS integration is the work of letting an outside application search, retrieve, store or display images held in a hospital's imaging archive, with the correct patient context and access rules. DICOM (Digital Imaging and Communications in Medicine) is the standard that defines both the image files and the network services used to move them.

The goal for a product team is an authorised image inside the intended workflow, with evidence of where it came from and how it arrived. A screenshot of a viewer does not prove that. The integration also has to answer which patient the study belongs to, whether every image arrived, and who is allowed to open it.

For the standards side in more depth, see our architect's guide to DICOM and FHIR and the beginner-level DICOM and FHIR guide for developers.

How imaging works inside a hospital

A hospital imaging workflow runs in six steps: order, worklist, acquisition, archive, integration and report. A PACS integration plugs in at the archive and integration steps, so it depends on everything that happened before it.

1. Order. The EHR or radiology information system (RIS) schedules the exam for a patient.
2. Worklist. The scanner receives patient and procedure details through a DICOM modality worklist, when both systems support it. This ties the images to the intended exam.
3. Acquire. The scanner creates a study made of series and individual image objects.
4. Archive. The PACS stores those objects and provides search and retrieval services.
5. Integrate. Your product finds the study, connects it to the correct record and opens it for authorised users.
6. Report. The radiologist's report travels separately, usually as an HL7 message or a FHIR resource.

A patient name or a successful upload does not settle the association question on its own. Identifier domains, order references and reviewer rules decide it.

Six types of DICOM integration work

DICOM integration covers six distinct kinds of project, and each has different requirements and different proof of success. Naming the type early stops a project from being scoped as one thing and judged as another.

• Scanner integration: modality worklists and delivery from the scanner into the archive. It needs the scanner and archive to support the agreed workflow.
• PACS to product integration: an application finds and opens the intended images. This is the route the walkthrough demonstrates.
• Teleradiology integration: routes selected studies to a reading destination and tracks receipt, exceptions and ownership.
• AI or research integration: retrieves permitted studies and handles results with their source recorded.
• Archive migration: moves a defined inventory between archives and reconciles what arrived. Volume, vendor rewriting, retention and cutover rules must be tested before anyone promises a completion date.
• Report and record integration: connects study references and radiology reports to the clinical record through FHIR or HL7. It is accepted separately from image transfer.

4 ways to integrate with a hospital PACS

A product can reach a hospital PACS through DICOMweb, a DICOM gateway, a vendor API or viewer launch, or DICOM file import. The right route is the one the existing archive supports for the workflow you need.

1. DICOMweb

DICOMweb is the REST-based part of the DICOM standard, and it is the most direct route when the PACS exposes it. QIDO-RS searches for studies, WADO-RS retrieves images and STOW-RS stores them. Modern archives and cloud imaging services increasingly support it, but support for each service and each object type must be confirmed in the vendor's conformance statement.

2. DICOM gateway inside the hospital network

A DICOM gateway is the route when equipment and archives only speak traditional DICOM network messaging (DIMSE). The gateway sits inside the hospital network and is configured with application entity (AE) titles, IP addresses, ports and the image encodings both sides accept. A mismatch in that last item is the usual reason DICOM images send but do not display.

3. Vendor API or viewer launch

A vendor API or viewer launch fits when your product only needs to open the hospital's existing viewer in the right patient context. Access, licensing and single sign-on depend on the PACS vendor and the customer's configuration. EHR-side imaging modules such as Epic's work this way; see our Epic Radiant integration guide.

4. DICOM file import

DICOM file import fits when studies arrive through an approved export, such as a disc or a secure file transfer. It still needs a manifest, patient matching, duplicate checks and permissions. Batch import and a continuous archive connection solve different operating needs, so do not treat one as a cheap version of the other.

What the walkthrough shows on real CT images

The walkthrough runs a DICOMweb transfer between two local archives using 62 real chest CT images from The Cancer Imaging Archive. Original pixel bytes and scanner geometry are kept; patient identities are synthetic test records.

During transfer, the service stores each missing object in the destination archive, reads it back and compares its file hash with the source. When the destination connection is cut, the job stops, keeps its progress and keeps the study hidden from viewers until it is complete. The operator sees a specific failure and a retry button instead of a silently missing image.

On retry, objects already present are checked and only missing ones are stored, so recovery does not duplicate the whole study. The transfer was interrupted after 16 verified objects and recovered to all 62.

Patient association and access control

A study can arrive perfectly and still be linked to the wrong record, so association needs its own control. In the walkthrough, putting the association on hold removes the image from the viewer, and a direct request for the image file is also refused by the server. Hiding a button is not enough; the protected image route itself checks the association.

A second test session whose patient scope does not include the study requests the same image directly. The server returns HTTP 403, and the activity log keeps the interrupted transfer, the recovery, the hold, the confirmation and the denial for later review.

What each PACS integration check proves

Each check in a PACS integration proves one thing, and passing one does not prove the others. Acceptance criteria should name which check covers which risk.

Storage commitment, a separate DICOM service where the archive confirms it has taken responsibility for objects, is another check again. It is a contract with the archive and has to be tested against the archive you will use.

Six PACS integration risks to settle in discovery

Most PACS integration delays come from six questions that were not answered before the build. Each can be settled in a short discovery with the hospital and its archive vendor.

1. Vendor compatibility. Read the archive's actual DICOM conformance statement and test with permitted sample images. A "DICOM compatible" label does not cover every object type, compression format or service.
2. Patient and order context. Confirm the patient identifier and who issues it, the order reference and how studies are matched. Uncertain matches need a named reviewer.
3. Partial and late studies. Studies arrive in parts. Decide how to detect expected series, late arrivals and changes after review.
4. Duplicates and retries. Retries need duplicate protection, and content that differs under an existing identifier needs a hold and a recorded decision. Some vendors rewrite file encoding, which changes how you reconcile.
5. Network, identity and operations. Agree network access, single sign-on, permitted users, monitoring, retention and who owns incidents.
6. Clinical scope. Diagnostic display, other modalities, compressed images and clinical interpretation each need separate specialist validation.

PACS images and the clinical record

Images and the clinical record are related but travel separately. A FHIR ImagingStudy resource describes a study and where to retrieve it; the pixels still come from the imaging service. A radiology report follows the clinical system's own interface, such as an HL7 ORU message or a FHIR DiagnosticReport.

That means launching a viewer does not prove report delivery, and accepting a report does not prove the images are available. Plan them as separate milestones in any EHR integration. For a portal pattern that combines both, see how DICOM images and HL7 reports reach a portal.

What to ask a PACS integration partner to deliver

A PACS integration proposal should start with a bounded discovery and end with acceptance tests run on your own studies. The discovery covers the archive vendor, the exact services it exposes, permitted sample images, patient and order rules, and the workflow your product needs. Those facts set scope and cost.

• Build: the connector, reconciliation, patient-context access rules and visible exception handling. Keep the existing archive when the need is connectivity.
• Acceptance: representative studies plus agreed failure cases: partial transfer, retry, uncertain association, restricted access and late revisions, with a written statement of what each passing check proves.
• Operations: who runs the connection, who owns exceptions, how failures are monitored and how the team recovers.

Nirmitee builds imaging and clinical data connections as part of our healthcare interoperability services, and the connector shown in the video was built by our team. If you need imaging inside a new platform, our healthcare product engineering team designs it in from the start. Talk to our team to scope a first PACS integration milestone against your archive and workflow.

Image source: TCIA NSCLC Radiogenomics, Bakr et al. (2017), Version 4, The Cancer Imaging Archive, doi:10.7937/K9/TCIA.2017.7hs46erv, licensed CC BY 3.0. Pixel data retained; record identities and DICOM identifiers reconstructed for a local evaluation. Not a diagnostic system.