Cloud vs. On-Prem Veterinary PACS: A Practical Decision Framework

Veterinary practices often compare PACS platforms by looking at viewer tools, storage capacity, integrations, support, and price. Those details matter, but they do not fully explain how the system will perform when the internet is unavailable, local hardware fails, or the practice expands to another location.

PACS is also more than a single archive. It can involve imaging modalities, worklists, storage services, viewers, reporting tools, patient systems, and network connections. The effect of an outage therefore depends on where each part of the workflow operates and what fallback options are built into the system. NIST

Key facts

• Keystone uses a hybrid local-plus-cloud architecture. A local server or workstation supports image acquisition, storage, and viewing, while studies are also synchronized to Asteris’s cloud infrastructure for off-site archival and remote access. Source
• Asteris states that Keystone uses patented lossless compression and transfer technology for DICOM studies. Encryption and hashing are also used to support security and data integrity. Public Asteris documentation does not specifically state that an integrity check confirms that every individual transfer “arrives complete,” so that wording should not be used without further technical documentation. Source
• For most Keystone customers, off-site data is retained for seven years, and Asteris states that this period can be extended. Whether seven years satisfies a practice’s legal or professional retention requirements depends on its jurisdiction and policies. Source
• Keystone is designed to work with non-proprietary hardware and standard DICOM modalities rather than tying the practice to one imaging equipment manufacturer. Compatibility and server requirements should still be confirmed for each installation. Source
• Keystone uses a pay-as-you-go model and does not limit the number of concurrent users. However, Asteris states that pricing may depend on factors including the number of locations and modalities. Adding staff may not create another concurrent-seat charge, but adding a location can still affect the overall price. Source

What can be affected in a cloud-dependent veterinary PACS?

The term “cloud PACS” covers a range of architectures. Some systems operate almost entirely through remote infrastructure, while others include a local gateway, acquisition queue, cache, or limited offline functionality. It is therefore inaccurate to assume that every cloud PACS behaves the same way during an outage.

In a fully cloud-dependent setup, functions that require access to a remote server may become unavailable when the connection drops. This could affect study uploads, access to prior images, cloud-hosted viewers, worklists, patient matching, reporting, or confirmation that a study has reached its intended archive.

The modality may still be able to capture images locally, depending on its configuration. The question is what happens next. Can the study be reviewed on a local workstation? Is it held safely in a queue? Will it upload automatically when the connection returns? Can the team tell whether the transfer succeeded?

DICOM includes separate services for storing studies, retrieving them, obtaining modality worklists, and confirming permanent storage. A vendor should be able to explain which of these functions remain available during an outage and what mechanism is used to confirm that a study has been safely archived. DICOM Standard

Connectivity can also affect performance without failing completely. Large CT, MRI, or radiographic studies may take longer to upload or retrieve when several workstations and devices are using the same connection. The practical effect depends on study size, available bandwidth, local caching, compression, and how much of the workflow is processed remotely.

The accurate conclusion is not that every cloud PACS stops working when the internet drops. It is that a cloud-dependent workflow needs a clearly documented plan for limited or lost connectivity.

Questions to ask about cloud downtime

• Can new studies still be acquired during an outage?
• Can recently acquired studies be reviewed locally?
• Can prior studies be accessed without a live connection?
• Are studies held in a secure local queue until connectivity returns?
• Does synchronization restart automatically?
• How does the system confirm that a study has been permanently stored?
• Which functions remain unavailable until the connection returns?

What can fail in an on-premises veterinary PACS?

An on-premises PACS keeps its primary archive and workflow components within the practice. When the PACS server, viewer, modalities, and local network are functioning, the practice may be able to continue acquiring and reviewing images without an external internet connection.

That reduces internet dependency, but it does not remove infrastructure risk. The practice still depends on its local server, storage drives, network equipment, power supply, database, and workstations.

A properly designed on-premises system does not necessarily have a single point of failure. It may include redundant drives, secondary servers, power protection, replication, and off-site backups. The risk arises when the local archive is the only recoverable copy or when backups have not been tested.

RAID or mirrored drives can help protect against certain drive failures, but they do not protect the archive from every event. Fire, flooding, theft, ransomware, accidental deletion, database corruption, or damage to the building can affect the primary system and any backup stored beside it.

CISA recommends using a combination of on-site and remote backups to protect against hardware failure and physical damage. Backups should also be secured and tested so the practice knows that data can actually be restored. CISA

Managing an on-premises archive responsibly can therefore require:

• Redundant storage
• Power protection
• Hardware monitoring and replacement planning
• Secure off-site backups
• Documented recovery procedures
• Regular restore testing
• Software patching and security management
• Access to qualified technical support

