Many institutions are at a point where they need to replace their PACS. Whether this process is undertaken with a new or current PACS vendor, it's a perfect opportunity to redesign the system's architecture to prepare for the future.
Changing your PACS often means changing your vendor as well. There can be multiple reasons for switching vendors, ranging from unhappiness with the current vendor's service level to missing PACS functionality and/or reliability.
In many cases, the reason may be because the hospital corporate headquarters decides to single-source all of its imaging equipment from a different vendor. This often occurs when a hospital is acquired and the corporate office wants to have a single vendor to improve information exchange between the institutions.
In the rare case when one is not replacing a PACS but, rather, buying a new one for the first time, most of the recommendations listed below equally apply.
Herman Oosterwijk of OTech.When replacing a PACS, 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.
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 than the PACS vendor. It is possible to purchase a vendor-neutral archive (VNA) from the same vendor as the PACS; however, it is very hard -- if not impossible -- to prove they are not tightly coupled.
For example, some vendors do not physically delete images from the archive but, instead, only set a deletion flag in the database. That's unacceptable because the deletion-flagged images will almost certainly reappear if the archived images are ever migrated to a different vendor. 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 connecting multiple PACS 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 to 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 store so-called key image information and annotations in the database instead of encoding them as a DICOM object that can be migrated. It's possible to decode this vendor-proprietary information and create new DICOM objects, but 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 was used.
For example, the chance that a 5-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.
Finally, some PACS store diagnostic reports, and some don't. If the new PACS doesn't and the old PACS does, these have to be migrated from the old PACS to either a RIS or electronic medical record (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 DICOM objects that are stored with the images. This made a lot of sense when radiologists could only access electronic information on the PACS workstation.
However, as most institutions can be expected to have an EMR or be in the process of installing one this year, it does not make sense to continue this practice. These documents 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. This electronic order 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, some CDs are still created with image resolutions that simply have no diagnostic value (such as simple JPEGs), 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 are provided by the PACS vendor, and some are provided by a third party. Eventually, images will be exchanged through health information exchanges (HIEs), so using a file-sharing service may serve as a logical step in that direction.
6. Apply rules learned from IHE scheduled workflow.
I am convinced that the majority of PACS don't fully use the scheduled workflow features in the Integrating the Healthcare Enterprise (IHE) standard, and thus do not take advantage of their efficiency and workflow benefits.
In particular, implementing a DICOM 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 is a good opportunity to review the bidirectional RIS/PACS interfaces and activate MPPS as well as DICOM 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 might become obsolete as sophisticated computerized physician order-entry (CPOE) systems are becoming available as part of EMRs.
A radiology department would still need software to manage its resources, finances, supplies, and other typical department management items, but the traditional RIS features that include ordering, scheduling, and report management and distribution can be centralized in an EMR. Integrating 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. 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 the PACS.
Most VNAs 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 EMRs (see ihe.net for more information). A temporary solution is for the EMR to have a PACS plug-in that allows the EMR access to the primary PACS archive. However, the system architecture should be designed to eventually get the images from the VNA.
9. Make sure there is support for all recent DICOM enhancements.
A new generation of DICOM objects, which I refer to as DICOM 4.0, are based on multidimensional object definitions with DICOM headers that are much richer and better defined and encoded.
This family of so-called DICOM Service-Object Pair (SOP) Classes includes the enhanced MR and CT and the new digital mammography, tomosynthesis. There are even new versions for cardiology, angiography, and radiography/fluoroscopy.
Instead of having to use dedicated modality workstations to view these new DICOM SOP Classes, make sure that the new PACS supports them. Other groups of SOP Classes are the Structured Reports that encode ultrasound measurements and computer-aided detection (CAD) results, which should be supported and interpreted as well as displayed correctly.
Finally, 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. An institution may want to keep it in house due to concerns over privacy, security, and availability, and whether or not the information is considered an important strategic asset. 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 large geographical areas (e.g., in Canadian provinces) and 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.
Herman Oosterwijk is president of OTech, a healthcare imaging and IT company specializing in EMR, PACS, DICOM, and HL7 training.
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnie.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group.
