UK Imaging Informatics Group
VNA specification PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Procurement & Business Cases >
Subtopic Last Post Last Poster Posts
Archive through February 03, 201203-02-12  09:09 amJohn Parker20
Archive through February 08, 201208-02-12  07:50 amPim Philipse20
Archive through February 27, 201227-02-12  04:54 pmJohn Parker20
Archive through March 04, 201204-03-12  09:42 pmNeelam Dugar20
 Link to this message Greg Strowig  posted on Monday, March 05, 2012 - 06:22 pm Edit Post Delete Post Print Post
While XDS may be nice for non-DICOM data management, it needs to be utilized where there is ability to interact via XDS.

While we have XDS registry, repository, and interfaces in our software, they don't make sense for everyone. If the customer has proprietary radiation treatment plan files (say, from Tomotherapy), and the customer wishes to store these within our VNA, but has no ability to interact with XDS from any other system in their environment, what value does XDS add? If the customer needs their Tomotherapy files back from the VNA, they will utilize the tools that are applicable for their Tomotherapy system, not anything to do with XDS.

So, while we support the use of XDS, and are happy to sell this to our customers who can use it, it isn't a panacea.
 Link to this message Neelam Dugar  posted on Monday, March 05, 2012 - 09:40 pm Edit Post Delete Post Print Post
So customers need to choose the right VNA from the 3 below choices:
1. DICOM data store only from a single source (Radiology PACS) ---DICOM part 10 format is key.
2. DICOM data store from multiple DICOM sources(Radiology PACS, Cardiology PACS, Ophthalmology PACS etc)--DICOM part 10 +MIMA
3. DICOM & non-DICOM data from multiple sources--DICOM part 10 + MIMA +XDS Registry/Repository

Standards are key to ensure vendor neutrality (just the term VNA does not ensure that what is being bought is truly vendor neutral).

I see the 3rd type really something that will change the face of Global Healthcare IT.
 Link to this message Neelam Dugar  posted on Wednesday, March 14, 2012 - 09:52 pm Edit Post Delete Post Print Post

My column in Auntminnie based on the discussions on our forum. I am really excited about the global interest in VNA as I see this as a pathway from PACS to EPR via XDS.
 Link to this message Neelam Dugar  posted on Tuesday, March 27, 2012 - 10:59 pm Edit Post Delete Post Print Post
If you are incorporating XDS registry & repository within your VNA, XDS metadata is key.
Here is an updated version of the metadata based on IHE-UK discussion & a document worked on by the Sintero Project Group (which I hope will eventually have a UK-wide adoption.)

One significant metadata item that is LACKING in the metadata is "INTENDED RECIPIENT". This should be included in the XDS metadata set in my view. Hope IHE-UK takes this to global IHE for change in the standard. However, I would suggest that VNA vendors include both XDS & XDR metadata when indexing images & documents.
application/mswordXDS-XDR Metadata
XDS_Metadata_submission_v4.doc (61.4 k)
 Link to this message Neelam Dugar  posted on Friday, May 04, 2012 - 10:30 am Edit Post Delete Post Print Post
Pim Philipse (Rogan) commented on the Spring 2012 Meeting thread

"I'd like to share some thoughts about the speed of viewers that use XDS-I. This was presented as a zero-footprint viewer issue, but a thick client is affected as well.

First, the situation is not so dire as suggested, since apart from the SOP Instance UID's, the KOSD also contains:
- the SOP Class UID's
- the division of the study into series.
Thus, from the SOP Classes the client can immediately identify which SOP Instances contain PR and KO objects (with possible rejection notes) and retrieve these. It can then retrieve the first image of each series in order to obtain the series attributes of each series and guess the layout based on the image dimensions. Then it can present a screen to the user that displays the first image of each series. Possibly later on the sort order will dictate that this image be changed, but in a great number of cases this shouldn't be necessary.

A more robust solution would involve the use of DICOM supplement 148, WADO via web services. This allows the client to retrieve only the metadata of a SOP Instance, or even a subset thereof. The catch is that this transaction is not recognised by the XDS-I.b and XCA-I profiles, so one should negotiate this as a separate item (and/or submit a Correction Proposal to the IHE Radiology committee)."

I am inclined to update to VNA spec to include WADO support within the VNA-- for XDS-I viewers.
"VNA must support DICOM Supplement 148 WADO via web services --to enable XDS-I viewers to have an improved speed of access to the images within VNA."

Any views & comments on this please. Please do correct me if I have got the wrong end of the stick here Pim.
 Link to this message Neelam Dugar  posted on Sunday, May 20, 2012 - 05:32 pm Edit Post Delete Post Print Post ralized

I think this is rather interesting. 3 types of VNA is described:
1. Single Department DICOM based VNA (Radiology)
2. Multi-Department DICOM based VNA (Radiology, Cardiology, Medical photography etc)
3. Multi-Department XDS Based VNA (DICOM, non-DICOM content that can be indexed by XDS--CDA, encapsulated pdf etc)
Each of the above can be used for 1 hospital or multiple hospitals.

I will simplify the VNA spec document to reflect this simple categorisation. I would be grateful for comments.
 Link to this message Shannon M. Werb  posted on Sunday, May 20, 2012 - 10:22 pm Edit Post Delete Post Print Post
Hi Neelam, glad the InMedica report is materializing in the UK as well. We are pleased with the results and optimistic on the market growth trends for VNA. Specifically VNA data under management to grow ~50% year over year while PACS only grows ~5% year over year.

Clearly VNA's are preferred to PACS 10:1 these days, as the RFP/Tenders indicate.

Likewise I'm pleased to see how InMedica categorized the providers - PACS provided enterprise archives from VNA independent providers, with multiple delivery models (onsite, cloud, and hybrid).

Looks like we are staring at an exciting outlook for VNA!

Shannon Werb
Acuo Technologies
 Link to this message Neelam Dugar  posted on Monday, May 21, 2012 - 04:57 pm Edit Post Delete Post Print Post
With regards to a level 3 VNA customers need to think of 2 other aspects
1. Data culling--enterprise wide rules being set up for images & documents
2. Audit trails central repository--which can be migrated. ATNA profiles.

Any thoughts please.....
 Link to this message Shannon M. Werb  posted on Tuesday, May 22, 2012 - 10:48 pm Edit Post Delete Post Print Post
Hi Neelam,
My opinion would be that Data culling and standardized auditing (as defined by DICOM/IHE) should be a core requirement of any VNA offering.

Depending on how type 1 and 2 are deployed (same or different PACS on the front) and the technology of the VNA provider I'm not sure if I'd qualify those as VNA. But not trying to debate the inMedica definitions I'd content that all types should include this requirement.

Acuo Technologies
 Link to this message Neelam Dugar  posted on Sunday, August 05, 2012 - 07:05 pm Edit Post Delete Post Print Post
Tony Corkett gave a very interesting talk on VNAs at UKRC. He has given me permission to share it on our website for others to benefit.
application/pdfUKRC2012--Tony Corkett
T Corkett PACS 120626.pdf (575.8 k)
 Link to this message Neelam Dugar  posted on Sunday, August 05, 2012 - 07:42 pm Edit Post Delete Post Print Post
VNA has become an integral part of any PACS & RIS Replacement Project going on at the moment. The key reason for this is to ease the data migration at the end of contract.

I have written a document which include describes how a VNA can form the key to a Trust's exit strategy for RIS & PACS. Comments please
application/mswordExit Strategy for PACS & RIS using VNA
Add Your Message Here
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Options: Automatically activate URLs in message