The ARRA (American Recovery and Reinvestment Act) (stimulus bill) is going to pump billions of dollars into the healthcare IT ecosystem. I'm not in complete agreement with how that money is going to be spent nor do I think it will actually do much to improve healthcare for patients (but it will line healthcare IT consultants' and vendors' pockets quite nicely, which I don't mind).
Many of us will be trying to use the new stimulus funds over the coming years to buy new systems so I wanted to give a little advice. Be careful with your selection because it's much easier to get into a system than to get out of one. The initial exuberance of getting into a new IT system always make you feel that things will continue to go well into the future. Of course, that's rarely the case.
We've all seen it: we spend weeks or months in the "sales and demo cycle" for our applications. If we're lucky we consider all workflows, if we're even luckier we test drive the UI and make sure training goes smoothly, if we're smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it's been installed for a while.
Why is getting out important? Because every application becomes "legacy" sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition ("barrier to entry") is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?
If you can't answer the "how, in 24 months, will I be able to move on to the next-better technology or system?" question then you've not completed your due diligence in the sales cycle.
When preparing an RFI or RFP or when you're looking to purchase any new system, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:
- Do you own your data or does the vendor?
- Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you're locked in so be very wary.
- Are the data formats that the system uses to communicate with other vendors open? If not, you don't own your data.
- How much of the technology stack is based on industry standards? The more proprietary the tech, the more you're locked in.
- Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you'll pay dearly.
Leave a comment