How HCL Workload Automation Revolutionizes the Insurance Claim Acceptance Process

This is the second part of our four-part series covering how Workload Automation can mimic end-to-end processes on the insurance business side. (Here’s the link to the first part in the series, for your reference.)

Here, we examine the below process and try to mimic it using HCL Workload Automation.

An insurance claim during the acceptance process undergoes completeness checks to make sure all documentation has been submitted as part of the claim. The results of the checks could lead to an email notification being sent to the contact or it could allow the process to go onto the next step.

The next step is if the claim needs to be escalated. The escalation requirement could result in either the escalation sent to a portal for further review and approval.

In case escalation is not needed for the claim case, it would undergo acceptance check and result in the claim set to pending in case some further clarifications are needed or result in claim being accepted and registered into the system.

The data pertaining to the claim form and documentation is already present stored in a Mongo DB and the same is accessed via Docusumo APIs exposed in the foreground, one could also substitute this with an equivalent product like IBM Discovery API, Google Cloud Vision API, etc.

Completeness check of insurance form data:

The completeness check of the insurance form data is performed via HWA job realized as a RESTFUL GET job which would leverage Docusumo APIs to perform a RESTFUL GET operation to get the data from a Mongo DB (where all data resides):

The joblog of this job would be as follows:

This job would also have conditional dependencies to determine if the data is complete:

So, this looks for the keyword “N/A” in the joblog and decides whether the data is complete or if there are missing fields in the scan done earlier from Docusumo:

Completeness Check of Insurance Attachment Data:

The completeness check of insurance attachment data is done via a by making a RESTFUL GET call via an HWA Job into the same Mongo DB serviced via an Internal API running in the background:

The completeness check of documentation data is again validated with conditional dependencies defined at the job level where the string “N/A” in the joblog indicates this data was not available in the scan or is missing, this would result in the condition “NOTCOMPLETE” getting satisfied:

If the “NOTCOMPLETE” condition is satisfied, this results in a mailing job to send notification to the customer via email to intimate him about the missing data.

Email notification job for completeness check of image data (attachment data):

The mail notification job sends a notification out that the documentation is not complete:

CLAIM_ESCALATION Job:

This is realized as Unix Job to check if a claim escalation is needed in this case, so the script called evaluates if the value returned is beyond a particular value:

There would be conditional dependencies defined where every Return Code is mapped to “REQ”, “NOT_REQ”. So, depending on the Return Code 5 or 0, the corresponding conditions are passed that is Required and Not Required.

In case escalation is required, SEND_CLAIM_ESCALATION_PORTAL job is called to do a RESTFUL POST job into the Portal such that the Claim is escalated for further approvals to higher Management in case the amount is beyond a particular value.

MAKE_ACCEPTANCE_DECISION Job:

The MAKE_ACCEPTANCE_DECISION job would run either a AWS Lambda Function or Google Cloud Functions to run in a serverless fashion on AWS or GCP where the evaluation is performed using Analytics in the background or in the form of a Google Big Query job or Azure Data Bricks job to check if the Claim can be accepted based on historical data captured from previous trends or a Custom Function written by the Insurance Company or if it is to be put to “pending” or it can be “Not Accepted”.

There would be conditional dependencies defined where every Return Code is mapped to either “ACCEPT”, “NOT_ACCEPTED” and “PENDING”. So, depending on the Return Code 127, 37 or 0, the corresponding conditions are passed.

SET CLAIM PENDING Job:

This job sets the claim to pending in the Mongo DB, so that the claim could further evaluated manually for further checks from the insurance company:

In case “ACCEPT” condition is passed, the claim is accepted through “RESGITER CLAIM” job & a mail notification is sent out via Mailing job to intimate the registration of the claim is completed successfully.

Whole Flow at HWA Side: