Top Ten Considerations for VNA Implementation, Part 1 | Novarad

Top Ten Considerations for VNA Implementation, Part 1

The majority of US-based healthcare facilities are either considering or implementing the consolidation of their medical image archiving in the form of a Vendor Neutral Archive (VNA). Early experiences have taught that it is not trivial to select the right VNA, and have revealed several pitfalls during the implementation phase. This series of two articles lists the top ten considerations for VNA selection and implementation.

Implementing a Vendor Neutral Archive (VNA) for the Right Reason

Make sure you implement a VNA for the right reason. In other words, you should have a good idea of why you want a VNA to start with.

The initial motivation for VNA purchases was in most cases to eliminate the “pain” of having to migrate images every time one changes PACS vendors, which can be costly, labor intensive and time-consuming, often taking more than a year to get them all moved to the new PACS system. Over the past several years, the migration argument has become less important as other benefits emerged, in particular the capability of having patient-centric access to images, i.e. getting the complete set of studies, independent of whether or not a different specialty or department produced them.

An additional advantage of a VNA is that it provides a convenient “gateway” for a universal viewer, often integrated with an EMR. A physician can review the patient history and reports, and simply click on an icon if there is an image available, and it will show up in the EMR portal. The VNA is also ideally suited to serving multiple institutions needing to share and access images on an enterprise level. There have been successful implementations of a VNA to cover all the hospitals in a single state or province such as is the case in Canada–or to span multiple states for a large group of hospitals.

A VNA can also serve as a gateway to an external registry, which can be a private or public HIE (Health Information Exchange). When the images are registered using standard protocols as defined by IHE (Integrating the Healthcare Enterprise), any authorized party may access these registries to locate and retrieve the images.

A key reason to use a VNA is the need to store non-DICOM objects such as JPEG’s, documents, video clips, waveforms (EKG’s) etc. The latter is somewhat controversial as there are two schools of thought; the first one states everything should be “DICOMized,” which means encapsulated with a DICOM wrapper or metadata. The other school of thought is that one can submit the document or object with sufficient meta-data as defined by the XDS standard so it can be managed; however, the object itself is not “self-contained,” as the metadata will be stored in the database and not part of the object. For that reason, some institutions have decided to manage non-DICOM objects in a separate document management system and not include it in their VNA.

According to Harold Welch, the vice president of technical solutions at Novarad, another aspect of this is the rapid IT developments of the past several years. “Because of that advancing technology, with the implementation of the EMR and standards compliance, the industry has realized that the old systems of keeping track of data aren’t sufficient,” Welch said. “In order to provide patient-centric care, the medical record needs to have all information, consistent across the board and accessible to anyone in the care continuum who might need access to it. The best way to achieve that is by implementing a VNA.”

One can also use the VNA to “clean up” the metadata, which is important if the sources are not consistent with regard to their study, series descriptions and body part identifiers, which are referred to as “tag morphing.”
Also, take a minute for some self-reflection; if you are implementing a VNA “just because,” you shouldn’t. You can save a lot of money and effort by doing what you do today–assuming it meets your requirements.

The Right Approach

There are two different approaches for implementing a VNA. The first one is top-down, i.e. one installs the VNA hardware and software, which could be from a vendor other than your current PACS vendor(s), and connect the various image sources. The second approach is bottom-up, by expanding an existing PACS archive and adding the functionality to make it into a VNA.

The approach often depends on the scope or range of the image archive consolidation. Five different VNA classifications can help determine the correct strategy.

Departmental Vendor Neutral Archive (VNA)

This is the scenario when there is only a single department feeding the images into the VNA. The images and other objects (reports, documents, JPEG’s, possibly waveforms) are all in a DICOM format and the main reason for implementing a VNA would be its “neutrality,” i.e. to facilitate future migrations and possibly to function as a portal to an EMR. An important feature is the automated synchronization of any changes that occur in the PACS and its subsequent changes in the VNA.

Multi-departmental Vendor Neutral Archive (VNA)

In this case, there could be multiple departments feeding the VNA. The VNA must ensure that key identifiers are cross-referenced or made unique by adding prefixes to indicate their source–in particular non-unique Accession Number and Patient Identifiers.

Multi-specialty Vendor Neutral Archive (VNA)

The difference between this implementation and the multi-departmental version is that specialties such as ophthalmology, dermatology, endoscopy, and others have different workflows (encounter-based vs order-based) and often deal with non-DICOM objects such as PDF’s, JPEG’s, video clips, etc. The latter means that there is a need to support the XDS protocol for data submission and retrieval.

Enterprise Vendor Neutral Archive (VNA)

In this case, the VNA covers multiple sites, e.g. 1-15, which is typical for covering a metropolitan area by a small-scale IDN, a province in Canada or region in the UK, or a VISN by the US Veteran’s affairs. In this scenario, tag morphing becomes essential, and if the architecture includes a HIE, the VNA should support XDS and supporting PIX/PDQ profiles defined by IHE.

Corporate Vendor Neutral Archive (VNA)

In this case, all of the images from a major healthcare consortium such as Kaiser, HCA, Tenet and others are consolidated in a central location. One could consider this as having one’s own “cloud-solution.” High availability, scalability and redundancy are required features. Security is also critical, as there is a higher risk for hacking resulting from many more potential data access points. One consortium is actually starting to encrypt all data on their VNA because of the increased security exposure.

For a departmental, multi-departmental and specialty use case, a bottom-up approach might be feasible, i.e. adding slowly more features. For the enterprise and corporate VNA implementations, a top-down strategy is more effective.

Considering Workflow

There are several groups of professionals involved with image capture and review processes for whom the PACS/VNA/RIS/EMR architecture must provide an efficient and effective workflow.

Technologists

Note that this is applicable for radiological technologists as well as for physicians who might be performing the imaging studies. A worklist has to be available at the modality that shows all studies to be performed for that specific modality (except if you use a “pool” of modalities such as multiple ultrasound rooms, which are to be used on a first-come-first-served basis).

After the patient to be imaged is selected from the Modality Worklist, and the images are sent to the PACS/VNA, the technologist will perform a QA check. After that, one would “complete” the study, which can be done at the PACS, RIS, or, in this case, automated, as it might be a good opportunity to revisit the widely implemented but sparsely used MPPS (Modality Performed Procedure Step), which will do an auto-complete at the modality. There are different workflows depending on the modality, whether priors have to be pulled or imported from CD (or, in rare cases films to be scanned in), MPR’s and/or 3-D’s to be created, documents to be scanned, etc.

Radiologists and Cardiologists

In most cases, there will be a PACS that functions as a short-term storage and provides a workstation worklist which, depending on the radiologist profile and preferences, will provide a list of studies to be reported depending on his or her specialty (e.g. for a neuro-radiologist who does all head and spine studies).

In the case where there is no PACS, the VNA will be the source of the studies to be read, typically going through a third party worklist/workflow provider. When to make images available to the PACS and/or VNA depends on who needs to access the images and when they will need them. One could send images to the PACS and VNA at the same time, or to the PACS first, and then after a report is created, send the images to the VNA, or only send to the VNA a few hours after arrival at the PACS in case there might have been changes and updates to the images. In many cases, sophisticated routing is needed, which, if missing from the VNA functionality, might need to be purchased from a third party vendor.

Physicians

Depending on when they need access, the workflow needs to support the image availability. An ER and ICU physician needs immediate access, a referring physician needs access as soon as or just prior to the patient coming back from the imaging department, a primary care physician might not need it until the next appointment.

PACS Administrators

PACS administrators are typically only involved when there are exception cases, such as when images are misidentified, lost, or are unavailable due to another issue. The automated synchronization of any changes between a PACS and VNA is critical, otherwise a VNA implementation might double the workload for these professionals.
The good news is that there are now more options for physicians to optimize their workflows. In the past, one could determine whether the worklist was “PACS-driven” or “RIS-driven.” The RIS, in many cases, have become obsolete and replaced by the EMR and/or CPOE functionality, and now it becomes a choice between “PACS-driven,” “VNA-driven,” or in the case of the referring physicians and specialists, “EMR-driven.”

Ensuring the VNA Fits Your Image Exchange Strategy

Make sure the VNA implementation fits in your image exchange strategy. An excellent source for your image exchange strategy is the set of white papers on this subject created by the joint HIMSS-SIIM working group on enterprise imaging. If you look at this publication, you will see that the VNA is at the core of their platform definition, even though it is referred to as an “Enterprise Image Repository, combined with an interface engine and modality worklist services.” In this definition, the modality worklist services are provided by the workflow manager for the technologist workflow as described under workflow considerations above.

The mentioned interface engine is also a critical component, which could be included in the VNA–several of them do this. Most interface engines are designed to map information contained in the HL7 transactions that are relevant to use cases such as patient registration, scheduling, orders, updates, merges and changes, and results or reports.

