Epic's Principles, Part 7

Epic's 13 principles
1. Do not go public.
2. Do not be acquired.
3. Expectations = reality.
4. Keep commitments.
5. Be frugal.
6. Have standards. Don't do deals.
7. Create innovative and helpful products.
8. Have fun with customers.
9. Follow processes. Find root causes. Fix processes.
10. Don't take on debt for operations, no matter how good the deal.
11. Focus on competency. Do not tolerate mediocrity.
12. Teach philosophy and culture.
13. If you disagree, dissent. Once decided, support.

"Follow processes. Find root causes. Fix processes."

This one has always bothered me from a semantics angle. What is the Epic Employee to do with the knowledge of the Root Cause? Why was the employee told to find it? What if the process wasn't the root cause of the problem? I would have rephrased it to "Follow processes. Find root causes of problems. Fix root causes."

Epic has a lot of processes that need fixing, and since several of these processes have been flawed for the better part of a decade (at least), it's clear that Epic has no interest in fixing them. The most obvious example of this is their HR practice. Epic follows the practice of hiring the best and the brightest of the inexperienced. Shortly after the employee becomes competent with solo work, the load gets bigger until the employee either buckles under the strain or decides that the strain isn't worth it. At that point, the employee starts looking for work outside of Epic, taking all that experience with him.

The root cause of that problem is firing the employee instead of investing in their growth. Since Judy has gone on record at a staff meeting to lament their employee retention numbers, she could kill two problems by fixing one root cause.

Then there's the problem of Epic's development. Everyone who's gotten a peek behind the curtains knows that Epic's code base is held together with chewing gum and baling wire. A bona fide Patient Safety Escalation comes out every other week, and there are about a dozen Care Concerns each week.

Development processes were followed; Epic has numerous checklists for that. Problems were introduced into the product. Root causes were discovered by the Patient Safety committee. The problems were fixed after the fact (mostly), but the processes that allowed those issues into the software weren't modified.

The root cause of a given PSE is relatively easy to discover, and the code change required to prevent that specific problem from occurring in the future is manageable. However, the root cause of Patient Safety issues in general hasn't been looked at. How can Epic prevent buggy software from going out? I've heard suggestions (and posited some of my own), but nothing has changed.

While Epic talks a big game about fixing processes, they don't really deliver on that.

Go-Live Gone Wrong, Continued

I saw a co-worker reading this: Epic Installation Proves More Expensive, and I read the article over his shoulder. It's a follow up to the Go-Live Gone Wrong article that I wrote about a while back. In a testament to the state of modern journalism, the only new fact is that Maine Health is spending $55 million dollars more, solely because of Epic. Most of the money is for training and retraining users, with the remainder being used for the previously planned rollout of Epic throughout the organization.

 The comments on the article are interesting--especially the one about Stockholm Syndrome amongst Epic's customers. While technically Epic doesn't have a monopoly on the industry, free-market principles don't apply to EMRs. It is just too expensive (in dollars and hours) to take one's business elsewhere if an EMR vendor doesn't deliver.

Does Judy know what happens at her company?

A coworker of mine showed me this article: Healthcare IT News: Go-live Gone Wrong. It details a couple of organizations that had huge monetary issues after going live with Epic. Apparently, no one told the clinicians that they'd have to take charge of some of their billing workflows (e.g., Charge Capture), therefore the hospitals had huge budget shortfalls.

It brings to light an old problem with Epic: lack of training. I'm not sure what Epic provides for trainers at customer sites, but this shouldn't have even been an issue--Epic's implementation staff should have covered this in their project plan. However, Epic doesn't always provide IS for existing customers. Everyone has a TS, but they certainly aren't trained in any kind of project management skills--I don't think it was just me, but during my tenure TS received no training (there's that word again) in project management. We weren't even given a book on the subject. Project Plans are just not something TS know about. The tools given to IS at the start of their new employee orientation are geared to helping new customers and getting someone with no healthcare experience a chance of successfully completing a large-scale multi-million dollar project.

I don't know any specifics about these implementations other than what's in the article--I don't know if it was an IS or a TS who screwed up. I do know that Epic is giving itself a bad reputation with this kind of thing. Training is, at its core level, a somewhat rapid way of imparting experience. As the target audience of this blog can attest, Epic has a problem with giving anyone more experience than the bare minimum necessary. While I don't know if it was an IS or TS who failed here, I'm >80% certain that that employee had less than two years of Epic experience. Anyone who had been there longer would have known better and this wouldn't have happened.

And that brings me to Epic's biggest problem: its turnover rate. Whether its from employees getting burned out and leaving on their own volition or the employees being forced out--there is an unmistakable dearth of experience at Epic. My current employer, when I started working here, had an experienced TS. We've been live on Epic for a while, and the TS had been at Epic for most of that time. That TS had seen the changes Epic had gone through, been through the transition from table-based order transmittal to rule-based, helped us with our build decisions and, in short, knew the differences between our system and Epic's Model. Well, that TS left, amazingly without exhibiting any outward signs of burnout, and was replaced by a fresh out of training newb. Two years later, after dealing with I don't know how many "I don't know" responses on weekly issues calls, the replacement has burned out and left. We're now on our third TS in as many years, and the replacement's replacement shows all the outward signs of being new, as well.

From a personal standpoint, the team feels betrayed by Epic. I know my customers from my TS days felt that way when I was pushed out and replaced by newer folks. (They told me as much when I asked if I could use them as references.) It's a problem that has been going on for years now, and based on Judy's high and mighty rhetoric about how much support Epic customers receive, I get the impression that no one in her circle actually has the boots-on-the-ground perspective--or maybe they're too scared to tell her.

The current impression at my organization is that Epic doesn't care about live customers. New, implementing customers are great, and Epic will move mountains to make sure things are done right (or not, I've heard interesting things about Duke's implementation). But existing customers adding new clinics and new hospitals can figure it out themselves. Epic's already got their money.

My advice to Judy, if she (or her delegates) are reading: You actually need to retain your staff. Free health insurance and a month-long sabbatical aren't enough--you will have to quit firing people. It is not, in fact, easier to train someone new than to re-train someone with experience. Experience matters to your customers, and Epic's lack of it is starting to show.