Disruption in the EHR Market: Will Anyone See It Coming?

Having gone from writing FORTRAN programs on mainframes to creating web applications in the cloud, I have seen the computer revolution up close.   Change has been the only constant, and yet innovations are consistently overlooked, especially by companies who are next on the endangered species list.    Yahoo and Alta Vista were Googlelized.  Blackberry, having been cored, was just recently sold.  Digital Equipment Corporation, which in the age of mainframes became the #2 computer company by way of minicomputers, ignored personal computers until it was too late.   Wang once led in word processing.   Remember Novell? The list of has-beens is full of big names.

As someone who would love to buy stock in the next,  “next big thing,” I spend a lot of time pondering why market leaders so often fail to spot key trends. I am especially interested in what makes a technology disruptive and what counts as an innovation.  Here are my conclusions.

Migrating to new technologies is not a straightforward process
Most current EHRs were developed for classic LAN-based client/server architectures. Migrating those systems to the cloud is not a simple matter of moving a database to a server and writing a web interface.   Cloud development is vastly different than LAN-based C/S, as is mobile.   Cloud databases are multi-tenant; LAN-based ones are single tenant.   Most LAN-based EHRs were based on Microsoft technologies from operating system to development tools.  Mobile and the cloud platforms are much more diverse. Mobile is dominated by Apple and Android, making Java and Objective-C major players.  Web applications tend to use MVC architectural models and make use of JavaScript, HTML, and CSS.

Migrating from a LAN to the cloud, done properly (and if not, it will be noticeable), not only requires a development team with very different skills, but also a redesign of the application’s underlying architecture.     The number of adjustments that companies have to make in terms of personnel and product design/architecture is disruptive in so many ways that it creates an opening for new companies.   Even worse, competition for the required talent is cut-throat (that is, once a company finally realizes new talent is needed).    Significant technological change goes beyond leveling the playing field, it changes the rules.   Advantages can disappear quickly.

“Best” is always relative
I happily used a flip phone until last year.  Now, I use my smartphone as much as my laptop, but for very different things.  Overall, I am more productive, and until I got a smartphone, really didn’t see what all the fuss was about.   My frame of reference for  the best way of doing things was based in the past, and since I had fully adapted to that “best way,” it was not only hard to imagine a new best way, but even bothering to do so seemed to be a waste of time.  That is my only explanation for why I had no problem seeing the cloud and NoSQL as obviously useful innovations while being lukewarm to smartphones.

I’m sure a lot of CEOs think the same way.   They see their current products/services as best ways and consider “new fangled” technologies to be fads until it’s too late to catch up.   If revenue is steady and customers are happy, few will really try anything radically different—if it ain’t broke…

Sufficiently novel innovations are treated as curiosities and not as valid alternatives

If you want something new, you have to stop doing something old
Peter F. Drucker

Anything truly new is usually poo-pooed. For some reason, it is easy to assume that version 1.0 of a product/device/service–anything really–is the best version that will ever be and then attack it for not being really useful.  Obvious shortcomings are attacked while promise and potential are completely ignored.

This pattern has been consistent across last the 30 years of computing.  Personal computers were given this treatment until the IBM PC AT appeared.   Distrust of the cloud parallels exactly what I heard concerning LANs in 1990.   Remember how the iPad was derided in 2010?

Of course, creating something sufficiently novel requires going against the conventional wisdom. This in itself creates an odd dynamic–everyone is looking for the next major innovation, yet when it arrives, it is initially ignored or treated with snarky contempt.

With the above in mind, it seems safe to make two predictions. First, any sufficiently new approach to EHR design will be rejected as untested and unworkable, especially if the inventor lacks a clinical or informatics background (the no one else understands healthcare fallacy).   Second, EHR vendors will say: 1) their current products have all of the supposedly new features, so there is no real innovation, or 2) any features that the new product  has that their products do not have are superfluous and simply there for marketing purposes.    One thing is certain: skepticism will abound directly in proportion to the novelty of the product and/or feature.

