8 Things Real Radiology IT Support Actually Covers (That a Vendor Contract Doesn't)

What radiology IT support covers day to day — monitoring, DICOM, storage, vendor escalation, DR — and the eight gaps a PACS vendor contract quietly leaves open.

Radiology IT support is the discipline that keeps an imaging department running between the moment a technologist presses expose and the moment a radiologist opens the study. It is not the same thing as your PACS vendor's support contract, and the difference is expensive. A vendor contract covers the vendor's product inside the vendor's boundary. Radiology IT support covers the estate — the network the images cross, the storage they land on, the interfaces that carry the order, the displays they are read on, and the vendor escalations nobody else wants to own. This is a list of eight things that fall in the gap.

A scope note before the list. RAD365 operates radiology infrastructure: uptime, connectivity, integrations, migrations, storage and vendor management, for hospitals, imaging centers, radiology groups and veterinary practices. We do not read or interpret studies. Everything below is systems work.

Most "PACS outages" aren't PACS outages

Across RAD365 environment assessments, the clear majority of incidents reported as "the PACS is down" resolve one layer beneath the PACS application — in DICOM routing, network segmentation, storage headroom, interface engines or identity services. Those layers sit outside a typical PACS vendor's support boundary, which is precisely why they go unmonitored.

1. Continuous monitoring of the things that actually fail first

A vendor's health check confirms the application is answering. That is not monitoring. Useful instrumentation watches DICOM listener availability per AE title, send and receive queue depth, HL7 and FHIR interface message rates against expected baselines, storage capacity trend by tier, backup job completion and restore verification, modality worklist query latency, and certificate expiry dates. Nearly every one of those degrades gradually before it fails, which means it can be caught. This is the operating model documented in the RAD365 PACS support framework, and it is the single largest difference between a department that firefights and one that does not.

2. DICOM and network troubleshooting as one problem

DICOM failures are usually network failures wearing a costume. An association that will not negotiate, a transfer syntax mismatch after a modality firmware update, a called AE title changed during a migration, an MTU problem that only shows on large CT series, a firewall rule quietly reinstated by a policy push. Diagnosing these requires someone who will read association logs and take a packet capture rather than open a vendor ticket and wait. Where routing complexity is genuinely high — multiple sites, mixed vendors, cloud archive — a managed DICOM gateway gives one controlled point to route, normalise and audit traffic rather than maintaining rules on every modality.

3. Storage, archive integrity and restores that have actually been run

A green backup job is a claim, not evidence. Real coverage means capacity headroom tracked against growth, tiering policies reviewed as slice counts increase, integrity checking against silent corruption, and a scheduled restore test with a documented result. The question worth asking your team this week is simple: when did we last restore a study from backup and verify it opened? If nobody can name a date, the organisation does not know whether it has a backup or only a backup job.

4. Interfaces to the RIS, EHR and reporting stack

Orders arrive, studies complete, reports return. Each of those hops is an interface, and each interface fails quietly — a dropped segment, a changed field, an accession mismatch that produces an unmatched study nobody notices until a clinician calls. Interface monitoring with message-rate baselining catches these in minutes rather than at end-of-month reconciliation. Vendor contracts almost never cover the interface engine itself, because it belongs to a different vendor.

5. Vendor coordination — owning the case, not forwarding it

When an incident spans a modality vendor, the PACS vendor and the integration vendor, someone has to hold all three to account simultaneously. Doing that well means reproducing the fault, packaging logs in the format each vendor demands, attending their calls, and refusing to let a case be closed as "no fault found" when imaging is still degraded. This is unglamorous and it is where a great deal of the value sits. Comprehensive managed PACS services price vendor case ownership into the scope rather than treating it as the hospital's job.

6. Change control that understands clinical rhythm

A hypervisor patched during a Monday morning trauma window is a clinical incident, not an IT task. Imaging-aware change control means change windows agreed against actual scanning schedules, a rollback plan written before the change, pre- and post-change verification of DICOM routes and interfaces, and enterprise IT looped in so imaging is not patched as generic infrastructure. Most departments do not need more change governance; they need governance that knows when the CT is busy.

7. The display, dictation and endpoint estate

Diagnostic displays drift out of calibration and need scheduled QA against ACR expectations. Reading workstations accumulate GPU driver and viewer version mismatches. Dictation platforms lose their PACS integration after an update and radiologists lose thirty seconds per study, which at volume is a real number. None of this is inside a PACS vendor contract, and all of it is felt by the people reading.

8. Disaster recovery that has been rehearsed

Defined RPO and RTO agreed with clinical leadership. Documented failover for archive and interface layers. Offsite or immutable copies. A runbook naming individuals, not roles. And a scheduled exercise with a recorded outcome. An untested DR plan is a document. The exercise is the deliverable. Full-estate coverage of these eight areas is what RAD365 radiology IT support is scoped to deliver, and the operating detail behind it is worth reading before any provider conversation.

Vendor contract versus radiology IT support: what each actually covers

Area	PACS vendor contract	Radiology IT support
Application defects	Covered	Escalated and case-owned
DICOM routing across vendors	Own product only	End to end
Imaging network and VLANs	Out of scope	Covered
Storage tiering and headroom	Out of scope	Monitored and planned
Restore verification	Out of scope	Scheduled and evidenced
RIS/EHR interfaces	Interface to own product	Whole message path
Multi-vendor incidents	Boundary dispute	Single owner
Diagnostic displays	Out of scope	QA and calibration cycle
Out-of-hours change authority	Ticket queue	Staffed engineer
Disaster recovery testing	Out of scope	Rehearsed with evidence

How to find your own gap in four steps

List every imaging incident from the last 90 days and mark which layer it actually resolved in — application, DICOM, network, storage, interface, endpoint. The distribution usually surprises people.
Read your vendor contract's scope section and highlight every one of those layers it explicitly excludes. That highlighted set is your exposure.
Ask when the last verified restore and the last DR exercise happened. If there is no date, that is finding number one.
Score coverage against the eight areas above, then decide what to build internally and what to buy. Most organisations end up hybrid, and that is a legitimate answer.

Hospitals working through this for the first time often start from the wider picture on the RAD365 outsourced PACS support homepage, which sets out how assessment, scoping and onboarding run in practice.

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 →

Radiology IT support: frequently asked questions

Scope: what radiology IT support covers

What do PACS support services include for radiology departments?

PACS support services cover the operational technology layer beneath radiology: DICOM node and routing configuration, modality worklist health, HL7 and FHIR interfaces into the RIS and EHR, storage tiering and archive integrity, verified backups and documented restore tests, user and hanging-protocol administration, continuous monitoring, incident response under written SLAs, patch and change control, and escalation into PACS, modality and integration vendors. It is an infrastructure and systems discipline. 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 running out of headroom. 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 and P3 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, genuinely 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 experience, and contract language guaranteeing 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 a single dedicated PACS administrator once benefits, tooling, recruitment and unavoidable coverage gaps are counted. RAD365 quotes only after a written assessment of the actual environment.

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

Yes, and multi-modality coverage is the normal case rather than the exception. 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 handled the same way: engineers work to each device's conformance statement rather than to one manufacturer's playbook.

What is the difference between PACS support and general radiology IT support?

PACS support is scoped to the imaging application and its immediate interfaces. Radiology IT support is the wider estate that PACS depends on: imaging VLANs and network segmentation, storage and virtualisation, diagnostic display calibration, dictation and reporting integrations, identity and single sign-on, certificate lifecycle, and change control across all of it. Departments that buy only PACS support frequently discover that the majority of incidents blamed on the PACS actually originate one layer down.

Coverage, response and operations

What does 24/7 radiology IT support actually include?

Real round-the-clock coverage means monitoring that generates alerts a human acts on, a named engineer awake and reachable at 03:00, and out-of-hours incidents following the same documented lifecycle as daytime ones. It should include change authority — an engineer who can act on production rather than only log a ticket for the morning — plus an evidenced post-incident record. A useful contract-stage test is to ask precisely who receives a P1 raised at 02:00 on a public holiday, within how many minutes, and with what authority.

How fast should a radiology IT support team respond to a critical system-down alert?

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 into the contract, measured against real ticket data, and reported monthly with evidence rather than asserted in a sales deck.

Can radiology IT support cover legacy or vendor-discontinued systems?

Yes, and this is one of the strongest arguments for independent support. When a vendor sunsets a platform, the software keeps working but the safety net disappears: no patches, no engineering escalation, no roadmap. An independent team can maintain the environment on a defined horizon — hardening it, isolating it at the network layer, tightening backup and restore discipline — while the organisation plans a migration on its own timetable rather than the vendor's.

How does radiology IT support handle DICOM and network troubleshooting?

By treating DICOM as a network protocol rather than a black box. That means association and negotiation logs, verifying called and calling AE titles, checking transfer syntax and compression mismatches, packet capture when association fails, monitoring send and receive queue depth, testing storage commitment, and validating modality worklist queries end to end. Network-side work covers VLAN segmentation between modalities and archive, MTU and firewall rules, and bandwidth headroom as CT and MR slice counts grow.

What's the difference between hiring an in-house radiology IT admin and outsourcing IT support?

One person cannot provide continuous coverage, cannot be deep in every layer of a modern imaging stack, and represents a single point of institutional knowledge that leaves when they do. Outsourced support supplies a team with overlapping specialisms, documented runbooks, contractual coverage windows and continuity independent of any individual. The most effective arrangement in larger hospitals is usually hybrid: retain an internal administrator for clinical workflow ownership and buy the engineering depth and out-of-hours cover.

Can radiology IT support teams work across multiple hospital sites?

Yes, and multi-site estates are where the model pays for itself fastest. Multi-site scope covers per-site routing rules, cross-site prior retrieval, consistent hanging protocols and user administration, WAN capacity planning between sites and archive, one escalation matrix regardless of which vendor is involved, and consolidated reporting so leadership sees the whole estate rather than one dashboard per facility.

Commercial, compliance and onboarding

Does radiology IT support include vendor coordination during upgrades?

It should, and this is one of the most under-valued parts of the scope. Coordination means owning the vendor case end to end: reproducing the fault, gathering logs and evidence in the format the vendor requires, attending vendor calls with your interests represented, holding the vendor to their own response commitments, and running the change through an imaging-aware window with a rollback plan. Without this, upgrade coordination lands on a clinical administrator who has no leverage with the vendor.

What HIPAA/security responsibilities does a radiology IT support provider take on?

A provider handling protected health information must sign a Business Associate Agreement and carry real obligations under it: role-based access control with individually attributable accounts, encryption in transit and at rest, audit logging of administrative actions, documented least-privilege access reviews, secure remote access, vulnerability and patch management, workforce security training, and defined breach notification procedures. Ask to see the access-review evidence, not just the policy document.

How does flat-fee radiology IT support pricing compare to hourly break-fix support?

Break-fix creates a structural conflict: the provider earns more when things break and nothing funds prevention. Flat-fee aligns the incentive — a provider on a fixed monthly fee is financially motivated to stop incidents recurring. Flat-fee also makes budgeting predictable and removes the internal hesitation to raise a ticket because of cost. The trade-off is that scope must be written carefully so both sides know what falls inside the fee and what is a chargeable project.

What happens during a radiology IT support onboarding period?

A typical 30 to 60 day onboarding runs discovery of every system, interface, modality and storage tier; documentation of the current-state architecture and known recurring faults; deployment of monitoring and alerting; establishment of secure access and the BAA; agreement of the escalation matrix and change windows; a backup and restore verification test; and a written remediation backlog ranked by clinical risk. A provider that wants to go live without discovery is guessing at your environment.

What certifications should radiology IT engineers hold?

Look for a blend rather than a single badge: healthcare imaging credentials such as CIIP for senior staff, ITIL for service management discipline, vendor-specific PACS and modality training relevant to your stack, plus core infrastructure certifications in networking, storage, virtualisation and security such as CCNA, VMware or CompTIA Security+. Certifications indicate baseline competence; the more informative test is a technical call in which your administrator questions their engineers about your actual architecture.

Does radiology IT support include disaster recovery planning for imaging systems?

It should cover both the plan and the proof. That means defined RPO and RTO agreed with clinical leadership, documented failover architecture for archive and interface layers, offsite or immutable copies of imaging data, a written runbook naming who does what during an event, and — most importantly — scheduled DR exercises with recorded results. An untested disaster recovery plan is a document, not a capability; the restore test is the deliverable that matters.