What is a Vendor Neutral Archive?

http://dejarnette.com

Over the past few years there has been tremendous buzz in the industry about what constituents a “Vendor Neutral Archive”, sometimes referred to as a VNA. There are a number of industry consultants touting the virtues of these devices. Salesmen are actively trying to sell them. However as I talk to people in the industry, both end users and vendors, I find a great deal of confusion. I have heard time and again, “oh, you mean a DICOM archive?”, or “yeah, we are talking to our PACS vendor about a “Super-PACS”, or “yes, we have one.” I will attempt to bring some clarity to the issue of what is and is not a Vendor Neutral Archive.

Some of the issues which point towards the need for vendor neutrality
There are all types of vendor neutrality. In this instance the neutrality of concern is a neutrality that assures freedom from vendor imposed limits on how, when, where and what a healthcare enterprise does with its electronically stored images and documents. A common complaint among owners of PACS is that they do not feel they own their images and associated data. Anything they choose to do generally has a dollar cost associated with it and they must involve their PACS vendor. The PACS vendor is not always cooperative. There is a feeling of being held hostage and helpless. A PACS owner will often see as their only solution, changing PACS vendors when it comes time to replace their existing system. It is “pay-back time”. From this reality the concept of Vendor Neutral Archive was born.

A recently hired hospital CIO who came from the banking industry, when learning of his radiology director’s needs and issues commented on the craziness of this system. How “nothing talks to anything else”. How it is impossible for his IS people to effectively manage his institution’s imaging storage infrastructure, the way they were able with billing, patient records, employment records, etc. It is also from this reality the concept of Vendor Neutral Archive was born.

The problem with all of our PACS today is a fundamental architecture and business platform issue. A PACS has a number of logical components; a HIS/RIS interface engine, a workflow engine and database, modality gateway components, a storage system and a viewing system. All of these components are generally supplied by a single vendor. In order to lock a purchaser into a particular vendor’s products, all too frequently industry standards are only used by a vendor for getting images and order information into their PACS. All interest is lost in these standards once the image and order data has been acquired. A PACS purchaser may find it very difficult, expensive or in some cases impossible to add new functionality to their PACS. Desirable features all too frequently must wait until the purchase of the next PACS. Frequently it is the lack of extensibility in the current PACS that causes a PACS owner to purchase a new system before the current system has reached the end of its useful life. It is also from this reality the concept of Vendor Neutral Archive was born.
The characteristics required of a medical image “Vendor Neutral Archive”
A medical image archive, to be useful, in its most fundamental form consists of three components; 1) a storage sub-system, 2) an interface to the medical imaging application world which allows for the storage and retrieval of images and associated documents in a “clinically useful fashion”, and 3) a database that manages and remembers where, what, when, how and who stored images and associated documents into the storage sub-system. The phrase “clinically useful fashion” is significant. It is this characteristic that makes this particular set of components a medical image archive and distinguishes it from archives of employee files, financial data, etc. It is this characteristic that presents the greatest challenge to IT specialists in dealing with and managing medical imaging data.

When supplied as part of a PACS, the medical image archive or storage system database is traditionally a shared resource. It is frequently shared with the workflow engine, the HIS/RIS interface engine, a reporting engine if part of the PACS offering, and other sub-systems which need to remember and recall highly structured data. While this makes good engineering sense and was at one time a requirement in order to keep the cost of a PACS down, this architectural decision is the cause of many of the industry’s interoperability problems and the cost savings today from using a single database for all of these purposes is minimal.

The above characteristics are those of a medical image archive. In order to be vendor neutral, there are other requirements to meet. There are two types of vendor neutrality which are paramount; 1) the ability to function with no noticeable differences1 between similar storage products of different manufacture, and 2) the ability to function with no noticeable differences between similar imaging applications, ie, PACS vendor neutrality. It is this second requirement that provides the greatest benefit to the end user customer and provides the greatest challenge to vendors attempting to provide a true Vendor Neutral Archive product.

By now the reader should be getting a good “feel” for what a Vendor Neutral Archive is and the characteristics it must have. It should be noted that when discussing what a VNA is, this must be done in the context of the domain in which the archive is to operate. This paper only considers the question of vendor neutrality in the domains of radiology and cardiology. These domains may span a single medical treatment facility, a larger, multi-site enterprise or a region with many independent enterprises.
A Vendor Neutral Archive meets the following requirements:

• It must interface with other clinical systems and disparate PACS for the purpose of communicating imaging data, by means of DICOM;
  
• It must interface with other clinical information systems for communication of reports, results, workflow, etc., by means of HL7;
  
