I recently reviewed a cardiology PACS Request for Proposal (RFP) that had a section on the migration of stored data from various PACS archives to a new system, as well as a section on migration of the data when the potential vendor's PACS was replaced.
The idea of migrating the image and related data right now, in five years, than again in five years till eternity, every time one changes a vendor is not very appealing. That is where a vendor neutral archive (VNA) comes in the picture, which only requires migration once and for all into a true neutral and open format.
These data migration clauses are becoming more common in health IT RFPs—especially for second- and third-generation PACS adopters. This is because many of these users were shackled with the bill for migrating their data, which can be expensive, resource intensive, and very time consuming.
The cardiology PACS RFP author was apparently unaware of the VNA concept, and how it could help their institution avoid future migration issues. I was able to help them get the right requirements in the updated RFP, based on this checklist.
I strongly suggest that anyone who is considering the replacement of their PACS should be seriously considering implementing a VNA (a "true VNA," as defined here). If not, it better be for very good reasons—if you can come up with any, I would be interested in hearing them.
Sunday, August 1, 2010
Cardiology PACS: IT A-Fib
Although the first blush of cardiology PACS as a new health IT product has passed, the systems still lag about five years behind their cousins in the radiology market. This is not only in the number of system installations, but also in its technology and integration capabilities. From an IT perspective, cardiology is more challenging than radiology, as there are many more pieces of information that need to be integrated. However, from a technology perspective, there is no reason for vendors not to provide totally integrated solutions. Unfortunately, many of the current cardiology PACS offerings lack this necessary capability.
There are fundamental and significant differences in the IT workflow of cardiology and radiology with regard to PACS. First, the Cardiovascular Information System (CVIS) plays a more important role than a RIS. Not only does it take care of the interface with a HIS for patient demographics, it also provides ordering and scheduling information as well as a robust supply inventory component. In many cases, an interface with a surgery information system is needed, as rooms can be used for both diagnostics and treatment.
The reporting component is also very different. Speech recognition is not as prevalent (yet) and the level of macros, templates, and structured text are much more important. Ultrasound has special requirements defined by the Intersocietal Commission for the Accreditation of Echocardiography Laboratories (ICAEL). And most importantly, the automated interface to ultrasound modalities that create DICOM structured reports (which provides all the measurement information to populate the appropriate fields in the header) is critical.
With regard to the workflow, yes, there is a "scheduled workflow" profile defined for cardiology by IHE. However, in practice, it seems that there is much more workflow variety among cardiology practitioners than in radiology, which may be because PACS is not as pervasive in that market.
When it comes to the modalities employed by clinicians to deliver patient care, radiology PACS is fairly well integrated. This is not to say that the work is complete. There are still some issues around making information available to the radiologists such as the requisition for the “reason for study” or “admitting diagnosis.” In addition, technologist notes, ER discrepancy reporting, and critical results reporting might be better integrated, but overall, it kind of works. However, in the case of cardiology, a PACS has to integrate not only with the DICOM modalities for images--including cine loops--but also with the hemodynamic, physiological, and EKG data.
This is a major challenge for IT administrators as some of this data may be in proprietary or semi-proprietary (as a customized pdf or xml file) formats. A cardiology PACS should be able to take this information and manage it. Some cardiology systems are clearly defunct as they only are designed to store true DICOM data and, in the best case, might have a Web interface or plug-in to other data sources, but they don't really manage this. There are not many cardiology PACS that support a true level 5 vendor neutral archive (VNA), which would allow all the information to be managed.
So, if you are considering the replacement of your cardiology PACS, or are in the market for your first system, don’t use the same requirements as you did for purchasing your radiology PACS. These are two very different products. Pay special attention to the back-end, make sure the system provides true multimedia connectivity, ensure that the CVIS provides the functionality your cardiologists need, and that the system meets the workflow requirements of your institution.
There are fundamental and significant differences in the IT workflow of cardiology and radiology with regard to PACS. First, the Cardiovascular Information System (CVIS) plays a more important role than a RIS. Not only does it take care of the interface with a HIS for patient demographics, it also provides ordering and scheduling information as well as a robust supply inventory component. In many cases, an interface with a surgery information system is needed, as rooms can be used for both diagnostics and treatment.
The reporting component is also very different. Speech recognition is not as prevalent (yet) and the level of macros, templates, and structured text are much more important. Ultrasound has special requirements defined by the Intersocietal Commission for the Accreditation of Echocardiography Laboratories (ICAEL). And most importantly, the automated interface to ultrasound modalities that create DICOM structured reports (which provides all the measurement information to populate the appropriate fields in the header) is critical.
With regard to the workflow, yes, there is a "scheduled workflow" profile defined for cardiology by IHE. However, in practice, it seems that there is much more workflow variety among cardiology practitioners than in radiology, which may be because PACS is not as pervasive in that market.
When it comes to the modalities employed by clinicians to deliver patient care, radiology PACS is fairly well integrated. This is not to say that the work is complete. There are still some issues around making information available to the radiologists such as the requisition for the “reason for study” or “admitting diagnosis.” In addition, technologist notes, ER discrepancy reporting, and critical results reporting might be better integrated, but overall, it kind of works. However, in the case of cardiology, a PACS has to integrate not only with the DICOM modalities for images--including cine loops--but also with the hemodynamic, physiological, and EKG data.
This is a major challenge for IT administrators as some of this data may be in proprietary or semi-proprietary (as a customized pdf or xml file) formats. A cardiology PACS should be able to take this information and manage it. Some cardiology systems are clearly defunct as they only are designed to store true DICOM data and, in the best case, might have a Web interface or plug-in to other data sources, but they don't really manage this. There are not many cardiology PACS that support a true level 5 vendor neutral archive (VNA), which would allow all the information to be managed.
So, if you are considering the replacement of your cardiology PACS, or are in the market for your first system, don’t use the same requirements as you did for purchasing your radiology PACS. These are two very different products. Pay special attention to the back-end, make sure the system provides true multimedia connectivity, ensure that the CVIS provides the functionality your cardiologists need, and that the system meets the workflow requirements of your institution.
Subscribe to:
Posts (Atom)