CoverageAvailable Usage and possible extension

Topics: ACORD XML 2.x
Developer
Jun 21, 2016 at 4:57 PM
We have already begun implementing some of the ideas around the need for CoverageAvailable, including denoting which coverages are available as well as which limits/deductibles/options are available for given coverages. At this point we've hit a bit of a snag and would like input from the group.

Background: CoverageAvailable will be present everywhere a coverage exists today, to provide a means to show which coverages, even if not selected, are available and to show which limits/deductibles/options are available for that available coverage as well. CoverageAvailable is repeating, as well as the limits/deductibles/options held there (since CoverageAvailable simply extends the Coverage type.) We discussed on one of the calls that for limit/deductible/option combinations we could use multiple CoverageAvailable aggregates with the same coverage code to group them so that you could see what combinations belonged together.

Our sticking point is with split limits/deductibles/options (I'll focus on limits but the same applies for split deductibles or option groups.) Exposing split limits seems to lend itself to using multiple CoverageAvailable aggregates, each with a split limit in the list of limits. However, I will show below that this might not be enough.

For the simple, non-split case we could have two possibilities:
<Options name="SimpleCase">
  <Option name="Collapsed">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
  </Option>
  <Option name="VeryVerbose">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
  </Option>
</Options>
In the Collapsed case, you see a single CoverageAvailable with 3 separate limits. With the very verbose case you see the same coverage 3 times, each with the single limit. Based on discussions, both are supported by having CoverageAvailable and are functionally equivalent implementations.

Now look at split limits. You cannot have the collapsed case because you don't know what limits are "paired" as split, you only see a list of limits available. You can, however, make this happen with the VeryVerbose case:
<Options name="SplitCase">
  <Option name="VeryVerbose-SplitLimits">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
  </Option>
</Options>
However, this breaks down when you attempt to send back a split limit that is the only available limit for that coverage:
<Options name="UnknownCase">
  <Option name="???">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
    </CoverageAvailable>
  </Option>
</Options>
Here you cannot tell if this is a split limit being offered at 1000000/2000000 or a set of single limits available of 1000000 and 2000000 separately.

Given this, we have an option:
1 - We always must be very verbose, and say any "group" of limits inside a CoverageAvailable aggregate is by definition a split limit and by extension every single limit must belong by itself even if not split. This gets very verbose in XML, makes it harder to know what deductibles/options could go with those particular limits (because we would have to product a cross product permutation to show that, see A below.)

2 - We add a "SplitGroupCd" element to the Limit/Deductible/Option aggregates so that we can logically group them inside the CoverageAvailable aggregate (see B below.)

A - What happens when we add deductibles and options in? In the collapsed case you see we simply have deductibles inside the single coverage available. With the Very Verbose option we have a permutation of availability. (It also gets harder to process when a deductible only belongs to a single limit vs all limits.)
<Options name="SimpleCase">
  <Option name="Collapsed">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>1000</FormatInteger>
      </Deductible>
      <Deductible>
        <FormatInteger>5000</FormatInteger>
      </Deductible>
      <Deductible>
        <FormatInteger>10000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
  </Option>
  <Option name="VeryVerbose">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>1000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>5000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>10000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>1000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>5000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>10000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
        <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>1000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>5000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
      </Limit>
      <Deductible>
        <FormatInteger>10000</FormatInteger>
      </Deductible>
    </CoverageAvailable>
  </Option>
</Options>
B - What does it look like with split limits? You can see that the splits are logically grouped by that new element. It also allows us to be much less verbose in what we return for limits in general and for the combinations of limits/deductibles/options together.
<Options name="UnknownCase">
  <Option name="???">
    <CoverageAvailable>
      <CoverageCd>ABC</CoverageCd>
      <Limit>
        <FormatInteger>1000000</FormatInteger>
        <SplitGroup>1</SplitGroup>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
        <SplitGroup>1</SplitGroup>
      </Limit>
      <Limit>
        <FormatInteger>2000000</FormatInteger>
        <SplitGroup>2</SplitGroup>
      </Limit>
      <Limit>
        <FormatInteger>3000000</FormatInteger>
        <SplitGroup>2</SplitGroup>
      </Limit>
    </CoverageAvailable>
  </Option>
</Options>
I recommend adding the SplitGroup element (or whatever other name we decide on) to the Limit/Deductible/Option aggregates to allow for better support of CoverageAvailable.

Any thoughts, concerns, or questions from the group?
Developer
Jun 23, 2016 at 12:36 PM
I will try to look at this later when I have more time. We looked at the split/CSL issue and found a solution. First thought though, that in the case of PL Auto BI/PD,

100/300, the 100 and 300 that while paired, are separate coverages, and the 100 is a different limit from a 100CSL and must be indicated that way.