Insurance Claim Lifecycle Model

Alpha Insurance Behavioural Model (Questions & Answers) (c) Monique Snoeck

Model EDG to start from

Lifecycle of Claim Case Then the company opens a claim case, makes sure that all the necessary documents are in place and sends it for assessment by different estimators based on their area of expertise. According to the reports issued by the estimators, it is decided whether the claim is approved - then the sum of compensation is calculated and the compensation is paid to the customer s account, or that it is rejected, so no payment will be transferred to the customer. In very rare cases, estimators find that the provided documents are possibly fraudulent. Then the claim is not just rejected, but rejected as fraud, the customer s contract is suspended and the customer is blocked. Blocked clients with suspended contracts cannot submit any claims, get new compensations, or perform any other activities involving Alpha Insurance. In case of a mistake in the fraud accusation, the customer can be whitelisted again: once the fraud is disproven, the claim case is then sent for expertise once again, and the contract is unsuspended. However, after being blocked, not only the claim case, but also the client file has to be assessed again. Sometimes clients forget to send all the necessary documents when they submit a claim, so the claim case cannot be assessed correctly. In such an event, the office clerks retract the claim case documents from the estimators and add the necessary documents to the file. After all the necessary papers are in order, the case has to be resent to the estimators for assessment. Events/States: send/sent approve/approved reject/rejected rejectAsFraud/rejected as fraud disproveFraud/sent or Exists retract / Exists send/sent

