Habush Habush and Rottier

Friday, June 17, 2011

Epic Scale Priorities

An observation: I guess it started around the time when customers started upgrading to the 2009 version of Epic. Few customers (that I've been aware of) are implementing any enhancements. They want to, and it's on their priority list, but they are just too busy fixing things to work on enhancements. The 2010 version seems to be no different. I remember the 2007 and 2008 versions--there were few persistent problems. Most of the issues seemed to be enhancement related. "We have a doctor who wants to be able to do X. Is that possible?" At the end of my term of service, my customers had just upgraded to '09 and the issues were of the variety: "None of our doctors can send prescriptions. Was that functionality removed? We'd like it back."

Maybe it's just an artifact of later IUs vs early IUs. The first few years I was at Epic, my customers were on late IUs where the bugs had been worked out, and then upgraded to early IUs that were buggy. If that's the case, it's acceptable to a degree. Every new version of software will have some bugs. Testing will catch a lot of them. Testing can't catch everything; it's impractical to test every single esoteric combination of keystrokes/mouseclicks that a user will enter. But, some of the issues cropping up just look like no one tested the workflows at all. A discussion in the Epic Users One Stop Shop group on LinkedIn mentions constant crashes, in all kinds of workflows. That should have been caught earlier. If there were beta testing, it would prevent a lot of these issues.

To prevent these issues, every workflow needs to be tested. With 200+ customers, all of them with different combinations of applications, in different states with different regulations, using different workflows--there's no way Epic could staff that many QAers, and no way the QAers with no healthcare experience could mimic the actions of a user in the real world. The best solution then is to allow bleeding-edge customers the opportunity to be the first customer on a new application/new version for several months, with the promise of increased technical support in the form of more TS and on-site Epic developers. This will allow for faster end user feedback, faster fixes, and "test" scenarios that "mimic" actual, live environments.

During my tenure, Judy Faulkner constantly brought up KLAS ratings regarding needed functionality. "The needed functionality is there! You just need to get our customers to take the enhancements!" It's great to say that, but if the basic functionality is too broken to use, no one is going to want to install new, untested modules.


  1. Hi...Thanks for your blog. I want to become an epic consultant. New to the industry. Background in clinical data management in biotech. I have read many stories about epic non compete and I'm looking for other ways to get the certification without looking to work there. I would appreciate any suggestions you would have for me. Close to 100% of the jobs I see online want someone with experience. Thanks!

    1. Take a look at the comments on this page. What you want to do isn't easy, but I know that some people have done it.

  2. A lot of this has to do with when Epic decided to de-emphasize the Model System, which was one of their worst mistakes. I was staffed to Model shortly after they decided to put IS back on, and we had a LOT of cleaning up to do. I couldn't believe that customers were getting cuts of the Model with that many mistakes in them, and there were literally thousands of QANs that couldn't be addressed by the one/two QA people on Model from my clinical application. I'd like to think that things are getting better in that sense, but it's still tough to get DLGs created for new functionality outside of easy enhancements that IS/TS can do themselves.