How Does AI Integrate With PACS? DICOM, HL7 and Worklists
How radiology AI connects to your PACS over DICOM, the three routing patterns, where results come back, the difference between a modality worklist and a radiology worklist, and what the integration asks of your own team.
By the Radiological.ai team
July 2026 · 9 min read
Worklist
Structured report
DraftRun the assistant to draft this report for review.
Illustrative sample · not a real patient study, not a diagnosis
Decision support for qualified clinicians. Radiological.ai does not provide a diagnosis and is not a substitute for professional judgment.
The short answer: Radiology AI integrates with PACS over DICOM. Your archive sends a copy of each study to the AI system using the same standard network protocols it already uses to talk to viewers and modalities, the AI processes the study, and results come back as a DICOM object, an HL7 message, or a flag in the worklist. No PACS replacement is required, and in most cases no change to how radiologists open a study. What varies between vendors is not whether they can receive images, but where the results land afterward.
Updated July 2026.
Integration is the question that decides most radiology AI purchases, and it is usually asked too late. By the time a group is in contracting, the clinical case has been made and the price has been argued over, and then somebody asks the PACS administrator how this is actually going to work. That conversation should happen in the first demo. Here is what to ask, in the order that matters.
How does AI integrate with PACS?
At the plumbing level it is unglamorous, which is good news. PACS systems have exchanged images with other systems for decades using DICOM, the imaging standard that defines both the file format and the network protocol. An AI system is configured in your PACS as another DICOM destination, exactly like a viewer or a second archive. When a study completes, the PACS routes a copy to it. The AI reads the pixel data and the header, does its work, and sends something back.
Three routing patterns cover almost every deployment. In push routing, the PACS forwards studies matching a rule (modality, body part, study description) to the AI destination automatically. In pull routing, the AI system queries the archive on a schedule using DICOM query and retrieve, then fetches what it needs. In on-demand, a radiologist triggers processing for a single study from the viewer or worklist. Push is by far the most common because it is the only one that works before anybody has opened the study, which is the entire point of triage.
What is DICOM and why does it matter for AI integration?
DICOM is the standard that lets imaging equipment from different manufacturers talk to each other. It covers the image format, the metadata header attached to every study, and the network operations for sending, querying and retrieving studies. Every PACS in clinical use speaks it. That is why a vendor saying "we integrate over DICOM" is making a genuinely meaningful claim: it means the connection uses machinery your environment already runs, rather than a bespoke interface somebody has to build and maintain.
The header matters as much as the pixels. It carries the accession number, patient and study identifiers, modality, body part and study description. AI systems use those fields to decide whether a study is in scope and to match results back to the right study. When integrations go wrong in practice, the cause is usually messy header data rather than a networking failure: inconsistent study descriptions across sites, a modality that populates body part differently, or an accession number format that changed when the RIS was upgraded. Ask the vendor how their routing rules handle inconsistent study descriptions, because your data is messier than the demo data.
Where does the AI actually run?
There are three deployment shapes and each has a different conversation attached.
| Deployment | How it works | What to check |
|---|---|---|
| On-premises | A server or appliance inside your network processes studies locally. | Who patches it, who monitors it, what happens when it needs more capacity. |
| Cloud | Studies are transmitted to the vendor's environment for processing. | Encryption in transit and at rest, the business associate agreement, data residency, and whether images are retained or used for model training. |
| Hybrid or edge | A local gateway handles routing and de-identification, processing happens in the cloud. | What the gateway sends, and what it strips before sending. |
None of these is automatically the right answer. What matters is that the choice is explicit in the contract and that your security review sees the actual data flow diagram, not a marketing slide. If protected health information leaves your network, the business associate agreement and the retention terms are the two documents to read closely.
How do AI results get back into the radiologist's view?
This is the question that separates tools that get used from tools that get switched off after four months. Receiving images is easy. Returning results into the workflow a radiologist already uses is where products genuinely differ.
The common return paths are a DICOM secondary capture (an image with annotations burned in, which appears as an extra series in the study), a DICOM structured report or presentation state (structured findings your viewer can render as overlays if it supports them), an HL7 ORU message into the RIS or reporting platform, and a worklist flag that changes priority or adds an icon in the reading list. Better integrations use several at once: a priority change in the worklist so the study surfaces sooner, an overlay in the study so the flag is visible where the radiologist is already looking, and a draft that lands in the reporting template.
The pattern to avoid is results that live only in the vendor's own web console. A separate window that a radiologist has to remember to check is a tax paid on every study, and it is the most reliable predictor of a pilot that quietly dies. When you evaluate the AI radiology software options on your shortlist, make each vendor show you the result in your viewer, on your study, not in their demo environment.
What is the difference between a modality worklist and a radiology worklist?
They sound alike and get confused constantly in vendor conversations. A DICOM modality worklist is what a scanner queries so the technologist does not retype patient demographics at the console: it pushes order information out to the equipment. A radiology worklist is the reading list radiologists work from, the queue of unread studies with priority, assignment and turnaround tracking. AI triage changes the second one, not the first. If a vendor says they "integrate with the worklist," ask which worklist, because the answer tells you whether their product touches the read at all. This is the difference that radiology worklist software exists to manage.
Does AI radiology software work with any PACS vendor?
Almost always yes at the protocol level, because DICOM is universal. The practical caveats are about depth rather than connectivity. Overlays and structured reports render differently depending on how completely your viewer implements DICOM presentation states. Some PACS platforms require a licensed interface module to add a new DICOM destination, which is a line item nobody mentioned in the quote. And worklist priority changes usually need an interface into the RIS or the reporting platform rather than the archive, so that path may involve a second vendor.
Ask directly: name your PACS and your viewer version, and ask the vendor for a reference site running the same combination. A vendor who has already integrated with your exact stack is worth a meaningful amount of money in avoided project time.
How long does a PACS integration take?
For a straightforward DICOM push integration on a single site with a modern PACS, expect the technical connection to take days rather than months. The realistic timeline for the whole project is longer, and the time goes into things that are not technical: the security review and business associate agreement, agreeing the routing rules for which studies are in scope, mapping study descriptions across sites, configuring how results should display, and the pilot period where radiologists tell you the priority thresholds are wrong and you tune them.
A sensible plan reserves two to three weeks for the security and contracting work in parallel with a few days of technical setup, then four to six weeks of pilot on a limited study scope before widening. Groups that try to go live across every modality in week one spend the following month unwinding it.
What does the integration ask of your own team?
Get an hours estimate by role and treat it as part of the price. A typical integration needs your PACS administrator to configure the destination and routing rules, your network or security lead to approve the data flow and open the connection, someone from IT to handle the certificate and firewall work, and a radiologist champion to make the calls about which flags actually help and which are noise. That last role is the one groups forget to staff, and it is the one that decides whether the tool is trusted.
Budget monitoring time too. A DICOM route that stops delivering does not usually announce itself: studies simply stop being processed while everything appears to work normally. The same discipline that data teams apply when they set up monitoring that catches a feed which silently stops or changes shape belongs on a clinical AI route. Ask the vendor what alerts exist when volume drops to zero, and who receives them.
What to put in the contract
Four integration terms are worth writing down before signing. First, the deployment shape and the exact data flow, including whether images leave your network and how long they are retained. Second, the return paths the vendor commits to supporting for your specific viewer and reporting platform, named. Third, the implementation scope: how many sites, how many interfaces, and what happens if a second site takes longer. Fourth, an exit clause covering what happens to your data and your configuration if you leave, because integration work is the switching cost that keeps groups in contracts they have outgrown.
The through line in all of it is to keep the integration surface small. A tool that consumes studies over standard DICOM and returns results into the systems you already run can be swapped in a quarter if it disappoints. A tool that required its own viewer, its own worklist and three custom interfaces cannot. That is the core argument for treating radiology PACS integration as an evaluation criterion rather than an implementation detail, and for preferring an assistant that adds to your stack over a platform that replaces it.
The bottom line
AI integrates with PACS the same way everything else in imaging does: over DICOM, as another destination on a network your archive already talks to. The technical connection is rarely the hard part. The parts that decide whether the investment pays off are where the results land, who on your team carries the work, and whether the routing keeps running six months after go-live when nobody is watching it any more. Ask those three questions in the first demo, and the shortlist gets shorter fast. From there, the flags, the worklist order and the structured report draft either show up where your radiologists already work, or they do not.
See Radiological.ai read a study
The assistant flags suspected findings for review, prioritizes the worklist so urgent studies surface first, and drafts the structured report into your template. You review, edit and sign every study.