In the Boston marketplace, Partners Healthcare is replacing 30 years of self-developed software with Epic. Boston Medical Center is replacing Eclipsys (Allscripts) with Epic. Lahey Clinic is replacing Meditech/Allscripts with Epic. Cambridge Health Alliance and Atrius already run Epic. Rumors abound that others in Eastern Massachusetts are considering Epic.
Why has Epic gained such momentum over the past few years? Watching the implementations around me, here are a few observations.
1. Epic sells software, but more importantly, it has perfected a methodology to gain clinician buy-in to adopt a single configuration of a single product. Although there are a few clinician CIOs, most IT senior management teams have difficulty motivating clinicians to standardize work. Epic’s project methodology establishes the governance, the processes, and the staffing to accomplish what many administrations cannot do on their own.
2. Epic eases the burden of demand management. Every day, clinicians ask me for innovations because they know our self-built, cloud-hosted, mobile-friendly core clinical systems are limited only by our imagination. Further, they know that we integrate department-specific niche applications very well, so best of breed or best of suite is still a possibility. Demand for automation is infinite, but supply is always limited. My governance committees balance requests with scope, time, and resources. It takes a great deal of effort and political capital. With Epic, demand is more easily managed by noting that desired features and functions depend on Epic’s release schedule. It’s not under IT control.
3. It’s a safe bet for Meaningful Use Stage 2. Epic has a strong track record of providing the products and change management required to help hospital and professionals achieve Meaningful Use. There are no certification risks and no MU-related product functionality risks.
4. No one gets fired for buying Epic. At the moment, buying Epic is the popular thing to do. Just as the axiom of purchasing agents made IBM a safe selection, the brand awareness of Epic has made it a safe choice for hospital senior management. It does rely on 1990’s era client server technology delivered via terminal services that require significant staffing to support, but purchasers overlook this fact because Epic is seen in some markets as a competitive advantage to attract and retain doctors.
5. Most significantly, the industry pendulum has swung from best-of-breed/deep clinical functionality to the need for integration. Certainly Epic has many features and overall is a good product. It has few competitors, although Meditech and Cerner may provide a lower total cost of ownership which can be a deciding factor for some customers. There are niche products that provide superior features for a department or specific workflow. However, many hospital senior managers see that Accountable Care/global capitated risk depends upon maintaining continuous wellness — not treating episodic illness, so a fully integrated record for all aspects of a patient care at all sites seems desirable. In my experience, hospitals are now willing to give up functionality so that they can achieve the integration they believe is needed for care management and population health.
Beth Israel Deaconess builds and buys systems. I continue to believe that clinicians building core components of EHRs for clinicians using a cloud-hosted, thin client, mobile friendly, highly interoperable approach offers lower cost, faster innovation, and strategic advantage to BIDMC. We may be the last shop in healthcare building our own software and it’s one of those unique aspects of our culture that makes BIDMC so appealing.
The next few years will be interesting to watch. Will a competitor to Epic emerge with agile, cloud hosted, thin client features such as athenahealth? Will Epic’s total cost of ownership become an issue for struggling hospitals? Will the fact that Epic uses Visual Basic and has been slow to adopt mobile and web-based approaches prove to be a liability?
Or alternatively, will BIDMC and Children’s hospital be the last academic medical centers in Eastern Massachusetts that have not replaced their entire application suite with Epic? There’s a famous scene at the end of the classic film Invasion of the Body Snatchers which depicts the last holdout from the alien invasion becoming a pod person himself. At times, in the era of Epic, I feel that screams to join the Epic bandwagon are directed at me.
[This piece was originally published on John Halamka’s blog, Life As A Healthcare CIO, on July 24, 2013. To view the original post, click here.]
Dale Sanders says
John, as usual, you provide a succinct and precise description of the situation. It’s a situation that is very troubling to me as a customer of the care delivered through EMRs, not to mention an informed member of the HIT community.
I’ve been blessed by fate– no skill of my own– to manage a great home grown EMR system at intermountain (HELP). Later, at Northwestern, we managed Cerner and Epic; and now, in the Cayman Islands NHS, we run Cerner, too. While HELP is certainly a technology platform that is no longer realistically supportable, I can say without reservation, HELP is enormously more adaptable from a software engineering perspective– it was designed with object oriented and loosely coupled software, long before those were common practices– and that adaptability is one of the most important reasons for the innovation and high ROI that Intermountain’s culture derives from IT.
Epic and the other EMRs that are popular in the market today are a reflection of old school Healthcare 1.0, motivated by defensive medicine and billing, not clinical efficiency, quality of care, patient engagement in their own care, and affordability of care. Maybe worse, today’s commercial EMRs are also a reflection of old school software engineering– tightly coupled, Win32 applications– which translates into software that must be tortured into supporting innovative clinical and business processes– “innovative” concepts like clinical ease of use and efficiency, quality of care, patient engagement in their own care, and affordability of care. At Northwestern, we had a substantial team of very talented programmers dedicated to extending the functionality of Epic and Cerner in very minor but important ways. Epic and Cerner’s APIs were incredibly closed at that time, in 2009. Even minor extensions of functionality were laborious to develop. Cerner is turning the corner with MPages, finally buying into the realization that an open and flexible API will grow their business, not threaten it. I see nothing of the same coming from Epic, technically or culturally. And thanks to $25B in federal incentive money, there is no natural incentive in Epic, or the market in general, to build anything more innovative, functional, adaptable, or agile.
Epic should take it upon themselves to apply a trivial $100M of the many (billions?) in tax dollars that have funded Epic’s windfall and invest that money back into society by building a totally new generation EMR, technically and functionally. If Epic wants to leave behind a big legacy, that would be it. If not, they are going to leave behind a very different legacy—in a few years, the market and federal government will look back with regret on the rush to adopt a very brittle EMR that cannot adapt to Healthcare 2.0 and the Triple Aim.
I applaud your courage to stay the course of EMR independence, John. Credit to you and BID. You’ll inevitably be faced with the same challenges we had at Intermountain and the declining supportability of HELP, but maybe if you can hold out long enough, there will be a new generation EMR– an enterprise Healthcare Information System– that reflects modern software engineering and the functionality required by Healthcare 2.0.