Webinar Transcript: How University of Cincinnati Health Increased OR Efficiency through Analytics Tools

In June 2020, University of Cincinnati Health’s Director of Transformation Tyler French and Perioperative Supervisor of OR Scheduling Julie Kirby joined LeanTaaS Implementation Specialist Alyssa Trocchio to share how the health system managed the cultural changes required to improve operating room capacity management and leveraged iQueue for Operating Rooms to reach their desired capacity management goals. While LeanTaaS and our customers have grown and evolved since this webinar was presented, the lessons learned remain very much relevant. 

The full webinar recording and a blog summary are also available. 

MB: Welcome to today’s webinar, How University of Cincinnati Health Increased OR Efficiency Through Analytics Tools: Lessons Learned. In case you’re wondering who this disembodied voice is, I’m Marianne Biskup from LeanTaaS, along with– 

AT: My name’s Alyssa Trocchio, and I’m an Implementation Specialist here at LeanTaaS, as well as, I will have the Cincinnati team go ahead and introduce themselves. 

TF: Hello, all. My name is Tyler French. I serve as the Director of Transformation, Associate Project Management office, the system for UC Health. 

JK: I’m Julie Kirby, and I’m the Perioperative Scheduling Supervisor for UCMC. 

MB: And before we begin today’s webinar, I’m going to give you just a quick orientation on our console, because I know this is an unfamiliar tool for many of you. So bear with me. If you want to submit a question, you can use the Q&A widget. You will notice that that’s at the bottom of your console. And also, all the console windows can be moved and resized to make the experience more pleasurable for you. 

If you’re having any technical problems, the most common solutions are noted in the LeanTaaS webinar tips window. Also, we know that a lot of you are eager to receive a recording of this webinar, post-webinar. You will receive that in your inbox. It will also include the slide deck. Look for that within one day of our webinar. And also, if you want to contact us directly, you’ll note a text number and an email address that appear at the top of your console. Additionally, you can post any comments regarding the webinar. We strongly encourage comments. We’re always striving for ways to improve our webinars. You can do that using these survey widget. And now here’s the team. 

AT: Thanks, Marianne. So Marianne already shared with you the title of the presentation. So I’m going to go ahead and skip to the agenda slide. We’re going to talk to you a little bit about who LeanTaaS, and what iQueue is, as well as the background and existing challenges that we’re facing, UC Health, and in particular, the University of Cincinnati Medical Center, the early success that they’ve seen with iQueue and lessons learned. So the majority of the beginning of the presentation will focus on just what is iQueue, and more importantly, showing you the product and doing a demo. And then we’ll talk a little bit about the success that Cincinnati has seen.

So who is LeanTaaS? We are a company-based out of Silicon Valley. And we really truly have one, large mission, which is to unlock capacity of scarce assets by transforming core business processes. […] 

We work with everybody from large academic institutions to large community institutions, as well independent standing hospitals. The motivating force really driving iQueue for Operating Rooms, or what you’ll see has developed into the product, is that OR time is precious. And not only is it precious, it’s in high demand. In addition to that, there’s a push to do more with less, given reimbursement pressures across the United States. Both this and the fact that demand for time is unpredictable, make challenges in the perioperative space continue to evolve over time. When we say demand for time is unpredictable, we mean specifically volatility, not only in case volume, but case practices. By that I mean, how many cases they do per week versus how many cases they do per month. It’s very hard to predict that, especially when you have a new provider. And so there’s no perfect block allocation method.

So in addition to demand for time being unpredictable, we end up in this vicious cycle. So supply is expensive. Demand is unpredictable. Surgeons don’t always release their time. And then there’s not open time. So we end up in a situation where most institutions are 95% to 100% blocked on their block schedule. They’re having difficulty freeing up that time because there’s not much incentive for surgeons to release time, which limits open time, and then results in surgeons asking for more block time in order to get their cases done. 

What iQueue does is really unlock those scarce resources and allows you to create what’s a little bit more of a liquid marketplace. And these challenges that we see are pretty much bucketed into three big areas: accessibility, accountability, and visibility. We really believe that as we’ve partnered with these institutions and the more that are to come, that we have a joint vision for operating room efficiency. We’re trying to address these three things in a big way. And I’m going to show you how we do that with the product here very soon. So how are we able to not only create accessibility and visibility, but drive accountability in order to unlock those scarce resources? We’ll talk a little bit about how we do that in particular with our customers towards the end of the presentation with the University of Cincinnati Medical Center. 

So iQueue for operating rooms is made up of three modules. I’m going to share what those three modules are and then provide you a quick demo. 

Exchange is really the module that creates a liquid marketplace or creates that open time in a very easy and fluid way. So if you’ve used OpenTable before, it’s very similar to that. You can go on to the web or on your phone, search for additional operating time or what we call open time . And then you can request and release. So the release portion is what creates that open time. And so I’m actually just going to jump into a demo very quickly. I’m going to share my screen with the audience. And I’m going to show you exactly what the product looks like specifically. 

I’ll orient you to what you’re seeing on the screen. So these are our three modules. I first started with Exchange. So also, I do want to tell the audience, if you go ahead and push the red button on your screen. You will be able to see what I’m demoing. So you’ll see on the left hand side, you’ll see Exchange, Analyze, and Collect. I’ll tell you Analyze and Collect are the other two modules. But the Exchange portion, where the OpenTable piece, where you create that liquidity, you are able to not only release and request time, but you’re also, for clinic schedulers or their surgeons, there’s also a task list in a way that the OR schedulers interact with the product. And I’ll show you what that looks like in a moment. 

So for the release portion of the product, I’m going to make up a scenario here. I’m Dr. Archdeacon’s OR scheduler. I want to simply release his time. I can type in his name here. And it’s going to bring up every single day that he has block time over the coming months. His scheduler can very simply go in and release that time, either to open and/or transfer that time to his partner. And that will go ahead and notify OR scheduling that Dr. Archdeacon is going to release his time on Friday, December 28. And then the OR schedulers would go ahead and release that in the EHR. The other nice feature that Exchange offers is that we also send release reminders. 

So iQueue will look at historical booking patterns for Dr. Archdeacon. I know that he’s an orthopedic surgeon. I can say that he seems like he will pick up that he typically books his cases, five weeks in the future. It’s four weeks in a day. And iQueue picks up that he doesn’t have cases scheduled. We will trigger his office with a release reminder, asking them to go ahead and release time. So the release function within Exchange is helping unlock those scarce resources by proactively reminding clinic schedulers that time has not been booked. And we would push them a little bit to go ahead and release it so that other surgeons can request it. I’ll show you what that looks like now. 

So the other functionality within Exchange is the request portion. So this is that OpenTable concept. Again, if I’m Dr. Archdeacon, I can search at any of the potential locations. So UC Health right now has one contracted location with us, and that’s Cincinnati Medical Center. They can pick this location. They can search anytime of the day that they’re looking for and any chunk of time throughout the day. So I’ll just say, I want four hours, and I can search either morning or the afternoon, and then I go ahead and click Search. And that’s going to bring up a nice calendar view of what time is available versus what time is not available. 

So not only can he go ahead and request, okay, I’d like to pick the day after Christmas. I can pick any four-hour chunk of time that I’m looking for. I can write specific notes, like I need an OR or a CR here. And then I would go ahead and submit that request to the OR scheduling office. And then say that I want time on a day that’s not available. So on December 28, I can go ahead and set an availability alert on that day. It will actually show as yellow. I’m just in the OR scheduling view. They can go ahead and set an availability alert. It’s basically putting themselves on a wish list and saying that I would like time on that day. And then as soon as somebody releases time on December 28, it’s going to go ahead and send out an email. iQueue will send an email to everybody who has set an alert on that day, prompting them to go ahead and request time if they’re still interested in that time that’s available. 

So instead of booking sheets or cases and sitting in the depot, waiting for time to auto-release you’re able to, again, proactively set an alert that helps the clinic schedulers remember as soon as time is released that they’re looking for time on that day. 

There are a couple other functionalities within the Exchange product that are specific to the OR schedulers. There’ll be a task list here that they can very easily work from, as well as a history of every transaction that’s ever happened. So I know I used to be a business manager of operations at an institution in Ohio. And the scheduling office would keep track of all the released time in an Excel sheet if they got any released time. 

Now, they’re able to. And I know Julie can probably speak to this a little bit later in the success that they’ve seen with the task list there, which is they’re able to keep track of all the releases here. So when I share with you the Analyze and the Collect portion, where we’re keeping track of the analytics, this makes the kind of back and forth — did I really release my time? Did I not release my time? It’s much more transparent because it’s all in one place. So we’ll keep track of every transaction that takes place in iQueue here. 

I’ll flip back to the presentation now, to Analyze. I’ll tell you a little bit about what Analyze is specifically. Then I’ll go back to the product and show you a demo. 

Analyze is the platform where we’re creating deep visibility into operating metrics in real time. So we’re showing you first, case on-time starts, case volume, block utilization in a different level of detail than what your EHR can provide for you today. We’re also proactively sending out performance alerts, not only to administrators, as well as anybody who’s on the perioperative administrative team. We’re also sending out text messages or emails to surgeons with weekly performance. And I’ll show you what that looks like. I’m going to go ahead and flip back into the demo again. 

Please feel free to ask questions if you have them as we go. We can answer them throughout the presentation, as well as towards the end.  

So when you log into iQueue, again, I’ll show you the dashboard up front. Every operating metric has its own specific tile, as well as a different level of detail that goes beneath that. So I’ll pick volume here. You can click View Detail, and then see a month over month trend of the specific location volume. So again, UCMC or the Medical Center here, and not only can you see it month over month, you can also see how it trends year over year. You can pick a specific group of surgeons or an individual surgeon if you’re interested. So I can very simply unselect all and see. I’d like to better understand surgical oncology volume over the last four years, and it will show you what that looks like. Not only that, you can also pick a leaderboard. And I will Select All and go to the leaderboard, and then I can see who my high volume surgeons are, and how they’re performing over any specific range. 

So if I want to see how they did the past quarter or past month, all of that is available to you here. 

In addition, you can also compare across service lines and see who your high volume service lines are, and who your low volume service lines are. So we’re comparing performance across it. For example, if you’re a physician that oversees the Department of Surgery, you can compare your divisions within the department. Or if you’re an executive, you can see how various service lines are performing again in any specified time period that you’re interested in looking at. You can also see patient class, as well as case class. So you can slice and dice the data in any way that you’re interested. Not only can you see volume — I’ll pick on one other tile to share with the audience before we get into Cincinnati specifically —  you can also see very unique visualizers that most likely you cannot pull out of your EHR today, or I know for the most part you cannot. So we’ll pull up a block over again, I’ll pick on Dr. Archdeacon. 

I can see his performance over the past quarter. I can see what day he has blocks allocated to him. So specifically, he works on Tuesdays. The gray portion here at the top with the slanted lines are the time that he’s released. You can see he’s doing a really good job of releasing his time. And then you can see the gray block time he’s allocated here as well, as well as the green usage, and again, this is collating this all over his Tuesdays and very quickly showing you a snapshot of how he’s performing in his Tuesday block time. You can then click the Show Detail. And this will allow you to see his performance every day for the past quarter —  again, what time he has released, the time he’s worked in, and where he has worked outside of his block.

Analyze is a plethora of information. So not only do you have a tile on each specific metric, there is also a tile for the surgeon scorecard. So every surgeon has a unique scorecard. I’ll pick on somebody besides Dr. Archdeacon. You can click Detail, and it’s going to bring up a snapshot of how the surgeon’s doing from volume to utilization, to operating metrics. A lot of our customers are using this specifically to have their reviews with surgeons, or sit down and talk about performance, or very quickly bring up how they’re performing within their block if they’re asking for more block time. So there’s a whole plethora of information that is located specifically within Analyze. I’ll let Julie and Tyler here in a few minutes speak to how they’re using it at Cincinnati. 

Back at the presentation, I’ll share with you what Collect is. And then we’ll go ahead and have Tyler and Julie orient you to a little bit of UCMC and share their background. 

Collect is the last module. And Collect really focuses on enforcing accountability. So if you remember at the beginning of the presentation, I mentioned we’re attacking these three specific challenges. 

Exchanges is addressing that accessibility. Analyze is addressing the visibility portion. And Collect is really what addresses accountability. So what is Collect? And what is collectable time for that matter? 

So Collect is the portion of the product that identifies true portions of time that can be repurposed. And it does that without actually impacting existing case volume. And so how does it do that? I’ll go ahead. And the definition of what collectable time is it’s made up of three things: large portions of unused time that you consider usable within your facility, and that’s configurable. So if you’re an institution that runs eight neuro-operating rooms, really four, five hours will be considered collectable, because neurosurgery just takes longer than if you’re doing a significant amount of outpatient procedure. That’s going to be what you would consider a portion of unused time will be smaller than that of somebody that’s running five or six, seven neuro hours. So it’s portions of unused time, complete abandoned time– so time that was never released, and hit an auto-release deadline, and then releases beyond a certain threshold. 

So for example, the institution I came from has set in their policy that it’s OK to release 20% of their time. But if they’re releasing 30, 40, 50 hours you can look really great in a block utilization metric. But do you really need that much time? And so Collect is addressing those three things for you. And I’ll show you what this looks like in a visual. So I’m going to orient you to what the visual looks like on the screen. The royal blue colors are used times. The empty white chunks on the screen are unused time. And then the bars with slashes in them are released time. And then anything with the star in it is what we’re considering Collectable. 

So what we’re saying here is that on January 3rd, the case started late, which is not great from a patient satisfaction standpoint or from an OR efficiency standpoint. But really, you couldn’t have put a case in this white chunk of time here. Same thing on February 1st. There are gaps in the day, which is not great from an efficiency standpoint. But you can’t collect that time and put another case in there. Nor can you collect all those small chunks of time and say that you can put cases in them collectively. So what we’re saying is collect these big chunks of time that were left on the table or that were not released. Again, you can see on March 15th that this day was just not released. It hit a three-day auto release deadline. If you have enough of those, so if you’re running a big or small institution, and surgeons are consistently not releasing their time, that’s how you end up in a vicious cycle where other surgeons are not able to access that time. Yet you’re just coming to say, why are we closing one or two or three ORs every day? And it’s because there is not necessarily enough add-on or i-patient volume to backfill all the time that didn’t get released far enough in advance to be filled by more elective type volume. 

Let me jump into the product again and show you what the Collectable Table looks like. And then I will turn it over to Tyler and Julie to explain a little bit about UC Health and share with you the experience. 

So again, when you jump into the application, you will see the collectable time portion of the product over on the left hand side. You just click Collectable Time. It will bring you into the Collectable Table. The first thing you do when you get into the table is just define those metrics that I talked a little bit about earlier. So you would go ahead and pick that. Again, I’m going to make things up. We’ll say it’s okay to release up to 50% of your time. We’re going to consider three hours as usable. And then we’re going to go ahead and save that. There are a number of different things that are in the Collectable Table. So you’ll see the block owner, the day of week that the blocks on. If you have multiple locations, it will pop up here. You’ll also see the Collectable Percentage, as well as the allocated number of blocks, and then what we’re considering Collectable Number or Collectable Blocks. So I’m going to go ahead and filter by the Collectable Blocks. You’ll see Trauma pops up here to the top. I’m going to go ahead and remove Trauma, as well as I will remove Hand in this specific scenario. 

So what this table is doing is really showing you where you have the biggest opportunity. And again, keep in mind that it is a conservative number. And that it’s only capturing those big chunks of time that are left on the table. And so I’ll just take on a group specifically. So if I picked ophthalmology on Fridays, you can see that eight of their 16 blocks are considered collectable. So what does that mean? 

Well, what the product will allow you to do is click those three dots. And it’s going to give you a breakdown of all the time that ophthalmology has allocated to them on this specific Friday. So it’s going to show you up at the top here in gray their allocated minutes. It’s going to show you in blue their used time. And then it’s going to show you in red what we’re considering their collectable time. 

When you click the drop-down arrow for the total allocated time, it’s going to show you that nice visualizer view again, where it shows specifically the block that’s allocated to them, their time that’s been used, as well as outside time that they may have. So again here, you can see time that may not have been released or specifically was left on the table. 

So we’ll show you all of that in the allocated time. We’ll show you their usage. So how much of the time do they use in their block? What did they release above that 50% threshold? And then what was less than three hours left on the table? So we’re breaking down the used time for you, as well as breaking down the collectable time.

So really, here, it’s kind of the big bang for the buck. So you can see that of the 17,000 minutes that they left on the table, or that we’re considering collectable, how much of it was just entirely unused? How much of it was released above the 50% of block allocation? And then how much of it were they leaving more than three hour chunks on the table? And we’re breaking that down specifically for you. Again, so you can see every day that they just didn’t release. And again, a lot of this for Cincinnati was pre-iQueue. And so just what time they didn’t release or just or left on the table specifically. 

What this allows you to do for collectable time, in particular, I know the way the institution I came from is using it is that their block committee is now using collectable time. So quarterly, they’ll go through and review the Collectable Table. They’ll see you specifically who pops to the top of the list. So instead of going through 10, 20 pages of block utilization reports, three months in the rear, they’re able to see performance up to the prior week. And so they’ll go through everybody who has collectable time. They’ll be able to sit down and have a conversation with them in openness in real time, and just ask what’s going on. Again, it’s a management tool. It’s not saying that you have to do this. But we’re just showing you the opportunity. And some of them, you can choose to not do anything with. And others, you can say, okay, we know this has been an issue for a long time.  But now, we have the data to support that. 

So with that, I’m going to go ahead and stop sharing my screen. And I’m going to turn it over to Tyler and Julie to just tell you a little bit about UC Health and, specifically, the University of Cincinnati Medical Center, the background and existing challenges they were facing, why they chose to pursue iQueue, and talk a little bit about the experiences that they’ve seen. So Tyler and Julie, take it away. 

TF: Thanks, Alyssa. I just want to give a high-level overview of the system and kind of talk a little about the scope for this particular project. So UC Health is a health system that has a community hospital, as well as a level one academic medical center. So our scope, in particular, we’re looking at UCMC, UC Medical Center in this level one trauma center. They have a total of 31 operating rooms. We have 25 functional, there are actually 26 functional. They’re actually in the main hospital. And then we have an ambulatory surgery center that has five ORs. 

Just to give a little bit more background on the kind of impetus for this, we actually specifically focused on UCMC because we had what we call a traction team developed. And a traction team is really just a fancy word for a project team. That’s a priority for the system. So our system was looking at different things across the system. And we’re kind of dictating what is high priority. And one of those being OR efficiency. So what they had done, I would say maybe about 2 and 1/2 years ago was to convene this traction team, which had a few different stakeholders from all the different groups: surgeons, anaesthesia, UCMC OR staff. And then I had support in the capacity of this being a project manager. But that’s really where we start in the beginning. 

I’ll kind of weigh in here and I’ll let Julie add a little bit at the end, when this team came together, again, they were tasked specifically with improving efficiency in the UCMC ORs. They had kind of a very large project plan. But here’s some of the key things that they were looking for, and some of the things that we were struggling with. 

The first thing was that we had to dive into the information, like all of us when we figure out what the problem, why it is a problem, how do we solve it. We need information and data. And we, in particular, had gotten to the point where we had information. We knew there were problems. And we knew somewhat to, maybe a mid-level, what the problems were. But the problem is we couldn’t get to the actionable level. Meaning, for example with block time, we had a report that gave us information on block time. We worked very hard on it actually. But we realized very quickly was that as Alyssa alluded to, OR time is precious. Any time you discuss reallocating time, that’s a very heated conversation or could become heated. So we want to make sure we have very clean cut data that cannot be argued and people trust. And most important, we can get down to a level to where we can actually start making decisions. 

So that was one of driving with this. And really, behind that was really to improve overall OR utilization. That’s both the utilization of our physical resources and our staff resources, anaesthesia and OR in tech teams. Julie, I’ll pass off to you for the request and release process. 

JK: We basically were not getting any releases. We were obviously getting a lot of our class. We have a lot of add-ons every single day that probably could have been allocated to a room. However, when our positions we’re not releasing time, we were unable to schedule those because it has been alluded to earlier. We have precious block time. And no one wanted to give it up. So with iQueue, we have a streamlined where it’s in one area the schedulers can go in from offices. And there’s a little more faith. They can see that, hey, they do have open time. I can select that. Or there is a request, and they can put that in. We’re still in the thick of things working through it all. But it is streamlining and helping us get to a better system where it’s all trackable. And it’s all out there for everyone to see. It’s not just my schedulers holding onto paperwork and having to show that, hey, we did get this release now. Any physician, surgeon, administrator, myself can go in and see, oh, it’s there, okay. 

TF: So at the end of the day, with a decrease in unused time, really, what we’re just saying, again, is improving our overall resources but from a physical standpoint and a staff standpoint. Going back a little bit how we were measuring that, I think, for the most part, we are measuring it as any OR measures it. What we wanted to kind of hone in on though is really what our true outcome metrics were. So we measured. And we still measure and had made projects focused on lots of different pieces of the puzzle. So turnover time, first case on time start, case cancellations. But at the end of the day, if I were to say, kind of our vague or broad ultimate goal, it’s really three-fold based on the perspective. 

Number one, and first and foremost for our surgical patients, we want to improve their access, right? There’s folks who need our care. They need surgery. They need it quickly. And we want to make sure that we have the capacity and the processes to do so. Secondly, from the staff, both surgeons and RN techs, we want to make sure that they were working when they were expected to work. Meaning, they weren’t running over by too much. They weren’t coming in overtime or on call too much. We want to make sure all of our processes were as efficient as possible, so that they were really matching their demand to our capacity appropriately. And then third, which you see here on this slide was, really, at the end of day from the hospital perspective, we want to utilize that physical resource. 

So we had set in our operating plan for the year to have a goal to utilize our ORs at 80%. And when I say 80%, I mean physical room utilization at 80%. Then in particular, maybe you can interpret this as somewhat a process matter to that, we also wanted to really look at block utilization and say, are our surgeons and our departments being good stewards of the time we’re giving them? So we also want to set a 75% goal for the department’s block utilization. But really, that’s just one aspect of how we are trying to measure this and one of the key drivers for how we would prompted the discussions that iQueue. 

So how the conversation with iQueue in particular was prompted was that we were kind of in the middle of this traction team. We had a few projects under way. And that baseline data, but we were, again, hitting that kind of hurdle or that wall where we didn’t have actionable information. We are trying our best. But we were coming back with either, number one, they didn’t trust the information, which is just a historical occurrence. Or number two, they trusted it, but we weren’t giving them clear enough direction on what we need to do, or what they needed to do as a department to reallocate their time. So one of our senior leaders had actually worked in another health care system, and had been involved to a certain degree with iQueue, and had known about it. And they had known about the value that it was providing in the early stages. 

So when he was involved with this team, and he was actually one of the executive sponsors of this team, he had said that, hey, this is something we might well look into. And what we are careful to do is what we first is an assessment of our, quote unquote, collectable time. What I mean by that, just saying, obviously, if we’re 95% utilization, this is not a problem. But we knew we were not. But what we did with the senior leaders, we reached out. And we kind of gave them our problem statements and what we had found thus far. And we tried to match that with really what the functionality that iQueue is offering and what Alyssa just went through with you. 

AT: Thanks, Tyler. I did just want to cause for a quick second before I go into the implementation process. We had an interesting question from the audience that I think you may be able to speak to and will provide a good background as we head into the rest of the presentation. So the question was that the goal is for room utilization and block utilization, specifically as 80% and 75%. And they asked what the baseline is. And so I know for most departments, the baseline for block utilization hovers around 60%. Correct me if I’m wrong. 

TF: Correct.

AT: Yes. So the baseline is around 60%. And then do you want to speak specifically to room utilization and just some of the unique ways that the challenges that we’ll talk about as we work through this? 

TF: Yeah. Actually, it’s a good question because it’s something that we would think would be somewhat direct. But actually it was a big hurdle that we had to get over. And that’s really the operational definition of what utilization meant. Because in the very beginning, if you were to ask anybody what is utilization, what’s our baseline, and you get very different answers because you had very different definitions. And what I mean by that, and I don’t want to obviously get too far in the weeds, but our specific struggle was that we had to make sure we’re clarifying what is capacity. So when we were looking at it, we would ask one person. And they would say, oh, we’re at 90% utilization. And what they were thinking of is they were excluding certain rooms that were not staffed. 

So what we staff to, just to give you additional details, we actually support 23 of those rooms currently. And then there’s a few other rooms that we don’t actually staff on a daily basis, meaning, if we use them, we’re pulling staff from one room to another. So if you were to go around and ask different team members or folks in the OR, you get very different answers. So we had an important conversation throughout this whole time and build with iQueue to say, all right, what is utilization telling us? And at a very high level, what we agreed is that we want to look at all of physical capacity. And if you look at all of physical capacity, I mean, all of our rooms, regardless if they’re staffed or not, we’re in the 60s. Now, if you were to take out a few of those rooms we don’t staff, then we bump up a bit to the 70s. Obviously, we’re not putting cases in there. We don’t have staff to support it. 

So that’s actually a really good call out because it was two different ways we measure it. And just as of this last month, the team agreed that we need to look at both because both have value. And that’s something iQueue is providing as we speak as a breakout of fiscal utilization and staff room. So long story short, our baseline was around 60 when you look at overall physical utilization. 

AT: Thanks, Tyler. I think that’s good background to add, especially as we go into the implementation process and early successes. One of the things that we do as a company when we come in if the institution is interested, obviously, we go through the implementation process. So when we first contract with the customer, we go through roughly two to eight weeks of data initiation. And so what that means is assuring that we’re getting clean data from the EHR. And our data teams will pair with the data teams at the institution and assure we’ll go back and forth that we’re pulling out everything that we need to make the product function. And that can vary depending on who the resource is, what the EHR is. But that roughly takes anywhere from two to eight weeks. 

We then go into what we call discovery. So it’s usually a two day offsite visit where we’ll come and meet with folks, like Tyler and Julie, the administrative team, various surgeons, any key stakeholder that the organization considers important for us to reach out to and understand their processes. So for example, we’re partnering with one of the large academic institutions in the south. And we’ve spent quite a bit of time understanding, not how did the OR scheduling offices work because they have multiple locations, but also how do the staff assistants schedule for the surgeons, how did the surgeons schedule? So we really truly like to understand the operational workflows and how iQueue can marry with those. iQueue is very configurable and can work for any specific institution. And so we take a lot of time to better understand that. 

We also align on your metric definition so that everything we show and Analyze is pairing with what you’re used to seeing. We compare block schedules, past and future, and just make sure all of the data is flowing from EHR into iQueue. We then go into a phase called staging. And part of this was exactly what Tyler just discussed, where we spend a lot of time with the leadership team talking about what are their goals for iQueue, and how do they want to improve that, and what’s their baseline. Some folks go through that before they contract with us. We just spent quite a good amount of time doing this with Cincinnati through the implementation process. 

So the staging portion takes anywhere from about four to six weeks. And so within that, we identify process change management, we’ll onboard users, wdeploy an iQueue playground if necessary. So we really partner with you to figure out what is it going to make the launch successful. And then we’ll come onsite for one to two days to go through the launch process. And so specifically, when we worked with Tyler and the traction team that he mentioned, there were a host of initial opportunities that were identified that iQueue picked up on and the traction team already knew. 

And so we partner together to say, what are these big buckets of opportunity that not only will help Cincinnati optimize their operational workflows but also enhance the success of iQueue? And so those came through in three big areas. So it was the ability to create additional capacity, which Exchange does for you. However, one of the things that Tyler and Julie can speak to this specifically, one of the things that we identified was that Cincinnati was an all group block. And this can absolutely work for you. But in order to drive accountability and create accountability down to the surgeon level where appropriate, we encourage switching to individual time. As long as there’s what we call a gentlemen’s agreement or take for example, if urology is in a group block, but they have a pretty elective practice. 

Internally, the OR scheduling office, as well as the clinic scheduling, the clinic offices, know Dr. Trocchio works on Monday. Dr. Tyler works on Tuesday. We simply just suggest assigning that to the individual level to create the accountability, A, with those release reminders and, B, just interacting with the product. We pointed that out as an opportunity. Cincinnati was more than willing to do that, so they made that change. So on the next couple slides, Tyler and Julie will talk through some of the changes that they work through. So not only did we identify the ability to create additional capacity, we identified with them the need to match the number of allocated blocks to the number of physical rooms. 

So if we go back to the situation Tyler outlined, not only did they have 26 physical rooms, they had 25 blocked rooms. But we’re only staffing 23. And so how did they start to pare that back using Collect, they’ll talk a little bit about closer to the end of the presentation, and then driving positive change using detailed analytics. We identified these opportunities, as I mentioned, as we went through the staging process. Tyler will speak to internally the project plan they put together and the milestones they wanted to accomplish, given the baseline opportunities we set out to achieve. So not only achieving obviously block utilization and room utilization as somewhat lagging metrics, but also creating the accessibility, driving the accountability. Tyler will speak to kind of what the change management looks like for them. 

TF: Sure. So what you see in front of you is a high level implementation timeline. One thing I want to point out, though, is Alyssa talked a little bit about the big data phase and the data vetting phase. And that actually isn’t represented on here but was extremely crucial. So although I actually started the timeline in June, we had spent, and Alyssa can fill in maybe more of the details, a few months prior to that really diving into the vetting of that data. And it continues through this. It wasn’t a single process. But that was an important point out, because those few months were really just a very small team from iQueue. 

And on our group, getting your eyes on all the different metrics, all the things that we currently use or had been using, and comparing that with the data that was being shown, that is now so important. Again, we had a long history of all kinds of reports being distributed in all different ways, right? And I’m sure many of you have experienced that too. So what we want to do is really create a very good baseline of, hey, this is what we’ve done in the past. This is what this new tool and functionality will show you. And this is why it may be different or may not. So that was really important. But in June, specifically, is when we had our, quote unquote, go live. And really, that first, I think a good chunk of the summer was dedicated to education and training. 

So the very first kickoff we had was in June, and there’s two events that we had. The first was we had every clinic scheduler and the OR schedulers come with Julie’s team come into a single room and really just show them specifically the exchange, the request, and release process. The number one, just show them the value in it, get their input on it. And two, get to specific training on how to use it. So that was actually a really good turnout with that. I think that’s a positive kickoff. There was lots of follow up, and videos, or conferences after that for them to get additional information. I would say probably a week or so after that, we had, really our traction team, we wanted them to be kind of the leading edge or the early adopters for this. 

We gave all the access to those senior leaders and trained them on all the modules, but specifically on Analyze because they were the ones that looked at this information. They knew they needed to dig into it to get actionable steps. So they really dug into that, probably a good chunk of June and July. And then probably one of most important ones we did was then we moved in the traction team to what we call EDBA chair meetings. What I mean by that is that’s our Executive Director of Business Administration. So each department has that head of business who’s kind of the partner with the chair. And they’re the ones that are really responsible and accountable for block time and capacity allocation. So they’re really the ones that we need to work with most closely on this. And they have to feel most comfortable with this. So in July we worked with them and we established a group presentation. 

We, as a group, Julie and Alyssa and I, and a few others sat down, one on one or two on two, whatever it may be and talk through two major things. Number one, high level, what is iQueue and functionality, to reiterate that. But two, we did our first deep dive into the data and said, what is it showing you? And what is it telling you? And one of the things in terms of change management I think we tried to do was that, we didn’t want to go in there and say, here’s your data. We tried to go into each of these department meetings and say, break this, please. What we mean by that is go in here, and tell us what’s not working. Because in the past, well, what happened is that first stage of acceptance, right, is the data right?  

We came in there on a high horse and said, this is the data and shoved it down people’s throats the change management. That would not have worked. They would have merely found ways to tear it apart, right? And rightfully so because this is their information. So in these EDBA chair meetings, we start off very humbly saying, is this correct? And then really, there are two issues with it. There are two potential scenarios. One, it was correct. And we just need a little education on, really, this is calculation. This is actually how it works. And maybe anecdotally, it feels differently. But this is what the data supports. Or two, maybe there were corrections or some sort of changes. And so we worked with the iQueue team and ourselves in those scenarios just to, if there were little, quote unquote, bugs to fix, we would do so. But that was really the foundation in the summer. Moving through late summer into fall, we then realized that we can have the tool all day long. 

iQueue has such great risk resources. But at the end of the day, we also have to carry our own weight. We have to establish clear processes and make some hard decisions to support the tool. If we just have a tool, it won’t be enough. So what you see here is when we went through that implantation process, we realized that iQueue in itself is not a silver bullet, right? We had to go through this entire process of saying, hey, we understand that this has been done for 10, 15 years. But we’re going to try to take a new look at this, and we’re going to do two things. We’re going to use this data to prompt conversation. And we’re going to develop trust in it. And most importantly, as we went through cycles, one of the main challenges we had was that lots of new people were getting into it. 

So sometime in the fall, we actually moved to all surgeons getting access, which was wonderful, which is great. But then we had realized, hey, we have a whole new group of people. We have new questions and new thoughts on it. So we continue to expand that. And we still continue to expand that. 

JK: Yeah. So one of the best things that brought us here to the implementation process is a lot of the previous administration, backdoor agreements were made. Now, there is a team of people looking at this data. And it’s really transparent. Everything is transparent. Any surgeon can go in, look at their department, and see how they are doing. It helped the schedulers with us going, okay, you really don’t have time. It became a more open conversation that we weren’t hiding time or protecting it. It’s open. They can see it. There’s understanding. The Business Directors are now aware of some of the things that were going on. Not bad things, but they just had no idea that these things were actually happening because it wasn’t a conversation that was had with everybody. And with the implementation, we were able to have this conversation. 

It’s much cleaner. The schedulers understand. My schedulers understand. The business directors understand. The physicians understand. And we’re streamlining all of that and making, again, more transparent and open conversations with everybody. 

AT: Thanks for sharing that, Tyler and Julie. So now onto the fun stuff, we have just about 10 minutes left. I want to talk through the success that Cincinnati is seeing with all three modules specifically, as well as keep addressing some of the questions that you have. So please feel free to continue to send questions through if you have them. And we will start answering them as soon as we get through the last couple of slides. 

So for change specifically, the University of Cincinnati Medical Center has seen 43,000 minutes that have been requested, as well as 98,000 minutes that have been released. I think their transaction total is somewhere between four and five hundred. And so again, what you can see here is that we are unlocking the capacity, surgeons are releasing time, their offices, the residents, whoever on behalf of the surgeon is releasing time. When they’re going on vacation, when they have clinic. They’re transferring time to their partners. And then others are able to go in and request that additional time that has been created. We’ve onboarded a significant amount of schedulers and surgeons. And what we’re starting to see with success for Analyze is that, now that the surgeons are onboarding, they’re getting their text messages or emails. They’re starting to ask questions. And they’re wanting to understand why is their utilization this, why is their utilization that? And this is a good thing. It’s creating that culture of transparency that Tyler mentioned previously. And it’s also helping UCMC drive the change that they’re looking to drive because everybody’s more aware of where their metrics are, instead of having a conversation three months in the rear. And then the other thing that I would add is that they’re using Collect specifically to what we talked a little bit about earlier. And get them from the 25 allocated blocks to 23 rooms. And then some of the things they’re looking to do in the future and have already started doing is creating their block review process around, not block utilization but collectable time as well. 

And starting to make that transition, and so they’ve been able to, specifically on certain days of the week, pare back that 25 allocated blocks to a more reasonable number. And they’ll continue to do that over time, maybe even be amenable to create open time on certain days. And so they’ve seen tremendous success with all three modules. And I’ll let Tyler and Julie, not only be to the success that they’ve seen or felt anecdotally, but as well as talk a little bit about their future goals and lessons learned throughout the process so far. 

JK: One of the biggest things we are learning is we are getting rid of the paper maintenance. In the past, I was using a calendar, basically, to keep track of when doctors release or emais, and that type of thing. And there were several types of ways we could get these emails. It could be emails, a phone call, whichever way. But now we’re doing everything through iQueue. We’re looking to open more time. We’re able to look at a lead time analysis that gives us saying, hey, you need a little bit longer of a block. Or you need less of a block. You need to release earlier. You don’t need to release. And it’s all out there, and open, and able to have the conversation, and show the surgeons exactly what’s going on with the tool, iQueue. 

TF: And just to piggyback on the release time piece, what we’re doing specifically with the release time and what that I could help with is that we know that in January, we’re going to kick off our block review process. So you see that the bottom bullet there, the block governance process. But before that, we want to say, all right, before we actually permanently reallocate time, there are just places where we can free up capacity in the OR by improving the release time. So beyond just requesting release, extending auto-release times, based on that scheduling history. 

So this lead time analysis allowed us to look and say, all right, so if doctor A or block A, on average, 80% of their kids are scheduled a week out, and that’s appropriate. Then maybe we can release that a little bit earlier than just simply a few business days and free that up earlier or for someone else who may need it. So that’s a big one, that kind of initial step we had. We’re in the process of that, prior to the block governance. So we had the block governance, the release lead time analysis, and then also the expansion of a certain adoption. So we’re at the top of the curve for certain adoption, meaning, we’ve kind of expanded it widely to all surgeons. 

But we have very much work to do in terms of educating them. A good portion of them probably have not dove into it directly. And we’re starting to get questions slowly but surely. But we’ll continue over the next few months to kind of propagate what iQueue is, and why you’re getting these emails, and what the data is showing. But those are some next steps that we’re looking at. 

AT: Tyler, specifically to that point, for the surgeons on the traction team and the executive group, there was a question about how big of a lift was it to get surgeons engaged. And I know, as you just spoke to kind of the large masses, we’re still working through that. But maybe speak to the engagement of the surgeons and even the executives that are on that group, and how they’ve kind of taken the lead on understanding what the data is, and the charge by the medical director to truly understand that. I think if you could speak to that a little bit, that may be helpful. 

TF: Yeah. Well, two things. I think, number one, I will say that the traction team, it existed as a group for a number of months or maybe even up to a year or so, prior to iQueue coming on board. So a lot of brainstorming occurred prior to that. It doesn’t mean there was complete agreement, but they had a pretty good framework that they all agreed upon about what is efficiency, what is block time, what is all that in regards to capacity allocation. But to your point,. Alyssa, when I came on, I think one of the main things that we tried to do for the traction team, and the senior leaders on there, and the surgeons was that making sure they’re ambassadors for what we’re trying to do. 

And specifically, this may sound a little counterintuitive, but we tried to point out the folks on the traction team that maybe were the most uncertain and the most leery of the data, and that were the ones that I think felt like they had the most to lose with this new process. And we actually tried to flip the table and say, you guys are going to be the closest to us. And you, guys, are going to be the ones that help drive the implementation of this because that way, we automatically get-, not automatically, but we work through a lot of buy in. In fact, they own it. And if they’re the closest to it, they’re going to trust it the most, and it’ll kind of run downhill from there. 

So I think there was a little bit of upfront work. That’s a traction team already. But once we came into the point where we could start using iQueue, we picked specifically and acutely a few key leaders, both surgeon and senior leader, that may have been the most uncertain about the product to kind of help us walk through the implementation. 

And then the last point in terms of lessons learned, these are just a few things that I may have already pointed out, or Julie has, too. But just to emphasize them, one of the things we learned was having the right people at the table. And that, in itself, is an iterative process because you’re never going to get every single person on the table at the right point, at the right time. 

So all those months we’ve had from June until now has been really both being proactive and finding people who want to be involved and educating folks. But also as folks come in and say, hey, what is this? I didn’t hear about this. Trying to educate everyone that wants to be a part of the team. And maintaining that balance is difficult. But it’s really important. Another important point with that is that we did have a little bit, I don’t want to say hiccup, but in the implementation that we were at a time where we had a large influx of new leaders, all new leaders. Julie corrected me. All new leaders at that time, right. So you can imagine, usually when that happens, a lot of great feedback comes. 

But also, there’s a completely new frame of reference for how things are looked at. So we had a little bit more extended discussions because when all those new leaders came in, we had to realize, all right. They may see things totally differently. They may have measured things differently in their system. So how do we both combine what they’ve seen previously that they want to see because they are our senior leaders? And then also kind of acquaint them to iQueue and what it really is. And I think we’re deep into that process. We have a lot of work to do. But I think we’re out the other side. At least, where we’re looking back and a lot of those are those new senior leaders who are bought in. 

I was just going to say the last part about garbage in, garbage out, we were really careful, again, to be humble and say, number one, is this data showing correctly. And that, we’ve gotten through a lot of that. But then also the release time — so great example of this, right? A doc, just a few weeks ago, came in and said, hey, this is not what I utilized the OR for. I utilize a lot more of the OR. And you’re showing low utilization. And what we had explained is that, hey, an iQueue is a system, right? It’s a process. And you have to release your time or transfer your time. Otherwise, it won’t really be counted or accounted for in the system. 

So it was not about the garbage in, in a sense that the data is wrong. But just that there’s processes that need to be built in the front end, about how you release and how you transfer to make sure we had good actual information that comes out the other side of the iQueue system. 

JK: And for us, I think this thing was the policy and procedure tool that we implemented with the traction team in starting that there is senior leadership behind it and now, it’s a hardcore policy that we are following. And like Tyler said, getting the surgeons and administrators in who had things to lose or felt like they had something to lose and didn’t want to, by getting them involved and say, hey, this is how we’re going to look at it. This is how we’re going to do it. It gave my schedulers an easier time to go because in a week ago, if this is policy, it’s been out there. We’re showing it. And we have the backing of the senior leadership to follow that policy for the good and the bad. 

AT: Right. And so I think in the last minute or so, what I would add is that Tyler, and Julie, and a few of the surgeons on the traction team really were the ones that were raising their hands, saying this is going to make a difference for us. And then the senior leadership supported them in that. And I think that is what has made the difference. So not only were the surgeons brought in, but OR scheduling, those that were truly affected by this. And so obviously, we’ve shared some of the early success with Exchange, Analyze, and Collect. And then we’re continuing to monitor those high level goals. 

So they are starting to see some movement. And not only in block utilization, but again, kind of how they define room utilization, and what they choose to do with that. So not only creating the capacity with the Exchange and kind of the low hanging fruit, but they’re also starting to drive that accountability and make big changes with the block grid in order to drive block utilization improvement. And so they’ve started to see some movement in that. But as Tyler mentioned, they’re kind of in the thick of change right now. And so as those metrics change over time, that’ll afford them to do different things and make different decisions at a higher level. So please continue. 

I’ll have Marianne chime in here. Please continue to submit your questions, I believe via email to info@leantaas.com. And if you have any interest in connecting with us afterwards, we’d be happy to do that. I’m going to turn it over to Marianne to wrap up logistics. But just wanted to thank Julie and Tyler very much for their time in sharing with the group on the line.  

JK: Thank you, Alyssa. 

TF: Thanks. 

MB: Yeah. Thanks to everyone for joining us today. And thank you to Alyssa and the OR team for another great webinar. And special thanks to Julie and Tyler for joining us today. We really appreciate it. As Alyssa mentioned, if you think of any questions, or you just want to provide some feedback, feel free to contact us. Thanks again for joining us.