There was also a more subtle flaw. The desire to continue to pack things into the basic OE/ R – EMR design in order to to pick up all the extra potential pieces of ROI in order to pay for front-end costs. Imo, this has led to a tremendous overengineering – if the original objective was to support clinicians in day-to-day care delivery – and projects-that-never-end phenomenon. In the run-up of design with the intent to reach a “critical mass” of functionality necessary for lots of buckets of benefits to accumulate a positive ROI, we continually forget that in physics critical mass is when things explode. Which they do in overly complexed EMR projects too. It usually takes about a 7 year cycle to forget and the complexity to return. E.G. CHINs to RHIOs

Obviously, the advances in architecture and increases in computing power and storage could address the first problem. But, over the years EMR projects have taken on a life of their own. The sunk cost – $, emotions, egos – prevents returning to the original design questions and objectives. It prevents the potential for rethinking the answers and adopting new tools to achieve the core objectivs. Instead, one vendor with a data processing architecture is abandoned for another. And so cultural clashes over objectives and priorities continue, if not getting worse. I think we would be best served if we followed Antoine de Saint-Exupéry’s advise: “Great design is not when there is nothing left to add but when there is nothing left to take away”. That is, let’s get “hospital systems to swap clinical data across the hall” and then move on.

But then again, who really cares if there is no money to be made?