Managed PACS Services: How to Evaluate PACS Providers in 2026

A practical 2026 guide to evaluating PACS providers: scope tables, SLA language, staffing models, pricing inputs, onboarding and radiology IT support coverage.

Choosing between PACS providers is one of the few procurement decisions in a hospital where the thing being bought is almost entirely invisible at the point of purchase. You cannot test overnight response before you sign. You cannot see how an engineer behaves during a stalled archive replication. What you can do is evaluate the structure that produces those behaviours — scope, staffing, SLA language, escalation, onboarding depth — and that structure is knowable in advance. This guide sets out how to do it, and how managed PACS services should be scoped in 2026.

Scope note: RAD365 is a physician-owned global operations partner running imaging infrastructure for hospitals, imaging centres, radiology groups and veterinary networks. We operate the systems layer — monitoring, DICOM and HL7/FHIR connectivity, storage and archive integrity, migrations, legacy platform support, vendor management. We do not read or interpret studies. What follows is drawn from environment assessments and transitions, which is operations experience rather than clinical experience.

Scope beats price, consistently

Across RAD365 assessments of existing arrangements, the most common source of dissatisfaction is not the fee — it is a scope boundary the hospital did not know existed until an incident landed on the wrong side of it. Comparing exclusion tables before comparing prices removes most of that risk before signature.

Step 1: Inventory before you go to market

You cannot scope what you have not documented, and every provider will quote against whatever you tell them. Before an RFP goes out, produce a working inventory: every DICOM node and AE title, every modality with make, model and software version, gateways and routing rules, interface engine and message specifications, archive tiers with current size and growth rate, the imaging network topology, identity services, workstation counts, and the vendor contracts already in place with their support boundaries. Sites acquired in the last three years are the usual gap — they are frequently absent from every existing schedule.

Step 2: Shortlist on two hard filters

Filter one: genuine coverage of the stack you actually run, including any end-of-life platform. Filter two: real after-hours engineer staffing, meaning a named person awake and on shift with standing authority to act, not a portal that acknowledges tickets. Applying these two filters usually takes a long list down to three to five candidates, which is the right number to evaluate deeply.

Step 3: Demand a scope-and-exclusions table

Ask every bidder for a two-column table listing what is included and what is explicitly excluded, element by element, across both the PACS layer and the infrastructure layer beneath it. This single document does more to differentiate PACS providers than any other artefact in the process, because it forces the narrow bidder to state their narrowness in writing.

Comparing PACS providers: what to hold side by side

Dimension	Weak provider	Strong provider
Scope definition	General phrase such as "PACS support"	Element-by-element inclusion and exclusion table
Overnight cover	Portal intake, human next business day	Named engineer on shift with change authority
SLA targets	Response only	Response and resolution per severity, reported monthly
Monitoring	Server availability ping	Queues, interfaces, associations, storage headroom, replication
Infrastructure layer	Out of scope or unstated	Radiology IT support included in the same contract
Onboarding	Credentials handover, straight to live	Discovery, monitoring, runbooks, shadow period, then SLA start
Exit terms	Silent or restrictive	Data ownership, hand-over pack, transition period

Step 4: Interrogate the staffing model

Ask how many engineers hold your account by name, the shift pattern across nights, weekends and public holidays, whether overnight staff are awake and working or on call from home, what they may change without daytime approval, how many other accounts each carries, and what happens to coverage when a named engineer resigns. Then run a technical session in which your own administrator questions their engineers about your architecture. Nothing else in the process is as informative.

Step 5: Read the SLA and the exit clause together

A usable SLA defines severities by clinical impact, sets both response and resolution targets for each, names escalation contacts with authority levels, states how attainment is measured, commits to a monthly report that discloses misses, and specifies the consequence of a miss. The exit clause should confirm hospital ownership of data and documentation, define the hand-over package, and set a transition period. Read them as one document, because together they describe what happens when the relationship is under strain.

Radiology IT support: the layer that quietly loses coverage

The most common uncovered gap we find is not in the PACS application. It is in radiology IT support — the imaging VLAN and its segmentation, bandwidth and latency between modalities and the archive, diagnostic workstations and displays, dictation endpoints, identity and access services, and the virtualisation platform underneath. These are frequently assumed to belong to general hospital IT, while general hospital IT assumes anything with "imaging" attached belongs to the PACS contract. Neither assumption is written down, so the layer goes unowned.

How that coverage lapses without anyone noticing

It happens the same way every time. An administrator leaves and duties are informally absorbed. A procurement round renews a vendor contract at a narrower scope. A monitoring agent stops reporting after a server rebuild, and the absence of alerts reads as good news. A site arrives through acquisition and is never added to a schedule. Nothing breaks on the day; it breaks weeks later, and the post-incident review discovers the layer had no owner the whole time.

Recovering the coverage

