Reservation Selection Claim Classification and Episode Detection

Reservation selection consists of selecting the right reservation specification and using the reservation regime to connect the claim line being processed to the right reservation line - if any.

Claim Classification and Episode Detection are both instruments to flag a claim line and/or a claim in order to use those flags later on, typically during pricing. While the processing unit is - as always - the claim itself, the scope of both instruments is different. Claim Classification stays restricted to the claim at hand while Episode Detection will often span multiple claims.

Pre Reservation Derivation Rules

Before the reservation selection starts, the application derives the two dates it needs for benefit specification selection; these dates are used in the selection of reservation specifications in this flow, as well as in the selection of the other benefit specifications (waiting period, authorization, coverage and post benefits) later in the flow.

Derivation rules are user configured rules that update the value of certain fields on a claim, bill or claim line. At this point in the flow, only derivation rules are executed for which the "step" field has the value "Pre Reservation".

The following pre reservation process field derivation rules on the claim line are evaluated:

1. claimLine.benefitsAgeInputDate

2. claimLine.benefitsInputDate

Benefits age input date and benefits input date are required fields later in the claims flow. If these fields are not set directly after the process field derivation rules, the following fatal messages are attached to the claim line, dependent on the missing attributes:

Code	Sev	Text
CLA-FL-CLAS-004	Fatal	Benefits selection requires the benefits age input date to be specified
CLA-FL-CLAS-005	Fatal	Benefits selection requires the benefits input date to be specified

These messages get the origin PRE PRICING

Derivation rules are evaluated even if a fatal message is attached to (any level of) the claim. Note that claim line level derivation rules are not evaluated for locked claim lines and replaced claim lines. Refer to the text on derivation rules in the implementation guide on Process Rules for more details.

Reservation Selection

In this step the application attempts to find a reservation benefit specification that matches the claim line. If one is found, it means the claim line requires a reservation. Next, the application attempts to find that reservation, based on the configured reservation regime.

This step is skipped for a reservation line, quote line, a locked claim line or a claim line with a checked keep benefits indicator or with an checked external benefits indicator. If an error is attached to the claim line during reservation selection, it gets the origin RESERVATION

Clean Up Reservation Results

The messages attached to the claim, claim line and bill that were attached in a previous reservation selection step are removed. Note that claim and bill messages are only removed if at least one non-replaced and non-locked claim line has an unchecked 'Keep Benefits' indicator.

In addition, any claim benefit specifications that references a reservation specification, is removed and the link to a reservation line is nullified. This way, a clean slate is provided as a start for the selection of reservation specifications to be (re)done.

Select Policy Products

If a claim line specifies an overriding coverage regime or an overriding coverage specification, then the flow skips further parts for the reservation selection

Otherwise, per claim line, the person’s or object’s products returned in the enrollment response are filtered on date (only policy products that are valid on the claim line start date are used for benefit specification selection).

Policy product selection is not performed for claim 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*: SANITY CHECKS, ENROLLMENT, PRE PRICING.

^* In case of fatal messages of other origins, it is desirable to do the selection of policy products, in order to determine the person’s or object’s product (if any) and consequent eligibility for coverage. This information can be used in determining whether a denied claim line files under provider liability or under adjudication liability.

The outcome is a list of time valid policy products that serves as input for the selection of the reservation specifications.

Select Reservation Specifications

The selection of reservation specifications follows the same flow as described in Select Benefit Specifications. Because reservation specifications do not have a reference to case definitions, that part of the flow will not be executed and therefore no new cases will be created.

Validate Selection

The result of the preceding steps is a list of eligible reservation specifications. Per product, only one product reservation specification can be applied. If more than one reservation specification is found for a certain product, the list is ordered by the benefit priority of the reservation specification. The lower the priority field value, the higher the priority. If a reservation specification has no priority value, then this is interpreted as the lowest possible priority. This way, only a single reservation specification should have the highest priority for a certain product. If not, the following product dependent fatal message is attached to the claim line:

