iLingo - The Language of Insurance e-Business

Authors

(C) 1999 Lexica, LLC

The information in this document is proprietary information and/or intellectual property developed and owned by Lexica, LLC. The information in this document may be used for review purposes only. Such information may not be incorporated into any software program, used as the basis for any XML schema or other file format, modified, used as the basis for any derivative work or for any other purpose (other than review). Copyright 1999 by Lexica, LLC. All rirghts reserved. ilingo is a trademark of Lexica, LLC. The use of "iLingo" in this white paper refers to the iLingo technology.

1. Introduction

iLingo is a set of XML schemas designed to be an inter-operable language for the insurance supply chain. It provides a consumer-centric set of schemas for exchanging information within insurance transactions and attempts to cover the complete supply chain from acquisition of consumer data through to policy issue. By doing so, iLingo represents a framework with which market makers can establish insurance markets.

2. The Insurance Supply Chain

The insurance industry supply chain is traditionally divided into two parts--the agency or customer service side of a direct carrier that manages the relationship with the consumer and the underwriting and claims processing of the carrier and their affiliated re-insurers. In the course of doing business, diverse interactions also occur between the "primary" entity (the agency or carrier) and third-party providers of information and services related to insurance sales, underwriting and servicing. With the introduction of the Internet and direct sales through web market portals, the division between trading partners becomes much less well defined. In addition, the possibility of using web technologies to automate this supply chain further changes the way one views insurance.

Thus, a new model for the supply chain must be developed that takes into account new business models for the Internet as well as existing business practices while creating a market. Essential to the operation and implementation of this supply chain is the business party that will deploy, support, and operate components within the market. In this context we define the concept of a Market Maker.

A Market Maker is the business party that operates the systems that implement a marketplace. They provide the framework in which the business parties in the supply chain--the insurers, re-insurers, payment services, credit agencies, etc.--can operate their technologies, components, and platforms that provide business services to the supply chain. Essentially, the Market Maker provides the backbone for the supply chain.

In conjunction with the Market Maker, participating business parties--insurers, etc.--provide components that integrate with the workflow of the supply chain. These components provide necessary functions related to the role that the business party plays.

For example, an insurer must provide components that can provide "rate" information for specific insurance products to produce quotes for a consumer. In addition, they must provide, through their components, the insurer-specific process for taking that quote to the point of binding a policy, producing legal documents and, ultimately, transferring that data into their own systems.

The role of an insurer, as described previously, is that of a Manufacturer in the supply chain. That is, they produce the insurance products that the consumer buys. There is a specific workflow that a consumer must go through that is common to all insurance products of a particular type with the exception that an insurer may have specific requirements or customizations that must be accomplished along the way. It is this workflow that a Manufacturer participates within and enhances by adding customizations to add value.

In support of the Manufacturer--the insurer--the Market Maker provides supporting services with the supply chain. For example, a credit report is often used as data when quoting an insurance policy. Thus, a market maker provides access to credit information through another participant in the supply chain. These participants are called Supporting Participants.

This diagram illustrates the concept of a Market Maker and a supply chain market:

In addition to providing a market in which Manufacturers and Supporting Participants gain benefit, the Market Maker can collaborate and communicate with other Market Makers. This allows Market Makers to allow their participants to operate within other markets with one single point of integration essentially providing a super-aggregated point of view to a consumer. This concept is called Cross-Market Collaboration.

The following diagram illustrates this concept:

3. iLingo

3.1. Overview

iLingo is a set of XML schemas designed from a buyer's (consumer's) perspective. Each schema either fills a particular role in the supply chain or augments another schema in some way. All document instances are related to each other through a set of cascading hyperlinks which start at the consumer account hub document.

3.2. Markup Architecture

A Markup Architecture is a set of patterns used in designing a set of schemas. The following sub-sections contain the design patterns and rules used to design iLingo.

3.2.1. Naming Conventions

Naming of elements and attributes in iLingo follow a very simple set of rules:

1. Abbreviations are not used unless there is a very good reason (e.g. a common industry acronym that is easier to recognize then the fully-expanded name).
2. A period is used to separate words.
3. All lower case is used.
4. Consistent names are used among similar constructs (e.g. similar attributes with different subjects use the same prefix or suffix).

3.2.2. Attributes vs. Elements

The decision of when to use attributes over elements is based on the following criteria.

When to use attributes:

• When there is a single fact about an element and that fact has no sub-structure.
• When it is necessary to link one element to some other element or document.
• When the set of facts has no order.

When to use elements:

• When the fact is a component of the parent element with sub-structure.
• When attributes or links are needed to be associated with the fact.
• When there is a set of facts (e.g. a set of driver violations).
• When order matters.

In addition, as an overall rule, if something has been made an attribute or element for a particular reason, anything with a strong relationship should be made to be similar. For example, in an Address, City and Zip are elements, so State is an element as well.

3.2.3. URI Usage

URI values are used in attribute values within iLingo to either name an object or to refer to another. In certain usages, these URI values are location URIs. In other uses, they are simply a name that can be used for referencing. In addition, the use of URI values allows a Market Maker to assign URN values to certain objects within the system so that naming can be location independent.

3.2.4. Links and Multiple Documents

The iLingo design uses simple one-way links to associate one document to another. This allows the schemas to be focused on a consistent subject while existing within an abstract framework. That is, for example, a person schema can focus on modeling information about a person and another schema can point to instances of that schema to associate other data or transactions with that person.

When a simple link is encoded, it is of one of three categories:

1. A location link whose presence on an element is one of the main purposes for the element. For example, the person.ref element in the consumer account schema. This is represented by the presence of an href attribute of type URI. In this case, the URI value is meant to be a location of the target.
2. A location link whose presence on an element augments or associates the targeted object but is not the main purpose of the element. For example, the quote.result.href attribute of the auto scenario schema. This is represented by a "role" or "identifier" suffixed by a href name with a type of URI. In this case, the URI value is meant to be a location of the target.
3. A name link whose presence on an element is one of the main purposes for the element. It identifies a target object but the value of the link is not a location. For example, the ref attribute on the auxiliary.driver element of the auto scenario schema is the URI value used in the auto line of business which uniquely identifies the driver who plays this role. This is represented by a ref attribute of type URI. The URI value does not represent a location but rather a name which must be resolved to a location.
4. A name link whose presence on an element augments or associates the targeted object but is not the main purposes for the element. It identifies a target object but the value of the link is not a location. For example, the vehicle.ref attribute on the vehicle.coverage element of the auto scenario schema is the URI value used in the auto line of business which uniquely identifies the vehicle being covered by the scenario. This is represented by a "role" or "identifier" suffixed by a ref name with a type of URI. The URI value does not represent a location but rather a name which must be resolved to a location.

3.2.5. Object Identifiers

In certain cases, URI values are used to identify an object (element construct) within a set of instances. This URI value is encoded as an attribute suffixed by a id name. The attribute value is used when another document needs to identify which object in the system is being targeted.

For example, the us.address element has an attribute named object.id. This attribute value is used when other documents in iLingo need to be able to identify a particular address instance. Such a document is the Auto Policy Endorsement in the change.address element.

In this case, the address being changed is identified by the object.id attribute on the us.address child of the change.address element. This tells the system that whatever document that contains the address identified by the URI value of the attribute is the address being changed. Hence, the system is expected to keep track of these identifiers and keep them unique.

Typically, such a URI value would use a non-location scheme. An example might be object:identifier where 'identifier' is some system generated identifier that is guaranteed to be unique within the system.

3.2.6. Containers and Optionality

In general, the following rules were used in designing the schemas with respect to container elements and optionality:

• For sets of elements, a container representing that set is preferred. For example, there is a people element that contains person.ref elements in the consumer account schema.
• If a set of elements is optional, a required container element with optional children is preferred over an optional container element with required children. That is, A with a model of B* is preferred over A? with a model of B+.
• Enforcement of when something is required from a business perspective is an arbitrary decision. Therefore, the schemas only enforce what is necessary for integrity of the framework and not the integrity of the data. The checking of data integrity is a necessary second step, part of which can be accomplished with more restrictive schemas. This allows systems to collect and store information legally at any stage in the process.
• Optional elements should be at the end of the content models.

3.2.7. Attributes

The design of the attributes use the following rules:

• There are no defaults for attributes.
• All attributes are atomic. That is, there are no attributes with multiple values such as NMTOKENS.
• Attributes are only required when they are necessary for the framework (e.g. a hyperlink attribute) or the element would be nonsense without the attribute value (e.g. valued.equipment on a vehicle without the equipment type attribute).

3.3. The Schemas

The schemas that make up iLingo are intended to support multiple lines of the insurance business, e.g., personal auto, life, homeowners, business owner's, etc. At this time, iLingo only addresses the details of personal auto insurance, but provides a framework for all lines of business. In the future, iLingo will accommodate detailed schemas across multiple lines of business.

3.3.1. Summary

3.3.2. Consumer Account Schemas

3.3.2.1. Consumer Account

The consumer account schema represents the hub document of a consumer account. For any consumer, there is only one of these documents. From this instance, all other information known about the consumer can be accessed.

This document also identifies three important facts about the account:

1. An e-mail address to be used to contact the account holder.
2. A person identified as the account holder.
3. A address to be used as the default for all transactions, persons, and vehicles when another address has not been specified.

3.3.2.2. Person

The person schema represents information known about a certain individual associated with the account. There many be multiple instances of a person document associated with one consumer account. For each instance, there is a person.ref element as a child of the people element in the consumer account document.

3.3.2.3. Billing Information

The billing information schema represents billing information associated with a certain individual. It is a separate document so that it can be updated at purchase time without interfering with the integrity of the quote.

There can only be one billing information document associated with each person in the account. This association is through the billing.information.href attribute on the person document to which this billing information should be associated.

3.3.2.4. Auto Line of Business

The auto line of business schema represents all the information collected about the consumer's vehicles and drivers as well as any links to auto insurance scenarios. There is only one of these documents per consumer and the association is through the auto.line.of.business element in the consumer account document.

3.3.2.5. Auto Scenario

The auto scenario schema represents an auto insurance scenario--essentially a "what if..." model. It is the focal point for quoting in the auto line of business. It contains information that cross-relates drivers with vehicles with specific insurance coverages. When quoted, the document has a quote.result.href attribute which points to a set of quote results.

3.3.2.6. Auto Quote Result

The auto quote result schema represents a set of quotes for an auto insurance scenario. Each of the quotes presents the cost and the exact coverage quoted in the case that the coverage request is not available from the carrier (e.g. $250,000 requested but only $300,000 is available). If a carrier chooses or cannot be quoted, a quote declined element is represented in the document.

3.3.3. Policy Schemas

3.3.3.1. Legal Folder

A legal folder is the hub document for all legal documents associated with an insurance policy. This document is not line-of-business specific. Instead, it is just a set of hyperlinks with roles that point to policy documents from a specific line-of-business.

3.3.3.2. Auto Policy

The auto policy schema represents an auto insurance policy. It contains a "snapshot" of all the information from the consumers data used to generate a binding quote as well as any ancillary data added during the purchasing process. In addition, it contains pointers to "printable" forms if application, binders, etc. are necessary to legally bind the policy.

3.3.3.3. Auto Policy Endorsement

The auto policy endorsement schema represents a change to an existing auto insurance policy previously represented in iLingo.

3.3.4. Market Schemas

3.3.4.1. Market Registry

The market registry schema represents information about the market participants. Specifically, there is one instance of the registry that contains participant information for each member of the market. In addition, it identifies the Market Maker.

3.3.4.2. Auto State Registry

The auto state registry schema represents information about state requirements and constraints. It contains links to all information categorized by state.

3.3.4.3. Auto Coverage Minimum

The auto coverage minimum schema represents state minimums for auto insurance policy coverage. Anything not specified in the instance is considered unbounded for that state.

3.4. Extending iLingo

The iLingo schemas are designed to meet nearly all of the requirements of those performing on-line transactions in the insurance industry. These schemas define the overall structure of standard business objects (such as vehicle and driver) and their properties (such as a vehicle's make and model, and a driver's birth date). However, should the need arise (and it almost surely will) to extend this predefined set of properties to meet the needs of a particular organization, there are several ways in which this can be done. To that end, Lexica is currently exploring the following candidate schema extension mechanisms:

• External Annotation
• Internal Annotation
• Schema Refinement

None of these mechanisms are available with this release of iLingo, however, one or more of these techniques will be made available with an upcoming release.

3.4.1. External Annotation

Of the three candidate extension mechanisms, this is the most straightforward technique. This form of extension is achieved by adding extension reference elements to each of the iLingo business objects. These reference elements designate additional documents (identified by URI) as extended descriptions of the containing business object. For example, the following auto.line.of.business document includes a driver with an External Annotation:

  <auto.line.of.business xmlns="urn:x-lexica:ilingo:auto.line.of.business:en" ...>
    ...
    <drivers>
      <driver object.id="object:foo:1234" ...>
        ... 
        <extensions>
          <extension.ref href="addl.driver.props.xml"/>
        </extensions> 
      </driver>
    </drivers>
    ...
  </auto.line.of.business>

In the above example, the driver1 object is augmented by the contents of the addl.driver.props.xml document. This supplementary document contains additional driver properties as prescribed by some extension schema. Here's an example of this supplementary document:

  <driver.extension xmlns="urn:x-lexica:carrier-extension:carrierx:en"
                    object.ref="object:foo:1234" ...>
    <corrective.lenses>required</corrective.lenses>
  </driver>

This document contains driver properties as allowed by the urn:x-lexica:carrier-extension:carrierx:en schema (defined by some carrier, in this case, by carrierx), and not by the iLingo schemas. This carrier specific schema allows for driver.extension documents which can contain corrective.lenses properties. This new property is said to annotate the original iLingo driver element.

The link to the external (carrier supplement) document is maintained throughout the processing of the parent iLingo document and may be put to use by any process that understands the external document's schema, and ignored by any that do not. This same technique can be used to extend any of the iLingo objects without affecting the iLingo schemas directly.

The only modifications that need to be made to enable this form of schema extension are the addition of the extensions and extension.ref elements to each of the business objects' content models in the iLingo schemas, which will be done only if External Annotations are chosen as one of the extension mechanisms to be included in the next release of iLingo.

3.4.2. Internal Annotation

Internal Annotation is achieved using elements with fully qualified names (see the W3C's [Namespaces in XML] Recommendation) directly in iLingo documents. Here's an example that adds the corrective.lenses property (as defined by carrierx) to the driver1 object:

  <auto.line.of.business xmlns="urn:x-lexica:ilingo:auto.line.of.business:en" ...>
    ...
    <drivers>
      <driver object.id="object:foo:1234" ...>
       ... 
       <extensions xmlns:x="urn:x-lexica:ilingo:carrier-extension:carrierx:en">
          <x:corrective.lenses>required</x:corrective.lenses>
        </extensions>
      </driver>
    </drivers>
    ...
  </auto.line.of.business>

As in the External Annotation example, this mechanism requires the addition of an extensions element to each of the iLingo business objects. However, it does not require extension.ref elements as the extensions are directly included in the extensions element. One problem with this approach is that, in order to maintain document validity, one must use an XML parser capable of validating this type of document.

A standard XML 1.0 parser will not validate the above document unless the extensions element has been explicitly defined to allow the carrierx:corrective.lenses element. This means carrierx must modify the iLingo DTD directly. Therefore, Internal Annotations cannot be supported using XML 1.0 parsers (without Namespace and XML Schema support). When validating parsers are available which support both the [Namespaces in XML] Recommendation and the upcoming [XML Schemas] specifications, Lexica will consider adding this form of extension to iLingo (by adding the required extensions element to all iLingo business objects).

3.4.3. Schema Refinement

This extension mechanism is described in the W3C [XML Schema Refinement Task Force Report]. Lexica plans to support this form of schema extension directly, allowing anyone to refine iLingo objects and properties using standard XML techniques.

Although this specification is a work in progress, the current thinking is that one will be able to define a new schema which refines (inherits and extends) the properties of iLingo elements. Documents which adhere to this new schema will still be considered valid iLingo documents. Processes which do not recognize the new schema will only see a subset of the document as defined by iLingo. There are two specific ways in which an iLingo element can be refined: 1) add attributes to existing elements (Attribute Set Refinement) and 2) define new elements which can only be appended to the existing content model of iLingo elements (Content Model Refinement. The following sections describe each of these methods in detail

3.4.3.1. Attribute Set Refinement

Using Attribute Set Refinement, one can add new attributes to existing element definitions. Here's an example of a document that refines the iLingo driver element by adding a new corrective.lenses attribute (the new element is called driver):

  <auto.line.of.business xmlns="urn:x-lexica:ilingo:auto.line.of.business:en" ...>
    ...
    <drivers>
      <x:driver xmlns:x="urn:x-lexica:ilingo:carrier-extension:carrierx:en" 
                object.id="object:foo:1234" 
                corrective.lenses="required" ...>
       ... 
      </x:driver>
    </drivers>
    ...
  </auto.line.of.business>

Here's a snippet of the schema that refines the iLingo driver element's attribute set:

  <schema xmlns="http://www.w3.org/1999/XMLSchema" ...>
    ...
    <import schemaName="urn:x-lexica:ilingo:auto.line.of.business:en"
            schemaAbbrev="alob"/>
    ...
    <element name="driver">
      <archetype>
        <refines name="driver" schemaAbbrev="alob"/>
        <attribute name="corrective.lenses" type="string">
          <enumeration>
            <literal>required</literal>
            <literal>not-required</literal>
          </enumeration>
        </attribute>
      </archetype>
    <element>
    ...
  </schema>

More examples of Attribute Set Refinement can be found in the [XML Schema Refinement Task Force Report] as well as the [XML Schemas] specification.

3.4.3.2. Content Model Refinement

Content Model Refinement allows one to extend the content model of elements such that newly defined content may be appended onto any content defined in the base element type. For example, the following document has a corrective.lenses element appended onto the standard iLingo driver element's content model:

  <auto.line.of.business xmlns="urn:x-lexica:ilingo:auto.line.of.business:en" ...>
    ...
    <drivers>
      <x:driver xmlns:x="urn:x-lexica:ilingo:carrier-extension:carrierx:en" 
                object.id="object:foo:1234" ...>
        ...
        <x:corrective.lenses>required</x:corrective.lenses>
      </x:driver>
    </drivers>
    ...
  </auto.line.of.business>

Here's a snippet of the schema that refines the iLingo driver element's content model to allow the inclusion of the corrective.lenses element:

  <schema xmlns="http://www.w3.org/1999/XMLSchema" ...>
    ...
    <import schemaName="urn:x-lexica:ilingo:auto.line.of.business:en"
            schemaAbbrev="alob"/>
    ...
    <element name="driver">
      <archetype>
        <refines name="driver" schemaAbbrev="alob"/>
        <element name="corrective.lenses" type="string">
          <enumeration>
            <literal>required</literal>
            <literal>not-required</literal>
          </enumeration>
        </attribute>
      </archetype>
    <element>
    ...
  </schema>

More examples of Content Model Refinement can be found in the [XML Schema Refinement Task Force Report] as well as the [XML Schemas] specification.

4. Looking Forward

iLingo is not complete and never will be complete. Instead, we have designed iLingo such that it can grow and be extended. Rather than focusing on point-to-point communication, iLingo focuses on a conceptual framework for the whole supply chain from consumer to insurer.

We have designed iLingo to provide a top-down framework and a basic set of primitives and structures--the XML equivalent of a data dictionary--so that different markets can use iLingo and focus on refining the "gray middle" where market needs diverge. With that said, we welcome feedback on our schemas and structures as we proceed with developing them further.

In the future, we look forward to working with [OASIS] and [ACORD] on XML-based standards in the insurance industry.

Appendix A. XML Schemas and DTDs

iLingo uses the [W3C XML Schema Working Draft of 6-May-1999]. Although there have been later drafts, we have been reluctant to move forward until a new syntax stabilizes. In addition, we have been conservative in our use of XML Schema refinement/archetypes because they have been in flux.

With the recent drafts and the promise of a proposed recommendation, we will move iLingo forward in the near future. This will allow us to take advantage for more schema constructs and, thus, make iLingo more usable as a basis for XML in the insurance supply chain.

In many ways, the current iLingo represents three general uses of XML Schemas:

1. An XML syntax for the schemas that allows us a great deal of flexibility.
2. True data typing of "leaf nodes". That is, if something is a date, it is typed as a date.
3. The current element types are really the manifestation of a more complex type system that we haven't modeled in the schemas and really represent the "leaf nodes" of this type system.

Given that we cannot guarantee that an XML schema processor exists at all points in the supply chain, we have provided XML DTDs that are generated from the XML schemas. These DTDs allow a document that conforms to the schema to syntactically parse and provide a certain level of validation. Although this validation cannot check all datatypes, it does provide the structural checking of content models and the verification of required attributes.

Appendix B. Production Notes

All the HTML documentation and reference material in this distribution was generated from XML content using [XSLT]. The XML document types--with the exception of the XML Schema document type--were developed at Lexica along with the stylesheets.

In addition, a tool called XSDDOC written by R. Alexander Milowski provided the ability to generate the DTD files and HTML reference material from the XML Schemas. This tool has not been made available to the general public due to the instability of the XML Schema draft but should be available real soon now!

Appendix C. References