Whilst this is new and not yet widely adopted, it is an attempt to standardize how to make PACS and platform neutral plugins.
The (naive ? ambitious?) goal is obviously to allow any PACS to run any plugin without requiring n:m individual integration development and validation efforts.
I have been around almost every PACS vendor at UKRC asking about DICOM 118 support. No-one has come back with a yes answer. One of the major vendors has said to me & echoed by others---there is no business demand for this development---I.e. nobody is asking for this.
So there we are ----if we do not ask we will not get it!!! Looking ahead we will need best of breed plug-ins for Orthpaedic Templating, CAD, 3d etc. I do believe it is important that we as customers insist on this standard.
By the way there there was a big change this year compared to last year---all PACS suppliers now support XDS-I. I am grateful to Ronan Kirby from Siemens who were the 1st major PACS vendors to openly stand up supporting XDS-I in their PACS product (rather something in their development) at our Spring Meeting this year.
I have asked IHE-UK to support the request of our Group for development of a IHE profile standards based plug-ins based on DICOM supplement 118 standard. IHE will be discussing workstreams for this year very soon.
posted on Sunday, September 18, 2011 - 10:41 pm
Some good news.
IHE is considering a profile to address the plug-in issue: "Unified Post-Processing Workflow with Application Hosting" I think this will greatly help the user community.
This came to my attention. I think radiologists around the country will be interested in such a tool. I do think Trusts should also take an interest in this as 1 lawsuit prevented could pay for such CAD software. However, these plug-ins need to be integrated seamlessly into a radiologists workflow. Hence, adoption of plug& play interoperability by PACS and CAD plug-in vendors is key. We will hear more about DICOM 118 from our AmbiVu speaker on 7th Nov.
As I understand it, the Riverain SoftView product is a server that processes chest x-rays sent to it and they become part of the study (stored in the PACS) for the radiologist to view (like a CAD server), and it is not something interactive that "plugs in" to the view, hence Sup 118 is not really applicable.
For this type of routine "batch processing" of acquired images (like mammo CAD for instance), the tradition has been to integrate these with what is referred to as a "push workflow" (modality (or PACS) auto-routes to server which processes and sends to PACS).
Whilst this creates all sorts of problems (knowing when acquisition is complete and ready to process, or when processing is complete and ready to read) that require crude heuristics to solve, there has been great reluctance to try to "manage" this workflow (whether it be via GP-PS or IHE PPWF or any other means). Neither the processing server vendors, nor the PACS or RIS vendors nor the customers have shown much interest in trying to manage post-processing workflow, and it remains to be seen whether UPS and/or the corresponding proposed IHE profiles make a dent in this.
Anyway, it is important to clearly articulate the difference between "interactive" plugins that have a user interface in the reading workflow (to which the Sup 118 API is relevant), and services that work behind the scenes and may (or may not) need to be "managed" (to which UPS may be relevant).
Needless to say, there are practical cost and complexity implications, in that an "offline server" is relatively cheap in terms of its implementation of integration and testing (just DICOM receive and send, basically) by comparison with a plugin component to an interactive user application is not.
So be careful that you don't specify a more expensive solution than is minimally necessary to get the job done.
I.e., one could demand that a viewer/reading tool include all sorts of (expensive) image processing performed on-demand in real-time with interactive parameters, or one could just live with something that was pre-processed and available if you want to look at it (analogous to separate soft tissue and bone reconstructions of a CT for example).
David Clunie said "So be careful that you don't specify a more expensive solution than is minimally necessary to get the job done.
I.e., one could demand that a viewer/reading tool include all sorts of (expensive) image processing performed on-demand in real-time with interactive parameters, or one could just live with something that was pre-processed and available if you want to look at it (analogous to separate soft tissue and bone reconstructions of a CT for example). "
I think this is one of the lessons from the days of PACS between (say) 1995 and 2005 - assumptions were made on the implementation of features that ended up reducing RoI. A great example is that of the abstraction of what we now call VNA. Does the archive function NEED to be fulfilled by the same system as the PACS workflow function? Probably not, although clearly precisely where the line is drawn varies with whom you speak.
Providing Output-Based-Specifications is the best way to minimise the impact of this but couching the "Outputs" in a way that is minimally restrictive can be a long and tedious process. For example in the Softview instance - assumptions about the eventual workflow may well rule it out altogether.
But thats a little offtopic. On the topic of Supp 118 - I personally believe it is a great way of reinvigorating the PACS ecosystem (which is in need of such), but I have a fear it will go the way of the CCOW - for many of the same reasons.
Neelam you point out above that the major PACS vendors claim there is no demand for this functionality. There probably won't be until the niche/specialist vendors express their products in a form compatible. But why should they - if the market for the re-expression is purely speculative. Its a chicken and egg thing that needs a 'genesis moment'.
A similar thing happened with CCOW 5-6 years ago. There is no point making CCOW a *must* rather than a *should* unless one has coughed up £100k+ for a HA Context Server, but there is no point having a Context Server until there is a critical mass of major vendors who support it.
Thanks, david & Martin. I do agree with comments. I did make assumptions about the workflow. Let us look at the past and try to predict what the future may hold for both softview & Mammography CAD. Previosly CT scanners did the MPR recons and sent them to PACs,. Then innovative companies like Voxar, Vital, Terarecon etc came in with their innovative products that provided realtome recons . Today MPR is a standard element of a PACS (as the vendor has intergrated the plug-in) Mammograpgy CAD will be sold as a as part of FFDM or other mammograhy eqipment and softview as part of CR and DR equipment. It will be difficult to buy these prducts as individual items particularly in NHS but cowould be morely likely to be attractive if bought with CR/DR or mammography. However, in future they are likely to be pof interactive PACS function.
Thanks, David & Martin. I do agree with comments from nith I did make some wrong assumptions about the workflow. I thought it was a interactive on demand plug-in type of workflow. However, I do believe this will be different in future. Let us look at the past and try to predict what the future may hold for both Softview & Mammography CAD. Previously CT scanners did the MPR recons and sent them to PACs,. Then innovative companies like Voxar, Vital, Terarecon etc came in with their innovative products that provided realtime recons . Today MPR is a standard element of a PACS (as every PACS vendor has intergrated the plug-in for MPR) . My predictions are Mammograpgy CAD will be sold as a as part of FFDM or other mammograhy eqipment and softview as part of CR and DR equipment. It is be difficult to buy these prducts as individual items particularly in NHS but would be morely likely to be attractive if bought bundled with CR/DR or mammography equipment. However, in future they are likely to be interactive PACS function.
posted on Tuesday, December 20, 2011 - 07:50 pm
Ability to integrate plug-ins with PACS. Recently our PACS Manager showed me how he has been able to create a plug-in on Agfa Impax from instructions provided by Trauma-Cad without needing to involve either of the suppliers. On clicking on the Trauma-Cad icon on Impax, we are now able to launch Trauma-cad Templating software for that patient. Well done both suppliers. This will have a big workflow benefits to our Orthopaedic surgeons.
We do need plug-in & PACS vendors co-operating on plug-in integration. Adoption of vendor neutral standards would be of great help.