PACS has been the single most successful hospital clinical IT tool in the world. Its success has been largely due to the interoperability standard of DICOM, which encourages collaboration between vendors toward the common goal of an integrated image record for radiology. But, as in all aspects of life, innovation is driven by competition.
Dr. Neelam Dugar is a consultant radiologist at Doncaster Royal Infirmary, U.K., and chair of the Royal College of Radiologists' Imaging Informatics Group.There are two main reasons why a customer must be able to move easily to a new vendor's PACS at the end of a seven- to 10-year contract. First, often the storage architecture of the old PACS is outdated and it provides customers with an opportunity of storage architecture refresh; we all know how storage technology has changed over the last decade, even for domestic use. Second, display software may be outdated and new technology is available on the market.
The ability to change a PACS vendor should be considered a good thing by organizations -- not something to be afraid of or frowned upon. However, there is a lot of scaremongering that changing a PACS vendor can be as difficult as going through a divorce. There are rumors that vendors don't let users remove the data, or they charge huge amounts to release the data. A lot of PACS migration vendors have emerged who can provide specialist migration services, but polite support from the outgoing PACS vendor makes the migration process a lot easier than if there is lack of support and even an attempt to lock in the customer.
In simple terms, two components within PACS need to be migrated:
Image archive, or images as they were sent from modalities. I am told this is relatively easy to migrate due to the DICOM standard.
Relational database, which stores metadata, demographic updates, storage of annotations, etc. This is held in proprietary format, but is important as image archive migration is meaningless without the associated metadata.
It can make a big difference if a PACS customer has a prenuptial agreement when signing a contract. That way, it is possible to get the PACS vendor to agree to support the migration of data to a new vendor's archive at the end of contract. This is the kind of suggested wording:
END OF CONTRACT DATA MIGRATION AGREEMENTS -- PACS supplier must support migration of all the stored image data (in DICOM part 10 file format, preferably). Read-only access to data must be allowed to a qualified Migration Service Provider. Supplier must provide explicit information about format of images stored and if any proprietary compression is used. Information about how annotations and image flips, etc., are recorded must be provided upfront by vendor (private tags? other format). Database dumps must be permitted for migration if required. Supplier must support both DICOM push and bulk data migration of data migration technologies. If PACS vendor chooses to store radiology reports and radiology requests, then they must be stored in standard HL7 and/or CDA format. This will ensure that reports and requests can also be migrated into the new vendors PACS.
We asked David Clunie, a U.K.-born DICOM standards expert who now lives in the U.S., to forward our request for Integrating the Healthcare Enterprise (IHE) to consider the development of an IHE Migration Profile. This would make it easier for a customer to specify in their prenuptial agreement by simply saying: "PACS must support Image Archive/Manager Content Migration Profile of IHE." Unfortunately, the IHE Planning Committee rejected the proposal because other competing proposals prevailed. I hope that IHE considers this during the next round of planning.
Ease of migration of PACS data is vital for customers. It will ensure investment in innovation in PACS through market competition. Hence, it is important that customers recognize this fact.
Dr. Neelam Dugar is consultant radiologist at Doncaster Royal Infirmary, U.K., and chair of the Royal College of Radiologists' Imaging Informatics Group.
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnieEurope.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group.
