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.
