This set of questions came through to the LDEx team via an email and we wanted to be able to add it here for future reference.
- Do you know if anyone is using the TestProductionCode indicator in for testing? Trying to figure if this is something we need to code for to make configurable or not.
- Yes, this is being used. It is specifically being used in new case or new integration set up. Many of the ben admins require this so they don't have to scrub data based on regions.
- If we approve spouse life, assume we should pass the "DependentPartyId" in the Coverage element as opposed to EmployeePartyId?
- In this scenario xsd:element name="InsuredPartyID" type="xsd:string"> should be the "DependentPartyId".
- Who defines the Benefit Plan Identifier value?
- Identifier usually refers to the carrier generated value where ID is a unique value to reference data within the payload.
- Are these 'standard' or can they change from client to client (or ben admin to ben admin)?
- They should be defined the carrier, and used consistently across the carrier's partners.
- Trying to figure out how we should build this to have the right level of flexibility, but don't want to make it flexible if it doesn't need to be! We have a field in our system called Coverage Category that would work well here, but I also don't know if we as the carrier get to dictate this or if the receiver will be telling us what values they want to see.
- We would expect the carrier defines these elements, based on values their staff would know internally.
- Also, are the values in the sample the values we should use (VGTL, VGTLSP, etc), or are these just what was defined for the example payload?
- No I suggest you use the values you would internally and keep them consistent across your partners.
- In the 'InsuredCoverageEffectiveDate' field, we are planning to pass the date we make the decision. That's really all we can pass here, and I think other carriers are in the same boat. The client may have different rules for updates defined in their Ben Admin platform (e.g. 'all decisions made are effective the first of the next month') for payroll and/or billing reasons or simplicity. We don't have the ability to take those rules into account within our underwriting system, we just know the date we make the decision. Just curious if you've seen any questions around this.
- Unfortunately if that's all you can send, that's all you can send. Just make sure you work with the receiver to be 100% sure they understand exactly what this date represents.
- Have a few questions on some of the 'Amount' elements that I'm hoping can be clarified. Want to be 1000% sure here, as these are really the key fields to the whole standard. Below are how they're defined in the XSD:
- BenefitAmount: Value of approved coverage, based on the defined plan rules for the enrolling person.
- ElectedBenefitAmount: Value of the coverage being asked for (aka elected) based on the defined plan rules for the enrolling person. Requirements: Situational, for all coverages (New Coverage, Evidence of Insurability, Employment Status Change, Billing, Miscellaneous Transactions, and Coverage Change transactions) this is required for products with benefit amounts in an approval situation, else optional.
- TotalBenefitAmount: The total inforce amount that the carrier has currently approved for the insured. This is not just the dollar amount that was underwritten, but the entire approved amount. Requirements: Situational, required when UnderwritingDecisionCode=Approved, Declined, or Closed in the transmission.
- UnderwritingApprovedBenefitAmount: The amount that the carrier has approved for the insured, during the EOI underwriting process. Requirements: Situational, required with an amount greater than 0 when the UnderwritingDecisionCode = Approved and benefit is a flat amount and/or a calculated amount or required with an amount equal 0 when the UnderwritingDecisionCode = Declined or Closed
So applying a real-life example here, let's say someone already has $50,000 of coverage in-force already from a previous year's enrollment. They are now wanting to increase to $200,000 and the entire increased amount ($150,000) is pending for EOI. Voya approves this $150,000 increase, which means the member will have $200,000 of total approved life insurance. Here is what I assume we should pass based on the definitions above. Does this look right to you?
- BenefitAmount: 150,000 (as this is the amount of pending coverage that was applied for and approved)
- ElectedBenefitAmount: 200,000 (as this is the total amount of insurance requested)
- This appears to be incorrect because this value should only represent this year's elected enrollment amount.
- TotalBenefitAmount: 200,000 (as Voya approved the member for 200,000 total)
- UnderwritingApprovedBenefitAmount: 150,000 (as this is the amount of coverage the member applied for that we approved)
In the scenario where there is no GI and $50,000 of existing inforce coverage:
- ElectedBenefitAmount: 150,000
- The amount elected this enrollment cycle
- UnderwritingApprovedBenefitAmount: 150,000
- Due to no separate GI or Buy Up underwriting is reviewing the full elected benefit amount.
- BenefitAmount: 150,000
- This is the value of this enrollment cycles approved coverage.
- TotalBenefitAmount: 200,000
- This value equals prior inforce coverage plus the "BenefitAmount" which in this scenario includes the "UnderwritingApprovedBenefitAmount" elected within this enrollment cycle.
#LDEx-API#LDEx-EOIS#LDEx-JSON#LDEx-XML------------------------------
Michael J Grudgings
Business Architect, Data Standards | LL Global, Inc.
300 Day Hill Road, Windsor, CT, 06095
t: (860) 298-3850 |
mgrudgings@limra.com------------------------------