Code	Sev	Text
CLA-FL-CLAS-006	Fatal	{number of found benefit specs} reservation specifications have been found with the same priority for this claim line: {code1}, {code2}, {code3}, {code4}, {code5}

When no fatal message is issued, the claim line reservation specification is stored.

Find Matching Reservation Line

Before the evaluation, the claim line is checked for product specific fatal messages that apply to the same product as the reservation specification. If found, then the evaluation of the reservation regime stops.

The function dynamic logic that is configured on the reservation regime, is applied, resulting in one (or none) reservation line as output (see the Implementation Guide for Dynamic Logic, section on functions).

If a reservation line is found it is attached to the claim line which may lead to the following messages:

• if the reservation line has the status DENIED and the message for denied is configured in the reservation regime, then this message is attached to the claim line

• if the reservation line belongs to a claim that is not finalized, the following fatal message is attached to the claim line:

Code	Sev	Text
CLA-FL-CLAS-007	Fatal	It is not allowed to select a reservation line that is still being processed.

Note that it is possible to link to a locked line.

In the event that no reservation is found, then the "not found" message specified on the regime is applied. The severity of this message can be either fatal or informative. If fatal, this effectively means that claims line is denied because the reservation was not present.

Note that the other messages that can be configured on the reservation regime (not met, met, met and exceeded, exceeded) are attached later in the flow, i.e., when calculating consumption; the same applies to the exceeded coverage label.

Note that by finding the matching reservation before the callout rules, the reservation line information can be used in a callout rule, later in the flow.

In case of multiple products, the reservation regimes are evaluated in order of product priority. The lower the priority field value, the higher the priority. If a product has no priority value, then this is interpreted as the lowest possible priority. In the event that two different products in the list have the same priority, or if both have a null priority, the following product independent fatal message is generated:

Code	Sev	Text
CLA-FL-CLAS-008	Fatal	Policy products found with same priority for serviced person {code} on date {date}

After a reservation line has been found by the matching function, the search stops - so no subsequent product needs to be evaluated.

Claim Classification

The first step of claim classification is to determine which classification scheme to use, as described in the Pre Pricing Checks. If, as a result, exactly one classification scheme is found, it is stored on the claim header and will now be used to classify further. If a classification scheme is found, this scheme is used to first classify claim lines one by one and then rolling up that information to the claim

Pre Classification Callout Rules

This is the first possible point for callout rules to trigger. If the response to a callout takes the form of a claims update request, the claim is immediately reset to the CHANGE status to do the requested updates. Otherwise, the claim continues in the claims flow.

Callout rules are evaluated even if a fatal message is attached to (any level of) the claim.

Refer to the text on callout rules in the implementation guide on Process Rules.

Claim Line Classification

For each non-replaced and non-locked claim line in the claim, the classification scheme is used to classify the claim line. This is done in two consecutive parts:

1. all the fixed dimensions of classification scheme details are matched against the claim line

2. all the dynamic dimensions of the remaining classification scheme details are matched against the claim line

This step is not executed if the classification scheme of the claim could not be determined, or if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT or RESERVATION) exists that is attached to the claim line (directly or inherited).

Evaluation of fixed dimensions

A claim classification scheme detail consists of the following fixed dimensions that all need to match the claim line at hand for the claim classification scheme detail to be applicable:

• time validity
  The price input date should lie between the start and end date

• procedure groups and/or conditions
  The three claim line procedures are matched at the price Input date against the group details of all specified procedure groups and/or procedure conditions. There is a match if at least one of the three claim line procedures is in the specified procedure group/condition at the price Input date (this check is performed for every specified group and condition). So for example if Procedure Group 2 is specified then one or more claim line procedures should be part of that procedure group at the price input date.

• diagnosis group or condition
  If specified in combination with diagnosis group usage 'In': one of the diagnoses in the diagnosis group or condition should match the primary diagnosis of the claim line. If specified in combination with diagnosis group usage 'Not in': none of the diagnoses in the diagnosis group or condition should match the primary diagnosis of the claim line.

