In the past, there have been other adjectives used for the PACS system, which came and went. For example, the terms of the integrated PACS, the RIS (Radiology Information System) driven or PACS driven, and several others. In the meantime, the RIS is pretty much dead as most hospitals now have an EMR (Electronic Medical Records) with order entry capability in the form of a CPOE (Computerized Physician Order Entry) function, so there is no use to talking about integrated RIS/PACS or RIS driven PACS anymore.
So, what is the deconstructed PACS in my opinion? It is nothing other than using a best-of-breed approach or commoditization for the individual PACS components. It is a logical evolution of what has been happening since PACS started all along.
Going back in PACS history, the initial PACS systems were a “package deal” containing hardware and software for the archive, viewing stations, including dedicated expensive video cards, and monitors. This was true until the hospital IT departments got involved, especially from the large providers, who had a contract with for example, HP, Dell or IBM to provide all of their hardware, which could amount to literally thousands (or more) computers a year. Most of them can buy the hardware much cheaper than the PACS vendors, and therefore wanted to provide their own hardware for the viewing stations.
The same thing happened with the archives, for example, an IT shop who had all EMC hardware with its support and maintenance agreement, would be very hesitant to bring in another vendor just for the PACS. Remember that the PACS from a hospital perspective is just another piece of their healthcare IT puzzle together with the other department systems, HIS, billing etc. To make a point, when I visit a hospital IT room I can appreciate their perspective, as the PACS servers take up just a few of the many computer cabinets in one of the several rows of hardware of their computer room.
Some of the first vendors very smartly addressed that requirement and started to sell PACS software licenses only while specifying minimum hardware specs such as required CPU, memory and OS version, which did shake up the industry and pretty much everyone started to follow. We are now at the point that you can provide your own hardware, including the medical grade monitors, video boards, computers, servers and storage devices for all PACS components.
After that, VNA or Vendor Neutral Archives were introduced. Users were getting tired of having to migrate data every time they changed PACS vendora, so they wanted to take control over their data and purchase the archive from a different vendor and use the PACS archive mainly as a cache to allow for fast access of the most recent studies.
In the meantime, more “ologies” wanted to manage their images electronically and again, the CIO’s were not allowing a department to buy yet another archive for let’s say cardiology, dentistry, surgery and other images. The users also found out that not all images are in a DICOM format, for example, speech pathology, physical therapy and dermatology were all storing native JPEGS and MPEGs, and ophthalmology has been creating pdf’s containing very detailed and specific results. Moreover, the push to share this information in a standard manner with Health Information Exchanges (HIE’s) forced these VNAs to become a gateway to the outside world using standard protocols such as XDS. And if you need to have access to all of the patient images creating a patient centered view, you might as well access the VNA instead of all the individual PACS systems while using a zero footprint viewer.
An additional problem with uncoupling the archive i.e. VNA from the PACS is synchronization. If an image has to be modified or deleted on the PACS, you don’t want to have to do that twice, voila, the IHE IOCM (Imaging Object Change Document) profile that provides that functionality. So we arrived at an archive device (VNA) that supports DICOM, non-DICOM, can talk XDS, supports the PACS synchronization and has a standard DICOM viewer interface. At least this is a “true VNA” in my definition.
So far we have deconstructed the PACS hardware and software, the archive and the viewer, which actually caused some “experts” to announce that PACS is dead, which is definitely a misstatement. Therefore, myth number one that the deconstructed PACS is the same as “PACS is dead,” is definitely a misstatement. We still need PACS systems that manage the department workflow, providing very fast access to images and efficiently providing very specific tools and image presentation in the form of hanging protocols to deal with specialties such as cardiology, mammography, dentistry, nuclear medicine, and last but not least, general radiography. This is in addition to features such as peer review capabilities and critical results reporting.
Going down the path of deconstruction, we also need so-called workflow managers that manage the workstations. These started out as a solution for radiologists who are serving multiple hospitals, each one might have a different PACS system. Instead of having to log into different worklists for each individual PACS, the workflow manager would combine or aggregate these worklists and create a single one, while synchronizing the reading between multiple users and PCS systems. The step from different PACS systems to a single archive (VNA) that has images from different sources is not that hard to make, hence we have the next step, i.e. a workflow manager from a different vendor. The step to use a best-of-breed viewer is now easy to make, yet from another vendor.
So far we reconstructed the archive, workflow manager and viewer, however, we need additional middleware to make this work. In particular, we need to clean up the data as it comes from different sources, such as series and procedure descriptions, especially if the images are created at different institutions with their own terminology. For this a DICOM cleaner or “tag morphing” software is needed. In addition, if you don’t have a universal ID, you need the Master Patient Index or MPI capability. Last but not least, to get some of the details needed from the orders, you need an interface engine that consolidates all of the HL7 feeds.
As of now we have five components, the VNA, workflow manager, viewer, DICOM router, HL7 interface engine and an optional MPI provider. You can purchase each one of those from a different vendor, which is the best-of-breed approach.
This brings us to myth number 2, which is that a deconstructed PACS is less expensive, which is not necessarily true. The reason is the effort involved with integrating, testing and maintaining such a diverse system. Assuming that you have a strong IT department, and educated imaging and biomedical engineering resources, it could definitely be less expensive and provide best of breed, i.e. a solution that better meets your specific requirements and workflow. The truth is that for many institutions this is not an option. They might want to deconstruct the PACS only to the level of the VNA, and even in that case they might be better off to purchase the VNA from the same vendor as their PACS provider. However, if you do so, I would strongly recommend requiring standards support at each level so that you can replace any of the components for either business reasons or if the vendor simply does not keep up with new developments. As an example, you would be surprised how many vendors still don’t support 3-D breast tomosynthesis images, or even the new enhanced multi-frame CT and MR for their viewer, in which case you might be better off to look for a different solution.
The last myth is that a deconstructed PACS is something new, which is incorrect. It is just a logical evolution of what started 15 years ago by opening up the PACS by using standard interfaces and allowing the replacement of the several parts by the different vendors. So, the truth is that there is nothing new under the sun, which might take some of the marketing hype away from the vendors, but that is OK, they just have to come up with another term to sell what is basically the same old thing.
In the meantime, as a user, it is important to make sure that any new PACS purchase allows for the deconstruction by requiring standard support, and verifying and testing these, and continue to get educated and stay knowledgeable to provide the more sophisticated support needed for these systems.