• It must have the ability to store the complete suite of DICOM SOP classes including presentation states and key image notes;
  
• It must store all objects in a non-proprietary format understood by the community at large, ie., DICOM part 102;
  
• It must support the most inclusive DICOM query/retrieve specification as a service provider for the information stored in the archive at all information levels;
  
• It must provide context management, i.e., the ability to manipulate DICOM tags so as to convert the DICOM implementation and demographic needs of one PACS vendor (or imaging application) to the DICOM expectations of another PACS vendor (or imaging application) with no significant impact on the customers daily operation3. Context management includes the ability to prepare a PACS through HL7 for ingestion of images from another, disparate PACS;
  
• It must handle ADT updates to the image files stored in the 
  It must support a wide variety of storage infrastructure solutions so as to facilitate storage hardware upgrades and replacement with little impact on the clinical enterprise;

• It must include a separate, independent, commercially available database product which supports SQL, so as to allow for easy integration into an IT department’s every day management operation4,5;
  
• It must ingest any type of electronic document through the use of an API and categorize that information with the lowest level association that can be made within the archive;
  These are the minimum requirements. Any product which does not meet all of these requirements, while it may be useful, is not vendor neutral and will not provide the benefits of a “Vendor Neutral Archive”. The vendor neutrality of this device spans PACS vendors, storage vendors, offsite storage providers and Vendor Neutral Archive software providers6.
  Some industry consultants and academics would include other requirements/characteristics. While these requirements/characteristics may be useful to the end user customer, they are at best irrelevant to vendor neutrality, and at worst antithetical to the concept of vendor neutrality7. Following is a list of useful features in an archive product (there are certainly others) which are consistent with and in no way interfere with the vendor neutrality of such a device.
  
  • Support for various IHE profiles (detailed later);
    
  • Support for high-availability hardware and software platforms so that the archive
    continues to operate when there is a single failure of a disk, server or network interface;
    
  • Highly scalable so that the enterprise archive can grow with the needs of the clinical enterprise;
    
  • Support for image compression in a non-proprietary, industry standard fashion;
    
  • Support for multiple departments: radiology, cardiology and any other departments with
    digital images requiring storage, not necessarily DICOM8;
    
  • Support for automatic pre-fetch of prior studies triggered by HL7 order messages that includes context management;
    
    

• Support for auto-routing of images and other documents that includes DICOM context management;
  
• Support intelligent management of the information within the enterprise archive independent of the clinical systems interfacing with the archive (CLIM – clinical life cycle information management);
  
• Simultaneous support for both onsite and offsite data storage; and
  
• Visualization tools that can interface with the enterprise’s EMR solution to provide access to the images within the archive outside of the clinical PACS9. It is imperative that these tools be based upon acquiring and interacting with the VNA through industry standard protocols. WADO (Web Access for DICOM Objects) is such an industry standard protocol.
  
  The benefits of a Vendor Neutral Archive
  
  There are numerous benefits provided by a Vendor Neutral Archive:
  
  • switching PACS systems without requiring a complex image/data migration;
    
  • making use of the latest storage hardware technology without requiring a complex
    image/data migration;
    
  • maximizing ROI on legacy PACS and imaging applications;
    
  • easily bringing online new imaging applications not supplied by your PACS vendor;
    
  • synchronizing the demographic data associated with your image data and your
    HIS/RIS10;
    
  • sharing common IT managed storage with other applications; and
    
  • effectively controlling your image data.
    There are other benefits depending on the additional features your VNA software provider supplies. For instance automated deletion of old unneeded data through CLIM; the ability to easily share image and report data; the ability to provide patients and referring physicians with access to their images over the Internet; etc.
    Alphabet soup may be harmful to your health (care practice)
    It should be noted that it is possible to build a Vendor Neutral Archive without supporting any of the IHE profiles. Today, IHE conformance adds little to the useful functionality of a VNA in a single radiology or cardiology department as the PACS themselves do not generally support IHE. This however changes as you attempt to provide a VNA that interfaces outside of a single department to provide for enterprise data sharing. This will also change in the future in the departments themselves as more PACS conform to IHE. Today, a prospective purchaser of a VNA should take with a grain of salt any sales pitch that includes addressing significant departmental issues through IHE conformance.
    This is not to say that IHE should not be part of a go forward strategy. It should be! Data sharing outside of the individual department and certainly across an enterprise will in future depend upon equipment which supports the IHE model. IHE will certainly be part of the solution in providing national electronic health records. This is already seen to be the case outside of the US where the western democracies are ahead of the US in deploying such solutions.

The following IHE profiles are thought to be most useful in the context of a VNA:

• Radiology’s Scheduled Workflow (SWF) integration profile;
  
• Radiology’s Patient Information Reconciliation (PIR) integration profile;
  
• IT’s PIX and PDQ integration profiles;
  
• IT’s Consistent Time (CT) integration profile;
  
• IT’s Audit Trail and Node Authentication (ATNA) integration profile;
  
• IT’s Enterprise User Authentication (EUA) integration profile;
  How is a “Vendor Neutral Archive” different from a DICOM Archive?
  A DICOM archive is not the same as a VNA. A DICOM archive supports only a subset of the functionality that a VNA does. DICOM archives have existed for more than 15 years. Some PACS vendors make use of a DICOM archive as their primary image storage cache. These products however have not solved the problems associated with replacing a legacy PACS without requiring a complex image migration. These products have not made the majority of PACS owners feel as if they own their image data. In very few cases have these products represented an investment that was useful beyond the life of the PACS that it was provided with.
  The single biggest difference between a DICOM archive and a VNA is the VNA’s ability to perform context management. This is the ability of the VNA to manipulate its stored data to provide a presentation of that data which is different from the presentation with which it was originally stored. We have all encountered the problem that one imaging vendor or PACS vendor’s DICOM is not always useable by another vendor’s products. Suppliers of legacy PACS migration software and services have to deal with this problem daily. Different PACS products use the non-image DICOM tags differently. A particular tag (DICOM element) that is missing may be acceptable to vendor A, but cause vendor B’s product to choke, and vendor C’s product to not display images correctly. This is the big problem that DICOM archives do not address and VNA’s do.
  Another significant difference is that a DICOM Archive does not interface to a HIS or RIS, while a VNA does. This allows the VNA to keep demographic and other non-image data synchronized between the stored image file and the HIS or RIS. The great majority of PACS in fact, whether they make use of a DICOM archive or not, do not provide this ability.
  Finally, a DICOM archive is just that. It stores DICOM objects. A Vendor Neutral Archive can store objects of other types, such as non-DICOM image files from other “ologies”, scanned documents, PDF files, etc. and provide a means for indexing them and associating them with other DICOM and non-DICOM objects.
  How is a “Vendor Neutral Archive” different from a Super-PACS?
  Super-PACS or Mega-PACS are a traditional PACS product offering which has been scaled to function across a larger enterprise. The net result of this type of architecture is that it accomplishes data sharing across an enterprise so long as the enterprise is populated totally by PACS of that single vendor. A Super-PACS solution does nothing to address vendor neutrality of storage. It is in fact antithetical to the entire concept of vendor neutrality. A Super-PACS has all the same problems that a traditional PACS does when it comes time to replace the product with a new PACS. The only difference is that the magnitude of the problem is much greater. The PACS owner remains locked into a particular vendor and will have to spend significant monies in order to move away from that vendor.
  

Vendor neutrality must drive next-generation system architecture!
It is difficult to imagine how a PACS vendor today can provide a VNA. Most of today’s PACS architectures suffer from the flaw of a shared storage and workflow management database. These systems also generally provide for advanced functionality of the vendor’s viewing components through database usage. The intertwining of these components through the database makes such systems a bad place to start in developing a VNA.
Vendor neutrality demands the usage of widely accepted standards at all component interfaces. Few if any PACS vendors today worry about these standards inside of their own PACS products. In future, true vendor neutrality will require a new PACS architecture, shared by all PACS and PACS component vendors. This architecture will of necessity split out the archive, if not the entire storage subsystem. The other major PACS components, workflow management and applications (including all viewing) do not have to be split out in order to assure that a customer maintain effective control over their imaging data. However splitting these components out of PACS is possible and desirable from the perspective of the customer. This breakup of PACS into these components would allow vendors to concentrate on their core competencies, increase competition and ultimately reduce prices. In such an environment it would be possible for non- medical imaging vendors with experience and generic products, such as workflow management products/vendors, to participate more easily in the PACS market, bringing a deeper domain experience and commitment to the market.
The DICOM and IHE standardization efforts have been driving towards vendor neutrality for 15+ years. At this point in time there is a high level of acceptance, adoption and experience with these standards. At this time, hospital and imaging center CIOs are beginning to demand solutions that allow them to effectively manage radiology and cardiology data in a shared storage environment. Computer and storage technology have reached a point where the addition of standard interfaces to provide for component neutrality does not result in significant application performance degradation. The confluence of these realities makes next-generation PACS architecture possible. One in which vendor neutrality is assured.

If you have any additional questions about Vendor Neutral Archive implementation, contact sales@dejarnette.com