Cloud PACS or on-premise?

Most centre owners who ask us about cloud PACS in India have already half-decided. Either the server in the back room has died once too often, or a second centre is opening and nobody wants to buy another server, another UPS and another annual maintenance contract. Sometimes it is the opposite: the owner has been burnt by a slow web viewer and wants everything on a box they can touch.

Both instincts are reasonable, and neither is a decision on its own. The advantage of an on-premise PACS is that it sits on the LAN, next to the modalities, and does not care what the internet is doing; its disadvantage is that every additional site, remote reader and backup becomes a separate project. A cloud PACS turns those projects into configuration, but it moves the weak point to the line between your scanner and the data centre. Herman Oosterwijk made a related point in his recent piece What's beyond PACS 3.0?: running PACS in the cloud is becoming universal, but much of it is still the same software in a virtual machine on someone else's server. So how a system is built for the cloud matters as much as where it runs. Let's go over the things you can actually measure, in the order we would look at them.

Start with your upload speed, not the brochure

A cloud PACS is only as good as the line from your modality to the data centre. For PACS, what matters is the upload, because every study your CT or MR produces has to go up before anyone else can read it.

Study sizes are bigger than most people think. A 2013 paper in the Journal of Digital Imaging measured average study sizes at one institution of roughly 153 MB for CT, 99 MB for MR, 84 MB for mammography, 14 MB for CR and 366 MB for PET. They are on the low side for today. A single 512 × 512 CT slice stored at 16 bits is about half a megabyte uncompressed, so a thin-slice chest-abdomen-pelvis with 1,200 images is already around 600 MB before you add a contrast phase. Breast tomosynthesis is worse: David Clunie estimated about 350 MB for a four-view tomo study even after lossless compression, not counting the 2D views.

Now do the arithmetic for your own centre. A 600 MB study is 4,800 megabits. On a line that genuinely delivers 20 Mbps upstream, that is four minutes per study, assuming nothing else is using the line. At 100 Mbps it is under a minute. Multiply by a busy day's CTs and you will see whether your line chokes at 11 a.m.

Two practical points follow from this. Get a business line with a stated upload speed, not a home plan, and get a second line from a different provider on a different physical path, because sooner or later a JCB will dig up the fibre on your main road. (If terms such as C-STORE and DICOMweb are new to you, our guide to what DICOM is explains how images actually travel between machines.)

The edge gateway: why a good cloud setup is never fully in the cloud

A sensible cloud PACS keeps a small local device or server at the centre, usually called an edge gateway or local cache. Modalities send studies to it over the LAN, which is fast and does not care whether the internet is up. The gateway then pushes studies to the cloud in the background and retries if the line drops.

On-premise keeps everything local; a good cloud setup adds an edge gateway and storage tiers.

The result is that your technologists never wait on the internet to free up the scanner console, and if the line goes down, studies queue and go up when it comes back. Many setups also keep recent studies and priors on the gateway, so a radiologist sitting inside the centre can open them at LAN speed.

When you evaluate a vendor, ask exactly what happens in the first ten minutes after the internet fails. We would put three questions to them:

1. Can the in-house radiologist still open today's studies?

2. Can the front desk still register patients?

3. Can a report be typed and printed?

If the answer to all three is "no", you are buying a system with a single point of failure on a public road.

Storage tiers, backups and the real cost

Not every study needs to open in two seconds forever. Cloud storage is usually sold in tiers: fast "hot" storage that is more expensive per GB, and cheaper archive tiers where retrieval is slower or costs extra. The big cloud providers publish these classes openly; AWS's list of S3 storage classes is a good example of how the trade-off between price and retrieval time works. For a radiology archive, a common pattern is to keep the last 12 to 24 months and all priors for active patients in hot storage, and move older studies to an archive tier. The question to ask is how a prior from four years ago behaves when a patient comes back for a follow-up. If it takes hours to restore, your radiologist will report without it, so make the vendor show you an old prior being fetched, live.

