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.
Multiple Workflows
In the late 1990s and early 2000s, legacy PACS were designed to support one workflow and one workflow only: interpretation (and archiving) of diagnostic images. The truth is that most of today's legacy PACS are still based on these architectures. Over time, additional capabilities were added such as web access for clinicians and 3D, but only through the addition of separate servers and licensed technology. And while since then legacy PACS has been upgraded to support even more workflows, most require their own servers, different modules, additional software, isolated workstations and third-party applications to fulfill the needs at hand. Each of these servers needs to be configured, managed, integrated, licensed and maintained at great expense and complexity to the institution.
The resulting system architecture is more often one of disorder than order, one of numerous servers and systems that are tied together with a variety of standard and proprietary integrations. How can one easily assess the speed of an individual workflow? It's not straightforward without doing a Proof of Concept, because each silo of functionality may demonstrate one "speed" in isolation, but as soon as it is tested with other required system components the speed slows down. Integrated testing must be done in order to provide an accurate reflection of actual production performance.
Here's four representative examples related to viewers:
- 3D/Advanced Visualization. If 3D is delivered via desktop integration to a legacy diagnostic workstation, or even a separate server-based system, it needs to get access to images. If the images aren't sent in advance, or if the 3D server is in a remote datacenter over a limited bandwidth connection, the end result is the radiologist is going to wait. What images are sent to the 3D system? Just the current study? How about priors that also require 3D? Having a separate workflow for 3D slows down primary interpretation.
- Mobile Access. Very few, if any legacy PACS offer mobile capabilities as a core part of the PACS. It almost always is a separate server or stack of servers required for use. These server(s) need to be synchronized with the PACS in order to have the latest studies required for viewing, along with the latest changes to studies (edits, deletes, ADT updates, etc.). Does it have all studies? Likely not. What happens when the studies required for viewing are not on the server(s)? The end user will have to wait, or the stud(ies) may not be available for access.
- Universal Viewers. With most legacy PACS, universal viewers provided by the PACS vendor have either been built in house, or more than likely are a separate third party viewer, or are a re-branded third party viewer. Even if they were built in house, they typically have been built using a separate technology stack than the legacy PACS. That means separate server(s) to support the universal viewer, even if it was built by the PACS vendor. Again, separate servers mean additional management overhead, and separate integration points to the PACS. Often times the universal viewer works great in the demo, but once it goes live in production and is integrated to the local or multiple PACS, performance takes a hit.
- Breast Imaging. The vast majority of legacy PACS have inadequate solutions for breast imaging, plain and simple. The result is separate islands of breast imaging workstations, keypads and archives all dedicated to breast imaging. They take up desktop real estate in the reading rooms, generate a ton of heat, and cause radiologists to pivot from one workstation to another all day long. These workflow disruptions are an island from the rest of the PACS and cause headaches for imaging administrators. One of our customers estimated their lifecycle cost for a single breast imaging workstation at $250K. Once they went live with Visage 7, they were able to retire dozens and dozens of breast imaging workstations (and eliminate the need to purchase additional dedicated breast imaging workstations) saving the institution millions in cost savings and cost avoidance.
In contrast to these legacy solutions, Visage 7 performs with incredible speed while supporting a One Viewer philosophy.
Using a single Visage 7 Backend Server, all of the following workflows are supported at incredible scale: Diagnostic, Clinical, EHR, 3D, Mobile, Diagnostic Mobile, Cardiology, Breast Imaging, Specialties, Telerad, At Home/Remote Reading, Non-DICOM, Visible Light, Multimedia, HD Video, Audio, QA and DICOM Modality Worklist.
When all workflows are supported on the same ultrafast architecture, they are all incredibly fast and straightforward to support. Instead of an architecture of disorder, Visage 7 offers a streamlined architecture built for scale, availability and performance.
Stay tuned. Next up is our final post in the speed series for "Can you? Visage can", Chapter 11: Interoperability.
