It’s harder to get out than get in

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

If you have other considerations, share them here.

Newsletter Sign Up


4 thoughts on “It’s harder to get out than get in

  1. I know this all too well…having implemented a EMR 5 years ago. It is the cost of getting out of a multiple state system that is slowing a move to a more favorable type system. Where will the medical records go?? Should I print them out?? What responsibility of the vendor for retrieveing the data? How much do I need to pay for maintaining a system that technically I am not using but I have to maintain records for years. In this type of world be ready to make a long term sacrifice…conversion of healthcare data is not like a payroll system or a general ledger. These systems are almost impossible to convert from one data model to the next!!! Unless you have unlinmited funds or time. We all know that every software company can fix anything with time and MONEY!!

  2. Coincidentally, HIT News just wrote up a large IDS dealing with the same issue: http://www.healthcareitnews.com/story.cms?id=5291

    A few solutions from cheap to expensive:

    1. CHEAPEST – Print the paper and scan it
    2. CHEAPER – Print the paper to PDF or TIFF with some metadata tags for patient identification and have your vendor write programs to convert and upload the information into your new record
    3. CHEAP – Print the paper to PDF or TIFF and have your staff convert it (the staff cost is probably higher than what it would cost for your vendor to write a program)
    4. Middle of the Road More Expensive – make it your new vendor’s problem to convert the data
    5. Middle of the Road Less Expensive – broker the discussion between your new vendor and your old vendor
    6. Expensive – Investigate a solution like NovoGrid to see if they have prebuilt interface links between the vendors and have them do the conversion
    7. Very Expensive – write your own (have a qualified developer do it for you) formal generic model database (meta-data driven database… Shahid has written this up), select the data worth converting in discrete form, text the rest, store it in a new data model and have your new vendor bring it into the new environment

    Good Luck…

  3. One last thought… assuming your EMR allows Hl7 encapsulation of the information you require, use BizTalk’s or NeoTool’s HL7 tool to receive messages from your old EMR in XML encapsulated HL7 messages, then write a message viewer or ideally have your new vendor convert this information. Regardless of the solution, ensure your new vendor will not paint you into the same box.

Add Comment