Inside One Hospital's Search for the Right PACS Provider

A hospital IT director evaluated four PACS providers. What separated the winner wasn't price or brand — it was the answers to five uncomfortable questions.

Four PACS providers sat in the shortlist folder on a hospital IT director's desk, and on paper they were indistinguishable. Each proposal promised 24/7 coverage. Each listed monitoring, incident response, DICOM administration and vendor escalation. Each carried a monthly figure within about fifteen percent of the others. The director — three sites, two PACS platforms inherited through an acquisition, one archive quietly running out of headroom — had exactly one useful question and no obvious way to answer it: which of these four would actually fix a stalled archive at 3am on a Sunday?

What follows is how that question got answered. The names are withheld; the process is not. It is close to how most managed PACS services evaluations should run and almost never do.

The starting position: two platforms, one budget, no documentation

The estate had grown the way most do. The main hospital ran one PACS; a community site acquired two years earlier ran another; a third site fed studies into whichever archive its modalities had been pointed at during installation. Nobody had a current node inventory. The interface map existed as a diagram drawn in a meeting eighteen months earlier and never updated. The single PACS administrator had been on the payroll for nine years and, in the director's own assessment, was the documentation.

The trigger was not a disaster. It was a two-week annual leave during which two modalities stopped routing correctly and the studies were found manually. Nothing was lost. It was simply obvious, for the first time, how thin the layer was.

Question one: who exactly is awake at 3am?

All four proposals said 24/7. The director asked each provider for the shift roster: how many engineers on the overnight shift, awake and on shift or on call from home, how many accounts each covered, what they were authorised to change without waking a manager, and how the roster changed on public holidays.

Two providers answered with a service-desk description. One answered with an on-call rota where the responder covered eleven accounts across three service lines. One answered with a named roster, a stated authority level for P1 conditions, and an offer to introduce the engineers who would hold the account. The shortlist effectively halved in a single email exchange.

Question two: what is explicitly out of scope?

Every provider had listed what was included. The director asked for the exclusions, element by element. This produced the most informative document of the whole process: one provider's cheapest tier excluded interface engine changes, storage expansion planning and any out-of-hours change window — three things this estate needed within the first six months.

Radiology IT support: the boundary that decided it

The most consequential question turned out to be a boundary question. Two of the proposals scoped PACS support narrowly — the application, DICOM routing, worklists and archive — and left everything underneath to the hospital. But the incidents this estate actually suffered were not application incidents. They were imaging VLAN reachability, latency between a community site and the central archive, a firewall rule change that broke a C-STORE association, a diagnostic workstation build inconsistency. Those live in radiology IT support: the network, workstation, identity and virtualisation layer the imaging chain runs on.

Split across two contracts, each of those incidents starts with a jurisdiction argument. The director had lived through enough of them to price the argument realistically. The winning proposal put both layers under one contract, one severity framework and one escalation path — which meant no incident could begin with a debate about whose problem it was. That single structural choice mattered more than any line item in the pricing table.

Question three: can you describe our architecture back to us?

Before the technical session, the director sent each provider the same partial information: vendor names, site counts, approximate study volume, and the fact of the dual-platform estate. In the session, each was asked to describe how they would expect study flow to work and where they would expect it to fail.

Three gave general answers. One walked through the likely AE-title collision risk across two platforms sharing modalities, asked whether the community site's link queued locally during an outage, and asked to see the archive growth rate before commenting on headroom. It was not a sales answer. It was an engineering answer given before any contract existed.

Question four: tell me about a night you failed

Reference calls were structured deliberately around failure. Not "are you happy with them" but "describe your worst incident since onboarding": what happened, how quickly it was detected, who responded, whether the SLA was met, whether the root cause recurred, and whether the monthly report disclosed the miss.

One reference described a missed Severity 1 target that appeared in the monthly report with a root-cause record and a permanent fix attached. That disclosure was worth more than the three flawless accounts described elsewhere. Providers who never miss a target either have very easy clients or a reporting process that does not surface misses.

Question five: what happens when we leave?

The exit clause was requested before price negotiation, deliberately. The director wanted to see who would write clean terms while still competing for the business: data, configuration, documentation and runbooks as hospital property; a hand-over package within a defined window at no extra charge; a 90-day transition period at standard rates. The winning provider sent it back amended in the hospital's favour without being asked twice.

How the four compared

What discovery found

Three weeks of discovery produced the estate's first complete node inventory, an interface map with message specifications, a tested restore of a real study set, and an archive growth projection that put the central store inside twelve months of its ceiling. None of that was a surprise to the incoming engineers; all of it was new to the hospital. The documentation was written into the contract as hospital property from day one.

The consolidation of the two platforms was then planned properly rather than urgently, staged through PACS migration services with dual-feed routing during the overlap and verified batch migration of history — instead of the compressed weekend the previous year's budget cycle had imagined.

The process, in six steps

1. Inventory first. Even a partial one. Providers cannot quote accurately against a guess, and the gaps tell you where your risk is.
2. Shortlist on two hard filters. Genuine coverage of your actual vendor mix, and staffed after-hours engineering.
3. Request exclusions, not inclusions. The exclusions list is the real scope document.
4. Settle the radiology IT boundary explicitly. One contract across both layers, or a written seam you have agreed to live with.
5. Structure references around failure. Ask about the worst night, not the launch.
6. Negotiate the exit clause while you still have leverage. It never gets easier later.

If your own estate is mid-consolidation or short an administrator while you run this process, interim PACS support can hold the line so evaluation is not conducted under pressure.

Related resources

• RAD365 managed PACS services — the full scope, SLA and coverage model
• Compare managed PACS support options — tiers, staffing and reporting
• Radiology IT support — network, workstation and infrastructure coverage
• PACS support framework — severity levels and escalation matrix
• PACS in radiology — architecture and operational fundamentals
• How a hospital network changed PACS providers — a second transition story