UK Imaging Informatics Group
Some points to ponder (PACS and RIS r... PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Procurement & Business Cases >
Message/Author
 Link to this message Brandon Bertolli  posted on Wednesday, May 22, 2013 - 08:15 pm Edit Post Delete Post Print Post
Some things to consider if you are replacing your PACS or RIS, or changing your vendor:

1) Process mapping is vital before even drawing up the spec or user requirement of the system. The process mapping will pick up what is mandatory in your workflow and suggest what is not being covered by your current system. It is an arduous process, yes...particularly if you do it in a manner that goes right down to the granularity of what happens per exam code. If you don't do it, you may end up paying the vendor for workarounds to cover lost functionality (the new system doesn't do something that the old system used to do). The resources needed to do this process mapping may mean you have to back-fill in the department with agency radiographers, for example.

2) Any vendor response (whether it is a formal document or a demonstration) should only include products, modules and features that exist currently on the market. Otherwise he is potentially winning a contract on vapourware.

3) A "lessons learned" pack should be a mandatory deliverable on the part of the vendor. If the vendor has installed or is installing the same product at another facility in your country, they should provide that to you. If it is subsequently discovered that you are absorbing risks at installation or go-live which could have been avoided if they had been advertised in advance via lessons learned at other facilities, then there should be financial penalties for that.

4) Before the contract gets signed it needs to be checked very carefully for any "woolly areas" especially around licensing, supplementary software modules, hardware and software dependencies and minimum performance expectations. It is all very well if the contract specifies unlimited client application licenses but each client runs on a Citrix session which itself is licensed but you haven't been told the financial and performance implications of that. You may have to get the contract independently checked if the expertise doesn't exist locally.

5) It is becoming obvious to me (based on what is happening at several sites) that the modality leads / imaging superintendents / area leads have a default expectation and assumption that the new system will at least have the same functionality as the old one. I think there needs to be more involvement by these leads in the scrutiny of the contract and what it delivers. It needs to be looked at with reference to key requirements identified in the process mapping.

6) Radiologist buy-in is essential, especially from the lead "IT" radiologist representative. That person needs to understand that they can't work the same lists as before the project: they must give up time on at least a weekly basis for the project.

7) It needs to be specified in the contract what the latest date is (relative to go-live) that the Trust will expect to have access to at least a training or test system. Of course the vendor deserves protection if the hold-up is on the customer's end, but the aim is for the radiology staff to be able to get onto the system and at least test peripherals and software compatibility as early as possible. There is a lot of system admin work that can at least be planned, and snags that can be found in a timely fashion if there is early access to the system.

8) Local equipment lists need to be updated before the project starts, because this takes a lot of resources and time which may not be available during the project. This means modality lists, PACS workstations, third party workstations and Trust PCs which are expected to run the new vendor's software.

9) Get a detailed migration plan from your "old" vendor as soon as possible and give this to the "new" vendor. This may help with getting on top of nasty surprises early on (such as critical fields not being migrated to the new system).

10) Make sure your contract includes detailed migration requirements so that you don't have those nasty migration headaches the next time.

11) If you are changing either the PACS or RIS entirely, make sure the vendor can prove to you that those systems actually do integrate properly, specifically when it comes to desktop integration and software dependencies on the reporting workstation. Don't forget VR!

12) If you are part of a consortium or you have outsourced IT support, you need to allow for extra project time due to contractual arguments, insufficient resources on the part of the vendor and the outsourced IT company and various other unexpected issues such as differences in training expectations which stem from different business models in the various Trusts.

13) Document as much as possible of the system you are replacing, especially workflow timing process efficiency. How long did it take you to do a certain function on the old system and how long does it take you on the new system?

14) It might be useful to have a pre and post system change staff survey, asking questions around system function, productivity and vendor support. It is better if these surveys are online because a radiologist won't necessarily want to spend a lot of time on it! I find Survey Monkey useful for this.

15) Get as many site visits as possible, without the vendor tagging along so that you can find out as much as possible about the system and the vendor's service at other facilities.
 Link to this message Nick Hollings  posted on Thursday, May 23, 2013 - 09:54 am Edit Post Delete Post Print Post
this is all good advice. Having litterally just gone live with a new, post CfH contract PACS, another critical decision is whether to go big bang or dual run. The former is harder from a training and bug fixing point of view (all your eggs are in one basket and if it goes belly up you're in big trouble, nothing to fall back on) but the latter is not risk free either, as we have found. Getting modalities to dual send is a headache and places added stress on your radiographers. There may also be messaging issues between the new and old PACS meaning some images do not appear on the new system at the workflow stage you expect them to - something we found out to our cost. Beware!!
 Link to this message Neelam Dugar  posted on Sunday, May 26, 2013 - 08:55 am Edit Post Delete Post Print Post
MODALITY INTEGRATION is a very importnat step: 50+ modalities to connect--
1. DMWL integration with old PACS broker to new DMWL provider--PACS or RIS
2. DICOM send to new PACS

A gradual approach is best in my view.
1. Old RIS HL7 feed to OLd PACS Broker made to feed new DMWL Broker as well (Broker maybe from new RIS or PACS--we are using new RIS for DMWL)
Gradually modality vendors come in and point to the new DMWL broker.
2. New PACS added as a DICOM source to old PACS.
Modalities are gradually made to do a DICOM send to new PACS and new PACS forwarded them to old PACS (We did not experiance any clinical delay in images visible on old PACS).
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: