What motivates the CIO of a large health system? For Steve Hess, it’s “picturing that day when we save someone’s life through the use of informatics.” Of course, it will take — and has already taken — a great deal of blood, sweat, and tears to get to that point, from getting five hospitals and hundreds of clinics onto an integrated EHR system, to creating standardized workflows, to turning data into “actionable clinical decision support.” In this interview, Hess talks about merger that created UCHealth three years ago, why he’s a big believer in going big bang, the “why not Epic?” philosophy that has helped increase buy-in, and how collaboration is more of an art than a science. Hess also talks about the three tiers of analytics, the “real heavy lifting” when it comes to data, and the exciting direction healthcare IT is taking.
- UCHealth’s birth in 2012
- Implementing Epic & Lawson across the system
- A “high-level framework” for project management & governance
- People, process & tools
- “Why not Epic?”
- Customization vs. configuration — “Be collaborative, but get to the decision.”
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
I had a framework, a way to actually manage the project to success, but I also wanted to make sure that I understood the culture and who the influencers were, and make sure I build those relationships with those folks.
I’m a big believer in always looking at people, process and tools. Often the IT systems are just the tools, and we really have to make sure that the people are ready and the processes are ready to actually take advantage of the new tools.
We set up the governance structures to be very collaborative and inclusive of clinicians, leaders, and frontline staff, but we set it up so that we could get to decisions quickly and efficiently.
We don’t avoid configuration; we actually encourage configuration to make sure that it works well for the individual departments. It’s the customization where we’re going very different from the standard system that we really tried to avoid.
About two weeks before go-live, every single decision that you make is second-guessed. ‘I can’t believe we made that decision, that’s not going to work for us,’ so having the decision tracker allows you to go back in there and say, ‘That’s why we made the decision.’
Gamble: Hi Steve, thank you so much for taking some time to speak with us today.
Hess: Sure thing.
Gamble: To give our readers and listeners some information, can you provide an overview of UCHealth — what you have in terms of number of hospitals and maybe a little bit of your history?
Hess: Absolutely. UC Health is actually a fairly new health system that came about in 2012. It was really a consolidation of three fairly large health systems in Colorado. Universal of Colorado Hospital, which is essentially a standalone academic medical center, formed a new system called University of Colorado Health — the short name is UCHealth — with Poudre Valley Health System, which is two hospitals in Northern Colorado, and then Memorial Health System, which includes two hospitals in Colorado Springs. Almost overnight, three systems with about 500 beds apiece came together to create UC Health, and that’s what we are today. We’re five hospitals, about 1,600 beds in total, a little over 15,000 employees, 104,000 admissions, 2.8 million clinical visits, and a net revenue of about 2.8 billion.
Again, it was formed in January 2012, so a little over three and a half years old. We’re a new health system; a very good health system. Three of the hospitals are magnet hospitals and we obtain really good quality scores and good financial success, so a new system but a great foundation to grow upon.
I’m the CIO for University of Colorado Health. I actually came to Colorado about six years ago to be the CIO at University of Colorado Hospital, and then when UC Health was formed, I became the CIO there. I’ve been in healthcare IT for over 24 years now, and it’s really an exciting time to be in healthcare IT. I think the things that we’re doing are pretty awesome from the perspective of not only patient safety, but really patient engagement, outreach, and health information exchange, it’s really an exciting time to be in healthcare IT.
Gamble: Yeah, definitely. Now, when these health systems merged, was it mainly from an economic viewpoint, just being able to get stronger and be able to stand up to all the changes going on in the industry?
Hess: I think that the underlying big reason is that we all felt like while University of Colorado Hospital and Poudre Valley Health System and Memorial were very successful standalone systems, the reality is the changing landscape of healthcare just really demands economies of scale trying to find some ways to lower costs, improve care, and be part of accountability care organizations or value-based purchasing. The reality is, if you’re larger, you have opportunities to do some better things as a system.
Gamble: And you said that’s six years ago that you’ve been in Colorado—you were first with University of Colorado Hospital?
Hess: Exactly. I was the CIO for a fairly large system in the mid-Atlantic region for five years prior to coming out to Colorado.
Gamble: Which one was that?
Hess: That was Christiana Care.
Gamble: Oh, right. I’m in New Jersey, so I’m familiar with it. Now, when you arrived at University of Colorado, was Epic in place at that point or what had to be done at that time?
Hess: It was not. I actually came out to University of Colorado Hospital to implement Epic and also implement Lawson as the ERP solution across the system. We took 26 clinical systems and collapsed them to a single Epic instance. So it was very much a best of breed environment between ED and ambulatory and inpatient and OR and cancer center and so on, and we took all those systems and collapsed them to Epic. I came out there for that challenge. We also did the same thing again on the ERP side with Lawson.
Gamble: So you came in knowing that this is something you were going to tackle. Did you already have it in mind, ‘This is how it should be approached,’ or how did you look at that?
Hess: My history was actually with Cerner. Christiana Care was a Cerner shop, so Epic was fairly new to me. I obviously understood what Epic was and the fact there was the enterprise system and that it would cross many of those patient areas. So I had a high-level concept of how I wanted to set up the project and set the governance structure, but my first couple of months on the job back in 2009 were just meeting with people and listening and hearing what their concerns were with current IT systems and current IT governance. I made sure that we set up the Epic project with guiding principles and also made sure that I had my finger on the pulse of how the organization really worked.
I had a framework, a way to actually manage the project to success, but I also wanted to make sure that I understood the culture and who the influencers were, and make sure I build those relationships with those folks. The reality was that we treated the Epic implementation not as an IT project — I know that’s easier said than done — but we really looked at it as an enterprise project, obviously using IT tools. I’m a big believer in always looking at people, process and tools. Often the IT systems are just the tools, and we really have to make sure that the people are ready and the processes are ready to actually take advantage of the new tools. So really I looked at it from that framework.
Gamble: When you talk about the guiding principles, I imagine that was one of them — what you just talked about, but was there anything else that really served as a guide?
Hess: Yeah. With a project that’s as huge as an enterprise electronic health record, we laid out the principles such as, ‘Why not epic?’ There’s often a thinking of ‘we have this best of breed system in the ED and it works great for us, and the Epic ED Module isn’t going to be quite as good as that. So can we just remain on our own system?’ So we laid out obviously number one as ‘Why not Epic,’ and we’ve always taken that approach of whenever we have a business need or a clinical need, we always ask, ‘Can Epic fulfill that for us?’ Because it’s always going to be better and more integrated than a standalone tool. So that was number one.
Number two was actually focus on the Epic Foundation System. Back then, it was called the model system, and the idea was try to avoid customization for the sake of customization, and try to make sure that we’re doing things in a very standardized way. The reality is, the biggest guiding principle we laid out was to be collaborative but get to the decision. With an enterprise-scale project, it’s easy to just get paralyzed by analyzing the different options and looking at the system and saying, ‘We need to change our process,’ or ‘We need to have these 16 groups weigh in on this’ and so on. So we set up the governance structures to be very collaborative and inclusive of clinicians, leaders, and frontline staff, but we set it up so that we could get to decisions quickly and efficiently.
Because the reality is, you want to go live. If you’re sitting there and your project takes three years, you’re paralyzing the organization because you’re not to make change with your legacy systems when you know a new system’s coming. In essence, for the duration of the implementation, you’re essentially paralyzing the organization. So get to the decision, get to the go-live date, and then you can start optimizing and get into a better place. Those were the foundations of the guiding principles. Use Epic, use the Epic Foundation System, and be collaborative but keep moving. Get to the decision.
Gamble: Did you find that to be a challenge from the customization angle especially when you are in an environment that’s best of breed and people are probably used to being able to do that to a large extent?
Hess: It’s always a challenge. Customization and configuration are two words sometimes used interchangeably, and they do mean different things. When we talk about customization, we’re really talking about doing something extremely different than what the core system is doing, versus configuration where you’re saying, okay, this department is configured for this workflow, but it’s still within the construct of the standard system. So we don’t avoid configuration; we actually encourage configuration to make sure that it works well for the individual departments. It’s the customization where we’re going very different from the standard system — that’s what we really tried to avoid.
The standard Epic implementation has a pretty good approach for validating workflows against the model or foundation system, and you can then document where you actually made decisions that were different than the model or foundation. And that’s helpful because you’re including the front-line staff and the leaders on those decisions, and then you document it so that you have that for posterity.
A lot of organizations probably struggle with that, we actually were pretty successful with it. Not perfect by any stretch, but by being inclusive and actually articulating the value of trying to stay to the model or foundation system, we got pretty good buy-in — again, not perfect by any stretch, but we’re in a good place because of the approaches we took back then.
Gamble: Right. One of the other things that you touched that I’m sure can be tough is striking that balance between being collaborative but not wanting to get lost in having too much input and having to draw that fine line?
Hess: It’s an art, it’s not really science. So what we did was we really set up a very clear decision-making structure that started with the board of directors and the executive team and then the Epic executive steering committee, and then cascaded down to a physician advisory group and a nursing advisory group and an ambulatory advisory group, etc. It’s a very laid-out visual where you can actually see what the decision-making authority was of each group, so that wasn’t a surprise to anybody.
And this is actually really important — we set up a decision tracker where every single decision that had to go to a group in that decision-making structure got documented. We had a workflow where those decisions could be very easily seen any time — what the decision is, when does it need to be made by, who is the decision-making group, and what the status of it is. That’s where we actually had our decision-making documents that had options in them linked to the decision, so at any point, we could actually see what decisions are out there, what needs to be made yet, which ones are the highest priority based upon the data that’s needed. And frankly, about two weeks before go-live, every single decision that you make is second-guessed. ‘I can’t believe we made that decision, that’s not going to work for us,’ so having the decision tracker allows you to go back in there and say, ‘That’s why we made the decision,’ and see how who was involved in the decision and that it’s still the right decision, so let’s move forward. And that actually proved to be extremely successful for us.
The other thing — and again, this is a little bit art — but we wind up the meetings within the decision-making structure such that they were sequential. So if there was a meeting of the physician advisory group, it was always right before the Epic executive committee such that those kinds of decision that had to go through the physician advisory committee up to the Epic executive committee were all being made within one week of each other, so that, again, the final decision, approved decision could be made fairly quickly. It wasn’t months apart between meetings; it was days apart between meetings.