Welcome to the second to last post in our "speed" series of blogs, “Can you? Visage can.” In our last chapter, we discussed how most people think about speed in terms of the front end (e.g., the viewer(s)), but don't adequately consider the speed of the backend (e.g., the server(s)).
A good way to look at speed is that they are two sides to the same imaging coin. If either is slow, it's going to slow your imaging organization down. If you're an organization with significant incoming volume, the slower the backend, the likelihood your radiologists will be working from behind is high. If both sides of the Imaging coin are slow, then you'll likely have a slew of problems organizationally that only get compounded with scale. One measure of backend speed is study ingest performance, or how quickly can the server(s) process incoming DICOM studies. Visage 7 is scaled to support massive ingest performance, supporting tens of millions of studies annually. It's also important to repeat that Visage has never encountered a PACS, viewer, archive or VNA that can even come close to the speed, ingest performance and scale of Visage 7.
Most legacy PACS architectures do not have streamlined architectures, meaning they require multiple servers, with a variety of functions, networked together in order to deliver the total requirements of the PACS. When institutions want to add (for example) additional locations, add multiple new modalities, add mobile imaging access, and support new -ologies, additional servers are typically required. These add to the architectural complexity that must be supported, but how does it impact speed?
And that brings us to our next topic in Chapter 10: Multiple Workflows.