Healthcare delivery organizations are experiencing a paradigm shift from departmental views of medical images -- typically seen in radiology and cardiology -- to a single, enterprise view that encompasses all medical images.
The new paradigm has three major components. First, the vendor-neutral archive (VNA) occupies the center of enterprise imaging operations to improve access and reduce storage and migration costs.
Second, individual diagnostic display applications that are used in the various imaging departments across the enterprise become plug-ins to the VNA. The primary benefit of this architecture is that display applications relinquish ownership of image data, improving data exchange and performance.
Michael Gray of Gray Consulting.Third, an enterprise worklist application consolidates diagnostic workflow into a single view and determines the most appropriate display application to be launched from the VNA for interpretation. This new paradigm in diagnostic imaging is referred to as PACS 3.0.
This series is written as a call to action by presenting a compelling argument that departmental PACS is shifting to an enterprise imaging environment. In particular, healthcare institutions continue to release requests for proposals (RFPs) for departmental-based PACS/VNA solutions, driven by a belief that a departmental solution from a single vendor will also satisfy enterprise IT requirements.
Imaging departments must have the ability to choose the best application to treat patients. Similarly, IT must have the ability to own the infrastructure and applications that manage the data. Finally, the solution must provide enterprise access to medical images and related content from all departments, as well as integrate with one or more electronic medical record (EMR) systems.
The strategy of purchasing a combined PACS/VNA departmental solution all too frequently results in the purchase of a vendor's PACS, as well as the same vendor's PACS archive (marketed as a VNA). Despite assurances that images from other imaging departments can be managed by the VNA component, this is rarely the case.
When the PACS vendor provides the VNA solution, the vendor still has control of the data. As a consequence, the organization is exposed to many of the traditional costs associated with PACS, including the following:
- Moving the data out of PACS/VNA system
- Changing the storage platform
- Adding other PACS to the system
- Adding modalities
- Integrating other applications
It is also important to recognize that while the vendor's diagnostic viewing application performs well when retrieving images from the same vendor's VNA, connecting to other enterprise systems is unlikely to deliver the same level of performance due to proprietary PACS/VNA data access methods.
Purchasing a combined PACS/VNA limits the ability of the IT department to build a medical content management platform that can serve the enterprise. In the PACS 3.0 paradigm, healthcare delivery organizations (HDOs) separate diagnostic applications from the VNA, implementing a best-of-class approach to achieve success. Fear of shifting to this paradigm, as well as the challenges of selecting best-of-class providers, can be significant. Organizations should be equally, if not more, fearful of failing to prepare for this paradigm shift.
Overview of R-PACS 2.0
Current-generation radiology PACS has come to be known as R-PACS 2.0. Figure 1 depicts the functional components of this system. The PACS is comprised of the components highlighted in purple, including the DICOM interfaces, the core PACS applications, the clinical and diagnostic viewer applications, and the applications that support departmental workflow and creation of the reading lists. Some traditional PACS can be launched through a RIS or other workflow solutions. Note that storage is included in the PACS configuration because the PACS tightly controls the storage solution and the images stored there cannot be directly accessed by another application.
Figure 1. All images courtesy of Michael Gray.The RIS, EMR, and reporting systems are usually separate and interfaced via HL7. Clinical users access the images through the EMR and end up using the R-PACS clinical viewer to display the images, which usually consist of only radiology studies. This design, the foundation of nearly all current-generation PACS, is now at least 10 years old.
A great deal has changed in radiology, yet over the past several years, little of significance seems to have changed in radiology PACS. Today's medical imaging environment, including radiology and numerous other imaging departments, is striving to evolve past DICOM to achieve an "all object" construct. Unfortunately, R-PACS solutions are ill-equipped to make this transition. The time has come to investigate alternatives and arrive at a new PACS paradigm.
PACS technology challenges
The fundamental problem with current-generation PACS is that nearly all commercially available solutions are based on limited and aging technology. This applies to R-PACS and other departmental PACS as well because of their emulation of the R-PACS design, but with even less attention to the archival component. Let's explore the major technology challenges that prevent today's PACS solutions from keeping pace with modern requirements.
Challenge No. 1: Infrastructure
Many current PACS solutions cannot be configured with an adequate backup system -- a secondary, fully redundant instance of the PACS application suite. This goes beyond a mere disaster recovery (DR) solution toward a full business continuity (BC) solution.
There are myriad definitions of what constitutes disaster recovery, the most basic being a simple means for creating a second copy of the data. If and when the first copy of the data managed by the primary PACS is somehow lost or damaged, a second (backup) copy is used to replace the lost or damaged copy.
Unfortunately, the term disaster recovery and the concept of DR have morphed over the years to imply full business continuity. A PACS DR solution, however, is not a BC solution. If the primary PACS application and/or its servers become unavailable, there is no quick fix for continuing business until the cause for the downtime is rectified.
A true business continuity solution requires a separate instance of the complete PACS application suite, including a separate instance of the directory database (Oracle, SQL, etc.) running on its own hardware, preferably in a second data center. Most current-generation PACS configurations fall short of this goal by having only a limited database on the DR solution.
The edge server, sometimes referred to as a local facility server, can provide a degree of autonomy to a major facility that is somewhat remote from the data center. If the PACS solution supports these edge servers at all, they may not be comprised of the full application suite or this local server may not have a local instance of the directory database. Without a complete application suite and an independent local database, the edge server cannot support local autonomous operations of the wide-area network (WAN) connecting the remote facility with the main instance of the PACS solution if the main data center goes down.
Do not confuse DR solutions with BC solutions and do not confuse slaved edge servers for BC solutions. A true business continuity solution requires nothing short of a separate, fully functional PACS solution that the department will operate from during both scheduled and unscheduled downtime on the primary PACS or the WAN connecting the facility with the data center. Unfortunately, the basic technology limitations of most current-generation PACS prevent them from being configured with a true BC solution.
Challenge No. 2: Diagnostic display
Today's radiology PACS networks feature diagnostic and clinical viewers that are Web-delivered as fat- or thin-client software applications. This means that the complete software application package is originally installed on the PACS server, while the pieces of the package designed to operate on the images are either manually or automatically downloaded (over the network or "Web") to the individual diagnostic and clinical display stations located throughout the enterprise.
There are two key issues:
- The application software that operates on the image pixel data runs on the client's viewer hardware platform.
- The image pixel data have to be downloaded to the client hardware platform and any work product that needs to be saved has to be uploaded back to the core PACS.
The consequential load on the local and wide-area networks and the corresponding performance issues become unworkable at this point. Exotic and often proprietary compression schemes and fancy pixel streaming technologies intended to alleviate the performance issues simply do not meet today's performance challenges. In other words, the laws of physics cannot be beaten.
Ever-increasing study sizes coupled with other applications that consume bandwidth have greatly outpaced network performance gains over the years, to the point where at-home diagnostic work is painfully slow and more complex in-house processing of massive datasets -- 3D and digital breast tomosynthesis, for example -- is frequently delegated to specialized/dedicated workstations. Client-side image processing and the requisite download of the image data is now an outdated display paradigm.
Another major display issue traces back to the origin of PACS. From the beginning, radiology PACS featured two major classes of display applications: diagnostic and clinical. For obvious reasons, the majority of application development focused on the diagnostic display suite. Rather than design a clinical application suite that met the specific needs of the referring physician, most PACS vendors chose the shortcut. Assuming that referring physicians only require a simple subset of the radiologist's tools, they released clinical viewer applications that were a defeatured version of the diagnostic application suite.
Because the two classes of viewers in this case are based on the same code and accessed through the core PACS, they are inextricably linked together, so that a software upgrade can affect one application positively and the other negatively. Today's referring physicians need to access and view all of a patient's medical images, not just the radiology images. For this reason, it makes more sense for the clinical viewer to be a separate application that is independent of the diagnostic PACS and has access to the entire set of a patient's studies.
A clinical viewer, especially one that would be accessed through the EMR, would support a broader range of users and therefore would have access to more than radiology studies. To date, PACS vendors have not demonstrated that they can deliver the required feature set for displaying the full range of medical imaging -- radiology, cardiology, and other 'ologies (DICOM and non-DICOM images) -- all on the same viewer. Furthermore, intimately tying the clinical viewer to the PACS makes it even harder to access the image data created by other departments that are not readily accessible to that PACS. The department-specific clinical viewer is an outdated display paradigm.
Challenge No. 3: Pixel tricks
Current-generation PACS whose display applications feature client-side processing and therefore are required to transfer image data to and from the client display platforms have introduced numerous tricks in an attempt to beat physics. Some have developed proprietary compression schemes and pixel streaming technologies to create the impression that the display is highly responsive by displaying a first image or first screen layout very quickly, before the rest of the study is downloaded. Seeing the first images is encouraging until the user realizes that you cannot actually begin processing the study until all of the images are onboard.
The diagnostic display application of many current-generation PACS displays the lossy compressed version of prior images to save download transfer time, and many PACS clinical display applications routinely display only the lossy version of the images.
Another common pixel trick is to precache study data on a display station so it will already be onboard when the user sits down to access studies. The problem with this approach is the complication of having to accurately predict which new studies and relevant priors should be precached to a specific workstation. If physician schedules change or reading priorities change, the correct study list may not be on the correct display station. In some cases, the priors are not precached, so the user ends up waiting after all.
There are many datasets that probably should not be moved across the network to be diagnosed. Many have argued that it does not make sense to move any full datasets across the network. For example, digital breast tomosynthesis studies are very large datasets. It is extremely difficult for the R-PACS featuring a client-side diagnostic display application to meet performance expectations when it has to deal with moving such a large dataset. There are no pixel tricks available to solve this problem.
Perhaps the largest negative impact of client-side processing is on at-home reading, which has quickly become a hot button for many healthcare organizations. More physicians are making legitimate arguments for having the ability to interpret the study and dictate the report from home or any other location outside of the reading room. Setting up VPN tunnels to all of these potential locations is simply too expensive and impractical. Ever-increasing study sizes and neighborhood competition for broadband bandwidth make it extremely unlikely that a client-side application is going to meet performance expectations, yet vendors continue to claim that their current-generation R-PACS has a viable offsite reading application. Pixel tricks employed to solve performance issues are an outdated display paradigm.
Challenge No. 4: Windows exclusivity
Client-side processing applications usually require specific hardware configurations and nearly always run on Windows OS. This strategy is suited to IT departments that have zero interest in supporting multiple platforms. In today's healthcare environment, the practice of "bring your own device" (BYOD) is gaining popularity among all ranks of physicians, as well as reluctant support from the IT department. Multiple options for OS and a reduction in the hardware requirements would improve efficiency for both diagnostic and clinical viewing by making more and less-expensive platforms available to the physicians. Consequently, the restriction to Windows-only display platforms is becoming a significant limitation and, clearly, an outdated display paradigm.
Challenge No. 5: Closed system
Most current-generation PACS were simply not designed to work effectively with a foreign archive. If they are somehow induced to forward a study to a foreign archive, they require a "store and remember" software module to know how to retrieve the study. Most PACS are unable to send to a foreign archive the metadata changes made to studies in the PACS, i.e., merge, edits, and deletes, along with updates communicated through an HL7 interface by the HIS and/or RIS. While most current-generation PACS have difficulty interoperating with a foreign archive, there are solutions for synchronizing the two disparate databases. Current-generation PACS were designed to be self-contained systems and were not intended to interoperate with the other systems in a larger healthcare environment. The PACS solution designed to be a closed system is an outdated PACS paradigm.
Challenge No. 6: DICOM only
PACS wouldn't exist if it weren't for industry-wide acceptance of the DICOM standard. Nevertheless, there are numerous image data objects that are not natively DICOM and may not lend themselves to being converted to DICOM. PACS solutions designed for endoscopy, ophthalmology, and dental applications frequently manage JPEG images and may not offer a DICOM conversion interface or have sufficient patient metadata associated with the objects. Digital still-frame images and video clips captured with a mobile device in dermatology, surgery, and the burn unit do not originate as DICOM images. It is a simple fact that a significant percentage of the medical images in a patient's longitudinal medical record are not natively DICOM. Current-generation PACS designed exclusively for DICOM images is an outdated paradigm.
PACS myths
The problems with current-generation R-PACS do not derive exclusively from a gap in technology. There are philosophical issues with system design and marketing. There are also business aspects holding back traditional PACS from embracing the changes occurring in our industry. Let's explore some common myths that continue to shape R-PACS 2.0.
Myth No. 1: Proprietary is good
A proprietary PACS solution (proprietary data formats, proprietary DICOM header elements, and proprietary compression and streaming technology) allows the vendor to assume the paternal role and thereby control the solution, so the vendor can "protect the customer from themselves and other people" in the organization. An open solution is easily modified. A closed solution is nearly impossible to modify -- and certainly not without vendor approval.
Myth No. 2: Vendor control of the data is good
Once again, the vendor wishes to assume the paternal role, i.e., "It's for your own good" that the directory database cannot be accessed and that the data dictionary and schema are guarded like crown jewels behind intellectual property claims. Control of the data greatly complicates data migration and therefore becomes a significant impediment to replacing the vendor's PACS with another.
Myth No. 3: An integrated, single-source solution is good
If the PACS vendor supplies all of the applications, there will be no finger-pointing and no messy interoperability issues. In fact, many components of R-PACS 2.0 solutions were acquired through OEM relationships with other companies or obtained by acquisition of other companies. The vendor has had to integrate all of these disparate applications into the core systems, often contorting the acquired applications to match the proprietary format that the core PACS is based on. Additionally, the application programming interface (API) integrated specialty tools and applications are required to work through the core PACS but are not controlled by the PACS vendor. Instead of a unified solution built from the ground up, the result is a compromised assembly of parts that would make Dr. Frankenstein blush.
Myth No. 4: Data migrations are inevitable (and good business)
Data migrations are required when you change your storage, when the PACS vendor changes its database structure, and when a PACS is replaced. The migration problem not only moves from system to system, it grows exponentially larger as time goes by. The fear of and expense related to a data migration provide the vendor with significant leverage over the customer's decision process. The data migration issue only keeps the customer more captive to the PACS, essentially kicking the can down the road for someone else to deal with the problem when it's worse.
Myth No. 5: A foreign archive changes nothing
Taking the "A" out of PACS is merely a shift in connectivity to the long-term storage solution. There is no reduction in PACS functionality. The PACS still has to support the "archive" application, even if the data are transferred to a foreign archive. Therefore, the vendor claims this is not an argument for a reduction in the price of the core R-PACS 2.0 application suite. Indeed, this has been the case in the market to date. Adding a replacement R-PACS 2.0 to an existing VNA environment does not effectively reduce the quoted cost of the PACS (software license, professional services, and maintenance).
Myth No. 6: If you think you need a VNA, we have a VNA
For years, the PACS vendors fought the VNA concept. Now, virtually overnight, many PACS vendors have a VNA. There is obviously a semantics issue at play here. A name change ordered by marketing does not a VNA make. The "archive" component of an R-PACS 2.0 extracted from the core PACS, as opposed to a completely ground-up development, is merely an enterprise archive (or "bit bucket") at best. An extracted R-PACS 2.0 archive that is now shared between the vendor's radiology and cardiology core PACS solutions and does not truly interoperate with any other vendor's core PACS solutions is also merely an enterprise archive.
VNA is not a 'bit bucket'
In the PACS mindset, the VNA is simply a termination place for data. A VNA, however, is not merely a big bucket of DICOM data stored in a proprietary format. In reality, a true VNA adds a layer of workflow and interoperability to the management of all enterprise data. PACS vendors design their systems to work best with their own solutions. Ensuring their solutions work well with other vendors, especially other PACS competitors, is not a priority.
Most VNAs introduced by PACS vendors are simply enterprise archives stood up separately from the core PACS. They do not treat the image data acquired from other disparate PACS the same as their own data. The enterprise archive typically does not support the same level of access to this "foreign" data and the requisite format translations typically hinder the speed at which this class of data can be delivered to external systems. As a consequence, the other systems are required to manage a large working cache of this class of studies to enable proper performance, basically negating the benefit of the VNA.
Beware the bolt-on
The common PACS vendor strategy for addressing missing features is to "bolt on" third-party applications to the core PACS via API toolkits. For example, there are numerous third-party diagnostic applications on the market that would make excellent complements to current-generation R-PACS unable to meet these requirements. Unfortunately, the PACS vendor will only approve of the third-party applications if they are connected through the core PACS. The process of accessing each application, however, is arduous and lengthy. The third-party application is launched via workflow that requires study selection be made through the core PACS worklist. Software and connectivity issues aside, this strategy obviously keeps the core PACS at the center of department operations and the PACS vendor clearly in charge.
Another bolt-on for many current-generation R-PACS is the zero or near-zero multiplatform viewer with server-side (as opposed to client-side) rendering. Unfortunately, this upgrade was a matter of expediency to meet the demands of referring physicians for a multiplatform and better-performing clinical viewer. It takes time and attention to detail to develop this class of display application in-house, so many of the PACS vendors simply looked to OEM partners to provide this tool.
Figure 2.Figure 2 illustrates that many of the advanced application requirements, including the new generation mobile clinical viewer, are actually satisfied by interfacing third-party applications to the core R-PACS. Users must navigate the menu tree of the R-PACS to get to these advanced applications, and the source of the images remains the core R-PACS, even if this configuration is deployed in a VNA environment. Third-party applications are "second-class citizens" to the R-PACS, producing poorer performance and limited access. A major flaw in this system architecture is that the R-PACS remains at the center of department operations and therefore continues to exert its idiosyncrasies over workflow.
In the next part of this series, I will focus on the impact of vendor-neutral archives and universal viewers on the current paradigm and examine the opportunities for embracing these technological advancements.
Michael Gray is the principal of Gray Consulting, a consulting practice established in 1991 that has provided services to more than 100 healthcare organizations. Mike's areas of expertise include radiology and cardiology PACS, vendor-neutral archives, and clinical viewers that image-enable the EMR. He routinely publishes articles on his weblog at www.graycons.com. Mike has a bachelor's degree in biology and chemistry from Washington University in St. Louis. He has been awarded three U.S. patents and has an extensive bibliography in medical image display and electronic information management systems. Mike and his family reside in Novato, CA.
The comments and observations expressed herein are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
