This is the second part of two articles detailing the top ten considerations for Vendor Neutral Archive (VNA) selection and implementation. In the first part we discussed selecting a VNA for the right reason, picking the right approach (top-down or bottom-up), considering the workflow, ensuring it fits into your image exchange strategy, and paying attention to the database and storage architecture.
In this part, we will focus on determining whether you need any additional building blocks, paying attention to synchronization of the data and normalizing it, including different workflows, checking the support for open standards, and selecting the right vendor.
Determine What Other PACS Components You Might Need
There is a lot of discussion about “deconstructed PACS,” which simply means taking the current PACS apart and replacing it with off-the-shelf third party components. Implementing a VNA is a step in that direction, but one could just as well use a modality worklist provider from a different vendor, a workstation and workflow manager/universal worklist from yet another vendor and potentially supplement it with a router that has tag-morphing capabilities, along with an interface engine.
Note however, that this is not for the fainthearted; it requires significant internal resources, as you need to be your own system integrator, and need to be prepared to support troubleshooting, fixing, upgrading and maintaining the system yourself. You don’t need to go “all-the-way,” but you need to look at the missing functionality of your VNA and supplement it with any of these components.
With regard to the architecture, make sure you build in redundancy, high availability, and back up. Having two VNAs to duplicate the data in physically different locations is a good idea, as well as backing up on tape and/or in the cloud in case of a major disaster. It is imperative that the backup, wherever it is located, is monitored and validated on a regular basis. Switching over to a clean backup has inherent risks – if the data is compromised or out of date the risk are compounded.
Paying Attention to Synchronization and Normalization of Data
One of the most common complaints from PACS administrators supporting a VNA is the increased workload with regard to their “fix-ups.” Common reasons for these “fix-ups” include modifying the image information for deletion because the lifetime of the image might exceed the retention criteria (e.g. a study from a patient who has passed away, or exceeding the legally required retention time span which is typically 7 years), or if it is clinically insignificant (e.g. an image of a patient that has serious moving artifacts that have been replaced with a retake), or clinically incorrect (e.g. the incorrect left/right orientation). There are also cases where the images have been misidentified because a technologist has selected the incorrect patient from the worklist, or needs changes in the patient demographics in case an image comes from a different institution and is imported from a CD.
Other reasons for correction of the data could be missing information in the case of an emergency study of an unidentified patient, or incorrectly entered information at the modality due to the order entry system being down. The problem with these changes is that they have to be made at each location where a copy of the image resides, in this case at the PACS and VNA. There is a standard communication mechanism defined by IHE to communicate between the source and destination of these changes in the form of a so-called DICOM Key Object Note, which has a reference to the image(s) and the reason for the change. This mechanism is called the IOCM (Imaging Object Change Management) profile. Most VNAs support this capability, as do some PACS systems, but in practice, as many of the PACS systems are running one or two releases behind, most do not have that capability. Therefore, make sure that your system supports IOCM or if not, you have an upgrade plan, and an interim workaround solution.
The normalization of the data using Tag Morphing is important as well. As an example, if you want to pull prior studies for comparison for a head CT, you might need to search for “skull,” “brain,” “head,” “head-neck,” and multiple description variations in lower and uppercase. Tag Morphing will normalize these parameters, i.e. replace them with a standard term or, even better, pull them from a set of codes defined by DICOM and/or a well-managed code system such as SNOMED, so that they can be found and retrieved.
Including Different Workflows
In my discussions with VNA implementers, their number one issue seems to be facilitating the various workflows of the different specialties. The challenge is not within the traditional imaging departments such as radiology and cardiology as their workflow has been well documented and covered by IHE in the form of the so-called “scheduled workflow” profile, whereby an order is placed, a worklist is presented to the technologist, images are acquired, appear on the radiologist worklist, and a report is generated. There is also a well-documented “unscheduled workflow” use case, which is especially important for emergency cases as is common in cardiology, whereby standard transactions are used to update the patient information after the exam has been performed.
Both of these use cases fall under the category of “order-based” imaging workflow. However, these use cases do not fit the many non-radiology and cardiology specialties that want to use the VNA as their imaging repository. For example, an ER physician who wants to take a picture with his smart phone of a wound of a patient in the ER does not necessarily have access to a worklist to get the patient demographics. Imaging which is done outside the context of an ordered procedure is referred to as “encounter-based imaging.” It is not clear what the optimal manner is for matching up the images with the patient information, some institutions use a HL7 admission or registration message (ADT), some use a universal worklist created through a DICOMWeb implementation, which is still immature, others use a FHIR resource, and there are probably some more solutions.
The IHE committee is working on a new Encounter-Based Imaging Workflow Profile, which could specify how to integrate devices to capture appropriate context, link to related data, populate relevant indexing fields and ensure the images are accessible and well integrated with the medical record. In anticipation of the outcome of this activity, which may provide some guidance, one should plan right now the most effective solution for one’s environment.
Consolidating these specialty archives using these different workflows also has the potential to significantly reduce costs, according to Holly Rakovan, senior director of enterprise solutions at Novarad: “Most hospitals have other archives outside of imaging—for example, archives in wound care, ophthalmology etc.,” Rakovan said. “Each of these archives and manual workflows cost money to maintain and prevent images from being shared in a timely manner. With a VNA’s central archive and electronic workflows, disparate archives and manual processes can be eliminated.”
Ensuring the Vendor Neutral Archive (VNA) Supports Open Standards
Identical to a PACS system, ensure that the VNA supports the HL7 standard for incoming transactions regarding patient, order and results management and the DICOM standard for everything imaging related. Not only should it support the receiving and forwarding of the most recent DICOM image and image related object types but it should also support DICOM Storage Commitment to allow for safe hand-offs between the PACS and VNA and Instance Availability (IA) to provide information about the availability of the studies.
Both DICOM and HL7 are communication standards, defining the interface to the VNA. Unfortunately there is no archiving standard; therefore, a vendor can store an image in any format, which could cause an issue whenever migrating the data if that storage format is locked up with a proprietary patent for example. It is therefore good practice, especially if one claims to be “vendor-neutral,” to maintain the original pixel and metadata–DICOM header–and, even better, to encapsulate the DICOM file with a small meta-header that lists the encoding of the data (e.g. if it is compressed). This is to ensure that the object is self-contained, i.e. one would not need additional information to either migrate or interpret it, which is also known as the “DICOM Part-10” format.
The IHE standard for synchronizing the information with a PACS system for updates and changes regarding the images is already discussed above, i.e. IOCM, which should be a requirement as well. In case the VNA is accepting non-DICOM objects, the XDS standard for exchanging the data and for submitting the metadata is a requirement. For registering and querying an external registry such as HIE, one would require the support of PIX/PDQ, which are the IHE profiles defined for Patient Identifier Cross referencing and Patient Data Query. The XDS extension for imaging, called XDS-I provides the capability to exchange images across different enterprises.
Selecting the Right Vendor
With regard to vendor selection, make sure to perform due diligence, similar to when you purchased a PACS system. First, invest in a VNA for the right reasons, not because it is the latest fad. Check the IHE integration statements, which are all available on-line, for support of the IHE profiles mentioned previously. Select a vendor with an eye to the future as there are new developments on the horizon that could dramatically affect VNA implementations in the next few years. Among these are new modalities such as digital pathology, which could potentially affect the storage capacity needed by a factor of five to ten, which makes scalability a key requirement.
There is a lot of interest in FHIR, the new HL7 standard that uses web services to access resources such as patient information and results. Also consider the emerging DICOMWeb standard, initially defined for mobile access, which might become a big driver as it could become the predominant mode of access for physicians and the workflow especially for encounter-based imaging. Note that DICOMWeb is still immature and in the process of being standardized. Again, one must perform due diligence as one would with any major purchase. Remember as soon as a vendor is chosen, the healthcare facility is tied to that vendor for at least five to seven years. It is not like buying a car: there is no PACS trade-in possible after 6 months. A VNA purchase should fit into a long-term strategic plan, and the product should meet the requirements for now and the future.
In conclusion, implementing a VNA is not for the fainthearted–especially if one takes a top-down approach and is implementing a fully featured VNA, which transcends more than one department. The standards supporting the VNA are still emerging, notably the IOCM profile for synchronization, encounter-based workflow, XDS-I, HL7, and DICOM web services. However, one should not let this discourage or delay a VNA implementation. Simply be aware of the potential pitfalls, and make sure to select the right vendor as your partner on this journey.
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).