How to Modernize a Medical Imaging Platform Without Compromising Availability

A radiologist mid-read is a hard stop on your maintenance window. Not "please schedule around it" — a hard stop. And the old trick of deploying at 2 a.m. dies the moment your platform serves teleradiology across several time zones, because it's always working hours somewhere.

The reflex answer is more redundancy: another replica, blue-green deploys, chase another nine. I've watched teams spend quarters on that and still get paged, because the real availability risk on imaging platforms usually isn't in the deploy pipeline. It's in not knowing how the system is assembled — and in touching the wrong layer first.

After several years of working on radiology and imaging systems at Devico, my rule is: modernize from the outside in. The layers furthest from the reading path — infrastructure, backup and DR, monitoring, device fleets, analytics — absorb change safely, and that's where most of the actual risk lives. The viewing and reporting path changes last, incrementally, and only once you can observe it and restore it.

The stakes aren't abstract. In the 2025 Ponemon/Proofpoint study of 677 US healthcare IT and security professionals, 72% of organizations hit by common cyberattacks reported disruption to patient care, and the average cost of the most significant attack was $3.9 million. On an imaging platform, "disruption to patient care" means someone's diagnosis is late.

What "availability" means when a radiologist is mid-read

Before you modernize anything, get precise about what failure looks like. Imaging platforms fail in ways uptime checks are blind to.

Downtime, degraded reads, and lost studies are three different failures

They have different blast radii and different fixes:

• Downtime — the worklist won't load, nobody can read. Loud, obvious, and honestly the rarest of the three.
• Degraded reads — the worklist responds, but studies arrive late, images render slowly, prior exams take 30 seconds to hydrate. The radiologist works slower and trusts the system less. Your HTTP 200 monitoring says everything is fine.
• Lost or stalled studies — a routing device drops a series, a study sits in a queue nobody watches. This is the worst one, because nothing looks broken until a clinician asks where the scan went.

We saw the second failure mode play out at medneo, a radiology-as-a-service provider founded in 2012 that runs MRI and CT sites across Germany and the UK on a bespoke RIS. There was no outage to point at. Patient volumes grew, features kept shipping, and load times quietly degraded while regressions started to slip through. Availability eroded without a single incident ticket.

So the first modernization deliverable isn't a new architecture. It's a definition:

1. Split the platform into paths: ingest, storage, routing, viewing, reporting.
2. Give each path its own SLO.
3. Measure what clinicians feel — study-arrival latency, time-to-first-image, worklist refresh time — not HTTP status codes.

The honest limitation: per-path SLOs need instrumentation that legacy imaging stacks don't have. That's not a reason to skip it. That's your first project.

And the load is only going up. Signify Research counted 5.9 billion diagnostic imaging procedures globally in 2024 across CT, MRI, X-ray and ultrasound, growing at a projected 4.5% a year through 2029. Meanwhile the Harvey L. Neiman Health Policy Institute projects that imaging demand will grow up to 26.9% by 2055 against a 25.7% growth in radiologist supply — the shortage persists. Every radiologist-minute your platform wastes is getting more expensive, not less.

Map the system before you change it

Here's the unglamorous truth: on most legacy imaging estates, the biggest availability risk is that nobody can tell you how the thing is put together.

Our engagement with OpenRad started exactly there. OpenRad — formed in November 2022 from the merger of Biotronics3D and Visbion — runs a cloud radiology reporting platform with a teleradiology module, an enterprise worklist, and a thin-client architecture that streams pixels instead of transferring image data. The brief wasn't "rearchitect the platform." It was: enterprise-standard IT, minimum downtime, and critical-system availability in a disaster event.

What we found first was an infrastructure with no documentation and a recovery path nobody had ever tested. Until that's fixed, every change is a gamble — you can't reason about blast radius on a system you can't describe.

This isn't an imaging-specific quirk. In the Uptime Institute's 2025 outage analysis, 40% of organizations reported a major outage caused by human error in the past three years — and 85% of those incidents traced back to staff not following procedures, or the procedures themselves being broken. Undocumented systems don't just fail more; they fail in ways you can't rehearse.

So the sequence before any migration is:

1. Inventory the critical services. Every VM, every dependency, every "oh right, that box" that turns out to route half the studies.
2. Write the runbook. On OpenRad we kept documentation in Trilium Notes — the tool matters far less than the habit.
3. Test the restore. Not "backups ran green." Actually rebuild a critical service from backup and time it.

A team that can't rebuild a node deterministically has no availability story, whatever its deploy strategy diagram says.

The cost is real, though: discovery produces no user-visible change for weeks, which makes it the first thing stakeholders want to cut. Defend it anyway.

Layer one — infrastructure you can rebuild and restore

Once the map exists, the highest availability-per-effort work is the layer that touches zero clinical code: virtualization, provisioning, backup, monitoring.

On OpenRad, a two-person Devico team — one sysadmin, one BI developer, engaged since 2023 — standardized the estate on:

• Proxmox VE for virtualization, replacing an unoptimized, inconsistent setup
• Proxmox Backup Server for backups that get restore-tested, not just taken
• Ansible so a node is a playbook run, not an artisanal snowflake
• Prometheus + Grafana so degradation shows up on a graph before it shows up in a radiologist's complaint

Deliberately boring choices, and mostly open source — which also cut vendor licence cost, a real consideration when the platform runs on infrastructure margins.

Why backups-you-can-actually-restore leads the list: Veeam's 2024 Ransomware Trends report (1,200 organizations that had been breached) found victims were unable to recover 43% of their affected data, and one in three organizations that paid the ransom still couldn't recover. For a hospital-facing platform, "we lost 43% of the studies" is not an IT incident, it's a clinical one. Ransomware pressure on the sector isn't easing either — Comparitech tracked 445 ransomware attacksagainst healthcare providers in 2025 alone.

The monitoring half of this layer is what makes the per-path SLOs from earlier real. The shape of the check matters more than the stack — what you want is an alert on the clinical symptom:

Alert on the thing the radiologist feels, not on the box

• alert: StudyArrivalLatencyHigh

expr: histogram_quantile(0.95, rate(study_arrival_seconds_bucket[10m])) > 300

for: 15m

annotations:

summary: "p95 study arrival exceeds 5 minutes — reads are degrading"

(That's the shape, not OpenRad's config — the point is the metric: seconds from modality push to worklist-visible, not CPU on the ingest box.)

Be honest about what this layer is: infrastructure hardening, not application modernization. The result on OpenRad was a stable, enterprise-level infrastructure with documentation and a tested critical-service recovery plan. Nobody's reading experience changed — and that's exactly the point. You just removed the biggest class of catastrophic risk without touching the reading path.

Layer two — the transport edge: DICOM routing and device fleets

Engineers who haven't worked in imaging consistently forget this layer exists. A big share of an imaging service's reliability lives in hardware sitting at the hospital edge — devices that route, translate, compress and encrypt DICOM between modalities, trailers, and the platform.

Visbion is the sharpest example I've got. Their Image Cube is a DICOM 3.0 routing, translation, compression and encryption device used by NHS Breast Screening and Diagnostic Imaging Services — including managing mobile scanning trailers — and it's the UK's largest installed base of dedicated imaging routing hardware. When investment-funded growth pushed the fleet into the hundreds of devices, the constraint wasn't application code at all. It was fleet management.

The work — three Devico DevOps consultants, engaged since 2023 — was classic outside-in:

• Infrastructure automation for fleet deployment, so provisioning hundreds of edge boxes stops being manual toil
• DICOM compression and encryption optimization, because at fleet scale, transport efficiency is a reliability property
• A modular redesign using cloud components, so the architecture can absorb the next few hundred devices

The reported outcome: lower operational costs and a marked increase in the performance and reliability of the entire imaging service. I'll flag the limitation myself — those results are qualitative; no before/after numbers are published.

Two more constraints make this layer slower than it looks:

• Edge changes are gated by hospital network policy — you ship on the hospital's terms, not your sprint cadence.
• Some of it needs physical access. You can't ansible-playbook your way into a scanning trailer that's parked at a different site today.

But notice what this layer shares with layer one: massive availability upside, zero changes to the viewing and reporting code that a radiologist depends on mid-read.

Layer three — the application: refactor under load, don't rewrite under load

Eventually you do have to touch the reading path. The question is how.