Innovations solve real problems
Products that succeed solve real problems. They save money, assure quality, increase productivity/efficiency, lower costs, increase revenue or ease regulatory compliance.  One of the reasons that Cerner and Epic are dominating is that both reduce the need for costly and troublesome interfaces, which are essential in best-of-breed EHR approaches.  Here is my brief list of market issues with corresponding product features that I think could be disruptive in the EHR/HIT marketplace.

Proof of care quality/data quality
The marketing literature of every healthcare organization states that it provides the best care possible.  No one will quibble with this until someone has hard numbers.   The first healthcare entities that get hard evidence that they provide high quality care will use it as a marketing tool.  This does not mean they will denounce other provider organizations, but only that they will make a strong case for themselves with plenty of graphs and charts.  Convincing proof requires data at a quality level that few EHRs (if any) can currently provide.

Fear of being tied to a vendor/data portability
Moving data between systems is a headache.   Fear of being tied to a product or being unable to move 100% of data are legitimate concerns.  Though it goes against the conventional wisdom, removing that fear could lower the threshold for buying a product.  I think there is a lot to be said for data portability as a marketing point.   However, I am sure any EHR vendor reading this will likely end up ROTFL.

Customizable systems/EHR platform
I think platform EHRs have significant disruptive potential.  Buying and implementing an EHR are significant barriers, especially for small practices.  Why not let practices buy what is needed as they see fit?  Even better, allow mixing and matching to attain the desired functionality. Not everyone needs a full-featured product.     This approach works best if third-party developers are allowed to provide apps/plug-ins/modules that extend basic functionality.   The platform would provide essential features such as data store, security, data exchange, etc.– the rest would be add-ons.

A platform EHR would require a different support system, would likely lower consulting revenues for implementations, lower the overall cost of clinical software, and threaten the profitability of current vendors.   I am aware of two viable attempts at platform EHR-like systems; however, neither takes it to the extent I am advocating.   And in all likelihood, no current vendor will do so because that would threaten current revenue streams.   Having an API where third parties can write apps for a system is a good beginning, but does not a platform EHR make.

Implementation and training ease/configurable workflows and user interfaces
Full-featured EHRs are complex systems.   Any product that can hide that complexity will be welcomed.    Implementation difficulty and training times are both reflections of EHR ease-of-use.    Currently, practices have to adjust to the interface and workflow that are built into the product. Why not change that approach?    There is no reason why an EHR cannot have user-configurable workflows or interfaces.  Products with these capabilities would be more difficult to design and build, but having a product that a practice didn’t need a consultant or major hand-holding to implement would be a major innovation.   The first vendor that can provide objective evidence that its clients have reproducibly lower costs, the same or higher revenues, and increased productivity will not really need much of a marketing department.

EHR systems on the market, except for modifications due to MU and movement to the cloud, are pretty much as they were in 2000.   Today, we have faster computers, faster networks, more memory, more delivery platforms, better software development practices, and better development tools.   The dominant vendors are consolidating their market shares and expanding their customer bases.  They are doing well, and have no reason to change.   The price of entry into the market for newcomers is so high that market leaders seem to have little to worry about other than the next sale.   Now, where have I heard this before???



  1. This was a very interesting post. The user experience offered by Cerner and Epic is decidedly lacked. I still find CPRS/Vista at the VA, for all its flaws, to be the most usable EMR.

    I wonder about disruptive innovation in the user experience as well. For instance, I think there is potential for an EMR to completely do away with note-writing as we currently understand it, which would represent a true value and time-saving.

    Others have pointed out the lack of EMR usefulness in any sort of task management activity. For my personal life I have a task manager that synchronizes with my online calendar and email, but at work I carry around a sheet of paper with a bunch of checkboxes on it…

    1. Mark, thanks for your comment. I agree that the UI is a prime target for innovation. If you have read some of my other posts you will note the importance attached to supporting processes, which is what the task manager example illustrates.


Leave a Reply

Your email address will not be published. Required fields are marked *