Unfortunately, almost none of the HL7 interfaces are identical. In addition, there are at least four different versions widely implemented–2.2, 2.3.1, 2.4 and 2.5–each with a slightly different definition and location where important attributes might be stored. For example, the patient ID’s (primary ID, SSN, MRN, etc.) might be in one of three locations in version 2.2, while they are included in one single field location in a list format from 2.3.1 on.

Another important contribution of these HIMSS-SIIM white papers is that they distinguish the various images depending on their “intent.” In addition to the imaging for diagnostic purposes to confirm a suspicion, there are three other categories. These categories include the following: procedural imaging, used for guiding during surgery or stent placement; evidence imaging to document, for example, facial injuries or as a result of a colonoscopy; and image base clinical reports such as those used for bone densitometry.

A critical component of image sharing is also analytics, which can be derived from the data through deep learning to provide potential decision support. The image sharing discussion also lists the governance, which is often overlooked–especially when a VNA is used as an enterprise or corporate solution, there could be questions about who can access the data, how to deal with consents, and who is responsible for managing and supporting the hardware and software.

Attending to the Database and Storage Architecture

PACS systems are typically characterized by closed database architecture. In many cases, a vendor does not allow access to the database on a SQL level (assuming it has a SQL database as most of the PACS systems do) for simple queries, updates and deletions. Even fewer vendors allow tables to be changed in the database. If you don’t know the database structure, it is difficult to access, even for simple data mining or statistics. In fact, some institutions just route the images to a different database and take whatever they want from the DICOM metadata and use this “data-warehouse” as a source for their statistical analysis and decision support.

For VNAs this is a different story. First of all, they typically don’t treat their database scheme as intellectual property but make it available to the end user. Second, they open up the database back-end so that it can be managed by the end-user IT department. In addition to the image database access method and capabilities, it is also important to determine the database type.

There are three types of database architectures used for medical imaging. The hierarchical, which is common for the first generation of databases, has been a model for the DICOM database query language. If a modality wants to perform a query for a patient’s set of images, it always needs to access it through the top-down hierarchical Patient-Study-Series-Image query. It is not as efficient but it is robust and works well and it isolates the user from needing to know the database table structure of the PACS vendor.

If you like to do a more sophisticated query such as “find all studies that were done at a certain time, or by modality CT and MR for the patient ‘Smith’ and ‘Smit’ etc.” you could do that using the second or relational database architecture. One could use a relational query with DICOM, which is very rarely, if at all implemented. That is the reason that every PACS system has a direct, proprietary database interface between workstations and the PACS using the relational database.

The third database architecture is the object-based database which can be very efficient if used in addition to a search engine based method, especially if the data is of poor quality and sometimes requires “fuzzy matching” such as the case for patient demographics.

With regard to the storage architecture, there are three methods to store the data–either on a block base typically using a SCSI or fiber channel interface, a file-based interface using for example NFS or an object-based interface. There are several advantages when using this “object store.” Each image and/or document—whether it is encoded as a DICOM object or in another format such as a JPEG—is identified with a unique object identifier. This identifier allows for duplication for the purpose of redundancy, scalability and performance. Imagine retrieving your email from a Gmail account, for example. You really don’t know where it is stored, but there is universal access, redundancy and performance built into the email access. An object store could provide the same features as its object identifier can be treated as a unique record locater (URI) which again can be accessed from any network access point, and provides this scalability and redundancy. As the industry is moving to object-based databases and away from the block to file and object storage solutions, one should consider this when selecting a VNA.

These first five considerations are important when selecting and/or implementing a VNA. In the next part, we will focus on the remaining five considerations: determining if you need any additional building blocks, paying attention to synchronization of the data and normalizing it, including different workflows (order-based vs encounter-based), checking the support for open standards, and selecting the right vendor.

Click Here-Part 2

 

Herman Oosterwijk is president of OTech Inc., and is a healthcare imaging and IT trainer/consultant specializing in PACS, DICOM and HL7. Mr. Oosterwijk authored this article on behalf of Novarad Corporation, in order to promote awareness and knowledge of Enterprise Imaging and Vendor Neutral Archive (VNA).

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Name *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Hello, I'm Kristi!

I am the Editor for the Novarad Newsletter, curating and creating

great articles, whitepapers, case studies, and more!

Get these in your inbox monthly

15585

Receive Whitepapers, Case Studies, and Market Insights...

Stay up-to-date with all the latest trends in Enterprise Imaging

 

15856