• location type group
  If specified in combination with location type group usage 'In': one of the location types in the location type group should match the location type of the claim line (either directly or inherited from bill or claim). If specified in combination with location type group usage 'Not In': none of the location types in the location type group should match the location type of the claim line (either directly or inherited from bill or claim).

• provider group
  The priceIndividualProvider or the priceOrganizationProvider of the claim line should be in the provider group at the price input date (if price input date not available then at claim line start date).

• provider category
  For an in detail description, see Select ProviderPricing Clauses.

• product category
  For an in detail description, see Select ProviderPricing Clauses.

• modifier list
  If specified in combination with modifier usage 'In': at least one of the modifiers in the list of the claim classification scheme detail should be present on the claim line. If specified in combination with modifier usage 'Not In': none of the modifiers in the list of the claim classification scheme detail should be present on the claim line.

• condition dynamic logic
  Claim line level dynamic logic condition to validate that the classification scheme detail is applicable to the claim line.

• condition dynamic logic on authorization
  This dynamic logic is intended to determine if the classification scheme detail is applicable to the claim line based on the presence of an authorization. If specified, the classification scheme detail only applies if the referenced condition returns "True" for any of the serviced person’s or object’s authorizations. For this, the person’s or object’s authorizations are evaluated against the specified condition, one by one, new to old. When an authorization is 'hit' that returns 'True', this classification scheme detail applies to the claim line and the authorization is stored on the claim line - further evaluation of authorizations is then omitted.

Evaluation of dynamic dimensions

After the evaluation of the fixed dimensions of the claim classification scheme details, only a subset of the claim classification scheme details will remain. For all the details in that subset, the classification scheme detail condition (stored on the classification scheme itself) needs to be evaluated. This condition specifies how dynamic fields on the classification scheme details are compared to the fields (fixed or dynamic) of the claim line. For a more technical description, see the Implementation Guide on Dynamic Logic.

When no classification scheme detail applies, the claim line is not classified. This is not considered an error and does not result in attachment of a message to the claim. When more than one classification scheme detail applies, the detail with the highest priority takes precedence. It is considered a configuration error when multiple details apply that share the same highest priority. In that case the claim line is not classified and the following message is attached to the claim line:

Code	Sev	Text
CLA-FL-CLAS-001	Fatal	Claim line is not classified because different applicable claim classification scheme details share the same highest priority

When this error message occurs the following message is attached at claim level (if not already attached):

Code	Sev	Text
CLA-FL-CLAS-002	Fatal	Claim is not classified because a claim line could not be classified due to a fatal message.

Claim Classification

When all claim lines have been classified without errors, the claim itself is classified; note that the situation where one or more claim lines did not get a classification is a valid one as long as the classification of those claim lines did not lead to an error. For this, the claim line classification that was determined by the classification scheme detail with the highest priority is also stored on the claim header. I.e. the claim is classified the same as its claim line with the 'most important' classification. When multiple claim lines with a different classification share the same highest priority the claim cannot be classified and the following message is attached to it:

Code	Sev	Text
CLA-FL-CLAS-003	Fatal	Claim not classified because different claim line classifications share the same highest priority.

Claim classification messages get message origin PRE PRICING.

Note that it is possible that none of the classification scheme details where applicable to any claim line: i.e. that none of the claim lines were classified. In this case, the claim itself is also not classified. This is not considered an error and does not result in attachment of a message to the claim. The classification scheme on the claim may still be used in e.g. callout rules.

This step is not executed if the classification scheme of the claim could not be determined, or if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT or RESERVATION) exists that is attached to the claim line (directly or inherited).

End Classification Callout Rules

Callout rules may be executed in this step. The claim is sent back to status Change, if a callout rule is executed and the response to it contains a Claims Update request. Otherwise, the claim continues in the claims flow.

Callout rules are evaluated even if a fatal message is attached to (any level of) the claim.

Refer to the text on callout rules in the implementation guide on Process Rules.