An on-premises PACS can be reliable, but that reliability depends on how the infrastructure and recovery plan are implemented.

How do cloud and on-premises models affect multi-site practices?

Multi-site practices add another layer to the decision because every location needs access to imaging data without creating unnecessary operational dependencies.

A cloud platform can centralize access across multiple clinics, but functions hosted remotely will still depend on connectivity at each site. An outage at one clinic may affect that location without affecting the others. A broader cloud service or data-centre outage could affect several locations, depending on the provider’s architecture and redundancy.

An on-premises model can also support multiple sites, but it usually requires additional planning. The practice may install separate infrastructure at each clinic, connect locations to a central server through a WAN or VPN, replicate archives, or use another form of shared repository.

These approaches are possible, but each introduces costs and dependencies. Separate servers can create fragmented archives if they are not synchronized. Routing everything to one central location makes remote clinics dependent on the connection to that server. Replication and failover can solve some of those problems, but they require configuration and management.

A hybrid architecture can provide another option. Each clinic may operate through local infrastructure for acquisition and immediate review, while studies are also synchronized to an off-site archive for remote access and recovery.

This can reduce the effect of an internet outage on local work while still allowing studies to be accessed across the organization when connectivity is available.

Hybrid architecture does not make the system immune to failure. A local server can still fail, a cloud service can still become unavailable, and synchronization can still be delayed. Its advantage is that the practice is not relying entirely on one server, one building, or one live connection.

Hybrid architecture does not make failure impossible. It reduces the number of situations in which one failed connection, server, or location can interrupt the entire imaging workflow.

How should a practice choose between cloud, on-premises, and hybrid?

The categories below are a starting point rather than a universal rule.

Retention, cybersecurity, uptime, and legal compliance should not be assumed from the words “cloud,” “on-premises,” or “hybrid.” They depend on the vendor’s implementation, service agreement, recovery procedures, and the practice’s own responsibilities.

What questions should a veterinary PACS vendor answer?

Architecture claims should be supported by specific answers rather than broad labels.

1. Offline operation: What exactly happens when the internet connection drops? Can the team still acquire new studies, open the viewer, review prior images, match studies to patients, and produce reports?
2. Local hardware failure: What happens if the local PACS server fails? Is there a secondary server, a local failover option, or a documented process for restoring the archive?
3. Off-site archival: Are studies archived automatically? Where are they stored? How long are they retained? Can the retention period be changed?
4. Transfer and storage confirmation: How does the system verify that a complete, usable study has reached the off-site archive? Does it use hashing, checksums, DICOM Storage Commitment, archive reports, or another verification process?
5. Recovery: How quickly can the practice regain access after a server failure? How long would full restoration take for the practice’s current archive size?
6. Multi-site access: How does a veterinarian at one clinic access a study acquired at another? Does the originating location need to be online?
7. Hardware compatibility: Does the vendor require proprietary servers or imaging equipment? Which DICOM modalities and viewers are supported?
8. Pricing: Is pricing based on studies, storage, modalities, locations, users, or concurrent sessions?
9. Data ownership and portability: Can the practice export its complete archive in standard DICOM format? Are there migration or data-egress charges?
10. Security: How are studies encrypted in transit and at rest? Are multifactor authentication, role-based permissions, activity logs, security updates, and incident-response procedures available?

The answers to these questions are more useful than the architecture label on its own.

How Keystone approaches the cloud vs. on-premises decision

Keystone is built around a hybrid local-plus-cloud model. A local Keystone server or workstation supports image acquisition, storage, and viewing within the practice. Studies are also archived through Asteris’s cloud infrastructure for remote access, sharing, and recovery. Source

Asteris states that Keystone uses encryption, hashing, patented lossless compression algorithms, and patented transfer protocols to protect data and move studies off-site. It also states that diagnostic image data is not degraded for storage optimisation. Source

For most customers, studies are retained off-site for seven years, with longer retention available. Keystone is designed to support standard DICOM modalities and non-proprietary hardware, and Asteris does not impose concurrent user limits. Pricing is tailored to the practice and may account for its locations, modalities, and required features. Source

The value of this architecture is not that failures become impossible. It is that a temporary internet outage does not have to remove local access to newly acquired studies, and a local hardware problem does not have to leave the practice with its only copy of the archive in the affected building.

That is the standard worth applying to any PACS evaluation: what remains available during an outage, how the archive is recovered after a local failure, and what the system will cost as the practice adds users, modalities, or locations.

To evaluate Keystone on those terms, ask to see the offline workflow, the archival process, the recovery plan, and a clear explanation of how pricing changes as the practice grows.

FAQ