The Year a Hospital Network Changed PACS Providers: An Evaluation Story

A composite narrative of a 5-site hospital network evaluating PACS providers — the shortlist, the SLA that failed scrutiny, and how the switch happened without downtime.

The decision to change PACS providers almost never begins with a catastrophe. It begins with a spreadsheet. This is a composite account — assembled from patterns RAD365 sees repeatedly across hospital assessments, with details changed and no real organisation identified — of how a five-site network with roughly 190,000 studies a year worked out that its support arrangement had stopped being an arrangement at all, and what the eleven months that followed actually looked like.

Scope note: RAD365 operates radiology infrastructure — uptime, DICOM connectivity, integrations, migrations, storage and vendor management. We do not read or interpret studies. Nothing below concerns clinical interpretation.

January: the spreadsheet

The imaging director had been asked for a three-year cost projection. Building it meant listing what was actually being paid for, and that turned out to be harder than expected. There was the PACS licence and its bundled support. There was a separate contract with the modality supplier at two sites. There was a regional IT firm on a break-fix hourly arrangement for anything network-adjacent. There was an integration consultancy retained by the day for interface work. And there was one PACS administrator, twelve years in post, who in practice absorbed everything that fell between those four contracts — which was most things.

The projection was not the problem. The problem was the column she added next to it, listing who owned each of the previous year's fourteen significant incidents. In nine cases the honest answer was "the administrator, personally, on her own time."

March: reading the incumbent's SLA properly

The incumbent's contract promised a four-hour response on critical issues. Under scrutiny three things emerged. "Response" meant an automated ticket acknowledgement, not an engineer. The clock started when the ticket was logged in the vendor's portal, not when imaging stopped — and out of hours, nobody was logging tickets. And "critical" was defined by the vendor's own product severity scale, so an incident where studies were reaching the archive but not reaching the reading room was a P3, because the product was technically functioning.

None of this was dishonest. It was a product support contract being asked to behave like an operational support contract, which is a category error that costs hospitals real money. The distinction between the two is the thing the whole evaluation eventually turned on, and it is worth understanding before any procurement starts — the structured version is set out in the RAD365 managed PACS services scope.

April: PACS system vendors versus PACS support providers

The network's first shortlist mixed the two categories together, and the proposals were incomparable as a result. Separating them clarified everything.

What PACS system vendors sell — and where their obligation stops

PACS system vendors build and license the imaging application: the archive, the viewer, the worklist, the administration tooling. Their support obligation covers defects in that product and configuration questions about it. That is a legitimate and necessary thing to buy. What it does not cover is the environment the product runs inside — the imaging VLAN, the storage array, the interface engine belonging to another vendor, the modality fleet, the identity service, the diagnostic displays. A vendor cannot reasonably be asked to own faults in systems they did not build and cannot see.

When comparing PACS system vendors against PACS support providers, the network eventually used a single framing question: if this incident spans two suppliers' products, who is contractually obliged to resolve it? Vendors answer "our part." Support providers answer "all of it." Both answers are honest; only one of them closes the gap in the spreadsheet.

The comparison the network ended up using

June: the four-question technical call

Four providers reached the technical stage. The network's administrator ran each call herself and asked the same four questions, which turned out to be more discriminating than the entire written RFP.

1. "A modality intermittently fails association, but only on large CT series. Walk me through your first hour." Two providers described opening a vendor ticket. Two described association logs, transfer syntax negotiation, MTU and fragmentation behaviour, and a packet capture. That single question halved the shortlist.
2. "When did you last restore a study from a client's backup and verify it opened?" One provider named a date and offered the report. The other described their backup monitoring, which is a different question.
3. "Describe an incident that spanned two vendors' products and what each vendor's support initially said." The answer reveals whether a provider actually owns cases or forwards them.
4. "Show me last quarter's SLA attainment across your book of business, including the misses." A provider that measures itself produces this in a day.

The four questions map closely onto the operating disciplines documented in the PACS support framework, which is not coincidental — they were chosen to test whether a framework exists in practice rather than in a proposal.

September: transition without downtime

The transition ran as an overlap, not a cutover. For six weeks both arrangements were live. The incoming team ran discovery across all five sites and produced a current-state document the network had never possessed. Monitoring went in parallel while the incumbent was still contractually responsible, which had the useful side effect of quantifying the baseline before anyone could claim credit for improving it. Read-only access first, then P3 categories, then P2, then P1 in the final fortnight. Credentials, runbooks and monitoring configuration transferred before the end date rather than on it.

Two things made the overlap work. The old contract's exit clause, negotiated years earlier, happened to require documentation hand-over — a clause that had seemed like boilerplate and turned out to be worth months. And the network resisted the temptation to bundle a platform migration into the same window. That came later, planned separately as PACS migration services work with its own reconciliation and parallel-run period, which is the only sane way to do it.

The following March: what actually changed

Total supplier spend was roughly flat. That surprised the finance committee, which had expected either a saving or an increase. What changed was distribution and accountability: four contracts became two, nine ownerless incidents became zero, and the administrator stopped being the escalation path of last resort — she moved to clinical workflow and hanging-protocol work, which was what the department had hired her for twelve years earlier.

The measurable items were unglamorous. Mean time to engagement on out-of-hours incidents fell from "the next morning" to inside the contracted window. A restore test ran quarterly with a written result. The archive capacity projection stopped being an annual surprise. Two recurring incident classes — a routing fault at the smallest site and an interface mismatch after every RIS update — were eliminated rather than repeatedly fixed, which is the difference a flat-fee incentive actually buys. Departments running the same evaluation against a single site or a shorter horizon often start with radiology PACS support scoped narrowly, then widen it once the model has proven itself.

If you are at the spreadsheet stage

1. List last year's significant incidents and name the contractual owner of each. Blank rows are your real finding.
2. Read your current SLA's definitions section — response, severity, clock start — before its promises.
3. Separate vendors from support providers in the shortlist so proposals are comparable.
4. Run the technical call yourself with your own administrator asking the questions.
5. Plan an overlap, not a cutover, and keep any platform migration in a separate window.

Related resources

• Managed PACS services from RAD365 — scope, SLAs and reporting
• What a managed PACS contract should include
• Radiology PACS support for hospitals and imaging centers
• PACS migration and archive consolidation
• Interim PACS support for transition periods
• 9 things that separate the best PACS support models