Robotic process automation, or RPA, has dominated much of the automation conversation in the insurance industry for several years. RPA is able to capture manual steps that employees take to log into software, search documents, and enter data and replicate them.
Enterprise insurance firms can thus deploy a “digital workforce” for use-cases in claims processing, underwriting, and more.
In many cases, discussion about RPA and artificial intelligence intertwine, and this can be confusing for insurance leaders looking to automate key business processes at their companies. In this article, we first discuss what’s possible with RPA in key insurance processes.
We also provide readers in insurance with best practices to consider when implementing RPA at their business. We then discuss the difference between RPA and AI and end with a use-case in which AI is used to prepare insurance data from various forms for use with an RPA software: document digitization.
To better understand the myths circling around the conversation about RPA and a brief overview of what’s possible with AI in document digitization use-cases, read the latest white paper from Vidado, an AI-based document digitization vendor.
RPA in Claims Processing
In general, RPA software is good for copying data from one source into another so long as that data appears the same in both sources every time. Claims adjusters are often tasked with collecting relevant information from claimants, hospitals, the police, and other insurers in order to make a decision on whether to pay out a claim and for how much.
Once the necessary records are obtained, the relevant data within them needs to be translated to the insurer’s digital record of the incident. Without automation, claims adjusters would read through all of the records they collected and manually enter the necessary information into the system. In specific cases, RPA can help in this effort.
For example, someone might file an auto insurance claim immediately after their accident while they’re still on the road. In this case, they may need someone to tow their car. Some auto insurance customers pay for roadside assistance.
Traditionally, employees would need to manually input data from a claim about the customer’s accident into the system of a third-party mechanic that has an agreement with the insurance company. RPA software could automate the translation of this data between systems, thus speeding up the time it takes for a tow truck to reach the customer.
RPA could also assist in verifying information located in disparate sources throughout the internet. For example, claims adjusters at a life insurance carrier could use RPA to verify death certificates on various government websites. Auto insurers could check public records for whether or not a claimant was arrested for a DUI or a hit-and-run.
Again, the only way an RPA software would be able to translate the data found on these websites into the insurance carrier’s system is if the data is in the same location on these websites and is accessed the same way every time.
Even if the data is located in the same spot on a particular webpage, if it takes an additional click to navigate to that webpage, the RPA software would need to be reprogrammed.
Similarly, RPA could be used to move data from historical claims records in an insurance carrier’s system into analytics applications so long as the insurance carrier reprograms the RPA software whenever they introduce a new way of storing claims-relevant information.
RPA in Underwriting
RPA has similar applications in underwriting, namely its ability to pool information from disparate sources into a single place. Underwriters need to evaluate the risk that potential customers, their homes, and their cars pose to the insurance carrier. The information they need to do this varies depending on what they need to assess.
An auto insurance underwriter might need to check if a driver has been previously insured and translate information about their insurance history into the auto insurer’s CRM.
Underwriters at larger auto insurers can check if a driver has been previously insured with similarly-sized auto insurers within a shared database. RPA software could do this instead, copying the name of the customer’s insurance carrier into the appropriate spot in the auto insurer’s CRM.
Underwriters also may need to search the Comprehensive Loss Underwriting Exchange (CLUE) database for claims that a customer filed with previous insurance carriers. RPA could log into the CLUE database and navigate to a particular customer’s CLUE report.
Then, it could copy any relevant claims information, including the number of past claims, on the CLUE report into the appropriate spots in the insurer’s CRM.
Similarly, underwriters at auto insurance carriers may need to check if an applicant is eligible for a policy given their criminal record. To do this, underwriters may access public databases for evidence of arrests, charges, and convictions in motor vehicle-related incidents.
As previously discussed, RPA software could translate data from public databases into the auto insurer’s CRM, allowing the underwriter to make a decision about whether or not they can offer the applicant a policy or not faster.
RPA may also have uses in providing potential customers with car insurance quotes. When someone fills out an online form to get a quote from an auto insurer, an RPA software behind the scenes could verify the contact information that person provides against public records databases, such as those for criminal records and the DMV.
This could allow the auto insurer to provide potential applicants with a quote faster, which could increase the likelihood that they buy from that particular auto insurer over its competitors.
Implementing RPA Software in Insurance
We briefly touched upon the need to reprogram RPA software whenever there’s a change in the way it needs to navigate to applicable internal and external data sources, but there is more to consider when implementing RPA.
For example, insurance carriers need to set up protocols for when the RPA software stops working and diagnosing what part of the process it was running changed. Was it a change in a website or enterprise system it was accessing?
Was it a change in the form from which it was intended to scrape data? Someone at the company then needs to be responsible for reprogramming the RPA to run its process given the recent change. This needs to be done quickly to minimize downtime that may affect the ability for multiple departments to do their jobs.
In addition, RPA cannot stand on its own. It requires integration with existing IT infrastructure and legacy systems. Sometimes this infrastructure, these systems, are best changed to allow an RPA software to run its process with the least likelihood of failing due to a sudden change in that process.
In some cases, RPA is altogether the wrong automation solution for a use-case because the process changes too frequently. Automating processes with any level of unpredictability is often best left to artificial intelligence.
RPA Vs. AI: What’s the Difference in Insurance?
To be clear, RPA is not inherently artificial intelligence, but there are RPA solutions that come equipped with AI features. AI comes with the inherent ability to “learn” or improve the accuracy of its output over time and with more data. This is not the case with RPA. Vidado illuminates how RPA’s limitations can in turn limit an insurance carrier:
The truth is the RPA is taking and doing the same amount of work, [it’s] just doing it with a digital worker…It doesn’t necessarily learn or get any smarter about the work it’s supposed to do.
In an enterprise company, you’re always driving for strategic improvements across the board, where you’re facilitating better underwriting or customer service. With a digital workforce, you’re getting a better expense reduction, but you aren’t…driving new strategic value across the enterprise.
RPA may be able to scale certain processes, but it doesn’t improve those processes over time. It also doesn’t adapt to changes in the enterprise and the external data sources and webpages through which it navigates. AI and machine learning, on the other hand, adapt to new data and new systems.
All of the previously discussed RPA use-cases highlight another key difference between RPA and artificial intelligence in insurance. An AI-based search function based on natural language processing (NLP) would likely be able to copy the date the claimant stayed in the hospital regardless of where it existed on the form.
This is because NLP-based software would be trained to find words and phrases within the form that likely correspond to the date a claimant stayed in the hospital and also to copy the date into the appropriate place in the insurance carrier’s system.
As a result, such a software wouldn’t need to be reprogrammed to find this information within the medical records pulled from many different hospitals, and it wouldn’t stop functioning when changes were made to the hospital’s forms and insurance carrier’s system.
Document Digitization in Insurance – Preparing Data for RPA
Aside from searching external data sources, insurance enterprises also require a lot of manual data entry from their employees. Many insurance claims are still filed on paper, which means a claims handler has to manually enter data within that form into the insurance carrier’s system or CRM.
Only once a digital claims form is created can an RPA software start filling the data within it into appropriate places in the insurance carrier’s system.
This is a part of the claims process that is ripe for improvement. RPA alone can’t help with digitizing documents, but artificial intelligence, on the other hand, could play a role in automating this tedious data entry.
Document digitization has been available to insurance enterprises for several decades, but the technology that makes it possible, OCR, has its limits. Traditional OCR software matches a particular set of pixels to a text letter; it’s a rules-based, “if-then” kind of software.
If a particular handwritten letter looks too different from what the OCR software is used to “seeing,” it either won’t translate it into digital text or will translate it incorrectly.
Such a limitation means that an insurance enterprise could only use an OCR solution it procures to digitize specific kinds of forms. It will need employees or outsourced labor forces to enter other forms manually.
According to Vidado:
[OCR] always made companies compromise…[For example], ‘We can only address 30% of the forms that are coming in. The rest will have to be manual.’ It’s lead to a lot of failed projects because [enterprises] have gone in with the expectation of hitting very high accuracy rates across a whole bunch of use-cases, and what they end up with has always been ‘We can be successful with this specific thing…but never at the promise and scale we envisioned.’
As a result, insurance enterprises have outsourced the manual data entry that can’t be handled by an OCR software. Machine vision, a type of machine learning, could be a solution to such a problem.
In contrast to OCR, machine vision software “learns” over time with enough data. What it “reads” as a handwritten “t,” for example, may start out as a specific way of writing a “t,” but as it encounters more and more iterations of how people write “t,” it will start translating these iterations into digital text “t”’s accurately.
In many cases, machine vision vendors offering a document digitization solution have already trained their software to recognize these various iterations of handwritten letters, putting them far ahead OCR’s static ability to read only certain kinds of text, and, as a result, only certain kinds of forms.
A machine vision-based document digitization software like Vidado’s could be trained on thousands of forms of varying types containing numerous handwriting styles and machine-printed text.
What this means is that the software could be more likely to accurately translate an oddly written letter or misspelled word correctly into a digitized form even from forms it hasn’t encountered before.
Vidado’s software can purportedly normalize data such as telephone numbers and dates and enrich data where applicable so that it’s ready for an RPA software to scrape and copy into another system.
This article was sponsored by Vidado and was written, edited and published in alignment with our transparent Emerj sponsored content guidelines. Learn more about reaching our AI-focused executive audience on our Emerj advertising page.
Header image credit: Brett A. Podolsky
