The original concept of the Enterprise Archive was to provide a centralized long-term storage solution for multiple department PACS, like Radiology, Cardiology, etc. Deploying the individual “archives” incorporated into each of the Health System’s department PACS often requires supporting multiple technologies. That and the obvious redundancy means higher cost of ownership. Several years ago, the simple solution was to deploy a single storage solution that could be shared by the various department PACS, and with a growing number of Radiology and Cardiology PACS vendors supporting open storage solutions, this simple solution was a reasonable solution.
While this solution reduced some of the redundancy, it did nothing to standardize the data. As more and more Health Systems began to realize that replacement of an old PACS with a new PACS required a migration of the data to the new PACS, it became obvious that a solution was also required to address this problem. Thus the original concept of the Enterprise Archive was modified to include a solution to the expensive and painful problem of data migration.
A storage solution alone is not equipped to handle the data migration issue. The management of Radiology and Cardiology data objects requires a feature-rich layer of DICOM services on top of the storage solution. More specifically a DICOM service is required to convert the idiosyncrasies in the DICOM format used by vendor A into the idiosyncrasies in the DICOM format used by vendor B. Simply put, the tools typically used by the data migration service organizations to migrate data from PACS A to PACS B would need to be integrated into the DICOM services package that sits on top of the storage solution. The common term for this format conversion is Tag Morphing. The integration of Tag Morphing into the DICOM layer of a storage solution would enable any PACS to forward image data to this storage solution as well as retrieve image data deposited by itself or any other PACS.
Tag Morphing eliminates the need for future data migration, and Tag Morphing enables data exchange between disparate PACS. Hence the term PACS-Neutral Archive.
The evolution from shared storage solution to PACS-Neutral Archive was a pretty nifty evolution in concept, and it was clearly the genesis of an emerging new segment of the image management market. There are at least six vendors in the United States that offer a product that meets the basic requirements of a PACS-Neutral Archive: Acuo Technologies, Agfa Healthcare, DeJarnette Research, Emageon, InSiteOne, and TeraMedica. There are already several installations of such systems in the United States, and several more in Europe.
But the Enterprise Archive needs to be more than a PACS-Neutral Archive.
Several years ago the concept of accessing image data through the Electronic Medical Record (EMR) was popularized. Then and now, the concept of an EMR is that the vast majority of physicians in a Health System would post their charts and research their patient’s study results in the EMR. Therefore it would be convenient if they could access the images associated with those results while remaining in the EMR application. To date EMR products do not include the specialized viewer software required to view Radiology, Cardiology, Ophthalmology, etc. images. Furthermore the EMR is not typically configured with the volume of digital storage required to store a copy of all of these modality images. Instead of incorporating the Image Viewer in the EMR and instead of creating yet another image data repository in the EMR, a much better solution has evolved. A URL interface links the patient study instance in the EMR to the corresponding Department PACS that provides the long-term digital archiving of the study data, as well as the viewing application for the display of the images. The EMR user clicks on a study listed in the EMR and a link takes the user directly to the PACS where the images related to that study are being archived. The viewing application is the same viewer that would otherwise be accessed if the user logged directly into the department PACS. In this case, the user has the benefit of using the department PACS without having to really leave the EMR environment.
This approach is really a major step forward in information access, but it didn’t take long to foresee two significant problems. First, enterprises with multiple department PACS would have to support separate URL links between the EMR and each of those PACS. In really large Enterprises, the number of separate PACS is a big number. Second, the physicians who choose to view images from within the EMR application have to learn how to use multiple viewers, each supported by the different PACS.
A PACS-Neutral Archive can obviously become the EMR Data Repository, as it is the single enterprise archive where all image data from all PACS is stored. But the PACS-Neutral Archive alone is not equipped to provide the EMR with a viewing application. Archives are typically not expected to support a viewing application, but that is exactly what is needed to solve this new problem. The ideal Enterprise Archive would first of all be a PACS-Neutral Archive and therefore be the EMR data repository, and secondly it must support a thin client or web-delivered image viewing application that could display any of the image objects that have been committed to the Enterprise Archive. The trick of course is being able to display different types of images (Radiology, Cardiology, Pathology, Visible Light, etc.) with the same viewing software, maybe on the same display screen and in the same working session. This would be the ultimate multi-modality medical image viewer!
The PACS-Neutral Enterprise Archive configured with a Multi-modality Viewer for the EMR would be extremely useful to even a small enterprise. But there are still more key issues that need to be resolved before one could accurately describe this new kind of Archive. What kind of data objects can it accept? How does it treat different types of data objects? Does every object have to be DICOM? What display feature set is appropriate for the EMR user? Interestingly enough, all of these issues are inter-related, and there is a significant difference of opinion on these issues among the developers of the new Enterprise Archive. In my next post, I’ll present some interesting positions on these issues and attempt to defend my own personal opinions.