Habush Habush and Rottier

Showing posts with label quality assurance. Show all posts
Showing posts with label quality assurance. Show all posts

Friday, July 25, 2014

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.

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.