Case Study: Part 2: Insurance claim acceptance process

​This is the second part of the 4-part series of blogs covering how HCL Workload Automation can mimic end to end processes on insurance business side.

​In this second blog (2/4), we are looking at the below process and trying to mimic it end to end via HCL Workload Automation. Here’s the link to the first Blog: https://www.workloadautomation-community.com/blogs/case-study-insurance-claim-registration-validation-through-hwa incase you landed on this Page via a Search result.

An Insurance Claim during the Acceptance process undergoes checks for Completeness with respect to the Claim Form and also with respect to all documentation submitted as part of the Claim, the results of the checks could lead to Email notification being sent to the Contacts or proceed to 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.
Incase escalation is not needed for the Claim Case, it would undergo acceptance check and result in the Claim set to pending incase 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 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 of the job 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 a 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.

Incase 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:

---

Sriram V, ​Senior Technical Lead
​
I have been working with Workload Automation for the last 14 years , have had a chance to work with 100+ Customers from various industries as an Implementer , SME , India SME in IBM before also getting a chance to directly work on the Product Support Side as a DevOps Engineer on IBM SaaS Offering of the Product ,also had a stint with Lab Services Team developing Conversion Utilities to move from Competition,  have been working as a Technical Advisor on the Product lately on the Tech Sales Side.