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.
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.
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.
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.
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.
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!
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.
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.