Three actions close it. Audit the current contracts against the asset inventory and mark every element with a named owner — anything unmarked is your gap. Fold the infrastructure layer into the same contract and the same severity framework as the PACS layer, so no incident can fall between two agreements. Then re-audit annually and after every acquisition, upgrade or staffing change. During a platform change this matters even more: read the interaction between PACS migration services and the infrastructure layer carefully, because migrations that overrun almost always overrun on bandwidth, storage provisioning or network segmentation rather than on the archive tooling.

Onboarding: the five phases that predict the next three years

Discovery and asset inventory — every node, interface, modality and dependency documented, with a tested restore.
Monitoring deployment — agents and thresholds tuned to your measured baseline, not to defaults.
Runbook authoring and escalation sign-off — named people, authority levels, vendor contacts on file.
Shadow period — running alongside existing staff for at least one full cycle including an after-hours window.
SLA commencement — formal start with the first monthly attainment report already scheduled.

Four to eight weeks is realistic for a single site; multi-site networks take longer. A provider proposing to go live on day one is proposing to learn your environment during your incidents. The structure we hold ourselves to is published in the RAD365 PACS support framework, and the day-to-day radiology PACS support service describes what the running state looks like once onboarding closes.

Why RAD365 makes this argument

RAD365 runs imaging infrastructure vendor-agnostically across GE, Sectra, Intelerad, Philips, Fujifilm, Agfa and end-of-life platforms. We staff real shifts through nights, weekends and holidays, work on a flat monthly fee against a written SLA with resolution targets, and support deprecated systems other providers decline. We are an infrastructure and operations team, not a reading service. The arguments above are the ones we would want a hospital to use on us during an evaluation.

Managed PACS services and PACS providers: frequently asked questions

What Managed PACS Services Cover

What does a managed PACS services contract typically include?

A complete contract covers continuous monitoring of the imaging estate, SLA-bound incident response with severity levels, DICOM node and routing administration, modality worklist health, HL7 and FHIR interface management, storage tiering and archive integrity, verified backups with documented restore tests, user and hanging-protocol administration, patch and change control, vendor escalation on the hospital's behalf, and monthly SLA attainment reporting. It should also name the assigned engineers, define the escalation matrix, and state data-ownership and exit terms.

What is the difference between PACS support and radiology IT support more broadly?

PACS support is scoped to the imaging chain — the PACS application, DICOM routing, worklists, archive and the interfaces feeding them. Radiology IT support is the wider layer the imaging chain sits on: the imaging VLAN and its segmentation, bandwidth and latency, diagnostic workstations and displays, dictation and reporting endpoints, identity and access services, and the server or virtualisation platform underneath. In practice the two overlap so heavily that splitting them across separate contracts creates the exact boundary disputes that delay incidents.

What network and infrastructure elements fall under radiology IT support versus PACS support?

Radiology IT support typically owns the imaging network segment, switching and firewall rules, bandwidth and latency between modalities and the archive, VPN and site-to-site links, diagnostic workstation builds, display calibration workflows, virtualisation hosts and identity services. PACS support owns the DICOM nodes and routing rules, worklist configuration, HL7/FHIR interfaces, archive tiering and retention, hanging protocols and user administration. The failure point is the seam between them — which is why a single accountable contract works better than two.

Can a single managed PACS services contract cover both radiology IT support and PACS administration?

Yes, and it is the arrangement we recommend. One contract, one escalation path and one severity framework across both layers removes the argument about whose problem it is at the moment when the argument is most expensive. The practical requirement is that the scope document lists both layers explicitly, element by element, rather than relying on a general phrase like "imaging IT". Anything not written into the scope table will be treated as out of scope during an incident.

Do managed PACS services include DICOM gateway and interface management?

They should. The DICOM gateway and the interface engine are where a disproportionate share of real incidents originate — a routing rule that no longer matches a renamed AE title, a compression setting changed during a modality service visit, an order feed that silently dropped a segment after an EHR upgrade. Gateway and interface management means owning the rule set, monitoring queue depth and association failures, and testing changes in a controlled window rather than discovering them clinically.

Evaluating PACS Providers

How many PACS providers should a hospital request proposals from?

Three to five. Fewer than three leaves no basis for comparing SLA language, pricing structure or engineering depth, and makes it impossible to tell whether a term is standard or unusual. More than five turns evaluation into an administrative exercise that delays the decision without improving it. Shortlist on two hard filters first — genuine coverage of the PACS and modality stack you actually run, and real after-hours engineer staffing — then evaluate the shortlist deeply with reference calls and a technical session.

What questions should I ask PACS providers about their engineer staffing model?

Ask how many engineers will be assigned to your account and whether they are named; what the shift pattern is across nights, weekends and public holidays; whether the overnight engineer is awake and on shift or on call from home; what they are authorised to change without daytime approval; how many other accounts each engineer carries; what the handover process between shifts looks like; and what happens to coverage when a named engineer leaves. Vague answers here reliably predict slow after-hours incidents.

How do PACS providers handle after-hours escalation for a hospital's imaging network?

Strong providers run a documented escalation matrix agreed before go-live: severity definitions tied to clinical impact, the named first responder per shift, the second-line engineer, the duty manager, and the vendor contacts with account numbers already on file. The engineer on shift holds your runbook and has standing authority to act on P1 conditions. Weak providers escalate by email into a queue that a manager reads the next morning — technically an escalation path, operationally a delay.

How do I know if my hospital's current PACS provider is underperforming?

Watch for a consistent pattern: your staff detect incidents before the provider's monitoring does; SLA reports arrive late, arrive without misses disclosed, or do not arrive at all; every after-hours ticket resolves the following morning; the same root cause recurs without a problem record; scope changes are quoted slowly and priced opportunistically; and no one at the provider can describe your architecture without asking. Any two of those together warrant a formal service review with the attainment data in front of you.

Contracts, Pricing & Onboarding

How is "managed PACS services" different from a break-fix support ticket system?

Break-fix is reactive and transactional: something fails, you raise a ticket, someone bills for the repair. Managed services are proactive and preventive: continuous monitoring on the specific failure points, thresholds tuned to your baseline, patch and change control, capacity planning, restore testing, problem management to stop repeats, and a flat fee that gives the provider a direct financial incentive to prevent incidents rather than accumulate them. The distinction shows up most clearly in whether anyone is watching between failures.

What discovery steps happen before a managed PACS services contract starts?

Discovery inventories every DICOM node, AE title, modality, gateway, interface, archive tier and dependency; maps the imaging network and identity services; records current retention and backup arrangements and tests a restore; documents vendor contracts, support boundaries and account numbers; captures workflow and hanging-protocol conventions from the clinical side; and establishes the performance baseline monitoring will be tuned against. It typically runs two to four weeks and produces the documentation set the hospital keeps whatever happens next.

How do PACS providers price contracts for a multi-site hospital network?

Usually as a single contract with per-site scope schedules rather than separate agreements. Inputs are site count and size, aggregate study volume, the number of PACS and modality vendors in the estate, interface count, archive size and location, platform age and how much unsupported software is present, and the coverage window. Central monitoring and engineering are shared across sites, so marginal cost per additional site normally falls — which is also why splitting sites across different providers is usually the most expensive option available.

What documentation should a managed PACS services provider hand over during onboarding?

A full asset and node inventory, an interface map with message specifications, a network topology diagram for the imaging segment, per-system runbooks, the escalation matrix with named contacts and authority levels, backup and restore procedures with evidence of a tested restore, the monitoring configuration and alert thresholds, the change-control process, and the SLA with severity definitions and reporting format. All of it should be stated as hospital property in the contract, deliverable on exit without negotiation.

Radiology IT Support & Transitions

Why might a hospital's radiology IT support coverage lapse without anyone noticing?

Because lapses are quiet. An administrator resigns and the duties are informally absorbed; a vendor contract renews with a narrower scope after a procurement round; a monitoring agent stops reporting after a server rebuild and nobody notices the absence of alerts; a site joins through acquisition and never gets added to the contract schedule. Nothing fails on the day coverage lapses — it fails weeks later, and the discovery is that the layer had been unowned the whole time. An annual coverage audit against the asset inventory is the cheapest control available.

What happens if a hospital's radiology IT support needs change mid-contract?

A well-written contract anticipates it with a change-control clause: a defined request process, an agreed pricing basis for additional sites, interfaces or coverage hours, and a review cadence — quarterly is typical — where scope is reconciled against reality. New modality, new site, an EHR upgrade adding interfaces or a migration project all flow through that process. The failure mode to avoid is informal absorption, where the provider quietly does more until a renewal negotiation makes the accumulated scope visible all at once.

Can managed PACS services support a hospital transitioning between PACS providers?

Yes, and an independent provider is the natural party to run it because it has no stake in which platform wins. That role covers documenting the current estate, validating data integrity and study counts, coordinating the outgoing and incoming vendors, maintaining stability on the legacy platform throughout, and holding interim PACS support cover if in-house staff leave mid-transition. Hospitals that make the incoming vendor responsible for the transition usually discover the legacy side had no owner.

What role does radiology IT support play during a PACS migration?

A decisive one, because migration is mostly an infrastructure exercise. Radiology IT support sizes and provisions bandwidth for bulk transfer without degrading clinical traffic, segments the network for parallel running, stands up and validates the target storage tier, reconfigures gateways and routing for dual-feed operation, updates workstation and identity configuration, and monitors throughput and error rates across the whole window. Migrations that overrun usually overrun on infrastructure constraints rather than on the archive tooling itself.

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 →