Dear Members of NCRP of PACS, and National CfH Design Team, In many of the postings previously by Rhidian, there was a mention of CCOW being considered as a strategic direction for NPFIT. Locally, I am involved in trying to get a good desk-top integration. I am trying to get our RIS and PACS vendors to comply with CCOW for this. Obviously this is rather difficult, as vendors prefer to use proprietory interfaces to achieve this. As you will realise, this is not just a local issue, it is a vital issue for all PACS installations. It may be beneficial for CfH to take this as a national issue, rather than for each Trust have to be deal with it as local issue.
Here is some basic readable info regarding CCOW for those that are interested.
"Of course, there are many benefits to becoming CCOW compliant. However, none of those benefits apply to the vendor itself. The benefits are all for the user and for the IT shop that can help users streamline their work." is quite a good statement from the second article.
"Now, to answer the readerís original question: why donít legacy vendors support it? The simple answer is that CCOW provides no real value to them." Similarly, due to the contracts negotiated by CfH for us, our PACS supplier, although not legacy as such, does not have real value for implementing CCOW. It is more beneficial for them to provide proprietory interfaces with consequent financial benefit.
posted on Thursday, July 06, 2006 - 02:49 pm
3 points to add to this:
1) There IS some benefit to the vendor (the same as any standardisation) in that they would, if they used CCOW properly, only need to write and support ONE interface, rather than many.
Against this are points 2 and 3
2) By charging for the work of writing these horrible, proprietary, messy interfaces, they can make a profit on each one - i.e. they are profiting by "re-inevnting the wheel"
3) Perhaps far more importantly, and not mentioned in the preceding articles in this thread, the vendors can use ANY proprietary interfaces such as this to provide "lock-in", denying the users a free choice of systems when the time comes to upgrade or replace EITHER of the ends of such abominations!
Obviously at the moment, the vendors are (to the detriment of users) seeing (2) and (3) as more important than (1) :-(
In a proper free market, with knowledgeable users, any vendor trying to peddle this sort of stuff should be treated the same way as one trying to sell a CT with a proprietary system instead of DICOM, and promptly shown the door.....
Of course, the challenge is how to achieve the same pressures on vendors to do things properly in the CfH environment, and this is being considered by the National Design Steering Group......work continues......
"Of course, the challenge is how to achieve the same pressures on vendors to do things properly in the CfH environment, and this is being considered by the National Design Steering Group......work continues......"
You are very right Dave, but the trouble is that Cfh may not have any sense of urgency in this matter, but we do. With a "go live" date hanging over our heads, and penalities from LSP for not meeting these, we need to proceed with decisions of desk-top integration.
If CfH do not act quickly, each NHS Trust will be dragged down the proprietary interface route. It is the result of non-competitive CfH contracts, vendors have a large upper hand over the users.
We have had an official response from our LSP PACS supplier to our desk-top integration specification questionaire, but surprise, surprise it is bound by "the commercial secrecy law". I am not an integration technical expert, and I do not know how I can take it any further.