Vendor neutral archive

Most would agree that what is implied by the term is actually "PACS Vendor Neutral Archive". So what makes an archive PACS vendor neutral? Answer: Adhering EXPLICITLY to the universally accepted DICOM standard as written. Providing standards based storage is an absolute requirement for a product to call itself truly vendor neutral. This is also the only way to guarantee the longevity of archived medical images. Sound simple? It is... 


Now that we've covered the "vendor neutral" piece, let's look at the second part of the term. What is an archive? Again simple. In terms of electronic diagnostic study data, an archive is a long term storage repository, or data preservation system, for DICOM image data as well as some non-DICOM data (reports, etc.). An archive must have the capability of automatically migrating the stored information from one generation of storage technology to the next, so that the stored electronic information can be preserved for its required retention period (usually 7+years in the case of diagnostic study data). In other words, the archive must provide a storage infrastructure that will automatically span multiple generations of storage hardware, while preserving the underlying data itself (by adhering to the DICOM standard). This automated data migration process must be decoupled from, and transparent to, the PACS in order to maintain the archive's vendor neutrality. 


That's it! Now there are numerous other functions and features that are available in VNA products, such as disaster recovery capability, enterprise viewing, HL-7 integration, image sharing, etc. But if you use the "Occam's Razor" approach, and simply look at the term "vendor neutral archive" it gets much simpler to define. So after you get past the basics of "PACS vendor neutral" and "archive", simply select the other available product features based on your requirement, project scope, budget, etc., just like you would with any decision to implement a new product or service. 


Potential actors : DeepWell Archival Services, DeJarnette Research specializes in large enterprise projects requiring image sharing among disparate PACS,. ACUO and TeraMedica, there may be a few others out there as well, but not many. 


What a VNA vendor is NOT, is a RAID-5 or RAID-6 disk array with a server in front of it running a freeware or homegrown PACS application, and storing data in non-DICOM standard, proprietary formats. Just because a storage device is utilizing parts of the DICOM standard, does NOT mean that it is "standards based" storage. This covers about 90% of the vendors out there who are taking advantage of the term "VNA" and misleading their customers about long term data and image preservation. Start by looking at the conformance statement of any "purported" VNA vendor and you will start separating the men from the boys right away! Also ask any VNA vendor: "How do you guarantee image integrity and longevity over seven year (minimum) retention cycles?" If the answer is "Ummm, what do you mean?", you have just eliminated that vendor as a potential solution provider!  The hype and confusion created by mislabeling PACS solutions as VNAs is likely to continue. 
The bottom line, however, is that PACS vendors, by and large, do a good job with medical image acquisition, display, departmental communication and workflow – where they are focused and should remain focused. The data management and enterprise interoperability aspects of PACS, however, is problematic for healthcare providers and government institutions that need to assemble a complete picture of the patient from many disparate and proprietary silos of patient data. The vendor neutral archive is an innovation whose time has come as our industry moves to the next level of technology-enhanced healthcare delivery and outcomes.
As to VNA well it depends on where you draw the line on neutrality. Do you draw it at storage interface or at the DICOM interface.


If you draw it at the storage interface most Storage Area Networks (SAN) and Network Attached Storage (NAS) are vendor neutral. They look like a big hard drive to the server. The SAN is so much more though. You can create different levels of archives with different hardware / spinning disks / tape drives. Different methods of archiving to different devices for different periods and different redundancy techniques. They are vary scale-able as well. They can become very complex though. They require a good knowledge base in the IT department to maintain. The PACS never sees anything behind the SAN interface. For that matter no system sees any more than a file system. Being truly vendor neutral. A NAS is just a network file system but the modern systems have some interesting mirroring capabilities. A NAS can also be put behind a SAN when the need arises.  If you are looking at it from the DICOM interface I argue you loose that vendor neutrality. Technically it will not work for EMR data or user files. When it handles all data types then you are neutral. Although If you are looking for DICOM image neutral well it would be close. You could most likely send and receive DICOM images to and from any device that speaks DICOM. If your EMR used WADO as a DICOM interface then the EMR could view DICOM images. It will work best if you use the vendors viewing station. They will have the propitiatory hooks to view the images as fast as possible without the added overhead of the DICOM protocol.


Although Agfa had an interesting concept. They still had their propitiatory viewing station but they tried to include other file formats. Their idea was wrap everything as a DICOM package. This did have the added benefit to create an index on the data. If you decided to take advantage of the DICOM header. The downside is it does take more space to store the header not much generally less than 1% could be 700% though if you stored a bunch of 5 character files. They had a nice little web interface where you could get access to your files. They also had an API that you could write to if desired. To send and receive data to and from their system. Data retrieval is quit a bit slower than direct connection to the SAN.


Amazon and other generic cloud storage companies charge for storage every month, e.g. $.20/GB etc., and they typically charge for retrievals. Unlike some of the more well known cloud storage companies, e.g. Amazon, et al, DeepWell charges a one-time ingestion fee for the life of the study data, with no ancillary fees for retrievals, etc. Many cloud storage companies charge $.10 - $.20 per GB of storage used on a cumulative basis, every month. So you’re paying for your: {(current month’s storage) + (new month’s storage)}x $/GB. This type billing is cumulative, and grows with your storage volume month after month, year after year… When you add the necessity for replication to meet HIPAA Security Rule requirements for disaster recovery and business continuance, you can double that price. These costs become exponentially high over (7+) year retention periods.  Cloud vendors’ pricing models, by examaple DeepWell charges a one time ingestion fee for the life of the study data, with absolutely no additional fees (retrieval fees, etc.). The bandwidth required for archival purposes is roughly 1Mbit/sec per TB/yr of data storage, for example a customer archiving 5TB of diagnostic study data per year would need 5Mbit/sec of bandwidth for archive purposes. This is usually significantly less bandwidth than the facility has in place for day-to-day image sharing, etc. The costs of rolling your own storage can get expensive as well though, especially when you look at all of the “not so obvious costs” of implementing and managing storage over 7+ year retention periods. Consider all of the costs involved in managing storage from the most granular to the most visible levels: file system, volume management, and storage vendor specific software, i.e. SAN or NAS disk array vendor specific software, data center “real estate” costs, whether hosted or owned by the imaging organization, disk array and tape hardware capital costs, backup software, replication costs, hardware and software maintenance costs, power and cooling costs, capacity expansion costs, interoperability issues and data migrations, as the data typically outlives several generations of hardware and software, etc. And on top of all that, it industry estimates typically say you will spend $3-$5 annually, for the human resources that it takes to manage all of the infrastructure, for every dollar spent on hardware and software. I think we all get the idea: managing long term data storage can be complex and expensive!  A low, one time fee for the life of the study data becomes a compelling business case for sure. Some providers implement with an onsite-offsite architecture typically with 3+ years of onsite, DICOM enabled storage cache which is immediately accessible by the PACS, with multiple copies of the data stored in purpose built data centers for secure, long term preservation purposes.


By example : Telepaxx Medical Archiving Gmbh, is responsible for the safe, secure archival of over 1.6 billion medical images worldwide, with over 15 years of operating history in cloud based storage.


Source : http://www.linkedin.com/groups?home=&gid=133633&trk=anet_ug_hm