Hospital Information Systems: Ripe for Disruption

The Hospital Information System (HIS) market is ripe for disruption. One HIS project in Toronto was recently estimated at $600M. Another HIS implementation in Vancouver recently cost $850M. That is not the cost to build completely new software systems. That is the cost to license and install already built software, configure it, and train staff on how to use it. My first thought on seeing those numbers is: “Man, I’m in the wrong business.” My second thought is: “The days of multi-hundred-million dollar HIS implementations have got to be numbered.”

Hospital Information Systems are responsible for tracking many things: admission, vitals, lab results, radiology, diagnoses, pharmacy, treatments, discharge, and also often beds, billing, staffing, and other administrative tasks. The idea that the way you make a hospital is that you build a big building, fit it out with medical hardware, and then spend hundreds of millions of dollars on a single monolithic piece of software to run the entire place is last century’s thinking.

I see three forces driving this change. The first one is technology. Last century it was perfectly normal to build your own data centre and then buy a large proprietary software system to run in it. Other industries just don’t do that anymore. More than half of Canadian hospitals are running on software built on MUMPS, a software platform invented in the 1960s that runs on a proprietary data store and programming language that predates SQL. This means there is no practical way to get data out of these systems to measure things like operational efficiency or clinical outcomes. Other industries run on modern data repositories with properly layered architecture, and can partner with a wide range of analytics vendors to monitor and improve operational performance.

The second force driving this disruption is innovation. The problem with relying on a single monolithic HIS to run your entire hospital is that while some features of that HIS may be best in class, other parts will be frustratingly inadequate. The hospital may want to replace the weaker parts with modern innovative solutions, but due to technology limitations, will often find it impractical to do so. Some hospitals forge ahead with the innovative solutions anyway, and force their users into awkward workarounds to deal with the lack of interoperability.

The third force is the one that I believe will push the inevitable disruption over the edge, and that is the need for continuity of care and consumer access. Patients increasingly expect to play a role in the management of their own healthcare, and they expect to be able to share their health records with all of the people caring for them. Traditional Hospital Information Systems were designed to be self-contained operational systems; not well suited to open collaboration.

As any industry about to be disrupted, HIS vendors are painfully aware of these challenges. They feel the future breathing down their neck. Some of them will make the radical transformation necessary for survival. Others will be left behind. But none are prepared for the disruptive new players that will enter the field and turn the market on its head.

If I had a blank slate and could design a modern HIS from scratch, I would separate the data repositories from the workflow apps that run on top of them. The data repositories (lab, meds, vitals, charts, etc) would be independent, standards-based interoperable data stores. And I would promote a broad market of apps to run on top of these data stores, encouraging the best of breed for each domain to rise to the top. The total cost would be considerably lower (I would venture at least one order of magnitude), and innovation would flourish. This separation would also permit flexibility on how clinical data stores are shared across regions.

As Herbert Stein famously observed, “If something cannot go on forever, it will stop.” I believe it is inevitable that the trend of purchasing multi-hundred-million dollar hospital systems will come to an end.

share this article...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn