UK Imaging Informatics Group
PACS and VNA workflow survey PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Subtopic Last Post Last Poster Posts
Archive through June 25, 201425-06-14  09:56 pmNeelam Dugar20
Archive through July 10, 201410-07-14  12:58 pmDavid Clunie20
 
Message/Author
 Link to this message Shaun Smale  posted on Thursday, July 10, 2014 - 01:09 pm Edit Post Delete Post Print Post
A file/image can not be "shared" via the VNA if it is not in the VNA.
In its early life a record is very dynamic and subject to change, new content is being added, corrections, edits and approval and so on are being made. Archiving too soon means the archive copy will be at best out of date, at worst clinically un-safe.
There must be a mechanism to correct the discrepancies between the source, the archive, and any other copies. The most pragmatic solution is to delay archive (and distribution of copies) until the record reaches a stable state. However the point when a record become stable depends on many factors including local working practices, and so will require an archive trigger event based on a number of factors.
The archive is the best and logical point of reference for stable historic data, but to support collaborative work during the dynamic phase of the data, a clinician will need direct access to the dynamic master version of the data; a copy will probably not be in the VNA at this time. Here direct access to the source application is also required. Ultimately an over arching functional layer is required to provide a summary and transient view of the complete patient record irrespective of the location of its components.
A second point to consider is the time to deliver the copy to the archive and back again. Moving large data sets (GBs) across the network takes minutes. PACS and other applications have develop techniques to display a view of the clinical data in seconds; changes to its content will be instantly applied. To change an archived copy of a DICOM study a IOCM first deprecates the original and a replacement is then sent before the updated content is available.

commercial interest declared

Shaun
 Link to this message David Clunie  posted on Thursday, July 10, 2014 - 01:42 pm Edit Post Delete Post Print Post
My recollection of the "origin" of the concept of "VNA" was to factor out the storage component and responsibility, not duplicate it. See for example "https://www.frost.com/sublib/display-market-insight.do?id=84675209" and "http://www.auntminnie.com/forum/tm.aspx?high=&m=101689&mpage=1#102308".

The challenge was to achieve PACS-native performance levels for retrieval and display without having a duplicate inside the PACS, with all the storage "out-sourced", at a higher level of layering than the "old" model of outsourcing at the lower level of the disk array or filesystem or content-addressable storage level,
which had become commonplace.

Or to put it another way, the PACS's "cache" of the material was intended to be very short term, measured in seconds or fractions thereof, not months or years, and like any "cache" (in computing terms, "http://en.wikipedia.org/wiki/Cache_%28computing%29") was supposed to be reliable and transparent. Cache "inconsistency" is anathema.

Of course, this requires cooperation of the PACS vendors, to relinquish this responsibility, and for both PACS and VNA to tune to the same sequence of retrieval operations but using a standard rather than proprietary interface. To the extent that this has not (yet) happened for every (any) PACS vendor, the "VNA" concept may have changed its meaning.

So, we need to distinguish between "VNA" the original concept and "VNA" the current offering by "VNA vendors", which may have all sorts of other stuff tacked on, such as that which Neelam has found useful, or indeed completely deviated from the original concept (see "http://en.wikipedia.org/wiki/Vendor_Neutral_Archive").

In essence a "VNA" seems nowadays to be whatever a supposed "VNA vendor" has added to their offering to try to take business away from traditional PACS vendors, which I guess is consistent with the "vendor neutral" terminology, if not the "neutral archive".

Of course, in my harangue about Neelam's deviant architecture, I have mixed in the concept of the "Universal Viewer", which is a whole other can of worms, and was not "originally" part of the VNA concept.

David
 Link to this message David Clunie  posted on Thursday, July 10, 2014 - 01:52 pm Edit Post Delete Post Print Post
Perhaps we should have called it "Vendor Neutral Storage" instead of "Vendor Neutral Archive", since we have overloaded the concept of "archival" with active use in addition to "long term" or "permanent" recording.

And we are now confused about whether the "active" or the "archived" images are the ones to be used by (distributed to) the clinicians.

I guess this is a consequence of use of the historical use of the word "archive" in "Picture Archive and Communications System".

David
 Link to this message Shaun Smale  posted on Thursday, July 10, 2014 - 02:54 pm Edit Post Delete Post Print Post
David,
I agree. We need to move away from stretching department application/Hardware stacks to fit the modern cross enterprise requirements to functional layers.
Radiology are the main drivers who want other data types to be available, but there is no D for DICOM or R for Radiology in a VNA. I like robin's use of 'open source data'. The VNA does not need to be vendor neutral but vendor compatible, the data should be open source based on standards, but the VNA should not exclude native proprietary data, it is a Vendor-Neutral archive for healthcare data, agnostic to vendor software, storage technology and transfer protocols. To me the important word is Archive (for Picture and other data), the Communication System is manage by higher functional layers, the storage technology by lower layers.
All data from any application need to be stored and protected, as well as used and shared.
So how about Vendor Agnostic Storage Technology Neutral Open Source Healthcare Data Archive VASTNOSHDA :-)

