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.
