Tuesday, April 11, 2017

Top Ten VNA Requirements

The term PACS VNA (Vendor Neutral Archive) has been loosely defined by different vendors and its functionality varies widely among providers. Early implementations have seen some good success stories but also, in several cases, caused confusion and initial frustrations and unmatched expectations. The list below concentrates on the key features that are necessary for a successful implementation. So, the VNA should:

1.    Facilitate enterprise archiving: Enterprise Archiving requires many different components, as a matter of fact, the joint SIIM/HIMMS working group has done a great job listing key components, including governance, a strategy definition, image and multimedia support, EHR integration and a viewer, but most importantly a platform definition, which can be provided by a VNA. The VNA needs to be the main enterprise image repository, which is the gateway to viewers and the EMR, taking in the information encoded as DICOM, as well as other formats, following the XDS (cross-enterprise document sharing) repository requirements. A true VNA needs to be able to provide that functionality.

2.    Facilitate cross-enterprise archiving: The VNA should be the gateway to the outside world for any imaging and image related documents. Examples of image related documents are obviously the imaging reports but also measurements (Structured Reports) and other supporting documentation, which can be scanned documents, or be in native digital formats. It also needs to be a gateway for external CD import and export, for portals, and the gateway to cloud sharing and archiving solutions.

3.    Support of non-DICOM objects (JPEG, MPEG, Waveforms). Even though DICOM has proven to be an excellent encapsulation of medical images and other objects, such as waveforms, PDF’s, documents, etc., there are cases where this is not as easy or possible. A use case for this is when one needs to archive a native MPEG video file from surgery or another specialty. As long as there is sufficient metadata to manage the object, this should be possible and be provided by the VNA.

4.    Be truly vendor neutral: Even if the VNA is from the same vendor as one or more of your PACS systems, its interface with any PACS system(s) should be open and non-proprietary. This is one of the most important requirements: plugging in a PACS to your VNA from another vendor should be very close to “plug-and-play.”

5.    Synchronize data with multiple archives: Lack of synchronization is probably the number one complaint that I hear from early implementers. To be fair to the VNA vendors, in many cases synchronization is lacking on the PACS side. Even if the VNA is able to facilitate the IOCM (Imaging Object Change Management) messages, which is basically a Key Image Note with the reason for changes (rejects, corrections for safety or quality reasons or worklist selection errors), if the PACS has no IOCM support, then you are left with manual corrections at multiple locations. At best, there should be some kind of web-based interface that allows a PACS administrator to make the changes. It might be possible to adjust the workflow, which could minimize corrections, for example, one institution does not send the copy to the VNA till one day after the images are acquired which means that the majority of the changes have been applied at the PACS, however, if the VNA is the main gateway for physician access, this is not feasible. Lack of this synchronization requires a PACS administrator to have to repeat the changes at different locations.

6.    Provide physician access: A key feature of the VNA is that it provides “patient-centered” image access, i.e. instead of a physician having to log into a radiology, cardiology, surgery or oncology PACS with different viewers using different log-ins, and disparate interfaces, there is now a single point of access. This access point is also used for the EMR plug-in, i.e. there should be an API that allows a physician to open up the images referred to in the EMR with a single click provided by the VNA. Note that accessing the data with a different viewer could create some training and support issues as the features and functions are most likely different from the PACS viewer.

7.    Take care of normalizing/specializing: As soon as images are shared between multiple departments and even enterprises, the lack of standardization becomes obvious with regard to Series and Studies Descriptions, procedure codes/descriptions, and body parts. The differences could be obvious, such as when using “skull” or “brain” for the same body part or subtle changes such as between “CT Head w/o contrast” and “CT HD without contrast.”  Any difference, even minor ones, could cause prior images to not be fetched for comparison. That is where, what is sometimes referred to as “tag morphing,” comes in, where the data is “normalized” according to a new set of descriptions and/or codes before it is archived in the VNA. When a specific PACS expects certain information to be encoded in a specific manner, the data has to be modified again to facilitate its local quirks, which I would call “specialization”.

8.    Handle multiple identities: Images will be presented to the VNA with local patient identifiers that need to be indexed and cross-referenced. The same applies to studies and orders. Most VNA’s can pre-fix an Accession Number to make it unique in the VNA domain and remove that prefix when sending the information back. This assumes that the Accession Numbers are not using the maximum allowed 16 byte length, otherwise it has to be dealt with in the database.

9.    Be the gateway to the outside world using open standards. Many states, regions, or, if small enough, countries, are rolling out a central registry (HIE or Health Information Exchange) so that an institution can register the presence of images and related information to anyone outside the enterprise who is authorized to access this information. The registration and also discovery uses the IHE defined protocols XDS while the PIX/PDQ standards take care of the patient cross referencing and query.

10. Meet your specific needs: More than 50 percent of US-based institutions are apparently installing or planning to install a VNA, according to a recent survey. I suspect that the main reason is that many are getting tired of yet another data migration, which is lengthy (months to years), and potentially costly in terms of both money and lost studies. The elimination of future migrations is somewhat of a moot point as PACS migration will likely be replaced with migrating the VNA, so it is kind of shifting but not eliminating this issue. The real reason for getting a VNA has to be some of the key features listed above. If on the other hand you have a relatively small institution, with only images created in radiology and possibly cardiology but not in any other specialty, and there is no immediate need for image exchange, then I would argue that you might be better off staying with the current PACS architecture as the business case for a VNA is not quite clear yet.

In conclusion, VNA’s are here to stay, assuming they have most, if not all, of the features listed above. However, it might not be for you, so you need to make a business case and look at the potential pro’s and con’s of getting a VNA. When you are thinking about getting a VNA, talk with your VNA and PACS vendor about the features listed above to make sure you understand the clinical, technical and personnel impact if your vendor does not support one or more of these features. By the way, we'll have a VNA seminar coming up, see details here.