Habush Habush and Rottier

Friday, June 13, 2014

Epic's Principles, Part 5

 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.

"Create innovative and helpful products." Having recently spoken to some brand new Epic users, I could have some fun with the "helpful" part of this, but since I did drink the kool-aid pretty heavily for my tenure at 1979 Milky Way, I'll abstain from most of the snarkiness.

When used well, I do think Epic is really helpful. As a MyChart user, it's great to be able to see my lab results whenever I feel like it. It's convenient to schedule appointments without having to wait on hold on the phone. As someone who's watched clinicians ooh and aah when they were able to see other providers' notes on their patients, it's obvious that Epic can be helpful.

A couple of things have to align for Epic to be helpful: The customer has to have implemented the software correctly, and Epic's code has to work. It's not a principle, but it's shown at every staff meeting: "Rule #1: Software must work. Period." Judy used to enjoy mentioning how the Cerner CEO thought that was a personal dig directed at him, but I've seen enough Patient Safety Escalations and Care Concerns coming from hastily coded Epic software to say that Epic is guilty of breaking Rule #1, too.

Software that doesn't work isn't helpful. When Epic works, it's beautiful, but when it doesn't work it's downright dangerous. Epic needs to work on the safety of its products. That, in turn, will increase the helpfulness factor.

I'll give Epic half credit on the helpfulness bit of Principle 7. As for innovation, there's a good mix of innovation and stagnation happening in Verona.

On the one hand, they haven't done much that's truly groundbreaking since taking over the entire industry. Their new products are primarily focused on providing an Epic option for specialty software that used to be sold by best-of-breed vendors. On the other hand, MyChart is really cool, as is Haiku and Canto.

Meriam-Webster defines innovation as merely an improvement over something existing. By that definition, Epic is constantly innovating, as their software is consistently getting better over time. However, my own exacting standards demand more. I feel that innovation needs to be more earth-shattering, like what the iPhone did to the cell phone industry. Giving patients easy access to their own health records was that kind of game changer. There's a Chronicles quote that says "Talent hits a target that no one else can hit. Genius hits a target that no one else can see." MyChart was genius. Beaker, Phoenix, Beacon, Thumper or iHeartHearts or whatever they're calling Cardiant now--those  all stem from talent. Innovation requires genius, in my book.

tl;dr: Epic does a pretty good job with innovation and helpfulness, by the dictionary definitions. I wish they would do more and try harder to be more helpful and innovative.


  1. Currently, I am working on my masters degree in healthcare informatics. One of your statements is exactly a point that I am trying to get more detail on for a paper. At the facility were I work, we recently implemented Epic but we are having terrible issues with its ability to interface with the "specialty software" like our care management system, Midas. Instead of fixing the problem of duplicate encounters, we are often given the suggestion to implement their care management system. Sounds sorta shady... A year since the implementation, we still have the same issue.

    1. Is it Epic's job to interface with all of your 3rd party systems? Or is it your organizations job to verify that Epic is compatible with the 3rd party system before implementing it?

      Epic isn't responsible for fixing every issue that exists with your system. If the problem is Epic's.. then fine. But if the problem is that you want pieces of Epic.. and you want those pieces to integrate with pieces of 3rd party software.. and it just isn't happening.. then I think you need to revisit where you're placing blame.

      Unless Epic told your organization that they can interface seamlessly with Midas, then I don't see how it is their fault.

    2. Since none of Epic's principles actually mention taking care of customers and providing good value for the money they're paying, I guess Epic can do what it likes.

      It is shady business. There are as many reasons not to go Epic-Enterprise as there are reasons to get the whole software suite. As a company that touts its customer service (20+ employees per customer, rather than 100 customers per employee), it's not providing good customer service in this case.

  2. I don't think a lot of those inpatient apps were coming from talent. It's more out of a desire to fit the specialty workflows, as Inpatient and Ambulatory were the square pegs being hammered into circular holes. I saw it with Cupid's (cardiant) rise - it basically happened because people were making crappy versions of Cupid using Radiant tools, and it was unacceptably bad.

    Having seen the dev side as a TS, very few of our devs get to innovate - most of our "innovations" and "talent" come from customers complaining about features they lost from best-of-breed software. Epic's specialty apps come from trying to reach parity with competitors rather than innovation.