Moving Clinical Systems to the Cloud: Architecture Patterns That Actually Work

Cloud adoption in clinical imaging has moved past the argument stage. The useful question is no longer whether to use cloud, but which parts of the estate belong there and in what shape.

The systems that move well and the systems that resist have a consistent pattern, and it is not about criticality. It is about latency sensitivity and data gravity.

---

What Moves Well, and What Resists

Moves well:

• Long-term archive. Cold and archive tiers are close to an ideal cloud workload — large, append-mostly, rarely retrieved, and expensive to keep on-premises. This is where most hospitals start, and it is usually the right place to start.
• Disaster recovery targets. A cloud DR site avoids the cost of a second physical facility for capacity that sits idle by design.
• Analytics and reporting. Batch workloads with elastic demand and no interactive latency requirement.
• AI inference pipelines. Bursty GPU demand is exactly what elastic capacity is for.

Resists:

• The diagnostic read path. Radiologists open large studies and expect immediate response. Every millisecond of added round-trip is felt on every image. This can be made to work, but it needs deliberate design — caching close to the reader, aggressive prefetch, and a realistic latency budget.
• Modality ingestion. Scanners are on the hospital network and produce large bursts. Sending every study directly to cloud means the hospital's internet link becomes a clinical dependency.
• Systems with hard local dependencies. Anything tightly coupled to on-premises devices, licence dongles, or legacy integrations.

---

Three Hybrid Patterns

Very few hospitals run all-cloud or all-on-premises. These are the shapes that recur.

1. Cloud Archive, Local Cache

The most common and most defensible starting point. Recent studies stay on-premises in the cache tier; older studies migrate to cloud object storage. Prefetch pulls priors back before they are needed.

Works because it maps the cloud's strength (cheap durable capacity) to the workload that needs it and keeps the latency-sensitive path local.

Watch: retrieval latency and egress cost, both of which are driven by how often users cross the cache boundary. A cache window that is too short converts into a monthly bill increase and a user-experience complaint at the same time.

2. Cloud DR / Standby

Production stays on-premises; a warm or cold standby lives in cloud, kept current by replication.

Works because you pay for capacity that is genuinely idle only when idle, and avoid a second data centre.

Watch: the actual failover procedure. A DR site that has never been failed over to is a hypothesis. Test it, and time it — the measured RTO is the only one that counts.

3. Cloud-Native VNA With On-Premises Edge

The archive of record lives in cloud, with an on-premises edge appliance handling ingestion buffering and read caching.

Works because the edge absorbs the burst behaviour of modalities and shields the read path from internet variability.

Watch: what happens when the link drops. The edge must buffer ingestion for the full realistic outage duration and continue serving cached studies. Ask the vendor for the specific behaviour and the buffer sizing, and test it by actually disconnecting the link in a controlled window.

---

The Economics People Get Wrong

Cloud storage pricing looks simple and is not. Three line items surprise people in year two.

Egress. Storing data is cheap; getting it out is not. Every retrieval of an archived prior is billed. If your cache window is too short, you pay repeatedly for the same clinical behaviour. Model egress from measured retrieval rates, not from an assumption that archived data is rarely touched — in imaging, "rarely" still means thousands of retrievals a month.

Retrieval tiers and minimum durations. Deep archive classes are dramatically cheaper per terabyte and carry retrieval fees, retrieval delays measured in hours, and minimum storage durations. Data deleted or moved before the minimum period is still billed for it. For imaging with long legal retention this is usually fine — but only if the retention policy and the storage class are designed together.

Request charges at scale. Object storage bills per request. An archive containing many small objects — every instance stored individually rather than per-series or per-study — can generate request costs that rival storage costs. How your PACS or VNA maps studies onto objects is therefore a financial decision as well as a technical one.

The honest way to model this is to take a year of real retrieval logs and price them against the proposed architecture. Vendors will model it for you; running your own numbers alongside is worth the afternoon.

---

Latency Budgets for the Read Path

If any part of the diagnostic path crosses the internet, build a latency budget explicitly.

The components:

• Round-trip time to the cloud region
• Object retrieval time from the relevant storage class
• Decompression and rendering
• Local network and workstation time

The two that dominate are round-trip time and storage class retrieval. A deep-archive class with retrieval measured in hours can never serve an interactive read — which is fine, provided prefetch guarantees nothing lands there while it is still clinically active.

Practical guardrails:

• Choose the closest region, and confirm where data actually resides — including replicas
• Keep clinically active studies out of retrieval-delayed storage classes entirely
• Cache at the edge, and size the cache from comparison-study behaviour
• Measure real latency from a diagnostic workstation, not from the data centre

---

Before You Sign

Questions worth asking during procurement rather than during migration:

Data residency. Where is the primary copy? Where are replicas? Does that satisfy your jurisdiction's requirements for patient data, including any replicas created for durability?

Exit. How do you get 200 TB back out, how long does it take, and what does it cost? Get this in writing with a number. A migration in is always easier than a migration out, and the asymmetry is where lock-in lives.

Format. Is your data stored as standard DICOM objects retrievable through standard interfaces, or in a proprietary container? This single answer determines whether "exit" means a data transfer or a migration project.

Contractual availability. What is the SLA, what is the remedy, and does the remedy bear any relationship to the clinical cost of an outage? Service credits do not restore a reading day.

Shared responsibility. Precisely which security controls are the provider's and which are yours? Cloud storage that is misconfigured to be publicly accessible remains your breach.

Sub-processors. Who else touches the data, and how are they bound?

---

Related Reading

• Healthcare Storage Tiering — the tiering model this builds on
• Backup and Disaster Recovery for Clinical Systems — where cloud DR fits
• PACS Migration: The 5 Data Quality Failures That Derail Projects — moving the data is its own project

Planning a migration and need the data assessed first? Send us the details — we build migration analysis and reconciliation tooling against real archive exports.