VNA’s: Match Capabilities to the Need

April 10, 2013
Understanding VNA objectives aids in knowing how to apply industry standards

Continuing with my series on deciphering Vendor Neutral Archives (VNA), this blog is focused on clarifying the confusion over what VNA’s actually can store, and how they differ in terms of storage.  All VNA’s are not created equal!  Prospective buyers need to understand their objectives for a VNA up front to insure that they are getting a solution that will meet all of their needs. 

Let’s begin by addressing the apparent confusion around the use of industry standards and how they relate to a VNA’s objectives.  Many vendors will speak to support of DICOM and XDS as if this is all one needs to know for a VNA to handle any object.  From my perspective, this is a case of comparing apples and oranges.

According to the DICOM brochure (http://medical.nema.org/dicom/geninfo/Brochure.pdf) DICOM is “designed to ensure the interoperability of systems used to Produce, Store, Display, Process, Send, Retrieve, Query or Print medical images and derived structured documents as well as to manage related workflow.”  It is largely a format for managing digital images, just as JPEG is a format for photographic images, and PDF is a format for cross-platform documents.  In other words, DICOM is one of many potential image/document formats that might be encountered in healthcare.

In addition to DICOM, there is an initiative on the part of a joint committee of the Radiological Society of North America (RSNA) and the Health Information Management and Systems Society (HIMSS) organized to “improve the way computer systems share information.”  This initiative has become known as Integrating the Healthcare Enterprise, or IHE (http://www.ihe.net/).  In the words of the IHE committee, “IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical need in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively.” 

The distinction between the DICOM and IHE initiatives is not inherently clear from these definitions!  In the case of DICOM, it is a format for information sharing.  Whereas the IHE initiative is protocols for how information should be shared.  IHE makes use of format standards such as DICOM and HL7, but in itself, it is not a data format.

One of the IHE profiles is known as XDS, or Cross-Enterprise Document Sharing.  In the words of the IHE, XDS “is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility and personal health record systems. This is managed through federated document repositories and a document registry to create a longitudinal record of information about a patient within a given clinical affinity domain.”  Again, XDS is a protocol for the communication of information, not a specific format. 

As an extension of XDS, the IHE initiative created the XDS-I profile for handling images.  XDS-I represents a means for handling medical images within the interoperability of the XDS profile for managing documents across an enterprise.  It allows for the handling of non-DICOM objects, but it does so within the structure of DICOM by “wrapping” an object within the DICOM format. 

Figure 1 is a functional diagram explaining the structure of XDS.  Two key elements of the XDS profile are the Document Registry and the Document Repository.  The registry keeps track of every object added into the repository, and the repository keeps track of where each object is stored.  This is important when there are multiple sources of input, such as in an HIE (Health Information Enterprise).  However, if there is only one entity with a common source of patient identification, such as in a large IDN (Integrated Delivery Network), a document registry may not be necessary.

Figure 1

What can one surmise from all of this relative to a VNA?

  1. It is important to understand the intent of a VNA – does it need to address a single healthcare entity, or multiple entities?  Multiple data objects or single data objects?  Etc.
  2. DICOM is a valuable image format for diagnostic images, but it may not cover all image objects to be managed.  It is important to determine if the intent of the VNA is to address only image services that produce DICOM images or other imaging services as well.
  3. IHE and XDS are valuable protocols for handling documents and images where there are multiple sources, but it may not be necessary where there is a single source.  There may be alternative protocols that can handle multiple object formats more efficiently.
  4. Based on a recent study (http://capsite.com/reports/), “74 percent of U.S. hospitals plan to purchase new Health Information Exchange solutions,” so even if a facility hasn’t considered it, it may be in their best interest to consider solutions such as XDS that can image-enable an HIE.
  5. Understanding the intended use scenario for a VNA is critical to deciphering the differences between vendor offerings, and which features are essential to the application.
  6. One other thing to keep in mind – XDS is in its infancy!  Therefore, not many existing applications are XDS compliant, so implementing a VNA around XDS may be problematic in interfacing existing systems.  On the other hand, I am reminded by one vendor that an XDS-enabled VNA can act as the “broker” for implementing XDS in the enterprise!

I hope bringing these distinctions to your attention will help those wrestling with whether to implement a VNA in your facility.  The concept is gaining momentum – particularly in an ARRA/MU world.  But it is critical that organizations have enough of an idea of their intent for a VNA to be able to navigate the vendor landscape for solutions that are the best fit for their requirements.

I encourage comments from implementers and vendors alike.

Sponsored Recommendations

A Cyber Shield for Healthcare: Exploring HHS's $1.3 Billion Security Initiative

Unlock the Future of Healthcare Cybersecurity with Erik Decker, Co-Chair of the HHS 405(d) workgroup! Don't miss this opportunity to gain invaluable knowledge from a seasoned ...

Enhancing Remote Radiology: How Zero Trust Access Revolutionizes Healthcare Connectivity

This content details how a cloud-enabled zero trust architecture ensures high performance, compliance, and scalability, overcoming the limitations of traditional VPN solutions...

Spotlight on Artificial Intelligence

Unlock the potential of AI in our latest series. Discover how AI is revolutionizing clinical decision support, improving workflow efficiency, and transforming medical documentation...

Beyond the VPN: Zero Trust Access for a Healthcare Hybrid Work Environment

This whitepaper explores how a cloud-enabled zero trust architecture ensures secure, least privileged access to applications, meeting regulatory requirements and enhancing user...