The Vendor Neutral Archive (VNA) was initially touted as the greatest thing since sliced bread. It offers no more data migration, the ability to manage your own data, and freedom from being held hostage by a PACS vendor with proprietary implementations of annotations, measurements, key images and non-standard compression algorithms of the image data. In addition, a VNA promises to be able to handle non-DICOM data, communicate with outside Health Information Exchanges (HIE’s) using standard protocols as defined by IHE and, last but not least, allows access to a uni-viewer through a standard interface.
But then, what happened? Reality struck and it appeared not to be as easy as people thought. Many users are going through some serious growing pains and are on the “bleeding edge” with early implementations. I gathered the top ten most commonly heard issues here so you might be prepared when you are ready to implement a VNA in your organization.
1. Not all VNA’s are equal: despite the fact that there has been an effort to categorize and label the different VNA’s according to the various level of implementations (see related article), this has not been universally accepted. I found several vendors at the latest RSNA meeting advertising that they have a “level 5” VNA, however, it appears that vendors do not like to advertise that they have a level 4, 3, 2 or even only 1. This seems to make sense as they would not want to advertise what they don’t have instead of what they do have. In any case, many institutions are struggling with a VNA that misses the functionality needed to allow it to work optimally due to the fact that they have been either improperly labeled or not labeled at all, creating unrealistic expectations.
2. Synchronization has become a major issue: this is related to the missing functionality as mentioned under item (1), i.e. the VNA doesn’t have the capability for a PACS to synchronize updates and changes with the VNA. In one particular example, the VNA has to be updated manually with all the changes that are made at the PACS. Imagine an image to be deleted, updated, or patient and/or study to be merged or split. A PACS administrator knows to do this on the PACS, but if he or she has to do this again on the VNA it might be forgotten completely, or not done in a timely fashion. This leads to the information being out of sync, and if these are critical updates such as names or Left/Right indicators, there is a potential safety and legal liability. IOCM (Imaging Object Change Management) support will go a long way to resolving this.
3. IOCM support is a requirement: IOCM is a standard that specifies how local changes that are applied to existing imaging objects can be communicated to other devices managing these objects. A PACS connected to a VNA is a good example of two of these systems. IOCM not only communicates rejection of the images due to quality or patient safety reasons, or incorrect patient selection resulting in misidentification, but also the expiration due to data retention requirements. Information is exchanged using rejection notes that are encoded as DICOM Key Object notes, thereby following existing mechanisms for encoding and communicating this information. Not every VNA supports this yet.
4. Tag morphing is not simple: tag morphing involves changing the image header to make a PACS and the workstation behave in a way to facilitate efficient workflow and preferences. There are typically two steps: the first one is “normalizing” the data upon entry or inbound channel in the VNA to fix any violations and/or standardize patient and related study information. The second step involves facilitating specific needs and peculiarities of a specific PACS system outbound. The most important tags to be changed relate to the decisions on what to prefetch as prior studies, and the ones configuring the proper hanging protocols. This is especially critical when using a VNA for multiple institutions, as the wide variety of non-standardized procedures, series descriptions and scan protocols will become obvious. That in addition to peculiar behavior of certain PACS workstations, makes proper tag morphing a challenge and might severely impact workflow. Hopefully with better PACS workstation implementations and further standardization of the header parameters such as the protocols and other information, this will become less of an issue.
5. Universal worklist is becoming a necessity: The universal or aggregate worklist provides a physician with a list of images to be read from different PACS systems. Realize that the connection between the PACS (or in some cases RIS) workflow manager and the vendor workstations is proprietary and very tight as the worklist manager needs to coordinate, for example, multiple readers all reading from the same list, which can be sorted by modality, body part, or other user preferences. This allows for synchronization, so that, for example, as soon as a chest radiologist picks a study to read, his colleague who reads the same specialty will see in his/her worklist that the study is already being read. On the other hand, they would not see the nuclear medicine or PET/CT exams as those might be reserved in another worklist for another physician to read. A VNA by contrast, allows access from multiple PACS systems, but there is no easy manner to synchronize this access between different radiologists. There is an existing DICOM workstation worklist standardization, but it is rarely implemented. Therefore using the VNA as a source for day-to-day reading is not quite yet possible.
6. Migration is not trivial: a typical scenario would be for an institution to purchase a VNA, migrate the bulk of the data from the existing PACS to the VNA, followed by replacement of the PACS, which is connected to the VNA with access all studies of let’s say older than 3 to 6 months. Depending on how “dirty” the initial data is, the number of studies that cannot be migrated ranges from 1-5 percent. It is not uncommon for a typical mid-size institution to have anywhere from 5,000 to 10,000 unreconciled studies as a result of the migration process. This will take a full-time person several months to resolve. This activity is often under estimated or forgotten. A good practice is to have a data analysis of your data done whereby a certain subset of your old PACS is evaluated for its “dirtyness” so you can plan accordingly. Most migration companies will provide this service as part of their migration contract.
7. Prefetching is hard: studies need to be retrieved from the VNA based on certain criteria, which are encoded in the header. Proper prefetching requires both allowing proper tag morphing to make sure the information is present to make the prefetch decisions AND having a set of sophisticated rules that can be programmed by a user. The prefetch rules depend on the modality, for example for mammography it might include a certain number of previous studies, which could depend on the user preferences. Rules also depend on body part, for example it does not make sense to prefetch a previous MRI of a knee to compare with a head CT, but it does apply to the head MRI. This assumes again that we have standard protocols and body descriptions because a routing engine might not know that a skull is the same as a head.
8. Report storage should not be forgotten: reports have always been kind of a stepchild but are very important, especially if there is no easy access to prior images, and if it has detailed quantitative information such as measurements used with ultrasound and cardiology. Some PACS systems store reports in the PACS archive, some rely on the RIS, some rely on the report server, and some have it stored in a broker. It makes sense to take these reports and migrate them and store them in the same study as the images, typically identified with a different series description. A potential solution would be to migrate them using a HL7 outbound interface and map them into a DICOM structured report. Again a non-trivial effort especially if the corresponding image study cannot always be easily identified because of mismatches.
9. Patient ID and accession number reconciliation is a must: it is not uncommon for a cardiology PACS to use a different patient ID than a radiology PACS, even within the same institution. If the VNA is used to serve multiple facilities, including outpatient clinics that might not be on the same registration system, it is a given that they are different and non-unique and reconciling these ID’s is needed. Therefore, some kind of Master Patient Index (MPI) functionality is needed, i.e. reconciling patients that have a different ID and assigning an internal unique number. The same applies for accession numbers as these are typically only unique based on a so-called “filler-order” number that is issued by a department scheduling system. Many PACS systems require unique accession numbers, therefore part of the normalization and/or tag morphing could include modifying these. A common fix for the accession number would be to prefix them with a two-character origination code, assuming that the original number does not exceed 14 characters (accession number maximum length is 16 characters).
10. Foreign exam management needs to be addressed: CD’s are typically imported locally into a PACS system, which assigns the correct patient ID, makes sure the patient information is consistent with the existing information in the local system, and preferably stores the change history in the DICOM header according to the IHE profile for information reconciliation. That study is then sent to the VNA, which applies its own normalization rules and tag morphing. It is easier and makes more sense to do the import/export directly in the VNA thereby bypassing this first step.
The issues listed above are the ones that have surfaced so far. I expect that as the VNA gains a more crucial role in image distribution, additional issues will come up with deploying uni-viewers, with implementing Health Information Exchanges, and connecting other “ologies” beyond the most common radiology and cardiology. As an example, most level 5 VNA implementations have provided a XDS-I image exchange capability, however, there have been very few “takers” to actually use this feature as image exchange is still very much done through cloud services and brokers instead. In any case, I suggest users and vendors first address the issues listed above and then take the next steps to further integration, and be prepared to address image exchange issues, as they will definitely arise.