In our Group Meetings we have been discussing PACS data migration. This technology is now coming to age.
We have been talking to some migration experts recently. They are confident that they can extract data from PACS servers at the rate of 2TB/day. Now that is really impressive. We could get all data migrated in about a week!
The 2 questions that they asked were: 1. Are all images stored on PACS supported by DMWL--i.e. do they have a RIS entry--we confidently said "yes" 2. Do you radiologists make permanent changes on images on PACS & store any overlays etc. We allow radiologists to make temporary changes as part of their reporting--the images are stored as they originally sent by our radiographers. They were pleased to hear this as they felt we were unlikely to have private tags created within PACS.
Dont let LSPs & PACS suppliers create fear about PACS migration. It is really coming of age as a technology. "Dont allow vendor lock-in"-- often said by Dave Harvey.
It is impressive to achieve 2TB a day. I know because we have also achieved this. Only this was a Dutch hospital, we had the full cooperation of the 'legacy' PACS vendor who provided PACS database dumps, the IT dept who constructed a dedicated 10GB migration VLAN directly onto the PACS SAN, 6 brand new 6 core pcs running windows 7 & a total of 72 PJ processes extracting and fixing the data. I dont think this can be achieved in an LSP contract. It would be nice if it could
The migration expert who came went to our server room & felt confident that there should be no "technical" difficulty in extracting the data from Agfa PACS (they have done Agfa PACS migration before).
The PACS world is a small one. If vendors become hostile and force customers to stay with them by being uncooperative (whether Agfa, GE, Sectra or Carestream--I name these as they hold the large contracts in the UK), word does get around and customers will come to know. Personally I think all these PACS companies named are very good companies. However, the issue here is one of principles. I do not feel any PACS vendor should lock a customer. Customers should have a choice of a new vendor at the end of a contract.
Kevin, Why do you think it will not be possible for LSP contract 1. Will Accenture/CSC/BT turn hostile and use the contracts to penalise customers from moving away from them? or 2. Will Agfa/GE/Sectra turn hostile & prevent Trusts from extracting data from the PACS servers.
If either is true, it is really a sad state of affairs for the NHS, and a huge waste of taxpayers money. As NHS will be unable to take advantage of the a competitive PACS market with continuously reducing prices.
At UKRC, I did ask Mary Barber and CFH regarding clarity of migration process. I was told that suppliers could NOT turn hostile--as per the CFH-LSP contract. They will have to allow for data migration.
I do believe after having listened to the migration expert the other day---PACS migration has come of age & we should not be fearful of it.
Paul, Are you saying that LSPs are imposing financial penalties if you wish to migrate you Trust data away from them. Interesting------. But not surprised! There is a lot of money at stake. However, it is not right on priniciple.
there is no technical difficulty. We/you are not fearful of it, PACS migration has come of age! Are the components I have described in the 'Catalogue' for you to order ? If not then what do you do within the scope of the LSP contract, it just looks like a harder task & maybe a longer task than the migration itself to put the bits in place to achieve 2TB a day. Best to start migrating now with the tools available even though its not the quickest. The Tortoise sometimes wins I understand (as long as he starts on time)
I dont believe they are penalties as such just non commercial pricing. Proposed on the back of contracts that have only recently been published to the trusts and the perception that we have to go with the LSP offer. it would be nice to know definitively if we have to go with the LSP solution?
I would share Kevin's reservations. 2TB is of course technically possible given additional hardware in place and comprehensive planning (which should be in process pretty soon). Doing so without affecting operational performance would need to be carefully planned.
However - with reference to Paul's point about LSP solution - 2TB/day also makes the assumption that all hardware is in the same location. If trusts take on their own solution - geographically disparate from LSP, then there are additional complications.
"Are the components I have described in the 'Catalogue' for you to order ?"
Kevin, What I cannot understand is why do we need to buy migration from an LSP catalogue. What we really need is co-operation from LSP/existing PACS vendor. If we have their cooperation there should be no reason why we cannot achieve a 2TB/day migration. I was reassured at UKRC by CFH & Mary Barber that due LSP-CFH contract the supplier, we would get cooperation from LSP/PACS supplier for migration.
Are you expecting LSP/PACS vendors to turn hostile & uncooperative --thus not allowing the 'PACS database dumps'. Is there anything specific we need to ask them to find out whether they are going to be support 2TB/day database dumps.
Martin, In technical terms what "handles" or cooperation do we need from LSP PACS to enable a Database dump--2TB/day migration.
posted on Wednesday, July 20, 2011 - 03:53 pm
One important part of the debate so far has been the physical location in order to support the quoted 2Tb/day. Whilst current LSPs should assist in a migration, asking them to put foreign hardware into their data centres is almost certainly a step further than they are prepared to go in this. Without that, you are back to how fast you can make N3 run. London experience with MIA suggests 2Tb/day is not going to happen.
We’re currently migrating data from our legacy PACS to our new PACS. Although all parties have made efforts to complete the process in a time efficient manner, several years have passed and we are still migrating.
There are no specific singularly identifiable causes that have contributed to the delay, and the transfer was planned from the outset. I doubt companies will ever turn hostile against their customers (think of the PR!), but the differing implementations and interpretations of standards do make things complex from an I.T. standpoint.
Our legacy PACS is quite old (pre 2k) and hardware failures have hampered our efforts a great deal - we now have to actively regulate the speed of transfer to prevent both ends of the link from falling over or impacting on clinical service. As modern hardware is likely to be more reliable this will impact on the 201x migrations potentially less, the need to commit staff time to ‘matching up’ the legacy studies where necessary and identifying the accuracy of the transfers may not change though.
Technically migration is easy for those experienced in it and 2Tb per day is a great target to aim for; from a practical viewpoint some migrations take far longer and hit unexpected delays.
Migration isn’t something to be feared though, allowing ample contingency time is all part of a successful project!
Guessing a lot of this depends on how your PACS works. A couple of weeks ago I was told that for the London LSP PACS the image data in archive (MIA) would have to be brought back into the local working store so it can be matched with the metadata BEFORE the images can be migrated elsewhere.
The rate of transfer back from MIA would be limited by bandwidth and by how much data the PACS could handle - nowhere near 2Tb a night.
As the working store is of limited size have no idea how this is expected to work at the moment although I believe the whole process is being looked at by CfH/ LPfIT.
We as taxpayers have paid huge amounts of money into the LSPs till today. The minimum decency I would expect from CFH & LSPs is for them to co-operate in the migration process.
Again, we should have high standards in the NHS. Why should we accept commercial companies/LSP allow a outdated migration process, when we have become aware that there are modern methodlogies of migration. We should insist "direct data dump" be the primary process. If LSP/PACS suppliers refuse to allow this then look for a plan B.
"Our legacy PACS is quite old (pre 2k) and hardware failures have hampered our efforts a great deal" This is why migration of data is important--even if you stay with the same PACS vendor. It is important to renew the underlying archiving hardware & software. It is also important to look at what needs to be migrated & what needs to be culled. We would not be storing all film packets pre 2K would we? Unnecessary storage & then their future migration will cost NHS & us the taxpayers who fund the NHS.
Fear of migration--is detrimental to NHS & taxpayers both. We as a community need to understand this.
We will be discussing culling & archiving at the Autumn Meeting.
"Martin, In technical terms what "handles" or cooperation do we need from LSP PACS to enable a Database dump--2TB/day migration."
One should be careful to distinguish between the 'database' and the 'archive' - the 'database dump' typically being a one-time formatted copy of the relational database (e.g. Oracle). The 2 TB/day would be from the archive (usually stored outside of the 'database')
To get anywhere close to TB/day level though would probably (almost certainly) need additional hardware (as Kevin has pointed out) - just to facilitate the transfer. Taking out that much data from an operational system should also be approached with caution. Datacentres are very likely tuned to the contractual performance metrics and putting additional load may well have an impact.
IMO the biggest issue - as Paul points out, though - current LSPs would need to allow a good deal of equipment into their datacentres to avoid migration over N3. Potentially several racks worth. If a decision is made (has been?) to give individual Trusts control/responsibility over their solution then migration over N3 is pretty well inescapable.
Should that be the case, it may be prudent to begin the process (using commodity [cheap] hardware) sooner rather than later - even before contracts have been agreed.
PS I tried really hard not to make that last line promotional.
----One of the forum readers whose company has supported the migration of data from their own PACS system--although he was not directly involved had sent me some comments on email. (I do not wish to name the company as it would be unfair to call them "legacy" as they are reputable PACS company, but their customer wanted a change, so they supported their customer). They were good, professional and supportive. These are his comments:
"Ultimately I guess there was a requirement for giving access to the database with associated support for the fields and data within. Perhaps also there is a need to understand he workflow in the database. I also understand that the data throughput was so high that it caused some platform stability issues - in this case I guess we aren't just copying data, but extracting it from a database and the accepting it into a new database - which carries more overhead than a simple transfer of files. Naturally that would need support from both sides of the migration.
In terms of cost to the NHS I would assume that data migration is not part of any support contract (and so will not be 'free') and that the support required would be chargeable at a consultancy day rate, which I would suggest is not unacceptable. Even at a thousand pounds a day, you would struggle to spend 10K that way. You may want to negotiate a fixed price for the work as these things can throw up unknown problems and could string out for weeks.
If the cost is per megabyte transferred then I would expect that to be much more costly. I have heard of suppliers wanting to charge for data extraction in such a way, but i honestly couldnt tell you where. In my mind that's money for nothing. "
CAVEAT: "caveat that the figures mentioned are 'finger in the air' based on our knowledge of the current market. As any IT consultancy would probably tell you - we would scope out any project first which could result in different costs either side of 10K."
My view is there are a number of PACS Migration companies around these days. Talk to them & it will help you understand how you need to prepare yourself.
A PACS migration company has emailed me & said:
"We do PACS Migrations - lots of them over the years. Each one has its own characteristics. Some go fast and some go slow.
DICOM Negotiated Migrations are slowest but arguably most comprehensive. File transfers/Data Dumps are arguably faster that DICOM Negotiated.
We are told that it is always best to align to operational needs: network bandwidth, need for moving prior studies to support pre-fetch requirements by "listening" (with HL7) for scheduled patients and other factors.
We have a tool that allows us to make changes to DICOM header and it can accept a file transfer data dump or act as any other modality."
Someone with experience of PACS migration has said:
"In our project to construct a large image database we effectively did a data migration from a PACS. We aimed to take 3TB of data in total. We tried the option of DICOM push between the old and new database at first, but the transfer time using the network was the problem and we abandoned this approach after a week. We eventually did a database dump and this still tool a week to complete for 3TB across the ethernet.
We were paying both the PACS and RIS providers for their services on a contract and we also had to pay for several additional days at £1250 a day. I totally believe that all were trying their best to get the transfer - it is just true to say that once that amount of data is involved it is time consuming and the failure rate of software processes and networks becomes the limiting factor."
Good understanding & co-ordinated effort is required. Get a good understanding of who will need to co-operate RIS PAS etc and build this into your project.
There are a number of PACS migration meetings currently taking place in the North West hosted by the SHA. These days have suppliers presenting their migration strategy for LSP land and the audience is attended by representatives from the trusts.
There are also supplier stands available to discuss one to one, the challenges and lessons learned by these companies who have 'real life' experience of migrating from PACS.
There is no doubt that migration can work from smooth to problematic and this can be based on a number of factors that have already been discussed. However, it is imperative that risk is balanced against cost and experience, to ensure a safe transfer of sensitive patient data.
I believe the next meeting is the 27th July in St Helens.
Martin makes a valid point: "current LSPs would need to allow a good deal of equipment into their datacentres to avoid migration over N3. Potentially several racks worth. If a decision is made (has been?) to give individual Trusts control/responsibility over their solution then migration over N3 is pretty well inescapable."
Does anybody know HOW LSPs are going to let migration of data out of the CDS? Anybody had any clear discussions with them? Whilst CFH states that contractually they are bound to "release" the data. As pointed out by one of the people who emailed me "data migration is not part of any support contract (and so will not be 'free') and that the support required would be chargeable at a consultancy day rate, which I would suggest is not unacceptable." LSP& their PACS suppliers will need to support Trusts in migration. Big questions are 1. What will be their cost for migration support? Is this a fixed cost? or is this going to be daily charge. We need clarity on this? 2. Will LSPs support data extraction or insist on DICOM transfer over N3 ONLY? Or will they be willing to allow for quicker process like data extraction?
Beware both methodologies cost. This was experiance from a user from NHS "In our project to construct a large image database we effectively did a data migration from a PACS. We aimed to take 3TB of data in total. We tried the option of DICOM push between the old and new database at first, but the transfer time using the network was the problem and we abandoned this approach after a week. We eventually did a database dump and this still tool a week to complete for 3TB across the ethernet."
Lsten to what migration experts are saying. But look at all the methodlogies with an open mind & see what works for your Trust---cost, time, etc
Lessons learnt 1. Migration is inevitable. You can try an avoid it once, but you will have to do later at some time. 2. Bigger volumes of data and offsite--CDS etc makes migration more difficult to manage. Perhaps smaller chunks of data onsite within Trusts will make migration an easier option. 3. Bigger volumes of data make migration difficult & expensive--regular culling of data (based of local/national policies/guidance) and keeping volumes managable is a strategy to consider. Discussion at Autumn Meeting. 4. Clarity on support for migration at end of new contract to be written in the new contract--to avoid ambiguity in future.
This may be a completely impractical idea, if it were not planned for prospectively ...
But if a whole bunch of people are going to migrate images out of a central data store, and its native performance for bulk data export of database-reconciled images is poor, then perhaps the central store could install one solution, which exports and reconciles sets of data onto portable hard drives in pure DICOM form, such that the recipient can then take those and ingest it in bulk. I.e., split the problem into two parts, getting it out and getting it in.
Not to say that it is trivial to come up with such an intermediate form that contains absolutely everything that the recipient might need (reconciled identifiers, corrected/merged/split studies, annotations, measurements, presentation states, etc), in the form that they might need it.
This is not a new idea by the way; the VA in the US asked DICOM to "standardize" such an interchangeable "export" form, many years ago (to which our answer was that is already standardized ... that's what DICOM on media "is"). Nowadays this might be more effectively addresses with an IHE "offline migration" profile, which might be an interesting idea. Off-site long term archive disaster recovery providers are essentially the same thing.