Building the Best RFP: Part III -- Data migration prenuptial

AuntMinnie.com presents the third installment in the Building the Best RFP series. The articles focus on major technology issues involved in choosing the right PACS, and each edition includes the precise wording you might use in an RFP to a vendor. For part one on directory architecture, click here. For part two on display software packages and installation, click here.

Data migration refers to the process of transferring study data from one PACS to another, such as when an older PACS is replaced with a newer system.

Performing this data migration is good for a number of reasons. First of all, continuing software and hardware maintenance on the old PACS will probably be an expensive proposition, especially since you would have to do this for many years. Second, access to this historical data will be more reliable and efficient if it's moved over to the storage solution of the new PACS.

Data migration from the old PACS to the new one is inevitable. The question is: "What exactly are you going to be able to migrate?"

The new PACS vendor will most likely take responsibility for this data migration, or bring in a subcontractor to perform the migration. Unfortunately, the data migration process might require some assistance from the spurned PACS vendor, and that is the reason for addressing the subject of data migration up front, as part of the RFP for the new PACS, as well as during the eventual contract negotiation process.

The most obvious data to be migrated are the study image data, and an accomplished data migration service can migrate the basic image data from most existing PACS, even the very old generations of PACS. When I say "basic study image data," I am referring to the original image pixel data that were forwarded to the PACS by the imaging modality.

Unfortunately, you are probably going to be interested in migrating more than just the original pixel data. Additional "study data" are generally referred to as work products, referring to the results of any image manipulation, processing, and viewing of the study images by the interpreting radiologist.

You will probably want to migrate a number of work products along with your basic image pixel data. Here are some examples:

• Final report: The radiologist's final version of the report, including any addendums.

• Grayscale softcopy presentation states (GSPSs): The window/level settings created by the radiologist in the process of interpretation, and any alphanumeric overlays or graphical overlays created for the images results in the creation of metadata objects associated with the image. In DICOM parlance, these objects are referred to as GSPSs.

• Key image notes (KINs): The ability to tag key images and the ability to attach a typed text note to a specific image or the whole study results in the creation of metadata objects associated with the image. In DICOM parlance, these objects are referred to as KINs.

• Scanned documents: The ability to scan one or more documents that are associated with the study results in the creation of metadata objects. In DICOM parlance, these objects are usually secondary capture (SC) objects included as a series in the study file, or they can be DICOM structure report objects.

Migrating the final report to the new PACS shouldn't be a problem. No assistance from the vendor of the old PACS is required, as the final reports can be migrated from the HIS or RIS. This is how most data migration services retrieve the final reports.

Most PACS create presentation state and key image note objects; unfortunately, most old PACS and many new PACS do not treat these work product objects as DICOM objects. They are instead treated as proprietary data objects and typically stored in the PACS directory database.

In some PACS, these two data objects fall into a class of proprietary metadata objects that are stored in the image's DICOM header; they are either stored in private tags or the data are encrypted. Migrating these proprietary data objects will probably require the cooperation of the old PACS vendor, or they will remain trapped in the old PACS, unavailable to the new PACS display stations even if they could be accessed, and will disappear when the old PACS is decommissioned.

With the cooperation of the old PACS vendor, it may be possible to extract the data objects stored in the old PACS directory database and convert them to whatever object format (hopefully DICOM) is used by the new PACS during the data migration process before moving them over to the new PACS. Some data migration service providers are clever enough to reverse engineer the old PACS proprietary data formats, but it's obviously easier and far less expensive to achieve the data migration with the cooperation of the old PACS vendor.

Notice that I did not insist on the new PACS being DICOM-conformant in this regard. Personally, I believe a new PACS should be 100% DICOM-conformant to avoid these migration problems in the future, but that decision is up to the customer. The basic purpose of the data migration service is to move the study data from the old PACS to the new one, and most data migration services can accomplish this process, even if it means adapting the old PACS study data to the new PACS non-DICOM-conformant format.

The scanned document object is another area of potential trouble. The vast majority of PACS currently in the market have adopted a document scanning technique that treats the scanned document object as a DICOM secondary capture object. This SC object is appended to the collection of images as a new series, and the document series go anywhere the images go, including being stored with the image data in the PACS archive. Scanned document objects treated as SC objects in this manner are easily migrated along with the image data.

Unfortunately, a few PACS vendors decided to treat the scanned document object in a proprietary manner. Examples include .txt objects and JPEG objects stored in the directory database.

While this approach may have some advantages, it creates a distinct disadvantage for data migration. Without the cooperation of the vendor of this PACS, how can the document objects be extracted from the old PACS and converted to an object format used by the new vendor?

Unfortunately, there are other uses of proprietary data objects in many current PACS. Depending on how significant the user may consider these proprietary objects, the data migration process may be frustrating, expensive, impossible, or all three.

It may be too late to negotiate with the old PACS vendor for cooperation with your upcoming data migration to your new PACS, but it's not too late to negotiate with the new PACS vendor for cooperation in moving those data objects created over the next five years to the next PACS. That process should start with the RFP.

Relevant RFP Q&A

I have given four examples of key data objects that you may want to migrate from your new PACS to your next PACS. The following RFP questions will specifically address those data objects, and a fifth question is designed as a catch-all to help you identify any important data objects that have not been discussed in this article.

1. Describe how the radiology reports are stored in your PACS, including the nature (format) of the object and where it is physically stored.

   Good response:
   The best response to this question is DICOM structured reports, since this will be the easiest and least expensive to migrate with no assistance from the vendor.

   Bad response:
   There are no serious consequences to any responses to this question, because you can always migrate the reports to your next PACS from the HIS/RIS.

