Robotic Process Automation in Laboratory Medicine

Since the 1980s, automation has transformed clinical laboratory operations, enabling laboratories to keep pace with growth despite workforce shortages. Automation has become a mainstream application in laboratories of all sizes. While traditional robotic automation technologies have allowed laboratories to streamline manual tasks such as sample processing, loading, and retrieval, automation lags for electronic work flows involving the interface between humans and computers. Robotic process automation (RPA) leverages software “robots” to automate repetitive, rule-based tasks traditionally requiring human input. This technology, based on machine learning and artificial intelligence, is often referred to as software robotics. RPA solutions can now handle tasks such as data entry, form filling, and file movement with speed and accuracy; these reduce human error, improve quality, and boost productivity. In healthcare settings, RPA can provide significant time savings and improved efficiencies by automating tasks such as patient onboarding, medical billing, claims processing, and report generation. This not only enhances operational efficiency but also enhances patient experiences by reducing wait times and error. In this Q&A, we explore how RPA can be utilized in pathology and the potential it holds to digitally transform work flows in clinical laboratories. Our experts will answer key questions about what RPA is, how it can be applied in laboratory medicine, and what improvements are necessary for widespread implementation. What is robotic process automation and what types of tasks are best suited for RPA? Simone Arvisais-Anhalt: Robotic process automation (RPA) is software that enables the automation of repetitive, rule-based tasks by programming software robots or “bots” to mimic human-computer interactions. These bots execute predefined actions with the goal of reducing manual effort, improving efficiency, and minimizing human error. The tasks best suited for RPA: Involve high-volume, repetitive processes Follow well-defined, rule-based work flows Require minimal human judgment Have structured data inputs and outputs Are low risk from a patient safety perspective. Daniel Holmes: Prototypically, RPA software can send keyboard input and move/click the mouse, but modern RPA tools can read and interact with screen contents—images, text boxes, buttons, dropdown menus, and conditionally input and respond to other software applications. Additionally, they can leverage interaction with any software tool such as spreadsheets, databases, scripts, batchfiles, email clients, and application programming interfaces. In essence, if a human can do it, RPA can mimic it if appropriately programmed or configured. The tasks best suited to RPA are those that are repetitive, mundane, and error-prone because they are the easiest to mimic using programmatic work flows of RPA software and most likely to realize quality, morale improvement, and financial benefit. From a risk and regulatory standpoint, the task should attend to purely work flow-related administrative tasks and not have potential impact on patient care. Nicholas Spies: Classic use cases of RPA include repetitive data extraction, routine report generation, and bridging across non-interfaced legacy systems. In theory, any task a human can perform with a mouse and keyboard can be subjected to RPA. Therefore, it behooves us to highlight features of tasks that are poorly suited for RPA. Because most common RPA tools lack the ability to reason or adapt, they are limited to stable tasks that must be performed in the exact same way (with identical inputs and outputs) every single time. If a simple process map cannot be made for a given task, or if that process map contains too many exceptions or edge cases, the task is likely a poor RPA candidate. Additionally, if the task is rarely or easily performed, it may not be worth the effort to build and test the RPA solution. RPA failure modes can also be silent or opaque, making their use in “mission critical” tasks a decision that should not be taken lightly. If the target data is sufficiently structured and interfaced, a scheduled programming script (e.g., python, bash) may provide a more robust solution than RPA. Altogether, RPA can be conceptualized as a set of tools for interacting between disconnected systems in a well-defined, reproducible manner that can free skilled laboratory staff to apply their efforts to more valuable and complex problems. Dustin Bunch: The robots in RPA are not physical, but software “robots” that automate a tedious, repetitive process. You can think of RPAs as a recording of multistep human processes. Macros, used in MS Office products, are an early limited RPA able to record an individual’s process of layout and data manipulation, which is activated at the touch of a button henceforth. The macros code may need cleanup to optimize it, but it is functional if the data input doesn’t change. RPAs expand on this concept with increased flexibility and are not limited to a specific software or data input. Yet, the RPAs are great for repetitive tasks that require no human level interpretations of the results to continue. There are different levels where RPA can be applied. It can be programming assistance using large language models (LLMS) or full data stack applications that require data sources, data integration, data storage, data transformation, data versioning, data governance, and user interfaces. How is RPA being used at your institution or how can it be used in laboratory medicine? Daniel Holmes: In the past we have used RPA to perform isolated, time-consuming and repetitive tasks. For example, we once had to register 2500 anonymized research samples into the laboratory information system, all of which had the same blanket orders. Eighty hours of data entry time had been budgeted for this task, but recognizing that this could be achieved using RPA, we prepared an RPA tool in approximately 3 h that automated the entire login process. We also use RPA to digitize outpatient and out-of-network laboratory requisitions where the RPA software orchestrates interactions with the high-speed scanner, image processing tools (deskewing [correcting the skew], contrast/brightness, and resolution), barcode interpretation, optical character recognition, identification of health record numbers, conversion to PDF, making PDF text searchable, and saving requisitions in a manner that they can be rapidly retrieved by staff as needed. Another department in my institution uses RPA to extract registration information from requisitions to prepare it for data entry. The RPA reads fields from an image of a requisition, validates the contents against existing records, and prepares it for rapid cutting and pasting into registration software. This is an example of an “attended” RPA process where the repetitive work is performed by the RPA, but a human takes responsibility for vetting the final output. Nicholas Spies: Our lab has established a comprehensive enterprise data warehouse that aggregates and archives the most valuable data elements from our routine clinical and business operations into a series of structured databases that serve as the basis for most reporting and analytical tasks. However, RPA is still being used to extract, transform, and load data from sources that cannot or have not yet been interfaced into the data warehouse. So much so, in fact, that we have multiple staff focused on RPA efforts full-time. This team develops, validates, and implements nonclinical RPA solutions that extract courier information from scanned forms, move files between legacy systems, and other simple, rules-based tasks. These investments in RPA have led to noticeable increases in productivity, better data quality, and most notably, improved quality of life for our staff by off-loading these tedious and unengaging tasks. Simone Arvisais-Anhalt: Currently, RPA is being piloted in test environments by individual users to explore its capabilities and potential applications. After the implementation and stabilization of our new laboratory information system, we plan to scope out the deployment of RPA in live operational work flows. Our primary focus will be on using RPA to bridge gaps between disparate software systems and processes that do not seamlessly communicate, such as downloading reports from non-interfaced reference laboratories. Currently, human intervention is required to manually transfer information across these systems. By implementing RPA, we aim to reduce reliance on manual workarounds and improve efficiency in critical work flows. Dustin Bunch: Laboratory RPAs are currently being used to create reports and to reoptimize a machine learning model for staffing. For some reports, data is a combination of structured databases and unstructured data, often text. These reports can be either timed, where they use a scheduler software that executes code at predefined intervals, or action created. An action-created report requires a monitor software that triggers when a predefined action occurs. The action can be a specific result entry or the scanning of a document. Additionally, our machine learning model for anatomic pathology work flow gets updated monthly for changes in ordering patterns and surgeon changes. My team is in planning for improved RPA processes for infectious disease surveillance, cataloging reports from reference labs, and searchability of standard operating procedures. At the institutional level, RPA is being developed to aggregate and transform data, which will be cataloged and searchable in an attempt to prevent redundant aggregation that is occurring independently within the system. What are the resources and tools needed for implementation of RPA in a health system or clinical laboratory? Nicholas Spies: At the highest level, the first step in implementing an RPA solution is deciding which service to use. There are several options with a variety of feature sets and price points. Free, open-source options or trials of commercial products are often worth exploring first. Some institutions may even already have licenses for a particular commercial product in place, making the product selection step much simpler. Commercial solutions have made notable progress in recent years that have allowed them to push back on historical limitations to RPA, particularly as it pertains to flexibility features such as natural language processing or optical character recognition, or the incorporation of artificial intelligence in the forms of LLMs Before getting started, there is often a steep learning curve. There is no shortage of online support tools, forums, or instructional videos available to facilitate user engagement, and commercial products will likely have dedicated staff and training modules worth exploring. Once you’re ready to start building, it behooves you to engage a wide variety of potential stakeholders whose work may be impacted by the solution. This allows you to avoid redundancy in efforts and better understand the task at hand, reducing the risk of unintended consequences downstream. Representation from IT groups is a must at these planning meetings, as often these RPA solutions will require standalone hardware and new software integrations and permissions to perform their desired task. Developed solutions must be extensively tested and validated before implementation. Having a predetermined analysis plan, success criteria, and governance structure will improve the likelihood that your RPA efforts achieve their goals. Simone Arvisais-Anhalt: Successful RPA implementation in clinical laboratories requires the following: Enterprise-supported RPA software: Due to strict cybersecurity standards in healthcare, it is essential to use RPA solutions that meet institutional security policies and have undergone formal IT review. Integration with existing IT infrastructure: The best approach is to leverage RPA tools already approved within the organization, such as those available through enterprise software subscriptions (e.g., Microsoft 365 Power Automate). Governance and oversight: Establishing guidelines for RPA deployment, monitoring, and ongoing evaluation helps ensure compliance and safety. Daniel Holmes: While there are some RPA tools that are open-source, the most feature-rich tools are commercial and so the institution would need to select and purchase access to a tool to be made available. In most contexts, this would involve departments outside of the laboratory per se and end users from many clinical and administrative departments along with information technology would participate in a selection process. Once RPA tools are selected and purchased there needs to be a process for requesting installation, receiving training, establishment of rules for appropriate application, validation, deployment, and downstream support—the robustness of which is obviously related to the scale and impact of the tool. While a thorough exploration of this process is beyond the scope of this short article, the reader should consider that making “robots” with RPA amounts to low-code, no-code software development and so applications in a healthcare environment have privacy, data protection, and regulatory considerations along with the need for attendant sustainability, downtime, and support processes. It is noteworthy that RPA has become sufficiently mainstream that Microsoft Power Automate Desktop version is bundled with installations of Microsoft Windows 11. Dustin Bunch: People are the number one resource and the informatics stack is second. There is standalone commerical RPA software, but invariably when the limits of the software are identified then troubleshooting becomes a valuable skill. In the last 6 years of leading the laboratory informatics and data science groups, project rollouts have continued to improve as we identify new metrics to monitor. Our most useful team addition has been a dedicated project manager. As with any transformational project, truly understanding the project including deliverables and actual on-bench work flows are critical. This requires engaging with hospital informatics and all of the end users. Nothing is more frustrating than spending time and effort working on a useful project to find out nobody is using it due to fixable issues that should have been identified before go-live. From a nuts-and-bolts perspective, I treat my informatics projects the same as I would if I was validating a laboratory-developed test. RPA pipelines are no different. After development, I make a written validation plan with predefined metrics. If it fails a metric, then a new iteration is started. I also work hard on having test systems that can be thoroughly tested without going live and crossing my fingers. It is not always possible to have test systems in place. For those cases, I have extensive day-of validations that need to be performed before go-live. The plan should also include how to cleanly reverse changes to a live system quickly in case the validation fails. At the end of the day, the hardware, software, and work flows are important, but critical evaluation of the process is vital to prevent many problems later. I spend more time planning the validation than I do the development. How can introducing natural language processing and AI broaden the types of tasks that can be automated in the clinical lab? Simone Arvisais-Anhalt: The integration of natural language processing (NLP) and artificial intelligence (AI) can expand RPA applications in the clinical laboratory by enabling automation of more complex, unstructured tasks. While traditional RPA excels at rule-based, structured processes, AI-driven automation can handle tasks requiring language comprehension, contextual understanding, and adaptive decision-making. Nicholas Spies: The most significant barrier to widespread adoption of classical RPA tools was the relatively limited scope of problems they could solve: simple, rigid, explicitly definable processes on relatively well-structured data inputs. Expanding this scope will require tools for reliably extracting information from unstructured input data and combining it with a reasoning logic for flexible exception-handling. Image analysis tools such as optical character recognition (OCR) can aid in extracting unstructured information, while LLMs can allow for a greater degree of flexibility in what can be done with that now-extracted information through more effective NLP. To this end, the more modern commercial offerings focus on expanding beyond typical RPA tasks and into a suite of tools that include more flexibility in a of input data and more As these of business intelligence tools it will likely become more and more for laboratories to on them to perform the nonclinical tasks that are currently performed likely include quality from quality and patient regulatory compliance and or Dustin Bunch: and AI can expand the use of RPA in at the of that downstream processes without human include improved and data recent that LLMs can and code for This can also be applied to the laboratory for improved code times for data and code Daniel Holmes: While to RPA and LLMs some automation where the task we to avoid large of text to find data for some other simple application for which we developed a to standard operating By training a on our using our healthcare we able to make a tool that can be questions do I do if my is this and can respond with a answer with from the appropriate and to the primary PDF document. also reports from pathology where the of the text is of the either or can be to extract features of reports for (e.g., report from many reports, or feature for training or AI the same of process can be applied to from medicine, or and in to What improvements in technology are needed for and implementation of RPA? Dustin Bunch: Currently, RPAs some programming and that are often requiring Due to they are limited in the speed at which they can be It also the RPA is often to be by the end understanding of the RPA between the development and end which development and the is in the of their while the is often to the same language due to being in a different In the RPA in with LLMs will be that end users can RPA data without an understanding of the This will allow the to quickly and engage the hospital laboratory informatics groups with a At that the adoption will become the process required for implementation. Simone Arvisais-Anhalt: in the of use of RPA for end users will laboratory to and automation work flows without extensive IT Additionally, deployment of such as validation and will ensure that RPA is and and as Nicholas Spies: I think we are already a in the of these tools with their incorporation of and likely that as the scope of what can be automated so too will the on for clinical laboratories. the more the most to a need for institutional in working with these tools, and data more the most about the of automation tools is that there is a significant learning that must be before one can start to improvements in and would likely as much adoption as would any feature Altogether, I think a key focus of the modern laboratory should be a in our medical and in laboratory of which RPA and automation will be but not of the Daniel Holmes: I think that the of and implementation is related to ongoing limitations of the my that healthcare are often of that already The healthcare environment is by and in some to respond to are patient and and The is that in healthcare are by for technology applications may not be a It is on laboratory to identify appropriate in their development, information technology, or to applications in their environments and human resource for complex tasks to automation and software. RPA, robotic process large language natural language artificial The takes full responsibility that all on this have the required of for significant to the and of data, or analysis and of or the for final of the and to be for all of the that questions related to the or of any of the are appropriately and for has been from the all the is an for has from and the and from and is on the and for the of and is a of the of has from support to and from in the to is on the for of and in the and of Laboratory has or support from and

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.