When your cloud PACS goes down

Failure domains

“The cloud is down” can mean three different things

Continuity planning gets clearer when the team separates infrastructure, platform, and connectivity failures. A cloud region or data-center service may be impaired. The PACS vendor’s application, identity provider, database, or deployment may fail even though the underlying cloud is operating. Or the customer site may lose its route to an otherwise healthy service.

Those causes affect escalation and recovery differently, but the clinical response cannot depend on diagnosing the provider first. If a radiologist cannot open the current exam and communicate a result, the local workflow needs to take over. The fallback should therefore have few dependencies on the same identity, network, storage, and application paths as the primary system.

Minimum viable reading environment

Keep the clinical essentials on premises

A downtime system does not have to reproduce every PACS feature. It does need the pieces that let the department finish a safe preliminary interpretation: the correct patient and exam, enough images to read, an appropriate viewer, a place to dictate and edit, a controlled signing state, and a delivery route the ordering team can receive.

• Images: pre-cache likely downtime studies locally rather than waiting to retrieve them after connectivity is lost.
• Work state: show which exams are ready, in progress, signed, or waiting for delivery.
• Reporting: provide local speech transcription, editing, signing, corrections, and addenda.
• Concurrency: lock an active exam so two radiologists do not unknowingly interpret the same study.
• Delivery: support a pathway that does not depend on the unavailable PACS reporting stack.

The scope should be explicit. A downtime preliminary report may have different distribution, reconciliation, and final-signature rules than the normal workflow. Clinical leadership, IT, compliance, and the affected downstream teams should agree on those rules before activation.

Preparation

A fallback cannot begin by fetching everything from the failed system

Local availability has to be created while the normal environment is healthy. RadRead can pre-cache studies to an on-premises location so images are already near the reading workflow. The organization determines which facilities, exam types, and timing windows merit local coverage, balancing continuity needs with storage and retention policies.

Readiness also means testing the full path—not merely confirming that a service is running. A useful exercise verifies that a newly acquired case appears locally, the images open, dictation works, a preliminary report can be signed, and a recipient receives it through the designated downtime channel. Staff should know how activation is declared and where the alternate worklist lives.

Regular exercises expose quiet dependencies: a local workstation that still authenticates against the cloud, a fax account whose credentials expired, or a routing rule that excludes a recently added site. Treat the downtime workflow like any other clinical interface, with ownership, monitoring, and scheduled validation.

Communication

Reading is not continuity until the result reaches someone

During an outage, the report destination may be available even when PACS is not. RadRead can produce and send an HL7 ORU preliminary result to an accessible downstream interface. Where an HL7 route is unavailable or a recipient requires a document, a rendered report can be delivered by configured fax. Delivery state, retries, and errors need to be visible so staff know whether a signed interpretation actually left the downtime system.

Urgent findings still require the organization’s established critical-results process. Automation can deliver the report artifact, but it does not replace closed-loop communication, escalation, or documentation policies. The downtime design should make those human responsibilities easier to see rather than hiding them behind a green “sent” status.

Return to service

Plan the handoff back to the primary PACS

Recovery is a workflow of its own. The team must identify every exam read during downtime, every preliminary report delivered, every failed delivery, and every correction or addendum. Those records provide the reconciliation list for the primary environment. Without it, an apparently successful outage response can create missing reports or duplicate work after service returns.

Define who decides the primary system is stable, whether new cases immediately switch back, and how in-progress downtime cases finish. Preserve an audit trail of report versions and delivery attempts. Then hold a short after-action review: which dependencies failed, how quickly the fallback became usable, and what should be cached or tested differently next time?

RadFuzion module

RadRead is a focused on-prem downtime prelim PACS

RadRead is built for the gap left when a cloud PACS vendor does not provide a local fallback. It combines locally available studies with a browser-based preliminary reading workflow, speech transcription, controlled signing, addenda and corrections, exam locks, and delivery through HL7 ORU or configured fax.

It is intentionally not a claim that downtime becomes invisible. The operational advantage is that the team enters an interruption with a known, tested path instead of inventing one while images and reports are waiting.