The 2 AM Outage That Changed How One Hospital Thought About PACS Support

A composite case study: a 2 AM PACS outage, two vendors blaming each other, and what vendor-agnostic managed PACS support would have prevented.

By Trisha Seal — August 28, 2026. Trisha covers RAD365's PACS and imaging-IT operations practice, where vendor-agnostic support teams run archive, interface and connectivity environments for hospitals and imaging centers.

At 2:07 AM on a Tuesday, the archive at a 240-bed regional hospital stopped accepting studies. The CT technologist noticed first — a scan she had just completed would not commit, and the retry produced the same silent failure. By 2:20 she had three unsent studies and an emergency department waiting on one of them. This is a composite account, drawn from patterns we see repeatedly in imaging environments, and it is a fair description of what inadequate PACS support looks like from the inside at two in the morning.

The imaging IT director — call him Dan — was woken at 2:31. What followed over the next nine hours is the reason this story is worth telling: almost none of that time was spent fixing anything.

02:31 — Two vendors, one fault, zero ownership

Dan called the PACS vendor's after-hours line first. The engineer who called back at 2:58 checked the application, found it running normally, and concluded the problem was upstream — at the third-party integration layer handling DICOM routing between the modalities and the archive. Not their product, not their ticket.

Dan then called the integrator. Their on-call engineer reached the environment at 3:40, confirmed the routing service was up, and concluded the archive was rejecting the writes. Not their product, not their ticket.

By 4:15 Dan had two engineers on two separate bridges, each accurately reporting that their own component was healthy, and no one whose job it was to look at the seam between them. The technologists, meanwhile, were doing what technologists always do in this situation: writing study details on paper, holding images locally on the modalities, and hoping nothing would be lost when it was eventually sorted out.

The cost that nobody was calculating at 4 AM

Nobody in that incident bridge was thinking in dollars, which is understandable and also part of the problem — because the number is large and it is known.

$94,000+

