Uploaded by Hitman

Professional Liability Claims Handling System Class Diagram

advertisement
Modeling a Professional Liability Claims Handling System
Using the Unified Modeling Language
Abstract
This article presents a professional liability claims handling system modeled using the Unified
Modeling Language. The Unified Modeling Language (UML) is the object-oriented modeling
created by Grady Booch, Ivar Jacobson, and Jim Rumbaugh. A professional liability claims
handling system tracks claims, payments and the people and organizations involved with the
claim. This paper demonstrates the strengths of UML by modeling the professional liability
claims handling system.
1
Modeling a Professional Liability Claims Handling System
Using the Unified Modeling Language
Introduction
During the decade of the nineties several object-oriented methodologies and their notation were
introduced. The most prominent methods were Booch [Booch-94], Object Modeling Technique
(OMT) [Raumbaugh-91], and Object-Oriented Software Engineering (OOSE) [Jacobson-92].
Each method had strengths and weaknesses. Unified Modeling Language (UML) extends the
combination of these methodologies and has been adopted as the standard object-oriented
specification language by Object Management Group (OMG).
Object Oriented Modeling using UML
UML is defined as a language for specifying, visualizing, and documenting the artifacts of a
software-intensive system [UML97]. It is a graphical notational system that uses a variety of
modeling diagrams for capturing knowledge about an environment and expressing knowledge
about the environment for communication purposes. UML is composed of class diagrams,
sequence diagrams, state diagrams, collaboration diagrams, and use case diagrams. Most of
these diagrams may be applied throughout the entire software lifecycle. The tools that are
discussed in this article include class diagram, state diagram, and use case diagram.
Professional Liability Claims Handling System Overview
A claim is defined as any civil action, suit, proceeding or demand by any person or entity, other
that the insured, seeking to hold the insured responsible for monetary damages. The damages are
the result of a wrongful act actually or allegedly committed by the insured or by any other person
for whose wrongful acts the insured is legally responsible. [Fireman-96] A claim has four states:
incident, open, closed and purged. An incident is any occurrence that the insured believes may
become a claim and reports to the insurance provider. The incident is purged if no claim is filed
before the statue of limitations expires. A claim is opened when a claim is filed. The claim is
closed if a the case is dismissed, a settlement is reached, or a judgment is awarded. A closed
claim can be reopened. Purging of closed claims occurs after seven years.
All insurance claims involve two parties, the insured (the first party) and the insurance provider
(the second party). Professional liability claims also involve a third party, the claimant. The
insurance provider makes payments, usually to the claimant or his legal representative. [Malecki86]. An adjuster is in charge of each open claim. A defense attorney working for an attorney
firm is also assigned to each open claim.
Reserve amounts are assigned to open claims. The reserve amount is the estimated worth of the
claim. Adjustments are made to the reserve amount over time. The reserve amount minus the
amount of payments made equals the reserve balance. There are multiple reserve types
including legal reserves to pay legal expense and settlement reserves to pay settlements or
judgments.
2
Claimants, attorneys defending the case, and others, all receive payments. The system must
compute the amount of money available to pay claims before it can make payments. Many layers
compose an insurance policy. Each layer contains limits of liability that are contractually
predetermined. Three types of limits exist. The maximum paid to a single claimant is the
claimant limit. The maximum paid on a single claim is the claim limit. The maximum paid to a
single policyholder is the aggregate limit[Launie-86].
The Class Diagram
The class diagram represents the static, structural, “data” aspects of a system. Typical
information in a class diagram includes classes, associations, and inheritance. The class
represents entities with common characteristics or features such as attributes, associations, and
operations. In UML, a class is depicted as a compartmentalized rectangle.
Class name
Attribute:
Operation:
The top section of the rectangle contains the name of the class. The middle
section contains the structure of the class or a list of its attributes. The final
section contains the behavior of a class or its list of the methods (operations).
Associations represent relationships between objects in associated classes. In UML, an
association is drawn as a line connecting associated classes. Multiplicity defines the number of
objects that participate in the given relationship. The multiplicity of the association is shown
below.
1
One and Only One
Class
0..*
0..1
1..*
Class
Many (zero or more)
Class
Zero or one
Class
One or more
Class
Exactly one, two or four
1,2,4
Inheritance represents relationships between classes where a subclass shares the structure and/or
behavior of one or more classes or superclasses.
3
Superclass
The superclass has two subclasses, sub class 1 and
subclass 2. The two subclasses are mutually
exclusive.
Subclass-1
Subclass-2
Professional Liability Claims Handling System Class Diagram
The class diagram for the Professional Liability Claims Handling System is shown in Figure 4.
The diagram does not include any information not directly related to the tracking and paying of
claims. For example, provisions for billing policyholders are not included.
A list of the objects used in the class diagram is given in the following table:
Stakeholder
State history
Person
Organization
Policy
Layer
Reserve Type
Claim
Defendant
Claimant
Reserve
Adjustment
Payment
Any person or organization that has an interest, or ‘stake’, in the business or
system is a stakeholder. Claimants in an iclaim are either a person or an
organization. Named defendants are also either a person or an organization.
Handling both of these situations is very easy with the stakeholder object.
Claims go through many states including incident, active, and closed. In
some cases, the claim switches back and forth between states. The State
history object tracks the date on which a claim enters each state.
A person is a subtype of stakeholder.
An organization is the second type of a stakeholder.
An insurance policy purchased by either a person or an organization.
One or more layers combine to make an insurance policy.
Reserve types include: Legal Fees, Legal Costs, Settlement Costs. Reserve
types are grouped under each other. For example, Legal Fees and Legal
Costs may be grouped under Legal Expenses.
The claim object contains either an incident, open claim or closed claim.
The defendant object resolves a many to many relationship between a claim
and a stakeholder. Each stakeholder is a defendant in zero or more claims.
Each claim has zero or more defendants.
The claimant object resolves a many to many relationship between a claim
and a stakeholder. Each stakeholder is a claimant in zero or more claims.
Each claim has zero or more claimants.
A reserve adjustment changes the amount of money that is set aside to pay
expensed for a claim. A reserve adjustment may be for zero or one
claimant. A reserve adjustment is for one reserve type.
A payment is an exchange of money between two stakeholders. A payment
may be to zero or one claimant. Each payment is for one reserve type.
4
Stakeholder
Pay To
Address
Phone
Receive From
Policy Holder
Insurance Provider
Policy
Person
Organization
Policy limit
Per claim limit
Per claimant limit
Eff ective Date
Term Date
Insurance Co.
Stakeholder is
Defendant
Prefix
First
Middle
Last
Suff ix
DOB
Legal Name
Common Name
Policy Eff ective
Policy Term.
Money Exausted
Attorney Firm
Claim under Policy
Policy Layer
1+
Staleholder is
Claimant
Claim
Adjuster
Attorney
Defendant
Defendant for
Claim
Notes
State History
Claim Number
Description
Notes
1+
Claim
States
New Claim
Incident to Claim
Claim Closed
Claim Reopened
Claim Purged
Layer limit
Per claim limit
Per claimant limit
State Change
Date
Policy Eff ective
Policy Inactive
Money Exauhsted
Payment f or Claim
Rsrv Adj.
for Claim
Claimant f or
Claim
Layer
Reserve Type
Reserve type limit
Claimant Limit
Single Claim Limit
Claimant
1+
Reserve Types
of Layer
Layer Active
Layer Inactive
Money Exauhsted
Notes
Reserve Adj.
For Claimant
Payment for Claimant
Reserve Adj.
Payment
Amount
Date
Notes
Reserve Type
of Payment
Amount
Notes
New Payment Req.
Req. Approved
Req. Denied
Req. Canceled
Check Cut
Payment History
Status Change
Date
5
Payment
States
The State Diagram
The state diagram represents the temporal, behavioral, “control” aspects of a system. It shows
the different states that an object goes through in it’s life, events that are experienced by the
object, and the behavior of the object to an event. A state is displayed as a rounded rectangle.
State
A transition from one state to another caused by an event is depicted as an arrow.
State 1
event
State 2
Finally, the initial state is shown below.
Initial State
The Professional Claims Handling System State Diagram
The state diagram for the Professional Claims Handling System is depicted in the following
figure. The diagram does not include all of the objects from the class diagram. Each excluded
object had two states, Exists and Deleted. The included objects are Claim, Policy, Layer and
Reserve Type.
The Claim object has four states. Its initial state is an incident or open claim. An object in the
incident state becomes an open claim, or after the statue of limitations has expired, object
transitions from the incident state and becomes a purged claim. An open claim becomes a closed
claim if it is closed, settled, or if a judgment is awarded. A closed claim becomes an open claim
if it is reopened. Otherwise, a closed claim becomes a purged claim after seven years.
The Payment object has four states with the initial state being payment request. Upon approval,
the payment request becomes a payment pending. It becomes a Payment Made after the check is
cut. If the payment request is canceled, or the request is not approved, it becomes a canceled
payment.
A Policy object, which begins as a new policy, has three states. The Policy becomes active after
the effective date of the policy. The Policy becomes inactive after the termination date of the
policy, or all funds have been exhausted. The Layer and Reserve Type objects have the same
states as the Policy object.
6
Claim States
Payment States
Request f or
Payment
Incident
Request
Approved
tue
Claim filed
Sta
Re
of
lim
Re
que
que st D e
nie
st C
d
anc
ele
d
ita
n
tio
s
Open Claim
Payment Pending
ledPay ment
ve n
Ye
ar s
Check Cut
Canceled
Reserve Type States
Policy Active
Reserve
Type
Inactive
7
e
Term Dat
tive
tive
Layer Inac
Policy Inac
Layer
Inactive
Money E
xhausted
Reserve Type
Active
Money E
xhausted
Layer Active
Money E
xhausted
Effective Date
New Policy
Layer Active
New Reserve Type
Policy States
Policy Effective
New Layer
n ce
Payment
Made
Closed Claim
Layer States
Ca
Se
Reopened
Closed
Claim
Purged
R
e st
equ
Policy
Inactive
The Use Case Diagram
The use case diagram documents the “functional” aspects of a system from the users point of
view. It specifies the results of operations without specifying how or when they are done. A use
case diagram contains processes accept events from actors of the system.
A use case is depicted as an elliptical circle. The name of the use case is
inside the circle.
A flow is a line with an arrow on one end. It represents communication
between the actor and the system. We label our communications to better
understand the diagram.
An actor is shown as an stick figure. The name of the actor is given
immediately below. The actor stimulates the use case with system events. It
is an active object that drives the state diagram by producing and consuming
values.
Process
Data
Actor's name
The Professional Claims Handling System Use Case Diagram
The use case diagram for the Professional Claims Handling System is on the following page. On
this example, all data stores have been collapsed into one symbol called Data Bases. The
diagram contains four processes: File Claim, Pay Claim, Adjust Reserves and File Incident, and
three actors: Adjuster, Claimant and Insured.
8
Request
Payment
Adjuster
Re
qu
Release
tA
Pay claim
en
ount
m
st
Payment am
t
Limits
Payment history
u
dj
Check
Claim
es
Claimant
Limits
Claim info
Data Bases
Incident report
File incident
Insured
s
Reserve
Current
ent Info
Adjustm
Adjust Reserves
Incident info
Notification of claim
File claim
Conclusion
Unified Modeling Language has unified the best of Booch, OMT, OOSE and other
methodologies to produce a standardized modeling language. UML’s class diagram is complete
and understandable. Its state diagram, which identifies the required methods and states, is
straightforward. The use case diagram has allows one to comprehend how data and external
users affect the behavior of a system. Overall, UML has made it easier to specify, visualize, and
document a software system.
9
References
[Alhir-98] Sinan Alhir. UML in a Nutshell. O’Reily & Associates, Inc., 1998.
[Booch-94] Grady Booch. Object-Oriented Analysis and Design with Applications, Second
Edition. Addison-Wesley, 1996.
[Firemans-96] Firemans fund insurance policy, form C22016.
[Jacobson-94] Ivar Jacobson. Object-Oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley, 1994.
[Launie-86] J.J. Launie, J. Finley Lee, Norman A. Baglini. Principles of Property and Liability
Underwriting. Malvern, Pennsylvania: Insurance Institute of America
[Malecki-86] Donald S. Malecki, et. al.. Commercial Liability Risk Management and Insurance
Volume I. Malvern, Pennsylvania: American Institute for Property and Liability Underwriters
[Rumbaugh-91] James Rumbaugh, et. al.. Object-Oriented Modeling and Design. Englewood
Cliffs, New Jersey: Prentice Hall, 1991.
[UML97] Grady Booch, et. al. “The Unified Modeling Language for Object-Oriented
Development”, Documentation Set Version 1.1, Rational Software Corporation, 1997.
10
Download