Quarter 2 2020 - Volume 25, ISSUE 2

The Small Automation Collective

Dozens of tiny software robots work in harmony with staff and one another.

By Dennis Allen

I am the father of more than 200 bots at Emax Medical Billing. Bots, of course, is short for robotic process automation (RPA) software robots. Some of our bots work on their own, others interact with our staff to save them time and improve accuracy. Some bots work with and talk with other bots. Most of our bots are small with often no more than a few dozen lines of code, and a few are well over 500 lines of code.

We call our bot collective Erica, for Emax Robotic Information Collaborative Agent, and Erica is the most dependable member of our staff. She does repetitive tasks quickly and consistently. She never misspells a batch or file name, and never complains about the office temperature or requests a special-order K-cup flavor of coffee. And she never calls in sick or takes a vacation.

Erica manages our batch control process, does background administrative tasks and backups, provides information to staff on demand, ensures security compliance, processes report files, populates forms, builds client reports, and a lot more. Erica evolved with Emax’s DNA, and because of that, she is not for sale. Your bot needs will be different, and for that reason you will need to build your own bots.

As it turns out, though, bots are not that difficult to create, and there are several automation platforms with which to make them. We use a program call Macro Express Pro, which we have been using in various versions for over 20 years. Its power is veiled by a simple user interface that requires no programming experience to get started. Other available platforms include WinAutomation, RoboTask, and others. Also new to the party, though not quite ready for prime time, is Microsoft Power Automate, which shows great promise. There are also enterprise-level platforms available, though they are typically tailored for large IT departments. The point is, even if you do not have a large IT department, you can create your own bots for your RCM company.

It was never my intention to create Erica. In the beginning, I just needed a way to automate a couple of tasks and—this was back in the early days of electronic claims—scrub a text file so that our clearinghouse could accept our claims. To be clear, I am not a programmer, and I have never played one on TV. What follows are some of the lessons I learned—mostly the hard way—over the years while creating Erica. Even if you have never written a single line of code, you can create a bot for your RCM company, and this article is written with you in mind. If you, on the other hand, have the resources internally or can hire coding talent to create bots for you, consider this as background material that may help you with your project discussions.

Start With Simple Code
I learned this from Mike Maples, who was better known as the “adult in charge” as member of the four-person Office of the President at Microsoft until 1995. Mike was 20 years the senior of Bill Gates, who had personally recruited him from IBM. According to Mike, to evaluate the skills of a programmer candidate who had passed a gauntlet of interviews, Microsoft would ask them to solve a problem by writing a small program in a limited time. If the code looked okay, the candidate would be asked to make the program run faster. When the candidate passed that test, the candidate would be asked to make the program look prettier. Not only was it a successful way to evaluate software talent, it turned out to be a pretty good way to develop software. The lesson here is don’t try to be fancy. Aim for functionality; there will be time to improve on what you have done later.

Identify one repetitive task where the work is tedious and predictable. Depending on the platform, you can create a bot by first recording your mouse movement and keystrokes as you perform the task. You can then look at the resulting code, delete steps that are not needed, and add in steps that are needed. This is a great way to learn the logic of creating a bot. As you get more comfortable, you will want to skip the recording process and write the code from scratch. The process is straightforward.

Also, force your bot to run slowly during the creation and testing phase. When things work well slowly, speed up the process gradually while watching for errors. Most bots can perform tasks faster than the program or website with which it is interacting. So, program your bots to run slowly at first. Tweak for speed later.

Remember That You Are Human
Document your code or scripts so that anyone—including you—can modify the code later. In the early days, I did not always document my code, because I was in a hurry to get the process automated. Invariably, when something changed in the environment and the bot needed to be updated, remembering the purpose of all the lines of code was impossible. Each time I had to relearn what I had done before; it was like recreating the bot in reverse order. A bot always remembers it code, but you may not.

Also, be sure to name your bots. When I was in my 20s, I opened a Radio Shack near NASA’s Johnson Space Center in Houston, Texas, where I got to know several space shuttle engineers. They always gave personal names to computers, so that when the computers talked to on another (that is, exchanged data), the process was easy to follow. Instead of Computer A, B, and C, it was something like Bill, Ted, and Alice. For example, Bill would do a calculation and ask Ted if he got the same result. If Bill and Ted disagreed, they would go to Alice to resolve the difference. We think like humans, and naming your bots will help you keep track of who (that is, which bot) is doing what.

If any of your bots interact with a user, then teach that bot to talk to the user. Use dialog boxes to ask for input or provide a helpful hint. Think about what question the user might be thinking and try to answer it preemptively in a dialog box. Similarly, if a bot’s purpose is to do something destructive, always seek confirmation from the user before, say, deleting that file folder of unposted patient payments. And always provide a way out for the user. For example, if one of our users generates a batch name incorrectly, say it was marked as “payments” when it should have been marked as “charges,” Erica can remove the batch name from our tracking system. Before doing so, though, Erica forces the user through a two-step process to ensure the user wants to make the change. The user is given a clear choice to either cancel or continue with the deletion. And in case you are wondering, Erica also records the deletion for audit purposes.

Let Your Bots Use Tools You Already Have
Use application macros when available. Many applications provide their own automation, usually called scripting or macros. Use those native macros when possible. Why? Chances are, you can accomplish a specific task faster and easier using the native macro. But don’t stop there. Use a bot to call and manage those native macros to control a complete process. For example, one of Erica’s bots produces a report for clients using a combination of its own file manipulation capabilities, Excel’s native macros, and functions performed by an Excel add-in. The bot manages the entire process, including prepping and manipulating the source data, importing it to Excel, and calling the varied macros and functions to produce the final report.

Consider using Rich Text Format (RTF) files for creating or populating forms and letters. RTF allows you to incorporate formatting using a plain text file. The result can be later opened in Microsoft Word, Outlook, and Adobe Acrobat Pro. If you do not know how to create an RTF file, no worries; just export an existing document to an RTF file. Then your bot can use that file to replace or substitute data to generate a new custom document. Erica uses RTF, for example, when she assigns a batch name for incoming paperwork to be scanned. She creates a scan cover page with barcoded indexes, which our scanner reads and our document management system, eBridge, automatically populates in its index fields.

Use the Windows registry to store and retrieve information. You may have never heard about the Windows Registry; if you have, it was probably that you should never ever touch it or your computer would stop working. The Windows Registry is a storage place on a computer that keeps information needed by the computer and applications. When you create a bot, you are creating an application. So you, too, should use the Windows Registry in the same way. We use it mostly to store information one bot needs to pass along to another bot. The platform you use should provide basic instructions on writing to and reading from the Windows Registry. For example, if your billing system does not track time spent by client, consider creating a bot that wakes up whenever a user opens or switches to a client’s data. Record the specific client and the time started in the Windows Registry. Then, upon switching to the next client, grab that stored information, calculate and record the time spent with the first client, and start all over again with the next client. All of this can be done with little or no interruption to your user.

Treat Your Bots Like Employees
Whenever something related to a bot’s task changes, take time to instruct your bot on the change—just like you do with an employee. Always remember that bots only know what you teach them. How often must you retrain a bot depends on its function. We have bots that look up allowable amounts for Medicare or calculate the allowed amounts for an ambulance transport, and those bots have not changed for years. Yes, new data files are added each year, but the bot’s original code is the same. At the other end of the spectrum, we have bots that manipulate websites to get information, and those get changed every time the website changes.

Make your bots accountable by having them report their success or failure. Although bots will faithfully execute your instructions, they do not always succeed. Maybe a website was redesigned, and the location of buttons and links were changed. Maybe Windows 10 decided to do an update that interfered with the bot’s mission. Or maybe that last application you installed is a CPU hog, and now the computer does things more slowly than the bot expected. Unless the bot reports back to you, you may not know that an important function failed. So have your bots tell you what they did. If a bot’s mission is to download files, have it record how many it files it found, the file sizes, how many it downloaded, and what time it happened. If the bot encounters an error, have it record the error. Then, to prevent you from reading dozens of successful reports a day, consider having another bot evaluate those reports and send you an email regarding only the suspected failures.

Don’t Get Bogged Down
Avoid reinventing the wheel. If there is a function that several bots need, create it once as a separate bot that other bots can call. For example, several of Erica’s bots perform processes that are replicated for each of our clients. Rather than coding each bot to look up client information such as NPI, tax ID, etc., we use a separate bot that only looks up client information and returns it to the bot that made the request. With the information in hand, the requesting bot can continue its mission.

Don’t waste time trying to automate a function that requires knowledge you don’t have. Hire a programmer to write a script just to perform that one difficult function, and incorporate that script in your bot. For example, one of Erica’s bots had to perform several functions that resulted in either creating or marking complete shared tasks in Microsoft Outlook. The bot needed to work on multiple workstations, but performing the task using the Outlook user interface would have been disruptive to users. The solution was for the bot to communicate directly with Outlook using VBScript. Unfortunately, my knowledge of Outlook’s VBScript was limited. I turned to Freelancer.com to find a skilled VBScript programmer to write what turned out to be 16 lines of VBScript code. My cost was only $130, and now the bot does an awesome job of creating and marking complete dozens of shared tasks every day.

Use Bots to Perform Background Tasks
I especially like background bots, because they work without any interaction. One of Erica’s bots does nothing but watch for Excel’s macro file to change and then shares the new or changed macro with other users immediately. Another bot watches the folder that contains 837 files (claims). When a new file is created, the bot immediately stores a backup copy in the appropriate folder. Our users never have to remember these tasks, because Erica does it for them.

Another background task Erica does helps with our security. We expect our users to remember to remove their USB startup key after their system boots up. Leaving the USB key in is a security risk, but even the most conscientious people sometimes forget. Erica has a bot whose only job is to check that the user has removed their startup USB key from the computer. If the key is still plugged in after startup, Erica nudges the user to remove it and click OK. If the user clicks OK, but the USB key is still inserted, Erica reminds them again, and again, until finally the user is instructed to ask for help. Meanwhile, Erica releases the computer so the user can continue working and notifies me of the issue.

Consider having a bot process text files for you. For example, each day we receive two acknowledgement reports from our clearinghouse, Change HealthCare. One report is the clearinghouse acknowledgement of the claims it received or rejected, and the other is from the payers acknowledging receipt, rejection, or other disposition with claims. Most of the information is positive and requires no further action. However, rejections are another matter. Eventually, those rejections will populate in the Change HealthCare portal, but we prefer not to wait. The reports can be very long, and picking through them to find the rejections is too much work if done manually. Erica, it turns out, is a speed reader that processes the reports in a few seconds to find rejections and create actionable items, separated by client, that can then be routed to the appropriate biller.

Processing a text file is not limited to just linear conversion. For example, Erica processes the address exception file produced by our statement processor, InstaMed. Erica reads the file and creates two separate files that upload into our billing system, HealthPac. The first file is the new address, which updates the patient demographics. And the second file is a text comment that gets attached to the patient account signaling when the address was updated and includes the USPS move date.

Teach Bots to Discover Their Environment
When a bot wakes up (becomes activated), it needs to figure out where it is—and sometimes how it got there—before it can perform its mission. Depending on the platform you use, a bot may make some assumptions about its environment that are not accurate. If you deploy bots to work on multiple workstations, chances are those workstations will be different. Maybe the display is a different size, the system is running a different version of the operating system, or maybe the environmental variables have been set up differently. In the case of different displays, you can program the bot to check the display size and calculate an adjustment before proceeding each time it runs. If your systems vary greatly, then consider programming the bot to check either the computer name or the current username and behave accordingly on that system.

Similarly, do not assume that a bot written to interact with one browser will work okay in another browser. A website often looks similar in either Chrome, Firefox, or Edge. However, a web page may behave differently in each browser. Worse, a button that shows up in one browser may not appear in another browser. Unless you control which browser will be used, the bot will have to check to discover which browser is being used and respond accordingly.

Never depend on information being in the same place on a webpage. Websites frequently change. Sometimes the change is a major redesign, and the only solution is to rewrite the bot to adapt to the changes. It turns out, though, the most frequent type of website change is minor. Often, the text remains the same, but buttons and text become either larger or smaller than before. To avoid reworking your bots for those changes, consider using text as an anchor for a button or field instead of expecting the same pixel location. For example, instead of recording the precise pixel location for an insurance ID field on a payer’s website, have the bot search for, say, “insurance ID” (or whatever text is used), then issue a “Tab” keystroke to activate the corresponding field next to the text.

Also use creative ways to identify screen updates in real time. A bot can, for example, watch for subtle changes in the mouse cursor as it changes from an hourglass to a pointer. Have your bot wait for that change to signal that the website (or application) is ready before proceeding. Or if an area of the screen changes color in step with a process, have your bot monitor the color of a single pixel to recognize a change. We have bots that do that, for example, with eBridge when printing and importing documents. That allows Erica to upload multiple PDF documents by recursing through all the files in a folder with no further human intervention.

Moving Forward
Every RCM company has dozens (maybe hundreds) of repetitive tasks that are well suited to bots. The examples here may provide a springboard for you in thinking about how you can implement RPA bots in your workflow. Again, start with simple repetitive tasks that are tedious and predictable. Keep your code simple, keep human limitations in mind, leverage tools you already have, and treat your bots like employees. Don’t let yourself get bogged down with unfamiliar functions, and reach out for coding help when needed. Take advantage of a bot’s inherent ability to work without direction to do background tasks. And teach your bots to recognize their environment so they can work on all your workstations.

Erica has been a tremendous benefit to Emax, and we cannot imagine working without her. I hope that these tips will help you create your own Erica for your RCM company.

Dennis Allen is a partner at Emax Medical Billing LLC. In a previous life he was editor-in-chief of McGraw-Hill’s Byte Magazine and in charge of Byte Lab and National Software Testing Labs.