Clinical Chemistry - Podcast
Dr. Nick Spies from the Institute for Research and Innovation at ARUP Laboratories and the University of Utah..
Bob Barrett:
This is a podcast from Clinical Chemistry, a production of the Association for Diagnostics & Laboratory Medicine. I'm Bob Barrett.
Automation is a concept familiar to those working in high-volume clinical laboratories and for many, this means large physical instruments that perform repetitive processing tasks. As the pool of trained laboratory technologists shrinks and sample volumes increase, these instruments have become an integral part of the modern clinical laboratory. At the same time, there are many other repetitive tasks at the human-computer interface, like data entry, completion of forms, and generation of reports, that automated hardware cannot perform.
To address this deficiency, some are turning to software robots, otherwise known as robotic process automation, or RPA. Just like their physical robot counterparts, RPA has the potential to reduce error, improve job satisfaction for laboratorians, and improve overall efficiency.
A new Q&A article appearing in the June 2025 issue of Clinical Chemistry introduces the concept of RPA explains the tasks it’s best suited to handle and provides a roadmap for successful implementation.
In this podcast, we are pleased to speak with one of the article’s expert panelists. Dr. Nick Spies is a medical director of applied artificial intelligence within the Institute for Research and Innovation at ARUP Laboratories and an assistant professor at the University of Utah. His research interests focus on using analytics tools to improve the quality and efficiency of laboratory testing.
So Dr. Spies when we hear about automation in the laboratory, the first thing that comes to mind is the hardware components that so many laboratories have adopted. This Q&A however, focuses on automation in the form of software tools, namely robotic process automation, or RPA. Can you describe just what RPA is and why laboratories might need it?
Nick Spies:
Yeah, of course. So robotic process automation, or RPA, we might typically kind of colloquially refer to these things as “bots,” refers to a series of software tools that we can use to mimic how humans interact with computers. In theory, at least, any task that you or I could perform with a kind of mouse and keyboard on the computer, an RPA solution could also perform just as well.
So if we think kind of about all of the things that we might use a computer for and are kind of day-to-day laboratory tasks, you can think of some pretty kind of repetitive nature tasks that may come to mind; things like generating performance reports, aggregating quality control assessments, or moving data from one system to another, that may not interact with each other otherwise, or like transcribing information from order requisitions that have been printed out on sheets of paper and putting them into our own kind of electronic record-keeping formats.
All of these really routine kind of highly repetitive tasks make for pretty good candidates for an RPA solution. To give a bit of a quick example, you could imagine a scenario where all of the laboratory’s QC data lives on one software system, but all of your patient results live in another. Unfortunately, these two systems may not talk to each other, and so if you wanted to compare all of your IQC results with that of the patient medians or moving averages, some human would have to go and click through each of those systems’ user interfaces, download all of the kind of individual reports for each assay that you care about, collate them all together into a single source, and then kind of present them to the medical director for that discussion and decision making.
An RPA solution could theoretically do all of that data extraction and put all those results into a clean, nice PDF format or an Excel spreadsheet without requiring a human to do all of that mindless clicking for minutes to hours on end. It could even potentially kind of add conditional formatting or highlight specific parts of that final report that might require more attention if you can give a specific set of rules for the things you might want to highlight.
All that said, much like the promises we’ve heard from our kind of intricate hardware automation solutions, the goal for an effective RPA solution really should be to kind of reduce the amount of time that our workforce is spending on these really medial repetitive “low thought tasks” so that we can free them up to spend their time doing the more fun stuff, the problem solving, the working on complex lab tasks that can’t be easily automated.
Of course, it is a lot easier said than done.
Bob Barrett:
Absolutely. Now you’ve mentioned a few good applications for RPA. Are there any common unifying themes that make these types of applications particularly well suited for automation?
Nick Spies:
Yeah, absolutely. So we can typically think of the classic RPA solution as consisting of a series of 30 discrete steps or commands that you can give to a mouse and keyboard. There isn’t really any form of reasoning or exception handling involved.
And kind of as such, the tasks that are highly suited for RPA are those that you can very effectively protocolize with these well-defined beginnings and ends. Their inputs are very well structured and reproducible, as are their outputs and they require very little, if any, human judgments along the way. You can kind of think of these as step 1, click on this coordinate on your screen, then wait two seconds, then copy those contents into cell A1, and then paste it into another spreadsheet, and repeat until the final cell is empty.
Just very algorithmic, discrete, and easy to reproduce. You could imagine asking yourself the question is this something that a tech-savvy child could do, or is this something that we do frequently enough to make it worth building a bot? And if the answer to both of those questions is yes, then you likely have a good RPA candidate or RPA use case on your hands.
Bob Barrett:
Okay. Well, that’s the good news. Let’s go to the other side. Are there any aspects of the task that would make it a poor candidate for an RPA solution?
Nick Spies:
Yeah, with all of these kind of advantages, you might be thinking to yourself: Why haven’t we kind of replaced everything that we do with RPA solutions already? And there are some pretty significant limitations that are worth mentioning. First, kind of on the operational side of things and this might sound a bit obvious, but building out these RPA solutions isn’t always the easiest thing to do. It’s something that can take a lot of time and expertise and there’s definitely a learning curve involved with figuring out how these solutions work and how to build them and implement them.
And so if the task that you’re trying to automate is only performed rarely if ever, or when it is performed, it’s somewhat quick and easy to do, you may very well be better without an RPA solution. Perhaps more importantly here, it’s often the case that if you do build an RPA solution, it’s not going to be 100% perfect, and even worse, when it does fail, it may even fail silently.
So it’s really best to avoid these RPA solutions for mission-critical type tasks, things where you’re handling clinical data as part of your care delivery workloads, or where, if something went wrong, you would have a pretty significant fallout afterwards. So, sticking to lower risk kind of use cases, or those with easily identifiable modes of failure, is typically the best bet there.
And then finally, we can kind of highlight the limitations for RPA solutions as being the opposites of each of those attributes that made for good RPA candidates just a second ago. Those would be things like, if there’s any kind of complex reasoning that has to happen with the data inputs or outputs, or if there are a lot of exceptions that would make it difficult or unwieldy to really protocolize, or if the inputs for your data are difficult to find from different file systems, or they’re difficult to interpret, so if you’re looking at handwriting, for example.
And the same is true for the outputs. If it’s difficult to really capture down exactly what you want on the other end of the pipeline, then all of that would kind of make for a poorer RPA use case.
Bob Barrett:
Okay, good knowing these limitations. Some of these even seem like the types of things that artificial intelligence might be able to do instead. Can you comment on how any of the newer AI tools might fit into this discussion?
Nick Spies:
Yeah, so there has been this big push recently in a lot of the vendor-based RPA solutions or manufacturers to add AI-based agents or solutions into their products. They’re really kind of rebranding this whole RPA world as “intelligent automation,” where some of these limitations like the ability to reason or the ability to handle exceptions could be kind of turfed over to a large language model or some kind of AI agent that could do some of that for you, and so it really first, it opens up a lot of possibilities for kind of use cases that originally, 10 years ago, may not have been conducive to an RPA solution.
Now, we’re pushing the bounds of what is a good solution vs what is untenable or inefficient. And then I think, a really big one that may not necessarily be AI driven, but the ability for the inputs and outputs of our models to take less constrained shapes, so a big one here is optical character recognition, or using a PDF that’s been printed out as our inputs. You can kind of scan that page and identify names, birthdays, or letters from handwriting. So, you don’t have to necessarily have digital inputs anymore. OCR, or optical character recognition algorithms have gotten really good recently.
I know for our laboratory, one of our most kind of valuable use cases has been taking these requisition forms that may have some handwriting or may look relatively poorly reproducible, and using the newer generation of RPA models to be able to kind of automate and extract that information that may not look the same every time or may not be in the same place every time. And so being able to do that at scale through AI- or OCR-based add-ons to your typical RPA solutions has been really valuable.
Bob Barrett:
Seems like there’s an awful lot of potential here, so how might laboratory set themselves up to best start implementing these tools?
Nick Spies:
Yeah, that’s a really good question. I think the biggest consideration here is that this is a new skill set and we should go into it thinking of it as such. There aren’t a lot of people out there that are really kind of well versed in these tools and how to get them off the ground efficiently, effectively with as little input as necessary.
And so that’s an upskilling that our laboratories will really need to do. How that looks I think is a very much an open question. But, having people that are hungry to learn more, data savvy, tech savvy, and interested in automating some of these tasks that can be life-sucking, especially if you’re doing them all day, every day, it’ll be really good to capitalize on a lot of that tech enthusiasm that we’re seeing and turning it into having series of people that can build these tools and effectively implement them to affect change in the laboratory.
Bob Barrett:
Well, finally Dr. Spies, before we leave here, is there anything our listeners or readers should be aware of?
Nick Spies:
Yeah, one of the big things that we haven’t really touched on quite yet is exactly where these RPA solutions fit into the bigger picture as far as how our laboratories manage the data that we have and generate. And in reality, the RPA solutions are really best utilized when our software solutions can’t talk to each other. And if we do have systems where the infrastructure is in place for all of our software and middleware solutions to interface with each other, a lot of this report generation, a lot of these repetitive tasks, can actually be automated through simple kind of coding scripts and don’t need these fancy higher learning curve RPA type solutions.
Really if we’re talking about trying to get the best bang for our buck as far as handling our data better in the laboratory, a lot of it might actually take the form of building out these big enterprise data warehouses or data lakes, or interfacing all of the systems that we need to get our data from, and not necessarily building out these RPA solutions on top of what is somewhat isolated or siloed environments.
Really RPA solutions can probably be best thought of as a Band-Aid when you need some kind of quick fix before you’re able to implement these more expensive and time-consuming important data infrastructure advances. And so, I wouldn’t necessarily go all in on the idea that everything we need to do, we need to automate with RPA. It should be considered another tool in the toolbox we have. Especially, when we can’t build out the connections that we need to automate these processes in more robust ways.
Bob Barrett:
That was Dr. Nick Spies from ARUP Laboratories in Salt Lake City, Utah. He was an expert panelist in a Q&A article in the June 2025 issue of Clinical Chemistry, summarizing a variety of perspectives on robotic process automation in laboratory medicine, and he has been our guest in this podcast on that topic. I’m Bob Barrett. Thanks for listening.