Habush Habush and Rottier

Wednesday, August 7, 2013

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.


16 comments:

  1. In the article, the nurse mentions that there are eight different ways to do the same thing, and that they weren't sure if they are actually doing everything right or not... Exactly! Even during my 1.5-year tenure as a TS at Epic, I wasn't sure what the right way was a lot of times. I had to dig through multiple documentations and ask several people before I could get an answer. Even then, I sometimes came up conflicting responses...

    Epic's software is too complicated in general. New Epic employees go through several weeks of training just to learn how the system works (but only at a high-level, which is definitely not enough for troubleshooting purposes)... It is not intuitive and user-friendly. Granted, the nature of healthcare documentation is complicated, but there are a lot of screens that regular nurses don't use on a regular basis that can be removed...

    Epic really needs to think about how to make their software more simple overall...

    ReplyDelete
    Replies
    1. Having worked as an IS for over three (3) years at Epic (yes, I am a former employee), I can confirm that there are multiple ways to perform an action and I've often gotten mixed reviews from people about that.

      Lots of software systems offer multiple ways to get to a particular screen- I'm not aware of one that only offers one way to get to a workspace.

      Once customers learned the system, many reported that they found a way that works for them and are happy. Why the big fuss about having multiple ways to access a screen?

      Delete
    2. @Anon8/13 11:40--
      The problem is that, depending on build (or recent patient safety escalations/care concern bulletins), one method may be broken or it might not work the same way as another method. Users are often be trained on one method for a given reason.

      Viewing results is a classic example. I see a care concern regarding results at least once every other week. Some organizations create flowsheets for certain test batteries, others train Results Review and only Results Review, still others might just use the Results In Basket messages, and the flowsheet-on-the-fly functionality contained therein.

      It causes problems when those differing methods get broken. The Flowsheet on the fly has a problem, so we tell our providers not to use it. However, we can't be sure that all providers got the message or remember the message--it's a problem created by Epic development, and exacerbated by having multiple ways to accomplish one task. I can view a result 6 different ways, but if 3 of those ways are untrustworthy, then any convenience gained by accommodating multiple workflows isn't just moot--it's downright dangerous.

      Delete
    3. The previous post makes a good point... Another reason is that doctors (especially specialists) generally don't have the time to learn all the different methods and when they are presented with multiple ways of doing the same thing, they get easily frustrated... This is something that I observed firsthand. However, if you simplify things by having just one way of doing it (and focusing development efforts into making that one way easy and robust), then people will learn the system more quickly.

      Delete
  2. Sorry to return to the topic of non-competes, but as a potential employee; does the non-compete prevent you from working at all at a connected consulting company? Or only with projects that might conflict with Epic's software/etc.

    Thanks.

    ReplyDelete
    Replies
    1. (Does anyone have a copy of the current non-compete? It'd be nice to publish it.)

      It depends on the consulting firm. Some consulting firms only deal with healthcare IT, and they would probably be pretty strict. Other consulting firms have broader scope--it might be possible to work on a non-healthcare contract for the year of the non-compete. I think your best bet is just to call the firms you're interested in and ask. (And then post your findings here :) )

      Delete
    2. Ah, thanks for the reply. I'm still looking around, so I'm not sure if I'll be working at Epic, but I just wanted to get some more info before I decide. Probably due to the size of the company, opinions seem to be all over the place; so just in case I decide to work there and don't like it, just thought I'd explore what the limitations were.

      Thanks again.

      Delete
  3. People like to blame training but at some point the blame lies on the end user. At my current install, we've had hours of training, several hour long "SWAT" meetings on a weekly basis, in-services, etc. Lo and behold, we still see the same errors.

    I know this isn't the case for a lot of places, but the transition from paper to an EMR is a long upward battle for a lot of people.

    I'm curious about Duke's implementation. Can you expand a little on the "interesting" things? I'm at a different large academic health system.

    ReplyDelete
    Replies
    1. What I've heard comes third-hand: I heard that Duke was halfway through the implementation, when someone realized that it was going extremely poorly. They had to scrap it entirely (to the tune of replacing a lot of staff, firing an entire consulting firm, and firing Epic's IS) and start over. Rumors being what they are, I'm not sure how much, if any, of this is true.

      Delete
    2. They were pretty desperate at the end. One month prior to go-live, they hired a dozen build consultants to help complete build on the access side. Then they brought in a few hundred consultants to assist with go-live. I'm not sure how it all turned out. I'd love to hear more as well.

      Delete
    3. As a person knowing about the dozen build consultants, it was very difficult to build anything. The build environments still had whatever was previously built when everything was scrapped. A month before, the builders frantically received dozens of those department analysis sheets. These included some of the old information that was no longer valid, as well as hand written notes and highlights suggesting what needed to be built. Sometimes these conflicted with each other significantly - requiring a complete rebuild of their providers, visit types, and schedule templates. Sometimes what was written down was not what the department really needed. There was also significant tribal knowledge that was unknown to these last minute outside builders. They couldn't read minds. I'm not certain exactly how much was completed correctly by go-live. Based on the comments here, it doesn't surprise me that they had a bumpy time.

      Delete
  4. I'm a Credentialed Trainer, and this is the second hospital system I have worked for. The training I went through in order to teach end-users was pretty intense. The IDs (or PTs, depending on your hospital) went through certification, and then came back and were supposed to be well-versed enough to teach us the entire inpatient system. We had 6 weeks of classroom training, followed by 2 weeks of teach-backs and a panel presentation to Epic reps.

    But I will say this: most of what I learned about Epic, I learned on my own. I have yet to have a PT that knows as much as I do, simply because I took the time to explore on my own.

    The nurse that said they weren't taught Charge Capture? I find it REALLY hard to believe that the ENTIRE hospital wasn't taught how to charge. Unless they only had one trainer teaching ALL of the nurses, it's just unfathomable. It's part of the lesson plans (and yes, I know they're basic plans that are customized by each hospital. But could they really be stupid enough to eliminate something that takes all of 2 minutes to teach?)

    ReplyDelete
  5. Bill Simmons calls it the "Director of Common Sense" and most news organizations call it an "Ombudsman", but at the very least, having someone on the board who likes to call BS and challenge the status quo is extremely important. Would be interesting to see who does that at Epic, if anyone.

    ReplyDelete
    Replies
    1. (Hereafter, I, the author of this site, will be known as TheAdministrator. All the anonymouses were getting confusing. Changing how the name appears didn't fix past comments, however.)

      I don't think Epic has that kind of position. Judy is very vocal about how private the company is, and that she holds the reins (or that she reigns). Based on my experience, if there is a board, there are no business-people on it. According to Epic's own website: "Epic's leadership team includes clinicians, developers and process experts – people deeply experienced in patient care and healthcare technology." But not people experienced in client-vendor relations, or successful business experts.

      For such a "forward-thinking" company, they like their status quo. Epic conquered the vast majority of the market with their status quo. My impressions (years out of date) are that Judy won't adapt her company quickly. Instead, with her own position on the government boards, she'll steer legislation in such a way that Epic's current development will become required. Epic will therefore have a head start on any certifications or accreditations.

      Delete
  6. I'm a systems admin (desktop, server, networks) for a government org. in Southern California and have an opportunity to get into Epic. What position(s) would you recommend? I've heard of several IT folks at the hospital return from training to work only to request their old job back. I'm somewhat interested but don't want to get myself into something I'm going to regret. Is there some advice and/or links you can provide for someone in my situation?

    Cheers!

    ReplyDelete
  7. Epic environments need systems admins too, but that's a side of Epic I don't typically have to deal with.

    Maybe someone else can provide some assistance?

    ReplyDelete