“Cloud PACS” shows up on almost every OEM and VAR vendor comparison sheet, and it does more hiding than explaining. It is even possible to see it used two ways on one page. EBM’s own homepage calls EBM mAIn PACS® “Cloud-native” in one section, then benchmarks it against a separate column headed “vs Cloud PACS” a few sections later. Both usages are legitimate, because they describe different things.
One is an architecture description. The other is shorthand for a specific deployment model that keeps almost everything off-site. Neither changes what a PACS actually does, and both change where it does it. For a product team choosing a platform to build or embed, that difference decides the failure mode a partner signs up for the day one of its customers’ sites loses its connection.
What “Cloud PACS” Actually Describes
Three architectures get called “cloud PACS” in vendor conversations, and only one of them is really a single model.
Fully cloud-hosted. Acquisition still happens at the modality, but the study is pushed straight to a remote data center and the site keeps no meaningful local copy. Reading, storage, and often the reading worklist all live on infrastructure the vendor operates, and the site connects through a thin client, typically a browser. The authoritative copy is off-site from the moment the modality finishes the transfer. This is what most people mean when they say “cloud PACS” without qualification.
Hybrid. A local server or appliance caches recent, actively read studies for fast retrieval, while a cloud archive holds the long-term record and handles remote access. The authoritative copy still ends up in the cloud, but a second, temporary copy sits on local hardware for as long as a study counts as recent. That retention window is a configuration choice rather than a property of the architecture, so ask a vendor to state its own rather than assuming an industry norm. The site gets local-speed access to what it is working on today and offloads everything older to infrastructure it does not maintain itself.
Edge-to-cloud. Acquisition, storage, and the reading worklist run on hardware physically present at the site, so the local copy is the primary copy. A cloud layer sits on top for remote access and multi-site visibility, and the site does not need that layer to keep operating. What any given vendor’s cloud layer actually covers, backup and disaster recovery included, varies by vendor and is a question to put to each one directly.
EBM Fabric™ is built on this model, providing the edge-to-cloud architecture that partners ship under their own brand. EBM mAIn PACS® runs the core workflow at the edge through EPS Pi, with the cloud layer on top of that rather than in place of it. EBM’s own integrations page describes EPS Pi as edge storage with local backup. That is the architecture stating its priority plainly: the archive that matters most on a Tuesday afternoon is the one already in the building.
What Happens When Connectivity Drops
All three architectures behave differently the moment the network goes away, and that is usually the fact that decides which one fits a given site. It is also the easiest thing to test in a vendor conversation.
A fully cloud-hosted deployment stops working. Not “works with reduced features,” stops. The modalities themselves keep scanning, since a scanner’s console typically holds studies locally until a destination accepts them. But there is nothing local to acquire into and nothing local to read from, so PACS workflow, transfer, the reading worklist, and reading are all down until the connection returns.
EBM frames this plainly in its own comparison against cloud PACS. Its homepage lists “Requires reliable internet”, “Limited offline capability” and “No edge processing” under a column headed “vs Cloud PACS”. That is EBM’s own stated position, not a neutral third-party rating. It is also a fair structural description of what keeping everything off-site implies: remove the network, remove the system.
A hybrid deployment survives a disconnection for reading, at least for whatever is already in the local cache. A radiologist can keep reading anything the cache still holds. Acquisition is the harder question. A new study has to be acquired and queued locally during the outage, then synced once connectivity returns.
Whether that works depends entirely on whether the vendor built the local cache to accept new writes offline, not just serve cached reads. Ask that specifically. “Hybrid” describes where old data sits, and it does not by itself answer whether new data can still come in during an outage.
An edge-to-cloud deployment keeps acquiring, storing, and reading through the outage, because none of those three operations depend on the network in the first place. The cloud connection resumes syncing and remote access once it is back. For a mobile clinic, a rural site, or any location where connectivity is a variable rather than a given, that is the operational difference the other two models do not cover.
Bandwidth and Study Size on Retrieval
Even with a stable connection, the architecture still shapes how a study feels to open. A modern CT or MRI study is not a single image but a stack of cross-sectional images, and faster volume imaging keeps pushing that stack larger. Retrieving that volume over a wide area connection is a different problem than retrieving it over a local network, not a smaller version of the same problem.
A peer-reviewed study of PACS network performance in the Journal of Digital Imaging measured the gap directly at one radiology network in 2010. Initial testing showed wide area network retrieval running roughly thirty times slower than local area network retrieval. The researchers traced that gap to round-trip latency and protocol overhead rather than raw bandwidth alone. Sixteen months of compression, buffer tuning, and dedicated WAN acceleration brought the wide area figure down to about 1.5 times slower than the local network.
That ratio belongs to one deployment and one era, since compression, streaming, and transfer protocols have all improved since. The round-trip-latency arithmetic underneath it is still the physics any cloud PACS architecture has to engineer around. The structural gap between local and wide-area retrieval has narrowed rather than disappeared.
A fully cloud-hosted architecture retrieves every study over a wide area link by definition, so it needs real engineering investment in compression, caching, and connection tuning. A hybrid model sidesteps the problem for anything already in the local cache and only pays the wide area cost for older or first-time pulls. An edge-to-cloud model mostly avoids it during normal operation, since the study a reader needs today is already local. The bandwidth cost shows up on sync and on remote access rather than on the primary read.
The Cost Shape of Each Model
None of the three architectures reduces to a single number. A serious comparison has to look at the shape of the spend: what is capital, what is recurring, and what is triggered by use.
Fully cloud-hosted. Cost concentrates into an ongoing subscription or usage-based fee, tied to storage volume and often to egress, the cost of pulling data back out. There is little or no on-site hardware to capitalize, which lowers the up-front bar. The ongoing side scales with usage in a way that is harder to forecast at signing.
Hybrid. Cost splits between local hardware, a real capital line item even if a modest one, and a cloud storage and access fee for the archive. It sits in the middle on both sides: less local hardware than a fully edge-based deployment, less pure variable cost than fully cloud-hosted.
Edge-to-cloud. More of the cost goes into local hardware up front and less into ongoing per-study or egress fees. The primary workflow does not depend on pulling data back out of the cloud to function. Total cost of ownership also depends on what happens at the far end of a contract, not just during it. Egress and exit pricing vary widely by vendor and are worth pricing out before signing, whichever architecture a product team lands on.
Compliance carries its own cost shape, and it does not track cleanly with any single architecture. Any model that stores or transmits protected health information through a third-party cloud provider makes that provider a business associate under HIPAA. The U.S. Department of Health and Human Services states that directly for any cloud service provider that creates, receives, maintains, or transmits electronic protected health information on a covered entity’s behalf.
That obligation applies to a fully cloud-hosted deployment, a hybrid archive, and an edge appliance that syncs to the cloud alike. What changes across the three models is how much of the underlying risk analysis a site’s own IT staff can realistically do without outside help.
Deployment and Update Responsibility
Who installs the system and who keeps it current is the last variable, and it tracks closely with where the software actually runs.
Fully cloud-hosted. Installation and updates sit almost entirely with the vendor. Updates roll out server-side, the site has little to patch, and deployment is mostly account provisioning and network configuration rather than hardware setup.
Hybrid. Responsibility splits. The cloud side updates on the vendor’s schedule, the same as a fully cloud-hosted system. The local cache appliance still needs firmware and software updates applied on-site or pushed remotely, and someone has to own that half of the maintenance calendar.
Edge-to-cloud. More of the day-to-day setup sits on hardware physically at the site, so the initial install has a real, hands-on component. EBM states a typical deployment time of about a day for EPS Pi. That is the vendor’s own stated typical figure for its own appliance, not a guaranteed timeline, and not a number that generalizes to every edge deployment on the market.
Remote update capability is worth confirming on any edge appliance, because running at the edge does not have to mean sending someone to the site every time a patch ships. Ask how updates reach the box, and who applies them.
Choosing by Site, Not by Vendor Label
The label on a vendor’s homepage is a weaker signal than the actual conditions at the sites a partner is deploying into. A few questions settle it faster than the label does:
- How reliable is connectivity at the sites in question: a hospital campus with redundant fiber, or a mobile clinic and a handful of rural locations?
- Do acquisition and first-line reading need to survive an outage, or is occasional downtime an acceptable tradeoff for lower up-front infrastructure?
- What is the typical study size and volume per site, and how much of that has to move over a wide area connection rather than staying local?
- Who is actually available on-site to manage local hardware, if the chosen model has any?
A partner selling into large, well-connected hospital systems can reasonably prioritize a fully cloud-hosted or hybrid model, where centralized management outweighs the offline risk. A partner selling into mobile clinics, rural facilities, or any site where connectivity is not guaranteed is choosing a fundamentally different risk profile if it picks the same architecture by default.
EBM Fabric™ pairs an edge-first architecture with cloud connectivity rather than the reverse, which is the profile that fits the second case. The two models also combine. EBM’s homepage describes OmniPACS, a cloud-based, AI-powered PACS, as a partner and reseller that brings EBM’s edge-to-cloud imaging and mobile diagnostics to its cloud platform and customers. A partner does not have to pick only one, as long as the underlying architecture lets it run both.
What This Means for Your Evaluation
Each of the three architectures carries a different failure, and a product team is picking which one the sites it sells into can absorb. A fully cloud-hosted site goes dark until the link returns. A hybrid site reads from a cache that may or may not take new studies mid-outage. An edge site carries local hardware and a hands-on install at every location.
Pick against the wrong assumption and the bill arrives twice. The first outage sends it, at whichever site had the least reliable connection. The end of the contract sends it again, when egress and exit pricing decide what moving the archive costs.