A Framework to Aid VNA Implementation

As imaging data throughout the enterprise grows, so does the need for a vendor neutral archive (VNA) for more cost-effective storage. Selecting and implementing a VNA can be daunting. First requirements must be defined, and then vendor claims need to be assessed to achieve a good match. Although this can be challenging, finding ways to simplify and refine the process can be rewarding. A workable framework could help better define requirements and assess alternatives.

Framework objectives include:

• Improving the ability to more thoroughly define VNA requirements;
• Enhancing the mechanism for assessinga vendor’s match to a site’s requirements;
• Providing a set of common definitions of VNA functionality; and
• Encouraging users and vendors to use the framework.

Framework Proposal

This article proposes a workable VNA framework by identifying VNA elements and testing them with VNA vendors and users for substantiation. Starting with the constitution and delivery of services, a draft framework was circulated among a number of vendors and users for comment. Figure 1 illustrates the framework. An explanation of the framework parameters and examples of using the framework follows.

Figure 1.

The primary core of a VNA is a services layer that manages storing and accessing variable content hosted on various computer storage infrastructures, and accessed by viewing applications. There are various approaches to acquiring the technology, including capital and operational models.

Axis definitions are summarized as follows:

Services: Services represent the system processes for anaging content and infrastructure. Vendors themselves may provide services, or resell the services of others. Services definitions are as follows:

System Monitor: Monitoring services monitor system operation, notify of impending problems, and perform system auditing and reporting.

Data Integrity: Data integrity assures data is stored correctly.

Image Life Cycle Management (ILM): ILM rule sets manage how long data is stored to satisfy the legal retention period, as well as retention of minors, mammography, and environmental studies.

Workflow: Workflow rules address access rights and pre-fetching rules. Application workflows address how patient demographics are matched to images.

Clinical Abstraction: Data from multiple sources may require manipulation for storage. For example, some systems may include proprietary data sets that the VNA will need to handle as part of storing the data, enabling data that is accessible from the VNA without being tied to the originating device.

Data Migration: The ability to handle how data is converted, either into the VNA or exported to another environment, is an important aspect of a VNA Service.

Content: The Content axis addresses the extent of content managed by the VNA. Departmental solutions require only DICOM images, whereas enterprise-scale solutions may address non-DICOM and other industry standad formats (JPG, TIF, BMP, MINT, etc.) as well. In multiple entity environments, support for the cross-enterprise document sharing of images (XDS-i) and cross-enterprise sharing of documents (XDS), Integrating the Healthcare Enterprise (IHE) profiles, and health information exchange (HIE) standards may be necessary.

Infrastructure: The Infrastructure axis represents a range of equipment environments. The simplest is a software-only solution, while others may address both a software and hardware (turnkey) solution. Hardware can be physical or virtual, more sophisticated applications may be replicated or redundant hardware. Cloud-based services are growing in importance, and may include private and public clouds.

Accessibility: Independent access to stored content can make it accessible to a number of different users for multiple viewing purposes. Access independent of the originating system is important when the originating system is not available. New applications such as advanced visualization might access images from a VNA instead of an existing PACS. There can be diagnostic applications, clinical viewing, or universal image access such as through a linkage to the EMR. Mobility is increasing through “zero footprint” viewers that can be launched from a number of portable devices such as tablets or smart phones. Adding viewing capability to facility Web portals for access by either clinicians or patients will expand clinical content accessibility.

Total Cost of Ownership (TCO): TCO addresses options for financing and operating a VNA. Local applications on existing hardware favor a capital approach. There may be associated setup or professional services fees. Alternatively, the fee-for-service model is popular, either as a cost per study, or a cost per amount of information stored (gigabyte or terabyte). Some services only charge an “ingestion” fee, while others have additional fees for long term storage. Subscription fee models essentially level-load charges over a fixed period (monthly) for an estimated volume level. Fees may vary month-to-month if volume varies.

The axes form a shape (pentagon), and the area within the shape can be used to visually represent and contrast VNA scenarios. For example, applications can be differentiated by how much of each axis is shaded. Colors can represent such parameters as internally developed versus sourced applications.

Figure 2. Two different VNA applications are contrasted by the different area under the shape. Key: Green is internal content.

The first example in Figure 2 is a replacement archive in a single clinical service, for strictly DICOM data. It doesn’t need to address life cycle management, and it can span the full range of infrastructure. It is most likely is cost per study or subscription based pricing. If used for disaster recovery, no incremental display is necessary.

The second example represents an enterprise archive spanning multiple service areas. Support for cross-enterprise sharing might be important and rely on XDS content. Because it may span multiple entities and services, replicated or cloud infrastructure is preferred, separate EMR and/or portal viewing are important, and pricing is most likely a per-study or subscription basis.

Figure 3. The framework could be used to represent different VNA vendor segments. Key: Yellow is sourced content and green is internal content.

The first example in Figure 3 emphasizes a vendor who outsources services and display technology, and leverages its own infrastructure. The second example shows a vendor focused on providing the core VNA application as a software-only solution applied to a client’s infrastructure. Note the use of different colors to represent sourced versus internal content.

Real World Feedback

A theoretical model is one thing, but industry feedback improves the likelihood of acceptance and utilization. Initial contact with a number of VNA vendors provided them the opportunity to critique the framework. Figure 4 summarizes companies generous enough to provide feedback on the framework. The following summarizes vendor observations:

• Vendor discussions revealed no opposition to the framework, and vendors encouraged it as a means for improving market consistency of definition.
• Vendors confused “accessibility” to include areas such as user rights. This was clarified in the context of adding a “services” category for workflow, preserving the accessibility axis for visual access to stored content.
• Initial categories for infrastructure did not address virtualization. Changes were made to reflect either physical or virtual and replicated or redundant hardware configurations.
• Discussions were instrumental in adding work flow, and system monitoring to the services axis. A further segmentation was suggested between “system” services such as data integrity, and “clinical” services such as work flow.
• Pricing originally reflected only a capital versus a fee-for service model. Discussions differentiated fee-for-service model and subscription models. Vendors suggested adding a “professional services” category to reflect implementation expenses incurred for both capital and operational models.
• Portal viewers were seen differently from an EMR API, reflecting patient-based portals not directly associated with an EMR.

How did vendors feel about the value of the framework? Lenny Resnik, director of Enterprise Imaging and Information Systems, Agfa Healthcare, stated “The framework…will help providers carefully examine their needs and establish an overreaching strategy while accomplishing their individual goals in a way that will result in meeting their ultimate needs in the shortest timeframe and the lowest cost.” Jim Prekop, CEO of TeraMedica said, “The terminology usage of ‘VN A’…has grown significantly among healthcare providers and technology vendors. We applaud…the… real-world approach to objectively aligning specific customer needs (both today and tomorrow) with the optimal solution.” Bob Mack, director, US&C Business Management at Carestream, points out that “customers are still singularly based on individual components of a VNA…and not focused on the big picture. The framework helps focus on the big picture.” Shannon Werb, chief technology officer for Acuo Technologies feels “[the framework] provides bigger buckets/areas that people should be looking at when making VNA decisions.”

Figure 4. Vendors that provided feedback on the framework.

Overall, vendors felt the framework addressed the “bigger picture” of VNAs, which is beneficial to an enterprise-wide viewpoint. Consumers of VNA technology had similar sentiments, and raised implementation concerns. Phil Wasson, president and CEO/CIO, TriRivers Health Partners in Rockford, Ill., feels the “framework…really outlines the benefit of an independent vendor neutral archive very well.” He feels it is important that their VNA vendor “didn’t sell the other PACS components and only function on the archiving of PACS images and helping to manage the storage and workflow behind all of that.” Conversely, Richard Green, Clinical Imaging Enterprise Architect for Hospital Corporation of America (HCA), is “not so much concerned with vendor neutrality as with leveraging existing company relationships, and ensuring that their data is managed by an entity that is financially stable and able to support them.”

Christopher Roth, M.D., vice chair of radiology for information technology and clinical informatics, Duke University Medical Center feels that “it is important [for the VNA] not to be tied to a particular PACS” so the VNA can address the enterprise needs for storage and accessibility. Greg Pilat, system director of imaging services, Division of Clinical Transformation, Advocate Healthcare, raises concern with respect to implementing a VNA—the need for quality checks, metrics, and working definitions. Obviously, there are different facility motivators and factors for selecting a VNA that may present the need for additional framework elements.

Development of the model and securing real world feedback resulted in a realization that VNA vendors can be segmented as follows:

• The most common form of VNA vendor is the application provider. These vendors develop their own VNA service and content management applications. The vendors may offer software-only or complete turnkey solutions. Application provider vendors probably have the greatest degree of knowledge with respect to VNA applications, as they are responsible for the general capability that constitutes the VNA. Real-world examples include Acuo Technologies or TeraMedica.
• Typically an application provider does not have the infrastructure to support remote or cloud-based VNA applications. The infrastructure provider leverages existing infrastructure through partnerships with VNA Application Providers to provide cloud-based VNA applications. Most infrastructure providers leverage their infrastructure for many different applications, and may be attractive to facilities that have multiple applications or are attracted to a cloud-based environment. Real-world examples include DeepWell, Iron Mountain, or Logicalis, to mention a few.
• Integration providers have an infrastructure and a partnering relationship similar to an infrastructure provider, but go one step further to include integration services, or special customization of a VNA application with an HIE. An integration provider can be thought of as going beyond merely exploiting its infrastructure. Integration provider vendors include Dell and GNAX.

In summary, VNA’s are an effective way to address the burgeoning amount of clinical content that continues to grow in importance as EMRs evolve as part of meaningful use. Employing a framework to define the VNA may be a tool to optimize understanding of requirements and assess vendor capabilities. Segmentation can further assist in assuring that clinical requirements are properly met. CIOs may want to consider the proposed framework to further an understanding of VNAs and aide in effectively differentiating vendor VNA offerings. As noted with respect to implementation, the framework should be thought of as a “living” framework capable of being adapted to changing requirements.

Joseph L. Marion is principal, Healthcare Integration Strategies LLC, Waukesha, Wis.