Case Definitions
A case is a bundling of related claim lines possibly across claims. The case definition specifies how to recognize claim lines that are part of a case.
Purpose
Within OHI Claims, a case has two specific functional purposes:
-
The start of a case is used as a reference point in time when applying a benefit. For example, consider the benefit: a person is fully covered for all physical therapist consults for the first 30 days after a newly diagnosed bone fracture. In order to calculate whether a service date is within those 30 days, OHI Claims has to know when the fracture was diagnosed, i.e., when a new case started.
-
A case as a whole is used to differentiate over coverage specifications. So a case of the category 'Tibia Fracture' can have a regime that specifies a $200 copay, while a case of the category 'Cosmetic Surgery' has a $400 copay.
Concepts
First the concepts that are used to configure the rules to
-
Recognize a case
-
Apply benefits to a case
Case Definition
A case definition defines when and how to recognize a new case and how to include claim lines in an existing case.
Case Definition
| Field | Description |
|---|---|
Code |
The code of the case definition |
Description |
The description of the case definition |
Active? |
If unchecked, then no new reference to this case definition can be made |
Start Dynamic Function |
The dynamic logic function that is used to determine the start date of the case. This dynamic function will be executed when the case for a person or object is first recognized. The primary claim line that triggers the recognition of a new case is the input to this dynamic function |
End Dynamic Function |
The dynamic logic function that is used to determine the end date of a case. This dynamic logic will be executed when
|
Primary Claim Line Recognition Message |
The message that is attached to a claim line when the claim line is recognized as primary. The substitution parameters for this message are
|
Ancillary Claim Line Recognition Message |
The message that is attached to a claim line when the claim line is recognized as ancillary. The substitution parameters for this message are
|
Message for Ancillary |
The message that is applied to the ancillary claim lines when the primary claim line has one or more fatal messages [1]. The substitution parameters for this message are
|
Inheritable Primary Provider Group Scope |
The provider group scope that can be inherited by the ancillary claim lines. |
Primary Claim Line 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. |
Primary Claim Line Procedure Group |
To start a case a primary claim line must be recognized. A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as primary claim line. |
Primary Claim Line 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. |
Primary Claim Line Procedure Group 2 |
To start a case a primary claim line must be recognized. A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as primary claim line. |
Primary Claim Line 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. |
Primary Claim Line Procedure Group 3 |
To start a case a primary claim line must be recognized. A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as primary claim line. |
Diagnosis Group Usage |
To indicate In or Not in the Diagnosis Group |
Primary Claim Line Diagnosis Group |
A claim line must have a primary diagnosis in this diagnosis group to be recognized as primary claim line. |
Primary Claim Line Condition |
A dynamic logic condition, that is used to determine whether a claim line is a primary claim line. This condition must be evaluated to true for a claim line to be recognized as a primary claim line. |
[1]
A case can be used for a number of purposes
-
to group claim lines together for a benefit limit or a withhold limit per case
-
to apply a message to the ancillary lines if the primary line is denied
-
to use the same provider group scope for the ancillary lines as for the primary line
-
to select the benefit regime based on the fact that an a claim line is bundled in a case.
The following restrictions apply to a case definition:
-
Diagnosis group usage and primary diagnosis group of case definition should both be filled or both be left empty.
-
At least one of primary procedure groups, primary diagnosis group and primary condition for case definition should be specified.
-
The procedure group usage (In/Not in) must be specified when a procedure group is used and may not be specified when a procedure group is not used.
Ancillary Inclusion Rule
An ancillary inclusion rule specifies under which conditions a claim line is eligible to be attached to an existing case. This rule specifies multiple conditions: conditions on the procedure, a condition on the primary diagnosis and a dynamic condition. A claim line can only be attached to an existing case if that case is for the same person or object and the service date of the claim line is between the start and the end date of the existing case.
When a claim line is processed it is always first checked if the claim line can be included in an existing case. If the claim line cannot be included then the claim line is tested to be recognized as the primary line that starts a new case.
Ancillary Inclusion Rule
| Field | Description |
|---|---|
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 |
A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as ancillary claim line. |
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 |
A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as ancillary claim line. |
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 |
A claim line must have (with usage specified as In) or may not have (with usage specified as Not In) a procedure in this procedure group to be recognized as ancillary claim line. |
Diagnosis Group Usage |
To indicate In or Not in a Diagnosis group |
Diagnosis Group |
If the diagnosis group usage is "In" and the primary diagnosis on the claim line is included in this diagnosis group on the service start date, then this condition is met. If the diagnosis group usage is "Not in" and the primary diagnosis on the claim line is not included in this diagnosis group on the service start date, then this condition is met. If no diagnosis group is specified, then this condition is also considered to be met. |
Dynamic Condition |
The dynamic logic condition that is used to pose additional criteria on the claim line. The dynamic logic has access to the current claim line that is considered for inclusion and to the primary claim line of the existing case. In the event that the dynamic condition evaluates to be true, then this condition is met. If no dynamic condition is specified, then this condition is also considered to be met. |
Case Definition |
When all conditions are met, the claim line is included in a case of this case definition. |
Note that it is allowed to have multiple ancillary inclusion rules for the same case definition. If for one of the ancillary inclusion rules all the fields evaluate to true, the claim line is included as an ancillary line.
The following restrictions apply to an ancillary inclusion rule:
-
Diagnosis group usage and diagnosis group of ancillary inclusion rules should both be filled or both be left empty.
-
At least one of procedure groups, diagnosis group and condition for ancillary inclusion rules should be specified.
-
The procedure group usage (In/Not in) must be specified when a procedure group is used and may not be specified when a procedure group is not used.
Benefit specification
When a claim line is recognized as included in a case the benefit specification is selected based on the Case definition that is attached to the claim line. This takes precedence over the benefit specifications that are selected based on procedure and diagnosis code. If a benefit specification cannot be found based on the case definition then a benefit specification is selected based on procedure and diagnosis.
| The consequence of the rule that 'if a claim line is part of a case that the benefit regime is selected based on the case that the line is included in' is that the benefit regime applied to all lines included in the case is the same benefit regime. This means that deductibles, coinsurance and copayment for all lines in the case are calculated using the same regime. |
Adjudication Case
The results of the recognition of a case are stored in the adjudication case and adjudication case detail entities. An adjudication case is a group of claim lines that belong to the same episode of care.
Adjudication Case
| Field | Description |
|---|---|
Case Definition |
The case definition to which this case belongs |
Insurabe Entity |
The person or object (insurable entity) for which the case has been recognized |
Start Date |
The date when the case started |
End Date |
The date when the case ended |
Void? |
Should the case be voided so that it is ignored in claims processing? |
For each case definition, OHI Claims will keep track of the regime and limit counters. Case regime counters are used to determine which tranche to apply in a case based regime. Case limit counters are used to keep track of monetary or numbers limits on the regime, e.g., a maximum copay per case
The start date of a case is determined when the case is first recognized. This is done by executing the start dynamic logic function of the case definition whenever the case is stored during claims processing. Alternatively, a case plus primary claim line can come in through the Case Integration Point; in this instance, the start date should be provided for by the IP.
The end date of a case can be determined in four ways
-
When the case is first recognized. The end dynamic function is executed when the case is first recognized. This is done using the primary claim line as the triggering line. This implies that the logic in the end dynamic function is executed using the data of the primary line. If the end date is not determined by the primary line the end dynamic function returns an empty result instead of a date.
-
When an ancillary line is recognized. The end dynamic function is executed for each ancillary line that is included in the case. If the end date is determined by an ancillary line then the end dynamic function must return the end date.
-
When a new case is recognized for the same person or object and with the same case definition. The "old" case is then ended at the day before the start date of the new case.
-
When the end date is provided for through the Case Integration Point.
The option to void a adjudication case supports remediation in the situation where an existing adjudication case is in conflict with the adjudication cases created by other claims, such as a time overlap. A voided adjudication case is ignored in claims processing. This means the adjudication case does not raise time overlap violations, nor is it available when the system considers adding ancillary claims.
Adjudication Case Details
This entity is a crosswalk between claim lines and the case in which they are included a either primary or ancillary line.
Adjudication Case Detail
| Field | Description |
|---|---|
Case |
The case to which the specified claim line belongs. |
Subtype |
Primary or Ancillary. |
Claim Line |
The internal claim line that is a primary or ancillary case line. |
Description |
The description of the adjudication case detail |
Provider Group Scope |
The provider group scope of the primary claim line |
Indicator Denied |
Is the external primary claim line denied? |
Exactly one claim line must be specified as the primary case line. A claim line can be included in multiple cases, but only in one case per case definition.
Use case A
This use case illustrates a case that is used to
-
enforce a limit on all the procedures that are included in a hospital admission.
-
apply one copay for all the procedures included in a hospital admission
-
deny all the ancillary procedures if the primary procedure is denied
-
apply the provider group scope "IN" to the ancillary services if the primary service is "IN"
Case Definition
| Field | Description |
|---|---|
Code |
HOSPADM |
Description |
Hospital Admission |
Start Dynamic Function |
Primary claim line admission date |
End Dynamic Function |
Primary or ancillary claim line discharge date |
Primary Claim Line Recognition Message |
This claim line started a {0} case with start date {2} and end date {3} |
Ancillary Claim Line Recognition Message |
This claim line was included in a {0} case with start date {2} and end date {3} |
Message for Ancillary |
Ancillary services are denied, because primary service in claim {0}, line {1} is denied. |
Inheritable Primary Provider Group Scope |
IN |
Primary Claim Line Procedure Group Usage |
IN |
Primary Claim Line Procedure Group |
Room and Board procedures |
Primary Claim Line Diagnosis Group |
|
Primary Claim Line Condition |
Claim line is inpatient by bill type or location |
Ancillary Inclusion Rule
| Field | Description |
|---|---|
Procedure Group Usage |
IN |
Procedure Group |
LAB WORK AND RADIOLOGY |
Diagnosis Group Usage |
|
Diagnosis Group |
|
Dynamic Condition |
|
Case Definition |
HOSPADM |
The case definition is used in a benefit specification, that applies the 'ADMISSION REGIME' to the claim lines that are included in the case.
Benefit specification
| Field | Description |
|---|---|
Type |
Coverage |
Case Definition |
HOSPADM |
Regime |
ADMISSION REGIME |
Limited to |
|
Age from |
0 |
Age to |
150 |
The following limits are set up:
-
<Cover> limit <HOSPADM10000> per <Case> of <$10000>
-
<Withhold> limit <COPAYADM100> per <Case> of <$100>
These limits are used in the following cover withhold rules in the 'ADMISSION REGIME'
-
<Cover><100%> of the <original> on the <original> amount as <Coverage>.
-
Count towards <HOSPADM10000> and <Stop> when reached.
-
-
<Withhold><100%> of the <remaining amount> as <Copay>
-
Count towards <COPAYADM100> and <Stop> when reached
-
Use case B
This use case illustrates a case that is used to enforce a limit of 9 visits in the number of covered PT visits per case per year.
Case Definition
| Field | Description |
|---|---|
Code |
PT CASE |
Description |
Physical therapy |
Start Dynamic Function |
Primary Claim line Service Date |
End Dynamic Function |
|
Primary Claim Line Recognition Message |
This claim line started a {0} case with start date {2} and end date {3} |
Ancillary Claim Line Recognition Message |
This claim line was included in a {0} case with start date {2} and end date {3} |
Message for Ancillary |
|
Inheritable Primary Provider Group Scope |
|
Primary Claim Line Procedure Group Usage |
IN |
Primary Claim Line Procedure Group |
PT procedures |
Primary Claim Line Diagnosis Group |
|
Primary Claim Line Condition |
Ancillary Inclusion Rule
| Field | Description |
|---|---|
Procedure Group Usage |
IN |
Procedure Group |
PT Procedures |
Diagnosis Group Usage |
|
Diagnosis Group |
|
Dynamic Condition |
Claim line is not flagged as 'New case' |
Case Definition |
PT CASE |
The case definition is used in a benefit specification, that applies the 'PT CASE REGIME' to the claim lines that are included in the case.
Benefit specification
| Field | Description |
|---|---|
Type |
Coverage |
Case Definition |
PT CASE |
Regime |
PT CASE REGIME |
Limited to |
|
Age from |
0 |
Age to |
150 |
The following limits are set up:
-
<Cover> limit <PTCASE9> per <Case per calendar year> of <9>
These limits are used in the following cover withhold rules in the 'PT CASE REGIME'
-
<Cover><100%> of the <original> on the <original> amount as <Coverage>.
-
Count towards <PTCASE9> and <Stop> when reached.
-
Use case C
This use case illustrates the use of a case to pay the first 5 visits within a case at 80% and the next 5 visits at 60% and the next 5 visits at 40%. After that the coverage is 0%.
Case Definition
| Field | Description |
|---|---|
Code |
TIBFRAC |
Description |
Tibia fracture |
Start Dynamic Function |
Primary Claim line Service date |
End Dynamic Function |
|
Primary Claim Line Recognition Message |
This claim line started a {0} case with start date {2} and end date {3} |
Ancillary Claim Line Recognition Message |
This claim line was included in a {0} case with start date {2} and end date {3} |
Message for Ancillary |
|
Inheritable Primary Provider Group Scope |
|
Primary Claim Line Procedure Group Usage |
IN |
Primary Claim Line Procedure Group |
PT sessions |
Primary Claim Line Diagnosis Group |
Tibia fracture diagnoses |
Primary Claim Line Condition |
Ancillary Inclusion Rule
| Field | Description |
|---|---|
Procedure Group Usage |
IN |
Procedure Group |
PT sessions |
Diagnosis Group Usage |
IN |
Diagnosis Group |
Tibia fracture diagnoses |
Dynamic Condition |
Claim line is not flagged as a new case |
Case Definition |
TIBFRAC |
The case definition is used in a benefit specification, that applies the 'TIBFRAC REGIME' to the claim lines that are included in the case.
Coverage Regime
| Field | Description |
|---|---|
Code |
TIBFRAC REGIME |
Description |
Regime for tibia fractures |
Indication Repetitive |
No |
Reference |
Case |
Because the distinction in coverage is made over the number of visits and not over time the coverage regime period has no time boundaries. Within the coverage regime period the following tranches with the corresponding rules apply
-
Tranche with a maximum of <5> claimed units:
-
<Cover><80%> on the <original> allowed amount as <Coverage>
-
-
Tranche with a maximum of <5> claimed units:
-
<Cover><60%> on the <original> allowed amount as <Coverage>
-
-
Tranche with a maximum of <5> claimed units:
-
<Cover><40%> on the <original> allowed amount as <Coverage>
-
-
Tranche with a maximum of <unspecified> claimed units:
-
<Cover><0%> on the <original> allowed amount as <Coverage>
-