Does anyone know whether this already applies to the commonly used solutions in the NHS? (e.g. Agfa, GE, etc)
posted on Tuesday, December 21, 2010 - 09:54 am
This makes interesting reading & DICOM 10 should be the standard adopted by both PACS archives & Vendor Neutral Archives.
However, my only concern (after reading the thread on dcm4che) is that VNA & true DICOM archives can ONLY be used as a "backup" due to performance issues with inability to display images to the radiologist/clinical users screen within 3 secs. I do hope initiatives like MINT take off & thus make true VNAs a real entity for use in the clinical world. Please correct me if I have mis-understood the whole issue.
posted on Tuesday, December 21, 2010 - 05:41 pm
I hate to post as a vendor (because I rather represent myself via binaryHealthCare because that reflects me as an individual) but in my day job (with a solution provider), I have seem a few PACS solution that transmit in DICOM and the solution company that I current work for does the same - with an install site in Mass Gen and the verdict we have is even with a VNA in place (connecting multiple disparate PACS), performance was faster than before and the solution is transferring in DICOM.
urban legends such as slow performance due transmission in DICOM are some of the reasons why I spend my time working on binaryHealthCare
posted on Wednesday, December 22, 2010 - 03:21 pm
We are very grateful for your contribution to the forum as someone who is very knowledgable.
Can you elaborate. Are you saying 1. We can have a VNA Or DICOM part 10 conformant archive which all modalities can send their images to? 2. A different DICOM display vendor can display images from the VNA without any proprietary interference with confidence to display images within 10secs?
As this how the solution works in Mass Gen?
posted on Wednesday, December 22, 2010 - 03:22 pm
Sorry I meant 3secs!
posted on Wednesday, December 22, 2010 - 03:29 pm
Neelam, For a minute there I thought your standards were slipping (perish the thought!
As early adopters of VNA and Implementing Enterprise Imaging Strategy coming year, i feel that we require more exchange on VNA subject in this forum.
In our institution, we have implemented VNA 2yrs back as core component of imaging architecture (not as backup archive).
In our setup, VNA is integrated with cross-sectional modalities and Vitalimages SW for post processing. We are in preparation of PHASES II which is image enabling EMR.
It is important to consolidate silos of Medical Imaging archive, into a rule based intelligent imaging component accessible thru a univiewer, governed by the principle of Clinical Information Lifecycle Management practiced in the institution.
Following are conclusions we have derived
1)VNA is Strategic component of Imaging Architecture, not to be confused as back archive or enterprise archive from storage vendor. 2)PACS systems will eventually be for transactional and reporting needs 3)Deep Archiving and retrieval needs must be managed thru VNA integrated with PACS. 4)Instead of 4-6 different APIs for each pacs system, EMRs must be Image enabled via single UniViewer link on top of VNA for better adoption outcomes 5)Univiewer is common denominator tools set for all review needs, for diagnostics thin viewer should be triggered based on role based access and contextual information. 6)Information Management policies and ILM rules to manage imaging data must be implemented thru VNA for better compliance 7)Institutions must be educated and well aware on expectations from VNA. 8)VNA can also be a good Teaching, Research components for Image mining across ologies PACS 9)Tag Morphing, Dicom Part 10, 3 sec retrieval, open Univiewer integration are not issues any more. In HMC we have VitalImages on top of VNA, we have no issues on 3 sec compliance.
This year in RSNA, we studied ACUO, Terramedica, Mach7 offerings, and think above conclusions are in sync with industry trends and other institutions strategic roadmap.will post more as we progess .... :-)
Thanks Dharmendra. I am really pleased to hear that you do not consider VNA to be a backup archive. I do believe that VNA will be the future of Healthcare IT, and I think we are getting there slowly--particularly with the innovation done by the VNA vendors you name here. However, I do believe that standards adoption is key here.
Today VNA vendors are basically "DICOM archives". However, we need both DICOM archives, & XDS Repositories (with XDS Registry present) for moving to a truly multivendor EPR.
Work done by Vital Images is commendable but I think we must not restrict ourselves at a single viewer.
If you adopt an XDS repository & XDS Registry concept for an EPR: Any departmental system--Isoft EDIS, Anglia ICE Ordercomms, HSS CRIS, etc etc can display any image manifest or document which maybe stored in an XDS repository provided they are an XDS consumer (so you would have multiple viewers, as every departmental system would be a viewer as well as an image/document creator--rather than have a single viewer).
In the NHS (which is paid for by us the tax-payers) we need innovation & cost effectiveness in healthcare IT. I do believe you can only get an cost-effectiveness & innvovation if you have an open market. However, we also need a interoperable systems so that patient centric information is visible to the doctors/other professionals who deal with patients on "hospital floor". Currently images & documents are held in data silos due to commercial interests --companies wanting to sell you all their departmental systems as the only methodology for getting an EPR. That is why we need adoption of standards --XDS/XDS-I so that patient interest overide commercial interests.
We will continue to debate the issue of VNAs in our meetings--we have had Accuo, IBM speak on the issue at our last meeting. Please note that any vendor speaking at our meeting has strict rules--"We do educational meetings--so you are not allowed to make it a sales pitch for your product".
Agree on XDS compliance for VNA, though im not confident XDS/XDS-I can handle Tele-Consultation workflow where full dicom data set needs to pushed and populated on different workstation or pacs.
Fully agree on bringing innovation to healthcare.
We as healthcare provider and caregiver are aware about the information gaps and potholes in our day to day workflow. We are also aware about vendor-locks and proprietary issues from our vendor management experiences . We must innovate within our practice and not wait for vendors to come together and form standards which we then follow, even if its not applicable to uniqueness of practice. Vendors can definitely participate and contribute to enduser led platform but not drive the agenda.
in the context, dont forget that PACS vendors, in most cases, are reseller for 70% of the items they offer(roughly 30% is their own only RIS-PACS SW). We are responsible for compliance and regulatory requirements on all aspects of patient service. We need to see above and beyond the conventional models of procurements and implementation and employ innovative strategy to address a few.
One clarification....., please note in HMC, we have not implemented VitalImages as univiewer. The example was provided to demonstrate 3 sec retrieval. VitalImgaes in HMC is for 3D post processing only, we don't know their enterprise viewer functionalities.
posted on Wednesday, December 29, 2010 - 11:53 am
Dharmendra--- Whilst I agree that we cannot wait for vendors to come together & we as the end-users to drive the agenda. However, I do believe that interoperability standards are key to innovation.
PACS is the biggest success of Clinical IT throughout the world. DICOM as the underpinning interoperability standard. Images CREATED in ANY VENDORS modality can be STORED in ANY VENDORS PACS.
In simplistic terms what is PACS: 1. RECIEVES DICOM images (from modalities/other PACS or workstations) 2. LONG TERM STORE of DICOM images 3. SENDS DICOM images (to other workstations/PACS) 4. DISPLAYS Images from their DICOM store
In simplistic terms what is VNA: 1. RECIEVES DICOM images (from modalities/other PACS or workstations) 2. LONG TERM STORE of DICOM images 3. SENDS DICOM images (to other workstations/PACS) The only thing you get different with a VNA is that you can choose the display front end. This is an exciting concept for many of us end-users as we see many smaller companies with cutting edge display. However, as I have alluded to in my earlier posting is that unless VNA can show that they can provide performance i.e <3sec display I think PACS vendors currently have an upper hand over VNA.
It is upto 1. standards bodies--DICOM/IHE etc to adopt protocols like MINT as standards 2. VNA vendors like Accuo/Terramedica/Mach7 etc & Display vendors like VITAL Images/Medical Insight etc to work on the performance issues related to VNA. A separation of display & storage is what end-users need.
"in the context, dont forget that PACS vendors, in most cases, are reseller for 70% of the items they offer(roughly 30% is their own only RIS-PACS SW)" I agree and therein lies a big problem. I will give you a real world example. We have a McKesson(UK) RIS. We have a yearly User Group meeting hosted by McKesson. The meeting is chaired by one of the NHS PACS Managers. We have a McKesson developer who sits in the meeting. The end users drive the innovation & discuss the funnctionality deficiencies. As a NHS Trust who pays yearly revenue we are provided with about 10 product development days every year. If we are 10 Trusts using the same McKesson RIS, we have a pooled resource of 100 development days. At the user Group meeting we debate and discuss the requirement & vote on the requirement. The developer gives us a honest opinion what is achieveable & what is not or suggests alternatives. This shows a true partnership between user & supplier community. This leads to a system which is truly functionally rich for an end user. If a Trust needs a feature that cannot be accomdated within the 100 days a cost is provided to the Trust--if they want to fund that development themselves. However, if the company is a re-seller of products---then they cannot give you that kind of product development handle that a company that is a true innovator & product developer. This is why a product stagnates & does not meet with the requirements of the end user. We have seen this happen with NHS IT in the UK where the small local innovative companies were driven out by the National Programme for IT's strategy of creating monopolies. Large PACS companies do not give the users a role in product development--- as the product is not really "theirs" to develop, and they do no have the developers to participate in the meeting. In England it is even worse where we have more middlemen--"LSPs". Moral of the example-- is that we need direct dialogue between developers & end users & the contract between the supplier & Care provider should be transparent about product enhancement & development during the lifetime of the contract. 10years is a long time for a product to standstill. I do believe in a good partnership between users & suppliers with product development at the heart of it.
"though im not confident XDS/XDS-I can handle Tele-Consultation workflow where full dicom data set needs to pushed and populated on different workstation or pacs." I agree. DICOM display is important when radiologists are viewing an image to issue a medico-legal report, or when A&E doctors/Orthopaedic surgeons are reviewing images in the absence of a radiologists report. However, most other clinical scenarios clinical users are reviewing images in the context of a radiologists report (in broad daylight, on standard PC monitors). They do no even display the full DICOM image provided & do not need to. They need a simple EPR display using XDS consumer.
To bridge the gap between EPR & PACS & Deparytmental Systems in the future we need to specify: 1. PACS or VNA "must" be a XDS-I source 2. All departmental systems (RIS, EDIS, Ordercomms, CIS, Ophthalmology System, Clinic Letters System, E-Prescribing, E-Discharge, Pathology System) all must be XDS Source. 3. ALL departmental systems & DICOM Image display systems MUST be XDS consumers. This will lead to Radiologists creating reports on RIS but being able to review EPR information held in the XDS repository.
The question for me is "Are VNA vendors ready to move from being a DICOM archive to a XDS repository?"