Episode Detection

Clean Up Episode Results

The results from a previous detection are removed. This means that the episode details for claim lines within the claim are removed. As a consequence, the information about the claim line previously acting as trigger, include or new is also removed. If a new claim line was created as a result of the previous detection, that claim line is removed as well. Note that the results from a previous detection are not removed for locked claim lines; these claim lines will still be taken into account in the episode detection step.

Episode Detection

This step is not executed at all if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT or RESERVATION) exists that is attached to the claim. Claim lines having a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT or RESERVATION) are excluded from the subsequent evaluation.

The episode detection sub step will evaluate the configuration of episode definitions and episode criteria (see the Pricing Components Implementation Guide for description of the model). As a result, an episode might be created and one or more claim lines may be identified as belonging to the episode (already existing or just created).

All the episode definitions are evaluated to determine if one applies to the claim. In other words, the restrictions specified on the definition are evaluated to see whether it is applicable:

• Payer: if specified, the episode definition is is only applicable for those claims whose payer code belongs to this payer

• Provider Group: if specified, the episode definition is only applicable for those claim lines that have their priceIndividualProvider or the priceOrganizationProvider in the provider group at the price input date (if price input date not available then at claim line start date)

• Contract Reference: if specified, the episode definition is only applicable for those claim lines that have this contract reference defined on them

• Condition Dynamic Logic: if specified, the rule is only applicable for claims that meet the condition

The obtained list of episode definitions are sorted for selection by using the following order of evaluation:

• Existing Episode

  • For episode definitions that have an unvoided episode where an overlap in time validity with the claim being processed exists. This ensures that an existing episode takes precedence if more than one episode definition should qualify for selection.

• Payer

• Contract Reference

• Provider Group

This mechanism can be used to influence the outcome, because episodes can be sent in through the Episode integration point.

Here’s an example, consider that the obtained list consists of the following episode definitions with the following restrictions defined on them.

Episode Definition	Existing Episode	Payer	Contract Reference	Provider Group
A	No	ALAMERE	-	PROV1
B	No	-	C1234	PROV1
C	No	ALAMERE	C1234
D	Yes	ALAMERE	C1234	PROV1
E	No	-	-	PROV1
F	No	-	C1234
G	Yes	-	-	-

The order of evaluation of the episode definitions after applying the above sort will be: D, G, C, A, B, F and E.

The claim lines are evaluated against each of the episode criteria defined in an episode definition plus the provider group and contract reference specified in the episode definition.

• Exclude

The first question to answer is whether the claim being processed possibly has a claim line which could lead to its exclusion; this is done by evaluating all the claim lines against the episode criteria (if any) of type Exclude.

One single criterion can refer to a diagnosis group, multiple procedure groups, location type group and condition dynamic logic (the dimensions). It is satisfied when a single claim line adheres to all of the configured dimensions. If any one claim line for the serviced person or object satisfies at least one of the exclude criteria records, then this acts as an override, meaning that the episode definition is not considered applicable to any of the claim lines for the same person or object in the complete claim. As a result, none of the claim lines for the same person or object can act as a triggering or included line for that episode definition and are therefore sorted out for the further episode criteria evaluation. To draw attention to this exclusion, a message can be configured on the episode definition. If such a message configuration exists, then this exclude message will be attached to the claim line that led to the exclusion.

Locked claim lines that have episode details are ignored during the evaluation of the excludes. Locked claim lines that do not have episode details are evaluated, except that if a locked claim line leads to exclusion the exclude message will not be attached to it.

With the remaining claim lines the system continues the evaluation further to detect if any could be a triggering line (see next bullet).

Example : Consider a claim with three claim lines l1, l2, and l3, wherein l1 and l2 is for a serviced person A and l3 is for a serviced person B. The claim is evaluated against an episode definition 'D' having an exclude, trigger and include criterion each.

