Managed PACS Support and the Uptime Data: What Downtime Actually Costs a Hospital

Downtime costs hospitals up to $25,000 a minute. Here's what the uptime data says about managed PACS support versus reactive break-fix cover.

Managed PACS support is almost always evaluated as a capability question — what does the provider cover, how fast do they answer, what is on the scope sheet. That framing quietly skips the only variable that determines whether the arrangement pays for itself: how many hours of imaging unavailability a facility experiences in a year, and what each of those hours costs. The published downtime figures for healthcare are large enough that the arithmetic usually settles the question before the capability comparison begins.

By Trisha Seal · August 27, 2026 · Written from RAD365's operational experience running vendor-agnostic managed PACS and radiology IT operations across mixed hospital imaging estates.

$7,500

estimated average hospital loss per minute of IT downtime (Censinet)

$25,000

per minute at large hospitals (Censinet)

$1.7M

estimated hourly downtime cost, medium-sized hospital — $3.2M at large hospitals (Censinet)

$79K/hr

healthcare ransomware downtime cost, ~$1.9M per day, across 654 incidents 2018–2024 (Comparitech)

Start with the per-minute number

Censinet estimates the average hospital loses roughly $7,500 for every minute of IT downtime, and puts the figure closer to $25,000 a minute at large hospitals. Those are whole-organization numbers rather than imaging-specific ones, but imaging is among the most tightly coupled dependencies in the building: when studies cannot be stored, retrieved or read, the emergency department stalls, theatre lists slip, outpatient clinics run blind and downstream reporting queues.

Scaled up, Censinet's hourly figures are $1.7 million for a medium-sized hospital and $3.2 million for a large one. Whatever discount you apply to fit imaging's share of that dependency — and it should be a discount, since not all hospital activity halts when PACS does — the residual is still a number that dwarfs any plausible annual support fee. That is the arithmetic that makes uptime a procurement question rather than an IT one.

Two different shapes of downtime

The cost figures above describe unplanned outages of the ordinary kind: a failed storage array, an expired certificate, a routing rule that stopped matching, a botched patch. These are typically measured in hours and resolved the same day.

Ransomware behaves differently. Comparitech, analyzing 654 confirmed healthcare ransomware incidents between 2018 and 2024, puts the associated downtime cost at approximately $79,000 per hour — roughly $1.9 million per day. The hourly figure is markedly lower than Censinet's general estimate, but the duration is the point: these events run for days or weeks, not hours, and imaging systems are frequently among the last to be restored because of data volume and validation requirements. ITIC's research, which ranks healthcare as the most expensive industry for hourly outage cost with some scenarios exceeding $5 million per hour, sits at the upper bound of the same picture.

Both shapes argue for the same operational posture, for different reasons. Ordinary outages are shortened by detection and ownership. Extended events are shortened by tested recovery procedures, validated backups and someone who knows the estate well enough to sequence the restore correctly.

Where the hours actually come from

Reconstructing last year's unplanned downtime from incident tickets is an exercise most departments have never done, and it is consistently revealing. In the estates we take on, the hours cluster in a small number of recurring categories:

Storage and capacity events. Archive headroom crossing a threshold nobody was monitoring, producing write failures rather than a warning.
Interface and acknowledgement failures. Results appearing complete in the RIS and absent in the EHR, or the reverse, often undetected for hours.
Routing rules silently ceasing to match after a network, IP or firewall change made elsewhere in the organization.
Certificate and credential expiry on gateways and integration points — entirely preventable, and among the most common causes of a sudden overnight stoppage.
Change collisions. An enterprise patch window applied without reference to the imaging estate's dependencies.

What these have in common is that all five are detectable in advance by monitoring a defined metric against a defined threshold. None of them require the vendor's source code to prevent. That is the practical distinction between a managed operation and a break-fix arrangement: the same fault, encountered as a scheduled task or as an outage.

PACS radiology: the terminology, and why it matters to scoping

