Reservation Selection, Claim Classification, and Episode Detection

The reservation selection step applies only to actual claims (not to quote claims or reservation claims) and detects whether the line requires a reservation. If so, it attempts to find and link the matching reservation line.

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 are different. Claim Classification stays restricted to the claim at hand while Episode Detection often spans multiple claims.

Pre-Reservation Derivation Rules

Before the reservation selection starts, the application derives the two dates needed for benefit specification selection; the selection of reservation specifications in this flow uses these dates, 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 execute derivation rules for which the step field has the value Pre-Reservation.

Evaluate the following pre-reservation process field derivation rules on the claim line:

1. claimLine.benefitsAgeInputDate

2. claimLine.benefitsInputDate

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

Code	Severity	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 attaching to (any level of) the claim. The claim line level derivation rules ware not evaluated for locked claim lines and replaced claim lines. Refer to the text on "Derivation Rules" page of the Process Rules chapter in the Configuration Guide for more details.

Reservation Selection

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

Skip this step for a reservation line, quote line, a locked claim line or a claim line with a checked keep benefits indicator or with a checked external benefits indicator. If an error is attaching 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. Only remove the claim and bill messages if at least one non-replaced and non-locked claim line has an unchecked Keep Benefits indicator.

In addition, remove any claim benefit specifications that references a reservation specification, and nullify the link to a reservation line. 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.

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 ^[1] This information can be used to determine whether a denied claim line files under provider liability or under adjudication liability. SANITY CHECKS, ENROLLMENT, PRE-PRICING.

The outcome is a list of time valid policy products that serve 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. Since reservation specifications do not have a reference to case definitions, that part of the flow are not executed and therefore no new cases are 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. On finding more than one reservation specification for a certain product, order the list by the benefit priority of the reservation specification.

Lower the priority field value, higher the priority. If a reservation specification has no priority value, then this is interpreted as the lowest possible priority. Only a single reservation specification should have the highest priority for a certain product. If not, attached to the claim line is the following product dependent fatal message:

Code	Severity	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}

In absence of a fatal message, store the claim line reservation specification.

Find Matching the Reservation Line

Before the evaluation, check the claim line 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.

If not, the system attempts to find the matching reservation line.

• If the claim line specifies a reservation code and a reservation line code, then the system selects the corresponding reservation line.

• If the claim line specifies only a reservation code, then the system applies the matching function. In this scenario the function only searches a matching line within the specified reservation; it does not search other reservations.

• If the claim line does not specify a reservation code, then the system applies the matching function. In this scenario searches all reservations for the member to find a matching line.

If there is an attachment between reservation line and the claim line it 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, attached is the following fatal message to the claim line

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

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

It is possible to link to a locked line.

In the absence of reservation, or the specified reservation line does not exist, then the not found message specified on the regime are applied. The severity of this message can be either fatal or informative. Denial of claim line because the reservation was absent effectively means it is fatal.

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

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, evaluate the reservation regimes 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, it generates the following product independent fatal message:

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, on finding exactly one classification scheme, it is stored on the claim header and is now used to classify further. On finding a classification scheme, use this scheme 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, immediately reset the claim to the CHANGE status to do the requested updates. Otherwise, the claim continues in the claims flow.

Evaluate callout rules even if a fatal message are attached to (any level of) the claim.

Refer to the text on "Claims Callout Rules" page of the Process Rules chapter in the Configuration Guide.

Claim Line Classification

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

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

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

Execution of this step does not happen 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 date and end date

Procedure Groups or Conditions

Match the three claim line procedures 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 or condition at the price Input date (perform this check for each specified group and condition). 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 a detailed description, see Select Provider Pricing Clauses.

Product Category

For a detailed description, see Select Provider Pricing 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 applies for any of the serviced person’s or object’s authorizations. For this, evaluate the person’s or object’s authorizations against the specified condition, one by one, new to old. When an authorization applies, this classification scheme detail applies to the claim line and stores the authorization on the claim line - omit further evaluation of authorizations.

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 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 compare to the fields (fixed or dynamic) of the claim line. For a technical description, see the "Dynamic Logic" chapter in the Developer Guide.

When no classification scheme detail applies, no classification occurs on the claim line. 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 classification does not occur the claim line and attaches the following message to the claim line:

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

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

Code	Sev	Text
CLA-FL-CLAS-002	Fatal	Claim classification does not happen 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; 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 and also stored on the claim header. That is, classification of the claim occurs 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 attaches the following message 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.

It is possible that none of the classification scheme details where applicable to any claim line: That is, classification not done for any of the claim lines. In this case, the claim itself is 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. For example, callout rules.

This step does not execute 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 execution may happen in this step. Send the claim back to status Change, if an execution of callout rule occurs, and the response to it contains a Claims Update request. Otherwise, the claim continues in the claims flow.

Evaluation of callout rules occurs even if (any level of) the claim has a fatal message attached.

Refer to the text on "Claims Callout Rules" page of the Process Rules chapter in the Configuration Guide.

Episode Detection

Clean Up Episode Results

To clean up episode results, consider the below points:

• Remove the results from a previous detection and therefore the episode details for claim lines within the claim are removed. Consequently, the information about the claim line previously acting as trigger, include or new is also removed

• If a new claim line is getting created because of the previous detection, remove that claim line as well

• The results from a previous detection are not removed for locked claim lines; these claim lines are still considered in the episode detection step

Episode Detection

Episode detection step is not executed if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE-PRICING, ENROLLMENT or RESERVATION) 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 subsequent evaluation.

The episode detection sub step evaluates the configuration of episode definitions and episode criteria (see the "Episode Model" section in the Pricing COnfiguration chapter of the Configuration Guide) to determine if any one of them applies to the claim. Therefore, a new episode is created and one or more claim lines are identified belonging to the same episode (already existing or just created).

• Payer: If specified, the episode definition 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

Sort the obtained list of episode definitions for selection using the following order of evaluation:

Existing Episode

For episode definitions that have an un-voided episode where an overlap in time validity with the processed claim exists, ensure that an existing episode takes precedence if more than one episode definition is qualified 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.

For 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 are: D, G, C, A, B, F and E.

The system then evaluates the claim lines against each episode criteria defined in an episode definition

Exclude

Verify if the claim processed 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 configured dimensions. If any claim line for the serviced person or object satisfies at least one exclude criteria record, then this acts as an override, excluding the episode definition applicable to any claim lines for the same person or object in the complete claim.

None of the claim lines for the same person or object can act as a trigger or included line for that episode definition and are sorted out for the further episode criteria evaluation. To draw attention to this exclusion, a message can be configured on the episode definition. If a message configuration exists, then the applicable exclude message is attached to the claim line that.

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 if a locked claim line leads to exclusion, the exclude message is not attached to it.

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

Example

Consider a claim with three claim lines l1, l2, and l3, where l1 and l2 are 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 exclude criterion is met by l1, then l1 is considered as an excluded line and exclude message if configured on the episode definition is attached to it. The system does not evaluate l2 any further for the given episode definition D as it is for the same service person A as l1. l1 and l2 are still considered for further evaluation if there are subsequent episode definitions.

If l3 does not meet any exclude criteria for the episode definition D, then the system continues the evaluation to detect for the presence of it to be a triggering line.

Trigger

When a claim reaches this step in the evaluation, find if the claim contains a triggering claim line for the episode definition. This is done by viewing all the episode criterion of that definition of type Trigger.

Evaluation of one single episode criterion of type Trigger is identical to that of type Exclude. If more than one criterion is configured for type Trigger, the claim should have one or more claim lines for the serviced person or object that satisfy all trigger criterion. For example, while processing a claim, it is possible that a claim line for surgery and another for anesthesia for a serviced person is present on the claim before the claim can be recognized as a valid one for hip replacement. In this scenario, the first claim line for the given serviced person or object that meets the trigger criteria is considered as triggering and the others for the same person or object as included.

If a claim line is identified as triggering, the system tries to find an existing un-voided episode for the same person or object and episode definition where the identifier on the triggering claim line matches with the identifier on the episode within the time validity of the episode.

If such an episode exists and has a triggering claim line, then the new claim line is included instead of triggering, while configuring a category 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 n episode can be created through processing. If not, then the line is not considered as triggering, otherwise a new episode is created. When a trigger line tries to create an episode, episode identifier logic if specified is invoked. This function returns an identifier value that persisted on the episode. The episode identifier should match the identifier on the clime line, otherwise the new episode is not created, and line is not considered as triggering.

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

• the start date and end date dynamic logic functions - if present – are executed. The start date and end date of the episode can be set through claims processing at the time of identifying the triggering claim line. The end date can also be set by an including line, by UI or IP

Change of dates does not automatically invalidate the claims lines that are already included in the episode.

• the new line dynamic logic function - if present - is executed (for a description of this signature, see the Developer Guide for the "Dynamic Logic" chapter).

If more than one claim line for a given serviced person or object would satisfy the single trigger criterion, then the first claim line is considered as triggering, and the others as included.

The evaluation of the triggering claim line is 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 date and end date of the episode, are included.

If the triggering claim line has obtained a category, then these lines inherit that category as well. If the scope is Claim Line, then do not include these lines automatically, evaluate for inclusion (see next bullet).

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

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

Include locked claim lines that have episode details in the evaluation of the triggers, 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 is 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 or 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

If including in an existing episode, evaluation continues to find out a claim line, the application checks for the presence of an existing un-voided episode for the same person or object within the validity that is, within its start date and end date and have the matching episode and claim line identifiers.

The evaluation of one single episode criterion of type Include is identical to that of type Exclude or Trigger. When multiple include criterion exist, then the claim line can become included if it satisfies at least one include criteria record (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 identifier on the included claim line matches with the identifier on the episode within the time validity of the episode.

If such an episode does not exist, then the claim line cannot be attached to it. If an episode does exist, then the episode detail is created. While configuring a category on include criterion, then the episode detail gets that category.

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

• end date dynamic logic functions if available, are executed.

  NOTE

  End date logic is triggered after the line is considered as “include, the system does not check again if the validity of the claim line is still within the validity of the episode.

With this evaluation of the included claim line is concluded.

Its impact on the remaining claim lines depends on the scope setting on the episode definition. If the scope is Claim, then remaining lines for the same person or object on the claim, that are within start date and end date of the episode, and having the same episode identifier settings, are included.

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 evaluate the rest of the lines on the claim for inclusion.

Ignore locked claim lines during the evaluation of the includes. This implies that they cannot be included in an episode, so no episode details are created for them. However, locked claim lines that are already included in an episode 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) must be included in that episode as well (same as specified in the paragraph above).

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

For example, refer to the below scenarios:

Scenario 1

Suppose there are two episode definitions A and B, both with scope claim and each having three different criterion defined that is, 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 exclude criterion of A (assuming episode definition A has higher priority over episode definition B) and if they do not satisfy it, the system then evaluates l1 against the trigger criterion of A. If l1 meets the trigger criterion, the system checks for the presence of an existing un-voided episode for the same person within the validity that is, within its start date and end date and matching identifiers. If such an episode exists, and no triggering line is still present on it, then the claim line l1 becomes the triggering line for the episode and since the scope of the definition A is claim, claim line l2 is automatically included (provided it is within time validity of the episode and matching identifiers). The evaluation stops here since no claim lines are available for further evaluation.

In the above scenario, if l2 meets the exclude criterion then 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 are initially evaluated against the exclude criterion and if it does not meet the exclude criterion, they are evaluated against the trigger and subsequently against the include criterion (if it does not meet the triggering criterion).

Scenario 2

If there are two episode definitions A and B, both with scope claim line and each having three criterion defined that is, exclude, trigger and 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. If they do not satisfy the criterion. l1 is first evaluated against the trigger criterion and if it still 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 un-voided episode for the same person within the validity that is, within its start date and end date and matching identifiers. If an episode exists, then this claim line l1 is included as a part of the episode and this claim line is sorted out for the evaluation process.

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

Assume that both the claim lines do not meet any 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 if l2 meets it, consider the claim line as exclude line and since claim line l3 is for the same person it is not evaluated for trigger or include. The evaluation stops here since no more episode definitions are available.

---

1. 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.