We also have advanced analytics capabilities with the same great Copilot experience. Let's take a look. In the process map view, we can see the same end to end insurance claims process which we collated from different sources in use case 1..
To get a better understanding of the process, we can take a hierarchical approach. I can cluster my activities based on stage, which drastically simplifies the process map. I see there are three stages to the claims to.
Settlement process: initial processing, investigation and review, and finally, settlement and resolution. Just like with the base process map, I can see the cases that.
Flow through each of these stages, including the fact that some claims go directly from initial processing to resolution. If I just expand one of these stages, I can see the activities within.
Are either withdrawn or rejected. I can expand all stages, and the process map will show all the interactions of activities within each stage as well as between stages. I can even reduce the complexity of.
The process map by cutting some of the edge cases, which makes the overall process map more easily understandable. On top of the frequency, performance, and rework displays I can toggle for my process map,.
Which was also available in the web dashboard, I also have a financial display, which shows the flow of financial values within the process, including the claim amount and also the cost per event,.
Where I see that the costliest activity is investigation. In addition to the process map, we also have the ability to visualize the interactions between resources of the process, which is very important from.
An auditing and compliance perspective. The social chart view shows me the interactions between various resources in the process, and I see that there's two groups of.
Posts Related:
- How To Add Video As A Background Using HTML & CSS - Live Blogger BlogSpot
- InDesign Beginner Tutorial
- Power BI Beginner Tutorial
Resources that seem to not interact with each other.
Let's find out why. Clicking on each resource, I can see detailed stats about the resource from the perspective of frequency, performance, and rework. I can also see the activities for that resource..Here, I see this specific resource specializes in coverage checks and does that 100 percent of the time. Not only can I see activities for each resource, but I can also look from.
The perspective of any attribute I've adjusted. If I look at the handler team attribute, I can see that this resource is part of Team B. In fact, all other resources that this resource interacts with are also part of Team B,.
And the other group of resources are part of Team A. This is useful information as we dig deeper into compliance issues. For identifying compliance issues, I can ask my Copilot for help..
I can ask it about critical activities within my process I should be checking for from a compliance perspective and it is able to provide a list of activities in my specific process, many of them being check activities like policy coverage,.
Fraud checks, etc., as well as handler assignment investigation. Because our Copilot combines the most advanced large language model with specific data from your process,.
It is able to provide insights that combine both elements. With these insights from Copilot, I can now use our comprehensive filtering capability to find.
Non compliant claims where these crucial activities did not occur before settlement. I will start by filtering only for cases which have been settled. Then I can use the sequence filter to find instances.
Where critical compliance activities did not occur before settlement. One very useful feature of the app is that it dynamically calculates how many cases will be filtered based on the given filter conditions..
So I can see immediately that there are
132 cases where handler was not assigned, and investigation was not conducted. Back in the process map, I can look at the filter process flow for.Those 132 cases and assess the impact by looking at the total amount paid for these non compliant cases, which amounted to 43.2k. Let's continue. We can go back to filter.
And keep going down the list of key activities Copilot mentioned, and keeping an eye on the bottom to see if the number of cases is greater than zero. Luckily, no issues with fraud checks and covered checks,.
But we did find that there were 212 settled cases where FNOL, or First Notice of Loss, fraud and duplicate checks were not conducted. These cases represent 73.2k in.
Financial impact and sum to over 100k when combined with settlements without investigations. If we switch over to the social chart, we can see that there's a concentration of.
Resources that are involved in these non compliant cases. Looking at the activities, we can confirm that they are conducting various compliance checks within this process. These are really amazing actionable insights.
Where through Copilot and advanced filtering, we were able to identify specific claims and specific resources that were resulting in compliance violations. To continue with our compliance investigation,.
We will shift focus more to the financial side and look at the linked process that drills into the settlement to payment activities, which is mostly coming from the SAP system..
We see that in this process, we start with settlement and record creation, then the corresponding invoice document creation, approval, and finally payment processing. Let's start by looking at segregation of duties,.
Which is an important compliance gate on the financial side. The goal here is to ensure that the individual creating the settlement doc and the individual approving payment.
Is not the same person. In using the built-in conflict of interest filter, setting these two activities and checking for resource, we're easily able to detect 165 cases where this is a violation..
We can view the filtered process map and filter for the amount as before, and here we can see that a whopping 594k worth of claims were paid without noticing this conflict of interest..
We can create a view for this issue as well as other compliance issues we discovered so we can monitor and report on it using Power BI. Finally, let's look at late payments..
For insurance companies, timeliness of claim processing and payment is very important from a compliance perspective, and failure to comply may lead to damage to reputation, fines, and other legal repercussions..
In order to understand which claims were paid late, we can leverage the app's robust custom metrics capabilities. By comparing the due date set in the system with the due date of the process payment activity,.
We can create a new case level metric that is able to identify all instances of on-time and late payment. In addition to investigate late payments, we should also ensure that we only look at cases that have finished and are not running,.
Which may eventually be paid to ensure accuracy of our analysis. This is also very easy with the built-in case categorization feature. By filtering the end activities,.
We can see that 70 percent of cases have finished. Now we can filter for cases that have finished and are marked as late payment using the metrics filter, and save both late payment cases and on-time payment cases as views..
With both views, we can now leverage Process Compare to help us understand the differences between late and on-time payments. In the Process Compare tool, we can choose the late payment view.
To compare with our on-time payment view. In the output, the green activities and edges are those that are shared across both views. While the red is only present for late payments. We see that three claims were.
Late because it required reapproval, but it represents an edge case. Absolute numbers are not very useful here, so let's look at percentages instead. Now we see something interesting..
While the frequency of other activities is not very different between late and on-time payment, late payments have a much higher frequency of escalation at 54 percent. Drilling in, we can see that there.
Is a much higher likelihood of escalations, 68 percent for late payments versus 14 percent for on time. This is a great insight, but escalations are not something we can simply avoid,.
And there are various reasons why escalations occur. What we really want to do is predict whether a claim will be paid late. Let's ask my assistant on what to do. Copilot recommends a variety.
Of actions to assist in our goal. Some of them we've already done, but it also recommends doing a root cause analysis and then building a predictive model using.
Historical payment data as training sample. This is great. Let's start with Root Cause Analysis, or RCA, on finished cases. I can select late payment as my metric and only the influencing factors for my data,.
And RCA shows me that region is the most influential factor, where a subset of 30 regions account for the majority of late payments. In addition, I can look at.
Other influential factors like claim type, where one specific claim type is causing more late payments than others. I can also continue to drill into other influential factors..
Within those 30 regions, lower amounts actually contribute to higher likelihood of late payment. Now that we have a good understanding of the influential factors,.
