Coverage Options and Available Limits

Topics: ACORD XML 2.x, Resources
Coordinator
Mar 18, 2016 at 8:14 PM
JOIN THE DISCUSSION - Coverage Options - There was a good discussion about how to add Coverage options to a message. One suggestion to add <AvailableLimit> in a return message, to provide available limits. This could be used to show various limits that are available, or in providing a product definition.

The current recommended solution from E&S XML uses the same (repeating) coverage code in repeating Coverage aggregates, to communicate multiple scenarios of limits, deductibles and rates.

I am reaching out to the community to see if there are other examples our working group could consider. We will be considering alternative approaches on the next call.
Developer
Mar 19, 2016 at 4:29 PM
I did not see the presentation but would invite comment. I reviewed our schema and came up with this solution.

I like limitOptional or limitAvailable better than AvailableLimit. Also, you may have a limit or deductible that we are optioning. Frequently, we see deductible used as a limit in such things as PL Auto and this is not correct. I have tried to show this correctly using the following examples. This is as simple as I could make it. I think it would work well for showing comparative optional limits/deductibles to agents.

Comments?
<Coverage> (PL AUTO)
  <typeCd>CM</typeCd>
  <description>COMP</description>
  <limit>50000</limit>
  <deductible>500</deductible>          
  <premium>446.42</premium>
  <limitAvailable>
    <limit>50000</limit> (This is the limit of coverage, max payout on comp)
    <deductible>250</deductible>          
    <premium>649.00</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>1000</deductible>          
    <premium>378.00</premium>
  </limitAvailable>
</Coverage>
 
<Coverage> (COMM GL)
  <typeCd>GL_EAOCC</typeCd>
  <description>EACH OCCURRENCE</description>
  <limit>500000</limit>
  <premium>1549.00</premium>
  <limitAvailable>
    <limit>1000000</limit>
    <deductible>1000</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>1000000</limit>
    <deductible>2500</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>1000000</limit>
    <deductible>5000</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>2000000</limit>
    <deductible>1000</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>2000000</limit>
    <deductible>2500</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>2000000</limit>
    <deductible>5000</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>5000000</limit>
    <deductible>5000</deductible>          
    <premium>...</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>5000000</limit>
    <deductible>10000</deductible>          
    <premium>...</premium>
  </limitAvailable>
</Coverage>    
Coordinator
Mar 22, 2016 at 6:48 PM
I've consulted with some of our insurance experts and have the following clarifications.

For accurate communication of product appetite and offerings:
  • Must support multiple available limits (can apply 'per-occurance' or 'per-accident' - so it has to relate to coverage option cd)
  • Must support multiple available deductibles (same as above with relation to coverage option cd)
For accurate communication of pricing and alternate offerings:
  • Supply premium for chosen coverage limit/deductible/option
  • Supply premium for alternate selections
I believe these requirements can only be met by introducing a new aggregate <AvailableCoverage> that inherits from Coverage_Type.

The only remaining question is whether this new aggregate should exist as Mica illustrated above inside or outside the <Coverage> aggregate?
Developer
Mar 22, 2016 at 7:55 PM
Edited Mar 22, 2016 at 9:11 PM
For the above example:
  • If the coverage has been requested, then I would include it as limitAvailable inside the existing requested coverage.
  • If the coverage has not been requested,, then I would include it as a CoverageAvailable. (not AvailableCoverage...namespace accuracy)
See below example that includes the above as Jamie has suggested and includes optional limits, deductibles, and coverages. This strategy keeps all of the optional stuff naming and structure the same, and I think simpler.
<Coverage> (PL AUTO)
  <typeCd>CM</typeCd>
  <description>COMP</description>
  <limit>50000</limit>
  <deductible>500</deductible>          
  <premium>446.42</premium>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>250</deductible>          
    <premium>649.00</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>1000</deductible>          
    <premium>378.00</premium>
  </limitAvailable>
</Coverage>
<CoverageAvailable> (PL AUTO)
  <typeCd>CL</typeCd>
  <description>COLL</description>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>250</deductible>          
    <premium>649.00</premium>
  </limitAvailable>
  <limitAvailable>50000</limitAvailable>
  <deductible>500</deductible>          
  <premium>378.00</premium>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>1000</deductible>          
    <premium>329.00</premium>
  </limitAvailable>
</CoverageAvailable>
Coordinator
Mar 30, 2016 at 8:50 PM
Edited Mar 30, 2016 at 9:46 PM
FROM THE ACORD 2.0 Working group
Nyerges, Matt: The conversation on available options in ACORD is just starting in Liberty as well. In a current project we are looking to drive a UI internally with the ACORD message model by providing this "product definition"/available options to the UI based on an ACORD request. How to provide these in an ACORD response has been subject of conversation for us. (While this is not for external consumption yet, it could be use for alternative channels as well.)

The goal is to provide available coverages, limits, deductibles, options (and likely more) back to the UI for display and action by the user.

Whatever the final structure, I think the idea of an AvailableLimit/AvailableDeductible, etc. lists are better than a repeating Coverage aggregate. The reason is that ACORD as it stands today is the "what is" for a policy - that is, the data in ACORD represents what has been chosen and represents the policy at that point. What we're looking to add is the idea of "could be" - what could the policy be, what options for limits/deductibles/etc exist and would likely need to be an extension of what we have today. As Jamie pointed out on the call, many xpaths/processing logic are setup to find the first instance of a coverage with coveragecd = "abc" and repeating those to show options would put those at risk.
This would also likely be something that would need to be hierarchical. An AvailableCoverage would be based upon a coverage and would have AvailableLimit and AvailableDeducible aggregates underneath. Likewise, a selected Coverage could have those AvailableLimit and AvailableDeducitble aggregates as well.

One possible issue was brought up in the call last week - what happens when a deducible is only available for certain limits? We may have to have the ability to have two distinct lists (for instances when there is not interplay) and another hierarchy for when there is (the AvailableDeducibles that are associated with a specific AvailableLimit would live under that AvailableLimit, as an example.)

