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”.
