An imaging order starts in the EHR. The study is acquired on a CT, an ultrasound or a digital X-ray unit. The images land in a PACS. A radiologist reads them and dictates a report. The report goes back to the ordering physician. Four systems, five handoffs, and on a whiteboard it looks finished.
Ask a practice manager at an orthopedic group or an imaging center how it actually runs and the picture changes. Someone retypes the patient’s demographics at the modality. Someone else prints the report, scans it, and attaches it to the chart as a PDF. A physician who wants the images opens a second tab, logs into a separate viewer, and searches by name. That is the normal state of radiology workflow at a large share of ambulatory practices, and it is where most of the avoidable errors, repeat scans and billing delays come from.
This article walks the loop, points out where it breaks, puts a number on what the breaks cost, and lays out what a working integration looks like.
The order to report loop, step by step
Each handoff has a standard behind it. Knowing which standard carries which piece of data is the fastest way to find where a problem lives.
The order leaves the EHR as an HL7 message, an ORM in version 2.x or an OMI in newer implementations. It carries the patient identifier, the ordering physician, the procedure code, and an accession number that follows the study for the rest of its life.
The modality does not read HL7. It reads DICOM. A broker, a RIS, or the PACS itself converts the order into a DICOM Modality Worklist entry, so the technologist picks the patient from a list on the scanner instead of typing a name.
Once the study is acquired, the modality sends the images to the PACS using DICOM C-STORE. Every image header carries the patient ID, accession number and study instance UID populated from the worklist.
The radiologist reads in the PACS viewer and signs a report. The report returns to the EHR as an HL7 ORU message, either as a text block or, in better setups, as a structured result with discrete fields.
Finally the EHR needs a way to show the images, usually a context aware link that opens the right study in the viewer without a second login or a manual search.
Five hops, two standards, one accession number holding it together. Which is why this is fundamentally an interoperability and integration problem rather than an imaging problem, and why it gets solved at the interface layer rather than inside any one of the four systems.
Where it breaks
Patient identity does not survive the trip
If the worklist is missing or the technologist bypasses it, demographics get typed at the scanner. A transposed birth date or a dropped hyphen is enough to create a study the EHR cannot match to its order. The images exist, the report exists, and neither attaches to the right chart until somebody reconciles them by hand.
Even a low error rate adds up. A practice doing 150 studies a day with a 2% mismatch rate is correcting three studies every day, and each one is a delay in reporting and a risk of a result landing in the wrong record.
The accession number is not shared
The accession number is the thread tying the order, the images and the report together. When the RIS generates one number and the PACS another, or when the EHR sends an order without one and the PACS invents its own, the thread snaps. Reports come back as unsolicited results with no order to close, so the order sits open and the physician’s inbox never gets the resulted flag.
Reports arrive as pictures of text
Many integrations deliver the report as a PDF attached to a document message. That satisfies “the report is in the chart” while defeating most of the point. The impression cannot be pulled into a note, a follow up recommendation cannot trigger a reminder, and the report cannot be searched or trended. For a practice tracking incidental findings, a PDF is close to useless.
Images are one login away
Physicians in orthopedics, sports medicine and urgent care want to see the image as well as the report. If the EHR offers no image link, or the link opens a viewer demanding a separate login and a fresh patient search, most physicians stop using it within a month. Anything beyond one or two extra clicks gets abandoned. This is why an orthopedic EHR or an urgent care EHR is judged on image access in a way a primary care record never is: in those settings the image is the clinical decision, not a supporting document.
The interface was built once and never touched
Interfaces drift. The EHR upgrades and changes a field. A modality firmware update alters a DICOM tag. A new ultrasound unit arrives and nobody adds it to the worklist. Each change is small, and each one quietly removes a link in the chain until the department is back to typing and scanning.
What the broken loop actually costs
The clinical risks are the ones people talk about. The financial ones are larger, more measurable, and almost never attributed to the interface.
An imaging study bills as a technical component, a professional component, or globally, and the professional side generally cannot be billed until there is a signed report tied to the right patient and order. So every one of the failures above has a revenue consequence attached:
- An unmatched study is an open order and an unbilled professional component until someone reconciles it. At three a day, that is roughly sixty studies a month sitting in a queue.
- A report delivered as a PDF cannot populate the diagnosis or the finding that supports medical necessity, so the coder works from a document rather than from data, which is slower and more error prone.
- An order that never closes does not appear on a missing charge report as a missing charge. It appears as an open order, which is a clinical queue nobody reconciles against revenue.
This is the part worth carrying into a vendor conversation. An interface defect does not present as an interface defect. It presents as a coding backlog, an aging report, or a denial for insufficient documentation, and it gets investigated in the billing office rather than in IT.
Which is why practices that outsource radiology billing often surface integration problems faster than practices that do not. A billing operation working a queue of studies with no matched report asks why within a week. An internal team absorbs it as normal.
One more thing that changed: patients see the report first
Under the information blocking rules, diagnostic results now generally release to the patient portal as soon as they are available, rather than waiting for a physician to review and call. For imaging that has a specific consequence: a patient can read the radiologist’s impression before the ordering physician has opened it.
That is a workflow requirement rather than a compliance problem. Practices handling it well do two things. They make sure the ordering physician’s notification fires at the same moment the result posts, not on a nightly batch, which is only possible if the result arrives as a discrete result rather than a scanned document. And they prepare patients at the point of ordering for the fact that they may see the report before the conversation. Confirm current requirements and any applicable exceptions against the rules themselves, since implementation details vary.
Cloud PACS changes the network problem, not the data problem
Practices moving from an on site PACS to a cloud hosted one usually do it for storage, disaster recovery and remote reading. Those are real benefits. What a cloud PACS does not do on its own is fix any of the failures above.
The worklist still has to be fed from the order. The accession number still has to match. The report still has to come back as data. Some cloud vendors handle these through a small on premise gateway that speaks DICOM to the modalities and HL7 to the EHR. Others expect the practice to keep a broker. Either way the integration work is the same work with a different endpoint on one side.
Image access is the one place where cloud makes a real difference. A browser based viewer with a URL that carries patient context can be linked from any EHR without a desktop client, which removes the most common reason physicians stop looking at images.
When a practice evaluates PACS medical imaging software, the interoperability questions matter more than storage tiers or price per study: whether the vendor has a documented HL7 interface specification, whether the Modality Worklist is standard or a paid add on, and whether the viewer supports single sign on and a context passing launch URL.
What a working integration looks like
The easiest way to describe a healthy setup is by what does not happen.
Nobody types a name at the scanner. Every study, including walk ins and add ons, starts as an order in the EHR and appears on the modality worklist within seconds.
Nobody reconciles studies. The accession number is generated once, by the ordering system, and every downstream system uses it.
Nobody scans a report. The signed report arrives in the EHR as a discrete result, closes the order, and lands in the ordering physician’s inbox. If the report includes a follow up recommendation, the EHR can act on it.
Nobody logs in twice. From the chart result, one click opens the study in the viewer, already filtered to that patient and exam.
Nobody discovers a broken interface from a patient complaint. Message queues are monitored, and a failed ORU or a worklist entry that never fired raises an alert the same day.
What this looks like across different EHR platforms
The interfaces themselves are the same three regardless of platform: outbound orders, inbound results, and an image link launched from the chart. What differs is how much of the mapping is published in advance and how much happens during the project.
Large enterprise platforms publish detailed specifications, and a PACS vendor with a listed integration has usually done the mapping already. An Epic EHR integration for imaging is the well documented example of that pattern. Ambulatory platforms tend to be more configurable and to do more of the mapping inside the project, which cuts both ways: less is prescribed up front, and more can be shaped to how the practice actually works, including order code sets and result routing that an enterprise template would not bend to.
The variable that predicts success is not platform size. It is whether the practice owns three things, because no vendor can own them for you:
- A master list of every modality and its DICOM configuration, kept current as equipment changes.
- A mapping of order codes to procedure codes, maintained rather than set once.
- A named person who monitors the interface after go live, with the authority to escalate.
Vendors can build the interface. They cannot maintain a modality list they are not familiar with, and they will not notice that your new ultrasound unit never made it onto the worklist.
Questions to ask before signing anything
For the PACS vendor: Is the Modality Worklist included or licensed separately? Which HL7 version and message types are supported for orders and results? Can the report be returned as structured data rather than a document? Does the viewer support a context passing URL and single sign on with our EHR?
For the EHR vendor: Which imaging interfaces are available on our license tier? Is there a published integration with this PACS, or is this custom work? How are inbound results matched to orders, and what happens to unmatched ones? Can a signed result close the order and fire a notification in the same transaction?
For the integration partner, if there is one: Who monitors the interface after go live, and for how long? What happens when either vendor pushes an update that changes a field?
The answers will not always be encouraging. It is still far cheaper to learn that the worklist is an add on before the contract is signed than to learn it from a technologist six months later.
The point of all this
The goal of connecting a PACS to an EHR is to make the imaging result behave like every other result in the chart: ordered once, matched automatically, delivered as data, and viewable in one click.
Practices that get there stop losing studies, stop repeating scans, and stop paying staff to close gaps the software was supposed to close. Practices that settle for “the PDF is in the chart” keep paying those costs every day, in a coding backlog and an aging report queue, without ever seeing them on an invoice.
