Does a Deconstructed PACS make sense for you?

When I was a young student in engineering school I built my own “deconstructed” sound system. By Bombardon” bass speaker and tweeter (no, nothing to do with Twitter), veneered the enclosure and using speaker cloth for the front. It was a lot of fun but in a different time frame given the fact that Radio Shack just went bankrupt as people today don’t do this kind of thing anymore.
building I mean, tracing the printed circuit and etching out the tracks according to a published schematic, buying the components (capacitors, transistors, resistors, and transformer) at what was the equivalent of Radio Shack, building a chassis from aluminum and creating a front plate and enclosure. I even built my own speakers, using at that time what was the famous Philips “

So, why would anyone build their own PACS from the ground up? As with building any sophisticated electronics system, whether it is a sound system, a gaming computer, or a PACS system, it is not for the faint of heart. But, in some cases, it does make a lot of sense. Before deciding if it makes sense for you, let’s look at the pro’s and con’s.

Arguments “for” implementing a deconstructed PACS:

1.      You get best-of-breed - For example, you go to a trade show such as RSNA or SIIM and you see this really nice workstation that does everything you need, in other words it has all the bells and whistles you would ever want. Or you really need to use this super-duper modality worklist provider that allows you to filter the worklist by location, station name, referring physician, and much more. Or, you found a workstation worklist provider that allows you to manage different worklists from several PACS systems all from different vendors. You can’t just carve out one piece at a time from your existing PACS so you will have to start building your own.

2.      It addresses a specific need that nobody else in the market is able to provide - For example, despite the fact that almost every vendor says that they provide a VNA, a true fully functional VNA with full support of the applicable IHE profiles, comprehensive tag morphing and routing as well as DICOMWeb implementation is relatively rare among the “traditional” PACS vendors. Therefore, you might be forced to look around for third party solutions, hence the start of a deconstructed PACS.

3.      It provides a major workflow advantage - A single department consisting of one specialty does not pose a lot of workflow challenges, but if a radiology group supports let’s say more than 10 hospitals each having a PACS from a different vendor, and there is also a extensive teleradiology component, you might be forced to look at solutions that support that type of workflow.

4.      It provides economy of scale - Imagine you are the CIO of a large hospital chain, which could be 15 to more than 100 hospitals. Similarly, you can imagine being in charge of IT for a VISN (Veterans Integrated Service Network) within the department of Veterans Affairs. Having to purchase and support multiple systems leads to duplication, therefore, sharing resources makes good sense from an initial cost, support and maintenance perspective. That is why the VA has some of the best examples of deconstructed PACS implementations using a single image archive/VNA solution for the whole delivery network and uses third party routers, worklist providers, and workstations.

5.      It allows for a “gradual” implementation - If you have a large monolithic system, it is often implemented in a “big-bang” kind of manner, i.e. on Monday morning 8 am everyone goes from the “old” to the “new.” Using a deconstructed PACS, you can phase implementation, which can be advantageous especially if you have a large-scale deployment. You can start by first implementing a modality worklist, making sure all your modalities are connected and working, followed by the archive, then switching the workstations, voice recognition, etc.

Arguments “against” using a deconstructed PACS:

1.      Deploying it is a lot of work - Instead of shopping for one component, you’ll be shopping for a VNA, workstation workflow manager, modality worklist provider, router(s), radiologist workstations, physician workstations, 3-D and other miscellaneous capabilities such as dose reporting, critical result reporting, peer review package, and I probably missed a few more. You’ll have to work with many different vendors for selection, contracting and implementation.

2.      It requires expertise - You need an educated purchasing team, an IT team, integration team, you need dedicated PACS administrator staff for staging, managing the migration, training, and project management. You’ll need experts in DICOM, HL7, and IHE and very likely will need to train your staff in those skills and send them back to take a seminar or training course. Most of this is not needed or needed to a much lesser degree if you purchase everything from a single vendor.

3.      It could be more expensive - I say “could” because it is not quite clear. Note the analogy of building a car from its parts, it costs about 5-6 times as much, which is the reason stolen cars are typically cut up and sold as parts. Big contracts for monolithic systems are often discounted as well, so you could be paying more for these parts. However, you can also do better shopping for some of the components. Note that “best of breed” could include “best breed for the money.”

4.      There is no single vendor contact for support - Service for these relatively complex systems is still a big differentiator, so having a single number to call might be advantageous, as you reduce the amount of finger pointing. However, one could also argue the opposite, as service is rather expensive, you could potentially save a lot of money by managing the level of in-house support. But there is no question that having a single service contact point has its advantages.

5.      It is high risk - You can design the architecture and look at the specs but there is a chance that it might not work as expected. There are safeguards you can put in, if nothing else, you should spend a lot of time testing and verifying it. I have seen good examples of that, one of the major institutions I know of used a six months trial and test phase, but the chance of failure is higher than going down the beaten path.

Most decisions are not black and white or obviously one or the other, it is often a balance, weighing multiple pro’s and con’s. I would argue that if there is not a clear advantage for a deconstructed PACS, you might be better off sitting tight for a few more years until these early installations have matured and any gaps have been filled with additional functionality or middle ware solutions. However, I remember building my own deconstructed sound system, I had a lot of fun and a learned much more than I would have learned by buying it off-the-shelf. So, if you are up to it, I’d say go for it!