The Week an Imaging Department Stopped Firefighting: What Real PACS Support Changes

A composite case study of an imaging department under strain — and exactly what changed in 90 days once real PACS support took over monitoring, DICOM and vendors.

At 06:40 on a Tuesday, the CT at the north site stopped sending. Nobody found out for two hours. This is a composite story — assembled from patterns RAD365 sees repeatedly across hospital and imaging-centre assessments, with details changed — about what PACS support actually is once you strip away the brochure language, and what measurably changes in an imaging department that has been quietly firefighting for years. If you want the definitional version instead, our guide to managed PACS services covers the model in structured form. This one follows a department.

A note on scope. RAD365 operates radiology infrastructure — uptime, DICOM connectivity, integrations, migrations, storage and vendor management. We do not read or interpret studies, and nothing below concerns clinical interpretation.

Monday: an environment that looks fine on paper

Three sites. One primary PACS, inherited from an acquisition, plus a second archive that was supposed to have been decommissioned in 2023 and never was. Fourteen modalities across CT, MR, DR, ultrasound and mammography. One PACS administrator, twelve years in post, universally respected, on call permanently in practice if not on paper. Uptime, as reported to the executive committee, was 99.6%.

That number was not a lie. It was measuring the wrong thing — whether the PACS application was responding, not whether images were reliably reaching the archive and the reading list. When we ran the initial assessment, the environment had a queue of small, invisible faults that had each been individually tolerated for months:

A mammography unit whose studies reached the archive only because a technologist remembered to push them manually at the end of each shift.
An HL7 order feed from the EHR that dropped accession numbers for one order type, producing unmatched studies that staff reconciled by hand.
Priors from the pre-acquisition archive that were not retrievable from the current viewer at all, so comparisons were fetched by phone call.
A nightly backup job that had been "green" for four years and had never once been restore-tested.

Across the environments RAD365 assesses, roughly 70% of imaging service disruptions originate outside the PACS application itself — in interfaces, modality configuration, storage or the network. Those are precisely the incidents a PACS vendor contract does not cover.

Tuesday: the two-hour gap

The CT stopped associating after an overnight OS patch on the receiving node. There was no monitoring on the DICOM listener, so the failure surfaced the way these failures always surface: a technologist noticed the study list looked short, asked the administrator, who was already inside a different incident at another site. By the time the node was restarted, eleven studies were sitting on the modality's local disk and two patients had been rescanned unnecessarily.

Nothing about that morning was exotic. What made it expensive was ownership. No system was watching the listener, no runbook existed for a failed association, and the one person who could diagnose it was a bottleneck by design. That is the pattern radiology PACS support exists to break — not by being cleverer than the administrator, but by putting instrumentation and a second, third and fourth pair of hands behind them.

What changed in the first 30 days

Onboarding was deliberately unglamorous. Discovery and documentation of every DICOM node, route, interface and storage tier. Monitoring deployed against the things that actually fail — listener health, queue depth, interface message counts, archive capacity, backup completion and restore verification. An escalation matrix with real names and real phone numbers at every vendor in the estate. Runbooks written for the ten faults the department had already experienced twice.

Within the first month the mammography routing was fixed properly, the HL7 mapping defect was reproduced, evidenced and pushed to the integration vendor with the trace attached, and the first restore test in four years was run. It failed. That failure was the single most valuable finding of the engagement, and it was found on a scheduled Thursday afternoon rather than during a ransomware event.

The archive nobody owned

The orphaned second archive turned out to hold roughly 190,000 studies that were still clinically relevant for comparison. Rather than a rushed replacement, it was stabilised and scheduled into a planned consolidation under PACS migration services, with verification counts and pixel-level integrity checks per batch. The department kept its priors. Finance kept its capital plan.

Day 90: what the numbers looked like

The point of support is not that incidents stop. It is that they get caught early, owned by someone accountable, and closed with evidence.

Measure	Before support	Day 90
Mean time to detect an imaging fault	Reported by clinical staff, often hours	Alerted in minutes by monitoring
Faults requiring manual workaround	Four standing workarounds	Zero standing workarounds
After-hours coverage	One person, informally	Staffed rota with written P1 targets
Backup posture	Job status only, never restore-tested	Scheduled restore verification with evidence
Vendor cases	Opened by clinical staff, little evidence	Opened by engineers with logs and DICOM captures
Administrator's week	Almost entirely reactive	Clinical projects and change ownership

How the engagement actually ran: the four steps

Written assessment. Every system, integration, storage tier, coverage gap and recurring fault documented, with risk ranking. The hospital keeps this document regardless of what follows.
Stabilisation. The highest-risk findings — unverified backups, unmonitored listeners, manual routing dependencies — closed first, before any optimisation work.
Steady-state operations. Monitoring, tiered incident response, patch and change control, monthly reporting against the SLA. This is where the PACS support framework and its ITIL-aligned incident lifecycle carries the load.
Planned projects. Consolidation, migration and modality onboarding scheduled as projects with their own scope, rather than absorbed into whoever is free.

The part that surprised the executive team

It was not the uptime chart. It was that the ticket volume went up in month two. When tickets carry no marginal cost and someone visibly acts on them, staff start reporting the small things they had learned to live with. Early tickets are cheap; the same fault reported three weeks later, after a workaround has hardened into a habit, is not. A rising ticket count in the first quarter of a support engagement is usually a sign the model is working, not failing.

For departments running a platform the vendor has already sunset, or waiting out a replacement decision, the same operating model can be applied on a fixed horizon through interim PACS support — stabilise now, decide later, on evidence.

Get a free PACS assessment

Talk to a RAD365 PACS engineer about coverage, migration, or interim support for your environment. No obligation, no sales pitch.

Get a free PACS assessment →

PACS support: frequently asked questions

What PACS support covers

What do PACS support services include for radiology departments?

PACS support services cover the operational IT layer beneath radiology: DICOM node and routing configuration, modality worklist health, HL7 and FHIR interfaces to the RIS and EHR, storage tiering and archive integrity, verified backups and restores, user and hanging-protocol administration, continuous monitoring, incident response under written SLAs, patching and change control, and coordination with PACS, modality and integration vendors. It is an infrastructure and systems discipline, not a clinical reading service — RAD365 keeps the imaging environment running and does not interpret studies.

How do PACS support services help reduce downtime in medical imaging workflows?

Most lost imaging time is not a full outage. It is a stalled DICOM queue, an HL7 order feed that silently dropped a segment, a modality that stopped associating after a firmware update, or an archive tier quietly filling up. PACS support reduces downtime by instrumenting those exact failure points, alerting on thresholds before clinical staff notice, and running a documented incident lifecycle with P1/P2/P3 response and resolution commitments instead of ad-hoc troubleshooting after a technologist complains.

What should I look for when choosing a PACS support service for my hospital?

Look for vendor-agnostic engineering depth across the stack you actually run, written SLAs with measurable response and resolution targets, genuine staffed after-hours and holiday coverage rather than automated ticket acknowledgement, documented escalation paths into your PACS and modality vendors, a signed Business Associate Agreement, demonstrable migration and consolidation experience, and contract language that guarantees data ownership plus a clean exit hand-off.

How much do PACS support services typically cost for a mid-sized clinic?

Support is normally priced as a flat monthly or annual fee scoped to environment size, site count, modality classes and coverage window, rather than billed per ticket. For a mid-sized clinic a flat-fee agreement usually lands below the fully loaded cost of one dedicated PACS administrator once benefits, tooling, recruitment and unavoidable coverage gaps are counted. RAD365 quotes after a written assessment of the actual environment rather than from a published rate card.

Can PACS support services be customized to work with multiple imaging modalities?

Yes, and multi-modality coverage is the normal case rather than an exception. A support scope is written per modality class — CT, MR, DR and CR, ultrasound including cine, mammography, fluoroscopy, nuclear medicine, dental and intraoperative capture — because each has its own DICOM conformance quirks, worklist behaviour and storage profile. Mixed-vendor fleets are supported the same way: the engineering team works to the conformance statement, not to a single manufacturer's playbook.

Coverage, SLAs and operations