Departments rarely search for "picture archiving and communication system support." They search for PACS radiology — a loose umbrella term covering the whole imaging technology stack: archive, viewers, worklist, routing, gateways, and the interfaces binding them to the RIS and EHR. It is not a formal product category, which is exactly why it is useful: it describes the estate the way the people responsible for it actually think about it.

The scoping consequence is significant. A support agreement written against "the PACS" tends to mean the archive application. A support agreement written against the PACS radiology stack includes the joins — and, as the downtime categories above show, the joins are where the hours come from. When we scope managed PACS services, the boundary is drawn around the stack rather than the product, because a boundary drawn around the product leaves the most common faults outside it.

For teams mapping their own estate against that definition, the component-by-component breakdown on our PACS radiology page is the practical starting point, and the connectivity layer specifically is covered under DICOM gateway and interface support.

Reactive versus proactive, priced against the data

Failure category	Reactive break-fix outcome	Proactively monitored outcome
Archive capacity exhaustion	Write failures; multi-hour outage; emergency procurement	Threshold alert weeks ahead; planned expansion
Certificate expiry on a gateway	Sudden transfer stoppage, often overnight	Renewal scheduled from an expiry calendar
Routing rule stops matching	Studies missing from worklists; discovered by a radiologist	Queue-depth and delivery alert within minutes
Interface acknowledgement failure	Results silently missing; found during reconciliation	Ack-rate monitoring flags the drop immediately
Enterprise patch collision	Imaging outage attributed to "the network"	Change control includes imaging dependency review
Ransomware recovery	Restore sequence improvised under pressure	Tested restore runbook, validated backups, known RTO

Read against Censinet's per-minute figures, each row in the right-hand column represents avoided cost that is straightforward to estimate and rarely estimated. A single prevented four-hour outage at a medium-sized hospital, on those numbers, is measured in millions — which is why the sensible comparison is not support fee against support fee, but support fee against last year's reconstructed downtime hours.

A four-step way to run the numbers for your own estate

Reconstruct last year's unplanned imaging downtime from incident tickets and change records. Count hours, not incidents, and include partial degradation where reading was materially slowed.
Categorize each hour by root cause using the categories above. Mark each as monitorable or not monitorable in advance. In most estates the monitorable share is the large majority.
Apply an hourly cost. Use an imaging-adjusted fraction of the Censinet hourly figure appropriate to your size, and document the assumption so the number can be challenged rather than dismissed.
Compare against contracted support cost for the coverage window you would actually buy — and separately against the cost of recruiting and retaining the equivalent in-house capability, including the rota gaps that recruitment does not close. Where an estate is between platforms or between staff, interim PACS support covers the same ground on a defined-term basis.

Departments that run this calculation usually find the decision was never really about the support fee. It was about whether anyone had counted the hours. Teams needing L1/L2 coverage layered underneath the imaging estate should read this alongside radiology IT support.

Managed PACS support and PACS radiology: frequently asked questions

What managed PACS support covers, in numbers

Which parts of a radiology department's day are actually touched by PACS support services?

More than the PACS application itself, which is why scope definitions matter more than service names. A working scope covers the archive and its capacity headroom, the DICOM services that move studies between modality, gateway and archive, the interface layer carrying orders and results, worklist and routing configuration, user and role administration, QC and study-correction work, patch and change control, and coordination with every OEM in the estate. If a scope statement stops at the application, the faults that most commonly interrupt a reading session — routing, interface acknowledgement, network path — sit outside it.

How much downtime does proactive monitoring actually prevent, and what is that worth?

The value is easiest to see through the cost side. Censinet estimates the average hospital loses roughly $7,500 for every minute of IT downtime, rising to around $25,000 a minute at large hospitals. At those rates, the difference between detecting a filling archive at 60% capacity and discovering it when writes fail is not an operational nicety — a single prevented multi-hour outage can exceed the annual cost of the monitoring that prevented it. Proactive monitoring does not eliminate incidents; it converts a category of them from outages into scheduled work.

What does an hour of PACS downtime cost a hospital in practice?

