SANJEEV AGRAWAL: Good morning and welcome to today’s webinar. My name is Sanjeev Agrawal. And the topic of today’s webinar is an introduction to iQueue for Operating Rooms, and how your EHR cannot do many of the things that iQueue does. My email is firstname.lastname@example.org. And if you want to reach us during or after this webinar, you can email me or us at email@example.com, or text us at anytime at 6308845493. By way of quick background, I am the Chief Marketing Officer and the President of LeanTaaS. And our product suite is called iQueue.
A quick introduction to us as a company, what LeanTaaS is, how we use predictive analytics to improve healthcare operations across the board. Second, we’ll dive deeper into the specific topics of using predictive analytics to improve operating room performance. And specifically, the problems we solve around increasing all our access for surgeons and for patients, around how we increase block and room utilization, and finally how the tools in the ICU suite help you create a far broader set of data driven transparency for your surgeons and for your administrators, as well as a block policy that’s far easier to enforce and adhere to than your current block policy might be, if it’s based on block utilization as the single metric.
The value of doing what we’re going to describe as significant, almost half a million to a million dollars per OR per year. And we’ll talk through the key elements of drivers of how that values unlocked through IQ. And then finally, as the title of the webinar suggests, we’ll spend a little bit of time talking about how different predictive analytics is from the types of things that EHRs do which is more around descriptive analytics and describing what happen as opposed to predicting what is going to happen and how we can make that happen.
So to start with, a minute on who we are as a company. LeanTaaS is a Silicon. Valley software company and our product is called iQueue. We have built iQueue on top of a couple of key areas of expertise. Very deep knowledge and understanding of lead methodology applied through sophisticated predictive analytics as opposed to Excel and Tableau type math. So advanced predictive analytics combined with LEAN and delivered as a software product through mobile and web. And you’ll see that over the course of today’s webinar.
In order to do this, we’ve assembled a world class team that has expert mathematicians, some of the world’s leading LEAN experts, a great engineering team and a proc team. And collectively, we’ve invested about $30 million in building this platform and this team. We work across various aspects of a hospital. In particular, the two products in market our iQueue for infusion, that is now live or we’re going to be live soon, but has on a contract over 90 infusion centers in over 2,400 infusion chairs. And a majority of today’s webinar is going to be talking about iQueue for operating rooms, that is now live in across nine healthcare systems.
Soon to be live across 10 or 15 others over the course of this year. While the infusion is at operating rooms, a big problem that we solve is helping our customers maximize the value they get from the investments they have already made in these expensive assets. So how do we increase patient access while improving asset utilization and lowering cost through the use of predictive analytics and LEAN, that’s our mission.
We have several other products in development as you see. And from a team composition perspective, we have a 70-person team that has some of the world’s leading experts in their fields. I was Google’s first head of product marketing and have been an entrepreneur in the Valley for the last 20 years. My colleagues come from companies like McKinsey, Yahoo, University of Colorado. Health, Symantec and many of the top academic institutions in the country.
So let’s jump right into the iQueue for operating rooms product and start by telling you who’s using the product already. So we have nine institutions that have either already deployed or are in the process of deploying iQueue. Several of them, as you see, are academic medical institutions, some community health care organizations. Some on [INAUDIBLE],, some on ethics, some on meditech. And we’re able to work across EHRs. It doesn’t really matter which EHR you have. Over the next six to nine months, we expect many, many other health systems to join the iQueue family. And a lot of it has to do with the kinds of market and technology pressures our customers are facing, which iQueue helps them solve.
So to jump right into what those pressures are, there are five reasons that people invest in iQueue and work with us. And not all five of these are true at every institution we work with. But I have now personally spoken to about 100 preoperative leadership groups. And across the 100, almost everybody is facing some combination, some more and some less, of these five issues. So let’s get right into them. The first has to do with an increasing demand for OR time in the existing ORs thay have. So many, many times when we walk into institutions, we find a situation where they feel like they’re fully blocked out and their surgeons need more OR time. So it feels like they’re trying to stuff a 10-pound weight in a 5-pound bag.
At the very same time, there are patients that are waiting for a long time to get their surgery scheduled. And the paradox of all of this is that when you actually walk around there a lot on a given day, it’s unclear whether they’re using their ORs as well as they could. So one specific example being in time that’s being released, it isn’t always being used well. In fact, time often is not being released and going abandoned or under utilized in the current way they release and request block. The second has to do with a related issue and that is to the extent that our healthcare partners are experiencing growth in patient volume and need for more cases in OR and more procedures.
There is the ability to attract new faculty or new surgeons by guaranteeing them block time is very limited, which goes back to point number one. Now, the reason it’s limited is that they are fully blocked out and their method of allocating block time often based on block utilization, and often fairly static– things that haven’t changed, the block allocation hasn’t changed for a while– leaving very little room to be able to accommodate these new surgeons. And both of these, greater demands for OR time as well as the inability to accommodate new surgeons, is happening at a time when capital isn’t quite as flexible and fluid as it used to be.
Some of our customers are space constraints. So the ability to build new. ORs in the short to medium term is fairly restrained. And so these constraints are causing them to try and find ways to do more with less to accommodate new surgeons and new volume within the ORs they have. While this is happening, the big elephant on the table, of course, is the reimbursement pressures all our customers are facing, especially from Medicare. But across the board, insurance reimbursements are going down. And at this point, the two big questions that are coming up are, one, are we using our existing OR capacity as well as we could before we even try and think about building new ORs.
And even a small increase in the utilization of the ORs we have can have a massive impact on patient access in revenue and profitability, given that the OR is the economic backbone of most hospitals. So this reimbursement pressure is also leading to customers asking for how they can use their existing ORs better. And then finally, the basis of decision making in most part of the hospital systems we work with is based on reporting that teams often get from their EHR or from a combination of systems, including their EHR. At the end of the day, they find themselves describing a problem as opposed to solving it. And being limited in the types of metrics that are being made available to them, and the actionability of those metrics in driving the kind of change in block allocation or the usage of OR time that they like, the credibility of the metrics is often questioned, the data is often questioned.
And despite a lot of effort that is that’s put in place by reporting teams and many EHR teams, it’s unclear whether surgeons and administrators are on the same page as far as the usefulness of those metrics is concerned, or as one customer described it, we have a lot of data but not a lot of information. And just to summarize where we find a lot of our customers, we find a lot of our customers on the spectrum of maturity of analytics. On the left is this idea that everybody has an EHR and everybody’s getting a report that’s telling them what happened. So this idea of describing the problem or admiring the problem exists everywhere.
So we know to the nth degree how many minutes are being used, what block utilization is, first case delays, turnover time, et cetera. And EHRs do a great job of providing that. As you move to the right, we now live in a world where we can do a lot more with this data. So the idea of diagnosing why something happened, not just what happened. And much more importantly, what’s going to happen. Much like Waze or your GPS can predict it’s going to take about 52 minutes for you to get home from the airport. And based on what is likely to happen, how can we make what we want to make happen happen. So this idea of prescriptive analytics as you’re about to see.
Those are things that are typically missing in the arsenal of tools that health systems have put in place. And that’s the reason iQueue exists because we focus on the two right boxes. So how do we solve the problems we talked about? There are four modules in this product that you’re about to see. And the four modules is going back to the problems we talked about. First, the first model is called exchange. What it does is it allows health systems to have a much better tool and provide visibility into released and requested time. So surgeons and clinics can see what time’s on the table and can request that time for themselves.
The second is looking at block policy and making sure that the right block policy that’s based on a concept of collectible time is in place, and not just looking at block utilization. The third has to do with transparency and visibility into the data to help drive better decisions. That’s called analyze. And finally, there’s a module called allocate that helps drive the decision of who should get access to what OR time. So let’s start with the first module called exchange. I’m going to show you the mobile view of this first, but imagine a similar view for the web, which we can also get into if we have time. Imagine a world in which your clinic schedulers and OR schedulers had access to a tool like this, where any clinic could on behalf of this surgeon’s request any available time that hasn’t been claimed or has been released through a web and mobile interface that you’re seeing.
So if I’m multiple locations,. I can go into one of them. I can see what time is available, request a chunk of that time, a portion of time that’s been unclaimed, put in special requests like I need an alarm or I need the robotics room. And instead of calling, emailing, texting, walking into the OR manager’s office, be able to put my hand up and say, I’ll be able to use this time well. If I need time on a day that no time is available, imagine being able to put my name on an Amazon wish list, sort of a waiting list. So in case time opens up on that day, please notify me. On [INAUDIBLE] side, if I realize I’m not going to be able to use time because I’m on vacation or the physician I’m supporting is traveling or at a conference, the ability to release that time through two simple clicks of a mobile button.
So this world is essentially translating what currently exists as a paper-based or a manual release and requests system into one that moves away from this notion of treating unusable chunks of all our time, as if you were doing a garage sale with them, and converts them into an OpenTable, like metaphor, where just like, we don’t call travel agents or we don’t call hundreds of restaurants to make travel bookings and restaurant reservations anymore. We go to OpenTable and we see open chunks of time. This ability to provide full visibility into chunks of open time for the clinic schedulers and for surgeons helps them both manage their own destiny, as well as get access to. OR time when they need it. We’ve also taken this to the point where it’s hybrid scheduling.
You can ask for small pieces of time or you can ask for full day blocks or half day block, depending on the institution. What ends up happening is a much more streamlined process where this request that you just saw gets communicated to the OR scheduler in a way that is in a simple portal, that I’ll show you next, where they can approve or deny the request. But the big win here from a surgeon perspective is surgeons can get chunks of OR time when they need it, and you as an institution never lose time on the margin.
Because even with the best block allocation in the world, life doesn’t work according to a block schedule. So things will come up. I will take vacation as a surgeon. I will go to a conference. I know my schedule for the next six months, and so chances that I won’t use 100% of my block time are very, very high. Another big benefit is no one loses. So if I actually put my block time into the spot that others can use,. I’m just giving up that one instance of time that I wasn’t going to be able to use anyway. I don’t lose all my Wednesdays. I lose the one. Wednesday that I would be at [INAUDIBLE] speaking.
UCHealth, one of our customers, has been able to absorb new surgeons by not guaranteeing them full block, but by giving them access to a tool like this that allows new surgeons to find available slots of time and request them to do cases while they create a book of business. And finally, one of the reasons why everything seems to be urgent emergent in an OR situation today is because of a lack of trust. It’s because of a lack of credibility that I will get time when I need it. And so if I have time today then, even cases that I could in theory have done a few days from now, I would much rather call them urgent emergent and try and do them today. So add-ons are a natural effect of the way block scheduling and release and request works today.
This lessens the pressure on making everything in urgent emergent add on today. I won’t show you the same demo again, but the same capabilities available to your clinic schedulers and to your surgeons online, so exactly what you just saw, where you can release requests and even transfer a block between surgeon groups that shared block time. As you can imagine this interface allows for more interactivity. But the idea is still the same, you’re able to work the release and request time through a simple interface. Now, what makes this even more powerful is the predictive analytics part of it. So what we recently introduced– well, actually, it’s now been about nine months that we introduced this concept of release reminders.
Think of this as almost like a dentist’s phone call or email or text message that says, hey, you have a dentist appointment two weeks from now. Are you going to show up or not? Please confirm. I just got one of those from my daughter today in fact. Now, imagine if such a release reminder were a reminder sent to surgeons and clinics saying, hey, look. You have time, 15 days from now [INAUDIBLE] auto-releases seven days away. But based on your booking patterns, you tend to book cases three weeks in advance, which means the likelihood of your block two weeks from now going under utilized is very, very high. So this is just a simple request. Dr. Jones, you have this blocked time. Are you going to use it? If you’re not going to use it, would you mind putting it into the pot that other people can use? Or please fill it up. So it’s not pejorative. It’s not making anyone release time. It’s just a gentle reminder.
The beauty of this reminder is that it’s a fully closed loop. Let’s say, Dr. Jones ignored this text once, twice, 15 times. You have a lot of data to then sit down with him or her, and say, look, over the last six months you’ve got 15 released reminders. You ignored a majority of them. Days that you ignored about half of them went under utilized. Please pay attention. So driving behavior through automated alerts, not Jim or Jenny or John following and nagging me to release time. But actually just like my. GPS sending me a service side message much more likely to be heard than being asked during business hours to give up my time.
Now, this in combination with this Amazon wishlist idea where I can put my hand up and say, I want time even though I cannot see any available time is beautiful, because it’s extracting demand signals. It’s making your surgeons say they can use time even if time is not available. And it’s giving iQueue data to go look for who has time on days when time has been requested and asking people to release it if it looks like that time would be under utilized. So think of this as a simple supply-demand marketplace, like an eBay, like an OpenTable. That’s both unearthing demand for you and then creating supply and matching it automatically without people being involved. And it works 24/7, 365 days a year.
Final thing on how this request or release is consummated. The last mile of this decision making still needs to be exercised with some human judgment. Because remember that alarm that was asked for, or the robotics from that was asked for, or the scope that’s being asked for, its equipment, it’s whether the OR is actually open, an anesthesia available, is nursing available. All of these are checks that you still think need to be done by the OR scheduler, and so they need to still exert some control over who gets the request approved, denied.
So just to play this video out quickly for you, the old schedulers life changes from a bunch of emails, phone calls, text messages, post-it notes, people walking into their office into a very streamlined portal, where they can approve or deny any of these requests in a seamless way. And if they deny a request, the reason they’re denying that request is very structured. It’s not because I don’t like you, Dr. Jones. It’s because in fact the OR not open today or anesthesia is not available, which. I’m sure, never happens in your institution, sometimes happens in the places we work with. Or if I’m approving the request, I have done the check, and said, we have three alarms, two of them are taken that day but the third one will be available for this case. And then notifying everybody that’s involved in that case, that this time has now been made available to this particular surgeon. This is the OR that they’ll work in.
The results are staggering. So this is one of the institutions we work with, University of Colorado Health. Exchange was introduced as a product mid 2016. In a 9-month period across 38 ORs, over 2,000 blocks were released and 1,300 requested. Block utilization went up 4 percentage points, which is the equivalent of conservatively $460,000 per OR per year. 11 new surgeons were added without giving them permanent block time, but giving them access to these large chunks of time made available through exchange. We estimate that anywhere between 12% to 15% of block capacity, it can be released and requested through a tool like this. And that’s a lot of capacity if you think about it.
Perhaps the most impressive stat from a day to day operations perspective, in addition to all the financial benefit, is this notion of release sleep time. What this is is how far ahead in advance does the body of surgeons and their clinics have visibility into open time. And that going from the auto-release 7 days, 10 days, whatever policy you have, to almost 27 days is miraculous. Because independent of service line or surgeon, the ability to put your hand up and get your patient ready and ask for time a month in advance is huge. The two things that have really been powerful are these release reminders. So the graph you’re seeing at the top is blocks released. And ever since these release reminders started going out, there’s been a huge uptick. And ever since on the request side, this wishlist was launched, there’s been a huge uptick in the number of blocks requested.
It’s gotten to the point where latent demand is no longer being throttled. What do I mean by that? What I mean by that is in a world where I know I only have Wednesdays to operate, I might not even see other patients I can in clinic because I only have Wednesday time. When I know that, in addition to Wednesday, I can get time when I need it, I might see more patients knowing that I’ll always find some time on the margin. And so this idea of filling your ORs better by never losing a block, think about this as no block left behind if you will. This is what this is doing. In financial terms, this is like date trading, and not reallocating your portfolio. So that’s the first module. The first module is allowing you to surface open time, make more open time available, and then allow surgeons to have access to it in their offices, to have access to it, and have a clearinghouse for that.
The second has to do with the fundamental block allocation itself. So remember, exchange works on top of a block allocation that’s being done either by service line or by surgeon. It’s not leaving time on the margin. The second module called collect is fundamentally questioning the basis by which block policy and block allocation is set. In almost every institution we walk into, the basic metric that everyone seems to use is block utilization. Here’s the problem with block utilization. Let’s imagine two surgeons, or this could be two service lines– surgeon A and surgeon B. Let’s say for a second, surgeon A is someone that does more predictably long cases. I’m an orthopedic surgeon. I do reasonably cookie cutter knees and elbows and hands. And my cases take 2, 4, or 6 hours.
If I have 10 blocks in a one quarter period, and I’m surgeon A, and I fill 7 and 1/2 of those blocks really well repeatedly. And then, I leave 2 and 1/2 days unused, completely unused. My block utilization is roughly 75%. If I’m surgeon B,. I’m a neurosurgeon. There’s no way anyone can predict how long an individual case will take because the patient population, because of the nature of what I do. I open brains up and I put them back together. So there is absolutely no way to say exactly how long the case is going to take. And in the end game, I end up using all 10 days. And some of these surgeries are exactly the same, but they took very different amounts of time. So the same surgery on. January 3 took six hours, but on January 10 took 4 and. 1/2. It was impossible to predict how long it would take before it happened.
As it turns out, over a period of time, I see that surgeon. B uses all 10 days. And guess what their block utilization is? Also 75%. So herein lies the dilemma with using block utilization as a metric to make block policy. If you took two days of time away from surgeon A, you can be pretty sure that they were still going to be able to get all their cases, all their elective cases not. If you tried to take two blocks away from surgeon B, it’s quite likely that a majority of their time they couldn’t get all the cases. They need all 10 days to get their cases done. And frankly, because you cannot predict how long it’s going to take for them to do the case, it’s almost impossible for you to actually capture some of the time that’s left at the end of the day on the margin because no one wants to go after them.
No one wants to wait for them to get started in the OR, especially because sometimes this case could take six hours as opposed to 4 and 1/2. So the biggest problem with block utilization as a metric is that one minus block utilization means absolutely nothing. What exactly does 76% block untilization mean? It does not mean you can take 24% time away as we just talked about. Secondly, it’s not very surgeon-centric. The way I could look really good at surgeon A is I could release two of my blocks every time. And then my block utilization would be 75 over 80. Imagine that. And I would always every day, every week of the year, look better than surgeon B. It’s just that the stochastic nature of surgery makes it very hard to use block utilization as a metric that makes sense. It’s not comparable across service lines and it doesn’t account for behavior like releasing a lot of block time.
So instead, let’s talk about a different metric. Let’s talk about collectible time which is a metric we have coined and seems to be working very, very successfully. The whole point behind collectable time is don’t miss the forest for the trees, really only go after chunks of repurposable time that can be gathered and given to other surgeons. What does that mean? Let’s for example look at the same grid. This happens to be an epic grid, but it could be an [INAUDIBLE] one for all practical purposes. Let’s start by saying, let’s ignore small grains of sand. The little blue triangles, which could be a 15-minute delay in first case starts. It could be half an hour left on the table at the end of the day. It could be turnover time that’s 10 or 15 minutes longer than you wanted it to be.
Not suggesting that those are great things to do, not suggesting first case delays are good, or turnover time being high is good. All I’m suggesting is those small grains of sand are not collectable and repurposable into usable time specific cases. Instead, if we look at three types of time in which you could actually put cases in. So the large red diamonds instead with the little blue triangles. The first is large enough chunks of time being left on the table either in the middle of the day like on 1/10, the end of the day like on 2/22, or the beginning of the day like on 3/1. What does large enough mean? It depends on the service line. For orthopaedics, large enough might mean 2 and 1/2 hours. For neurosurgery, it might mean five hours.
The point being, if you look at a history of how your service lines and surgeons are using time, it’s quite likely that if you stop thinking about block utilization for a second and start thinking about one, are there large enough chunks of time being left on the table? Some of my surgeons are using mornings well but not the afternoon, and they’re doing it repeatedly. Second, do some surgeons and service lines sometimes leave entire days unused? That’s like on 3/15. And the third is, are many of my surgeons hoarding block? And the way you know that is if they’re releasing too much block, and if the way you calculate block utilization excludes the amount they have released, you’re doing yourself a disservice.
Because they’re block utilization may look really good but they’ve just released, say, 30% or 40% of the block time that you gave them. So if you define collectible time as the sum of three things– large enough chunks of time left on the table, days that are abandoned repeatedly, and the time that’s released above a certain threshold you get to define– then you become very surgeon-centric, because this could be any service line. It could be any surgeon. And by definition collectable time means, because I’ve looked at it over a period of time, if you took that time away from me, you could be assured that I could still get all my elective cases done.
So what the tool does, what iQueue as a product in this module does, is allow you to configure how much is too much release time. So what’s the threshold above which you will consider time that’s released as being collectable? And what’s that contiguous unused chunk of time that you consider usable to put a case in. Like we said, it could be 2 to 2 and 1/2 hours for orthopedics. It would be five hours for neurosurgery. Once you configure the tool, we allow you by block owner, which could be an individual, or service line, or department, a group, whomever, by block owner, by day of week, by location, how much of their historical usage has been collectable.
And unlike block utilization, this is a much more precise, because in the conversation with Dr. Kennedy, when we go and say, Dr. Kennedy you have four blocks. One every Monday, we think you can get your cases done in three. It’s not because I’m fighting over a 10-minute delay in the morning or a 5-minute turnover delay or 30 minutes left on the table at the end of the day. I’m not fighting about block utilization at all. In fact, I’m giving you credit for those small grains of sand. What I’m really only pointing out is that if I look at the large red diamonds in that picture, then those amount to one full Monday I could collect and still not hamper your practice. What do I mean by that?
Let’s break the collectable time down into entire blocks unused by Dr. Kennedy, time that she has released above the 15% time that we’ve set as an institution as a release threshold, and how many times she’s left more than four hours of continuous time on the table because that’s the policy for her– that’s the continuous chunk of time for her service line. And then if we want to drill deeper, I can go on the right and show every block she’s used because all this data is beautifully kept in the EHR. So we can go block by block by block, month by month by month, week by week by week, year by year by year, and say, repeatedly, for the last 12 quarters, this last quarter as well, this is the composition of your collectable time, and that’s the argument for saying, “You could get all your cases done.” OK.
So the big aha here for us– when we look across the institutions we work with, the big aha is that if we look at the chunks of time that are left on the table, the reason they’re left on the table is not usually the ones that we go after first. So if I look at the left bar as being the total amount of time in the ORs we work with, and this bar on the right as being time that has been used, everything in the middle is time that’s not been used. And if I look at the drivers, the reasons why it’s not been used, instead of focusing on canceled cases, first case delays, cases ending early, turnover time, that’s not where the big opportunity is.
The big opportunity is in what we call schedule downtime, which is collectable time. It’s these large pockets of time that we don’t usually have discussions about because we’re still using block utilization as a metric to compare service lines. So Exchange allows you to never lose a block on the margin. Collect allows you to identify chunks of time that if you took away and repurpose, either to new surgeons or close the OR or to other surgeons, you wouldn’t hurt anybody’s practice. Think about this as a low-hanging fruit of repurposable time. One of the big benefits of this table is if you’re hiring a new surgeon and you want to see a certain day of the week that you want to give them time, you can find collectable time and block owners currently from whom you could take it away and give it to them.
So that’s one very, very precise use case. So Exchange, Collect. Let’s talk about Analyze. We live in a world where our. GPS tells us how long it’s going to take to get somewhere. Or I could go to my phone when I get close to my car, and it tells me how long it’s going to take to get home. Trying to edge into that world in the periop environment might look like this. So imagine a world in which all of you– all your surgeons, all your clinics– got one text message a week. OK? And that text message had five key metrics– if it’s a search and text message– and a little link at the bottom that allows surgeons to see their own metrics sent to them just once a week, if they care and if your institution cares.
They don’t have to participate, but if they did, then in 90 seconds or less, they would see everything about their performance; how they did on utilization, how they stack rank if they’re competitive against other surgeons, how they used every block that they owned in the last week. So how much OR time they took in their own block, in a service line block, in a group block, how much they contributed to the overall capacity of the institution. If there were delays, how many delays there were? First case delays, turnover delays. Why those delays occurred? All being surfaced to them in a very simple-to-use, at-my-fingertips-like method. If they want to see how they stack rank against other service lines– so if I were a chief of surgery for a certain service line– I can see all my docs. I’ll show you that next.
So the focus of this is make the right information available to the right individual at the right time without an act of. God, without combing through tons of paper and. PDFs and going and logging in through dashboards. If surgeons prefer to get this through email or paper, all of that could also be done. But this idea of information coming to me and being pushed to me is a very, very powerful notion. Let me show you a sister capability. Imagine all of you as leaders– periop leaders getting a sister text message that across all the ORs you manage across all the different locations– imagine in 90 seconds or less, you could get right to that individual surgeon who might be asking for more block time and be able to see their performance and have a fact-based conversation with them.
So, for example, being able to stack rank right on your mobile device, on your browser– no app involved, by the way. None of this requires an app– but if Dr. Taylor is asking for more time because she worked two overtime days in the OR for the last two Wednesdays, I could either say, OK, that sounds like you need more time, or I could go in and I could see every Wednesday that she’s worked the last 15 Wednesdays and say, you know what, it’s true that the last two Wednesdays you worked overtime but the 13 before then, you didn’t. And so, the case for needing more OR time might not be that strong. So the big benefit is anecdote doesn’t become strategy, and the loudest squeaky wheel doesn’t necessarily get what they want because we now, both as the surgeon and the administrator, have access to the same corpus of data that we can make decisions on together. OK? That’s step one.
Step two is actually then doing what we call anomaly detection, this idea that by the time utilization and first case delay and turnover and forecast accuracy metrics come out, it’s too late. It’s a day late. It’s a dollar short. What I really need is help while things are going wrong. So what if we could detect patterns of bad things happening? Cancelation ratios going up, utilization numbers going down, first case delays going up, when I work Wednesdays with a particular team is when I have more of these problems than others. Those are good things to bring to my attention before the fact– or what we call early warning signals– so this idea of, please look at. Wednesdays because I’m not trying to judge you or be pejorative, but I’m trying to help your Wednesdays, and for you to do better. OK?
So a lot more to talk about here, but the idea of reporting being translated into a world which is useful, accessible, and at my fingertips, in ways that I can actually better my performance, not just understand it after the fact. The final module has to do– it’s called Allocate. And the idea is to say, if we want to get precise about using a mathematically sophisticated method to understand how much time we should allocate by service line and by surgeon, we can do a lot better than, hey, we gave orthopedics 40 blocks last time, they lost two surgeons or hired two surgeons, so let’s give them 38 or 42. Instead, if we were to do this a little more precisely, we would use a forecasting algorithm that takes the volume and mix of cases being done by service line to project the volume and mix of cases that that service line would do, and then allocate time.
How does this work? So remember that. Swiss cheese diagram we showed you, the same one that was used to highlight collectable time? That same one has a tremendous amount of gold hidden in it because it shows patterns of seasonality– what is the variability or consistency in the number of cases a service line or a surgeon does and the length of cases they do. If you take all of this and roll this up to a department or service line level, your ability to forecast the mix of cases– meaning the lengths and volumes of cases– and then come up with a block allocation that makes sense because it takes all of these variables into account is much higher.
Let me give you an example. Let’s take the orthopedic service line. And if I knew the number of cases of each length– 0 to 1 hour, 1 to 2 hour, two to three hour, et cetera– over the last three years– So just to play that again for you, this is 0 to 60, this is 60 to 120, this is 120 to 180. These are the number of cases that lasted that’s long, done by orthopedics for the last three years. Then being able to forecast how many of those individual type of cases will be done in the next 90 days requires a time series estimation that every other industry does. FedEx does that to predict how many boxes of each size they’re going to take in their trucks in the next quarter.
And by definition, the way that that forecast is done is taking into account individual patterns of behavior– how Q4 compares to Q2 and Q3– not by a human being, not by a consultant, not by tableau. The machine learning is coming up with coefficients of different features, if you will. It’s saying, oncology doesn’t have a lot of seasonality, but it doesn’t know seasonality is seasonality. Just see the pattern between how many cases oncology does every quarter versus neurosurgery or, say, orthopedics. The use of the robotics, for example, you expect it to go up in Q4. But the way to forecast how much it will go up is to look at all of these past data points and forecast the volume and mix of how the robotics room is going to be used.
If you use this kind of forecasting to allocate block time within various departments, the following happens. This is a real example where there are three sections to this chart. The first section is, by specialty, the number of allocated blocks for a customer of ours that we walked into across 25 ORs that allocated 1,600 blocks through an algorithm like this when we projected how many blocks each of these service line should be given. It only ended up being 1,479, meaning that if they had, in fact, taken away 221 blocks from the mix and only allocated 1,479, we were very confident every service line would still be able to get all their cases done. Turns out, when we looked at the number of blocks they needed, it was even less than that.
The reason this forecast is so forgiving is that that neurosurgeon that always takes more than a half they put less than the full day, we allocate the full block to them. So it opens up time for you that you can put into. You can either close ORs or put it into mobile block exchange, as you saw earlier. So that’s step one, freeing up open time. Step two is then saying within a service line– when surgeon’s usage of time is all over the map, it’s highly volatile– even for high-performing surgeons, how do I allocate time to them? So you first open up open open-time, and then you take any given service line, and you put those surgeons and their performance on two– you plot that on two dimensions.
One is the number of cases they have done historically, how much volume they do, and how predictably they do that volume. The point being, surgeons that do a lot of cases but do them highly predictably– meaning with low volatility– should get a lot of permanent block assigned to them. The ones that do a lot of cases but have this kind of a format should get a good chunk of block time but be allowed to make up for their volatility through what’s called service line open time. So what the Allocate module does is it gives you a starting point that’s much better. It tells you how much time you should be allocating by service line to open up open open-time. And second, it tells you how you should allocate within that service line and open up service line open time.
So there’s two buffers you build in, which by definition give you a lot more flexibility, than allocating all 1,600 blocks at the beginning which doesn’t allow you to manage that volatility at all. And the output of that is by surgeon within service line, a recommendation for the base number of block that should be given and how much open time should be kept by a service line. If you do all of this, the financial ante is very high. So just through the Exchange and the Analyze module, an institution like. University of Colorado Health has gone public with their case study of being able to pack their ORs more and to be able to release capacity and increase block utilization by as much as $460,000 per OR per year. OK?
If you do all of these four modules, the opportunity is almost twice that. That’s why we say it’s about half a million to a million dollars per OR per year. Now that’s section one. We promised to talk about EHRs a little bit, so let’s spend five minutes on what we do that EHRs don’t. Now, don’t get me wrong,. EHRs are phenomenal tools for what they were intended for. They were intended for three reasons. One, to maintain a single source of truth for every patient encounter. Without that, we’d all be in trouble. The idea of being able to create an MRN number and follow a patient through and have a record of all that was ever done to them over a period of time. They’re also great at reserving resources.
So Epic, Cerner, every EHR allows you the ability to reserve rooms, infusion chairs, clinic appointments like a calendar would. It also allows you to schedule equipment and providers, inpatient beds, et cetera, et cetera. And then every EHR comes with a reporting capability that, for the purposes of what it’s meant to do, is pretty good. It’s like Charles Schwab telling me, here’s how you performed, here’s what you did. Schwab is giving me a platform to trade, but it’s not teaching me how to trade because it’s not meant for that. What EHRs is don’t do are four things.
Essentially, they’re not trying to optimize anything. So if you think about collectable time, if you think about forecasting, who is not going to be able to use time well, all of these requires taking the data we have and doing something far more sophisticated with it than just report what happened, going back to that chart of descriptive analytics through prescriptive analytics. So this idea that what’s the appropriate amount of operating time by surgeon, what’s the appropriate amount of staffing level in each OR, this idea of predicting the volume and mix to come up with an allocation model that makes more sense, or predicting who isn’t going to use which block well in order to get them to release it, EHRs hours were never created to do that.
The idea of when I spot a potentially underutilized block to be able to send out a mobile text message and say, hey, Dr. Jones, are you going to use that block or not? And if you’re not, please release it, and then consummate a transaction like a supply-demand interchange, as you saw with the Exchange tool, is just one example. Those are not interactions and workflows that EHRs were created for. And so, when you think about how iQueue coexists with EHRs, it takes data from the EHR to do optimization, prediction, be proactive, and use both mobile and web tools to consummate transactions that reduce collectable time and improve your block utilization as well as surgeon satisfaction.
So the whole idea behind the product is you’ve spent a lot of time and money and resources putting a bunch of ORs in place, are you doing as much as you possibly can with the capabilities you have in a manner that’s highly surgeon-centric? Block utilization is not a surgeon-centric metric. Not showing released time and being able to request time automatically is not very surgeon-centric. So if administration can get more surgeon-centric tools in place, the ability to start using the data better– when if you can provide that kind of OR access, the credibility of both sides goes up– the fairness of collectable time versus block utilization as a way to create block policy, and the transparency and the visibility into what’s happening allows you to play as a better team. So the way we do it, just as a quick reminder, is it takes understanding lean methods.
It takes understanding data science and machine learning way beyond averages and mediums and modes because, if you saw with block utilization, the problem with surgeon A and surgeon B in block utilization– my favorite metaphor is my head is in the freezer, my feet are in the oven, on average, my body temperature is OK– is exactly what we’re doing when we say surgeon A and surgeon B both have 75% block utilization. But what does that exactly mean? It means absolutely nothing. One point that keeps coming up all the time is how hard is this on your IT teams. Your IT teams are really busy. They have a backlog of lots of things. Over the last two years, we’ve made this really, really simple by doing two things.
One, the way we extract data from the EHR does not require HL7 or. FHIR or any interface that requires an Act of Congress. The top box here that if you have Clarity on top of Epic, if you have CCL on top of– or Millennium on top of Cerner, we just take a daily feed that comes to us like a simple Excel file or CSV file through an extract using technology that was available 30 years ago. So through an SFTP. Server, there’s a transfer through a simple script. And it’s gotten to the point where we know Epic and. Cerner well enough, and MEDITECH well enough to actually have pre-written some of the scripts that allow us to extract the data tables automatically. I won’t go into that into a lot of detail.
The big point being, we make it really easy on part of your IT teams to extract the data, to maintain the product, to onboard, support, and continue with the innovation in the cloud. The other big benefit is everything’s in the cloud. On AWS, it’s highly secure, SOC 2-compliant. It’s also done in a way that if any one of our customers innovates with us, everybody gets the benefit. So unlike a lot of EHRs that are individual system deployments with servers behind your firewall done specifically for you, if New. York-Presbyterian wants us to do something, the entire network gets the benefit of it. Much like Gmail. If Gmail makes a feature for one to improve, everybody gets the benefit of it, unlike a custom install behind your firewall. So let me stop here.
We have about 10 minutes. Let’s open them up for questions. Marianne, are there any questions?
MARIANNE BISKUP: Yeah. We already have a couple questions in our queue. The first one is, you mentioned Epic and Cerner, do you have any live. Cerner interfaces? If so, what type and do you have any references we can talk to you about that process?
SANJEEV AGRAWAL:. Yes, absolutely. So, like I said, interface and integrate are tricky words, so let me just double-click on that. We require– so if I click on this link, let’s see what happens. Hopefully, the right thing will happen. Otherwise, I will go and copy this. We have created scripts for your Cerner team to be able to run those scripts in 90% to 95% of the time. I’m not going to go through these scripts, don’t worry. But each of these is a little piece of code we have written for you to be able to run on top of your Cerner install and be able to extract the data you need. So the interface is simply running these scripts to give us a historical set of data as well as a forward-looking set of data.
So what your IT teams have to do is just deploy these scripts. If there are problems that come up because your Cerner install has been customized slightly differently, our engineering team will support you into making those adjustments, making whatever version of scripts work for you work to give us that data. So there are two steps. One, give us historical data. Second, there’s this notion of what’s called a cron job. A cron job is simply a times job that says, every night when you’re Cerner install refreshes your data warehouse– it could be Millennium, it could be something else– these scripts run automatically in the middle of the night and send us a fresh batch of data back to an SFTP Server we’ve set up for you.
So, yes, we do have Cerner installs that are live, New York-Presbyterian being one of them. We’re going live with Dignity, which is also in Cerner. There are two other customers that we haven’t announced yet that are also in Cerner. But independent of. EHR, the way we’ve made this product independent of EHR is we know exactly the data and the data tables we need. We’ve done 90% of the legwork in creating the scripts for you to make those work.
MARIANNE BISKUP: And we have a couple more questions here. How often do you suggest we review block allocation?
SANJEEV AGRAWAL: Yeah. So we would suggest you review collectable time a lot more than you review block reallocation. And here’s what I mean by that. Whenever you have fluff in the system, whenever you have slack in the system, collectable time’s essentially saying, you’ve given time to people and they aren’t using it well. Reviewing that and creating a discipline about risk-taking that time and doing something different with it is a wonderful thing. You may even want to do that monthly or every six weeks or every couple of months.
Why? Because you’re not redoing your block schedule. You’re just setting aside time that is not being used well, either to attract new surgeons or closed ORs, so it doesn’t hamper any given surgeon’s current practice. Allocate is a different problem. The problem with allocation and trying to do it too often is you don’t want to mess up people’s life. There’s tons of variables you have to take into account, as you know better than we do. One is just when people do clinics.
Two people’s summer schedules might be different. Not all rooms are fundable. There’s some rooms that are only capable of doing some types of cases. Some rooms have special equipment, and then some surgeons need those special equipment rooms only sometimes. So creating a precise block schedule is incredibly hard, so you want to do it wisely. So we do suggest that you look at reallocating block at least once every six months. If not, once every three months. But the Collect module and looking for collectable time, you should do much more frequently. Once every six weeks, once every 90 days would be our recommended pattern.
MARIANNE BISKUP: OK. We actually have a lot of questions in the queue, so we’ll try to get through all of them. If we can’t get through all of them in our allotted time, we will follow up with you post-webinar.
SANJEEV AGRAWAL: Yes.
MARIANNE BISKUP:. The next question is, what prevents the chance of miscommunication or the surgeon gets a text to release time? They release it, but their scheduler is in the process of scheduling cases in that time.
SANJEEV AGRAWAL: Right. So it’s a great question. It hasn’t happened yet but– and, really, the reason it hasn’t happened yet is a majority of time, that tool is used by the schedulers themselves. It’s not that often the case that the surgeons themselves are releasing or requesting their time. We found, 90% to 95% of the time, it’s the clinic scheduler– and doing it on the web version as opposed to the mobile version, so even the text messages end up going to the clinic schedule. So depending on the practice of– so that’s level one.
Level two is, if that does happen, there is a way to– I wish we had more time. I would have shown you the web tool as a way to roll back and go back and not– So, for example, if I put my name on a queue saying that time is released, that time is not released until the OR scheduler goes and actually releases it in epic or Cerner or your EHR, meaning there is a time lag between when I click the button and when the release actually happens. If you accidentally did that, you can always go back in through the tool, say, hey, I did that by accident. And that has happened before. And if you do it in a few-hour period, you’ll be able to get that time back.
Absolutely worst-case scenario, if you lose that time, you can fall back. And I can’t remember, of the thousands of blocks that have been released or requested, if this has ever happened that someone’s given up their time and then needed it back and not been able to get it back either on the same day or an adjacent day. But I’ll go back and check. There probably have been support requests about this. All I can tell you is that because it’s clinic schedulers that are handling it most of the time, that’s not a very frequent occurrence.
MARIANNE BISKUP: OK. The next question, what would you suggest we use to schedule a case? Historical case length or surgeon prediction?
SANJEEV AGRAWAL: Very, very interesting question. So predicting case lengths is a little bit like trying to predict the weather, where you can actually say things like– we’ve gotten good enough to say things like, it’s going to rain tomorrow afternoon between roughly 11:00 and 1:00. Trying to be very precise about it and say it’s going to take four hours and 30 minutes is very, very hard. However, your EHRs have great data on what, by CPT code or procedure code, the physician predicted their length of case was going to be, and then, wheels in to wheels out, what actually happened.
We can definitely work with you to take that data and come up with– because the answer is probably a hybrid. Some of your surgeons are better at predicting and owning up to the fact that it’s not just when they were in the OR– wheels in to wheels out, the case is in when they were in the OR. So not every surgeon believes that, but it’s not– so the point being, you have data in the EHR of the predicted lengths of cases from the surgeon perspective and what the actuals were. And we can use that to come up with a far more accurate depiction of what’s likely to be the case.
MARIANNE BISKUP: OK. And I think this is the last one we have time to field. What happens to cases that are denied? Do they go to another queue?
SANJEEV AGRAWAL: Yeah. So cases are never denied. Chunks of time that are being requested might be denied, and then you can ask for more time or you can do a backup plan. You can put your name on an Amazon wish list, right? So cases would never be denied. And remember, from a. Exchange perspective, this is over and above your block allocation. This is just extra time that’s floating around on the margin that’s being used well. So you still have your block time, and if you need more time that was denied, then you can look for other chunks of time using the same tool. Others?
MARIANNE BISKUP: Actually, our time’s up for today. But, again, if you have any questions, you can email us at firstname.lastname@example.org. You can also text us at 630-884-5493. So big thanks to Sanjeev for presenting today and to all of you for participating. Keep an eye on your inbox for a link to the recording of this session as well as any future announcements about webinars. And a friendly reminder, please complete the survey that will pop up on your screen at conclusion of this webinar. It only takes a few seconds and gives us some valuable data to help make these interesting and engaging for you. Thanks again, everyone.
SANJEEV AGRAWAL: Thank you. Thanks for coming.