Prepare for the Failure of Many EHR Vendors

Just sitting back and taking a look at the current EHR and EMR market, I have a strong feeling that we’re going to see a number of EHR vendors close up shop. Many of them may be disguised as purchases by bigger vendors who are trying to gain market share. Others will probably just close their doors completely and users of that EHR system will wonder why their support requests aren’t getting the response from their EHR vendor that they’re use to receiving.

I’ve talked previously about how EHR adoption will be slowed by the HITECH act. This slowing of EHR adoption is going to put a number of EHR vendors out of business. I have a feeling that far too many EHR vendors based their burn rate on their previous sales. Now that sales have slowed, they’re going to have to really fight to stay above water.

For those concerned, you might want to take a look back at my post on assessing your EHR vendor’s financial situation. Plus, I think it’s definitely worth taking a look at some contingency plans you have in case your EHR vendor does fail or get bought out.

The nice part of client-server based EHR systems is that you can usually keep using the EHR regardless of the financial viability of the EHR company itself. Granted, you’ll stop getting upgrades, but at least you can maintain the status quo. If you’re using an SAAS EHR, I’m not sure exactly what options you have available.

I should say that most EHR vendors won’t just shut their doors and leave. Most failing EHR companies will salvage what they can by selling to an EHR vendor that wants their customer base. However, when this happens, expect the new vendor to provide very light support for the purchased EHR software and a clear path to move to their software.

