In part 1 of this series, I shared some of the problems and "myths" associated with radiology PACS, also referred to as R-PACS 2.0. In this article, I discuss the impact of vendor-neutral archives (VNAs) and universal viewers (univiewers) on the current paradigm and examine the opportunities for embracing these technological advancements.
VNA supplies missing pieces
The paradigm shift in R-PACS architecture began with the concept of the vendor-neutral archive, first introduced in 2006. In an early blog entry on this subject, I referenced an article published in October 2006 by Nadim Daher, a medical imaging market analyst with Frost & Sullivan. There are numerous early articles and papers referenced in the Wikipedia entry on VNA.
The initial focus of the VNA concept was taking the "A" (archive functionality) out of the R-PACS and replacing it with an external PACS-neutral archive. There were numerous benefits envisioned for this concept, including the following:
Michael Gray of Gray Consulting.- Consolidating separate long-term storage solutions associated with multiple departmental PACS into a single enterprise storage solution
- Improving disaster recovery (DR) infrastructure, which frequently means replacing less-reliable near-term storage solutions with online spinning disk media
- Adding a business continuity (BC) component to the VNA that supports all PACS and enables the deployment of a BC component to the R-PACS (a fully functional second instance of the PACS application suite)
- Facilitating image data exchange between disparate departmental PACS by reconciling the idiosyncrasies in the DICOM header elements
- Eliminating future DICOM data migrations due to storage replacements, PACS upgrades, and migration between incumbent and replacement PACS by eliminating the need to move the entire dataset to the replacement PACS
- Eliminating future data migrations between an incumbent VNA and a replacement VNA by including in the VNA software package the GUI-based tools that would allow the user to accomplish any future migrations without professional services fees
- Simplifying and reducing the cost of periodic media migrations
- Adding centrally managed and intelligent metadata-driven information life-cycle management (ILM) to the long-term archiving operation
The above list of functionality is not all-inclusive, as many more useful features and methodologies have been added to the VNA requirement list over the past eight years. This list, however, conveys the key functions that remain largely missing from current-generation PACS to this day.
Univiewer expands the vision
The paradigm shift in R-PACS architecture continued into 2009 with the concept of image-enabling the electronic medical record (EMR) using a multidisciplined clinical viewer, referred to as a universal viewer or univiewer. This effort was principally motivated by the desire to achieve compliance with stage 2 of the federally mandated meaningful use initiative.
The initial focus of the univiewer concept was to take the modality-specific clinical viewer component out of the departmental PACS and expand its functionality to include the tools required to display any type of medical image. This would combine multiple, separate PACS-specific viewers into a single multimodality viewer, thus simplifying the interface to the EMR.
There were numerous benefits and characteristics envisioned for this concept:
- The ability to access and display in a consistent and highly performant manner radiology, cardiology, and essentially any DICOM image objects
- A methodology that provided integrated access to any of the patient's images (regardless of which imaging department produced those images), resulting in a unified presentation in a single viewing session
- Integrating via the EMR application programming interface (API), allowing the univiewer to aggregate all of the imaging studies associated with a patient, not just those available to the EMR
- Direct access to the univiewer for users who are authenticated through the local active directory (AD) or lightweight directory access protocol (LDAP)
- Introduction of a new display technology based on a zero or near-zero client paired with server-side rendering -- a technology that would provide superior performance over low-bandwidth networks and open accessibility to any OS, any browser, etc.
- A local working cache to prestage images from any PACS that is limited to DICOM data transfers, as opposed to the more efficient Web services that most VNAs support; of course this also implies support for one or more methodologies to keep the univiewer cache in sync with those contributing databases (ideally the univiewer would not have a cache and would only need to interoperate with the VNA to deliver images)
- Initially, only the basic image display features and functions would be provided, including those that the majority of referring physicians would need to manage patient care and meet meaningful use criteria
As expected with any display application, the issue of feature/function has undergone constant change. The basic features/functions of the traditional clinical viewer often do not satisfy the needs of true image users in the physician community. Ideally, the clinical viewer should provide display tools nearly identical to those available to the radiologists and cardiologists interpreting the studies.
Naturally there is considerable interest in how far univiewer vendors will expand their display technology. Figure 3 is a simple way of looking at image display applications. The line extending from "clinical" display applications to "diagnostic" display applications is somewhat of a continuum representing the ever-increasing demands of users for more and better tools.
Figure 3. All images courtesy of Michael Gray.
There are, of course, technology requirements associated with the more advanced tools required for diagnostic interpretation, but the hope is that zero or near-zero clients paired with server-side rendering technology can support all of the tools currently included in the most advanced diagnostic workstations used in imaging departments. Univiewers should be evaluated based on where they sit along this continuum, how far along the continuum toward "diagnostic" a vendor plans to take its product, and how soon.
The issue of non-DICOM
We have recently seen another shift in the R-PACS paradigm related to non-DICOM image objects. There is increasing interest in adding non-DICOM, nonimage objects to the VNA, such as PDF versions of reports (cardiology), administrative and clinical forms, and exam worksheets. PACS typically do not handle these object types very well, if at all, and EMRs may only handle a few of these object types. The VNA thus became the logical choice for managing these non-DICOM objects.
As more and more univiewers were deployed to image-enable the EMR, users became increasingly interested in accessing and viewing non-DICOM image and nonimage objects that are associated with an existing DICOM study and comprise the entire clinical study. An example of the latter is a collection of still-frame images and/or a video clip taken with a mobile device in a burn unit or a dermatology office.
Issues arose as to how to acquire these objects (interface options), how to manage them (object format), and how to display them in what was largely a DICOM-oriented display world. There are numerous approaches to acquisition, management, and display issues. Some approaches are proprietary and some are standards-based. The best approach today will depend on the data export options that are supported by the image source; the interface options that are supported by the various systems that will acquire, manage, and display the objects; and the display capabilities of the univiewer. No single approach in use today fits all of these variables. The future is somewhat clear, however.
A majority of PACS, VNA, and univiewer vendors have either already introduced or are working to develop a non-DICOM strategy based on a technology standard known as cross-enterprise document sharing for imaging (XDS-I) and more specifically XDS-I.b for use in acquiring, managing, and exchanging non-DICOM objects. An explanation of this technology is beyond the scope of this paper.
Online resources are a good place to begin learning about XDS technology and how it is deployed. The most important characteristic of XDS is that it is based on a standard, which somewhat guarantees a high degree of compatibility among the various systems in a multivendor environment.
Acquiring non-DICOM images from independent imaging sources such as endoscopy cameras and mobile devices is further complicated by the fact that metadata identifying the patient, the study, and the images has to be created and assembled and then tied to those images.
In many use cases, such as the acquisition of images in a burn unit, during a dermatology office visit, or during surgery, there is no formal order placed for the procedure. This complicates access to a patient's demographic information and the creation of an accession number for the study. Vendors investigating this issue are looking at ways to tap the EMR for some, if not all, of the metadata that can be passed to a simple application, which marries the image object to the required metadata and then forwards the study to the VNA or univiewer. In this sense, the VNA and the univiewer must take on yet another feature routinely performed in a PACS -- image acquisition and creation of a properly identified study object.
A shift in the VNA paradigm
Adding non-DICOM data to the VNA effectively demands a change to the initial design of the VNA, as it now has to be expanded/evolved to reveal the concept of a multiobject bus with plug-in applications. The plug-ins would include applications for handling DICOM objects, non-DICOM objects, XDS objects, document objects, and perhaps back-office applications.
In this sense, departmental/specialized PACS applications and the univiewer become plug-ins to the VNA image and object services bus. The long-term value of the investment in the VNA is the data and the tools to manage the data. The multiobject bus allows interoperability with the data by viewing applications, data mining services, storage platforms, and a host of other entities that will have multiple methods to interact with the data being managed by the VNA.
The image and object services bus is a specific example of a derivative of an enterprise service bus (ESB), described in a TechTarget posting as "software architecture for middleware that provides fundamental services for more complex architectures."
"In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end users via Web- or forms-based client-side front ends," the posting adds.
In the context of the VNA, the image and object services bus connects a wide variety of data sources with data users while hiding the complexity that may be inherent in the processes that are required to make those transfers seamless to users. The services bus facilitates information sharing across the enterprise with the many disparate information and image management solutions that physicians are using to access the information. This strategy obsoletes the idea of a monolithic, proprietary, departmental PACS purporting to be a VNA.
Figure 4.Figure 4 illustrates a VNA image and object services bus that is comprised of three layers:
- Access layer: Provides the various interface methodologies that are required to connect to the various imaging sources, the worklist application, multiple departmental PACS and specialty diagnostic applications, the univiewer, and the EMR
- Workflow layer: Comprised of the many feature and function applications that are internal to the VNA
- Store/archive layer: Comprised of the interfaces to the storage solutions and disaster recovery/business continuity components of the VNA configuration; the VNA services bus is the great facilitator that allows the VNA to acquire the data, store it, cleanse it, manage it, route it, migrate it, and add context to it
One of the highlights of the VNA services bus is the addition of non-DICOM data exchange interfaces based on medical imaging network transport (MINT) and Web access to DICOM objects using restful services (WADO-RS) to the common DICOM interfaces that are required by most current-generation PACS. These additional interfaces remove the DICOM overhead that is stifling data exchange rates to the point that DICOM-oriented applications must be configured with working caches to meet performance expectations.
In addition to the applications illustrated in figure 4, other important applications, which may plug into the access layer of the VNA image and object services bus, are listed below:
- Edge server/local cache server: Would be used for image acquisition and autorouting. Properly designed edge servers can be more proficient at image acquisition than the departmental PACS. They can immediately optimize the DICOM header for the intended target PACS, optimize network transfer by compressing the data using the compression syntax preferred by the target PACS, and perform the initial study reconciliation against the order. Specialized quality control would still be done at the target PACS. This is yet another feature of the current-generation PACS that arguably belongs with the VNA because of these and other inherent advantages.
- Analytics application suite: For business assessment, reporting, and data mining
- Document management system
- Back-office systems: Such as accounts payable and billing
Key aspects of the image and object services bus
The access layer abstracts the applications from owning and controlling the data and frees healthcare delivery organizations to decide which applications are required, when to replace them, and what to add. This strategy essentially ends the vendor lock that has been the hallmark of PACS vendors.
The clinical information life-cycle management application in the workflow layer includes retention/deletion, lossy compression, movement to less expensive/performant storage/cloud, and anonymization. The characteristics of each of the datasets produced by the health system are unique. Having one central interface to manage all the ILM policies is a tremendous benefit as opposed to having a multitude of systems where the various policies must be applied.
The storage layer, like the access layer, abstracts the data from the storage. Having the ability to add storage of a different type, manufacturer, or method to existing storage can be done without removing the existing storage. Replacing the existing storage can be done without impacting the applications that utilize the data. Adding services like cloud storage or backup tape libraries are done without impacting the applications.
PACS companies frequently charge significant fees to take the data out of the current storage, run it back through the application, and then archive it in the new storage platform. Healthcare systems often retain older storage platforms and pay higher support fees and higher costs associated with power and floor space due to the limitations of current strategies. Abstraction of the storage layer enables healthcare IT to make the decisions that are best for their organization as opposed to what is best for the PACS vendor.
The rationale for the concept of a VNA image and object services bus that accepts and services multiple application plug-ins is consistent with the early arguments for VNA. This version of the VNA consolidates all of the organization's data management infrastructure and storage solutions into a single enterprise class solution. It simplifies and consolidates system administration. It becomes the facilitator of interoperability and data exchange and is the enabler of the type of data mining that is critical to improving both business and healthcare. The VNA needs to be able to do more than simply store and manage all of this data generated across the enterprise. It needs to somehow be able to facilitate making sense of the data.
What's left for PACS?
Considering current-generation PACS and the components, features, and functions that have steadily been replaced over the past eight years, the VNA is positioned to replace the PACS archive and expand it for use across the healthcare enterprise. In addition, the univiewer is positioned to replace the PACS clinical viewer for integration with the EMR.
R-PACS functions have been reduced to the following short list of supporting tools:
- Specialized quality control
- Department workflow
- User worklist
- Diagnostic display/study interpretation
We have witnessed a consistent, deliberate, and step-by step dismemberment of the R-PACS 2.0 paradigm. These changes were borne out of a need to meet current and near-term requirements that have clearly not been met by R-PACS 2.0 and that cannot be met by the outdated underlying R-PACS 2.0 technology and design strategy.
Yet another shift in the VNA paradigm
We may very well be at the genesis of specialized apps that plug in to the image and object services bus. In use cases where the user's entry point is the EMR and the EMR is the worklist creator, the user could be taken directly to the display application that is most suitable for the user role/login and the type of object being accessed. The user would not have to go through the R-PACS application to get to one of these specialized apps.
In this scenario, the original URL call issued by the EMR would go instead to the VNA (not the univiewer) so that the VNA could invoke the logic that would determine the proper display application to launch. There are also specialized diagnostic applications such as nuclear medicine, oncology, and digital breast imaging that would no longer require a PACS but would leverage an application that has the specialized tools required for the discipline and would interact with the image and object services bus through one of many available methods.
The beginning of the end for R-PACS 2.0
Many of the features and functions formerly associated with a departmental PACS are no longer considered the responsibility of the core PACS application suite. They are now provided by the VNA and the univiewer, which are better suited to meet current user requirements. There are still unresolved issues and problems, however, with what remains of the R-PACS 2.0 generation of departmental PACS:
- Restriction to DICOM objects
- Restriction to Windows platforms for diagnostic display stations
- Requirement to move all of the study/image pixel data to the display platform, thus restricting the performance for at-home reading
- Inability to aggregate study awareness as well as data from across multiple, disparate departmental PACS
Simply put, there is a need for a new R-PACS paradigm, a completely new generation of R-PACS application that would fit seamlessly into the VNA and univiewer construct. In this sense, the tools used inside the imaging department simply become just another set of plug-ins to the images and object services bus of the VNA.
In the third part of this series, I will describe the PACS 3.0 concept and explore the benefits of making the switch to this new paradigm.
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.