What does genuine 24/7 PACS support look like in practice?

Genuine round-the-clock coverage means a named engineer is awake and reachable at 3am, monitoring is generating alerts that a human acts on, and out-of-hours incidents follow the same documented lifecycle as daytime ones. A useful test at contract stage is to ask what happens to a P1 raised at 02:00 on a public holiday: who receives it, in how many minutes, with what authority to change production, and what evidence is produced afterwards.

What SLA response times are realistic for imaging incidents?

In most hospital environments a workable structure is 15 to 30 minutes to acknowledge and begin work on a P1 that stops clinical imaging, one hour for a P2 degradation affecting a single modality or site, and next business day for P3 requests and administration. What matters more than the numbers is that they are written, measured, and reported monthly with real evidence rather than asserted in a sales deck.

How is PACS support different from general hospital IT support?

General IT support owns endpoints, identity, networks and the enterprise application estate. PACS support owns the imaging chain end to end: the modality, the association it makes, the routing rules, the interface engine mapping, the archive tier the study lands on, and the viewer that retrieves it. The skills overlap but do not substitute — most imaging incidents are diagnosed from DICOM logs and HL7 traces, which is a specialist reading skill inside IT.

Do we lose control of our systems if we outsource PACS support?

No. Administrative ownership, credentials and data stay with the hospital. Support is delegated rather than surrendered: every change is logged, reviewable and reversible, change control follows the hospital's existing approval process, and a written exit and hand-off procedure exists from day one. Sites that keep an internal PACS administrator typically pair them with an external team for depth and out-of-hours cover.

How quickly can a PACS support partner take over an existing environment?

A structured onboarding usually runs four to six weeks: discovery and documentation of the estate, monitoring deployment, runbook and escalation matrix creation, vendor contact establishment, then a supervised handover period. Environments in active distress can be stabilised faster under an interim arrangement, with full documentation completed while coverage is already live.

Cost, risk and decision-making

How do we calculate what imaging downtime is actually costing us?

Start with throughput: studies per hour on the affected modality, multiplied by the hours lost, multiplied by the average contribution per study. Then add the invisible costs — technologist and administrative rework, repeat exams, delayed discharges, deferred billing, and overtime to clear the backlog. Most departments find the indirect number exceeds the direct number once they measure a full week after an incident rather than the incident window alone.

Is PACS support worth it if our environment is stable today?

Stability is usually a description of luck plus one person's undocumented knowledge. The value of support in a stable environment is that it converts that luck into a documented, monitored, restorable operating model — so a resignation, a vendor end-of-life notice or a ransomware event does not become an unplanned project. It is far cheaper to onboard a partner while things are calm than during an incident.

Can PACS support work with a system the vendor has deprecated?

Yes, and this is one of the most common engagements. A deprecated platform can be operated safely for the twelve to twenty-four months a proper migration takes, provided somebody with real platform depth enforces patch discipline, archive integrity checks, verified restores and a hard boundary around permitted changes. That removes the pressure to replace a system inside a budget cycle that was never planned for it.

How does PACS support handle multi-site and multi-vendor environments?

Consolidated estates created by acquisition are the norm, not the edge case. The support model treats the estate as one operating environment with site-level routing, a single monitoring and ticketing plane, and one escalation matrix that reaches every vendor involved. That replaces the worst common pattern, in which three PACS vendors each support their own island and nobody owns the joins between them.

What should be in a PACS support contract before we sign?

Scope by named system, site and modality class; coverage hours and holiday handling; priority definitions with response and resolution targets; monthly reporting commitments; change control and rollback expectations; security obligations and the Business Associate Agreement; data ownership; and a written exit clause covering documentation, credential return and transition assistance. Anything not named in scope will be treated as out of scope during an incident.

How do we get started with a PACS support assessment?

The usual first step is a written assessment of the current environment — systems, integrations, storage, backup posture, coverage gaps and known recurring faults — followed by a technical call with the engineers who would actually run the account. The assessment produces a findings document the hospital keeps regardless of whether an agreement follows, which is the point: the decision should be made on evidence about your environment, not on a generic proposal.