This invention relates generally to data modeling, and more particularly to modeling of insurance product data.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright© 2001, Siebel Systems, Inc., All Rights Reserved.
Various insurance companies and agencies store information electronically in furtherance of their business needs. Typically, individual insurance companies and agencies store insurance related information in their own unique way. For example, a life insurance provider may organize policy related information in a way that is very different from the way that an automobile insurance provider may organize policy related information. Even within a single insurance company, that company may use many different application programs that employ very different schemas and data models. For example, an underwriting program may use a data model that is very different from the data model used by an accounting program. The use of customized data models by an insurance company or agency and by internal applications has the advantage that it allows information to be modeled in a way that is appropriate for the business needs of the insurance company or agency. Unfortunately, because of this diversity in the data models, it is not easy for the insurance company to share its information with insurance agencies or other companies or for internal applications to share their information.
Various attempts have been made to define standard data models so that information can be more easily shared between insurance organizations and applications. However, these data models have not been able to achieve sufficient data integration and simplicity. As a result, insurance companies and agencies have to maintain, support and upgrade multiple different data structures and maps for their products.
The present invention relates to various aspects for modeling insurance product data.
According to one aspect of the present invention, an insurance product class is defined which includes multiple data elements that are common to various insurance product types. Further, several classes derived from the insurance product class are defined, with each derived class extending the common data elements to include data elements that are specific to a certain insurance product type.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
In the following description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
A data model that provides a common data structure to represent an insurance product and allows for customization of the data model in a manner that facilitates upgrading of the data model is described. In one embodiment, the data model defines an insurance product class that includes a set of data elements that are common to various insurance product types. The various insurance product types may include an automobile insurance policy type, a life insurance policy type, a property insurance policy type, an insurance product quote (i.e., a quote for any insurance product type) type, or a type of any other product offered by an insurance company or agency. The insurance product class can be sub-classed (i.e., be a base class for a derived class) depending on the insurance product type. Each derived class includes the common data elements included in the insurance product class and a set of data elements that are specific to a certain insurance product type. For example, for the automobile insurance policy class, the specific data elements may include a list of vehicles associated with the policy, a list of coverages for each vehicle, a list of drivers associated with the policy and a list of coverages for each driver. In another example, the specific data elements of the life insurance policy class may include a list of holdings (e.g., properties or assets) associated with the policy, a list of coverages associated with the policies, and a list of policy beneficiaries and their roles.
In one embodiment, the insurance product class defines various relationships of an insurance product. These relationships may include relationships with related insurance products (e.g., other insurance policies of the same insured, insurance policies of a person related to this insured, etc.), relationships with parties participating in the insurance product (e.g., drivers, homeowners, benefactors, etc.), relationships with insurance product producers (e.g., insurance agents, underwriters, etc.), relationships with payment plans (e.g., an automatic monthly deduction from a bank account, etc.), etc. The data model models the relationships as attributes associated with an insurance product. In one embodiment, the data model is specified using a schema language such as XML Schema.
In one embodiment, the data model defines a hierarchy of the data elements for describing an insurance product. The data model may define data elements that are complex. A complex data element is a data element that comprises data sub-elements. For example, an address data element may be a complex data element that includes street, city, and state data sub-elements. The data model may specify custom data elements at various places within the hierarchy of data elements. A custom data element is of a custom data element type. The custom data element type initially defines no data elements. The data model can be customized by defining custom data elements that are specific to different applications or systems. For example, the data elements of the insurance product class may have a custom data element for a premium discount code, or the data elements of the automobile insurance policy class may have a custom data element for the date of the most recent incident of the insured. Because the custom data elements are defined at various places within the hierarchy, the customizations of the data model can be associated with related data elements within the hierarchy.
Accordingly, a common data model representing various insurance product types allows the insurance organizations to maintain, support and upgrade only a single data model and provides for efficient data transformations and mappings. In addition, the existence of custom data elements at various levels of the data model's hierarchy simplifies the customization of the common data model.
In one embodiment, the common data model 104 defines a hierarchical data structure representing an insurance product. This hierarchical data structure includes data elements that are common to all business systems 100. In addition, the hierarchical data structure includes data custom data elements at various levels of the hierarchy to define data fields that are specific to each business system 100, thus providing for easy customization of the common data model 104.
In one embodiment, the universal business application network 102 uses the XML and Web services standards.
The transport layer 216 is a mechanism through which business information is exchanged between the business systems 204 and the business integration server 200. Each business system 204 may have an adapter 202 that is appropriate to the protocol of the transport layer. For example, the transport mechanism may use communications protocols such as TCP/IP. The transport layer 216 may provide a messaging service for queuing, for guaranteeing delivery of messages, and for handling both synchronous and asynchronous messaging. The adapters 202 relay events from the business systems 204 to the integration server 200 and can import configurations of the business systems 204 into the integration server 200. In addition, the universal business application network may include encryption and authentication mechanisms to ensure the security and integrity of the information. For example, authentication will help ensure that a business process is accessing the intended business system, rather than an impostor business system.
The integration server 200 stores the representation of a data model 210 (e.g., in an XML schema file) that contains the definition of an insurance product class and the definitions of derived classes for various insurance product types such as an automobile insurance policy type, a life insurance policy type, a property insurance policy type, an insurance product quote type, etc.
The transformation store 212 contains a model data definition tool (e.g., an XML schema definition tool) to create a definition of the data model 210 (e.g., in an XML schema file) and to customize the data model 210 when requested by adding custom data fields to the data model 210. The transformation store 212 also contains transformations for transforming information received from the business systems 204 to the format used by the data model 210, and vice versa. For example, an automobile insurance policy class may include a globally unique identifier for each automobile insurance policy. A transformation for a business system that does not use globally unique identifiers may need to access an identification server to determine the globally unique identifier for each automobile insurance policy. The transformations may be specified as a computer program, an XML Stylesheet Language Transform (OXSL TO), etc.
The business process store 208 contains the business processes that have been defined. A business process may be specified as a script, a process flow, an executable program, etc. In one embodiment, the business processes are defined using the Web Services Flow Language (OOWSFL). The business processes orchestrate a sequence of steps across multiple applications provided by the business systems 204 to achieve a business objective.
The business process controller 206 coordinates the execution of the business processes. The business process controller 206 may instantiate derived classes and invoke functions of the resulting objects in accordance with the various business processes. The business process controller 206 may also initiate the execution of business processes based on predefined conditions and events. For example, the business process controller 206 may launch a certain business process each time an alert is received. Although not shown, the business integration network may provide a standard library of business routines that may be invoked by the business processes. For example, a standard business routine may identify whether two policy objects are related via participating parties and create a relationship between the two policy objects if they are related. The integration server 200 may also include various tools to facilitate the development of business processes. These tools may aid in the development of transformations, the defining of classes, and the writing of process flows.
Referring to
Next, processing logic identifies the insurance product type of the insurance product data sent by the source system (processing block 304). The insurance product type may be the automobile insurance policy type, the life insurance policy type, the property insurance policy type, the insurance product quote type, etc.
At processing block 306, processing logic transforms the insurance product data into a common format provided by a corresponding insurance product type class of the insurance product data model. Insurance product type classes are derived from the insurance product class that includes data elements which are common to all insurance product types. The common data elements define relationships of the resulting insurance product object with other objects such as other insurance product objects, objects of parties participating in this insurance product, objects of producers of this insurance product, etc. In one embodiment, the relationships of the insured product object are created during the transformation based on information received from the source system. Alternatively, the relationships may be created by designated business processes (e.g., business processes stored in the business process store 208) after the transformation.
Further, processing logic transforms the insurance product data from the common format into a format recognizable by the target system (processing block 308) and sends the resulting insurance product data to the target system (processing block 310).
Thus, according to the process 300, the sharing of insurance product data between two insurance applications does not require data mapping between the data format of the source application and the data format of the target application. Instead, the mapping is performed between each insurance application and the common data model.
In one embodiment, each class of the insurance product data model can be customized for a specific business system or application.
At processing block 402, processing logic retrieves a data definition schema for the insurance product class. The schema may be an XML schema file that include a custom data element of a type that is defined in another file.
At processing block 404, processing logic retrieves the custom data schema for the types of custom data. The schema may be stored in an XML schema file that contains the definition for each type of custom data.
Next, processing logic opens the custom data schema (processing block 406) and locates the tags relating to the custom data type of interest (processing block 408).
Further, processing logic adds the custom data elements to the located tags (processing block 410) and closes the custom data schema with the newly defined data elements (processing block 412).
One embodiment of a common data model representing a policy will now be described in more detail in conjunction with
The id data element 502 may be a unique identifier of a policy. The baseData data element 504 contains general information on the policy as will be discussed in greater detail below in conjunction with
The listOfRelatedPolicy data element 506 contains the list of policies that have some association with the current policy. This list may include, for example, policies that preceded the current policy and policies of parties involved in the current policy.
The listOfParticpatingParty data element 508 contains the list of people who are associated with the current policy (e.g., the policy insured, the benefactors, or anyone else who has an interest in the policy). The listOfParticpatingParty data element 508 will be discussed in more detail below in conjunction with
The listOfPaymentPlan data element 510 contains the list of payment plans associated with the policy. For example, the insured may choose a traditional payment method via mail or an online payment method via the Internet.
The quoteData data element 512 contains information pertaining to the policy quote as will be discussed in more detail below in conjunction with
The listOfProducer data element 514 contains information on entities participating in the creation of the policy. The entities may include insurance agents, insurance brokers, employees of the insurance company, etc. The listOfProducer data element 514 will be discussed in greater detail below in conjunction with
The customPolicyData data element 516 initially contains no data elements, but custom data elements can be added by defining data elements in the PolicyCustomDataType.
The controllingStateProvinceCode data element 602 contains information on the state or province that the policy comes under. The currencyCode data element 604 contains information about the currency that is used to pay the policy premium. The distributionOptionCode data element 606 specifies the way in which the money will be distributed for the policy. The endDate data element 608 defines the expiration date of the policy. The languageCode data element 610 defines the language in which the policy is written. The LOBCode data element 612 contains information on the line of business for the policy (e.g., whether the policy is an automobile policy, home policy or life policy). The originalInceptionDate data element 614 specifies when the insured was first issued a policy by this carrier. The payerCode data element 616 contains a code identifying the entity paying for the policy. The policyNumber data element 618 specifies the policy number that uniquely identifies the current policy. The startDate data element 620 specifies the effective date of the policy. The statusCode data element 622 defines the status of the policy (e.g., active, cancelled, expired, etc.). The statusReasonCode data element 624 contains information explaining the current status of the policy.
Next, as illustrated in
The insuredToBePaidFullAmount data element 802 contains information on the total amount that the insured would pay if the policy were to be issued based upon the current quote. The initialRequestDate data element 804 specifies when the current quote was requested. The conditionFlag data element 806 indicates if there are conditions associated with the quotation. The declinedFlag data element 808 indicates whether the quote was declined or accepted.
Further, as illustrated in
The agencyCode data element 906 specifies a code identifying a producer within an insurance agency. The contractNumber data element 908 specifies a contract number of the producer with the agency. The residentialProducerLicenseNumber data element 910 specifies a license number of a producer or agency issued by the state. The residentialProducerLicenseEndDate data element 912 specifies the expiration date of the producer's license. The roleCode data element 914 specifies a code identifying the role of the producer.
The lifePolicyBaseData data element 1004 includes general information on the life policy (e.g., the value of the life policy that has built up since the start date of the life policy, the face amount of the life policy, the underwriting class for the life policy, the premium to be paid annually for the life policy, etc.). The listOfHolding data element 1006 defines holdings (e.g., properties and assets) of the life policy. The listOfLifeCoverage data element 1008 defines coverages associated with the life policy. The listOfBeneficiaryClass data element 1010 defines beneficiaries of the life policy and their roles.
The listofVehicleCoverage data element 1104 includes information on vehicles associated with the auto policy and coverages of each vehicle. The listofDriverCoverage data element 1106 includes information on coverages of each driver associated with the auto policy. The customData data element 1108 initially contains no data elements, but custom data elements can be added as discussed in more detail above.
The computer system 1200 includes a processor 1202, a main memory 1204 and a static memory 1206, which communicate with each other via a bus 1208. The computer system 1200 may further include a video display unit 1210 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1200 also includes an alpha-numeric input device 1212 (e.g., a keyboard), a cursor control device 1214 (e.g., a mouse), a disk drive unit 1216, a signal generation device 1220 (e.g., a speaker) and a network interface device 1222.
The disk drive unit 1216 includes a computer-readable medium 1224 on which is stored a set of instructions (i.e., software) 1226 embodying any one, or all, of the methodologies described above. The software 1226 is also shown to reside, completely or at least partially, within the main memory 1204 and/or within the processor 1202. The software 1226 may further be transmitted or received via the network interface device 1222. For the purposes of this specification, the term “computer-readable medium” shall be taken to include any medium that is capable of storing or encoding a sequence of instructions for execution by the computer and that cause the computer to perform any one of the methodologies of the present invention. The term “computer-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.