2. Please provide a response to each of the following regarding grayscale softcopy presentation state (GSPS).

   1. Please describe the GSPS object (format) created by your PACS and where it is physically stored.

   2. Is this object exported as a DICOM GSPS object when queried by a DICOM-conformant system?

   3. What (if any) technical assistance will be required of your professional services group when the time comes to migrate this GSPS object to the next PACS?

   4. Estimate the professional services fee you would charge to migrate to the next PACS (as DICOM GSPS objects) the GSPS objects that will be associated with all of the radiology images that will be committed to your PACS in the next five years.

   Good responses:

   1. The DICOM GSPS object can easily be shared with and used by other DICOM-conformant systems.

   2. The PACS should export this object as a DICOM object. If the PACS does not initially create and store GSPS as a DICOM object, at the very least it should convert it to a DICOM GSPS object when queried by a foreign DICOM-conformant system.

   3. If the PACS does not create and store the DICOM GSPS object, at the very least it should be possible to pay a professional services fee to the vendor to convert these objects to DICOM objects in advance of a data migration.

   4. There would be no fee for migrating a DICOM GSPS over and above the fee charged to migrate the study's pixel data, so if there is a fee for converting the GSPS objects to DICOM objects, I would require the PACS vendor to provide this service at no charge. It's their decision to make it a proprietary object.

   Bad responses:

   1. If the PACS creates anything other than a DICOM object and stores it in its directory, it is a proprietary data object, and some degree of processing power/time is required to convert it to a DICOM object, if this is even possible.

   2. If this object cannot be exported as a DICOM GSPS, the objects cannot be accessed and used by any other DICOM-conformant system.

   3. If no such conversion services are available, the objects will remain trapped in the PACS.

   4. If the conversion services are available, they may be relatively expensive. Negotiate for a waiver of the fee.

3. Please provide a response to each of the following regarding key image notes (KINs).

   1. Please describe the KIN object (format) created by your PACS and where it is physically stored.

   2. Is this object exported as a DICOM KIN object when queried by a DICOM-conformant system?

   3. What (if any) technical assistance will be required of your professional services group when the time comes to migrate this KIN object to the next PACS?

   4. Estimate the professional services fee you would charge to migrate to the next PACS (as DICOM KIN objects) the KIN objects that will be associated with all of the radiology images that will be committed to your PACS in the next five years.

   Good responses:

   1. The DICOM KIN object can easily be shared with and used by other DICOM-conformant systems.

   2. The PACS should export this object as a DICOM object. If the PACS does not initially create and store KIN as a DICOM object, at the very least it should convert it to a DICOM KIN object when queried by a foreign DICOM-conformant system.

   3. If the PACS does not create and store the DICOM KIN object, at the very least it should be possible to pay a professional services fee to the vendor to convert these objects to DICOM objects in advance of a data migration.

   4. There would be no fee for migrating a DICOM KIN over and above the fee charged to migrate the study's pixel data, so if there is a fee for converting the KIN objects to DICOM objects, I would require the PACS vendor to provide this service at no charge. Again, it's their decision to make it a proprietary object.

   Bad responses:

   1. If the PACS creates anything other than a DICOM object and stores it in its directory, it is a proprietary data object, and some degree of processing power/time is required to convert it to a DICOM object, if this is even possible.

   2. If this object cannot be exported as a DICOM KIN, the objects cannot be accessed and used by any other DICOM-conformant system.

   3. If no such conversion services are available, the objects will remain trapped in the PACS.

   4. If the conversion services are available, they may be relatively expensive. Negotiate for a waiver of the fee.

4. Please provide a response to each of the following regarding scanned documents.

   1. Please describe the scanned document object (format) created by your PACS and where it is physically stored.

   2. Is this object exported as a DICOM object when queried by a DICOM-conformant system?

   3. What (if any) technical assistance will be required of your professional services group when the time comes to migrate this scanned document object to the next PACS?

   4. Estimate the professional services fee you would charge to migrate to the next PACS (as DICOM objects) the scanned document objects that will be associated with all of the radiology studies that will be committed to your PACS in the next five years.

   Good responses:

   1. Any DICOM object (i.e., secondary capture object) can easily be shared with and used by other DICOM-conformant systems.

   2. The PACS should export this scanned document object as a DICOM object. If the PACS does not initially create and store a scanned document object as a DICOM object, at the very least it should convert it to a DICOM object when queried by a foreign DICOM-conformant system.

   3. If the PACS does not create and store the scanned document as a DICOM object, at the very least it should be possible to pay a professional services fee to the vendor to convert these objects to DICOM objects in advance of a data migration.

   4. There would be no fee for migrating a scanned document if it were a DICOM object over and above the fee charged to migrate the study's pixel data, so if there is a fee for converting the scanned document objects to DICOM objects, I would require the PACS vendor to provide this service at no charge, since it is their decision to make it a proprietary object.

   Bad responses:

   1. If the PACS creates and stores the scanned document object internally as anything other than a DICOM object, it is proprietary, and some degree of processing power/time is required to convert it to a DICOM object, if this is even possible.

   2. If this object cannot be exported as a DICOM object, the scanned documents cannot be accessed and used by any other DICOM-conformant system.

   3. If no such conversion services are available, the objects will remain trapped in the PACS.

   4. If the conversion services are available, they may be relatively expensive. Negotiate for a waiver of the fee.

5. Please provide a response to each of the following questions regarding any other proprietary data objects stored in the PACS directory database, or proprietary metadata objects stored either in private tags in the DICOM header or stored in any private tag with proprietary encoding.

   1. Please list and describe all of the major data objects created by your PACS that would be required by another PACS to properly display the image or postprocess the image that are not stored and/or exported as DICOM-conformant objects. For example LUT values, image acquisition parameters, etc. Please include in your description where each of these data objects are physically stored in the PACS.