If l1 meets the exclude criterion, then l1 will be considered as an excluded line' and the exclude message if configured on the episode definition will be attached to it. The system will also not evaluate l2 any further for the given episode definition 'D' as it is for the same service person 'A' as l1. However, note that l1 and l2 are still considered for further evaluation if there are subsequent episode definitions.

Now, suppose l3 does not meet any exclude criteria for the episode definition 'D'; then the system continues with its evaluation to detect for the presence of it to be a triggering line.

• Trigger

When a claim reaches this step in the evaluation, it is required to find out if the claim contains a triggering claim line for the episode definition. This is done by looking at all of the episode criteria of that definition of type Trigger.

The evaluation of one single episode criterion of type Trigger is identical to that of type Exclude. If more than one criterion of type Trigger is configured, this means that the claim should have one or more claim lines for the serviced person or object that satisfy all of the trigger criteria. An example might be that both a claim line for surgery and another for anesthesia for a serviced person must be present on the claim being processed before the claim can be recognized as a valid one for hip replacement. In this scenario as well, the first claim line for the given serviced person or object that meets the trigger criteria will be considered as being the triggering and the other(s) for the same person or object as becoming included.

If a claim line has been identified as triggering, the system tries to find an existing unvoided episode for the same person or object and episode definition where the start date of the triggering claim line lies within the time validity of the episode.

If such an episode exists but already has a triggering claim line, then the new claim line will become included instead of triggering; otherwise the new claim line will be the triggering one. If a category is configured on the trigger criterion, then the episode detail gets that category.

If such an episode does not exist, then the follow up action depends on the episode definition setting whether or not an episode can be created through processing. If not, then the line is not considered as triggering, otherwise a new episode is created.

When the new claim line is the triggering one (for either a new or an existing episode), then:

• the start date and end date dynamic logic functions - if present - will be executed. So the start date and end date of the episode will only be set through claims processing at the time of identifying the triggering claim line (the end date can be set through UI and IP as well).

• the new line dynamic logic function - if present - will be executed (for a description of this signature, see the Implementation Guide for Dynamic logic).

If more than one claim line for a given serviced person or object would satisfy the single trigger criterion, then the first claim line will be considered as being the triggering and the other(s) as becoming included.

Now, the evaluation of the triggering claim line in itself has concluded. Its impact on the rest of the claim lines depends on the scope setting on the episode definition. If the scope is Claim, then the rest of the lines for the same person or object on the claim, that are within start and end date of the episode, are included as well; if the triggering claim line has obtained a category, then these lines inherit that category as well. If the scope is Claim Line, then these lines are not included automatically but are evaluated for inclusion (next bullet).

The triggering claim line and included claim lines if any that become part of the episode are then not considered for further evaluation.

Locked claim lines that do not have any episode details are ignored during the evaluation of the triggers. This means that they can not trigger the creation of a new episode nor can they be included in an existing episode, so episode details will never be created for them.

Locked claim lines that have episode details are included in the evaluation of the triggers, but only in the scope of the episode that they belong to:

• another claim line can become the triggering claim line of the episode, based on the existence of the locked claim line (same as in the standard evaluation)

  • another claim line cannot become the triggering claim line if the locked claim line is the triggering claim line (has an episode detail of type Trigger)

• other claim lines can become included based on the existence of the locked claim line (same as in the standard evaluation)

• no new claim line will be created if the locked claim line is the new claim line (has an episode detail of type New)

• no new episode detail is created for a locked claim line nor is the existing episode detail updated/deleted, even if the evaluation yields different results

The system continues the 'include' episode criteria evaluation with the remaining claim lines to detect the presence of any to be an including line (see next bullet).

• Include

The evaluation continues to find out if a claim line might be included in an existing episode; the application checks for the presence of a existing unvoided episode for the same person or object within the validity i.e., within its start date and end date.

The evaluation of one single episode criterion of type Include is identical to that of type Exclude or Trigger. When multiple include criteria exist, then the claim line can become included if it satisfies at least one of the include criteria records (so the same way as the exclude criteria are evaluated).

