PACS facts: Constructed and deconstructed explained

By Shawn McKenzie, Founder, President & CEO of Ascendian Healthcare Consulting

It can be safely said that the healthcare services is in a state of flux like never before. Reform initiatives driving the mandate to create interoperability are not in any way exempting medical imaging. As such, we are experiencing a rapidly evolving technology shift that is creating a great deal of confusion in the market. In part, this trend is fueled by the shifting sands of healthcare delivery in that nobody can clearly articulate what healthcare is going to look like in the next decade. So, in response we seem to be hedging our bet towards systems’ flexibility when we should be focusing our attention on systems’ standards, or both.

A number of years ago, I was speaking with a friend who was looking to purchase a new computer that would satisfy the technical requirements of her after-hours gaming obsession. Our conversation naturally evolved into discussing the models offered by the major PC vendors in the market and the component options and features for each model. Frustrated with the various packaged offerings, my friend decided to build her own PC as she was able to select the best of breed and methodically reviewed and selected; processors, video cards, memory and sound cards, etc. that created a “Frankenstein” customized performance rich PC.

She was very comfortable with this effort as her technical and functional requirements were well understood and her knowledge of the individual components related to capability and compatibility was way beyond the average PC user. As such, she successfully built and supported her gaming PC while I was happy with the performance and support offered by my pre-packaged and configured solution.

In essence, this same scenario is playing out in the fast paced changes and activities we are experiencing with contemporary medical imaging technology. The point to this comparison is that we are facing an industry where these similar choices are a reality and selecting imaging technology in component parts (deconstructed) has gained some traction and begun to chip away market share from the more traditionally packaged systems.

The determination to go either way is one that requires a good deal of thought and a better than average understanding of imaging technology and workflow. To back fill a bit on this trend, we will briefly review the history, reasons, trends and contrasting philosophy around the choice between deconstructed vs. constructed, or better yet, reconstructed PACS (Picture Archiving and Communication System) in the radiology market.

Medical imaging has lived in the digital environment longer than any other service-line in the health delivery continuum of care. Our journey has moved through a number of phases reflecting innovation and stabilization with the desired outcome to reach higher levels of clinical functionality, more efficient workflow and now the ability to measure our work in terms of cost accounting, efficacy, and value to the organization, customers and patients. These contemporary metrics have also led us to rethink imaging in terms of not only our own practice but in terms of the enterprise practice. We are now at a point where PACS is being redefined as a system or a series of converged systems, which will manage all of the medical imaging within the healthcare environment. The systems’ convergence for managing all imaging objects produced in healthcare is a subject for several other articles. We will focus on the trends affecting the current radiology market place. As we work through the variations with constructed and deconstructed PACS, it is important to be mindful of the integration requirements and organizational capabilities as they too will be a definitive factor in determining a fit for either option.

What does deconstruction actually mean?

de·con·struct (dë’ken-strûkt’)
tr.v. de·∙con∙·struct·∙ed,de∙·con∙·struct·∙ing, de∙·con·∙structs
1. To break down into components; dismantle

It is imperative to define what exactly deconstruction means in order to assist the reader in determining the contemporary market interpretation. It is possible today to completely dismantle a PACS into separate and independent components only to glue them together again in order to match the functionality of a constructed “standards based” PACS. One might ask why anyone would go to the time and cost of performing such a task unless there is strong data supporting significantly improved functionality, performance and sufficient and coordinated support, all at an equal or lower cost structure. Deconstruction is so new to the industry and so few organizations have implemented a fully deconstructed environment that it would be reckless to say with any validity that deconstruction proves to boast anything better and cheaper.

The interest and evolution of deconstructed PACS is more of an industry self-inflicted wound and now a referendum for those legacy vendors to seek compliance to industry standards. It is however, not a panacea. When frustration reaches a certain point, consumers will seek an alternative. The reactive vendor market will drive innovation to the scene of the crash and lend itself to emergence of a real or perceived remedy to the issue. This is the case in the radiology space. But, as physics teaches, for every action there is an equal and opposite reaction. Our industry is facing the working end of that principal.

So much has been written about deconstructing the PACS environment to provide flexibility. Somehow by tying deconstruction to phrases like “best of breed” or “plug and play”, the unknowing consumer reads “simplicity”. The idea of the “plug and play” flexibility is a nice sound bite, but in reality not as easy as it sounds.