Lifecycle of ClaimCase (Model Solution) This cycle is mainly needed to distinguish between incomplete and complete case files. "SendCaseForEvaluation" could also be "MarkComplete", and sending is then a BP Layer task. It should be possible to end Reports, for referential integrity reasons (impossible to end the Claim Case if there are still "life" Reports. If you do not add this event here, then a precondition is required demanding all reports to be ended for the RejectAsFraud event to be accepted.

Lifecycle of Contract After the customer s profile is assessed, a preliminary contract/offer on an insurance product is made to the customer either in person or by email. If the customer agrees to the offer, the contract is signed by both parties. After the signing of the contract, the client enjoys the coverage and is invoiced (monthly or yearly depending on the choice made in the contract) according to the price of the insurance product they bought. Then the company opens a claim case, makes sure that all the necessary documents are in place and sends it for assessment by different estimators based on their area of expertise. According to the reports issued by the estimators, it is decided whether the claim is approved - then the sum of compensation is calculated and the compensation is paid to the customer s account, or that it is rejected, so no payment will be transferred to the customer. In very rare cases, estimators find that the provided documents are possibly fraudulent. Then the claim is not just rejected, but rejected as fraud, the customer s contract is suspended and the customer is blocked. Blocked clients with suspended contracts cannot submit any claims, get new compensations, or perform any other activities involving Alpha Insurance. In case of a mistake in the fraud accusation, the customer can be whitelisted again: once the fraud is disproven, the claim case is then sent for expertise once again, and the contract is unsuspended. However, after being blocked, not only the claim case, but also the client file has to be assessed again. Events/States: crContract/offered sign/signed rejectAsFraud/suspended disproveFraud/unSuspend/un suspended

Lifecycle of Contract Using the " RejectAsFraud" event enforces simultaneous change of states in both lifecycles. The separate "Unsuspend" event can be used to unsuspend a contract once all claim cases are deemed clear. This is then an event that is triggered manually and may have an additional precondition to prevent triggering it erroneously. Do not forget to add end events for all the dependents! QUESTION: What about using a separate event "Suspend" ?

Coordinating Lifecycles Using the " RejectAsFraud" event enforces simultaneous change of states in both lifecycles of ClaimCase and Contract. Using a "suspend" event would require an additional constraint to enforce this, but would allow for more flexibility: if desired, you might keep the contract in the signed state instead of immediately suspending it. Reversely: using the "Disproof Fraud" event to trigger the transition from the suspended state back to the "signed" state, as soon as a single ClaimCase is disproved as fraudulent, the contract would go back to the signed state. In that state, further disprove events are not allowed, causing the system to block if several claim cases are to be disproved as fraudulent. So this solution is far from optimal. Given the fact that a contract may have several dependent ClaimCases, for reverting to the normal state, working with a separate event "unsuspend" makes more sense and is the better solution. QUESTION: What about using a separate event "Suspend" ?

Lifecycle of Customer Events/States: assess/assessed After the customer s profile is assessed, a preliminary contract/offer on an insurance product is made to the customer either in person or by email. If the customer agrees to the offer, the contract is signed by both parties. After the signing of the contract, the client enjoys the coverage and is invoiced (monthly or yearly depending on the choice made in the contract) according to the price of the insurance product they bought. Then the company opens a claim case, makes sure that all the necessary documents are in place and sends it for assessment by different estimators based on their area of expertise. According to the reports issued by the estimators, it is decided whether the claim is approved - then the sum of compensation is calculated and the compensation is paid to the customer s account, or that it is rejected, so no payment will be transferred to the customer. In very rare cases, estimators find that the provided documents are possibly fraudulent. Then the claim is not just rejected, but rejected as fraud, the customer s contract is suspended and the customer is blocked. Blocked clients with suspended contracts cannot submit any claims, get new compensations, or perform any other activities involving Alpha Insurance. In case of a mistake in the fraud accusation, the customer can be considered safe (normal) again: once the fraud is disproved, the claim case is then sent for expertise once again, and the contract is unsuspended. However, after being blocked, not only the claim case, but also the client file has to be assessed again. rejectAsFraud/block/blocked disproveFraud/unBlock/exists (= to-be-assessed)

LifeCycle of Customer (Model Solution) Don t forget this state, only after a customer is assessed, contracts, claim cases, etc. can be created!

LifeCycle of Customer (Model Solution) Claims cannot be created in this state. But it is important to make sure things can be finalized when arriving back in this state after disproofFraud--> end-events of dependents need to be here. After a customer has been blocked, Unsuspending contracts and re-Assessing the Customer can happen in any order. But both are needed to be able to create claims, claim cases, etc. It is important to make sure things can be finalized in this state --> end-events of all dependents need to be here

LifeCycle of Customer (Model Solution) QUESTION: would it also be possible to include the 'RejectAsFraud' event in the state 'assessed' and create a new event 'BlockClient' to transition to the blocked state?

Answer "RejectAsFraud" is owned by the ClaimCase. By using this event in the FSM of Customer to trigger the transition to the blacklisted state, you ensure that as soon as a single claim case is deemed fraudulent, the Customer is blocked. A solution with a second event "BlockClient" would mean that after labeling the ClaimCase as fraudulent, labeling the Client as "Blocked" is a separate action. Of course, one can define a transaction at the UI-level that ensures that both actions are done in one go. But just as well, one could also decide to keep the actions separate, and to have additional or other rules to block a customer. E.g. also block a customer when this person doesn't pay outstanding bills. So: Having one event enforces simultaneous change of states in both lifecycles. Having two events requires an additional construct to enforce this, but also comes with more flexibility.

LifeCycle of Customer (Student Solution) Such cycle mimics the "maximum one" broker cardinality. It is not in conflict with EDG, but unnecessary. Moreover, it would be in conflict with EDG if cardinality is updated to maximum many. ==> not a good idea

LifeCycle of Customer (Student Solution) Making covered or signed a separate state, is not necessary. The FSM of Contract should enforce that the contract is signed before the methods of the claim cases can take place. Additionally, this FSM enforces that a customer can sign a contract only once.

General feedback Acquired methods were often forgotten. In Merlin, you can use the check button to verify that your FSM is complete. The exam is on paper, so make sure to check manually with the OET! Grading: 10 points per FSM for ClaimCase, Contract and Customer (0/10 if this is a default FSM) -5 points from the total in case the other object types have a non-default FSM (except for invoice) Syntax errors (e.g., non-determinism): -3 Other errors: -1 (or -0,5 if only some methods are missing in a transition) OET is not graded, but on the exam, a point is substracted from the overall score if the OET is not OK!

Master objects and object name missing! Testing Fill in the template completely! Positive goal missing Success or fail? Is it always possible? What if the contract is already unsuspended, can it be unsuspended again? -> make clear under which conditions a positive or negative goal is expected to happen Fill in reason for fail and possible fix when outcome fails Minor: goal missing here Negative goal missing

Testing Fill in the template correctly! A negative goal is phrased negatively. This means that the expected outcome is still success Missing negative goal. Outcome filled in incorrectly (should be success/fail)

Referring to a master object that does not yet exist Modifying events on an object which has not yet been created Testing Fill in the template correctly! You cannot start by creating a dependent, you need its master first When you don t have a goal for a row, it was not necessary to say if a goal was satisfied or not OBJECT TYPES != MASTER OBJECTS But when you do have a goal you should say if it was satisfied or not! Not every row has to match with a goal: correct

Testing Fill in the template in a consistent manner! You cannot have failing scenarios and no failing test cases. There have to be at least two failing test cases for Goal 4 since both the positive and negative goal fail. This not being the case means that either: The outcome of the goals is wrongly filled in The outcomes from the test cases is wrongly filled in The test cases do not show the failing goals and are thus inadequate

Testing Be concrete when explaining a fix! adjust FSM Add event, method and new state You are communicating with others, make it clear to help them!

Testing Number of goals identified Very important testing metric If you do not test enough, you will not find any mistakes Ranges from 4 up to 17! Maximum 3 points < 8 goals: 0 points 8-10 goals: 1.5 points > 10 goals: 3 points 0/3 1,5/3 3/3

Testing general feedback 9 out of 25 groups did not submit the testing part! Part 1 has not been graded for those 4 out of 16 (!) remaining groups submitted an mxp which gave errors when using the prototype Test your own model before submitting. Only 4 out 16 groups filled in the template completely and correctly!

Testing - scoring Coverage 3 points Filling in the template completely 0,5 points Filling in the template correctly - 0,5 points Finding a mistake in the model 0,5 points Proposed correct fixes for the mistake 0,5 points Total: 5 points Email with peer reviews and feedback on the review you wrote will be send on Wednesday after the exercise session.