Under live clinical load, my strong preference is refactoring, framework upgrades and pipeline work over structural rewrites. A rewrite concentrates regression risk, and on an imaging platform regression risk is availability risk — a bug in study routing isn't a bad release, it's a delayed diagnosis.

medneo is the case I keep coming back to. The RIS wasn't down; it was accreting features, and every release made it a little slower and a little more regression-prone. Over three years (2019–2022), a team of eight Devico engineers worked on it like this:

1. Code optimization on the hot paths — including hunting down and removing unnecessary database calls that had accumulated over years of feature work.
2. Framework upgrades — moving legacy frameworks to current, more efficient versions in increments, instead of a big-bang platform swap.
3. CI/CD introduction — so every change to the reading path ships through the same tested pipeline.

The published results are directional, not numeric, and I'll keep them that way: significantly reduced load times, fewer outages, reduced impact from new feature rollouts, and headroom to scale with patient growth without performance loss.

The CI/CD piece deserves emphasis. On a system where you can't afford regressions, the pipeline isn't developer comfort — it's an availability control, the mechanism that lets you change the most sensitive layer in small, reversible steps.

And the limitation, stated plainly: refactoring cannot raise an architectural ceiling. If the reading path's fundamental design can't carry your growth, incremental optimization is buying time, not solving the problem. More on that at the end.

Layer four — move analytics off the transactional path

The last layer is about adding capability without adding risk: reporting and decision support belong beside the transactional system, on separate stores — never as heavy queries against the database your worklist runs on.

The failure mode you're preventing is mundane: someone builds a management dashboard against the production database, a quarterly report kicks off mid-morning, and suddenly image load times spike for every reading radiologist. Analytics traffic and clinical traffic have opposite shapes, and they should never compete for the same I/O.

On OpenRad this was the second workstream: BI across multiple databases, built on Power BI, Azure and MS SQL Server, shipped as standardized dashboard templates that OpenRad's clients drive themselves — slicing their own data without anyone touching the clinical path to answer a question.

For the architectural pattern at its cleanest, look at GazeHealth — with a caveat I'll make explicit: it's a mental-healthcare analytics platform and EMR, not an imaging system, so take it as evidence for the separation pattern only. Six Devico full-stack developers and two AI data scientists have been building it since 2019 as two components — an EMR and an analytics platform — designed to work independently or together, with role- and company-based routing enforced through AWS Cognito so users never even get routes to data they can't access. Either half can evolve, degrade, or be rebuilt without taking the other down. That's the property you want between your imaging platform and its analytics.

The costs of decoupling, honestly:

• Your analytics are now behind the transactional truth by whatever your pipeline latency is.
• You own a second consistency model, and someone will eventually ask why the dashboard and the worklist disagree.

Both are acceptable prices for the guarantee that a heavy query can never slow a read.

What this sequencing costs you

Outside-in sequencing is not free, and pretending otherwise is how the plan dies in month three. Going in, know that:

• User-visible progress arrives slowly. Documentation, backup, monitoring and fleet work are invisible to clinicians for months. If leadership expects a new viewer by Q2, this ordering will read as stalling — set the expectation before you start.
• The legacy core lives longer. You are deliberately keeping the old reading path in production while you harden everything around it. That's a feature of the plan, but it means carrying legacy operational cost longer than a rewrite roadmap promises (and roughly as long as a rewrite roadmap actually delivers).
• It needs a whole-system owner. Without someone accountable for the full sequence, you end up with a permanently half-modernized estate: nice dashboards, solid backups, and a reading path nobody ever got to. These are multi-year engagements — medneo ran three years, OpenRad and Visbion have been running since 2023.

The ordering rule underneath all of it: you can't safely change what you can't restore or observe. So documentation, DR and monitoring come first. The transport edge and analytics come next, because they're separable from the reading path. The reading path itself comes last, and moves in small, pipeline-guarded steps.

And one test decides whether this playbook applies to you at all. Ask: can the current reading path, refactored but not rearchitected, carry the next two years of study volume? If yes, work outside-in and let the core evolve incrementally. If no, the infrastructure work is still worth doing — but be honest that it's buying time for a deeper change on the core, and start planning that change now, while your restores still work and your graphs still tell you the truth.