The result of these market forces has been both the emergence of new companies and the steady growth of existing PACS vendors that have always been focused on IHE/DICOM standards. This market shift has created a pull from the once full sales funnels of the legacy PACS vendors. What we find now is that the once proprietary PACS vendors have begun course corrections by either driving their software towards open standards or by acquiring the newer vendors to augment their legacy systems. In consideration of the constant mergers and acquisitions occurring in the imaging vendor space, we can make an argument that the once deconstructed is more and more becoming the reconstructed. As this trend continues, the industry is left with the following choices each of which must be understood in the context of an organization imaging goals:

  1. Fully constructed Legacy (proprietary) PACS (single vendor solution)
  2. Fully constructed (standards based) PACS (single vendor solution)
  3. Partially deconstructed PACS (PACS database with a VNA)
  4. Fully deconstructed PACS (multiple vendor integrated software stack)

PACS has ALWAYS been deconstructed

There is much confusion in the market about deconstruction of PACS. To varying degrees, the argument can be made that PACS has always been somewhat deconstructed. As remediation, and by definition, the acronym for PACS is as follows:


The Picture component is defined by a viewing application capable of providing the clinician the tools necessary to render and evaluate an anatomical image varied upon the modality presentation of the image. But in many cases advanced visualization (PICTURE) software for 3D and 4D rendering of the image has been accommodated through an interface to a third party software application. The same applies for some designated mammography applications where they are not native to the vendors offering. Does this not count for the definition of deconstructed?

Until the introduction of the VNA (Vendor Neutral Archive), the Archiving feature of legacy systems was always a native component of the overall system and designed to work directly with the applications database. The archiving of images in many legacy PACS were regularly formatted with proprietary DICOM tags that added to the performance of the system.

Communications in the PACS has often been characterized as communication within the confines of the system; for instance, technologist to radiologist communication, or ER to Radiologist. These systems often used third party applications to provide communication inbound and outbound. The Radiology Information System (RIS) was not always native to the PACS application but served as both an “inbound” ADT/orders and “outbound” report application which comprised in part, the (COMMUNICATION) layer. Dictation systems can also be grouped with the communication aspect of the PACS, but very likely lived outside the native system, again in a deconstructed design that at times presented problems where reports did not always match studies.

The above may be seen by some as splitting hairs as the deconstructed layers in the legacy environment come nowhere close to the “big bang” deconstruction of today which has taken aim on the proverbial engine room of the legacy PACS. By the engine room, I mean to draw attention to the secret sauce which was always been in the workflow, primary viewing application and the speed from archive to full fidelity image transfer. While the legacy PACS vendors worked to provide enhancements related to user ease and speed, historically many vendors chose speed and functionality over standards in their design.

Lighting the fuse—market response to legacy PACS frustrations

Anyone that has been working in the operational capacity of the radiology service line for more than ten (10) years can attest to the level of frustration built-up by the cost, time and interruption of a systems upgrade of a PACS. Furthermore, the proprietary nature of some of the “Big Iron” legacy PACS often forced imaging leadership into making decisions related to service line expansion into a narrow gap defined by their PACS vendor. For the longest time, systems lacking flexibility and interoperability with other systems hindered options and allowed the PACS vendors to define the narrative of the business unit. This frustration echoed across the environment and was heard by existing and new companies with the mantra that all development will follow the guidelines of established data standards. In addition to the internal frustrations of radiology came the ever increasing need to consolidate the number of independent systems supporting the overall medical imaging service lines. Image producing departments were all generating data in multiple disparate systems with little to no cross pollination of the data irrespective of the clinical requirement or advantage to the care continuum to do so. Clinicians found themselves logging into a variety of different systems, all with different user interfaces to conduct business with even the slightest continuity. Clearly the industry had become ripe for systems that made it an easier task to visualize image related data from various departments. The years of proprietary systems fueled by changing healthcare mandates of improved interoperability created a backlash focused on the frustrations and limitations of legacy PACS.

The forces advancing deconstruction

The deconstruction trend was not born of boredom or some sort of end stage radiological psychosis. Rather this trend has been a product of years and years of the industry being forced to make systems selections that were not responding quickly enough to the shifting priorities of interoperability. In addition, Federal programs under the Accountable Care Act (ACA) such as the HITECH Act and The Accountable Care Organization (ACO) movement have focused the spotlight on data fluidity and unfettered use to drive collaborative care. These initiatives have also spawned a rapid pace of mergers and acquisitions where Integrated Delivery Networks (IDN’s) were absorbing hospitals and practices in order to shore up perceived breaks in care continuity. This convergence created great strain on the ability for the organization to efficiently and effectively share image data across the growing enterprise. The acquisitions often came with the need to make use of a legacy PACS because the cost, time and disruption of moving them onto the primary systems was often prohibitive.

The VNA was really the first attempt at chipping away at the legacy vendor’s domain. The concept was to separate the “A” from PACS and create an ecosystem that can act as the central repository for ALL radiology across a patch quilt of PACS brought on by the rapid pace of organizational convergence and M&A. The added advantage was for the potential consolidation of all image data generated across the enterprise.

The concept was a simple one to articulate. Consolidate everything into a single environment stripped of any proprietary tags and have all of the different PACS send and retrieve from that one location.

The next to fall was the “P” as a series of vendors developed clinical and diagnostic viewers that provided the tools necessary for the radiologists and referring clinicians. Utilizing industry standard web protocols (HTTP and secure HTTPS), these viewers provided a gap fill solution to the access and viewing functionality in a “zero footprint” concept. With many requiring only HTML 5 mobile browser for display, this technology provided more flexibility for platform viewing hardware choices and more control over bandwidth latency challenges with smart streaming technology. Initially, the viewers were focused on general reference viewing functionality and rapidly grew to expand the review and diagnostic toolset in order to incorporate multiple end-users.

Following closely behind came what falls under the “C” category where vendors developed independent workflow engines capable of not only mimicking the flow of exam worklists, but were able to provide a single worklist spanning across multiple PACS. In addition, these workflow companies incorporated the added value of Critical Test Results Management, (CTRM) and analytics related to Key Performance Indicators, (KPI) metrics in the radiology departments and, in some instances, Peer Review capabilities.

The pendulum swing

So now the law of physics works to normalize the momentum toward deconstruction. While some PACS vendors in the market have always been designed using standards, most immediately took action to “open” their systems by driving new version releases toward the adherence of standards. This action happened very quickly as changes to the old systems was a primary focus and partnering or acquisition of the younger more flexible companies brought the pendulum back from an industry seeking best of breed deconstruction to best of suite reflecting only partial or no deconstruction. It is interesting how some of the individual components once touting the benefits of developing a deconstructed systems stack have begun acquiring companies in a move that reconstructs the deconstructed. The upshot is the once deconstructed is now, through vendor acquisitions and add-ons, beginning the process of reconstruction.

An interesting dichotomy is how the rest of the healthcare world is moving at breakneck speed to function within the confines of a single “enterprise” system, while imaging has, at least temporarily gone the opposite direction. Perhaps the recent interest in a deconstructed environment and threats of “the death of PACS” has been no more than a diversionary tactic to get the legacy players to reassess how they approached the market and force a move to the middle where standards play a more active role than the proprietary design methodology of the past.

Considerations for a multi-vendor approach

One of the trending marketing sound bites being used in the new paradigm of deconstructed PACS is “Plug and Play”. This term denotes the ease of layering together and integrating a software stack where the effort can be seemingly done from a one page instruction manual. This is in fact not the case. With that in mind, each organization must determine their individual path based on understanding the pros and cons of a deconstructed PACS environment and taking into consideration their individually defined goals and capabilities.

In the legacy PACS world, healthcare organizations relied on their vendor partner to ensure the flow of data through the PACS worked as designed with few hiccups. Whether or not the system worked as designed, marketed and sold, it was a singular issue with a direct line to those responsible for the fix. As you move into the world of full, or partially deconstructed PACS, it is imperative to clearly understand the details around how data will flow through each individual system and to what degree the handoff is configured between individual systems. It takes a bit of sophistication and a better than average understanding of how imaging systems work to engage in the process of selection and integration of a deconstructed software stack. Even in a partially deconstructed PACS where an organization has decided on a VNA backend only, the method for ensuring the efficacy, efficiency and synchrony of data flow between systems must be fully understood and the systems integrated to perform as well as a system that was designed together.

Below are just a few of the common issues that must be addressed as part of a partial or full deconstruction of PACS:

  • Poor organizational governance pertaining to an enterprise imaging strategy that will not only address radiology in a deconstructed manner, but can ultimately provide the ecosystem for other image producing service lines.
  • Underestimating the complexity of fully deconstructed PACS implementation.
  • Synchronization of the image data as it relates to Image Object Change Management (IOCM) between the VNA and the application layer of the systems.
  • In a PACS to VNA (partial deconstruction), it is imperative to understand the PACS DICOM SOP classes as the functionality and synchrony may call for a system to be both a Storage Class User (SCU) and Storage Class Provider (SCP) versus one or the other.
  • The flow across systems related to image presentation states. Are the presentation states, (annotations for instance), stored in the database or the archive of the systems you plan on stacking as one.
  • Integrated Service Level Agreements (ISLA). When you have a deconstructed PACS, the vendors in the software stack individually manage the service levels expected from their system. When you bring the deconstructed systems together, it is critical to define the service level agreements for each individually, but more importantly, the handoff points between them. If a unified system goes down, the vendor team/s works collaboratively to find and fix the break. In a deconstructed system, it is up to the customer to articulate the expectation of service and the hierarchy and escalation path that all vendors will agree to be held accountable. This process can be a bit daunting because nobody wants to be holding the ball when things are going badly.
  • A poor understanding of your organizations current IT infrastructure or ability to engage in a deconstructed PACS initiative. Many organizations are suffering from IT project fatigue following some of the more prominent industry initiatives software implementations such as (ICD-10 and EHR).
  • Insufficient number of completed implementations of fully deconstructed environments to validate the functional and performance improvement claims over standards-based contemporary constructed systems.
  • Acquisition of the individual (deconstructed) module vendors by larger PACS companies.

Best of breed vs. best of suite—finding the fit

The industry vendors providing a consolidated solution have over the past few years moved to develop their systems in a less proprietary way by embracing industry standards. Some PACS vendors have always adhered to standards and are likewise gaining market share, while some continue to lag behind and are just now updating systems interoperability through internal development or through acquisitions and /or partnerships.

Knowing your capabilities as an organization is the first and foremost imperative as you begin considering your enterprise imaging strategy. As described previously, the industry provides a multitude of options when the need arises to update your radiology service line software solution. You must be able to clearly articulate the current and future needs before embarking on a path. The choice to go with a fully or partially deconstructed “Best of Breed” or a “Best of Suite” option where the system is built upon industry standards is an important decision for any organization. It is imperative to know what the organization is trying to accomplish as one size does not fit all.

The best fit may be the constructed or partially deconstructed option where workflow functionality of a system is driven by a single application layer, while creating flexibility in the archive space with the selection of a VNA. Most contemporary PACS vendors have realized this trend and offer a native VNA option, or show willingness to work with a third party VNA as part of the overall solution. Rest assured that even the addition of a third party VNA to support a more enterprising archival solution is not without its challenges.

The “Best of Suite” option where a vendor provides their own native VNA simplifies both the integration and the service and support component as you have in industry terms “One throat to choke”. Be cautious in this selection as the term VNA is used as an ear worm to get the attention of the buyer. Not all VNA’s boast the same functionality, so know what you are expecting the VNA to do for you short and long term.

On the flip side is the option of a fully deconstructed “Best of Breed” option where an organization has determined that selecting individual systems to stack together is the better choice. It is not prudent to go the path of deconstruction because it is “trending”. This decision must be made on the heels of a well-defined and thoughtful process taking into consideration the goals, objectives and organizational capabilities devoid of the market noise where deconstruction is touted as the messiah solution.


AHRA 2016 symposium: “PACS facts: Constructed vs Deconstructed”

View the recorded seminar from the AHRA Annual Meeting & Exposition in Nashville, TN on August 1, 2016. Shawn McKenzie defines in this presentation the differences between fully deconstructed, partially deconstructed, and constructed PACS. He ‘brings to light’ the technical factors, integration requirements and organizational capabilities that are essential when determining the best solution for your organization.

Author: Shawn McKenzie, Founder, President & CEO of Ascendian Healthcare Consulting

Related products