During a recent client review of vendor responses for a PACS (Picture Archive and Communications System) and VNA (Vendor Neutral Archive) acquisition, the discussion of a “deconstructed” PACS came up. What I discovered to no one’s surprise, is that there are different interpretations of what is meant by a “deconstructed” PACS. I thought it might be worth an attempt to clarify definitions and possibly help others avoid confusion.
It is no surprise over the past few years that several initiatives have had a significant impact on the definition of PACS. Figure 1 depicts a classical representation of a PACS.
All functionality is self-contained within the PACS. Image acquisition is the process for acquiring studies from modalities. Workflow addresses study identification, modality worklist, reading rules and lockout when a case has already been opened, etc. Interpretation addresses reading and reporting the study at a diagnostic workstation. Study management addresses the cache, archive and rules associated with study retention. And study access relates to other non-diagnostic clinical access.
The advent of VNA’s, and separate clinical viewers, along with the implementation of Electronic Medical Records (EMR), became the first efforts to “deconstruct” PACS. Figure 2 depicts the changes taking place.
The EMR has begun to take over some of the workflow classically associated with a PACS, as have 3rd party applications. The VNA represents a separate archive from the PACS and offsets the need for the PACS to manage images long-term. The Universal Viewer (UV) has displaced the need for the PACS to handle images outside of making the diagnosis and report. Such a scenario relegates the PACS to acquiring image studies and interpreting/reporting studies.
Recently, some vendors are pushing the notion of a completely independent PACS solution, again suggesting a “deconstructed” PACS. Figure 3 highlights this concept, where the central focal point becomes the study management and workflow. Images are acquired directly into a VNA, and can be accessed by both diagnostic and clinical viewers. In this variation, there is no need for separate image caches associated with a classical PACS. Images flow directly to a VNA and workflow rules govern accessibility for both diagnosis and clinical access in conjunction with the EMR.
Another twist to the “deconstructed” nature is that once images are centrally managed by a VNA, separate services such as dedicated advanced visualization applications can be added without the need to replace core elements.
Of course there are pros and cons to these alternatives. The key issue is in terms of system redundancy. When image acquisition and workflow are dedicated to PACS, if the PACS goes down, image accessibility is still operative throughout the institution via the VNA and UV. When the VNA becomes the hub for such activity, if it goes down, all accessibility is impacted. In a single service line application such as an imaging center or small hospital, this is probably not a problem as elements are not shared across service lines.
Similarly, in the case of workflow, when it is part of a service line PACS, the VNA is not burdened with managing the service line workflow. When centralized, the workflow application will need to address varying workflow rules for multiple service lines.
Another factor to consider is that in a “deconstructed” environment, the integration falls more heavily on the facility, as there may be multiple vendors involved. A more classical PACS places more of the burden on the vendor in terms of interoperability.
It may be early in the lifecycle, but another notion to a deconstructed PACS is the avoidance of duplicated applications. For example, the acquisition and study management needs for cardiology may be very similar to radiology, with the key differentiator being the interpretation workstation functionality. Having a common “backend” could reduce costs and simplify PACS at an enterprise level.
“Deconstructed” PACS are likely here to stay, and address specific needs. It is important to understand the different approaches in light of user requirements when considering such a solution. As always, I look forward to the reader’s perspective, as I am sure there are still more viewpoints as to what is meant by “deconstructed.” I hope this blog has helped “demystify” it a bit.
