By Ken Congdon
Back in the 1970s and 80s, “Nobody gets fired for buying IBM,” was a popular saying in corporate IT departments, given the dominance of the vendor in the computing space. Well, it appears a similar adage is currently trending in healthcare when it comes to EHR deployments — “Nobody gets fired for buying Epic Systems.” Boasting a dominating 20% of ambulatory and 19.1% of hospital Meaningful Use attestations to date1 and winning new hospital contracts at a 2-to-1 clip over its next closest competitor2, Epic is the undisputed 600-pound gorilla in the EHR market.
Epic may have the EHR world by the tail today, but whether or not the company is well positioned to hold onto its reign over the long haul remains to be seen. Like most EHR software platforms on the market, Epic is built on a client-server architecture. Many argue that this model is not ideal to accommodate the massive transformation currently occurring in the healthcare space — a transformation focused on opening up health data to facilitate exchange with providers, payers, and patients.
To this contingent, only cloud-based EHR platforms based on open data standards offer the flexibility necessary to quickly satisfy the dynamic demands of a healthcare industry in flux. “Client-server based EHRs offer centralized control, but they are also time-consuming to implement, expensive, and slow to change,” says Ed Park, EVP and COO of cloud-based EHR vendor athenahealth. “Open, cloud-based systems, on the other hand, offer an ideal platform to accelerate innovation. Accelerating EHR innovation from all points of the care continuum becomes increasingly more important as our health system continues to shift away from the hospital and towards a community of care that includes the patient at the center.”
Park explains how many Epic consultants bemoan the fact that it is currently extremely difficult to take innovations from one Epic installation and apply them to another because all the data dictionaries are different. This is an issue a cloud-based platform like athenahealth eliminates by creating a single standardized data schema nationwide. Park also notes that the ability for client-server based EHRs to innovate is further hindered by the fact that the company doesn’t have first-hand access to the data being captured by the software. Instead, the company is forced to retrieve it second-hand from its customers. According to Park, this data is “the rocket fuel for innovation,” and providers that select Epic or another client-server based EHR will essentially be locked out from applying new EHR innovations in a timely manner.
The previous weaknesses outlined by Park don’t just apply to Epic, but all client-server EHRs. However, there is one characteristic specific to Epic that could raise additional concern for the platform’s longevity — its programming language. Not only is Epic built on a client-server model, but it is also written using MUMPS (Massachusetts General Hospital Utility Multi-Programming System) — a programming code developed in the late 1960s. According to Park, MUMPS programmers are a dying breed, making it difficult to find people with the skill and/or desire to write extensions for Epic. This lack of resources could further impact Epic’s ability to innovate.
Why Is Epic Winning?
It’s true that Epic lacks the modern Web 2.0 technical features many believe are essential for an EHR with staying power. Why then is Epic so dominant in the EHR market? Why then would Bernie Rice, CIO of Nemours Children’s Hospital in Orlando, choose Epic when asked to select an EHR that was “future-proof” for a hospital that was built from the ground up and opened in October 2012?
Epic must be doing something right, and John Halamka, renowned CIO of Beth Israel Deaconess Medical Center (oddly enough not an Epic shop), pinpointed a few of the vendor’s key strengths in a blog post he penned last July. According to Halamka, one of the biggest reasons Epic is so popular among hospitals is its ability to address the key IT pain point of motivating clinicians to standardize work.
“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,” he says. “Epic’s project methodology establishes the governance, the processes, and the staffing to accomplish what many administrations cannot do on their own.”
Halamka also argues that Epic’s innovation limitations (a key weakness of the platform according to Park) actually help to ease the burden of demand management for hospital IT departments. To Halamka, unlimited innovation potential isn’t always a good thing because IT is not always in a position to satisfy internal demands for automation.
Finally, Halamka argues that Epic is winning because its enterprise-system architecture taps into industry demands for integration. Moreover, he states that this design makes Epic a safe bet for Stage 2 Meaningful Use (MU).
Park agrees the integration element is a key factor in Epic’s success, but argues that selecting an EHR solely for this reason may not be the best long-term strategy. “Currently, healthcare providers are all rushing to check all the boxes for MU,” he says. “Epic provides the integration necessary to achieve MU — or at least the perception of integration. For the time being, providers are willing to sacrifice innovation for integration. Providers feel they are getting 80 percent solution by selecting Epic, and they probably are today. However, I would argue that Epic could look more like a 20 percent solution five years from now as the new EHR innovations on the horizon come into the fold. The initial realms of the PC wars were built on functionality, but later gave way to usability. I think the same thing is going to happen in healthcare. Once the MU need is satisfied, the more human aspects of EHR usability will come into play. The question is, will Epic be able to satisfy those needs?”
Let’s assume for a moment that Ed Park is correct. Let’s assume that usability and flexibility will eventually trump integration as the key requirement for EHR technology. Let’s also assume that open, cloud-based systems are inherently better suited to address demands for usability and flexibility than client-server systems. Could Epic potentially shift to a cloud-based model when usability becomes the more important factor in the EHR equation? I would say no it couldn’t. I would also argue that Epic wouldn’t want to go down this path even if it could.
Everything about the way a cloud company is wired is completely different from a client-server company from a business model standpoint. Epic would not only have to rebuild its core technology (an unperceivably costly proposition), but would also have to completely overhaul its revenue model. Nope, I don’t think a cloud transition is in the cards for Epic. I would also argue that it probably doesn’t matter. While the cloud may have its advantages, it’s ludicrous to think that a client-server based product can’t have staying power, even in today’s Web 2.0 world. One needs to look no further than Microsoft to find proof of that point.
Does that mean I think Epic is future proof? Not necessarily. I don’t think any company is immune to the risks associated with a volatile EHR market. That being said, I do feel that Epic is better positioned than most vendors to be a long-term fixture in the EHR space. It may be slower to innovate than some of its cloud-based competitors, but its market share, reputation, and deep pockets will likely keep it an EHR power even if by sheer force of will alone.
1 Source: Software Advice
2 Source: KLAS Clinical Market Share 2013: More Than Meaningful Use report