Radiology PACS is changing. Something of a paradigm shift is occurring; from a current generation radiology PACS supporting interfaces to multiple third-party specialty applications, to a Vendor Neutral Archive (VNA) configured with multiple specialty display and workflow application plug-ins. In the former case, the PACS application is at the center of data management, and the PACS vendor continues to own the data. In the later case, the VNA is at the center of data management, and the healthcare organization owns the data.
Ten years ago when the current generation of radiology PACS (termed R-PACS 2.0) was first introduced, the core PACS application provided all of the features and functions that a radiology department needed. This single-source, turnkey package included the tools for image acquisition and QC, both the diagnostic and the clinical display applications, and the worklist and workflow applications. The system focused almost exclusively on whatever was required to acquire, display and interpret radiology image data. DICOM and HL7 were the ubiquitous data exchange interfaces. The radiology PACS was a standalone system and data exchange with any other system was not considered a requirement (much to the delight of the vendors).
Over the ensuing ten years, most of the current generation PACS fell further and further behind in meeting the ever-changing needs of the evolving radiology department. Unable to meet the requirements with in-house development, the easiest solution for many PACS vendors was to simply bolt on to their PACS the third-party applications that could meet those new requirements. Examples include specialty processing applications for Nuclear Medicine, Digital Breast Imaging, 3D, and Fusion, as well as Discrepancy Reporting, Peer Review, and Analytics. The latest zero-client, server-side rendering clinical viewers that so many organizations wanted to use to image-enable their EMR systems also became a bolt-on to the PACS. The department PACS was no longer a single source solution. Of necessity it had become a best of breed, multi-vendor solution.
Unfortunately the ten-year old current generation PACS is not even close to best-of-breed. [1] A fat display client that requires a full pixel set download to the display platform is old technology and incapable of meeting performance expectations. [2] The dependence on DICOM as both a data format and a transfer interface is severely limiting. [3] The requirement that any third-party application be bound to the idiosyncrasies of the PACS is simply inefficient. [4] The inability to support a dual-sited, fully mirrored configuration means there is no Business Continuity. For these and many other reasons, the era of R-PACS 2.0 is coming to an end.
The PACS paradigm has shifted 
to PACS 3.0, which is definitely a best-of-breed ensemble of [1] VNA, [2] various diagnostic and clinical display applications, and [3] an enterprise workflow/worklist application, all of which simply plug into the neutral VNA.
A Best-Of-Breed solution implies a more difficult support paradigm, and that rightfully suggests risk. However one must consider the fact that the R-PACS 2.0 solution that requires multiple third-party applications effectively makes those systems a multi-part solution as well…and most of the PACS vendors are not going to include those third-party apps in their SLA or their system monitoring solution. It seems to me that meeting all of the requirements of today’s radiology department virtually demands a best-of breed solution. Since most of the PACS vendors have clearly stated that their service support packages do not cover many of those third-party applications, these hybrid R-PACS 2.0 solutions present some degree of risk as well.
The greater risk however is the fact that these R-PACS 2.0 solutions will most likely have to substantially evolve in the next few years in order to meet the market challenges being presented by those companies whose display applications already feature the more advanced server-side rendering display technology and true BC configurations. Such a dramatic overhaul to the R-PACS 2.0 architecture will most likely cost significant upgrade dollars…costs that are unlikely to be covered by the yearly software maintenance fees. Unfortunately, if the PACS vendor that the healthcare system chooses to partner with does not make these dramatic upgrades, that organization will effectively be saddled with old technology for many years to come.
I invite the reader to learn more about the paradigm shift from R-PACS 2.0 to PACS 3.0 by reading my latest White Paper on the subject. Aunt Minnie is publishing the paper as a three-part series, with the first part appearing on September 25, 2014. Part 1 can be found at http://www.auntminnie.com/index.aspx?sec=sup&sub=pac&pag=dis&ItemID=108618