Average cost of a single imaging-system outage (Becker's CFO Report via AuntMinnie)

$55,415–$132,716

Estimated cost of a 3.5-hour outage at a 200-bed facility

2.3–7.0

Significant imaging outages per facility, per year

Those figures come from an analysis of Becker's Hospital CFO Report data published by AuntMinnie: PACS and imaging-system outages cost hospitals an average of more than $94,000 per incident, a 3.5-hour outage at a 200-bed facility runs between $55,415 and $132,716, and most facilities experience 2.3 to 7.0 such outages a year. Dan's outage ran to nine hours before studies flowed normally again — comfortably past the upper end of that estimate.

The second number from the same analysis explains why hospital CFOs react differently to imaging downtime once they have seen it: imaging accounts for roughly 37% of total hospital system revenue, with average per-bed imaging revenue of $370,190 a year. On a 240-bed estate, that is an imaging revenue line approaching $89 million annually, running through a system that stopped at 2:07 AM because two suppliers each correctly identified that the fault was not theirs. Uptime on that system is not an IT metric. It is a revenue control.

11:40 — What the fault actually was

It was a TLS certificate. The certificate securing the DICOM connection between the routing layer and the archive had expired at midnight UTC. Both components were genuinely healthy in isolation; the handshake between them was not. Each vendor's diagnostics were correct and each vendor's conclusion was correct, and the fault lived precisely in the gap that neither contract covered.

The relevant detail is not the certificate. It is that certificate expiry is a calendar event. It has a known date, months in advance, and monitoring it is trivial for anyone whose remit includes the whole environment rather than one product within it. That is the core of what managed PACS services are for: someone accountable for the joins, not just the components.

Reactive vendor support versus vendor-agnostic managed support

At 2 AM	Reactive vendor break-fix	Vendor-agnostic managed PACS support
Who detects the fault	A technologist, after it has already failed	Monitoring, at the threshold — often days before
Scope of responsibility	One product per contract	The whole imaging environment, including the joins
First hour spent on	Establishing whose fault it is	Restoring service
Vendor escalation	The hospital runs the bridge	The support partner owns and drives it
Certificates, capacity, interfaces	Unowned between contracts	Tracked on a maintenance calendar
Cost model	Time and materials, unpredictable	Flat monthly fee scoped to the estate
Disaster recovery	Backups complete; restores untested	Restore runbook tested on a set cadence

Dan's environment had support contracts covering every individual component and no contract covering the environment. That is an extremely common configuration and it is invisible until the night it isn't. For estates in that position while a longer-term arrangement is decided, interim PACS support covers the same ground on a defined-term basis, and teams needing L1/L2 depth under the imaging stack usually pair it with radiology IT support.

What is a Vendor-Neutral Archive (and why it matters for PACS support)

Six weeks after the outage, Dan's follow-up review turned up something he had half-known and never confronted: the hospital's imaging data sat in the outgoing PACS vendor's proprietary archive format. The platform was two years from end-of-life. Any move off it would require the vendor's cooperation on export — cooperation the hospital would be negotiating for at the exact moment it was telling them it was leaving.

A vendor neutral archive is the structural answer to that. A VNA stores imaging data in a standard, vendor-independent format — DICOM-conformant, with metadata and study relationships preserved outside any one application — so the archive is not hostage to the viewer sitting in front of it. Practically, that means three things: the hospital can change PACS vendors without a data-extraction negotiation, legacy and end-of-life systems can be decommissioned on the hospital's timetable rather than the vendor's, and multi-site estates running different PACS platforms can consolidate storage without consolidating applications first.

The market is moving decisively in that direction. The global VNA and PACS market is projected to grow from $4.88 billion in 2026 to $11.43 billion by 2035 — a 9.92% CAGR — with hospitals as the dominant end-user segment, according to Precedence Research. That growth reflects a real operational reality rather than a fashion: imaging IT environments are becoming more vendor-fragmented, not less, and a neutral archive is how a hospital keeps its own data portable across that fragmentation.

This is also why archive strategy and support strategy are the same conversation. A support partner that is vendor-agnostic by design can operate a VNA, a proprietary archive, or both during a transition — which is what most hospitals actually need, because migration is a phase, not an event. The sequencing, validation and reconciliation work involved is covered in detail under PACS migration services, and the component-level view of the stack sits alongside it.

What Dan changed

Three things, in order. First, he reconstructed the previous year's unplanned imaging downtime from ticket records — not incident count, but hours — and found 31 hours he had never totalled before. Second, he categorized each hour by root cause and marked whether monitoring would have caught it in advance; 24 of the 31 would have been. Third, he took both numbers to his CFO alongside the AuntMinnie cost figures, and the conversation about managed PACS support took eleven minutes.

The argument that worked was not about service levels or coverage models. It was that the hospital had already been paying for downtime for years without recording the amount. Once the amount was on paper, the support fee stopped looking like a new cost and started looking like a smaller version of an existing one. Governance and escalation structure for the new arrangement was drawn from a documented, ITIL-aligned support framework.

The certificate that caused all this now sits on a maintenance calendar with a ninety-day renewal alert. Nobody will ever notice it again, which is precisely the point.

PACS support and vendor-neutral archives: frequently asked questions

PACS Downtime & Business Impact

How much does PACS downtime actually cost a hospital?

PACS and imaging-system outages cost hospitals an average of more than $94,000 per incident, with a 3.5-hour outage at a 200-bed facility estimated between $55,415 and $132,716, and most facilities experience 2.3 to 7.0 such outages a year — per an analysis of Becker's Hospital CFO Report data published by AuntMinnie. The figure covers lost throughput, rescheduled and abandoned studies, staff time absorbed by workarounds, and the downstream delay to procedures that depend on the imaging result.

Why does PACS uptime matter more than most other hospital IT systems?

Because of what it is attached to financially. Imaging accounts for roughly 37% of total hospital system revenue, with average per-bed imaging revenue of $370,190 a year, according to the same Becker's Hospital CFO Report analysis — meaning PACS uptime is tied directly to one of a hospital's largest revenue lines. Very few other systems in the estate can stop a revenue stream of that size within minutes of failing.

How many PACS outages does the average hospital experience in a year?

Between 2.3 and 7.0 significant outages a year, according to the AuntMinnie analysis of Becker's Hospital CFO Report data. That range is worth sitting with: at the upper end, a hospital is losing imaging availability roughly every seven weeks. Most facilities cannot state their own figure from memory, which is usually the first sign that downtime hours are not being counted anywhere.

What's the difference between a full PACS outage and a "slow" PACS day?

A full outage means studies can't be read at all — clinical decisions stall. A slow PACS is a performance or capacity issue that degrades workflow without stopping it outright. Both point to the same underlying gap: nobody proactively monitoring the environment. Slow days are also the more expensive category in aggregate, because they are rarely logged as incidents and therefore never appear in the downtime total that budget decisions are based on.

What PACS Support Actually Covers

What is PACS support, exactly?

PACS support covers everything that keeps a Picture Archiving and Communication System running: 24/7 monitoring, DICOM/HL7 interface management, storage and archive lifecycle, workstation and modality connectivity, vendor escalation management, and disaster recovery — distinct from a single vendor supporting only its own software. The defining characteristic is that the boundary is drawn around the environment rather than around one product.

Is PACS support the same as calling the PACS vendor when something breaks?

No. A vendor supports its own product. Managed and outsourced PACS support covers the whole environment across every vendor the imaging stack touches, so nobody has to spend the outage arguing about whose problem it is. The practical difference shows up in the first hour of an incident: vendor support begins by establishing whether the fault is theirs, while environment support begins by restoring service.

What is a Vendor-Neutral Archive (VNA) and why does it matter for PACS support?

A vendor neutral archive stores imaging data in a standard, vendor-independent format, so a hospital is not locked into one PACS vendor's proprietary archive. That matters directly for migrations and legacy-system support: data can be moved, read, and validated without depending on the outgoing vendor's cooperation. The global VNA and PACS market is projected to grow from $4.88 billion in 2026 to $11.43 billion by 2035 — a 9.92% CAGR — with hospitals as the dominant end-user segment, according to Precedence Research, reflecting how much more complex and vendor-fragmented imaging IT environments are becoming.

Can PACS support cover a legacy or end-of-life PACS platform?

Yes — this is one of the most common reasons hospitals bring in outside PACS support: keeping a deprecated system stable and supported while they plan (but haven't yet executed) a migration. Vendor support for an end-of-life platform typically thins out well before the hospital is ready to move, leaving a gap of a year or more that has to be covered by someone who is not the vendor.

Choosing & Evaluating a PACS Support Partner

What questions should a hospital ask before signing a PACS support contract?

Ask about response-time commitments by severity level, whether coverage spans every vendor in the environment (not just one), how vendor escalations are actually managed, and what disaster-recovery testing cadence is guaranteed in writing. Then ask for the last three months of response-time reporting from an existing client environment of comparable size. Providers who measure themselves already have it.

How is managed PACS support typically priced?

Typically a flat, predictable monthly fee scoped to the environment's size and complexity — in contrast to unpredictable time-and-materials billing from ad hoc vendor support calls. The budgeting advantage is real but secondary; the more important effect is behavioural, because a flat fee removes the incentive to delay raising an issue until it becomes an outage.

Does PACS support require replacing the hospital's existing PACS platform?

No — PACS support works within whatever platform is already in place. It does not require a rip-and-replace. A support engagement should be able to start against the current estate, in its current condition, including the parts of it nobody is proud of.

What SLA response times should hospitals expect from a PACS support provider?

Response commitments should be defined by severity, with the fastest tier — critical, patient-care-impacting issues — typically measured in minutes, not hours. Just as important is who classifies severity: if the provider assigns the severity level unilaterally, a written minutes-level commitment can quietly become an hours-level response.

Can one PACS support provider cover multiple hospital sites running different PACS platforms at once?

Yes — this is one of the core reasons multi-site health systems outsource PACS support rather than staff every site separately. A single team with visibility across every site also sees patterns that site-by-site staffing cannot: the same interface fault recurring at three locations, or one site's storage curve diverging from the rest.

Staffing, Security & Compliance

Why do hospitals struggle to staff PACS administrators in-house?

Recruiting, training, and retaining a PACS administrator is expensive and slow, and a single in-house hire creates an immediate coverage gap the moment they take vacation, get sick, or leave. The role also sits awkwardly between clinical and IT reporting lines, which makes it easy to under-resource and hard to backfill quickly when the incumbent moves on.

Is outsourced PACS support HIPAA compliant?

A reputable PACS support provider operates on encrypted, audit-trailed infrastructure and signs a business associate agreement (BAA) covering all PHI the imaging environment touches. Access should be role-scoped and logged, with the hospital able to review who accessed what and when without having to request it as a special report.

What happens to disaster recovery and backups under a managed PACS model?

DR and backups become the support provider's responsibility, with recovery procedures tested on a defined schedule rather than left unverified until an actual failure happens. The distinction that matters is between a backup that completes and a restore that has been proven — plenty of hospitals discover during an incident that only the first was ever confirmed.

Does managed PACS support include help planning future migrations, not just day-to-day maintenance?

Yes — ongoing strategic roadmap planning (refresh cycles, consolidation, migration prep) is typically part of a managed PACS engagement, not a separate project. The team running the environment daily holds the most accurate picture of what is actually connected to what, which is precisely the knowledge a migration plan depends on.