If a claim line has been identified as included, the system tries to find an existing episode for the same person or object and episode definition where the start date of the included claim line lies within the time validity of the episode. If such an episode does not yet exist, then the claim line can obviously not be attached to it. If an episode does exist, then the episode detail is created. If a category is configured on the include criterion, then the episode detail gets that category.

Now, the evaluation of the included claim line in itself has concluded. Its impact on the rest of the claim lines depends on the scope setting on the episode definition. If the scope is Claim, then the rest of the lines for the same person or object on the claim, that are within start and end date of the episode, are included as well; if the included claim line has obtained a category, then the other lines inherit that category as well. If the scope is Claim Line, then the rest of the lines on the claim are evaluated for inclusion.

Locked claim lines are ignored during the evaluation of the includes. This means that they can not be included in an episode, so no episode details will be created for them. However locked claim lines that are already included in an episode (so for which an episode detail exists of type Include) that is based on an episode definition with scope Claim, are used to determine if the other claim lines (non-locked) have to be included in that episode as well (same as specified in the paragraph above).

Once all the claims lines are evaluated against a particular episode definition, the lines that get excluded or included (as included or triggering) are then not considered for evaluations against the subsequent episode definitions. This continues till the last claim line is excluded or included; or there are no more episode definitions available for evaluation.

Below are examples for some of the common scenarios:

• Scenario 1

Suppose we have two episode definitions A and B both with scope claim and each having three criteria defined of different types i.e., one exclude, one trigger and one include criterion. They apply to a claim with two claim lines l1 and l2 for a serviced person 'P'.

First, l1 and l2 get evaluated against the exclude criterion of 'A' (assuming episode definition A has higher priority over episode definition B) and say they do not satisfy it. The system then evaluates l1 against the trigger criterion of 'A'. Suppose that l1 meets the trigger criterion. Now the system checks for the presence of an existing unvoided episode for the same person within the validity i.e., within its start date and end date. Suppose that such an episode does exist and no triggering line is still present on it. In this case the claim line l1 becomes the triggering line for the episode and since the scope of the definition 'A' is claim, claim line l2 will be automatically included (provided it is within time validity of the episode). The evaluation stops here since no more claim lines are available for further evaluation.

In the above scenario, suppose that l2 meets the exclude criterion. In this case l2 is considered as 'excluded line' and the exclude message (if defined) on the episode definition 'A' is attached to l2. Since l1 is also for the same person, it is now not evaluated against the trigger or include criterion of definition 'A'.

Line l1 and l2 still need to be evaluated against episode definition 'B'. The system moves to the evaluation of the episode definition 'B'. l1 and l2 get evaluated first against the exclude criterion and if it does not meet the exclude criterion; they get evaluated against the trigger and subsequently against the include criterion (if the triggering criterion is not met).

• Scenario 2

Suppose we have two episode definitions A and B both with scope claim line and each having three criteria defined of different types i.e., one exclude, one trigger and one include criterion. They apply to a claim with three claim lines l1, l2 and l3 for a serviced person 'P'.

First the claim lines l1, l2 and l3 are evaluated against the exclude criterion of definition 'A' and say they do not satisfy the criterion. Now the l1 is first evaluated against the trigger criterion and suppose it does not meet it. Then l1 is evaluated against the include criterion and meets the include criteria; the system now checks for the presence of an existing unvoided episode for the same person within the validity i.e., within its start date and end date. Suppose that an episode exists then this claim line l1 will be included as a part of the episode and this claim line will be sorted out for the evaluation process.

At this point claim lines l2 and l3 remain which need to be evaluated since the scope of the definition is claim line.

Assume that both the claim lines do not meet any of the criteria (trigger or include) of episode definition 'A'; in this case the evaluation moves to episode definition 'B. Claim lines l2 and l3 are evaluated against the exclude criterion of 'B' and suppose l2 meets it; the claim line is then considered as exclude line and since claim line l3 is for the same person it is also not evaluated for trigger or include. The evaluation stops here since no more episode definitions are available.