This is part 2 of 4 of the Deconstructed PACS series, the full video and corresponding slides of the webcast can be viewed here.
The first thing you need to do when considering a Deconstructed PACS (DP) is knowing your requirements. Make sure you differentiate between what you want versus what is really needed. Specifically, do you already have a solution in place that works, and especially, how does a DP solution fit in your long term strategy. Consider the integration with other clinical systems, Know that there are many components to make a DP solution work, particularly the PACS, and RIS.
You have to decide where the data is stored, for example, on-site, in the cloud or do you consider a hybrid storage solution. Then, who owns the database, how is access provided and who is managing that. Note that this is one of the major differentiators between a traditional PACS which in many cases has a locked down access to the database and the deconstructed PACS which transfers ownership of that information, including opening up the database scheme to the customer, to the client.
It is important to know the trade-offs, in particular the gains and losses. Knowing the true cost of ownership is critical, including the support cost. This takes into account the cost and solution for redundancy, which can be solved in a central versus distributed manner. Service and support can be provided either internally or externally. Internal is typically less expensive initially but requires an investment in hiring the right people and providing them with training so in the end the costs may be the same or even slightly higher.
A word of caution is that one never should buy on price alone. No vendor will ever lose a deal on price. You need to make sure that everything is included in the purchase price. Don’t buy something you don’t really need. I have seen too many computers in a department sitting in a corner unused that were part of the deal looked good on paper, but turned out to be useless.
It is important to decide upfront who will perform the connectivity to all systems and how will it be done. You need to determine will it be a web-based interface, an HL7 or DICOM interface, or even a custom designed API (application program interface) that is commonly used to connect to your speech recognition system, or any other interface.
It is critical to get as much in writing as you can. Know that not everything can be negotiated and there are often certain policies and contract items that are standard.
Make sure you get feedback from all stakeholders before making the purchase decision, especially from the CIO and CTO. Those two are key. Do your due diligence to be able to justify your purchase. Look at all financing option,and in particular if you want to finance it from the operating budget, versus capital budget or even price per click. Regardless the term should not exceed 5 years as this technology is changing too fast to know what will be preferable at that time.
In conclusion, a deconstructed PACS is a good solution for certain applications, but not necessarily a one-size fits-all for everyone. Do your due diligence to find out if this might be a good solution for you. It might but then again, it might not either.
Mike Cannavo, aka as “the PACSman”.