When replacing a PACS system, it is highly recommended that you consider revisiting the fundamental image and information system architecture and workflow, as this is a prime opportunity to redesign it. In particular, one should consider the following:
1. Use a Vendor Neutral Archive (VNA) – To avoid multiple data migrations in the future, it is strongly recommended that you disconnect the PACS database or image manager from its archive and use a different vendor for the archive from the PACS vendor. It is possible to purchase a VNA from the same vendor as the PACS; however, it is very hard if not impossible to prove that they are not very tightly coupled. For example, some vendors do not physically delete images from the archive but, rather only set a deletion flag in the database, which is not acceptable. The reason is that if one ever is going to migrate the archived images to a different vendor, the deletion-flagged images will almost certainly re-appear. One could argue that deletion of images is not a common scenario, however, it is necessary if the age of the images is past the retention rules, or if they are simply incorrectly labeled or have no diagnostic value. Regardless, just for the sake of being able to go with other vendors in the future without massive, lengthy and costly data migrations, a VNA from a different vendor makes every sense in the world.
2. Consider an enterprise PACS solution – Another major advantage of using a VNA is that it allows a relatively easy transition to connect multiple PACS systems from several departments. The first one on the list is cardiology, however, this is probably also the most complicated as cardiology requires storage of not only images but waveforms and electrophysiological data as well. Other specialties ranging from gastroenterology to dermatology or dentistry have a need to archive MPEG files in addition to JPEG static images. A “true” VNA should be able to take care of these additional image format storage requirements.
3. Determine what information should be migrated – Many PACS systems store so-called key image information and annotations in the database instead of encoding this as a DICOM object that can be migrated. It is possible to decode this vendor-proprietary information and create new DICOM objects, however, this goes beyond a “simple” migration and can become quite involved and costly. Therefore, one should decide what information is clinically important and critical, which depends on how the previous PACS system was used. For example, the chance that a five-year-old study is going to be retrieved is small to start with, and if a measurement resulting in an annotation has to be redone, that might not be a big deal. However, if technologists were using annotations to correct left and right positioning indications, this has to be recovered and recreated. In addition, migrating is a good time to revisit retention rules to avoid migrating information that exceeds the retention requirement. Lastly, some PACS systems store diagnostic reports, some don’t. If the new PACS doesn’t and if the old PACS does, these have to be either migrated from the old PACS to a RIS or EMR.
4. Revisit document management – Many institutional systems have been scanning documents such as requisitions, release forms, and anything that was part of an order, as a DICOM object which is stored with the images. This made a lot of sense when the only access to electronic information for a radiologist was the PACS workstation. However, as most institutions can be expected to either have an EMR, or be in the process of installing one this year, it does not make sense to continue this practice, as it can be kept in the EMR. In addition, some of these documents, such as the requisition, should be available as an electronic order in the EMR, which includes the reason for the study and clinical history in electronic format, eliminating the need to scan requisitions.
5. Phase out CD import and export – Burning CDs and importing images from them has become a logistical issue in addition to the fact that some CD’s are still created with image resolutions that simply have no diagnostic value such as simple JPEG’s, or are stored in a proprietary format. There are other options for importing and exporting images using file sharing or cloud services, some of those provided by the PACS vendor, some of them provided by a third party. Eventually, images will be exchanged through Health Information Exchanges (HIE’s), therefore, using a file-sharing service may serve as a logical step into that direction.
6. Apply rules learned from IHE scheduled workflow – I am convinced that the majority of PACS systems don’t fully use the IHE scheduled workflow features, and thus do not take advantage of the efficiency and workflow benefits of those features. In particular, implementing a Modality Performed Procedure Step (MPPS) allows modalities to exchange exam status, the image count, and procedure changes with PACS and RIS, but MPPS has been sparsely implemented. Changing a PACS system is a good opportunity to review the bidirectional RIS/PACS interfaces and activate DICOM MPPS as well as Storage Commitment at all of the modalities. Storage Commitment (handing off archive responsibility) should be implemented between the PACS and VNA anyway to prevent information loss.
7. Look beyond RIS/PACS to EMR/PACS – RIS systems might become obsolete as sophisticated Computerized Physician Order Entry (CPOE) systems are becoming available as part of an EMR. A radiology department would still need software to manage its resources, finance, supplies, and other typical department management items, however, the traditional RIS features that include ordering, scheduling and report management and distribution can be centralized in an EMR. An integration of a PACS with an EMR on the front-end might make more sense than integrating it with a RIS. If nothing else, a plan to phase out the RIS should be part of the PACS replacement objectives.
8. Revisit the enterprise imaging solution – Images from the PACS have been made available throughout the enterprise by using web-servers that were part of the PACS system. However, when all images are going to be available at a VNA or enterprise archive, it makes more sense to have a viewer connected to the VNA instead of to the PACS. Most VNA’s support a web version of DICOM called WADO (Web Access to DICOM Objects) and there is actually a newly defined IHE profile that specifies how plug-ins would work with EMR’s (see www.ihe.net for more information). A temporary solution is for the EMR to have a PACS “plug-in,” which allows the EMR access to the primary PACS archive, however, one should design the system architecture to eventually get the images from the VNA.
9. Make sure there is support for all recent DICOM enhancements – There is a new generation of DICOM objects, which I refer to as DICOM 4.0, which are based on multi-dimensional object definitions with DICOM headers that are much richer, better defined and encoded. This family of so-called DICOM SOP Classes includes the enhanced MR and CT, and the new digital mammography, tomosynthesis. There are even new versions for cardiology, angio and RF. Instead of having to use dedicated modality workstations to view these new DICOM SOP Classes, one should make sure that there is support for them in the new PACS system. Other groups of SOP Classes are the Structured Reports that encode ultrasound measurements and CAD results, which should be supported and interpreted as well as displayed correctly. Lastly, there is an increasing demand to record dose information in the form of DICOM Structured Reports, which have to be managed in a PACS, i.e. recorded and exchanged.
10. Consider the cloud – Outsourcing storage might make sense for some institutions, depending on available in-house IT resources. Concern about privacy, security and availability, and whether or not the information is considered to be of such an important strategic asset may be reasons that an institution would want to keep it in-house. If for no other reason, one should consider maintaining a copy of the data in the cloud to provide disaster recovery. If there are concerns with security, organizations could consider creating their own clouds, which is rather common for either large geographical areas (e.g. in Canadian provinces), or for large provider groups. For a small institution that does not have any affiliations, a commercially available cloud service might make sense.
In conclusion, replacing a PACS with the same or different vendor without redesigning the architecture of the system would be a major lost opportunity. It is strongly recommended that you review the current architecture, workflow and standards support, i.e. how open the system is and how it can be improved, to make sure the new system can serve the next generation of hardware and software.