Month: February 2012

PACS / VNA Compatibility Issues

While much has been written and stated on behalf of the Vendor Neutral Archive being the ideal strategy for managing medical image data across the enterprise, little has been said about PACS Compatibility with the VNA Solution.

There’s a good deal more to this compatibility issue than the PACS being able to communicate with and exchange data with the VNA using DICOM.

Most department PACS, including Radiology and Cardiology solutions, were not designed to inter-operate with a foreign archive.  This is not to say that PACS systems were not designed to occasionally share study files with an external DICOM conformant system.  Most PACS can accomplish this using the DICOM communications protocol.  What I mean is that most PACS system designs are predicated on the assumption that the PACS will be the sole manager of the study data for the lifetime of the system.  And because of this design assumption, many of the current generation of department PACS are ill suited to the tasks required to fully inter-operate with a VNA.

Since most organizations probably did not include this compatibility issue in their PACS selection process, it may come as some surprise to learn that interfacing their existing PACS to a VNA is going to require solving a number of significant in-compatibility issues.

I thought it would be useful to present a summary of the more significant interoperability issues, because organizations need to be aware of the potential problems when they begin the process of planning for a VNA deployment.  The right VNA solution will have to be able to address these incompatibility issues.  It might also be prudent to consider these issues when planning for the next department PACS purchase, because sooner or later, odds are the organization is going to see value in data consolidation, and system interoperability.

Here is a list of the more critical PACS / VNA compatibility issues.

DICOM and IHE…The PACS should support a full suite of DICOM SOP Classes covering the full array of image objects that belong in the patient’s longitudinal record, not just those objects created in the imaging department.  This would include most of the DICOM Structured Report objects, image objects from Ophthalmology, Endoscopy, Pathology, and some of the non-image Cardiology objects like Waveforms and Hemodynamic data.  The PACS should also support image-related objects like Presentation States and Key Image Notes.  The system should also support a few key IHE profiles including Consistent Presentation of Images Profile, Presentation of Grouped Procedures Profile, Key Object Notes Profile, Simple Image and Numeric Reports Profile, and Transparent Query/Retrieve.

Foreign Study Support…The PACS should support the import and representation of Foreign Studies.  Ideally the PACS would directly accept from the VNA, studies originally acquired/processed by another (disparate) PACS or Image Source that are being managed by the VNA.  At the very least, the PACS would be able to receive from the VNA a non-billable order and use that order to aid in the acceptance of studies originally acquired/processed by another (disparate) PACS.

Store and Remember…The PACS should be able to “Store” (archive) DICOM objects originally acquired by itself to a foreign archive (VNA), and then “Remember” that the objects are stored on the VNA when the time comes to retrieve them.

Study Aggregation…The PACS should have the ability to automatically and pro-actively search for studies in the VNA that were originally acquired by another PACS and stored in the VNA (i.e. search the VNA for relevant priors originally acquired by another PACS).

HL7 Updates…the PACS should not only be able to accept HL7 updates from the local RIS or HIS and apply those updates to the metadata in the PACS that is associated with the image data the PACS is managing, but it should also be able to forward the same metadata updates to the VNA.

Object Versioning…The PACS should have the ability to forward to the VNA any updates or changes made to the study data (both pixel and meta data) after the initial “archiving” of the study data, effectively “re-archiving” the image or study.

Retention Messaging…The PACS should have the ability to accept and utilize the messaging from the VNA that is designed to communicate what image and study files have successfully been purged by the VNA’s Information Lifecycle Management (ILM) application.

The subject of PACS / VNA Messaging is actually the most critical of the PACS compatibility issues.  Perhaps one of the more challenging aspects of PACS / VNA interoperability is keeping the two disparate systems synchronized with each other.  Most but not all PACS accept and utilize HL7 updates from the HIS or RIS.  Many PACS do not have a reciprocal mechanism for updating a foreign archive (VNA) with changes that were made to metadata or pixel data in the PACS.

An even more challenging issue is presented by the advent of the purging mechanism that is supported by many VNA solutions.  This issue is referred to in the above list as Retention Messaging.  If a PACS is configured with a small local cache, and it is programmed to allow the oldest studies to fall off of that cache when the watermark is reached, how does it communicate to the VNA that it no longer has that study?  Correspondingly, if the VNA purges a study that has reached its retention limit, how does the VNA communicate to the PACS that the study no longer exists?

A number of the more advanced VNA solutions are attempting to resolve this “synchronization issue” through the use of a number of standard and not-so standard messaging techniques, because the VNA vendors recognize that few PACS vendors have considered VNA compatibility in their PACS designs and fewer still have implemented the appropriate IHE profiles.  Some of those solutions include:

  1. Private DICOM messaging
  2. Custom HL7 messaging
  3. The new IHE Profile called Imaging Object Change Management (IOCM), which is still in development

The Imaging Object Change Management Integration Profile will specify how one actor communicates local changes applied on existing imaging objects to other actors that manage copies of the modified imaging objects in their own local systems. The supported changes will include (1) object rejection due to quality or patient safety reasons, (2) correction of incorrect modality work list entry selection, and (3) expiration of objects due to data retention requirements. It will define how changes are to be captured and how to communicate these changes.

The successful assimilation of disparate PACS into an enterprise Vendor Neutral Archive configuration will have its challenges.  I think it is better to fully understand these challenges in order to better prepare for them, and I suggest that this knowledge play a key role in the VNA selection process.   It also makes sense to include the knowledge of these issues in the next PACS selection process, and thereby eliminate as many future interoperability issues as possible.

Pro-Active Image Data Migration to a VNA-enabled Storage Solution is a Strategic First Step in a Multi-Phase VNA Deployment Strategy

The concept of Vendor Neutral Archive (VNA) seems to be gaining traction in the medical Imaging market.  Why wouldn’t it?  It makes a good deal of sense…addressing problems directly attributed to the way department PACS manage image data.  Health Imaging & IT published a list of the top 10 PACS Problems in its July 2011 issue.  In my opinion, the VNA directly addresses 7 of the 10 problems listed in that article. Categories include Integration, Downtime, Hanging Protocols, Interoperability, Out with the Old (data migration), Whose PACS? (Radiology or IT), and Disaster Recovery.

Just to be clear on the concept, I offer the following succinct definition.  The Vendor Neutral Archive is an Enterprise-class data management system that consolidates primarily medical image data from multiple imaging departments into a Master Directory and associated consolidated Storage Solution, thus replacing the individual archives associated with departmental PACS…systems with unfortunate proprietary characteristics that limit their interoperability.   By virtue of it consolidating all of the enterprise image data, the VNA effectively becomes the unified image data repository for the Electronic Medical Record system.

The problem with VNA is not the concept, the problem is the expense.

The properly configured VNA is a BIG system.  It’s often nearly as expensive as the organization’s biggest PACS, since it will be managing all of the data from all of the department PACS, and the proper architecture is a mirrored, dual-sited configuration.

The point I want to make here, is that the properly configured VNA is big enough and expensive enough to require multiple years and multiple budgets…and this is very reminiscent of those first generation PACS deployments in the early 90’s.

Even as late as the mid 90’s, those first generation Radiology PACS required large investments.  And there was admittedly some doubt as to whether that generation of PACS would successfully replace film.  As a consequence, early PACS deployment strategies focused on solving more manageable, smaller problems with entry-level products that were modestly priced.  The mini-PACS for CT, MR, and Ultrasound, and Teleradiology systems were considered PACS precursor products that could ultimately be stitched together to create the full blown department PACS.  The typical PACS deployments in the mid-90’s were phased in over several years and several budgets.

Is there a multi-phase strategy for deploying a VNA?  I think there is.

As long as the organization’s image data is being managed in individual department PACS, the data format is (to some degree) proprietary to the PACS.  Consequently the organization faces the liability of future data migrations, whenever a department PACS is replaced with another vendor’s PACS, or even upgrade to a next generation PACS from the same vendor.  Therefore the first step in a multi-phase VNA deployment strategy should be to migrate all of the organization’s image data out of the individual PACS and into a VNA-enabled Storage Solution…converting the data into a “neutral” format in the process.  In this strategy, the organization is simply “parking” a copy of its image data for future use.  The hardware and software configuration does not have to support any department PACS operations.  This entry-level VNA is simply managing a copy of the image data “at rest”.

I refer to this first step as the Pro-Active Data Migration, and the ideal time to initiate this migration is at the mid-life of the organization’s largest PACS, which is frequently its Radiology PACS.  By the time all of the historical data has been successfully migrated and cleansed, its time to replace that largest PACS.   Now that the organization is in control of its image data, both the old and the new PACS vendors have much less leverage in the selection process.

Here are a few tips.  (1) Look for a VNA vendor that understands that the value of the VNA software license used to manage image data “at rest” (data that is not being accessed by a PACS or a Viewing application) should be a fraction of the value of the fully-activated VNA license.  (2) Consider forwarding the migrated image data to a vendor-managed Cloud Infrastructure, whose fee-for-study costs are probably going to be considerably less than those for an on-site, self-managed solution.

Once the organization has established a repository of one neutral copy of its image data, there are numerous second and third steps that can be chosen to complete the VNA build out.