posted on Wednesday, November 07, 2012 - 08:22 am
There were many discussions around PACS, VNA, radiology reports & document standards yesterday.
From an archive perspective, the main difference emerging between PACS and VNA is that VNA can store both images( DICOM) & Documents-pdf/CDA(Non-DICOM). From an enterprise perspective VNA archiving scores higher than PACS.
From a PACS Display perspective--PACS can only display DICOM & HL7 text blobs. Whilst VNA is not involved in display technology, emerging zero-footprint enterprise viewers which are able to display both DICOM images & CDA/pdf doc will have an advantage over PACS display for enterprise users. The future lies with integrated viewing of images & documents. There is a likelihood that PACS will be demoted to a radiology department viewer unless it accomodates the requirements of our enterprise users.
If we position VNA as an ARCHIVE, 10yrs down the line we will have same challenges as we have today with PACS. The objective is to enable a Vendor Neutral Architecture or Platform, which repositions management of images or objects from departmental pacs to enterprise entity. Departmental PACS must be for transaction and order-loop management and results report or clinical action for that episode of care. However this “action-item” has to be part of enterprise clinical knowledge management or Education and hence must be deeply owned by enterprise entity.
In a flow of Internal Medicine Imaging to Cross-Sectional imaging and or Pathology Imaging to OR Imaging for surgical removal of polyp may involve 4 different PACS system, two outputs report and 2 doesn’t, unless we enable Vendor Neutral Architecture, how will we have patient-centric view, manage knowledge, educate residents and still save costs on technical components. Lets identify tools we need and accordingly guide upcoming technologies(e.g. VNA). This will open new horizons for enabling patient-centric view across the enterprise.
posted on Wednesday, November 07, 2012 - 10:28 pm
Dharmendra, PACS is an excellent archive for DICOM images with a DICOM display. However, VNA is additional capabilities of storing & indexing non-DICOM documents --Pdf/CDA --XDS registry/repository. Enterprise Viewers need to be XDS consumer compliant to display non-DICOM content within the VNA. We need the next generation PACS to be natively XDS consumer compliant.
I'd like to add an additional point - the data (be it imaging or not) must also be semantically interoperable, not just syntactically interoperable.
1) Syntactically interoperable - ability to store/send/retrieve the original data (e.g. using XDS)
2) Semantically interoperable - the ability to actually view / interpretation the data as intended
For medical imaging, being semantically interoperable means for all DICOM viewers being able to open the same image and display them as it is, no distortion, no missing annotations etc, same image contrast (DICOM Part 14) etc.
Hence, having a big data dump and the ability to retrieve data from the big data dump is not enough <- that is merely an archival and retrieval process.
What we need is a VNA as in Vendor Neutral Architecture where we can retrieve the data and actually use it.
This is a longish topic (that's why I wrote a book on VNA to begin with) but I did present on this particular point back at HIMSS Asia Pacific 2012.
Unfortunately, I do not have my sides with me at the moment but I believe HIMSS members can download them.
The title of the presentation is "Effective Image Enablement in EHR with Semantic Interoperability".
Hope this helps.
posted on Thursday, November 08, 2012 - 08:27 am
" Semantically interoperable - the ability to actually view / interpretation the data as intended" Adam, DICOM & CDA bring about syntac interoperability XDS within a VNA would bring about semantic interoperability.
Any document or image stored & indexed in XDS registry/ repository compliant VNA "should" be displayable by an XDS compliant viewer.
Till recently, most PACS companies were using a 3rd party plug-in for an Non-DICOM doc display--I have seen this at GE, Siemens stand at last UKRC. Interestingly, just web-surfing last night I found that latest version of Fujifilm has "native XDS display " capabilities--i.e does not require a plug-in for CDA/pdf display. In my mind, this would allow us to see ECG, pdf/CDA doc, DICOM images etc from the same PACS viewer--even if the images/doc maybe held in another vendors VNA. Although I have not seen it in reality, I hope & wish this to be true, as I see PACS moving from being a radiology viewing solution to a "true enterprise viewer". I have no doubts, that if this is true, other PACS vendors will do the same within a year.
XDS will retrieve the medical images as it is, it the image contains some really nasty private tags, then it will not be opened properly in any 3rd party DICOM viewer.
XDS does not address semantic interoperability issues, rather, still under the syntactical issues (although non images documents should be fine as they are rather 'standardised')
Hope this helps
posted on Thursday, November 08, 2012 - 04:09 pm
Thanks Adam, Private tags are produced in modalities. So if we have a different PACS vendor to our modality vendor, radiologists dont see the "private tag features". Some PACS vendors like McKesson dont sell modalities at all. In the past modalities vendors used private tags as means of locking customers into buying "their" PACS. It is a thing of the past--the PACS & modality industry has moved on.
If DICOM works for images & XDS works for documents, i think we should be OK with a VNA that supports both these standards.
posted on Thursday, November 08, 2012 - 04:23 pm
"GE says that the VNA’s enterprise-wide zero footprint clinical viewer and IHE-XDS registry provide anywhere, anytime/near instant access to a patient clinical record." On EHI today. It is clear that PACS companies are moving out from radiology towards an enterprise wide strategy. This really good news for those still considering their PACS replacements. Ensure that non-DICOM doc -pdf/cda is included.
posted on Thursday, November 08, 2012 - 07:33 pm
Unless the world has changed significantly in the last 9 months the world of private tags is alive and well, and causing lots of the problems we're trying to now solve with vna etc....
The industry must just love DICOM as it gives them an excuse to sell extra bits to 'fix' the problems it causes...
As for 'tag morphing' -think I've covered that before....
posted on Thursday, November 08, 2012 - 09:42 pm
John, The point I was trying to make is that private tags are created by modalities (not PACS). PACS will usually store them & migrate them on. If the DICOM display is from same modality vendor then private tags will add value.
1) Modality from Vendor A produce an image with 'nasty tags' 2) Image is stored 'unchanged' in PACS from Vendor B and then sent to VNA (or, the way I prefer it, to VNA then routed to the 'correct' PACS) 3) PACS Viewer from Vendor X, Y, Z will still retrieve (via XDS) and open.... an image with 'nasty tags'.
Yes, we obtain a fantastic way to ensure images from all PACS within a large hospital clusters are exchanged (syntactic interoperability) but the original content still have some issues -no one touched it, it was created by the modalities (no semantic interoperability).
Now on the point of PACS not changing Tags. I actually did an experiment in a large hospital last year, they have 3 PACS for their radiology. I took an images a modality and send them to the different PACS, then compare the DICOM header (using a tool of course).
All 4 images - from modality and the 3 PACS have tags that are different. One of the PACS vendor does not sell modalities.
Just an FYI, I've seen PACS solution stripping off the entire DICOM header and store selected tags in their databases for performance improvement. You cannot migrate them images without their help and when you do export the images, they are not the same cause bulk of the tags are gone. Now in the real world, you are bound to find a system like that somewhere. I know this is a radiology forum but I deal with many other imaging discipline and when you implement a VNA for a healthcare cluster / group / enterprise, you are not going to use it just for radiology.
Private tags are produced in modalities. So if we have a different PACS vendor to our modality vendor, radiologists dont see the "private tag features". Some PACS vendors like McKesson dont sell modalities at all. In the past modalities vendors used private tags as means of locking customers into buying "their" PACS. It is a thing of the past--the PACS & modality industry has moved on.
If DICOM works for images & XDS works for documents, i think we should be OK with a VNA that supports both these standards.
Hi John, yes, I was talking about Tag Morphing (or rather, bi-directional Tag Morphing).
Yes Neelam, the private tags are great for the original modality, we are not saying we get rid of it (hence bi-directional - we return the original private tags to the specific modality and rectify the problematic bits if we need to send it to PACS viewer who cannot handle the specific tags).
Yes, XDS is impt (I'd not bother looking at a VNA without XDS capabilities but we need more to effective enable of clinical workflow), hence my presentation at HIMSS covered why just getting a 'big data dump' Vendor Neutral Archive is not enough but instead, a vendor neutral architecture is needed (and bi-directional tag morphing is one of the components within the architecture).
I actually covered all the above (and much more) in my book (my second book, the one on VNA, published last year).
General Impression is that the private tags originates in Acquisition Modality or workstation (aka Evidence Creator), however the fact is it can also be generated anywhere in post processing workflow by advance image software tools or by PACS or by any entity which complies to IHE technical profile- (Evidence Documents) to contain coded observations such as measurements, procedure logs, CAD results, SR objects/templates etc.
The real solution is the one which allows the interoperability of tags across the Eco-System.
There are lots of perfectly acceptable use-cases for private tags, the question is what happens to those when they affect the 'core' usage of the data. But perhaps this has gone a little off-topic
In relation to Neelam's OP I think the federated nature of XDS is somewhat neglected - not a single VNA but a variety, each with an independent value add. The key is how those come together as an end-user experience ('UX' in the parlance), a question that I think is beyond today's (admittedly often admirable) ZFVs, and could possibly be a perspective on the (recently coined) 'PACS 3.0'
This is a much wider question than Radiology (obviously). But for a number of reasons, those involved in PACS may be in the best position to pick up the ball and carry it forward (or indeed sideways, as Naas RFC U9s are wont to do).
posted on Saturday, November 10, 2012 - 04:56 pm
Thanks Martin for your comments. There has to be some sensible rationalisation between centralization vs. localisation (federated vs. centralised)
XDS is flexible enough for accomodate a federated or centralised approach.
We had a CT, MR, US, CR, NM miniPACS with their individual workstations until we moved to a central radiology PACS display.
However, integrated view of other images, lab reports, clinical letters will certainly improve patient care within each hospital. VNA with XDS based clinical portals is our "next generation Enterprise PACS" rather than a radiology only PACS.
Advantages of a central VNA repository for enterprise documents & images are 1. Life cycle management--controlled way based on Trust local policies 2. Access control--through use of Active Directory access to "document types" within a VNA could be controlled 3. Centralised audit controls
However, VNA based on XDS will allow for federation of source/information systems/image creators & also federation of image & document displays.
However, it will be down to every Trust.
posted on Tuesday, November 13, 2012 - 02:19 am
We are presently looking at VNA solutions in Australia
A company called acuo has received some attention here and I believe has a presence in the UK
Does anyone have any comments on the company and/or product?
Tag Morphing, and syntactic and semantic interoperability as mentioned by Dr Adam Chee recently are all valid points, and I should state clearly at the outset that these have to be dealt with by all parties in the PACS Eco system (and I speak as a ‘VNA vendor’). We would like it that they don’t exist, but they do, and we have to deal with their implications.
One point that isn’t often mentioned about this topic (and seems to have strayed some way from zero footprint viewers!) is the core reason that VNA was actually purchased, as opposed to just being theorized. I would say that the core reason is image availability – ‘I need to ensure that this data is available to whoever needs it (likely a PACS or EPR System), whenever they need it (maybe 20-years time) and in whatever format is relevant to them (DICOM In, XDS Out for example)’.
I suppose that after many years in industry I have to call myself an ‘archiving professional’ and this has led me into many industry sectors. In all those sectors one ‘feature’ is constant, the archive does not interoperate the data, the core application (PACS in this case) does, and will continue to do that.
I think if we put too many features into VNA then we are never going to achieve its core goals and it’s never going to make economic sense, especially since the PACS is (and should continue to) manage the clinical workflow and interoperation of the data. This does not conflict with Neelam’s statement about VNA being more than just DICOM, in fact that’s critical because there are many many other data sources within a hospital that have exactly the same issue, so combining technology makes economic sense.
I should refer back to my first statement and restate that even for a VNA vendor, it’s wrong to assume that ‘tag morphing’ doesn’t exist, it does and needs to be dealt with, but VNA’s core aim should be to improve the economic viability of managing healthcare data first and foremost.
Hi everyone, I’d like to offer a slightly different perspective here and bring us back to some of the points Neelam was referencing. Although I agree with some of the statements from Jamie (like image availability being important, and improving the economic viability of managing healthcare data) I don’t agree that we shouldn’t be pushing too many features into the VNA and rely on the applications to “interoperate the data”.
As I’ve presented many times before including last week at eHI, the challenges of the past, specifically one of the main challenges that helped create the need for the VNA market was the demand to better manage the data. You have all probably seen a version of the “Tsunami of data” slide I often talk about and the need for the VNA to better manage all of that data. Today and going forward though it is no longer about simply “archiving” the data (managing it) or solving the challenge of ever growing amounts of data, rather we need to be thinking about the unprecedented demand for the data. We used to worry about the Radiologist/PACS, then the Cardiologist/PACS, but now we are thinking about Pathology, non-DICOM, and even Genomics data in different ways, it is the access to this data that needs to be resolved. Archiving it is the easy part, how do we make it available to the specialists, the general physicians, and even the patient in a meaningful way?
This is what I refer to as data liquidity, the VNA needs to have technology to drive data liquidity through interoperability capabilities regardless of the source or consumer of the data. This will allow data to be available at the point of care, or better yet the point of need in the case the care is complete and we are consuming reference information.
So coming back to the discussion, the VNA needs to drive interoperability, not the application. Sure if the application can facilitate this, great, we should get out of the way – but when the applications can’t route data, can’t pre-fetch data, can’t provide tag mapping, can’t provide transcoding, can’t deal with non-DICOM content, can’t… the list goes on – the VNA should step in and the customer should demand it.
Although I agree with many of the technical attributes described above I like to put the technology aside for a moment and think about the core premise of the VNA along with the business model to deliver the VNA. Ultimately these areas will provide much better clarity for the customer before they make a procurement decision.
Regards, Shannon M. Werb Acuo Technologies
posted on Tuesday, November 13, 2012 - 05:23 pm
'perfectly acceptable use-cases for private tags'
......that may be, but I think thre is no place for these in an enterprise scenario, and anyone considering a VNA based on current DICOM (and all its iterations) will also be accepting some risk that images on one system do not display/ behave in the same way on a.n. other system.
If we keep loading functionality onto the 'VNA' we are likely to end up with a VNAP (VNA provided by a PACS)and maybe that is what some vendors are now offering.
It was interesting to hear last week that the Canadians were lookng at image sharing by jpeg (which is of course, a proper standard :-)
all of this is, of course, a pipe dream, until England sorts out its MPI......
posted on Wednesday, November 14, 2012 - 10:28 pm
I like the term "data liquidity" mentioned by Shannon. To me this reflects 2 important features 1. Data can flow into next vendors VNA at the end of contract--easier migration. Tag morphing & migration engine hold promise today. However, what we really need is a IHE migration profile. Dave Harvey is looking at whether IHE-UK can support the development of such a profiles--as per our request (this was discussed at the IHE-UK Meeting) 2. Data can be accessed by multiple systems---display or consumer system. For these to happen interoperability & standards are key.
VNA has the "technology to drive data liquidity through interoperability capabilities regardless of the source or consumer of the data" I like this statement as well. a. This defines that VNA concepts will allow multiple best of breed source systems--like the best of breed radiology modalities, best of breed information systems. b. This also defines that VNA will allow for best of breed consumers or display systems--Radiology image display (PACS), Cardiology display, Pathology display etc
With such an enterprise VNA, a. there is federation for sources & displays, b. with consolidation of archiving with centralisation of data culling policies (life cycle management), & data access policies.
VNA is an evolving concept. Customers need to be explicit about what they want from a VNA & choose the vendor who actually meets their requirements. However, PACS does radiology DICOM storage & display very well. I would advice against a VNA that ONLY does radiology & ONLY does DICOM.
Hi Neelam, a new term I was introduced to this spring - ANP - Archive Neutral PACS. GE actually sat on the SIIM panel (PACS and VNA vendors, we were there as well) where Paul Chang introduced it, they (along with Siemens, Dell, Laitek, others in the audience) embraced the concept indicating that PACS should definitely play well (complimentary) with the VNA.
My hope is that they realize they should leave VNA to those independent providers that can focus their efforts to improve the technology and the market for VNA while PACS vendors focus their effort on great clinical tools and interoperabilty with the VNA, rather than re-creating it.
posted on Thursday, November 15, 2012 - 11:32 am
Whilst I do agree with the concept of VNA & the need for standards compliance, I don't think it matters whether traditional PACS suppliers or an independent supplier provides a VNA.
PACS was a concept started by the radiology modality vendors GE, Siemens, Agfa etc who promoted & supported the development of DICOM for interoperability. It is the most successful health informatics system. However, with increasing popularity non-modality vendors McKesson, Sectra & many others entered into the market who provide radiology PACS globally today.
VNA can be supplied by both PACS & non-PACS vendors alike. Customers need to be explicit about their requirements. Customers need to insist on standards for document format (DICOM, CDA etc) and also insist on communication, indexing & access standards--XDS/XDR etc. I am pleased that both PACS & non-PACS vendors are supporting VNA concepts & standards compliance. I would expect customers to keep an open mind.