Unlocking CensisAI²: The Metrics That Matter for Smarter SPD Decisions

Hey, what's going on folks? It's Daniel Litwin, voice of B2B, and welcome to another episode of the Consensus Podcast brought to you by Census Technologies. Make sure that you're heading to our website, census dot com. Again, that's c e n s I s dot com for more information on our solutions and services and for more episodes of the podcast. And make sure that you're subscribing to the Consensus Podcasts on Apple Podcasts and Spotify, where we break down everything to do with sterile processing departments, whether that's SPD teams, workflows, technologies. If you wanna find out what's new, what's hot and what's changing in sterile processing departments, come here to the Consensus Podcast. All right, folks, we've got a special episode of the podcast here for y'all today. We're gonna be featuring a presentation. That's right, more visuals for you to engage with from our very own Beth Perry, who's an engineer of business intelligence and analytics at Census Technologies. Before we introduce Beth and let her start running the show with her presentation, I want to set the table on the topic. Today's topic is all about data, right? We're talking about something every SPD team is dealing with right now for better or for worse, and that's an influx of data. Whether it's useful or not is what we're gonna be digging into here today. So the challenge SPD teams are facing nowadays is not just collecting a lot of workflow automation data, you know, supply data, patient outcome data, all that good stuff. But are they using it? Right? That's the challenge. Is it being used to improve outcomes? Is it being used to make better decisions in reactive and proactive fashion? Right? Is it actually improving efficiency of SPDs? Is this data ultimately supporting the most important thing, patient safety? This is what we're gonna drill down on with today's presentation, right? The reality is that there's no shortage of metrics in sterile processing, but the challenge is knowing which ones actually matter. How do you sift through the noise? And even when you do identify the most important data points, how do you make them actionable? Right? So we're gonna be breaking down with today's episode and with our presentation from Beth, how SPD teams can actually cut through that noise, how they can focus on the right data and how they can turn insights into real operational impact. It's going be an exciting one for us today here folks, and I'm looking forward to showing you all of the great prep that Beth has put together for us. So for our special presentation, I'd like to welcome again Beth Perry, engineer of business intelligence and analytics at Census Technologies. Let's jump in Beth, welcome. Why don't you go ahead and introduce yourself, what we're diving into today. Let's hear it from the actual expert. My name is Beth Perry, and I'm a business intelligence and analytics engineer here at Census. And I'm excited to present to you today on such a practical and important topic, putting your data to work. Because we're talking about metrics that matter, and that implies a couple of things. First, for a metric to matter, it needs to provide you with some kind of meaningful insight. If you don't understand what a metric is or where it comes from, it's going to be difficult to understand what it might be trying to tell you. And second, a metric that matters is one that influences your decision and inspires you to act. If you have clear and insightful metrics but you never let them guide your decisions, how much value do they really have? As the Harvard Business Review puts it here: data without insights is meaningless, and insights without action are pointless. That's not what we want. We want data that produces insights and insights that inspire action. Awesome. Thanks for all the intro context there, Beth, And I'm looking forward to digging in deeper into your presentation. So first thing, I love how you framed that just now, right? This idea that, you know, what data actually matters? Well, it's the data that drives action, right? Data is useless unless it leads to action. That's sort of the the whole point. Right? So I'm glad you're reemphasizing that for our audience here. Just to get, you know, perspectives from the trenches. Right? Why do you think so many teams actually struggle to use their data? What's getting in the way? Why aren't they able to make best use of all these metrics and data points? Trying to act without a solid understanding of the situation is kind of like playing the old children's game pin the tail on the donkey. Have you ever played that, where someone blindfolds you and then spins you around in circles or asking you to try to pin a piece of string onto a picture several feet away? But once you take off the blindfold, then you can see clearly, and knowing where to pin the tail becomes a very simple exercise. So in the case of productivity, we'll ground our understanding of the current situation with this first question. How productive are we now, and what is the trend? And then we'll use that understanding to guide our answer to the second question. How can I do more? Now just to clarify here for a second, Beth, before we continue, when you say, you know, metrics that matter, the the data that actually matters, can you clarify for our audience here what actually separates those data sets, those metrics from everything else that teams are tracking? Like can you get a little bit more specific and granular on what differentiates metrics that matter versus metrics that don't matter? And, again, like, how those are actually separated out in practice, not just theory. What's an item processed? In SensiTrack, you work with containers and peel packs, scopes and equipment, not items. But if you've ever worked with the employee productivity report, then this terminology is probably familiar to you. Because different SPD processes can work with different types of things, and because the productivity module needs to give you a holistic view of everything you've worked on, it uses the term item to refer to whatever thing you've processed in each module. So in container assembly, one item is one container assembled. For peel pack, one item is one peel pack. In decon ten, you can work with multiple things. So one item could be one container, one case cart, or one piece of equipment, and so on. So items processed is all the things you've processed across all of the modules of Sensitra. Items per tech per day is the first metric in this big table at the top of the page. What this is doing is taking the total number of items processed in all of our core SPD areas and then dividing that by the number of days this facility was running, and then dividing again by the average number of technicians working on those days. So what that tells you is about how many items each SPD technician is currently processing in a single workday, which is basically their throughput. Now, think rates like this are really helpful for putting very large summary numbers in perspective. You notice back on the Overview tab, we were looking at hundreds of thousands of items processed for West Tower over the last year. And it's really hard for me to picture what that looks like on a day to day basis. But by breaking it down into this rate, it's a lot easier for me to think about a technician working on about forty six things in a day. You can also use the site trends chart in the bottom left to see your throughput trend. West Tower is also basically flat on this trend. Let's go ahead and take a second to make this a little more real here for our audience before we continue, Beth. And really what I mean is let's get some perspectives from actual SPD teams if possible. I know you, you know, you and your team interface constantly with real sterile processing department professionals. So can you give us your insights from what you've been hearing from your discussion with pros, in the industry? Where are you actually seeing this trend of data as a challenge, data as noise, right? Actually showing up in day to day SPD operations and where are you seeing this trend of making better use of data start to win out? Right? What are you seeing pulse on the, you know, real state of the industry? We'll need to identify some factors that influence how productive we can be, and we'll call those drivers. So let's explore three productivity drivers starting on the assembly standards page. Container assembly is a very manual process. As far as hands on time for the technician, it tends to be the most time intensive portion of the primary style processing workflow. So, if we want to increase productivity, it makes sense to see if we can reduce the amount of time required for container assembly. The Assembly Standards page helps you analyze how long it takes your team to assemble containers. Specifically, it breaks down the total assembly time into the average number of seconds that it takes to put each instrument into its container. Now, logically speaking, the more instruments there are on a count sheet, the longer it will take to assemble that container. And that's something that we can prove with the AI2 productivity method rule, and we see it for all ScentaTrack sites. I'll show you. Looking at this top right chart, we've taken the one hundred most commonly assembled containers, in this case for West Tower, and plotted the average assembly time against the number of instruments on a count sheet. We have average assembly time, number of instruments on a count sheet. And as you can see here, there is a direct linear relationship between the two. So, as the count sheet quantity increases, so also does the average minutes per assembly go up. Even small reductions to the count sheet can really add up. But depending on your relationship with the OR, reducing your count sheet quantity can be tricky. What if they won't let you take anything out? Okay, so let's circle back to average seconds per instrument assembled, because that metric is also a productivity driver. Maybe if we can just go faster, we can also do more work. So, action item number two: Reduce the average seconds per instrument assembled. Now, we have to be more careful with this one. Faster is not always better, right? We don't want technicians rushing during assembly. Rushing leads to mistakes, mistakes lead to rework, and rework is not productive. So, how do we get faster without rushing? Let's look at our ortho set again. Currently, we're averaging a little more than twelve seconds per instrument, right, when assembling this set, and that's across all of our technicians. So, let's click on that set, and then we can get a little bit more specific. So, with the set selected, now the tech detail chart on the right is showing me how fast each technician typically assembles the ortho set. Even though the overall average is about twelve seconds per instrument, you can see there's a wider range here per technician. In fact, the technician who assembles this set the most often takes about two and a half seconds longer than the next technician in the list. So that two and a half seconds per instrument over seventy three instruments adds up to about three minutes more per assembly. If we were able to save three minutes on each of the hundred and eight assemblies that Stacy did, that would reduce our hands on assembly time by about five and a half hours overall. So, again, we do have to be careful here because just because someone is slower, it doesn't mean they aren't doing a good job. And just because someone is faster doesn't mean they're following the right process. But assuming there are no process issues here, then looking at average seconds per instrument can help you identify better and faster ways of working on specific sets, letting you multiply efficiencies across your entire team. Yeah. Beth, I'm I'm really glad that you are tying it back to operations because that's where this really becomes more than data. Right? Like when you actually feel an operational impact to apply data metrics. When you see less tray errors, less missing items, less rework, less panicked OR calls. Right? That's how you know that data is driving real impact because the operations are smoothing out. And because those pain points, those day to day challenges SPD teams face are fewer and far between. So now let's do a little self promo here. Obviously, I wanna hear from you on, the Census AI squared platform, which I know is driving a lot of data visibility, and actionability for SPD teams. So can you clarify for our audience here and get in the weeds of the tool and platform a little bit? Where does Census AI squared come in to help teams act on all this data and actually start to drive positive impacts in their SPD operations. By putting all these metrics on one page, you can get more of an added glance view of your current situation and the related trends, hopefully speeding you along the way to insights and action. So Let's take a moment to review what we saw in the productivity model. We looked at two metrics that show how productive we are: items processed, which gives us the overall volume of all the assets processed in our department, and items per tech per day. This is our average throughput, which helps us to see what the overall volume looks like when it's broken down into the context of a single person on a single day. Rates like this tend to provide a perspective that's a little easier to wrap your head around than a giant grand total. Also looked at three drivers that influence productivity. How many instruments are in your containers, your technicians average assembly speed, and the proportion of work time spent on core SPD workflow. AI squared productivity provides metrics for each of these drivers. Now, depending on what the numbers look like for your department and what your relationship is with the OR, you might be able to increase productivity by taking one or more of the actions listed on this slide. If you can reduce the number of instruments in your containers, you should be able to assemble more containers in the same time span, which will increase your throughput and therefore productivity. Even if you can't take anything out, if you can reduce the typical time it takes to assemble the sets your team sees the most, then you can free up more time and get more done. And if your team is getting bogged by less productive tasks, like we saw all that location scanning going on in our demo, Try to figure out if there's anything that could be eliminated or reasonably shifted to different teams. To keep funneling down, in even more specific fashion, right? After you get something like Sensus AI squared implemented, you're now able to turn, you know, more data into more useful insights. Teams are able to prioritize their work a little better. Teams are given better visibility into tools, operations, status, etcetera. Can you walk us through a few of the specific metrics you've really seen move the needle for SPD teams? Because even within these sets of metrics, there's still a lot to make sense of. Which ones stand out to you as actionable, the most impactful, the most useful? You have limited training time and resources. So how can you make the best use of them to optimize your technician education? Similar to what we did for productivity, let's get grounded on the questions to be answered here. First, understanding the current situation. Here, we'll look at which errors are most prevalent and most costly. This is going to provide crucial context to help answer the second question, How do I help my technicians grow? Let's open the Quality Module and take a look. Here we are on the Overview page of the Quality Module. Just like with productivity, the overview is meant to answer basic questions about your current situation in this case, which errors are most prevalent and which errors are most costly. So, we'll start with most prevalent. The metric for this is going to be total events Event count is simply the number of times a particular event has been recorded in Censa Track. The more times an event is recorded, the more prevalent it is. Next, most costly. There are multiple ways that we could define most costly, but for today I'll be focused on monetary cost, which we'll measure in terms of case delay minutes. Census generally estimates that an average OR minute costs about sixty dollars The more minutes a case is delayed, the more costly in dollars that error is. So looking at the event count by group type chart in the bottom left, this will help us quickly identify our most prevalent issues. It's ordered by event count, so the most prevalent errors are right here at the top. We can quickly see that the most commonly reported quality event by far is set up incorrectly. Now if we only wanna look at quality events that are associated with case delays, we can just check this box. And now we're filtered to only quality events that are associated with delays. Looks like those incorrect setups are also the main issue here. So, now we've identified the biggest area where SPD quality is falling short. What can we do about it? Typically, we'd want to use some form of education to help technicians understand what the specific issue is and how to prevent it. But should that training be more of a personalized coaching session, or should you plan an in service for all of your staff? Let's take a closer look at the Set up incorrectly quality events. I will filter to just that event to make it a little simpler. How many technicians have made this error? Looking at events by responsible party, it's quite a few. Let's see. I'd say, just going through, it's more than twenty. And it isn't like the techs at the top of the list have super high event counts where everybody else just has one or two. It it's pretty, pretty evenly spread. What that indicates to me is that there are a lot of techs who could benefit from some training in this area, and you might be able to plan an in service to review proper setup procedures. So, I'll show you another example for comparison. Let's clear our slicers for a moment so we can see all the events again. Clear this. Clear this. Okay, this is all of our events, and this time I'm going to click on BioBird. Let's see what's going on with BioBird. Okay, so events by responsible party, here you can see a very different pattern, right? So, we have two lines here where there's a ton of events and then they drop off dramatically. What this is saying is that for Rosemary and the unknown line, which is just someone who free texted unknown whenever they created this event, These two entries take up forty five percent of all of the bioburden events that have been recorded for me. And so if I were going to look at how to address this issue, rather than doing a big in service with the entire team, I'd be tempted to kind of look at specifically what it what it is that Rosemary is struggling with. So I can provide her some individualized coaching, and that will address the majority of these issues. So let's take a look at that detail. I don't have comments for everything here, but I do have some helpful comments on some of these. But as I look through these, I can tell it looks like there's a common thread of particularly lumens, but more generally just making sure that things are completely clean, before they go into assembly. So, if I wanted to coach Rosemary, I can use this feedback and I can look at these sets and say, you know, maybe even specifically, I want to review the Cynthia's TFNA sets. So that's one way to find some topics for individual coaching, but I want to look at another one now. I'll reset my view to show all of the quality events for the West Tower facility. So by default, this events by responsible party chart is sorted by event count so we can see the most prevalent issues at the top. We used event count as our measure of prevalence because that's what the OR is seeing. They're going to focus more on the overall volume of errors than they are on which specific technician made a mistake. But for coaching, we want to consider another measure of prevalence, which is error rate. Error rate is a measure of frequency. It'll tell you how often this technician or service line or asset type experiences an error. In Census AI2 quality, error rate is a ratio of the total events compared to the total items processed. Based on feedback from customers, by default, we filter those total items processed to just include container assembly. You actually have control over that and can change it to anything that you prefer. So if I resort this table by error rate, now I can identify which technicians are more error prone than others. Remember that as a ratio, even one or two events can calculate to a very high error rate if the technician hasn't assembled many sets. And that's what you see going on with these first two, entries here. I'm actually going to dig in deeper on this third row with an error rate of three point three nine percent. What that's telling you is that at least three of every one hundred containers that this tech assembles results in some kind of quality event. Okay, with this filtered, now I can see the specific events and assets that this technician may be struggling with. And I can use this to guide my coaching. I'm actually going to recommend we move over to the Text tab so we can go one step further. With our technician selected on the text page, we get a new piece of information: How is this technician's error rate when compared to the rest of the team? This gauge at the top has a marker for the average error rate for all technicians, which is zero point four seven percent. This technician's error rate is significantly higher than that, at three point three nine, which is also indicated by the red fill color. Now, let's take a look at the Events by Group Type chart on this page at the bottom left. It has some new metrics in it. So, events per one thousand items. It's just that. Based on their history, if this technician processed one thousand items, how many would have this issue? Right? So, for every one thousand items that Margo processes, we would expect to see two to three, with instruments not protected issues. And then we have events per thousand items for all techs, and that really helps to put this in perspective. So for every one thousand items processed by everyone on the team, we wouldn't really expect to see any instruments not protected events. This zero point zero three, it's more like one in thirty thousand items processed. And then we have this final column, tech error rate percent of average. What this does is it gives you the ratio of the two rates, and it tells you that this technician is more than ten thousand times more likely to have an instruments not protected issue than other techs on your team. This is a pretty rare event, but if we scroll down to our Setup Incorrectly event, down here, we still see a significant disparity between this technician and the rest of the team. And of course, if we click on this event or if we drill into the detail, then we can get, we can actually identify the specific assets and issues where coaching can have the biggest impact for this particular team member. Okay? So, the intent here isn't to punish technicians for making mistakes it's to empower managers to provide education where it's most needed and most beneficial for each technician. Did you know you can also use the text tab to identify high achieving technicians? Let's switch our slicer value. Okay, I'm going to change you to Ilionin. There we go. So Ilyana is one of our super users, and the data really shows it. Her error rate is much lower than the rest of our team on average. Even super users do have some room to grow, so you see some coaching opportunities here in the bottom. But now I want to reverse the sort on this. Okay, so here's our setup incorrectly event. As you can see, Ilyana is actually eighty four percent less likely to have this issue than the rest of the team. So maybe you can use this as an opportunity to recognize her skills or even to enlist her to help train her peers. Now, you might say most all of these actions are reactive. Everything we've talked about thus far, we're looking at issues that have already happened, and we're looking at ways to correct those. How can I be more proactive about quality? And there is a metric I'd like to show you for that. It's called average repertoire size. Let's head back to facility comparison. Average repertoire size is a measure of how many different types of containers a technician typically assembles. You can think of it as a proxy for technicians' skill level. Typically, when new technicians start, they only assemble a very limited set of container types primarily your basic major and minor sets and general instrumentation. And as they advance, then they start to expand into other service lines with more complex instrumentation. Thus, the more different types of containers a technician can assemble, typically the higher their skill level. What we identified in the Census AI Squared Quality module is that technicians with higher repertoire sizes tend to have lower error rates. You can see this general pattern here on the facility statistics table. So, the facilities with higher error rates, you can see they also have lower average repertoire sizes. As this goes down, this gets bigger. Unfortunately, there's some issues in my demo data that are preventing our correlations charts from working. But I do have a sample I can show you for what you might see in your own environment. So this is probably the most common pattern that we see. And, at the lower end of repertoire size on this side, error rate is relatively high. And as repertoire size increases, you see that the error rate begins to drop off, and it does eventually level out. So, as a proxy for skill level, this kind of intuitively makes sense: better technicians are going to do better work. One of our theories as to why a broader repertoire might improve quality is that working with different instrument types can help technicians better anticipate potential issues, like where bioburden might be able to hide or where repeated use might make the sharp instrument very dull. If so, for newer technicians, then this gives us some guidance on how to help them grow into quality minded team members. So, your proactive action item, if the best technicians tend to have a broad rapport, can you set up training initiatives to build newer technicians' exposure to a variety of instrument types and help them to naturally expand their repertoire size? Now, as we wrap up our quality demo, I do want to quickly point out the executive summary button here. When you click this, again, you're going get that plain English overview of some of the key metrics for quality. Do you remember that this text is going to update, depending on what you have selected? So, you can pinpoint the context for the analysis. So, what is our current situation? Well, we used two metrics to define which errors were most prevalent and most costly. We have event count, which tells us how many times a quality event was recorded in Censitrack, and case delay minutes, which shows how many expensive OR minutes cases were delayed because of each quality event. These help us understand where and how our quality is falling short today. Next, to decide what type of training would be most effective, we focused mostly on how widespread the issue was, looking at data like error rate, event count, and response with party count. In summary, it makes sense to provide personalized coaching for errors a technician makes frequently, especially when compared to their teammates. If it's something that a lot of people are struggling with, then it makes sense to set aside some time to train everyone. Those are both reactive training techniques. Alright, Beth. This has been great so far. We're getting near the end. So thank you again for all the prep, all the presentation work that you've done. I want to now give some actionable tips for our audience here. There may be folks listening who are feeling like, know, we're subtly talking about them, right? Like let's say someone's listening and is thinking, okay, we have the data. Yes, this is me. I've got a lot of good data being captured, but we're not really using it. It's not going anywhere and we haven't seen any changes or improvements to our operations in a while. Okay. Let's say that is someone in our audience. Where should that person start? Right? Like, how should they get started with making sense of that data, starting to wrangle these different data points and turn them into actionable insights? Do you have a standard starting point? On our action packed tour today of Census AI Squared, we approached each module with two questions. First question was designed to help us understand what is my current situation? For productivity, how productive are we now? Quality, which issues are most prevalent and most costly? And instrument recovery, what are my problem instruments in terms of availability? With the second question, we then explored what actions we should take based on our understanding of the situation to meet each of these goals that we set up for today. Now that we've finished each of the demos, here is a complete summary of our goals and the actions that you can take to help maximize productive capacity, optimize technician education, and boost instrument availability for your team using the Census AI squared data platform. That's it. I hope you've enjoyed my presentation and that our time together has sparked some insights for you that you can turn into action within your departments very soon. And I couldn't agree more, Beth. Data only matters if it drives action. Folks, I hope you get that tattooed on your arm. Sear it into your brain. That really should be your guiding light as you decide to implement new SPD tools. And as you try to make better sense of the data you're already capturing. Best place to start is make some of that data drive a real change in your operations and drive positive change in a metric where you want to see some impact. Beth, this was incredibly valuable. Thank you so much for your insights today. Again, folks, we've been chatting with Beth Perry. Beth Perry is an engineer of business intelligence and analytics at Census Technologies. Beth, again, thank you so much for your insights, for your time and preparation. This was really great. Folks, anyone listening? Right. If you have questions on anything, Beth broke down today, head to our website, census dot com. Again, census dot com to check out more about Census AI squared. Right. To check out more about how to drive better data driven actions in your SPD. You are not alone in this. Census has your back. We've got the tools, the insights, right? And the thought leadership here to give you more to chew on to drive your actions. So folks head to our website census dot com for more and make sure that you're subscribing to our podcast on Apple Podcasts and Spotify at Conecensus, C O N C E N S I S. All right, for everyone listening, if you're thinking differently about your data after this conversation, that's exactly the point. And I can't wait to see how you level up your SPD with some better placed data and data driven actions. I'm Daniel Litwin, the voice of B2B. Thank you for joining us on this episode of the Consensus Podcast. And folks, we'll see you again soon.