Cloud PACS vs onsite

What "cloud PACS" actually means

A cloud PACS vendor hosts your imaging archive on their servers, in their data center, and rents you access to it every month. Your CT, MR, US and X-ray studies leave the building the moment they are acquired, travel over the internet, and land on infrastructure you do not control. You view them through a browser or a plugin the vendor ships. If you stop paying, the vendor decides what happens to your archive next, not you.

This is a legitimate model. It removes the question of who racks a server and who patches it. For a clinic with no interest in owning hardware, that tradeoff can be worth the monthly bill.

A note on vendor lists: "cloud-based PACS", "web PACS" and "RIS PACS system" mostly describe the same rented archive, sometimes bundled with scheduling and billing (the RIS side). When comparing PACS system vendors, the questions below matter more than which of those labels the brochure uses.

What onsite PACS means today, not in 2005

The image of onsite PACS (on-premise, or on-prem) as a server room with a dedicated IT hire is out of date. A modern self-hosted stack like MiniPACS is a handful of containers on one machine, either a small server the clinic already has, a mini PC, or the clinic's own cloud account. It is installed remotely over a secure tunnel, with zero ports open to the internet, daily encrypted backups and a watchdog that restarts anything that crashes. The clinic's own involvement is a 15-minute call. On the local server or mini PC options, studies never leave the building unless the clinic explicitly exports them; the own-cloud option trades that for someone else's building with your keys.

The viewer is a browser tab, the same as cloud PACS. The difference is where the data and the compute sit, and what that does to speed, cost and control. The sharing question sits next to that decision: see medical image sharing workflows for portals, direct DICOM transfer and keeping the source archive authoritative.

When cloud is the right call

Cloud PACS wins in a few specific situations, and it is worth naming them plainly instead of pretending onsite is always better:

• Zero appetite for owning hardware, even a small box, and someone else's ops team is worth the monthly rent.
• Reading groups whose radiologists have no site at all to host anything: everyone is remote and no clinic in the group can own the box. If the group has locations, onsite still works, one server and license per site.
• Very low volume, a handful of studies a month, where the fixed cost of any onsite setup is hard to justify regardless of the long-run math.

When onsite wins

Outside those cases, onsite pulls ahead on the three things that matter day to day:

• Speed and resilience. A study acquired on a local server lands on the worklist automatically, typically within about a minute of the last image, with no upload-then-download round trip. A cloud PACS has to push each study up to the datacenter and pull it back down before it opens, so every read waits on your bandwidth, and if the internet drops, reading stops with it. On the LAN, a local server keeps working.
• Data stays in the building. Nothing is transmitted off site by default. There is no vendor data center holding patient imaging, and no dependency on the internet staying up for reading to continue: a local network keeps working even if the connection to the outside world drops.
• The 5-year math. Below a certain monthly rent, cloud is cheaper. Above it, owning wins, and it keeps winning every year after that. The next section works the arithmetic.

The 5-year math

Take a typical cloud PACS bill of $700 a month. Over 60 months that is:

• $700 x 60 = $42,000 paid in rent, with nothing owned at the end.
• Against that, the MiniPACS + Vendo combo license is $640/month billed yearly, or $7,680/year. Over five years: $7,680 x 5 = $38,400.

$42,000 vs $38,400 is already a win for onsite at $700/month, and the gap only widens as the monthly rent goes up. The break-even sits at $642/month: $642 x 60 = $38,520, almost exactly the five-year cost of the owned license. Below $642/month, renting is technically cheaper on paper. Above it, which is where most clinic-facing cloud PACS pricing sits, the owned license costs less by year two and keeps costing less every year after.

The math ignores one more asymmetry: rent never stops. At year six, the cloud PACS clinic has paid $50,400 and still pays every month going forward. The onsite clinic has paid $38,400 over five years, and the archive sits on hardware it controls. For your own monthly bill, locations and study volume, use the cloud PACS cost calculator.

The ledger, row by row

This is the same comparison as the landing page, restated in full. Every row is something a clinic can verify in the live demo.

How to decide

Run through this in order:

• Estimate current or expected monthly volume. If it is a handful of studies a month, cloud's flat low-commitment pricing may still make sense.
• Check the current or quoted monthly rent. If it is meaningfully above $642/month, the five-year math already favors owning.
• Decide how much reading-day resilience matters. A cloud PACS makes every study wait on an upload-then-download round trip and stops entirely when the connection does; a local server keeps the worklist and viewer working on the LAN. That is a recurring operational difference, not a one-time decision.
• Decide how much it matters that imaging never leaves the building. For some clinics this is a compliance preference, not just a technical one.
• Compare that against the fixed cost of standing up onsite, which for a modern containerized stack is a 15-minute call and a setup fee, not a server room build-out.

For more background on how a PACS fits into the imaging workflow generally, see what is PACS. For the self-hosted case stated directly against per-study cloud billing, see the cloud PACS alternative. For clinics evaluating the open-source route specifically, see the Orthanc alternative comparison.

FAQ