Want to know the secret to being CIO at a large academic organization? Fear. “If I wasn’t a little bit worried about being able to deliver what the institution needs, it would mean I’m not paying attention,” says Joe Bengfort. But that, of course, is just part of an equation that also includes a confident knowledge of IT functions, a willingness to engage in the business side, and an ability to apply lean methodologies to situations like consolidating IT departments. In this interview, he talks about UCSF’s clinical enterprise strategy — and the infrastructure required to support it; his team’s “incremental approach” to analytics; the challenge academic organizations face in securing data without stifling creativity; and how he believes the CIO role will continue to evolve.
- UCSF’s analytics approach — “We’re incrementally moving and maturing the data model.”
- Early adopter of Epic Cogito
- Creating dashboards to ID and solve issues
- Two-tiered governance structure — “You can’t throw big, heavy governance at this.”
- Lean — “It’s a culture first.”
- Consolidating IT departments
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
I’m not really interested in a multiple million-dollar implementation of a standard data model and a standard set of tools that we’re all going to use, because in an environment where there is so much change and so much innovation, you could invest a tremendous amount of money and still be way behind.
We’re solving business problems early and often; instead of asking the business to wait for a year or two while we get all of this technical infrastructure in place, we’re taking more of a scrum method of building up analytic muscle and capability.
You cannot throw a big heavy governance at something like this if you’re just getting started. You really have to get focused on what are you trying to accomplish in those early days and put governance in place that’s very efficient and focused on those problems, and then grow it over time. Otherwise, it becomes almost a roadblock.
You can have a significant impact very, very quickly, and then if you don’t continue to follow up, you can lose those gains quite quickly as well, so we’ve learned that it takes a good degree of follow up and leadership engagement to ensure the incremental improvements that you’ve made don’t dissipate quickly.
That’s one thing that we found with lean — don’t look for 10 or 20 or 30 percent improvements. Look for 75 or 100 percent improvements, and you will find them.
Gamble: You talked about looking toward optimization, and I would imagine that along those lines, you’re talking about getting into things like data mining and being able to enable the users to leverage the data to improve care?
Bengfort: Yes, this is a critical aspect of our strategy. As I mentioned earlier, our approach to this has been a little bit different. The analytics marketplace, especially in healthcare, is fairly young. It’s a very complex data set that we’re dealing with, and so it becomes quite a challenge, but there’s a tremendous amount of innovation going on in the marketplace.
My approach to this has been that we want to work incrementally in this regard. I’m not really interested in a multiple million-dollar implementation of a standard data model and a standard set of tools that we’re all going to use, because in an environment where there is so much change and so much innovation going on, you could invest a tremendous amount of money and still be way behind where the marketplace is. So our approach to this has been a very of business problem-type focus, so instead of buying a third-party data model and implementing it, we’ve essentially leveraged the data warehouse that comes out of the Epic environment, Cogito, and populated that. We were the early ones to get Cogito up and running.
And then from an analytic standpoint, we basically asked the organization to prioritize what business problems are you trying to solve. Let’s just start from one to three or one to five, and we’re going to take the resources we have and we’re going to attack those three to five problems. And as we resolve one issue, we’ll determine, okay to solve this problem, we need these data elements. We need to define these metrics and these transformations of the data, and institutionalize those definitions, and implement. It’s either an analytical work product of some kind — typically, it’s an interactive dashboard of some sort. And then once we have that problem solved, we go to the next one and then we define all the data sets and definitions and transformations for one. By doing it this way, we are incrementally moving and maturing the data model and the analytical tools that we’re applying to those data. And we’re solving business problems early and often; instead of asking the business to wait for a year or two while we get all of this technical infrastructure in place, we’re taking more of I guess what you would call a scrum method of building up analytic muscle and capability.
The other thing I would mention about this is that it’s not just a technology issue. Clinicians, researchers, and educators have to learn how to use data. You can put tools in front of them that solve specific problems and they have to get acclimated to actually using the tool — how to use it, when to use it, and how to make it part of who they are and how they solve problems, versus their more traditional ways of dealing with things. So we’re really seeing the process of evolving the technology. We’re also helping the organization to develop analytical muscle over time.
Gamble: And so with something like the dashboards, would you say you started it to have certain functionalities and then would add certain things or take certain things away and just did it that way to really make sure that you’re putting the right information in front of people when they need it?
Bengfort: Essentially, yes. That’s absolutely actually correct what you just described. To be more specific, to give you some examples, since we wanted the executives — and we always need executive sponsorship for these things because it’s really their problems that we’re trying to solve. Since we engaged them early, the first problem they wanted to solve was, ‘look, we kind of know what’s happening in the hospital from day-to-day, but we really want to understand census. We want to understand throughput, we want to understand cash collected and we want to be able to drill down on an individual department basis on many of these items.’ So we basically created what we call flash dash. It’s a flash report that’s pumped out daily that shows all these dynamics within the hospital.
The second problem they wanted to solve was more specifically around throughput. One of the key drivers for throughput was discharge before noon, and so we created a dashboard that provided insight to all of the various steps required in order to execute, in a safe manner, discharging patients before noon when they met their discharge date. That helps drive throughput, it helps drive down the cost of care, it helps with many things. That was the next very pointed problem to solve. So we built a discharge before noon dashboard that had a lot more detail than what the original flash dash provided.
Then we just continued to move from there. There are blood utilization dashboards. There are dashboards around the various quality metrics from our quality department, which I think we’re up to somewhere in the range of 400 different quality metrics that we have in a near real-time basis. So it’s just solving those kinds of problems, and then once you’ve defined many of these data elements, you suddenly have a basis to create other kinds of value and other kinds of analytical tools. We’re just starting to see the flywheel spin on this.
Gamble: Right. Now how does that work as far as when you are making those tweaks and are doing different things — do you have like a specific committee or how do you get the different input from the various users?
Bengfort: This is a complex question in this environment. Again, we started very much with the clinical enterprise, and we established a governance group — really, we really established two. One was at an executive level with our CFO, our chief medical officer and our COO, to define some of the burning issues from their standpoint.
And then we created more of I guess you would call a tactical or execution-related working group that evolved into a data governance-type structure. Because many of the decisions that we had to make as we were solving these business problems is, ‘Okay, how are we going to define patient days or different metrics?’ We had to get the institution to agree on those things, so we created a very simple two-tiered governance structure very focused on analytics that would define not just prioritizing the business problems we want to solve, but also defining, down into some of the weeds, how are we as an institution going to agree to measure certain things?
This problem gets more complicated as you spread out to more parts of the organization, both within the clinical enterprise, but then when you start expanding into the research organization or the education side of the house, you can’t pile all these people into one room and have them talking about fundamentally different business problems. So we’ve created working groups around education analytics and research analytics, and we’re going to have some subgroups within the clinical enterprise for different specialties to make decisions on those things. And of course we always will run into resource contention because the demand for analytics, no matter what, will completely outstrip the supply that you have to offer. So we do have the higher-level governance group that basically is a mix now of research, education and patient care leaders who can look at the demand that we present to them. We’ll propose a priority and they can adjust things around. We try to make it as easy as possible for people to engage. So that’s general process, if that gets to your question.
Bengfort: But this is another thing. My advice is you cannot throw a big heavy governance at something like this if you’re just getting started. You really have to get focused on what are you trying to accomplish in those early days and put governance in place that’s very efficient and focused on those problems, and then grow it over time. Otherwise, it becomes almost a roadblock versus an enabler if you try to get too big too quickly.
Gamble: Right. When you talk about all these strategies like continued performance improvement and lean, and I would imagine that factors into a lot of the strategy of the way you prioritize things and manage certain projects.
Bengfort: Yeah, that’s right. That strategy is extraordinarily useful, really all the way from the executives all the way down to people in departments making decisions about what business problems they need to solve. We have an incentive program here within the UC system for the medical or the clinical enterprise that also ties to the strategic plan, so if people understand the strategic plan and their monetary incentives are tied to certain initiatives that drive that plan, you can get alignment fairly quickly.
Gamble: Now, as far as the lean initiative, you said that’s something where you’re fairly early on in the process right now?
Bengfort: Yeah, lean is absolutely a culture first, and culture is not something that changes overnight. Of course, it’s a methodology, there are a set of tools, there’s some very specific training, so it’s got the mechanics and the infrastructure behind it in order to impact culture. But it does take time to really have that feed throughout the organization. I think the typical timeframe I’ve heard at least is it’s probably a good five-year journey that we’re two years into.
We have seen a lot of success with lean and we have applied it to very specific patient care settings. We’ve applied it to information technology and the processes that we run in information technology, and we’ve applied it to administrative processes as well. We’ve learned a lot. You can have a significant impact very, very quickly, and then if you don’t continue to follow up, you can lose those gains quite quickly as well, so we’ve learned that it takes a good degree of follow up and leadership engagement to ensure the incremental improvements that you’ve made don’t dissipate quickly.
Gamble: Right, and is it something where when you do see those early wins, you have to really communicate that and kind of motivate people to keep going through the process?
Bengfort: You do. Our method around that has to do with report-outs at the end of Kaizen events and things of that nature. When the team has worked in a room for three or four days, dedicated to finding performance improvements or process improvements, they get the opportunity to present that, and it is a strong expectation that the executives — especially associated with that department — are engaged in the report out and that they continue to sponsor that on an ongoing basis.
Gamble: Right. Can you think of any like example or specific areas where you have noticed some of those early successes with implementing the lean methodologies?
Bengfort: Most of my individual focus has been in the technology world, so let me just give you one of those; that’s probably as good as any. It’s probably in the area of provisioning of systems. As I mentioned before, when I took on the research and education parts of IT, I found myself with two completely separate IT organizations that I needed to meld together in some way, which we did through an organizational consolidation. Those are always painful, but you get to consolidate an organization and you find you have a consolidated leadership team and a completely disparate set of processes that they’re running across the two. And so we really tried to identify where we were doing things differently and to apply the lean method in order to hopefully evolve from two totally separate things into one that takes advantage of the best qualities of both of the prior versions.
We did this in the server provisioning specifically, just to get way down in the weeds here for a moment, and through the process, we had customers who request servers. You’d be surprised they come from all aspects of research and education and from the patient care world. That’s a whole other conversation, but we had customers in the room, we had the people who actually do the provisioning, we had some process-oriented facilitators in the room. And we essentially took the process from being, I’m embarrassed to say, somewhere in the range anywhere from 1.5 to 3 months to implement a physical server, and somewhere in the range of 2 to 3 weeks to actually get even a virtual server implemented, down to really just a number of days. And that’s from the time a request comes in until the time it’s actually provisioned and ready for use.
So we saw easily a couple of hundred percent improvement in the time frames. That’s one thing that we found with lean — don’t look for 10 or 20 or 30 percent improvements. Look for 75 or 100 percent improvements, and you will find them. There’s just a tremendous amount of inefficiency, especially when you go through a consolidation of teams.