In part 2 of this series, I discussed the impact of vendor-neutral archives (VNAs) and universal viewers (univiewers) on the current paradigm of digital image management, along with opportunities for embracing these technological advancements. In this segment, I describe the PACS 3.0 concept and explore the benefits of making the switch to this new PACS model.
Defining PACS 3.0
In the new PACS paradigm, it is no longer appropriate to preface PACS with a department identifier. The new PACS paradigm applies equally to any department that creates medical images. At present, the PACS 3.0 market is clearly in the "innovators" stage of Geoffrey Moore's technology adoption curve.
Michael Gray of Gray Consulting.Several diagnostic radiology display applications are currently available to meet the criteria of a PACS 3.0 application suite by simply plugging into the VNA service bus. Some of these applications have been marketed as advanced diagnostic workstations that could be used to "upgrade" a current-generation PACS to postpone an outright PACS replacement. Some of these applications began as basic univiewers with feature/function sets pushed to the diagnostic level.
Regardless of the origin, these applications all share a very important technology component: They are based on a zero or near-zero client; they feature server-side rendering; and, in most cases, they utilize powerful new pixel-streaming methods for delivering the rendered image object to the user's desktop, laptop, or mobile device.
While specific features and functions vary greatly and some individual diagnostic display packages may not meet all the needs of a healthcare delivery organization (HDO), there are specific commonalities that distinguish PACS 3.0 applications from their radiology-oriented PACS (R-PACS) 2.0 predecessors:
- Ability to accept from the VNA and display both non-DICOM image and nonimage data objects, whether that means employing DICOM-wrapping or XDS. This would include accepting a study that is comprised solely of non-DICOM objects. Native object formats such as JPEG, TIFF, PDF, MPEG, etc., can be wrapped or accommodated within XDS. The key issue with respect to dealing with non-DICOM data objects is not the object format but the interface (data exchange) methodology that would be used by the acquisition system (PACS, VNA, etc.) to communicate with the non-DICOM data source device (PACS, workstation, modality, mobile device).
- Support for any hardware platform, any OS, and any browser -- it is the type of transaction that is critical, not the OS, hardware, or browser.
- Based on a zero or near-zero client and features server-side rendering with custom streaming and/or HTML data downloads to the client.
- Aggregation of study data across multiple, disparate departmental PACS and image repositories.
- Ability to support image acquisition and study quality control (QC) on their own but do not usually support the range of acquisition tools that are available on the more advanced implementations of VNA.
- Enables basic departmental workflow but lacks the range of features that are standard in packages from Clario, Medicalis, Primordial, etc.
What role can R-PACS 2.0 play in the new paradigm?
Although the archiving and clinical display applications associated with current-generation departmental PACS are not optimal, the core R-PACS 2.0 applications are still quite functional and can be integrated into the new paradigm framework.
The most important modification to a current-generation PACS, and one that is relatively easy to implement, is the addition of a software application that registers the knowledge of studies it has sent to the VNA. Some vendors call this functionality "store and forward" and others refer to it as "store and remember."
Supplementing the PACS archive function by implementing the software to interact with the VNA enables the core diagnostic display applications to efficiently exchange data. Other changes that need to be made to the existing R-PACS owned by the healthcare delivery organization include the following:
- End the vendor's control of the archived data and the physical storage solution by converting the R-PACS into a diagnostic radiology display application. This will enable the health system to either negotiate a much more favorable maintenance rate at renewal or to replace the system with a diagnostic display application that better matches its requirements. With a VNA already in place, there is no painful migration complicating the shutdown of one system and the go-live of a new one. In short, shut down the R-PACS 2.0 archive as soon as possible.
- Implement a univiewer that is owned and managed by the IT department and tightly interfaced to the EMR. This will provide a zero or very friendly lightweight, cacheless clinical display solution that will enhance the experience in the EMR.
- Begin to move other image databases into the VNA as requests for storage are being considered and the physicians begin demanding to see those images through the EMR. Take account of all the image-producing systems in the organization and bring them into a controlled, robust, and secure environment because few organizations realize how departmental imaging data are being stored, secured, and backed up.
An R-PACS 2.0 system upgraded with "store and remember" can operate as one of several display applications that are plugged into the VNA services bus. Even without this significant modification, the R-PACS 2.0 system could function as the core radiology PACS application that would be used to interpret routine study types, while third-party specialty applications would directly integrate to the services bus for more advanced study types.
Ideally, PACS vendors should make another modification to enable their R-PACS 2.0 systems to behave better with the VNA. This relatively simple modification involves the addition of a highly performing interface, such as Web services to allow the diagnostic display application to efficiently exchange data with the VNA without the need for a working cache. HL7 interfaces and workarounds exist to address the PACS-VNA synchronization issues, but elimination of the display cache eliminates the need to constantly sync the display cache with the VNA cache. The fewer databases managing the same objects, the better.
Similarly, specialized third-party diagnostic applications -- mammography, nuclear medicine, 3D -- can also become plug-ins to the VNA services bus (even if they are currently server-based, Web-delivered thin clients) if the server-based application supports a Web services interface.
Source of PACS 3.0 display applications
A small number of healthcare organizations have paired individual diagnostic display applications with the VNA, creating what is referred to in this article as a PACS 3.0 environment. Some of the display applications are thin clients and some are newer zero-clients. Only a few zero-client, server-side rendering display applications offer the range of features and functions that qualify as "diagnostic."
Where are these PACS 3.0 display applications likely to come from in the near future? The product development concept discussed in part 2 suggests that a number of vendors currently delivering univiewer applications will continue to develop display technology along the clinical to diagnostic spectrum. The zero-client, server-side rendering technology that is the fundamental core of PACS 3.0 is already here. It's the feature/function package that actually separates the basic clinical viewer from the diagnostic viewer. With the VNA doing all of the heavy lifting, this new generation of diagnostic display application paired with the VNA and a few other key subsystems (i.e., enterprise worklist) can certainly be considered a viable PACS replacement.
Transition to an enterprise worklist
An enterprise worklist application builds custom reading lists for individual physicians using information about the study, escalation rules, and physician preferences (i.e., the user's preferred PACS application). It supports the underlying technology/methodology for moving the study data to that diagnostic display application that best meets the assignment criteria.
For example, the selection of a nuclear cardiology study from the enterprise worklist would trigger the opening of the third-party nuclear cardiology application instead of the core radiology or cardiology diagnostic application. Enterprise worklist extends this concept across multiple departments with multiple PACS and multiple facilities.
Traditionally, the concept of worklist also encompasses what is generally referred to as workflow. Workflow and worklist encompass all of the features and functions of a departmental PACS that support image acquisition, study reconciliation, QA/QC, technologist notations, document scanning, study protocoling -- everything to prepare and present the new study for interpretation.
The concept of an enterprise workflow/worklist application encompasses all of the same features and functions, making the uniform set available to all of the imaging departments in the enterprise. Deploying an enterprise workflow/worklist application transfers yet another traditional function of the R-PACS 2.0 system to an external application that is another plug-in to the VNA services bus.
Figure 5. All images courtesy of Michael Gray.Figure 5 illustrates the concept of PACS 3.0. In this architecture, the VNA is at the center of data management and all various display applications. Imaging specialists access studies to be read from customized reading lists that are created by the enterprise worklist plug-in to the VNA. Referring physicians view studies using the univiewer application, either directly or from the EMR.
This diagram illustrates that the diagnostic radiology display application, whether it be an incumbent R-PACS 2.0 system or a server-side rendering PACS 3.0 application, is just another diagnostic display application plug-in to the VNA. The display plug-ins no longer "control" the image data. The VNA controls the image data and provides an entry point to the enterprise worklist.
Figure 6.In PACS 3.0, two options for image acquisition are illustrated in Figure 6. Image acquisition can continue to be managed by the core diagnostic display application/PACS. Alternatively, image acquisition can be managed by the workflow component of the VNA, which can be deployed as an edge server in remote facilities.
The latter approach offers several advantages. Configuring the VNA workflow application to be the recipient of new study data from the imaging modalities creates the opportunity to tag morph the incoming study and immediately apply a lossless compression scheme to the image data. This two-step process applied at the point of image acquisition would prepare the study to exactly match the requirements of the destination diagnostic display application and thereby improve overall system performance. The VNA workflow application supports DICOM modality worklist and XDS-I.b, or whatever other interface is required for non-DICOM image acquisition.
Once the new study data have been acquired and preprocessed, the VNA workflow application can then forward the new study data to the appropriate PACS or send a notification to the appropriate worklist application and/or diagnostic application that a new study is available on the VNA. Various QC options exist when image acquisitions are managed by the VNA, which will be explored in more depth at another time.
The enterprise worklist is tightly coupled with the VNA and receives all historical HL7 information along with new HL7 activity, informing it of all studies in the health system. Studies can be directed, along with priors and the appropriate medical record numbers (MRNs) to ensure proper display on the diagnostic application that will most likely be used to interpret the study. Again, various scenarios exist for routing new studies and relevant priors.
Determinant-based launch is key
Whether the enterprise worklist is the function of a freestanding application or a function of the organization's EMR, the key to making PACS 3.0 work seamlessly and efficiently for users is the concept of determinant-based launch (DBL). DBL is the feature of the enterprise worklist that launches the right diagnostic display application based on predefined determinants such as study descriptor, ICD-9 code, imaging department, facility identifier, physician profile, etc.
When the user selects a study from the enterprise worklist, DBL logic notes all of the various metadata details that describe the study and checks a series of internal specialty study descriptor codes for a match that will determine the most suitable diagnostic application that should be launched for that study. For example, if the study descriptor codes identify mammography and mammography-related ultrasound studies, the enterprise worklist would launch the appropriate mammography application.
An automated multiapplication enterprise worklist that determines the appropriate application to launch based on study parameters saves time. In a highly specialized radiology environment, manual selection of the most appropriate application from a worklist pull-down menu is an outdated paradigm.
The concept of DBL is the keystone of the enterprise worklist application, the application that unifies all enterprise imaging operations in a VNA-centric data management solution. The enterprise worklist with DBL technology is yet another application that can be more suitably performed outside of the conventional PACS 2.0 solution. The PACS 3.0 concept represents the step-by-step removal of traditional PACS applications including long-term data management, clinical viewing, specialty diagnostics, advanced visualization, workflow, and worklist.
Success requires a best-of-class mindset
Obviously, a move to the PACS 3.0 construct requires a best-of-class mentality. The VNA vendor must develop the tools and system support solutions that collectively provide the overall data flow and interoperability of the various application plug-ins for the VNA image and object services bus. Best-of-class should no longer be a cautionary strategy for healthcare delivery organizations, especially those with specialized imaging departments, because many traditional PACS 2.0 configurations have evolved to become best-of-class due to the various third-party applications that currently supplement departmental PACS.
Summary
We have witnessed a step-by step deconstruction of radiology PACS over the past few years as specific limitations of R-PACS 2.0 can now be more easily and less expensively addressed by outside applications. Although existing R-PACS architectures have remained relatively unchanged since their inception 10 years ago, radiology imaging and medical imaging have continued to evolve. These changes have resulted in a growing list of requirements that conventional radiology PACS has failed to meet.
The paradigm shift in R-PACS architecture began with the vendor-neutral archive, whose initial focus was taking the "A" out of PACS. Since then, we have witnessed the replacement of the PACS clinical viewer with the far more useful univiewer. As PACS vendors could not address new R-PACS requirements, such as advanced visualization, specialized imaging applications, discrepancy reporting, analytics, and multisite worklists, the quick fix was to simply bolt-on third-party applications to core R-PACS 2.0 solutions. This effectively created a best-of-class environment with a handful of applications that remained totally dependent on the core R-PACS 2.0 application, but without the benefit of a single service-level agreement.
Diagnostic display applications have remained as thick or thin clients that required the download of the full pixel set, and this has increasingly failed to meet performance criteria in the at-home reading environment. Perhaps the final blow to the outdated R-PACS 2.0 paradigm has been the requirement to add non-DICOM images and other digital assets to the patient's longitudinal medical record. R-PACS 2.0 solutions cannot adequately meet these increasingly common requirements.
This series has described a major paradigm shift toward an enterprise approach to information access. PACS 3.0 places a true VNA at the center of enterprise document and imaging operations. VNA workflow applications can interface to imaging devices, acquire images, and prepare them for future interpretation. The VNA image and object services bus is a variation on the generic concept of the enterprise service bus into which all applications that operate on data simply plug in. VNA applications such as tag morphing, information life-cycle management, univiewers, and diagnostic display applications are plug-ins to this bus.
The recent appearance of an enterprise worklist featuring a DBL application completes the PACS 3.0 paradigm. In this case, the worklist becomes yet another plug-in to the VNA bus and selects the appropriate display application. PACS 3.0 is the ultimate best-of-class model for data management, enterprise display, and diagnostic interpretation. While there is a role for the incumbent R-PACS 2.0 in this configuration, the new generation of diagnostic applications based on zero or near-zero clients and server-side rendering are far more performance-oriented than their fat-client cousins. The end of the R-PACS 2.0 paradigm has begun.
Recommendations for moving forward
This article presents a call to action through a compelling view of how departmental PACS and enterprise imaging environments in general are changing. The changes are a result of recognition that data produced by each imaging department should be managed and leveraged as both an asset and a liability, along with a growing requirement to make the data universally available throughout the enterprise.
The ability to make these much-needed changes is enabled through the introduction of new technologies and applications designed to integrate efficiently and work together to improve workflow and access to the patient's complete medical record. The organization is encouraged to take a serious look at its existing imaging infrastructure and determine whether the current solution is viable in light of the changing requirements, tools, and strategies described here. Beyond the responsibility to investigate whether the current solution is viable, healthcare delivery organizations should ensure that departmental plans are consistent with an enterprise approach.
Healthcare leaders must be bold about stopping requests for proposals (RFPs) for departmental solutions that include multiple archival components and focus on creating a PACS 3.0 platform that enables access to a complete patient record. The PACS 3.0 platform will ensure that data are secure in a robust and flexible configuration, that information life-cycle management (ILM) policies are enacted, and that the system provides a true business continuity solution.
Healthcare delivery organizations must determine how to execute a plan that marshals all clinical data across the enterprise, provides easier access, and ensures its near- and long-term viability. In most cases, the solution begins with the selection of the right vendor-neutral archive and development of an approach to wrest control of clinical content and storage from departmental system vendors.
The era of PACS 3.0 has begun. Healthcare organizations that take action today will avoid future expense and gain a competitive advantage in our challenging marketplace.
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.
