The Business Object Model

The business object model is described in Appendix A.

From that diagram we can create the Corticon Vocabulary

Initially there will be a Corticon entity corresponding to each business object in the diagram:

Next we need to model the relationships between the entities:

For example, the diagram shows that a property may be associated with many documents:

This now shows in the vocabulary as

  

After modeling the other relationships we’ll end up with a vocabulary like this:

 

Next we can enter all of the attributes of each business object

This vocabulary can be used by all the use cases.

UML Diagram (generated by Corticon from the Vocab)

 

The Business Use Case

Policy Update

  1. Start with a document that has already been matched to a property
  2. Evaluate document data within its own scope. Collect any business events (exceptions) that need to be manually reviewed.
    1. Do not proceed if business events identified – maybe in step 3.
  3. Evaluate document data in the context of the insurance policy data that has already been linked to the property. Collect any business events (exceptions) that need to be manually reviewed.
  4. Identify whether the document is a Renewal or End-Term Replacement or Mid-Term Replacement or Existing policy.
  5. Make decision on whether to ADD a new insurance policy record OR UPDATE an existing insurance policy record OR Just leave a NOTE on the Property.

Business Rules for Step #2:

  1. If effectiveDate is 180 days in the future then raise event “Verify Dates: effective date too far in the future”
  2. If effectiveDate is 400 days in the past then raise event “Verify Dates: effective date too far in the past”
  3. If effectiveDate and expirationDate are not 1 year apart then raise event “Verify Dates: Term is not 1 year”
  4. If Premium Amount is greater than $10,000 then raise event “Verify Premium: Amount too high”
  5. If Premium Amount is less than $1 then raise event “Verify Premium: Amount too low”

 

Corticon Rule Sheet for Step 2

Rule Sheet Scope

Notice the addition of 1:N associations between Document and Rule and between Document and Event.

Test Case

 

 

Business Rules for Step #3:

If premiumAmount is 10% lower or higher compared to the premiumAmount on the current policy then raise event “Verify premium: Amount too high/low compared to existing policy”

Rule Sheet for Step 3

Rule Sheet for Step 3 (split)

 

Scope

Assuming that “existing policy” really means “current policy”

So the rule sheet only executes if there are no events already attached to the property.

The attribute “isCurrentPolicy” is used to select the current policy.

This attribute needs to be set in another rule sheet.

Determine Current Policy

Test Case for Determine Current Policy

Test Case for Step 3

Test Case for Step 3 (split)

   

Business Rules for Step #4:

Existing Policy

  • Document is identified as Existing Policy if there exists one insurance policy in the policy history with same term and same insuranceCarrierPayeeCode
  • Save the matchedPolicyID for use in step #5

Renewal

  • Document is identified as Renewal if
    • It is not an existing policy
    • effectiveDate same as expiration date of the current policy
    • insuranceCarrierPayeeCode same as that of current policy

End-Term Replacement

  • Document is identified as End-Term Replacement if
    • It is not an existing policy
    • effectiveDate same as expiration date of the current policy
    • insuranceCarrierPayeeCode NOT same as that of current policy

Mid-Term Replacement

  • Document is identified as Mid-Term Replacement if
    • It is not an existing policy
    • effectiveDate falls in between the term of the current policy
    • insuranceCarrierPayeeCode NOT same as that of current policy

 

 

Rule Sheet for Step 4

Two steps are required:

Determine if a document matches an existing policy

Classify the remaining documents

 

Determine Matching Policy 

This compares all documents and all policies to find if an existing policy matches

  

Classify Document

This classifies the remaining documents with reference to the current policy (determined using the rule sheet described earlier)

 

Test Case for Step 4

 

Business Rules for Step #5:

 

Existing Policy

  • If any of the data in any of the fields on document is different from the matchedPolicyID  then Update the existing insurance policy with data from document
  • If the data is same then Ignore, leave a note (?)

Renewal

Add new insurance policy with data from document

End-Term Replacement

Add new insurance policy with data from document

Mid-Term Replacement

Add new insurance policy with data from document

Send a letter to the Property Address

 

 

 

 

Pre Expiration Letters

  1. Identify all insurance policies for all clients, for any coverage type, that are set to expire within 45 days, where a renewal policy has not yet been received
    1. Note that this scenario is not taking action on an incoming document, but rather on the entire set of loans and related data.

  2. Once all policies have been identified, request a pre-expiration letter based on the clients’ criteria.

 

Flood Zone Discrepancy Letters

  1. Start with a document that has been matched to two loans (Client A and Client B) for the same property
  2. Evaluate the document Flood Zone to the loan Flood Zone to determine if there is a discrepancy (mismatch) on either loan.
    1. Evaluate the grandfather flag if there is a discrepancy identified.
  3. Identify if a letter is required for either loan based on each outcome and the clients’ specification.

 

 

 

Design Options

 

Step 4 Classify Document

Business Rules for Step #4:

Existing Policy

  • Document is identified as Existing Policy if there exists one insurance policy in the policy history with same term and same insuranceCarrierPayeeCode
  • Save the matchedPolicyID for use in step #5

Renewal

  • Document is identified as Renewal if
    • It is not an existing policy
    • effectiveDate same as expiration date of the current policy
    • insuranceCarrierPayeeCode same as that of current policy

End-Term Replacement

  • Document is identified as End-Term Replacement if
    • It is not an existing policy
    • effectiveDate same as expiration date of the current policy
    • insuranceCarrierPayeeCode NOT same as that of current policy

Mid-Term Replacement

  • Document is identified as Mid-Term Replacement if
    • It is not an existing policy
    • effectiveDate falls in between the term of the current policy
    • insuranceCarrierPayeeCode NOT same as that of current policy

 

Underlying expressions

Design Variations

Appendix A

Object Model