The term Vendor Neutral Archive (VNA) is used by many vendors of PACS software to identify the core of their product--the component that is used to reliably manage, store, retrieve, and query medical images and related information. Unfortunately, there is no "official" definition of the functionality of a VNA. As such, VNA offerings vary from vendor to vendor. The result is confusion among users due to the lack of a baseline that permits a direct comparison of VNA functionality and features.
This white paper proposes a definition of a Vendor Neutral Archive (VNA) that identifies different architecture levels and their specific functionality. The various components which make up the core of a healthcare image and information management system will be discussed. It also provides the key advantages of a VNA compared with a proprietary solution. A checklist which can be used when evaluating and/or requesting a RFI/RFP for a VNA is included as an attachment.
we've got a sum of money for a VNA, primarily to retain all our PACS data on site [for business continuity and to ensure we have on-site data for 2013].
Does anyone have a spec we could 'borrow' for the procurement process please?
posted on Wednesday, August 31, 2011 - 12:56 pm
Great news William. It is good to see innovation going on in many corners of the NHS.
A/Prof Adam Chee (Binary Healthcare) from has recently asked me review his Electronic Book which should be available soon. Like him I prefer the term "Vendor Neutral Architecture" of which archiving is a important component. I think it is a must read for all those involved ---clinical & technical in Clinical IT.
Specification of a Archive that is vendor neutral: just some comments 1. Images stored MUST be in a vendor neutral DICOM part 10 file format. This will ensure that the images can be retrieved & ingested by your PACS vendor. This is the critical difference between a PACS vendors DICOM archive & a vendor neutral archive. As VNA data is retrivable by any PACS/DICOM vendor. 2. PAS/RIS integration is maintained at VNA database level through HL7 messages so that demographics or any exam name changes etc can be kept up-to-date. 3. If you store non-DICOM data, make sure that it can be retrieved by ANY vendor (not just your VNA vendor). Hence vendor neutral standards adoption is key.
Adam's book will provide you with more info to develop your VNA archive spec. I think it is well written & unbiased. I think Vendor Neutral Architecture is key to the development of an electronic patient record in a multivendor secondary care env as we have.
Thanks, Adam. =20 We're writing the OBS as I type! I'll be interested to see the book when it's ready, though. Regards, William
posted on Wednesday, August 31, 2011 - 06:43 pm
Take a look at our web site www.pfcl.co.uk for a VNA document which was published in Rad Mag last year. It is PDF format and can be downloaded. Best wishes
posted on Wednesday, August 31, 2011 - 07:06 pm
William, Would you be willing to share your Spec with the Group once it is ready? I am sure it will help other Trusts.
Another suggestion which was suggested by Adam in his book, is the option to use of your VNA archive as your disaster recovery solution. The data held will be in DICOM part 10 file format, so the data can be ingested by ANY PACS vendor (so it ensures that the Trust always maintains ownership of the data). VNA interpretation varies between vendors so be sure you are not "locked in" by VNA vendor.
Key questions are 1. How will the data be retrieved if the VNA vendor goes bust? 2. Would any PACS supplier be willing to ingest DICOM data from the VNA archive.
posted on Friday, September 02, 2011 - 08:34 pm
There are a number of PACS vendors who claim to have a VNA within their PACS solution--i.e. their DICOM archive is vendor neutral
Can you please explain 1. why a customer should buy a VNA from a 3rd party (and not from the PACS vendor). 2. what is the difference between a DICOM archive from the PACS vendor (compared to a DICOM archive from a VNA vendor) 3. If Trusts put in a VNA alongwith PACS replacements are we going to duplicate storage of the same data (DICOM data in PACS archive and then in the VNA archive too)---double our data storage management costs 4. If separate vendors for VNA & PACS are chosen do we need to double our integration costs --with RIS & PAS (one for VNA and another for PACS)
Although checklists are important in establishing the core attributes / functionality of a VNA, there really is a core tenant/philosophy that must be present in the vendor in order for it to be successful in the VNA space. In my opinion that has to do with core values which drives towards a philosophy of interoperability. Think about it, the PACS vendor wakes up each day and has a core requirement to build solutions that work well together across their product lines, that said when given a choice would their business model have them build the best integration to their front end PACS or to make sure that they work as well, or even better, with a PACS from another vendor? It is this core philosophy that drives the VNA (or it should) to support any and all PACS for not only disaster recovery archiving, data migration, but also as an active replacement of the archive of a traditional PACS vendor. Now once you understand this philosophy and see the demonstrable evidence that a VNA needs to have of interoperability with every major PACS, across multiple departments, in many cases within the same implementation – you understand that a PACS VNA solution probably can’t reference sites where they are doing this with a different PACS viewer, even multiple PACS Viewers.
You can also reference an independent opinion on this subject by a lead consultant in the US.
2. what is the difference between a DICOM archive from the PACS vendor (compared to a DICOM archive from a VNA vendor)
Similar to the answer in #1 above – when driving down to the tactical set of functionality we should refer to the checklists, it is much more than a DICOM archive, it needs to also support non-DICOM including open interfaces such as web services and standards such as XDS. It also needs to support workflow functionality so it can actually replace the archive of a PACS – simple DICOM Q/R won’t allow this to occur.
3. If Trusts put in a VNA along with PACS replacements are we going to duplicate storage of the same data (DICOM data in PACS archive and then in the VNA archive too)---double our data storage management costs
Absolutely not – if they do then they aren’t really implementing a VNA. Back in #1 recall that a core requirement is the FULL replacement of the active archive from the PACS vendor – this means that the archive in the PACS no longer exists – sure there might be a smaller cache but some workflow functions like routing/distribution/pre-fetching/normalization/reconciliation could be off-loaded to the VNA. A VNA must become the archive of record. The front end PACS no longer has to store the primary copy of the data (except maybe just the short term cache) and references the VNA as the archive or record.
4. If separate vendors for VNA & PACS are chosen do we need to double our integration costs --with RIS & PAS (one for VNA and another for PACS)
It shouldn’t – absolutely not – remember a true VNA vendor should focus on interoperability and as such should offer the customer a reduction in cost, not an increase. This can be done in multiple ways, for example: • Eliminate costly/multiple integration points for the departmental systems (PACS) to the EPR • Eliminate costly integration to customer choice of storage • Eliminate costly migration (DICOM or media/IT based) • In many cases even eliminate costly modality integration costs by having the modalities integrate to the VNA as a “router”/workflow engine in front of the PACS.
Thanks Mark for your response which is appreciated.
Instead of buying a VNA why not buy a XDS Registry & Repository. There is standard definition for this (unlike VNA whose definition differs from each vendor you speak to) 1. This will store & index all types of medical images & documents. 2. Any departmental system or PACS will have access to EPR information if they are XDS consumer compliant. 3. User community can be confident about what to expect from XDS Registry & Repository ( unlike VNA where the definition is so variable)
Instead of buying a VNA why not buy a XDS Registry & Repository. There is standard definition for this (unlike VNA whose definition differs from each vendor you speak to)
Well I do agree that the definition of VNA is a bit vague and that is a problem we (the industry and standards bodies) needs to resolve. There has been socializing concepts with IHE and DICOM bodies about a VNA profile or set of transactions that does a better job of defining this. That said – an XDS Registry and Repository isn’t really a VNA, specifically and XDS Reg/Rep doesn’t store DICOM objects, it stores references to DICOM objects (XDS-I) which exist in the VNA or the PACS. I do agree though that the lines are blurred and often the VNA is combined with the XDS Reg/Rep profiles.
1. This will store & index all types of medical images & documents.
See above - an XDS Registry and Repository isn’t really a VNA, specifically and XDS Reg/Rep doesn’t store DICOM objects, it stores references to DICOM objects (XDS-I) which exist in the VNA or the PACS. I do agree though that the lines are blurred and often the VNA is combined with the XDS Reg/Rep profiles.
2. Any departmental system or PACS will have access to EPR information if they are XDS consumer compliant.
Agree – yes, and a properly implemented clinical platform for content management (Acuo’s Universal Clinical Platform) will offer multiple content types (DICOM and non-DICOM), ingestion and export, as well as integration to the EPR.
3. User community can be confident about what to expect from XDS Registry & Repository ( unlike VNA where the definition is so variable)
True – but let’s not lose sight of the DICOM content as mentioned above.
posted on Wednesday, October 12, 2011 - 09:23 am
Hi all, thanks for the interesting thread.
Just one comment. I totally agree with Mark in regards to his point about vendor-neutrality and "openess" of a VNA. But we shouldn't fool ourselves.
Vendor-neutrality has NOTHING to do with the breadth of a vendors portfolio. It is a fundamental design principle of a system type called VNA. We should really by careful and differentiate between marketing "noise" and true technical facts!
IMO it is KEY to buy these kinds of systems from vendors who do provide profound clinical AND technical know-how in our domain. PACS-vendor or not!
Actually I'd feel better pruchasing a VNA from a PACS vendor instead of a vendor with no or very limited clincal/workflow know-how... but in the end, it's everybody's own choice.
Just my 2 cents and keep it up guys
posted on Wednesday, October 12, 2011 - 09:29 am
I recently was at the BIR at the PACS second time around course. Attached is a copy of my presentation on this subject. The use of a VNA can save management and storage costs.
posted on Wednesday, October 12, 2011 - 05:25 pm
Thanks for all comments & they are all valid in my view.
User community has 3 choices if they wish to store all clinical images & documents in a single repository. All the below 3 serve the same purpose. 1. VNA from a PACS vendor 2. VNA from a 3rd party 3. XDS Repository with XDS Registry
The advantage of 3rd option is that it is totally standards based. Hence, you will be able to access the data from any Clinical IT systems 1. Radiology PACS 2. RIS 3. CIS 4. Critical Care system etc provided each of these systems become XDS consumer complaint. Hence, the data will be accessible enterprise-wide and your VNA vendor cannot lock you into a display. Standards are important.
posted on Wednesday, October 12, 2011 - 09:25 pm
"DICOM XDS Repository - Archive all Strategy posted Nov 5, 2010 12:44 PM by James Keller [ updated Nov 5, 2010 1:14 PM ] Combining a DICOM and XDS archive into a single repository for images and documents across an enterprise.
PACS has been seen as large proprietary data silos of DICOM images. While, information systems (RIS, CIS, Ordercomms, Clinical letters system, Discharge summary system, E-Prescribing etc) all hold digital information in independent data silos, due to lack of document standards. The only way for clinician to access the full clinical history of a patient is by looking at paper notes, where the documents are printed and organised for each patient.
Cross-Enterprise Document Sharing (XDS) provides a document standard that is changing the EPR world completely. Information systems will create the documents and send them off for storage and display.
The other big advantage is we are currently struggle with old outdated information systems which are difficult to remove and replace. By adopting XDS standards with a Vendor Neutral PACS, information systems and PACS will send all data to the XDS repository and hence, one will find it as easy to replace an information system or PACS as it is to replace a CT/MRI scanner.
The archive all strategy of XDS provides a means of providing an EPR, and replacing the paper notes similarly to how PACS replaced the film packet. XDS connects all information systems even currently existing Information systems.
We see this as a huge advantage and cost savings to being able to deploying regional repositories that are both Vendor Neutral PACS repositories and XDS repositories on the same infrastructure with an internationally accepted standard. "
I agree with the above comments. If you are investing in a VNA, it MUST be XDS Registry & XDS repository compliant.