Cloud PACS Architecture: Build, Buy, or Extend for Medical Imaging Platforms
A cloud PACS is a Picture Archiving and Communication System that stores, manages, and delivers medical images from cloud infrastructure rather than on-premise servers, using the DICOM standard to encode images and DICOMweb services to move them over the web. It replaces the storage racks and dedicated workstations of a traditional PACS with object storage and browser-based viewers.
The architectural decision behind a cloud PACS is not simply about cloud versus on-premise. The question is whether to build a platform, buy an existing one, or extend a current PACS into the cloud, and the right answer depends on control, time to value, and data portability, which is often the deciding factor in cloud PACS migrations. This guide covers the layers of a cloud PACS, the standards that hold it together, the build-buy-extend decision, and the lock-in trap that a good architecture avoids.
Atta Systems builds medical device software under its own ISO 13485-certified quality management system and has developed the Medicai cloud imaging platform, which uses a cloud-native PACS and vendor-neutral archive architecture based on the DICOM standard.
What a cloud PACS is, and how it differs from a traditional PACS
A cloud PACS performs the same core job as a traditional PACS, storing and distributing medical images and orchestrating the radiology workflow, but it runs on cloud infrastructure and is accessed through a web browser rather than dedicated workstations. The functional difference for a clinician is a zero-footprint viewer that opens on any device. The architectural difference for an engineering team is much larger.
The main differences between a cloud PACS and a traditional on-premise PACS:
- Storage. A traditional PACS uses on-premise disk arrays with fixed capacity, while a cloud PACS uses elastic object storage that scales with the archive and is replicated across locations for redundancy.
- Access. A traditional PACS relies on dedicated diagnostic workstations, while a cloud PACS delivers a zero-footprint viewer in the browser, reachable from any device and any site.
- Cost shape. A traditional PACS front-loads capital expenditure on hardware and licenses, while a cloud PACS shifts to operating expenditure that scales with usage and storage.
- Maintenance. A traditional PACS requires the institution to run and patch its own infrastructure, while a cloud PACS moves that burden to the platform, including backups and disaster recovery.
None of this changes the standards underneath. A cloud PACS still speaks DICOM, still integrates with radiology and hospital information systems, and still has to move images to and from modalities designed for an on-premise world. The architecture is what reconciles the cloud model with those fixed standards.
The three layers of a cloud PACS architecture
A cloud PACS architecture is divided into three layers that can be designed, scaled, and replaced independently: the application layer that clinicians use, the integration layer that connects to standards and other systems, and the storage layer that stores the images. Keeping these layers distinct is what gives a cloud PACS its flexibility and, importantly, its data portability.
The application layer
The application layer is what clinicians interact with: the zero-footprint viewer, the worklist, hanging protocols, measurement and annotation tools, and reporting. It runs in the browser, where user experience and diagnostic-grade rendering matter. Because it is separated from storage, the viewer can be upgraded or replaced without touching the archive.
The integration layer
The integration layer connects the cloud PACS to the surrounding standards and systems. It exposes DICOMweb services (STOW-RS to store, QIDO-RS to query, and WADO-RS to retrieve) for web-based image exchange, supports classic DICOM networking (C-STORE, C-FIND, C-MOVE) for modalities and legacy systems, and uses HL7 (Health Level Seven) and FHIR (Fast Healthcare Interoperability Resources) to link images to patient demographics and clinical context. IHE (Integrating the Healthcare Enterprise) profiles such as Cross-Enterprise Document Sharing for Imaging (XDS-I.b) govern how images are shared across enterprises.
The hardest part of this layer in practice is connecting modalities and on-premise systems that were built before the cloud. The Medicai platform handles this with its DICOM Gateway: a lightweight component installed at each site that receives studies from local modalities over standard DICOM and transmits them to the cloud archive over a standard HTTPS connection, in minutes and without VPNs or site-to-site networking. Naming it makes the point concrete: bridging the on-premise and cloud worlds is a specific engineering problem with a specific solution, not an abstraction.
The storage layer
The storage layer holds the images, and in a well-designed cloud PACS it is a vendor-neutral archive (VNA) that stores studies in standard DICOM format on object storage such as Amazon S3. Storing in standard DICOM, independent of the application layer, allows an institution to retain its data even if it changes its viewer or reporting software. This separation is the single most important architectural decision in the whole system.
The standards that hold a cloud PACS together
A cloud PACS depends on a small set of interoperability standards, and getting them right is what separates a real imaging platform from a file store with a viewer. Each standard performs a specific job, and a platform that skips one creates an integration gap that later surfaces as a migration or interoperability problem.
| Standard | What it does | Why it matters in the cloud |
| DICOM | Digital Imaging and Communications in Medicine: the standard for encoding, storing, and exchanging medical images and their metadata. | The foundation. Storing data in standard DICOM makes it portable rather than locked to a vendor. |
| DICOMweb | The web-services layer of DICOM: STOW-RS (store), QIDO-RS (query), and WADO-RS (retrieve). | Lets images move over standard web protocols, which is what makes browser-based viewing and cloud access work. |
| Classic DICOM networking | The traditional message services: C-STORE, C-FIND, and C-MOVE. | Still required to connect modalities and legacy on-premise systems that predate DICOMweb. |
| HL7 and FHIR | Health Level Seven and Fast Healthcare Interoperability Resources: standards for exchanging clinical and administrative data. | Link images to the right patient and clinical context by connecting the PACS to the RIS and EHR. |
| IHE profiles | Integrating the Healthcare Enterprise profiles, notably Cross-Enterprise Document Sharing for Imaging (XDS-I.b), for cross-enterprise image sharing. | Govern how images are shared between institutions; Connectathon results show which profiles a platform has actually tested. |
Two supporting systems appear throughout: the RIS (Radiology Information System), which manages orders, scheduling, and reports, and the EHR (Electronic Health Record), which holds the broader clinical record. A cloud PACS is not an island; it is a node in an imaging ecosystem, and the integration layer connects it.
Build, buy, or extend: choosing the cloud PACS path
A cloud PACS can be approached three ways: building a custom platform, buying an existing cloud PACS product, or extending a current on-premise PACS into the cloud. The right path depends on how much the imaging workflow differs from what products offer, how much control the organization needs over the roadmap, and how much lock-in risk it can accept.
| Factor | Build custom | Buy a cloud PACS | Extend an existing PACS |
| Time to value | Longest; the platform is built to spec | Shortest; the product exists | Moderate; a cloud layer is added to what exists |
| Control over roadmap | Full; every workflow and integration built to need | Limited to the product’s roadmap | Bound by the existing PACS’s capabilities |
| Fit to workflow | Exact; designed for the specific imaging model | Good for standard workflows, weaker for unusual ones | Constrained by the legacy design |
| Lock-in risk | Low if built on standard DICOM and a VNA | Depends entirely on the product’s data model | Often high; legacy schemas are hard to exit |
| Best for | Differentiated imaging products and platforms | Standard radiology needs on a proven product | Adding cloud access to a working on-premise PACS |
For a company building a medical imaging product, rather than a hospital buying one, the build path is often the right one, because the imaging workflow is the product and cannot be outsourced to someone else’s roadmap. The key is to build on standard DICOM and a vendor-neutral archive from the start, so the platform never becomes the kind of locked system it was meant to replace.
The data-portability trap that decides migrations
Data portability is frequently the deciding factor in cloud PACS migrations, more so than features or price: whether the images are stored in standard DICOM that the institution can extract, or in a proprietary format tied to the vendor’s database schema. A platform that locks data in a proprietary schema turns any future migration into a costly, negotiated extraction.
How to avoid the trap when designing or selecting a cloud PACS:
- Store in standard DICOM, not a proprietary schema. Images should be retrievable through standard DICOM C-MOVE or DICOMweb WADO-RS, not only through the vendor’s own application. This is what keeps the archive portable.
- Separate the storage layer from the application layer. A vendor-neutral archive that is independent of the viewer means the institution keeps its data even if it changes viewing or reporting software.
- Verify the data export path before committing. Confirm the export mechanism and the contractual data-export terms up front, because the difference between a portable and a locked platform is measured in months of engineering time and large migration costs at exit.
- Check IHE Connectathon results. A platform that has tested its interoperability profiles at an IHE Connectathon has demonstrated the cross-system behavior on which portability depends, rather than merely claiming it.
Atta Systems built the Medicai cloud imaging platform on a separate vendor-neutral archive and DICOM-standard storage model, so data portability is designed in rather than discovered at migration. That model runs at scale: Medicai reports more than 1 million studies transacted or processed per year, more than 1.7 million studies in storage, and more than 50 million API transactions per year. Where such a platform includes AI — for example, image segmentation — that AI may be regulated as medical device software depending on its intended use, which can bring the EU AI Act obligations into the design from the start.
FAQ about cloud PACS architecture
A cloud PACS is a Picture Archiving and Communication System that stores and delivers medical images from cloud infrastructure rather than on-premise servers. It uses the DICOM standard to encode images and DICOMweb services to move them over the web, and it is accessed through a zero-footprint browser viewer rather than dedicated workstations. The clinical function is the same as a traditional PACS; the infrastructure and access model differ.
A PACS (Picture Archiving and Communication System) manages the active imaging workflow, including acquisition, viewing, worklist, and reporting, whereas a VNA (Vendor Neutral Archive) is a storage layer that stores images in the standard DICOM format, independent of any single vendor. In a well-designed cloud PACS, the two are separated, so the archive persists even if the viewing or reporting software changes. That separation is what protects data portability.
A cloud PACS needs DICOM for image encoding; DICOMweb (STOW-RS, QIDO-RS, WADO-RS) for web-based exchange; classic DICOM networking (C-STORE, C-FIND, C-MOVE) for modalities and legacy systems; HL7 and FHIR to link images to patient and clinical data; and IHE profiles such as XDS-I.b for cross-enterprise sharing. A platform missing any of these creates an integration gap that surfaces later as an interoperability or migration problem.
Build a cloud PACS when the imaging workflow is the product and requires full control, buy one when needs are standard and speed matters, and extend an existing PACS when the goal is to add cloud access to a working on-premise system. Building gives the most control and, if done on standard DICOM and a vendor-neutral archive, the least lock-in. Buying is fastest but ties the roadmap to the product, and extending is bound by the legacy design.
Avoid cloud PACS lock-in by storing images in standard DICOM format, retrievable through C-MOVE or DICOMweb WADO-RS; separating the vendor-neutral archive from the application layer; verifying the data export path and contractual export terms before committing; and checking IHE Connectathon results. The core principle is that the institution, not the vendor, should own the data in a standard format it can extract at any time.
Atta Systems builds cloud imaging platforms and medical device software under its own ISO 13485-certified quality management system, and built the Medicai cloud PACS and vendor-neutral archive, designing DICOM-standard storage and data portability in from the first version.
Atta Systems focuses on custom medical imaging and device software, where standards compliance and data portability are built into the architecture, rather than on off-the-shelf PACS resale or general file storage products without medical imaging requirements.
Related Articles