Shaun
 Link to this message David Clunie  posted on Thursday, July 10, 2014 - 03:51 pm Edit Post Delete Post Print Post
And per a previous discussion about viewers (http://www.pacsgroup.org.uk/cgi-bin/forum/show.cgi?2/74594) we would need to couple it with the "XDS/DICOM/WADO-RS/QIDO-based Archive Neutral PACS/VNA DICOM CDA PDF Absolute Zero Footprint Server Side Rendering Dumb but Extensible Mobile Device RESTful Universal Viewer" (XDWQANPVDCPAZFSSRDEMDRUV) :-)

Somehow I don't think the marketing guys are going to buy this!

David
 Link to this message Robin Breslin  posted on Thursday, July 10, 2014 - 03:59 pm Edit Post Delete Post Print Post
David and Shaun - I think you are talking about the German and Russian versions (respectively).
 Link to this message George Brown  posted on Thursday, July 10, 2014 - 04:07 pm Edit Post Delete Post Print Post
Let's code name it "pandemonium"?
 Link to this message Neelam Dugar  posted on Thursday, July 10, 2014 - 05:57 pm Edit Post Delete Post Print Post
I think both Robin and Shaun make very valid and useful points.
If PACS did everything that customers needed, VNAs would not have evolved.

Thanks Shaun for your re-assurance that the pragmatic view is to archive in XDS-VNA (or whatever anyone else David wants to call it :-) ) after the record reaches a stable state.
 Link to this message Chris Bull  posted on Friday, July 11, 2014 - 10:36 am Edit Post Delete Post Print Post
I go back to my previous postings where the VNA provides the key core of all the master patient data. The VNAs we installed monitored the patient information across the whole estate and when updates were made a new set of images were issued to the whole systems with a delete message being sent,then the new updated ones. All modalities were linked into the VNA as it can and should provide the necessary mapping and changes required for the systems it is serving. Current PACS becomes one of those systems and should provide updates as required so the VNA becomes the master record holder. This become more critical as more systems required digital storage and not just radiology. This was carried out in several NHS hospitals when I was working for my last company linking to the RIS and PAS via HL7 to obtain updates from them.
A VNA is middleware software and should be able to present a complete patient record that is secure and up to date as possible. Having a rules based engine that allow access from viewing apps etc.
I have seen the latest RIS system that has a viewer built into it for review purposes that links to an archive , PACS, VNA it does not matter. The key is that the viewer provides the master record view and I believe that should be in the VNA from the moment it is acquired. If your VNA does and is not able to provide this level of management then in my view it is not one in the true sense but just an archive.
I love the idea of an open source technology for a VNA but when dealing with key patient data the product must be owned and managed by someone.
 Link to this message James Daniels  posted on Friday, July 11, 2014 - 03:34 pm Edit Post Delete Post Print Post
[Advertising message removed]






(Message edited by alexpeck on August 02, 2014)
 Link to this message Neelam Dugar  posted on Wednesday, July 16, 2014 - 11:24 am Edit Post Delete Post Print Post
It had been a good debate and has highlighted some important points for customers and Vendors alike.

1. Modality --> PACS --> VNA;
a. This is the set-up we have in Doncaster where the images will be sent to VNA and XDS 24 hours after the finalised/verified status on the report is achieved. Currently PACS does not support IOCM and hence we dont want to have too much of manual updates for changes in the image data
b. VNA and PACS both receive ADT updates from PAS--so the demographic will always be up-to-date in both systems
c. VNA does NOT get HL7 ORM and ORU updates (PACS does get HL7 ORM and ORU updates). So any changes to exam description, status etc cannot be corrected in VNA. Hence, we wait till the finalised report status is attained in RIS and PACS before images are sent to VNA.

2. Modality --> VNA --> PACS
If this option is chosen
a. Ensure that IOCM is used for updating image information
b. Ensure BOTH PACS and VNA are independently connected to PAS for ADT updates
c. Ensure BOTH PACS are connected to RIS to get HL7 ORM and ORU updates.

Comments please.
 Link to this message Neelam Dugar  posted on Wednesday, July 16, 2014 - 11:25 am Edit Post Delete Post Print Post
t had been a good debate and has highlighted some important points for customers and Vendors alike.

1. Modality --> PACS --> VNA;
a. This is the set-up we have in Doncaster where the images will be sent to VNA and XDS 24 hours after the finalised/verified status on the report is achieved. Currently PACS does not support IOCM and hence we dont want to have too much of manual updates for changes in the image data
b. VNA and PACS both receive ADT updates from PAS--so the demographic will always be up-to-date in both systems
c. VNA does NOT get HL7 ORM and ORU updates (PACS does get HL7 ORM and ORU updates). So any changes to exam description, status etc cannot be corrected in VNA. Hence, we wait till the finalised report status is attained in RIS and PACS before images are sent to VNA.

2. Modality --> VNA --> PACS
If this option is chosen
a. Ensure that IOCM is used for updating image information between PACS and VNA
b. Ensure BOTH PACS and VNA are independently connected to PAS for ADT updates
c. Ensure BOTH PACS and VNA are connected to RIS to get HL7 ORM and ORU updates.

