Select Benefit Specifications

The 'Select Benefit Specifications' level 3 flow shows how Claims selects the applicable benefit specification(s) for a claim line.

The selection of benefit specifications includes all subtypes with the following exceptions:

• The selection of reservation specifications happens in Reservation Selection, Claim Classification, and Episode Detection,so it is already done.

• The selection of authorization specifications is not done for reservation lines (claim lines that belong to a claim with processing type Reservation) and also not for claim lines that refer to a reservation line. The rationale is that a customer will either make use of an authorization or of a reservation for a particular claim line, but not both.

The recognition and creation of adjudication cases is an integral part of the benefit specification selection step. An adjudication case is a grouping of claim lines that are adjudicated in the same way. Lines can either start a new case, or be added to an existing case. Lines that are added to an existing case are referred to as ancillary lines.

Lines are processed sequentially. However, a claim line that qualifies to be added to a case may be processed earlier than the line that actually starts that case. That means that, during the processing of the first line, there is no existing case that the line can be added to. This introduces a processing sequence challenge. For this reason, the benefit selection is executed in two phases.

The first phase selects the applicable benefit specification for all lines that do not qualify as a possible ancillary lines. If a candidate ancillary line is detected, it is flagged for the second phase. All lines in a claim go through this first selection before the second phase of the selection starts.

During the second phase, flagged lines are checked to see if they belong to an existing case. The possible outcome is that a line is added to an adjudication case that was created during phase one, even though the line that created the case has a higher sequence number. The second phase of the benefit selection is described in the Select Benefit Specifications for Ancillary Lines.

Within the scope of the flow depicted above, the steps are executed per claim line. The lines that meet one of the following conditions are ignored:

• Lines with a checked "Keep Benefits" indicator;

• Lines with a checked "Locked" indicator;

• Lines that specify an overriding coverage regime (note that the selection of benefit specifications of type 'post benefits' is still performed for these lines; the evaluation of these benefit specifications takes place just as if no overriding coverage regime was sent in on the claim line);

• Lines with a product independent fatal message (attached to the line itself or the bill or claim to which the line belongs) of the following origins: MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT, RESERVATION, PRICING, PRICING LIMIT, PRICING NO RECALCULATION, PAYMENT STATUS or PRE BENEFITS.

The lines that specify an overriding coverage specification are also ignored. Here the overriding coverage specification is the only selected benefit specification (aside from the post-benefits). This benefit specification skips the filtering on the specified fields (see below). This means that even if, for example, the age range on the benefit specification does not match the age of the serviced person, the benefit specification is considered valid. No waiting period or authorization specifications are added to the list. The claim line follows a simplified case handling and skip provider network selection. See each of the steps for more details.

The lines are processed in order of their sequence attribute. The claim waits for all lines to pass through the flow before continuing to the next step, i.e., selecting the benefit specifications for ancillary lines.

Select Eligible Benefit Specifications

For each not-suspended policy product, all enabled product benefit specifications active on the claim line benefits input date are listed ^[1]. This list is further filtered on the benefit specification fields. If the benefit specification specifies:

• A maximum and/or a minimum person age, then the serviced person’s age on the claim line benefits input age date must be in between the minimum and maximum age. Such a benefit specification is not considered for evaluation if the claim line is for a serviced object.

• a person’s gender, then the serviced person’s gender must be the same. Such a benefit specification is not considered for evaluation if the claim line is for a serviced object.

• A claim form type, then the claim’s claim form must be of the same claim form type.

• Procedure groups and procedure condition, then the three claim line procedures are matched at the claim line benefits input date against the specified procedure condition and the group details of all specified procedure groups in combination with their usages:

  • In case of a specified procedure group there is a match (when the usage is set to "in") if at least one of the three claim line procedures is in the specified group; when the usage is set to "not in" there is a match if none of the claim line procedures are in the specified group (this check is performed for every specified group).

  • In case of a specified procedure condition there is a match (when the usage is set to "in") if at least one of the three claim line procedures meets the specified condition; when the usage is set to "not in" there is a match if none of the claim line procedures meet the specified condition.

  • So for example if Procedure Group 2 is specified with the usage set to 'In' then one or more claim line procedures should be part of that procedure group at the claim line benefits input date. And if Procedure Group 1 and Procedure Condition are specified with the usages set to 'In' then one or more claim line procedures should be part of that procedure group and also one or more claim line procedures should adhere to the procedure condition at the claim line benefits input date.

• A diagnosis group:

  • Without a specified diagnosis type, then the primary diagnosis on the claim line must be in that group on the claim line benefits input date if the usage is "in", or may not be in that group on the claim line benefits input date of the usage is "not in".

  • With a specified diagnosis type, then the diagnosis on the claim line of that specific type with the lowest sequence must be in that group on the claim line benefits input date if the usage is "in", or may not be in that group on the claim line benefits input date if the usage is "not in".

• A diagnosis condition:

  • Without a specified diagnosis type, then the primary diagnosis on the claim line must meet that condition of the usage is "in", or may not meet the condition if the usage is "not in".

  • With a specified diagnosis type, then the diagnosis on the claim line of that specific type with the lowest sequence must meet that condition if the usage is "in", or may not meet the condition if the usage is "not in".

• A country region or a country region group, then

  • For person the country region of the site address - at the start date of the claim line - should be equal to the country region specified or belong to the country region group specified if the usage is "in". If the usage is "not in" then the site address may not be in a country region that is either specified on the benefit specification or belongs to a group that is specified on the benefit specification. Such a benefits specification is not considered for evaluation if the claim line is for a serviced object

  • For employer the country region of the site address - at the start date of the claim line - should be equal to the country region specified or belong to the country region group specified if the usage is "in". If the usage is "not in" then the site address may not be in a country region that is either specified on the benefit specification or belongs to a group that is specified on the benefit specification.

  • For benefits provider (individual): the country region of at least one of the rendering addresses (specified on the related service addresses) - at the start date of the claim line - should be equal to the country region specified or belong to the country region group specified if the usage is "in". If the usage is "not in" then none of the rendering addresses may be in a country region that is either specified on the benefit specification or belongs to a group that is specified on the benefit specification.

  • For benefits provider (organization): the country region of at least one of the service addresses that are valid on the claim line start date should be equal to the country region specified or belong to the country region group specified if the usage is "in". If the usage is "not in" then none of the service addresses valid on the claim line start date may be in a country region that is either specified on the benefit specification or belongs to a group that is specified on the benefit specification.

• One or more benefit specification conditions, then all of them must evaluate as true for the benefit to apply. Note that the optional message that can be configured on the dynamic logic condition is ignored in this processing step.

• One or more location types, then the location type on the claim line must be among the location types on the benefit specification if the usage is "in", or may not be among the location types on the benefit specification if the usage is "not in".

• One or more modifiers, then one of the modifiers on the claim line must be among the modifiers on the benefit specification if the usage is "in", or none of the claim line modifiers may be among the modifiers on the benefit specification if the usage is "not in".

• One or more specialties, then the service specialty on the claim line must be among the specialties on the benefit specification if the usage is "in", or may not be among the specialties on the benefit specification if the usage is "not in".

All fields that are combined with a usage (in, not in) are subject to the following behavior: if the usage is set to "Not in" then any claim line that does not specify a value at all qualifies for the benefit specification. For example, if the benefit specification is configured to apply to modifiers "Not in 50 and 51" then a claim line without a modifier is also considered to qualify.

The end result of this processing step is a list of eligible benefit specification of all four subtypes, that is, waiting period, authorization, coverage and post benefits. If the claim line specifies an override coverage specification, this specification is not filtered on the conditions above. It is always considered to qualify.

The next section describes what happens if at least one of the eligible coverage benefit specifications specifies a case definition. If this is not the case, the claim line skips ahead to the "validate selection" step.

Select Distinct Case Definitions

All distinct case definitions specified on the eligible coverage specifications are selected. In the next steps, the selected case definitions are evaluated sequentially to attempt to recognize the current claim line as ancillary, primary or unrelated to the case.

If the claim line specifies an overriding coverage specification with a case definition, the line is attached to the case with the corresponding case definition as an ancillary line without evaluating the ancillary line recognition rules. If no such case exists, a new case instance is created and the line is added as a primary line without evaluating the primary line recognition rules. The next steps (Recognize Ancillary Lines and Recognize Primary Lines) are skipped for this claim line.

Recognize Ancillary Lines

First, the system attempts to recognize the claim line as part of an existing case. A claim line that is added to an existing case is referred to as an ancillary line. All pre-existing adjudication cases that (1) belong to one of the case definitions selected in the previous step and (2) apply to the serviced person or object and (3) are valid on the claim line start date and (4) are not voided, are retrieved. These are adjudication case records that have been started by another claim line. For each retrieved case, all of the ancillary recognition rules are evaluated. Each ancillary recognition rule sets the following conditions:

• If a procedure group is specified on the ancillary recognition rule, then:

  • If the usage is In, at least one of the three claim line procedures must be in that group on the claim line benefits input date.

  • If the usage is Not In, none of the claim line procedures may be in that group on the claim line benefits input date.

• If a diagnosis group is specified on the ancillary recognition rule, then:

  • If the usage is In, the claim line primary diagnosis must be in that group on the claim line benefits input date.

  • If the usage is Not In, the claim line primary diagnosis may not be in that group on the claim line benefits input date.

• If a dynamic condition is specified on the ancillary recognition rule, then it should evaluate as true.

If the current claim line meets all the conditions set by at least one of the ancillary recognition rules, then the line is recognized as a possible ancillary line to the case and the claim line is flagged for further evaluation in phase II; at this point no adjudication case details are created (yet).

Lines that have been flagged are precluded from the next step, that is, the check to see if a line is a primary line. The rationale is that a line that qualifies to be added to an existing case and would also qualify to start a new case, is always added to the existing case.

Note that it is still possible for a line to be recognized as ancillary for a case with case definition A, while it is also recognized as primary for a case with case definition B. In this situation, further selection of the benefit specifications (for example, on provider status and priority) eventually determines which takes precedence.

Recognize Primary Lines

If the claim line has not been recognized as belonging to an existing case, then Claims attempts to recognize the claim line as a primary line. A primary claim line is a line that starts a new case, rather than being added to an existing case.

For all selected case definitions for which the line was not recognized as ancillary, the following conditions are set:

• If a procedure group is specified on the case definition, then:

  • If the usage is In, at least one of the three claim line procedures must be in that group on the claim line benefits input date.

  • If the usage is Not In, none of the claim line procedures may be in that group on the claim line benefits input date.

• If a diagnosis group is specified on the case definition, then:

  • If the usage is In, the claim line primary diagnosis must be in that group on the claim line benefits input date.

  • If the usage is Not In, the claim line primary diagnosis may not be in that group on the claim line benefits input date.

• If a dynamic condition is specified on the case definition, then it should evaluate as true.

If the line meets all conditions, then it is recognized as a primary line for the case. The start date and end date of the new case are set by the functions configured on the case definition, with the primary line serving as input. The end date is allowed to remain unspecified upon creation of the case. If no dynamic logic for the start date is specified, the following message is attached to the claim line:

Code	Sev	Internal Message
CLA-FL-BENS-016	Fatal	The start date of the new adjudication case for definition {case definition code} cannot be determined because the dynamic logic for it is not specified

A new case is created for the claim line person or object. The claim line is linked to the case as the primary line. If a "Primary claim line recognition message" is specified in the case definition, this message is attached to the claim line.

If an existing, partially overlapping case for the same person or object and the same case definition exists, and that case is not voided, then either the existing case is end dated one day prior to the start date of the new case or the new case is end dated one day prior to the existing case. If the new case fully overlaps with an already existing identical case that is not voided, then a fatal message is attached to the claim line:

Code	Sev	Internal Message
CLA-FL-BENS-002	Fatal	Duplicate adjudication cases found for insurable entity {code}: set up of case definition {case definition code} is incorrect

The new case detail is still preliminary. During the Finalize step, Claims will check if the concurrent processing of claim lines has not led to a situation where identical overlapping cases have been created. See the appendix for case definition for some elaborate scenarios, clarifying the effect of a case definition.

Whenever a claim line is included in a case as either primary or ancillary, the claim line start date must lie between the case start date and end date. Failing to meet this condition results in the following product specific message:

Code	Sev	Internal Message
CLA-FL-BENS-005	Fatal	The start date of the claim line should lie between the start date and the end date of the case _({"case.startDate"}+ - {"case.endDate"})+.

All the claim lines that are candidates for becoming an ancillary claim line, either to an existing adjudication case or to an adjudication case that could be created in a subsequent claim line, are being marked for evaluation during the second phase. Note that a claim line is always marked as possible ancillary line, unless it qualifies as a primary line for each and every evaluated case definition.

When a primary line is reprocessed, and the adjudication case only includes lines from the same claim, the adjudication case is discarded and recreated; the start and end dates are set on the 'new' case. If the adjudication case is comprised of lines from several claims, then reprocessing the primary line does not discard the adjudication case. The case remains untouched, and the primary line (assuming it still qualifies as primary) is reattached to the existing case. Upon reattachment, the case start and end date are set anew.

Refine Selection on Provider Network Status

After refining the selection for adjudication cases, the remaining product benefit specifications are filtered further on whether or not the claim line benefits provider is in or out of scope of the product provider groups and benefit specification provider groups. The following paragraphs explain when a provider is considered to be in scope for a provider group. Consider the following image:

A provider is affiliated with a provider group if a provider group affiliation (valid on the claim line start date) exists between the provider and that provider group. In the image above, provider A is affiliated with provider group B.

An organization provider is a direct part of another organization provider if the organization provider refers to the other organization provider as its parent organization. Organization provider C is a direct part of organization provider D.

An organization provider is an indirect part of "parent" organization if the organization provider refers to a third organization which, in turn, is a direct or indirect part of the "parent" organization provider. In the image above, organization provider D is an indirect part of organization provider F (and any organization provider between organization provider D and F).

A provider is within the scope of a provider group if one of the following statements is true:

• The benefits provider is affiliated with the provider group on the start date of the claim line;

• The benefits provider is an organization provider and is a direct or indirect part of another organization provider that is affiliated with the provider group on the start date of the claim line;

Evaluation

The evaluation of the claimLine.processAsIn takes precedence over other evaluations including the provider group scope inheritance within a case definition. If the value of claimLine.processAsIn is "Y" then the benefits provider status is IN for all policy products.

If the claim line belongs to an adjudication case as an ancillary claim line and the case definition specifies an overriding provider group status, then that status takes precedence over the status as determined by checking the product provider group status of the benefits provider.

At this point it is possible that the provider group status is already known (through adjudication case inheritance or the processAsIN override). If so, this is the status used for the benefit selection. Regardless, the benefit provider’s provider group status is always determined, even if it is not used for the benefit specification selection. This information may be required downstream, for example for sub ledger accounting.

The product provider group scope is determined separately per policy product. If no benefits provider is specified then the status is OUT for all policy products. The provider’s status is IN if the claim line benefits provider is within the scope of at least one of the product provider groups^[2] belonging to the policy product on the claim line benefits input date.

Once the benefits provider’s status is determined for each policy product, discard any product benefit specification that

• refers to a benefit specification that has a configured product provider group scope value IN while the benefits provider’s status (for that product) is OUT;

• refers to a benefit specification that has a configured product provider group scope value OUT while the benefits provider’s status (for that product) is IN.

The result is a list of product benefit specifications that are eligible based on Product provider group scope. The final step is to filter the remaining product benefit specifications on the benefit provider’s status in context of the benefit specification provider groups^[2].

Any product benefit specification with a benefit specification that:

• has a configured specific provider group scope IN, but the benefits provider is not within scope of any of the benefit specification provider groups,

• has a configured specific provider group scope IN, but the benefits provider is not specified,

• has a configured specific provider group scope OUT, but the benefits provider is within scope of at least one of the benefit specification provider groups,

is discarded from the list.

The result is a list of all benefit specifications that are eligible based on both Product provider group scope and specific provider group scope.

Assignment Labels

It is possible for provider groups to be included in the enrollment response payload in the form of policy product provider groups (refer to the "Enrollment Callout" part of the Claims Flow chapter of the Operations Guide for more information). If an assignment label is specified on a product provider group or a benefit specification provider group, then the system tries to find policy product provider groups for the policy product in context that have a matching assignment label and that are valid on the claim line benefits input date. If the system finds one or more applicable policy product provider groups, then those provider groups are used to determine the provider group status (instead of the provider group specified on the product provider group or benefit specification provider group record itself). So if for example a product provider group specifies provider group A and assignment label CORE and two policy product provider groups exist with assignment label CORE specifying provider groups B and C, then provider groups B and C are used to determine the provider group status, that is, they replace the default network A (depicted below in scenario 1). It is also possible to extend default network A with provider groups B and C as depicted in scenario 2 below.

If an assignment label is specified without a provider group on a product provider group or benefit specification provider group record and the system cannot find a policy product provider group with a matching assignment label that is valid on the claim line benefits input date, the following product dependent fatal message is attached to the claim line:

Code	Sev	Text
CLA-FL-BENS-065	Fatal	Policy product provider group with assignment label {assignment label} cannot be be found

Storing Evaluation Results

The outcome of the provider group status determination is stored on the claim line benefit specification record. The following is stored:

• The outcome of the product provider group evaluation (IN or OUT). If IN, then the provider group that the benefits provider was in, is stored as well. If the benefits provider is connected to multiple product provider groups, only one is stored.

• The outcome of the specific provider group evaluation (IN, OUT or empty). If IN, then the provider group that the benefits provider was in, is stored as well. If the benefits provider is connected to multiple benefit specific provider groups, only one is stored. If the benefit specification does not have specific provider groups then both the specific status and group are left unspecified.

• If claimLine.processAsIn = "Y" and no overriding coverage regime or coverage specification is specified, then 'processedAsIn' on the claim line benefit specification is set to 'Y'; in this situation the processAsIn indicator is directly responsible for the claim line being processed as if the benefit provider is in one of the product provider groups. The product provider group status as determined by adjudication case inheritance is stored as well (IN, OUT or empty). If the adjudication case does not impose provider group status inheritance, then this field is left unspecified.

Example

To clarify the concept on filtering on provider group, consider the following example. The image below reflects a scenario with a single product provider group and a benefit specification with two benefit specification provider groups A en B. The numbers represent providers, the position of the number reflects the provider groups for which the provider group is considered to be within scope. For example, provider 4 is within scope of provider group B and is also in scope of provider group A, but is not within scope of the product provider group.

The first and second column represent the way that the benefit specification is configured. The third column lists for which benefit providers the benefit specification is eligible, for example a benefit specification that has product group scope IN and specific group scope IN is eligible for claim lines with benefit providers 5, 6 or 7.

Product Provider Group Scope	Benefit Spec Provider Group Scope	Applies to Providers
IN	IN	5, 6 and 7
IN	OUT	1
OUT	IN	2, 3 and 4
OUT	OUT	8
EITHER	IN	2, 3, 4, 5, 6 and 7
EITHER	OUT	1 and 8

---

1. If the policy product is suspended no benefit specifications are listed

2. Product and benefit specification provider groups can be parametrized by using assignment labels; this is described in detail in the next section