Digital X-Ray & Imaging Network Uptime Checklist

When email is slow, staff grumble and work around it. When imaging goes down, the chair stops. A patient is seated, the provider is ready, and the appointment cannot proceed until a sensor connects, an image saves, or a pano unit talks to the server again. Imaging downtime is not an inconvenience the way most IT problems are — it is a direct, immediate stop to patient care, and it tends to happen in the middle of a full schedule rather than at a convenient moment.

The frustrating part is that the imaging software usually gets blamed first, and usually is not the actual problem. Sensors and pano units move large files over the network in real time. If bandwidth is shared unevenly, a switch port is failing, storage is nearly full, or a driver has drifted out of date, the symptom shows up as "the X-ray software is being slow" or "the sensor won't connect." The imaging software is often just the messenger.

This checklist walks the infrastructure layers that actually cause imaging downtime: the network the images travel over, the server and storage they land on, the sensors and workstations that capture them, the backups that protect them, and the vendor relationships that get a practice back up quickly when something breaks anyway. Work through it with whoever manages your network, alongside your imaging software vendor if useful.

Network infrastructure for imaging

Imaging traffic is bursty and large. A network built only for email and web browsing will move images, but not reliably, and not at the moment a full schedule needs it to.

• Does imaging traffic get dedicated or prioritized bandwidth (QoS) instead of competing with everything else on the network? Without prioritization, a large software update downloading in the background or a guest streaming video can slow an image transfer to a crawl at the worst possible moment.
• Are sensors and pano/ceph units connected by wired Ethernet wherever possible, rather than relying on WiFi? WiFi is convenient but adds latency and dropped-packet risk that a wired connection does not. A sensor that intermittently loses its wireless link mid-capture is one of the most common sources of "imaging is frozen" calls.
• Have switch ports and cable runs in the operatories been checked for wear, damage, or marginal connections? A cable that is bent, pinched, or just old enough to be failing intermittently can produce symptoms that look exactly like a software problem: slow saves, timeouts, occasional dropped connections.
• Is the network segmented so guest WiFi and patient devices cannot affect the network that imaging and clinical systems run on? Segmentation keeps a patient's phone update or a guest's video call from competing with imaging traffic, and it keeps unmanaged devices off the same network as PHI-carrying imaging traffic.
• Is there enough switch capacity for every imaging device, or are devices daisy- chained through unmanaged switches to make room? Unmanaged switches added ad hoc to fit one more device are a common source of slow, unpredictable performance and are hard to diagnose after the fact.
• Has actual network throughput between an operatory and the server been tested, not just assumed from the equipment's rated speed? Rated speed and delivered speed are not the same thing once real cabling, switches, and interference are in the picture. Measure it rather than guess.

Imaging server & storage

Images pile up fast, and the server holding them rarely gets attention until it is nearly full or nearly out of warranty. Both failure modes are silent right up until they are not.

What "imaging is down" usually turns out to be Most service calls that start as "the imaging software is broken" trace back to the network or the storage underneath it, not the software itself: a saturated connection, a failing switch port, a nearly-full drive, or a worn sensor cable. Treating the software as the suspect first often means the actual cause goes unaddressed and the same call comes back within weeks.

• Does the imaging server or storage have meaningful headroom, or is it running close to full? Imaging files accumulate faster than most practices expect, especially with pano/ceph and 3D volumes. A server that quietly fills up can start rejecting new images with no clear warning to staff.
• Is the age and warranty status of the server hardware known and tracked, rather than "it still works"? Hardware failure on an aging server is the single most disruptive kind of imaging downtime, because recovery can take days rather than hours if there is no warranty or replacement plan in place.
• Is the imaging software kept on a current, supported version rather than several versions behind? Older versions lose vendor support, may not receive security patches, and are more likely to have compatibility issues with newer sensors, workstations, or operating systems.
• Is the integration link between the imaging software and the practice management system healthy and actually checked periodically? A broken PMS-to-imaging link does not always announce itself. It can silently stop attaching images to the right patient record until someone notices.
• Is there a documented plan for what happens if the imaging server fails outright during business hours? Knowing who to call and what the fallback is matters more in the moment than any other single piece of preparation.
• Is storage growth tracked over time so a capacity shortfall is caught months ahead, rather than discovered the day it runs out? A simple trend line is enough to turn a future emergency into a planned upgrade.

Sensor & workstation maintenance

Sensors and the workstations driving them are handled daily, moved between operatories, and plugged and unplugged constantly. That wear adds up.

• Is there a regular inspection schedule for sensor cables and connectors, checking for fraying, kinks, or loose fit? Sensor cables take more physical abuse than almost anything else on the network and are a leading cause of intermittent capture failures.
• Are sensor and imaging device drivers and firmware kept current on a defined cadence, rather than only when something breaks? Outdated drivers are a common, avoidable cause of connectivity issues after an operating system update changes something the old driver did not expect.
• Do the workstations running imaging software actually meet that software's minimum specifications, not just "run" it? An underpowered workstation can technically run the software while still being slow enough that staff describe it as "imaging is down" when it is simply struggling.
• Are imaging workstations dedicated to imaging, or shared with general office use that can interfere with them? A workstation also used for browsing, email, or unrelated software is more exposed to slowdowns, conflicts, and malware than one used only for imaging.
• Is there a record of which sensor and pano/ceph unit is connected to which workstation and port? When something breaks, that record turns a guessing exercise into a five-minute diagnosis.
• Are USB ports and connections for wired sensors checked periodically for physical wear, since these get frequent daily use? A worn USB port is a small, cheap thing that can take a sensor offline in the middle of an exam.

Backup of imaging data

Practices are usually confident their backups cover patient records. Imaging files are a separate, much larger data set, and they do not always make it into the same backup plan.

• Does the backup plan explicitly include imaging files, not just the practice management database? Imaging files are frequently stored separately from the PMS database, and a backup built around the PMS alone can miss them entirely.
• Does backup frequency match how often new images are actually captured, rather than a once-a-day schedule set years ago? A practice capturing images throughout every day but backing up overnight can lose a full day of imaging in a failure, which is a meaningful clinical and legal exposure.
• Has a test restore of an actual imaging file been performed and confirmed to open correctly? A backup job completing without error is not the same as a usable backup. The only way to know a restore works is to run one.
• Is there an offsite or cloud copy of the imaging archive, separate from the copy sitting on-site? A local-only backup is exposed to the same fire, theft, or ransomware event as the primary data it is meant to protect.

Vendor support & warranty tracking

When imaging goes down mid-day, the speed of the fix depends entirely on relationships and paperwork that should already be in place before the call has to be made.

• Is the warranty and service contract status for each sensor and pano/ceph unit tracked and known? Finding out a unit is out of warranty during the repair call, instead of before, turns a routine fix into a budget surprise on top of the downtime.
• Is the imaging software vendor's support contract current and does someone know what it actually covers? An expired support agreement can mean no phone support, no patches, and no help at the exact moment imaging fails.
• Is there a documented escalation path for what to do the moment imaging goes down mid-day, including who to call first? The few minutes lost figuring out who to call, imaging vendor, sensor manufacturer, or IT provider, are minutes a full schedule cannot spare.
• Is there a spare sensor, loaner arrangement, or backup imaging plan in case hardware fails outright? Even a single spare sensor can keep a practice seeing patients while a failed unit is repaired or replaced, rather than rescheduling a day of appointments.