Comments please.
 Link to this message Simon Hadley  posted on Wednesday, July 16, 2014 - 11:38 am Edit Post Delete Post Print Post
Neelam,

If the users (outside of radiology) need to view images before the 24hours imposed delay has completed, are they using the same application as the VNA Viewer or a different application that views the PACS database/short term store?

Do you have a viewer that accesses and federates multiple databases (i.e. PACS / VNA and XDS Registry) assuming that you will have multiple DICOM libraries for other 'ologies moving forwards?

It would be interesting to hear how you have set this up with the introduction of the 24 hour delay and if you have 2 applications, how this will work in the future.

Thanks
Simon
 Link to this message Neelam Dugar  posted on Wednesday, July 16, 2014 - 11:52 am Edit Post Delete Post Print Post
All users will continue to use the current PACS for display and viewing as Fujifilm PACS is XDS consumer(viewer) compliant, so should display PACS and VNA information seamlessly.
So there is no additional viewing application required for our users--Radiology or outside radiology.

The way I see this evolving is that if other o-logies with their own viewer.
Our Cardiology PACS viewer could view other information in the VNA by simply being an XDS consumer compliant.
An Ophthalmology PACS can do the same.

NB: We have NOT introduced an risk as LSP implementations had a single copy of image data in the PACS or CDS. We are duplicating into VNA after status is finalsied. Once we implement IOCM we could into this again.
 Link to this message John Parker  posted on Wednesday, July 16, 2014 - 03:57 pm Edit Post Delete Post Print Post
In my experience, most users couldn't care less where images are stored, as long as they can view them in a timely way...
Similarly, I suspect the application users will use to view images will be of little consequence to most users, as long as they are relatively easy to use (intuitive) and support the functionality requred... I suspect users would staft to make some noise, if they needed to use more than one application for the same purpose however.

As a service supplier (as opposed to a supplier) I am interested where images are stored, and how they are accessed and managed. Early PACS systems did not have LCM functionality (amongst other things)and changing PACS meant migrating data - a potentially time consuming, expensive and painful task. The concept of VNA was born out of the idea to separate image/ data storage and the viewing application. Of course, we all know that there is no such thing as a VENDOR neutral archive - they are all supplied by vendors, some of which also supply PACS! Whilst some functionality may best sit on one side of the fence or the other, there may be items that could, in theory, sit on either....the main thing will be to make sure the functionality exists on one or the other

I might want to change my PACS regularly, depending on may factors (system performance/ supplier support/ costs/ new functionality...
I probably wouldn't want to be changing VNA with the same regularlty (otherwise what is the point??)

Perhaps, from a Businees Continuity perspective, I'd be looking at the main PACS application 'pointing' at local PACS storage, with the web based / zero footprint application 'pointing' at the VNA...


From the current discussion, I don't see the advantage in the modality-VNA- PACS workflow....
 Link to this message Brandon Bertolli  posted on Wednesday, July 16, 2014 - 06:46 pm Edit Post Delete Post Print Post
Neelam, I am curious: what were the prime three motivating factors for Doncaster to get a VNA?

What I mean is, from a brutally honest business case perspective, why does Doncaster need a VNA?
 Link to this message Neelam Dugar  posted on Wednesday, July 16, 2014 - 10:16 pm Edit Post Delete Post Print Post
VNA bought as part PACS replacement--huge cost "savings" compared to LSP PACS:
1. Back up Archive for Disaster recovery (did not have one from LSP)
2. Data ownership as all data is in standard Part 10 format in VNA-- (not in LSP)
3. End of contract data migration--Trust will be able to do the migration from VNA themselves at end of contract--(not in LSP)
4. Life cycle management--(Not in LSP)
5. XDS strategic direction for other ologies-)not in LSP)
"Significant" cost savings.
 Link to this message Chris Bull  posted on Thursday, July 17, 2014 - 04:43 pm Edit Post Delete Post Print Post
If the VNA is used for the modality connections the Trust can manage the management of each system as it is used. They are also in a position to add additional modalities as required saving those fees that the current PACS companies charge for. Just as they can handle any data migration s well as already stated in previous comments.
I believe that this is a step forward on the road to good data management and workflow. The key is insuring that the VNA holds the master record for all patients as it can be made to manage and secure data in a disaster recovery issue, with multiple copies being stored across different storage devices. The data base can be held on SSD for fast access and action backed up onto log term disk.
 Link to this message Neelam Dugar  posted on Friday, July 18, 2014 - 02:54 pm Edit Post Delete Post Print Post
Chris,
the key is ensuring that the data is kept "up-to-date" in the VNA
This is requires the VNA to be synchronised with other systems that "create" or "change" the data
1. PACS for radiology
2. RIS for radiology
3. PAS for ADT for both radiology and other o-logies
The same will apply to other o-logies.
If this is not considered in the out-set of any VNA implementation, the VNAs themselves will get a VERY bad reputation.
I hope all VNA vendors will be mindful of this.
 
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: