Skip to content Skip to navigation

Framing the VNA

May 1, 2012
| Reprints
A framework can build consensus and avoid misunderstandings when implementing a VNA
Click To View Gallery

“When it rains, it pours,” or so goes the old saying about salt … and work!  I’ve been in one of those phases where everything hits at once – hence the hiatus in my blogs.  It seems as if imaging is beginning to get some renewed focus lately, and not a moment too soon given the prospect of some aspect of imaging reflected in Stage two of Meaningful Use!

With the greater emphasis on imaging, I thought it might be helpful to convey my thinking on a framework for addressing the requirements of a VNA (Vendor Neutral Archive).  As with most acronyms, there usually is a diverse opinion on their definition.  I would like to put forth the following framework as a basis for the consideration of a VNA. 


The framework graphs organizational focus against functional purpose, in an attempt to differentiate the particular needs, and potential emphasis of various vendors.  Organizationally, initiatives can be focused around the needs of a single service area such as radiology, and primarily driven by the clinical service area.  Alternatively, efforts may be driven by Information Technology (TI) departments as they look to rationalize their resources.  Functionally, initiatives can likewise be focused on the needs of a specific service area, or modality, and extend all the way to the enterprise spanning multiple service areas. 

To illustrate, consider two client situations I have recently been involved with.  In one situation, the initiative came from the clinical administration for radiology and cardiology services.  The service area recognized the need for additional capacity for expanding radiology and cardiology services.  In this particular situation these operations spanned multiple PACS vendors.  Functionally, the need was focused on DICOM-compliant modalities, and did not encompass any information that was not DICOM.  One could argue that given these requirements, this particular opportunity would fall in the lower left-hand quadrant of the framework. 

In the other client situation, the initiative came from IT services and emphasized multiple service areas that span both DICOM and non-DICOM objects, in an attempt to encompass imaging within an EMR.  The entity is part of a larger network of similar healthcare providers in the state, and thus expects to share data across entities.  In this instance, one could conclude that their requirements might fall in the upper right-hand quadrant of the framework. 

As a consultant to both groups, how would I approach the various VNA vendors and properly represent these two entirely different situations?  The framework provides me with a communication tool to make sure that I have consensus among the provider stakeholders.  It also enables me a means to properly convey the requirements to VNA vendors, as well as to contrast vendors in terms of their perceived capabilities.  This is a win-win situation. It avoids misconceptions about client intent, and provides the client with a means for understanding different VNA requirements.  It affords the opportunity for the client to broaden their horizons, such as in the case where a service area initiative may not be in synch with IT objectives.  It can likewise alert the vendor to how best to position them for a response.  Surely it would not be in the vendor’s interest to emphasize IT relationships when the initiative is solely that of a service area. 

If both prospects and vendors could agree to adhere to such a framework, it might help them to make more informed decisions about how to position an initiative from the prospect’s side, and how to position capabilities and strengths from the vendor’s side.  As one who has been on both the submitting and receiving end of vendor solicitations, I can tell you, it can save a lot of unnecessary effort on both sides if there is a common understanding from the beginning.

As usual, your thoughts are welcomed!



Hi Joe, great perspective. I think this allows both the customer and the vendor to best come to grips with the absolute requirements along which should allow for a more substantive response from the vendor. The response not only can be better positioned but also more concise reducing review cycles for the customer.

I might also add that as the vendor best understands the requirements they can prepare a response that factors that into the cost, both required and optional. Not only should this allow the customer to achieve the lowest cost to meet their requirements but also to prepare a proper cost analysis in an apples-to-apples comparison across the responses.

Currently on the vendor side I have to agree that concrete requirements are always appreciated.

Excellent points! I think the cost factor is a great one. It's always difficult getting to an "apples-to-apples" basis, and being able to well-define the requirements goes a long way toward aiding the vendors in pricing their response.

I'm glad to see that there are people out there in the industry that "get it." My intent with these blogs has been to raise awareness, so that more places can make informed decisions.

Having been on both sides myself, I can fully appreciate the value of reducing the "cycle" time for acquisition.

Thanks again for the perspective.

This is a nice simplification of a complex concept - intuitively understood by those of us fighting in the trenches but not so cleanly presented. Thanks.