For those of us with the land of UK LSP, many of us face a number of uncertainties associated with the termination of our existing contracts for PACS and RIS, and the migration to new suppliers.
Connecting for Health have suggested Transitional Assistance as the solution for our concerns, but I am not convinced that the “grey areas” are any less numerous, nor tangibly blacker or whiter as a result of what I have seen so far.
I am no expert in such things, but I hope the attachment enclosed may assist in gaining further clarification of what we can expect as a “contractual obligation” and help clarify those elements which may be chargeable.
I have shared this draft document amongst the South West Consortia - thank you to those who have already contributed - and key staff within Connecting for Health for advice and comment.
Please feel free to use the enclosed, comment and constructively criticise, the more robust our documentation the better for all.
Regards Tim (Imaging IT Manager, Plymouth Hospital).
posted on Monday, September 03, 2012 - 07:25 pm
Thanks Tim. This is useful both for Trusts exiting LSP Trusts & also going into new contracts-important to write a good pre-nup exit strategy.
Once Trusts have chosen the new supplier, they should start sending data from modalities to new PACS. The staff remaining in CFH have a responsibility to ensure data in CDS is brought back into Trusts. They would come under criticism if they can't get data from LSP CDS.
It may be worthwhile having a more specific internal document also, which is based on a list of known differences between the old system and the new one that is to be installed. An example is DDPs. It may well be that your current system allows the construction of a DDP for a particular study which hinges upon the ability to act on a certain DICOM tag. The new system may not look at that tag at all, for the purposes of defining a DDP. It might be useful if you could get a dump of the current DDPs and find out from the new vendor whether all those tags are supported and whether miscellaneous manipulations such as zoom to crop etc are supported.
Another thing is: you absolutely CANNOT rely on the outgoing vendor to supply you with 100% accurate data surrounding existing configs and user information. Go ahead and ask for it, but you will have to set aside time for somebody to check that data before the old system is switched off. Even checking a random sample of the data is better than just accepting a spreadsheet from the vendor and assuming it is correct.
With regards to the IP addresses and station names of modalities and 3rd party workstations you are better off collecting that yourself, even if the outgoing vendor is going to supply the same information. This is where a differencing tool can be very useful!
Other things to think about:
1) Import arguments or broker manipulations when comparing the old and new PACS
2) RIS exam code sets if there are to be changes with the new RIS. You need to know this in advance because some modalities are exam code dependent, either because they map technical factors to that code or because they simply aren't exam code agnostic and you might have worklist issues if there are changes to the codes.
3) Worklist and search criteria: does the new system have the ability to handle searches or display worklists according to the variables currently being used by the old system? It may be useful to get a dump of those worklists, identify the main variables for each and then discuss with the new vendor how these can be implemented. For example the new system may not be able to generate paediatric lists based on birth date.
4) User settings vs workstation settings vs centralised settings. For example, on the old system where are your hot keys for window widths and levels defined? Is it per user, is it per workstation and how are those settings configured and applied?
And so on...
Of course, many of these issues will have come up already in the user specification document that the new vendor must work towards. In my opinion, you as a Trust will have to actively seek to get the required technical information out of the old vendor, check it for accuracy and then present it to the new vendor with clear instructions on what it is you want the system to do.
posted on Tuesday, September 04, 2012 - 01:59 pm
I would take a very pragmatic approach to this. 1. Whilst shortlisting suppliers ensure that you shortlist PACS suppliers who have done migrations before (or sub-contract to a migration specialist firm). They will know the ins & outs better than us. You can use a pass/fail question on your PQQ. 2. Regards contracts with LSP, I would leave CFH to deal with this. They need to ensure that Trusts get back their data.
I think Trusts need to concentrate on choosing their next supplier. Migrations will happen & data will come back from CDS.
Thank you all for the comments above, I need to add in some overlooked elements....hope others can use the documents as a starting point if they have not already created their own. I am beginning to get a nagging feeling that I’ve been too preoccupied with PACS and Image data, assuming the RIS data would be less of an issue....
posted on Thursday, September 20, 2012 - 09:08 pm
RIS vendor MUST support sql for the database items to be extracted.
We have taken a view that we will only transfer radiology reports from Nov2006, into the new RIS & PACS (this co-incides with our LSP PACS go live). We will leave our old McKesson RIS as a "dumb" database if we need to extract any other information in future.
We are really pleased that we will soon be moving onto a new & modern RIS, now that our RIS procurement is complete & we have chosen our supplier. I do believe RIS is the real workhorse of a radiology department.