Backups deserve the same scepticism. Ask any on-premise centre when they last tested a restore from backup. A cloud provider typically replicates data across disks and often across zones or regions, which protects you against fire, flood and the server room AC failing in May. Replication is not the same as backup, though. If someone deletes a study or ransomware encrypts it, replication can copy the damage. Ask the vendor for three things in writing: how often backups run, how long they are kept, and how quickly a deleted study can be restored.

Then there is cost. On-premise looks cheaper because you pay once. The real bill includes the server, storage that you will outgrow, a UPS and its batteries, air-conditioning, an OS and database licence, backup media, an AMC, and the person who gets called at night when it stops, and most of that hardware needs replacing every five years or so. Cloud turns this into a recurring fee, usually per study or per centre. It is easier to start and easier to scale when you add a centre; over many years it can cost more than a server that happens to run trouble-free, so model it for your volume. Just compare it against the full on-premise cost, not the price of the server alone.

Data residency and the DPDP Act

Under the Digital Personal Data Protection Act, 2023, your centre is the Data Fiduciary for patient data and the PACS vendor processes it on your behalf under a contract (sections 2 and 8). The Act does not ban storing data abroad; section 16 lets the government restrict transfers to countries it notifies. Even so, most Indian centres prefer their images to sit in an Indian cloud region, and you should get the region named in the contract. The DPDP Rules, 2025 also list the security safeguards expected of you and your processor, including encryption, access control, logging and backups (Rule 6), which apply from around May 2027, eighteen months after the Rules were notified. This is general information; talk to your counsel about your own contracts.

Where cloud clearly wins, and how to get there

If you run a single centre with in-house radiologists, a well-maintained on-premise PACS can serve you fine. The case for cloud gets strong the moment there is more than one site or more than one reading location. With everything in one archive, a patient scanned in one branch last year has their prior available in another branch today. Radiologists log in once and see one worklist across centres. A night-time CT can be read by a radiologist at home, or by a teleradiology partner, without anyone setting up a VPN to the centre (Dr. Vishwanath has written about why teleradiology in India needs more transparency, which is a separate question from the plumbing). Referring doctors can be sent a link instead of a CD. On-premise, each of these is a separate project and another hole in your firewall.

Getting there means migrating from the old system, and migration is where projects slip. Before you sign, ask:

1. How many studies and how many TB are in the old system, and who will extract them? Old PACS often move data slowly over DICOM, so a large archive can take weeks.

2. Will old reports come across? If they live in Word files or a separate RIS, they need a plan of their own.

3. How will patient IDs be matched, especially if the same patient was registered twice with different spellings?

4. Will you run both systems in parallel for a period, and who checks the study counts at the end?

A good vendor migrates recent years first, so radiologists have priors from day one.

How SOMATIQ does it

So where does that leave a centre owner? Measure your upload speed and your daily volume, insist on seeing the failure case and an old prior being fetched, and compare full costs rather than server prices. If you have more than one site or more than one reading location, the cloud usually pays for itself in the projects you no longer have to run.

Related reading

• RIS, PACS or RIS-PACS — what each system does and where the handoffs break.
• What is a zero-footprint DICOM viewer — client-side and server-side rendering, and why it matters on a slow line.

FAQ

What internet speed do I need for cloud PACS?

Work it out from your upload speed and your daily volume. A 600 MB thin-slice CT takes about four minutes at a real 20 Mbps upstream and under a minute at 100 Mbps. Busy CT and MR centres should plan for a business line with a stated upload speed and a second backup line from a different provider.

What happens to a cloud PACS when the internet goes down?

With a local edge gateway, modalities keep sending studies to it over the LAN, and the gateway uploads them when the line returns. Without one, you may not be able to store or view studies. Ask the vendor to demonstrate the failure case before you sign.

Is cloud PACS allowed under India's DPDP Act?

The Act does not prohibit cloud storage or, in general, storage outside India; it lets the government restrict transfers to notified countries. Your centre stays responsible for the data as the Data Fiduciary, so the contract with the vendor, the storage region and the security safeguards matter. Confirm the details with your counsel.

Is cloud PACS cheaper than on-premise?

Often in the first few years, and especially when you add centres. Over a long period it depends on your volume. Compare the cloud fee against the full on-premise cost: hardware refresh, UPS, AMC, backups, licences and staff time.