There is still much discussion to be had internally here and in the call tomorrow, but those are my thoughts to date. I'll try to produce some sample XML by tomorrow as well.
<Samples>
  <Note>Samples of what this might look like. Each sample shows a different combination of some of the availableX ideas. Would be extended to options and likely other product based aggregates as needed. We could also enclose the availableX in an overall ProductDefinition aggregate as well at each level.</Note>
  <Sample>
    <Note>A coverage with available limits:</Note>
    <Coverage>
      <CoverageCd>ABCD</CoverageCd>
      <AvailableLimit>
        <FormatCurrencyAmt>10000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>20000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>30000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
    </Coverage>
  </Sample>
  <Sample>
    <Note>A coverage with available limits and one selected:</Note>
    <Coverage>
      <CoverageCd>ABCD</CoverageCd>
      <Limit>
        <FormatCurrencyAmt>10000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </Limit>
      <AvailableLimit>
        <FormatCurrencyAmt>10000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>20000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>30000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
    </Coverage>
  </Sample>
  <Sample>
    <Note>A coverage with available limits and deductibles, no interplay:</Note>
    <Coverage>
      <CoverageCd>ABCD</CoverageCd>
      <AvailableLimit>
        <FormatCurrencyAmt>10000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>20000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>30000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
      </AvailableLimit>
      <AvailableDeductible>
        <FormatCurrencyAmt>500</FormatCurrencyAmt>
        <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
      </AvailableDeductible>
      <AvailableDeductible>
        <FormatCurrencyAmt>1000</FormatCurrencyAmt>
        <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
      </AvailableDeductible>
    </Coverage>
  </Sample>
  <Sample>
    <Note>A coverage with available limits and deductibles, interplay between limit and deductibles:</Note>
    <Coverage>
      <CoverageCd>ABCD</CoverageCd>
      <AvailableLimit>
        <FormatCurrencyAmt>10000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
        <AvailableDeductible>
          <FormatCurrencyAmt>500</FormatCurrencyAmt>
          <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
        </AvailableDeductible>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>20000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
        <AvailableDeductible>
          <FormatCurrencyAmt>1000</FormatCurrencyAmt>
          <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
        </AvailableDeductible>
      </AvailableLimit>
      <AvailableLimit>
        <FormatCurrencyAmt>30000</FormatCurrencyAmt>
        <LimitAppliesToCd>ABC</LimitAppliesToCd>
        <AvailableDeductible>
          <FormatCurrencyAmt>1000</FormatCurrencyAmt>
          <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
        </AvailableDeductible>
        <AvailableDeductible>
          <FormatCurrencyAmt>2000</FormatCurrencyAmt>
          <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
        </AvailableDeductible>
      </AvailableLimit>
    </Coverage>
  </Sample>
  <Sample>
    <Note>Available Coverage on a Policy with another selected coverage:</Note>
    <Policy>
      <Coverage>
        <CoverageCd>ABCD</CoverageCd>
        <!--limits/deductibles/availablelimits/availabledeductibles removed...-->
      </Coverage>
      <AvailableCoverage>
        <CoverageCd>XYZ</CoverageCd>
        <!--availablelimits/availabledeductibles removed (An available coverage cannot have a selected limit/deducible, only available options.-->
      </AvailableCoverage>
    </Policy>
  </Sample>
</Samples>
Coordinator
Apr 1, 2016 at 5:31 PM
Edited Apr 4, 2016 at 6:57 PM
Hi everyone, I've tweaked the above example into what looks like a complete solution. The fundamental issue I've addressed is that the presence of coverage aggregate indicates it should be added to the quote/policy, that is not always the case, especially when offering alternate coverage options for a given risk.

The benefits of the below implementation is the simple addition of a repeating <CoverageAvailable> anywhere there is a <Coverage> aggregate.

It will extend the base Coverage_Type class that already contains cov cd, limits, deductibles, options, amts, rates, etc...

This approach can be used to indicate appetite and offer alternate rating scenarios.
<Samples>
    
    <Note>Samples of what this might look like. Each shows a different combination of some of the available coverages, limits and deductibles. 
    This technique would be extended to options and likely other product based aggregates as needed.</Note>

    <Sample>
        <Note>Available Coverage on a Policy with another selected coverage (no limits, deductibles or options)</Note>
        <Policy>
            <Coverage>
                <CoverageCd>ABCD</CoverageCd>
            </Coverage>
            <CoverageAvailable>
                <CoverageCd>XYZ</CoverageCd>
            </CoverageAvailable>
        </Policy>
    </Sample>

    <Sample>
        <Note>An available coverage with available limits</Note>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>20000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>30000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </CoverageAvailable>
    </Sample>

    <Sample>
        <Note>A coverage with one selected limit and multiple available limits</Note>
        <Coverage>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </Coverage>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>20000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>30000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </CoverageAvailable>
    </Sample>

    <Sample>
        <!-- This is a common insurance appetite use-case -->
        <Note>An available coverage with available limits and deductibles, no interplay</Note>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>20000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Limit>
                <FormatCurrencyAmt>30000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Deductible>
                <FormatCurrencyAmt>500</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
            <Deductible>
                <FormatCurrencyAmt>1000</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
    </Sample>

    <Sample>
        <!-- From my initial research this scenario is not very common -->
        <!-- Please note: above example has repeating limits and deductibles in one coverage, below has repeating coverage aggregates -->
        <Note>An available coverage with available limits and deductibles, interplay between limit and deductibles</Note>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Deductible>
                <FormatCurrencyAmt>500</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>20000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Deductible>
                <FormatCurrencyAmt>1000</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>30000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
            <Deductible>
                <FormatCurrencyAmt>1000</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
            <Deductible>
                <FormatCurrencyAmt>2000</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
    </Sample>

    <Sample>
        <!-- This is a an alternative implementation using repeating coverage aggregates -->
        <Note>An available coverage with available limits and deductibles, no interplay</Note>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>10000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>20000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Limit>
                <FormatCurrencyAmt>30000</FormatCurrencyAmt>
                <LimitAppliesToCd>ABC</LimitAppliesToCd>
            </Limit>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Deductible>
                <FormatCurrencyAmt>500</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
        <CoverageAvailable>
            <CoverageCd>ABCD</CoverageCd>
            <Deductible>
                <FormatCurrencyAmt>1000</FormatCurrencyAmt>
                <DeductibleAppliesToCd>ABC</DeductibleAppliesToCd>
            </Deductible>
        </CoverageAvailable>
    </Sample>

</Samples>

Marked as answer by jamiesteward on 10/2/2016 at 11:50 AM
Developer
Apr 1, 2016 at 7:41 PM
Thanks Jamie, I like the modified solution. It helps keep the options actually selected (under <Coverage>) separate from what could be selected and is available (<AvailableCoverage>)
Coordinator
Apr 4, 2016 at 6:59 PM
Minor tweak to the final implementation.

Renamed <AvailableCoverage> to <CoverageAvailable>.

This is more inline with existing 'available' nodes and naming conventions:
  • PendingResponseAvailDt
  • PhotoAvailableInd
Developer
Apr 6, 2016 at 2:52 PM
Edited Apr 6, 2016 at 2:53 PM
MNYerges,

What do you think of the following code from above post?

Issue that I see is for application development, has to tie a requested coverage, to optional limits, in a separate coverage object. This is an issue as you must parse the Coverage list at that level to see if any are available. In the following example, you have a single Coverage, what is requested, and what is optional. Very clearly tied to Coverage. This would make it easier for an UI dev to display the requested limit and a dropdown of optional limits/ded/prem.

What if you have two similar Coverage objects at the same level? Now the CoverageAvailable becomes a real mess.
<Coverage> (PL AUTO)
  <typeCd>CM</typeCd>
  <description>COMP</description>
  <limit>50000</limit>
  <deductible>500</deductible>          
  <premium>446.42</premium>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>250</deductible>          
    <premium>649.00</premium>
  </limitAvailable>
  <limitAvailable>
    <limit>50000</limit>
    <deductible>1000</deductible>          
    <premium>378.00</premium>
  </limitAvailable>
</Coverage>
Developer
Apr 7, 2016 at 3:19 PM
Mica,

I think both are viable options each with their own pros/cons.

Being in separate coverages allows us to keep a clear delineation between what is selected (<Coverage>) and what is available (<CoverageAvailable>).

Being combined provides some simplified understanding/coding - the <Coverage> has all that is selected and is available.

I'm personally indifferent to looking at multiple levels. ACORD is a great message model, but if the structure provided in the message doesn't fit what you need for the UI (or any other component) my vote is to use specific accessors/structures for your needs (with any mapping necessary) vs changing the message model.

One aspect we should talk about today - how far do we see the idea of available options extending? If this goes beyond Coverage, what are the implications of our choices. (Basically, do we have <XXAvailable> aggregates to house information or do we create <XXAvailable> fields for each we wish to provide an option for?)
Developer
Apr 7, 2016 at 3:42 PM
MNyerges,

I think the <limitAvailable> provides a clear delineation from a data and implementation use case.

I would also prefer <limitOption> for coverages that were requested, and <CoverageAvailable> for coverages not requested, if its not too confusing.

I would like to hear other views on this, as this is kind of the point of this, discussion. I very much value your input, due to the impact that you face from such decisions. I would also like to hear from other carriers, and vendors. This kind of slow, group think is very very valuable to my decision and thought process.

I am not sure that this discussion belongs in the 2.0 discussion, but should be on CodePlex.

At this point, ACORD is struggling to depcrecate and produce 2.0. This maybe a 2+, or 3 feature. I definitely feel that extending this beyond coverage is a discussion we can have, here, perhaps in another thread, but probably not for inclusion in 2.0.

Jamie? Danny? Thoughts?
Coordinator
Oct 2, 2016 at 7:48 PM
As discussed previously; the presence of the <Coverage> aggregate indicates that the coverage has been selected, thus we cannot embed any new aggregates into that structure.

The group agreed to the <CoverageAvailable> structure which extends the existing 'Coverage_Type'. Unfortunately this approach is not easy to navigate and iterate upon, but then neither are things like Location, SubLocation, LocationUWInfo, Dwell, etc... so it's not the only time we have to use references. To help with this I will add the @CoverageRefs attribute to create some internal link.