All of this said, I’m predicting a number of EHR companies to fail in the coming year.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • Another well-written article. You’ve made an argument that can as easily be translated to other verticals: If a company owns the software and hardware, a vendor closing shop won’t be as big a problem… in the SHORT TERM.

    However, there is an aspect you’ve left out: On-premises vendors (Cerner among them) store their data in proprietary formats almost impossible to port to another system. To my knowledge, every SaaS vendor stored data in easily-exported tables that can be ported quite easily. This is because the data must be accessible via the API on such a large scale that doing weird changes to it will slow the system down too much.
    So while one may lose one’s software when a SaaS vendor goes under–but can move the data somwhere else–when an on-premises vendor goes under, one loses the ability to move to any other service at all. After all, who would sacrifice years of data?
    This is what client-server vendors will never tell you, but it is possibly the most important thing they should tell you.

  • David,
    You’re certainly right about a number of on-premise vendors storing their data in proprietary databases. However, you make it sound like the majority of on-premise EHR vendors store their data in proprietary databases. From my experience this is just not the case. Most on premise database systems I’ve seen are done with one of the big 3 SQL databases: Oracle, SQL Server and MySQL. All of these databases are just as easy to export from as any SaaS database (which is probably one of these 3 databases as well).

    Of course, if you’re someone who uses an EHR vendor that doesn’t use one of these 3 (or possibly other SQL based databases), then you definitely want to strongly consider the impact of your EHR vendor having a proprietary database. In fact, this should be important part of the EHR selection process.

    However, I would suggest that even in the long run, an on-premise EHR software that uses one of the 3 SQL databases I listed above is still better in the long run. If your SQL database is on premise, then you have complete unfettered access to all of your data. In a SaaS EHR software, no vendor that I’ve seen will ever give you SQL access to the SaaS EHR database. I’ve also seen very few that offer a full set of API that will allow you to extract all of your data before they go under. Any APIs that EHR employ are limited at best. Although, I’ve seen very few that have anything that resembles an API.

    Long story short, here’s how I’d order my preference if I were listing which type of vendor I’d want:
    -An EHR vendor that doesn’t fail
    -A SQL based database EHR vendor hosted at doctor’s office
    -A SaaS based EHR vendor
    -A proprietary database EHR vendor hosted at doctor’s office

    The first one is obviously the best. Just ask anyone that has chosen to move from one vendor to the other. It’s pretty rough.

  • The whole thing about databases is a proprietary database means it is almost impossible to export DIRECTLY from the DB. But exporting directly from even the three mentioned databases may be equally as hard. If it is a flat file database like Access then maybe, but no reasonable EMR today would be functionally sound with these low level databases. The three mentioned would need a table map to get data out or a HUGH amount of programmer work.

    With SAAS, there are two types, most are what you refer to here and are browser based – run inside a browser. With these if the vendor goes under you are toast – creditors may own the computers with your data or the computers may be under lease and lost -along with your data. The second type is true Cloud like Medscribbler cloud, where the server is technically owned by the doctor client and the EMR runs as a thick client – ie an installed app on each users computer but accessing the managed server.

    The best security against vendor financial failure is client server with an EMR that will allow basic demographics output into a text or XML file and at a minimum exporting of patient records including scans into pdfs, docs or even jpg format.

    Medscribbler is an easy to set up client server which can run like an SAAS with us managing the doctor owned server. It dumps patient info for import by any other reasonable EMR system.

  • CEOMike, thank you for that marketing effort. There are three things in there that need addressing:
    1. Throwing around words like “true Cloud” implies so many things… and a thick client is precisely what the Cloud is NOT. Further, it is possible to export entire databases without table maps–if anything, the concept of a table map is deeply-rooted in the on-premises database model and is virtually extinct in proper SaaS database services.
    2. Of course no DB (with the obvious exception of Google’s AppEngine) is built on one flatfile, which is why exporting databases includes multiple flatfiles, each with unique recordIDs, making it extremely simple to load into Access or to query with almost no programmer work.
    3. Thank you for promoting your company, but let’s stick to a discussion of the industry and the technology instead of advertising our products.

    Disclaimer: I work on the platform, and that is the system I know best. One can export an entire system into a series of flat-files (via SQL) with *unlimited* access to the *entire* dataset. It runs faster because it’s a thin-client, and the entire system can be integrated to a data warehouse if the client wishes to keep a local copy.

    After reading the above comment, I can’t say that I am optimistic about Medscribbler, given that the CEO calls it a cloud, yet I can see absolutely nothing in his description that supports that characterization.

  • Insightful entry, John. In the face of a staggering economy and the uneasy climate stirred by the stimulus, there’s much “wait and see” on the buyers’ side. I agree wholeheartedly that adoption will be slowed by the HITECH act, but also by the fact that the incentive plan, at this point, is strictly voluntary. Those physicians/practices who want an EMR/EHR solution fear productivity loss. Measures of usability have not been fully addressed across the market. In order to ensure “buoyancy” in the industry, a vendor must offer a quality product that is usable, adoptable, efficient, and safety-netted with outstanding support. Rather than be sold by a salesperson or consultant, buyers should lend their ears to their peers. No form of advertising or marketing can keep a company afloat like word of mouth. If the vendor provides a solution that is known to work and is proven to better the dynamic business of medicine, it will weather the current maelstrom of skepticism evident in today’s market.

  • CEOMike,
    I like your idea of an EHR software able to output patient charts into a PDF or other file format like tif. Sure would make switching EHR easier than trying to map each of the database fields. However, mapping the database fields is possible. I know, because I look through our EHR database all the time to run reports off of the data. It would be very time consuming, but wouldn’t be hard. To do just the most important parts of the chart would actually be relatively easy for my EHR vendor.

    Although, I’ve always said that if the clinic I work for (my day job) ever decided to switch EHR, I’d find new work.

  • David,
    I think you’re being too harsh when talking about definitions of cloud. My understanding is that Medscribbler can run off of what’s often called “cloud computing” and so his use of cloud is more than appropriate. Certainly there are long held discussions about SaaS EHR versus client server, however, I think Medscribbler has added a new twist by having your server in the cloud, but still getting the benefits of a client over a web browser.

    I think your comment about being able to export the entire app to a data warehouse for clients is what most SaaS EHR should do. If I was looking at SaaS EHR making sure I had a way to backup locally my data would be a major part of my discussion with that EHR company.

  • J,
    Fine comment. Definitely a lot of “wait and see” happening in the EHR industry. Although, I will reiterate that while adoption is being greatly slowed, interest in an EHR has probably never been higher than at this point.

    It will be interesting to see what happens with that interest in EHR.

  • John,
    I see where you’re coming from, but let’s not equate accessing a software product via a web browser with cloud computing. Whether the onsite server is accessed via a web browser or via a desktop application makes no difference. It is still a self-hosted solution, with all the inherent inconveniences and costs associated.
    I did not intend to be harsh, unless adhering to a strict definition of “cloud computing” is harsh.
    Glad you like the export feature that SaaS vendors should all have. I’d even take it one further and integrate the EHR with a data warehouse so that onsite backup copies are made in realtime, not just during incremental exports.
    If anyone would like to explain what specific characteristics of the Medscribbler product make it SaaS and cloud, I’d love to hear it. However, it appears no more “cloud” than an onsite hosted/maintained Outlook Exchange server that allows its users to run Outlook via a web browser… and nobody considers that cloud computing.

  • David,
    I agree with you that as long as the server is in your office it’s not cloud computing even if you access your own server through a web browser. There’s no doubt there.

    Real time backup copies to a data warehouse is nice, but I’m guessing would be too costly for most small clinical practices.

    I shouldn’t speak to Medscribbler specifically. I’ll let CEOMike do that. However, it seemed like he was describing a situation where the server was hosted in the cloud and then just accessed by the client. This cloud might be an EHR vendor cloud or even more cool would be if the EHR vendor’s cloud was built on top of one of the major cloud computing services like Amazon EC2. This type of hosting of an EHR vendor server would be really neat. Hopefully Medscribbler will describe exactly how they use the cloud, but this is what I inferred from what CEOMike said above.

Click here to post a comment