Censinet's figures put estimated downtime cost at approximately $1.7 million per hour for a medium-sized hospital and around $3.2 million per hour for a large one. Comparitech, analyzing 654 confirmed healthcare ransomware incidents between 2018 and 2024, puts ransomware-driven downtime at roughly $79,000 per hour, or about $1.9 million per day — a lower hourly figure, but sustained over days rather than hours. ITIC research separately ranks healthcare as the most expensive industry for hourly outage cost, exceeding $5 million per hour in some scenarios. The spread across these sources is wide, but the direction is unambiguous.

How should a mid-sized clinic think about the cost of PACS support relative to that risk?

As a ratio rather than a line item. Take your realistic hourly cost of imaging unavailability, multiply by the hours of unplanned downtime you actually experienced last year — most departments have to reconstruct this from incident tickets, which is itself informative — and compare the result with an annual support cost. Pricing structures vary with estate size, number of sites, modality count, platform mix and coverage window, so a single figure is meaningless without those inputs. What is consistent is that the comparison rarely turns on the support fee; it turns on how many hours were lost.

Does support scope change when a department runs many modality types on one archive?

It broadens, mainly at the edges. Each modality brings its own DICOM conformance quirks, its own header conventions and its own gateway behavior, and the faults that arise are usually at the joins rather than inside the archive — a CT sending a tag the archive stores differently from the ultrasound, a mammography workstation expecting a presentation state that never arrived. Vendor-agnostic support exists precisely to own those joins, since no single modality OEM will.

Managed PACS versus in-house and vendor break-fix

Where does managed PACS end and in-house IT begin, and who owns the overlap?

The overlap is where most unresolved incidents live, so it should be written down before go-live rather than negotiated during an outage. A workable split gives the managed partner continuous monitoring, imaging-specific incident ownership, DICOM and interface diagnosis, configuration and lifecycle work, and OEM coordination; in-house IT retains physical infrastructure, enterprise network and identity, endpoint support and on-site presence. The joint items — firewall changes, certificate renewals, storage expansion — need a named owner each. A RACI that lists them explicitly is worth more than a longer scope document that does not.

What separates genuine 24/7 monitoring from a 24/7 phone number?

Whether anything is being watched when nobody has called. Genuine monitoring means defined thresholds on archive capacity, DICOM service availability, interface acknowledgement rates, queue depth and job failures, with alerts routed to a staffed rota and an expected response for each severity level. A 24/7 phone number means a human answers after you have already noticed the problem. Both are described in proposals with the same phrase. Ask which specific metrics are monitored, at what thresholds, and to see a real alert-to-resolution timeline from the last month.

What should a hospital verify in a support contract that proposals rarely volunteer?

Four things. Measured historical SLA attainment rather than the target, with a clear definition of when the clock starts and stops. Whether a breach remedy has ever actually been paid, which tells you whether the SLA is enforced or decorative. Whether DICOM, gateway, interface and network layers are in scope in writing. And who owns the environment documentation at exit — a provider holding your estate map exclusively has created a dependency, not delivered a service. Our own answers to these are laid out in the PACS support framework.

What changes financially when PACS operations move from reactive to contracted?

The volatility, more than the total. Reactive support costs are dominated by the incidents themselves — emergency engineering time, overtime, deferred imaging revenue, occasionally penalty exposure — and those arrive unforecast. A contracted arrangement moves the bulk of that spend into a predictable base with variable elements for project work. Against Censinet's $1.7 million per hour figure for a medium-sized hospital, the case is less about reducing average annual spend and more about removing the tail events that make the average meaningless.

What uptime and response commitments are realistic to hold a provider to?

Severity-tiered response and restoration targets are more meaningful than a headline availability percentage, because 99.9% availability still permits nearly nine hours of downtime a year and says nothing about when those hours fall. Ask for: response targets per severity level, restoration targets where restoration is within the provider's control, an explicit exclusion list, a defined measurement method, monthly reporting against attainment, and a remedy for breach. Then ask for last year's attainment against those same tiers.

PACS radiology: the terminology hospital teams actually use

What does "PACS radiology" refer to, and why does the phrasing vary so much?

"PACS radiology" is the umbrella phrase departments use for the imaging technology stack as a whole — archive, viewers, worklist, routing, gateways and the interfaces that connect them to the RIS and EHR. It is not a formal product category, which is why it appears in searches far more often than in contracts. The variation exists because different teams enter the topic from different directions: IT searches for infrastructure terms, radiology searches for workflow terms, and procurement searches for service terms. All three are describing the same estate. A plain-language overview of that stack sits on our PACS radiology page.

Which components of the PACS radiology stack fail most often?

In our operational experience the archive application itself is among the more stable components; the recurring faults concentrate at the joins. Routing rules that silently stop matching after a firewall or IP change. Interface engines dropping acknowledgements so results appear complete on one side and missing on the other. Gateway certificates expiring. Storage headroom crossing a threshold nobody was watching. Duplicate or mismatched patient identifiers from a registration change. Each is cheap to prevent with monitoring and expensive to diagnose during a live incident.

How does the PACS layer relate to RIS, VNA and EHR imaging integration?

PACS stores and serves the images and drives the reading workflow. The RIS handles orders, scheduling and reporting workflow. A VNA, where present, provides vendor-neutral long-term storage beneath or alongside the PACS. The EHR consumes results and often embeds a viewer. Nearly every cross-system failure occurs in the messaging between these components rather than inside any one of them, which is why DICOM and interface connectivity belongs inside a support scope rather than being treated as a separate project category.

Does modernising PACS radiology infrastructure require replacing the platform?

Frequently not, and assuming otherwise is an expensive default. A significant share of the performance and reliability complaints we are asked to investigate resolve through configuration rather than replacement: routing rule cleanup, prefetch and hanging protocol tuning, storage tiering, query optimization, purging orphaned study records. Replacement is warranted when the platform is genuinely end-of-life, unsupportable or blocking a clinical requirement — and when it is, it should be planned as a structured migration rather than triggered by a bad quarter.

Evaluating providers on evidence

What evidence should a large hospital network ask for before shortlisting a support provider?

Evidence that survives a follow-up question. Measured SLA attainment for the last twelve months, not the target. A redacted incident timeline from a genuine major incident, showing detection, escalation, resolution and the post-incident change. Confirmation of multi-vendor experience with the specific platforms in your estate, including any end-of-life systems. Named escalation contacts and rota structure. And a reference from a network of comparable size and complexity, ideally one that went through a migration with them. Marketing claims and case-study prose are not evidence.

How do you tell a technically strong provider from a well-presented one?

Ask about failure. A strong provider will describe a specific incident they handled badly, what the root cause turned out to be, and what changed in their process afterwards — because operating at scale guarantees such incidents and mature teams treat them as inputs. A weaker provider will redirect to capability statements. The same test applies to metrics: strength shows up as segmented, percentile-based reporting, weakness as blended averages.

What should a provider be able to demonstrate about migrations and upgrades specifically?

A migration is where support quality becomes visible, because it exercises data integrity, downtime planning, validation and rollback all at once. Ask for the migration methodology in writing: how study counts and integrity are validated pre and post-move, how priors are reconciled, what the cutover downtime window is and how it was arrived at, what the rollback trigger and procedure are, and who is accountable if the counts do not reconcile. Then ask for the number of studies migrated in their largest completed project and what went wrong in it.

What compliance and security posture should a healthcare IT support provider evidence?

At minimum: a signed BAA, HIPAA-aligned administrative, physical and technical safeguards, documented access control with least-privilege and revocation on personnel change, audit logging of administrative actions on imaging systems, encryption in transit and at rest, and a tested incident response plan with defined notification timelines. Given Comparitech's finding of 654 confirmed healthcare ransomware incidents between 2018 and 2024, ask specifically how the provider's access into your environment is segmented and monitored — the support pathway is itself part of your attack surface.