Is a big bang go live for RIS and PACS at the same time isthe best way to do this?
What would you do in this scenario?
Nine Trusts use the same instance of RIS under an NPfIT contract - they OJEU conclude their procurement and have decided to switch to new commercial contracts.
They all agreed to go for the same RIS. The new Instance RIS will be running in a new data centre.
However not all of them selected the same replacement PACS - 3 chose supplier x, 4 supplier y, and the rest, 2, supplier z.
Question - How do they do go live?
Do they migrate the RIS data over the go live "weekend", load into new RIS and go live Monday Morning?
That way all the existing "future" appointments are on the new RIS, as is the work in progress (e.g. exams ordered, exams taken, reports not yet signed off).
Or do they export the old radiology report data into a E- Novation type read only system like some did last time?
Or do they continue paying the LSP to run the old RIS system for a period of time an dgo live with a clean RIS system?
PACS - do they each migrate the data and / images, or just images, from their LSP PACS in the many months beforehand (it would take that long) so they have these for the go live weekend? What about overlays, annotations - is it essential these are exported intact too?
What about translating private tags? How would they migrate the date?
Do they all have re-connect all their modalities over the week before the go live date so as many as possible are reconnected to the NEW PACS on Monday morning. A Trust could have 50 - 150 modalities connected so that is no mean task. What about the back log of un-reported images?
Or does each go live on the new RIS Instance one by one? How would that work because the databses would immediately be out of step wouldn't they.
Keith, Trusts need to be prepared to pay for 2 PACS and 2 RISes for a brief period-- 2 weeks or 1 month to allow for any problems that may arise.
Plan to Go live with new PACS & RIS 2 weeks before old contract ends. Do things properly this time. 1. Ensure RIS is capable of providing DMWL. So all modalities are ready to query RIS for DMWL (ensure that modalities are able to switch back to old PACS broker if go- live should fail). Modality vendors may need to be on standby with their engineers. Remember -- DMWL is simply a worklist of all patients who have an "arrived" workflow status on RIS. You can either provide this information directly from RIS to modalties or use an unnessary intermediary called a PACS broker. Dont just believe PACS suppliers if they tell you that DMWL provision their task. To be fair to them, they have provided a interim solution with PACS brokers when RIS vendors were lagging behind. 2. Similarly, Make sure your modalities are ready to switch to Sending images to new PACS on go- live but modality engineers at hand to switch back to old PACS if go- live fails. 3. New PACS suppliers with migration experts will be going through PACS image migration process in advance of go-live date 4. Similarly new RIS suppliers will be with their migration experts will be going through Radiology report migration into new RIS as vendor neutral CDA format for documents. 5. Make sure you have tested desktop integration between new RIS and PACS. 6. Make sure demographics update can provided from PAS to new RIS & PACs at the same time as old RIS & PACS. 7. Also time for standardising ORdercomms integration. Use CDA document transmission with workflow status synchronization beween ordercomms & your modern RIS.
We will be discussing RIS migration and standards adoption for Autumn to put minds to rest regarding RIS migration.
Depending on how you do your data migration, you may need to run 2 PACS/RIS systems for longer than a month. The problems are liable to be most severe in the large off-site data repositories (archives) in which the data is generally stored in a proprietary format: you may need to read all that data back, transfer it to the new PACS and re-write it back to the archive in the new format. The other reason you may need to read it all back is in order to build the new databases.
Not wanting to scare-monger, but a year is not an unreasonable expectation for this exercise, should it be necessary.=20
I am very aware of all the various unknowns and that the answer will be prefaced with 'It all depends'...but has anyone any idea of indicative costs to even replace like for like.On just say the Ris, Pacs software and storage.????
Ann, Most PACS & RIS suppliers should be able to give you indicative costs. Just contact them.
Paul, Most of data held in LSP land whether local or hosted is fairly clean & in DICOM format ( as there is a RIS entry for every exam & we are able to send images via IEP to other hospitals. IEP is dependent on DICOM push). Anyway any incoming PACS vendor should give you a rough idea about how long it will take. I remember Dr. David Lacey telling us about 3 months at one of our meetings.
Neelam, I was referring to the long-term image archives such as London's MIA. Everything there is stored as .blob, not raw DICOM. Pulling it all back and re-writing it was recently quoted as being about 300 days.
posted on Tuesday, June 07, 2011 - 09:27 am
Nice if you can do it - David's slides don't say whether all the data to be migrated was in DICOM format. As I said, we were quoted 300 days after a trial determined how long it took to pull data back from MIA (the deep archive for London) and re-write it again. It may have been on the pessimistic side, but it's still worth bearing in mind that it could take a very long time to transfer your deep archive. And that's for a disc-based one. What if your deep archive is on tape, in a format your new vendor doesn't support? Again, you've got to retrieve everything and write it to the new archive.
Based on these figures (which we had no reason to dispute) we opted to upgrade rather than migrate. It's just a warning really that if you decide to change vendor, it could take a very long time to move all your data across. Of course, if you don't have a deep archive and everything is on-line, it's a different story.
Paul, I think due to DICOM standard it is relatively easy to migrate data from a DICOM based PACS system. However, obviously if data is kept in proprietary formats you will have problems. There are specialist companies who do this for a living. They are able to do tag morphing if private tags are used.
I think there are some lessons to be learnt here 1. ALWAYS keep data in standard format-- DICOM for images 2. Avoid use of private tags as far as possible. Write it in your specification. 3. Ensure your end of contract exit strategy is written in you new contract right at the outset. Agree with the new vendor in advance how they will help migrate data at the end of their contract.
Keep 2 PACS going at the same time is expensive for any Trust. I personally think we should expect 1-2 months only. 3 months maximum.
Anticipated difficulty in migration due to data held in proprietary formats, is the wrong reason for NOT wanting to change your supplier.
The right reasons for staying with your supplier are 1. Good modern software with good functionality 2. Good service & willingness to help & support 3. Good interoperability standards which allow for plug & play interoperability-- with modalities, plug-ins, based on open standards 4. Willingness to integrate with a RIS chosen by the customer Etc
I think Paul's point is more to do with the physical access to the data rather than the format. The data is held off site in the BT MIA and it is the physical time it takes to get the data out of MIA via N3 that appears to me to be the issue. We are relatively small and because of the limited bandwidth available it took about 3-4 months to copy the images from the local archive to MIA in nightly "chunks"(I think it was 4T in total).
The other problem is that the servers themselves are owned by BT and not the Trusts and therefore access to the images stores will require BT's assistance even although we own the data.
If BT allow direct access to their servers then it is a different matter but I don't know if that question has been asked yet.
However without knowing exactly how the images are going to be "copied" to a new store we are of course just making guesses here!
While I must declare a commercial interest, I can offer a perspective from my time as end-user.
My past employment was with a hospital, (scheduled to be) one of the first up in the national Irish PACS programme. We had the challenge of preparing 30+ TB data from offline storage into a form easily migrate-able. We were able to pick up commodity storage for very little cost and set that as a secondary PACS, which is immediately accessible. The process itself took a number of months but should expedite the 'real' migration.
Open Source software like DCM4CHEE is ideally suited to such a scenario and allows for gradual preparation pre-2013 without breaking the bank - for migration purposes performance isn't an issue and hardware can be obtained for no more than £200 per TB