Implementing digital image and information systems provides a medical practice with both workflow and service advantages. However, creating an independent information silo with this data limits the capabilities of these platforms solely to the department that generated it.
Taking a page from the playbook of radiology departments, many cardiology practices today are seeking to move information beyond their group and into the information systems of the healthcare enterprise. But healthcare information technology (IT) administrators may face several issues in making this a strong, workable solution.
Medical facilities are looking to leverage existing systems to reduce costs, as well as improve efficiency and enhance workflow. Moving onto the enterprise means that cardiology must play nice with other IT systems with regard to imaging and information.
This article will attempt to specifically address integrating the cardiology department imaging into the radiology space, from a PACS-to-PACS perspective. Subsequent articles in this series will deal with the benefits and challenges of integrating other types of information, such has ECG data, hemodynamic data, and reporting information.
The main question asked in the field regarding integrating cardiology into other hospital systems has to do with the images. Primarily, facilities want to know how they can leverage an existing radiology PACS to store and distribute cardiology images.
"I want to use my radiology PACS as the archive for my cardiology PACS" is a statement that, on the surface, seems like a not-too-difficult request. Assuming you have a PACS in radiology and a PACS in cardiology that was released in the past few years, both these systems operate using the DICOM standard. Although having both systems capable of DICOM operations does not guarantee they will work successfully together, it is a good place to start.
Some older PACS do not store data in the DICOM format, and it would be very difficult, if possible at all, for them to integrate with a DICOM application. The system may be able to output a DICOM-compliant CD/DVD, but it would not be capable of the communications required to exchange images with another DICOM product in a workflow that would be meaningful. Currently, this issue is common with older, non-DICOM PACS products in use in cardiology departments.
After establishing that both systems support DICOM, there are some challenges to overcome, including a few not often mentioned when discussing whether to use the radiology PACS as the archive for a cardiology PACS.
Mistakes live on in the receiving system
Mistakes in the DICOM information associated with an exam are transferred and may not be automatically corrected in the receiving system. For example, a cardiology study comes into the cardiology PACS with errors in the patient information. As a standard operating procedure for incoming exams, the images are transferred automatically to the archive, which in this example is the radiology PACS.
These mistakes can be corrected in the cardiology PACS, but the exam has already been sent to the radiology PACS for archiving. This can be a serious issue if the images are to be viewed through the radiology PACS. Imagine two physicians viewing the same images on the two systems, but seeing a different gender, birth date, or exam date for the patient.
DICOM communication is slower than you think
The idea of sharing storage using your radiology PACS may be a great way to maximize your storage investment and free up space in your IT data center by not requiring another storage platform. You may even have a radiology disaster recovery solution that you can leverage for cardiology.
However, one of the prices you will pay, with regard to using the radiology PACS as an archive for your cardiology PACS, is performance. Unlike file-system storage, using another DICOM application as the vehicle for archiving involves several layers of communication that impact performance. More than likely you will find greater performance from using a network-attached storage (NAS), storage area network (SAN), or direct-attached storage (DAS) archive option. Interested parties should consult their respective vendor partners' DICOM conformance statement (DCS). The DCS document will explain and illustrate the processes used to store exams, as well as query and retrieve them.
Does the receiving PACS support DICOM storage commit?
DICOM storage commit is a DICOM service used to confirm that an image has been archived by the receiving DICOM application, not merely received by it. When using another PACS as an archive, support for this service is highly desirable.
The purpose of this service is twofold. First, is confirms that the images have been reliably stored by the receiving system. Second, it allows the sending system to remove these images from its local cache. While this service is not generally a requirement, it is highly recommended.
How does the radiology PACS handle cardiology images?
An important element to consider is how one system handles the images of the other. X-ray angiograms (XA) and ultrasound modalities frequently send images already compressed to some degree, either with lossless or lossy jpeg compression.
Be sure that the PACS archive can accept a compressed image, and confirm, via both vendors' DCS, that the systems support DICOM in a compatible manner. This will be very important in ensuring that exams sent to your cardiology PACS are archived on the radiology PACS in the exact same format, and consequently can be retrieved from the archive in the format in which they were originally sent. You will want to consider carefully what data the cardiology modalities enter into the DICOM header, and how your radiology PACS handles that data.
The concern here is whether the images will look the same on the radiology PACS as they do on the cardiology PACS, if you plan to view the images from both systems. Another important consideration is whether the radiology PACS will ignore and not archive some of the cardiology information, which could lead to cardiology PACS users being unable to retrieve the same image data that they sent to the archive. Again, carefully look at each vendor's DCS.
How does each PACS handle images received via DICOM query/retrieve?
For the most part, a PACS archive treats the images it acquires via DICOM query/retrieve (Q/R) from another system in the same way it treats images acquired via an imaging modality -- it archives them as it would any new image it receives. If a PACS has only the Q/R function and does not pass back a DICOM storage commit, it may create duplicate records, multiple times. You will want to verify that the PACS used as an archive in a multidepartment solution will return a message indicating that it has an exam archived, and that both the sending and receiving PACS accepts and uses this message.
Additionally, many facilities want to share images between radiology and cardiology, without using one PACS as the archive for the other. This is another scenario in which you want to pay close attention to how each system treats images it receives via DICOM Q/R. If either PACS handles DICOM Q/R images as new and archives them, you can imagine the effect on the radiology and cardiology storage as exams are shared back and forth, and re-archived on each department's storage platform. If your facility plans to use this type of image-sharing workflow, and either system treats images acquired via DICOM Q/R as discussed above, you will want to plan your storage capacity accordingly.
In addition to the various technical challenges of integrating a cardiology PACS across the healthcare IT enterprise, there are internal issues that will need to be considered.
Support
Support responsibilities for these systems will need to be re-examined. When images are not where you need them, who do you call? For example, a cardiologist is unable to view a patient's echocardiography exam from a PACS diagnostic workstation. The system administrator looks at the cardiology PACS and possibly has to call the vendor for technical support. Additionally, you may need to involve the radiology PACS system administrator and the technical support for that product to troubleshoot the problem, because the images may have been retrieved from this location.
The more people and systems involved in any process, the more complicated the issue and the more time required to resolve it. If you are considering cardiology and radiology PACS integration, be sure to thoroughly examine the internal support structure for these products, and investigate additional training in system administration.
Who pays for what?
One question that would seem to be obvious -- but is often overlooked because the purchasing process does not always involve cardiology, radiology, and IT as a group -- is how will the addition of cardiology images affect the storage capacity for the radiology PACS?
In designing a PACS, you normally designate a capacity for fast-access (such as RAID) storage and the long-term archive. The amounts for each are determined based on user expectations; for example, one year of fast-access RAID and an initial five years' capacity for the archive. When images from a cardiology department (including the possibility of cardiac catheterization and echocardiography) are introduced, the original plans for the image archive can be seriously impacted.
Clearly, it is important to bring all the stakeholders together before deciding on any type of integrated solution.
Planning and preparation
Many of the above-mentioned issues can also present themselves when you use the radiology PACS as a gateway for Web distribution or electronic medical record (EMR) access, rather than as an archive for the cardiology PACS.
It is critical for facilities, especially those considering using the radiology PACS as the archive for the cardiology PACS or vice versa, to do their homework. A major concern that should be addressed beforehand is having an archive available for either system if integration does not turn out the way expected -- due to a technical difficulty, unacceptable performance, or a workflow conflict.
The considerations above are merely a starting point for facilities that are contemplating integrating the radiology and cardiology PACS. More in-depth information on any of the elements presented in this article should be requested from prospective vendor partners before implementing any integration schema.
By Jeff Haglund
AuntMinnie.com contributing writer
December 26, 2006
Jeff Haglund is a senior healthcare consultant for Bothell, WA-based Philips Medical Systems' healthcare information technology division.
Related Reading
European cardiac PACS market shows growth, June 13, 2006
Standards, interoperability drive cardiac PACS, IS implementation, February 13, 2006
Cardiovascular disease growth pushes European digital cath lab implementation, February 2, 2006
Cardiac PACS pace quickens, September 22, 2005
Many skills needed for cardiology PACS administrator role, April 25, 2005
Copyright © 2006 Jeff Haglund
