UK Imaging Informatics Group
VNA White Paper Has Been Released PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Procurement & Business Cases >
Message/Author
 Link to this message Yusuf Hakim  posted on Monday, July 26, 2010 - 12:34 pm Edit Post Delete Post Print Post
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.

Download Now For FREE: http://bit.ly/cCjytG
 Link to this message William Saywell  posted on Wednesday, August 31, 2011 - 12:23 pm Edit Post Delete Post Print Post
Hi,

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?

Regards,

William
 Link to this message Neelam Dugar  posted on Wednesday, August 31, 2011 - 12:56 pm Edit Post Delete Post Print Post
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.
 Link to this message Dr. Adam Chee  posted on Wednesday, August 31, 2011 - 03:26 pm Edit Post Delete Post Print Post
Glad that the ebook helps :-)

Now to take a rest before thinking of what to write next! (maybe primary care informatics for clinical research informatics)
 Link to this message William Saywell  posted on Wednesday, August 31, 2011 - 03:34 pm Edit Post Delete Post Print Post
How can we acquire the ebook? William
 Link to this message Dr. Adam Chee  posted on Wednesday, August 31, 2011 - 04:21 pm Edit Post Delete Post Print Post
Hi Willam,

I am waiting for the foreword to be written and I would like to add abit more content to it plus the proof-reading etc.

When would you need the details?
 Link to this message William Saywell  posted on Wednesday, August 31, 2011 - 04:38 pm Edit Post Delete Post Print Post
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
 Link to this message Chris Bull  posted on Wednesday, August 31, 2011 - 06:43 pm Edit Post Delete Post Print Post
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

Chris Bull
 Link to this message Neelam Dugar  posted on Wednesday, August 31, 2011 - 07:06 pm Edit Post Delete Post Print Post
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.
 Link to this message Neelam Dugar  posted on Friday, September 02, 2011 - 08:34 pm Edit Post Delete Post Print Post
http://www.himss.org/content/files/TeraMedicaWhatisaVNA.pdf


Definition of VNA. William you may find this really useful.
 Link to this message Mark O'Herlihy  posted on Tuesday, September 06, 2011 - 02:08 pm Edit Post Delete Post Print Post
Hi all,

After checking with your PACS group chairman, it was felt that it would be useful to post our white papers on VNA and migration.

With over 600 implementations worldwide and over 200 PACS migration projects, we are well positioned to give an insight into the VNA & Migration market.

I have attached the VNA whitepaper and I hope you find this useful as a group. I will post the Migration whitepaper next week.

If you need any further information, please do not hesitate to contact me.

application/pdfVNA Whitepaper
VNA_Whitepaper-2011.03.15.pdf (628.1 k)


Regards,

Mark

Mark O'Herlihy
European Business Manager
Acuo Technologies
moherlihy@acuotech.com
+447973572457
 Link to this message Neelam Dugar  posted on Monday, October 10, 2011 - 07:21 pm Edit Post Delete Post Print Post
Mark,

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)
 Link to this message Mark O'Herlihy  posted on Tuesday, October 11, 2011 - 02:29 pm Edit Post Delete Post Print Post
Hi Neelam,
1. why a customer should buy a VNA from a 3rd party (and not from the PACS vendor).

So the typical approach most VNA vendors will do is take out their checklist, including us!

http://www.acuotech.com/statements/ACUO_VNA%20Checklist_Jan%202010.pdf

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.

application/pdfDo Not Purchase a VNA from a PACS Vendor
Do_Not_Purchase_a_VNA_From_a_PACS_Vendor_2011.03.08.pdf (239.8 k)



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.
 Link to this message Neelam Dugar  posted on Tuesday, October 11, 2011 - 07:42 pm Edit Post Delete Post Print Post
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)
 Link to this message Mark O'Herlihy  posted on Tuesday, October 11, 2011 - 10:19 pm Edit Post Delete Post Print Post
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.
 Link to this message Martin Lang  posted on Wednesday, October 12, 2011 - 09:23 am Edit Post Delete Post Print Post
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

Best,

Martin
 Link to this message Chris Bull  posted on Wednesday, October 12, 2011 - 09:29 am Edit Post Delete Post Print Post
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.
application/pdf
BIR Sept 2011 - Monday 26 Sept.pdf (4337.9 k)
 Link to this message Neelam Dugar  posted on Wednesday, October 12, 2011 - 05:25 pm Edit Post Delete Post Print Post
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.
 Link to this message Neelam Dugar  posted on Wednesday, October 12, 2011 - 09:25 pm Edit Post Delete Post Print Post
I found this rather interesting:
http://www.kellermed.com/in-the-news/dicomxdsrepository-archiveallstrategy

"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.
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: