Benefit Specifications

A benefit specification specifies what a claim line should look like to qualify for an authorization requirement, waiting period, coverage or post benefits. The same benefit specification can be used by different products.

Benefit Specification

Table 1. Benefit Specification
Field	Description
Code	Unique code that identifies this benefit specification
Description	Description for this benefit specification
Type	The type of benefit specification. The benefit specification can be of the type: Coverage; Reservation; Authorization; Waiting Period or Post Benefits
Service Option Service Code	The service option service code from which the benefit specification was generated in {prodComponent}
Claim form type	Specifies what kind of claim this benefit specification applies to, e.g., professional or institutional
Procedure group usage	How should the procedure group be evaluated? In: When one or more of the procedures in the group are present on the claim line. Not In: When none of the procedures in the group are present on the claim line.
Procedure group	The group of procedures to which this benefit specification applies.
Procedure group 2 usage	How should the second procedure group be evaluated? In: When one or more of the procedures in the group are present on the claim line. Not In: When none of the procedures in the group are present on the claim line.
Procedure group 2	The second group of procedures to which this benefit specification applies.
Procedure group 3 usage	How should the third procedure group be evaluated? In: When one or more of the procedures in the group are present on the claim line. Not In: When none of the procedures in the group are present on the claim line.
Procedure group 3	The third group of procedures to which this benefit specification applies.
Procedure condition usage	How should the procedure condition be evaluated? In: When one or more of the procedures on the claim line meet the condition. Not In: When none of the procedures on the claim line meet the condition.
Procedure condition	The flexible group of procedures to which this benefit specification applies.
Diagnosis usage	To indicate In or Not in for a diagnosis group or condition.
Diagnosis group	The group of diagnoses to which this benefit specification applies.
Diagnosis condition	The flexible group of diagnoses to which the benefit specification applies.
Diagnosis type	The type of diagnoses to which this benefit specification applies.
Product provider group scope	Specifies whether this benefit specification applies when the benefits provider is IN one of the product provider groups, OUT of all of the product provider groups or EITHER way.
Regime	The regime that is applied to the claim line, when the line meets all of the conditions set by the benefit specification
Case definition	The case definition for which this benefit specification applies. This can only be specified for benefit specifications of the type 'Coverage'.
Employer region usage	In: the employer address is in the country region (group) on the benefit specification Not in: the employer address is not the country region (group) on the benefit specification
Employer region	The benefit only applies if the employer of the person or object is based in the referenced region
Employer region group	The benefit only applies if the employer of the person or object is based in the referenced group of regions
Person age from	The person start age to which this benefit specification is applicable. If it is left empty then no minimum age applies.
Person age through	The highest person age to which this benefit specification is applicable. If it is left empty then no maximum age applies.
Person gender	This specification only applies to persons of the specified age. If it is left empty, then it applied to both genders.
Person region usage	In: the person address is in the country region (group) on the benefit specification Not in: the person address is not the country region (group) on the benefit specification
Person region	The benefit only applies if the person is based in the referenced region
Person region group	The benefit only applies if the person is based in the referenced group of regions
Provider specific group scope	In: the benefits provider on the claim line is associated with at least one the provider groups on the benefit specification Not In: the benefits provider on the claim line may not be associated with any of the provider groups on the benefit specification
Provider region usage	In: the benefits provider address is in the country region (group) on the benefit specification Not in: the benefits provider address is not the country region (group) on the benefit specification
Provider region	The benefit only applies if the servicing provider is based in the referenced region
Provider region group	The benefit only applies if the servicing provider is based in the referenced group of regions
Auth missing?	If this indicator is checked, then this specification will be evaluated only in the event that an authorization is required, but is not found. This can only be specified for benefit specifications of the type 'Coverage'.
Consume authorization?	If this indicator is unchecked, then the claim line on which the benefit specification is applied will not write consumption on returned authorizations. This can only be specified for benefit specifications of the type 'Authorization'.
Priority	The priority of the specification: the smallest priority value is the one that takes precedence.
Location type usage	In: the location type on the claim line matches against one of the location types on the benefit specification Not In: the location type on the claim line may not be among the location types on the benefit specification
Modifier usage	In: at least one of the modifiers on the claim line match against one of the modifiers on the benefit specification Not In: none of the modifiers on the claim line can match against the modifiers on the benefit specification
Specialty usage	In: the specialty on the claim line matches against one of the specialties on the benefit specification Not In: the specialty on the claim line may not be among the specialties on the benefit specification

A benefit specification can have one or more benefit specification provider groups:

Benefit Specification Provider Group

Table 2. Benefit Specification Provider Group
Field	Description
Benefit specification	The benefit specification
Provider group	The provider group
Assignment label	The qualifying label for the assignment of the provider group; if specified the system will use the policy product provider group(s) with a matching assignment label when determining network status in the claims flow

Constraints:

At least one of provider group and assignment label must be specified

A benefit specification can have one or more benefit specification conditions:

Benefit Specification Condition

Table 3. Benefit Specification Condition
Field	Description
Benefit specification	The benefit specification
Condition	A dynamic logic condition that serves as a condition that must be met by a claim line, if the benefit specification is to apply.

A benefit specification can have one or more location types:

Benefit Specification Location Type

Table 4. Benefit Specification Location Type
Field	Description
Benefit specification	The benefit specification
Location type	The location type

A benefit specification can have one or more location types:

Benefit Specification Modifier

Table 5. Benefit Specification Modifier
Field	Description
Benefit specification	The benefit specification
Modifier	The modifier

A benefit specification can have one or more location types:

Benefit Specification Specialty

Table 6. Benefit Specification Specialty
Field	Description
Benefit specification	The benefit specification
Specialty	The specialty

The following restrictions apply to a benefit specification:

The following fields can only be specified on coverage specifications:
- Case Definition
- Auth missing? (mandatory)
The following fields can only be specified on authorization specifications:
- Consume authorization? (mandatory)
For a coverage specification without a case definition one or more procedure groups and/or procedure conditions must be specified.
For a reservation specification one or more procedure groups and/or procedure conditions must be specified.
For an authorization specification one or more procedure groups and/or procedure conditions must be specified.
For a waiting period specification one or more procedure groups and/or procedure conditions must be specified.
For a post benefits specification one or more procedure groups and/or procedure conditions must be specified.
The procedure group usage must be specified when a procedure group is used and may not be specified when a procedure group is not used (this applies to all three procedure groups).
The procedure condition usage must be specified when a procedure condition is used and may not be specified when a procedure condition is not used.
A benefit specification may contain either a diagnosis group or a diagnosis condition but cannot contain both
If one of the two is specified, then the diagnosis usage must also be specified
A diagnosis type may only be specified when a diagnosis group or a diagnosis condition is specified
The product provider group scope is a mandatory field.
The specific provider group scope is a mandatory field if, and can only be specified if at least one benefit specification provider group exists.
The location type usage must be specified when a location type list is used and may not be specified when a location type list is not used.
The modifier usage must be specified when a modifier list is used and may not be specified when a modifier list is not used.
The specialty usage must be specified when a specialty list is used and may not be specified when a specialty list is not used.
The country region usage must be specified when a country region (group) is used and may not be specified otherwise. This applies separately for the person, provider and employer country region.

Provider Group Scope

The product provider group scope cannot be unspecified. If the value is IN, then the benefit specification applies only if the claim line benefits provider is within the scope of at least one of the product provider groups on the service date. If the value is OUT, then the benefit specification applies only if the claim line benefits provider is not within the scope of any of the product provider groups on the service date. If the value is EITHER , then the benefit specification applies regardless of specified product provider groups.

In case it is specified, the specific provider group is evaluated as follows: If the value is IN, then the benefit specification applies only if the claim line benefits provider is within the scope of at least one of the benefit specification provider groups on the claim line start date; If the value is OUT, then the benefit specification applies only if the claim line benefits provider is not in any of the benefit specification provider groups on the claim line start date.

The benefits provider is considered to be within scope of a provider group if that provider can be traced back to the provider group by traversing the path of organization providers and provider groups in between. In other words, at least one of the following statements must be true: (1) The benefits provider is affiliated with the provider group, (2) the benefits provider is an organization provider that is part of a greater organization provider that is affiliated with the provider group, or (3) the benefits provider is an individual provider and is affiliated with an organization provider that is affiliated with the provider group, either directly or because it is part of an organization that is affiliated with that group.

Diagnoses and Procedures

A benefit specification can specify either a diagnosis group or a diagnosis condition in combination with an optional diagnosis type. A diagnosis group defines a time valid list of diagnoses. A diagnosis condition defines a virtual group of diagnoses that consists of all diagnoses that meet the condition. If the diagnosis type is not specified, both the group and the condition are evaluated based on the primary diagnosis on a claim line. If the diagnosis type is specified, both the group and the condition are evaluated based on the diagnosis of that type on a claim line. The evaluation depends on the value of the diagnosis usage field. With regard to diagnoses, a benefit specification applies when:

Neither a diagnosis group nor condition is specified
A diagnosis group is specified, the diagnosis usage has value "In" and the applicable^[1] claim line diagnosis is in the diagnosis group on the claim line start date.
A diagnosis group is specified, the diagnosis usage has value "Not in" and the applicable^[1] claim line diagnosis is not in the diagnosis group on the claim line start date.
A diagnosis condition is specified, the diagnosis usage has value "In" and the applicable^[1] claim line diagnosis meets the diagnosis condition.
A diagnosis condition is specified, the diagnosis usage has value "Not in" and the applicable^[1] claim line diagnosis does not meet the diagnosis condition.

Procedures are evaluated in a similar manner. The three claim line procedures are matched at the claim line start 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.

Benefit Specification Conditions

The benefit specification meta model offers fields for the most common dimensions that drive the eligibility of benefit specifications, such as diagnoses, procedures, and providers. Benefit specification conditions are meant to impose conditions that cannot be captured by the benefit specification meta model. Consider the following examples. In order for a benefit to apply:

The service provider must have a particular specialty;
A dynamic field on the claim (e.g., placeOfService) must have a certain value.
A dynamic field on the person(e.g., studentStatus) must have a certain value.

Benefit specification conditions refer to dynamic logic conditions. The condition can be based on any field on the claim line, or any field that can be derived from the claim line, such as a field on the claim header. The outcome of the condition is either 'true' or 'false'.

In dynamic logic conditions the properties of the direct or of the related objects can be compared to each other or a literal value. For example, the specialty of the servicing provider can be compared to the literal value 'PT'. If the specialty of the servicing provider is equal to PT then the dynamic logic condition evaluates true. Otherwise the dynamic logic condition evaluates false.

In order for a benefit specification to apply, either no benefit specification conditions are specified or all associated benefit specification conditions must evaluated to be true.

Person Age and Gender

Benefits can vary per age and gender in case of serviced person. This can be set up using the fields: age from, age to and gender. The age of the person to which a service has been rendered by a provider needs to be between the age limits that are indicated on the benefit specification. For example when a product contains 2 benefit specifications:

Procedure group: 'Physical therapy' , Age from: 0, Age to: 17, Regime: Fully covered
Procedure group: 'Physical therapy' , Age from: 18, Age to: empty, Regime: 20% Coinsurance

then a person who is 18 at the service date will get a 20% coinsurance applied. A person who is 17 or younger will get no coinsurance applied.

Configuration Examples

Setting Parameters

Consider the image below. It shows he configuration for a COPAYMENT cover withhold rule using a parameter to set the dollar amount

Both therapy visits and office visits require a COPAYMENT, which is a withhold of a specific amount. The only difference between the two types of visits is that therapy visits require a 20 dollar copayment, while office visits only require a 10 dollar copayment. Rather than setting up two separate coverage regimes, the benefits configuration user chooses to set up a single coverage regime that withholds COPAYMENT without specifying an actual amount.

On the product benefit specification level, the benefits configuration user sets up two parameters: the first to specify that for THERAPY visits, any cover withhold rule that applies COPAYMENT should use an amount of 20; the second to specify that for OFFICE visits, any cover withhold rule that applies the COPAYMENT should use an amount of 10.

Benefit Specification Priority

Consider the following scenario a product contains a standard benefit for hair prosthesis. This benefit applies to both women and men of all ages, and requires a $10 copay. This is implemented by the following benefit specification.

Table 7. Benefit Specifications
Code	Prio	Gender	Age From	Age Through	Regime
HP1					$10 Copay

A year after the product is in use, new legislation is becomes effective, saying that all hair prosthesis for men between 30 and 49 is covered in full. This is an exception to the standard implemented by the plan, which takes $10 copay, so the configuration user is assigned the task to alter the product configuration. The user has two options. The first option is create a number of mutually exclusive benefit specifications. This would lead to the following configuration:

Table 8. Benefit Specifications Priority
Code	Gender	Age From	Age Through	Regime
HP1	Female			$10 Copay
HP2	Male		29	$10 Copay
HP3	Male	30	49	Covered in full
HP4	Male	50		$10 Copay

This option would require the user to alter the existing benefit specification and create three new ones. The other option is to use the benefit specification priority field. This approach is more concise. This requires that the user tags the existing benefit with the product "default" priority label and the mandated benefit with the "mandate" priority. This would lead to the following configuration:

Table 9. Benefit Specifications Configuration
Code	Prio	Gender	Age From	Age Through	Regime
HP1	Product Default				$10 Copay
HP2	Mandate	Male	30	49	Covered in full

The priorities are set up such that "Mandate" takes precedence over "Default". When a claim line is adjudicated against this benefit, and the person is a male between 30 and 49, the application will know to apply the mandated benefit because it has a higher priority than the product default.

Priority and Case Benefits

Consider the following scenario. Two separate case definitions have been configured; case definition C1 and definition C2. Case Definition C1 starts a new case if it detects a claim line with procedure code "123". Case definition C2 starts a new case when both of the following conditions are met: the claim line has the procedure code "456" and, within the same claim, there is another a line with procedure code "123". The underlying business logic is that if a claim contains both procedure codes, it should start a C2 case; if contains just the "123' code, it should start a C1 case.

Whenever a claim qualifies to start a C2 case, it will also qualify to start a C1 case. This means that the benefit configuration must be set up in such a way that C2 takes precedence over C1. Not doing so would result in a system denial of the claim, as the application cannot choose which benefit to apply: the one associated with C1 or the one associated with C2.

The way to configure this is by using the benefit specification priority. The benefit specification priorities have been configured so that "Product Priority" takes precedence over "Product Default":

Benefit Specifications

Table 10. Priority and Case Benefits
Code	Prio	Case Definition
BESP1	Product Default	C1	$500 Copay
BESP2	Product Priority	C2	$700 Copay

The effect of this configuration is that when a claim comes in with both procedure codes "123" and "456", the initial selection of benefit specification will yield both BESP1 and BESP2. After the initial selection the application detects that BESP2 has a higher priority. That means that it will drop BESP1 from the selection and create a case of definition C2.

1. Primary diagnosis or diagnosis of a specific type if specified on the benefit specification