Flow Overview

This guide clarifies the steps in the OHI Claims Adjudication process. The claims flow is schematically depicted by the following figure:

The claims flow is described in three levels of detail. The figure above displays the level 1 claims flow, that represents the bird’s-eye view of what it takes to process a claim. Each of the process boxes of the level 1 flow is further detailed in a level 2 flow. Each of the subsequent chapters discusses a level 2 flow.

The level 2 flow holds enough detail to clarify the behavior of that part of the claims process, with the exception of a few more complex parts. In these cases, a level 3 flow is used to zoom in on what happens in a level 2 process step.

The status of a claim reflects the claims position in the flow. A claim can have only one status at a time. In the claim flow figures, a status transition is depicted by a yellow text label. The text reflects the new status of the claim. The following claim statuses exist:

Status	Description
Entry	The claim has been manually keyed in and saved, but not yet submitted.
Initial	The claim has been received via the integration point, or it has been keyed in and submitted or it has been changed and is resubmitted. Claims in this status are being processed.
Sent out for Pricing	A claim attains this status when a claim indicates that it (1) should be priced by a component other than OHI Claims and (2) has not passed that pricing component. A pricing component determines the allowed amount per claim line. A copy of the claim is available for external components and is sent upon request. The claim remains in this status until the claim is overwritten by a new copy of the claim, received "claims in" integration point.
Manual Pricing	A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. The claim can be manually priced through the user interface.
Pricing Done	A claim attains this status when it has has passed all pre pricing checks and pricing logic.
Manual Pricing Adjudication	A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. A user needs to manually accept or deny the claim
Pricing Adjudication Done	The claim has either been manually accepted, denied or has given OHI Claims no reason to pend it for manual pricing adjudication.
Pricing Finalized	A claim attains this status when its benefits should be calculated by an external component. The pricing process is finalized after which a copy of the claim is available for external components and is sent upon request.
Manual Benefits	A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. The claim’s benefits can be modified through the user interface.
Benefits Done	The applicable benefits have been determined and the claim has passed all pre benefits checks.
Manual Adjudication	A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. A user needs to manually accept or deny the claim.
Adjudication Done	The claim has either been manually accepted, denied or has given OHI Claims no reason to pend it for manual adjudication.
Finalized	The claim is processed and the results have been written to the Claims Transaction Repository. The processing results of this claim are now visible to other claims.
Change	The claim can be changed through the user interface

Status

Description

Entry

The claim has been manually keyed in and saved, but not yet submitted.

Initial

The claim has been received via the integration point, or it has been keyed in and submitted or it has been changed and is resubmitted. Claims in this status are being processed.

Sent out for Pricing

A claim attains this status when a claim indicates that it (1) should be priced by a component other than OHI Claims and (2) has not passed that pricing component. A pricing component determines the allowed amount per claim line.

A copy of the claim is available for external components and is sent upon request. The claim remains in this status until the claim is overwritten by a new copy of the claim, received "claims in" integration point.

Manual Pricing

A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. The claim can be manually priced through the user interface.

Pricing Done

A claim attains this status when it has has passed all pre pricing checks and pricing logic.

Manual Pricing Adjudication

A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. A user needs to manually accept or deny the claim

Pricing Adjudication Done

The claim has either been manually accepted, denied or has given OHI Claims no reason to pend it for manual pricing adjudication.

Pricing Finalized

A claim attains this status when its benefits should be calculated by an external component. The pricing process is finalized after which a copy of the claim is available for external components and is sent upon request.

Manual Benefits

A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. The claim’s benefits can be modified through the user interface.

Benefits Done

The applicable benefits have been determined and the claim has passed all pre benefits checks.

Manual Adjudication

A claim attains this status when the claim pends as a result of a configured intervention rule. Processing is suspended. A user needs to manually accept or deny the claim.

Adjudication Done

The claim has either been manually accepted, denied or has given OHI Claims no reason to pend it for manual adjudication.

Finalized

The claim is processed and the results have been written to the Claims Transaction Repository. The processing results of this claim are now visible to other claims.

Change

The claim can be changed through the user interface

A claim line can have the following statuses. The claim line status is set as soon as a claim reaches the status PRICING ADJUDICATION DONE (when benefits are evaluated externally) or ADJUDICATION DONE (when benefits are evaluated internally). Before that, the claim line status field is empty.

Status	Description
Approved	The claim line is approved. The covered amount of the claim line is to be paid.
Denied	The claim line is denied. The covered amount is set to 0.00.

Status

Description

Approved

The claim line is approved. The covered amount of the claim line is to be paid.

Denied

The claim line is denied. The covered amount is set to 0.00.

Receive, Change or Enter Claim

A claim can either be received electronically in an EDI format or can be entered through the user interface. Claims can be sent in electronically through the claims in integration point. Claims can also be keyed in through the user interface. The claim can be saved while entering such that the entering can be continued later. Only when the user indicates that the claim is completely entered the claim is considered received and the automatic processing starts.

As this is the first step of processing a claim, this is also where claims fields can be updated. For example, a claim that has pended for manual action may require that a field on the claim is changed before it is resubmitted. In order to make that change, the claim is returned to the start of the flow.

Sanity Checks

This step contains a number of hard coded checks that validate the information on the claim and verify that the claim specifies the information that is required to start processing.

There are two types of hard coded checks: completeness checks and general checks. Completeness checks ensure that all information on the claim can be mapped to the resident reference data, e.g., is the specified person or object known to OHI Claims? General checks ensure the consistency of the claim, e.g., a claim line end date cannot be prior to its start date. Some of the general checks do touch upon user configuration. For example, a user can specify that a particular procedure requires the serviced person to be over a certain age. The check that ensure that the specified person meets applicable age conditions is hard coded. The actual age on the procedure code is user configurable.

Failing a hard coded check means that a fatal message is attached to the violating claim or claim line. A fatal message on the line will result in the denial of that line. A fatal message on the claim will result in the denial of the entire claim, including all its lines.

Pre Pricing Checks

This step contains the user configured rules and checks that do not require any information on the products that may apply to a claim (line). There are two types of user configurable logic: dynamic checks and derivation rules.

A dynamic check sets a condition that takes any combination of fields on the claim or claim line as input. The condition can either be triggered per claim or per claim line. The outcome is binary. Claims or claim lines that fail to meet the condition acquire the message specified on the dynamic check. This message can be either fatal or informative. Fatal messages result in the denial of the claim or claim line.

The other piece of configurable logic that executes during pre pricing is a rule, rather than a check. The difference being that a check represents a condition that the claim or claim line is required to meet, while a rule represents a certain action on, or triggered by, the claim. A derivation rule sets the value of a claim or claim line field. This value can be derived from any combination of fields on the claim or claim line.

Enrollment Callout

Per person or object, per claim, OHI Claims sends out a request for that person or object’s product information. The returned information is required to determine the applicable benefits later in the process. Another important piece of information that is returned in the response is the unique code for a person or object’s family. This code is required to keep track of limits that count per family rather than counting per person or object.

The returned enrollment information is temporarily stored in OHI Claims and is discarded as soon as the claim is rerouted to a part of the flow where it requires a new enrollment callout.

Claim Classification

The evaluation of the model for claim classification (for details on the model, see the Implementation Guide for Pricing Components) is split into two parts:

determining which classification scheme is used (executed in the pre pricing checks)
applying the classification scheme to all claim lines (done after the callout for the DRG grouper), i.e. this step in the flow

For more detail see Pre Pricing Checks and Claim Classification.

Callouts to external components can be executed at the beginning and at the end of the classification step. The processing of responses to these callouts can take the claim back to the Change status. This depends on the nature of the callout response.

Pricing

During this step it is determined whether the claim still requires pricing. If it does, and the claim indicates that it should be priced outside of OHI Claims, then the claim is sent out in order to be repriced.

If the claim indicates that it should be priced in OHI Claims, then the claim stays inside. If the claim meets the conditions set by at least one of the external intervention rules, the claim pends and can be manually priced. External intervention rules are user configured.

Callouts to external components can be executed at the end of the pricing step. The processing of responses to these callouts can take the claim back to the Change status. This depends on the nature of the callout response.

Pricing Adjudication

This step filters out claims which require manual review of the claim after pricing. Claims that require manual review are pended by executing the external intervention rules for step 'Manual Pricing Adjudication'. If the claim or one of its claim lines meets the conditions set by at least one of the external intervention rules, the claim pends. The user is presented with the options of (1) accepting the way OHI Claims processed the claim, (2) denying the entire claim or (3) rerouting the claim to an earlier step in the flow in order to change the claim’s fields or results.

Pricing Finalization

This part is only executed when a claim is marked for external benefits; for internal benefits, the step is skipped and the finalization is done at the very end, after benefits.

In pricing finalization, concurrent use of provider limits is checked. Once such a concurrent use is detected, the step of selection and application of reimbursement methods and pricing rules is automatically executed again. After pricing finalizing, a copy of the claim is available for the external benefits component through the claims out integration point..

Pricing Finalized claims can be unfinalized through the user interface or an integration point. Unfinalizing a claim means that the claim is open for changes, but the claim will need to go through the entire processing flow in order to be finalized again.

Payment Status Callout

Per person or object, per claim, OHI Claims sends out a request for information on that person or object’s payment status. The response to this callout takes the form of product specific messages. In turn, these messages can be used to deny the claim, serve a hook for an external intervention rule, in order to pend the claim, or simply provide information visible in the user interface. This callout can be disabled through a setting in the OHI Claims configuration file.

Pre Benefits Checks

In this step, three types of checks and rules are triggered. All pre benefit checks and rules are user configured. Pre benefit checks are typically checks that require product specific information that may apply to a claim (line). The three types of configurable rules/checks are: dynamic checks, derivation rules and combination rules.

The dynamic checks and derivation rules are identical to their pre pricing counter parts, the difference being that they are executed later in the flow. Pre benefit dynamic checks are always triggered in the context of a product. The rationale is that, any check ignorant of product information should have been a pre pricing check.

Combination checks are similar to dynamic checks. The difference is that combination checks validate across claim and claim line history, rather than within a single claim or claim line. In other words, a combination is able to compare lines that belong to different claims. A typical example of a combination check is the detection of duplicate claim lines.

Benefits

In OHI Claims benefit are configured as benefit specifications. A benefit specification applies within the context of a group of procedures and specifes a number of additional conditions based on any field on the claim or claim line. Three different types of benefit specifications exist; for waiting periods, for authorization requirements and for coverage benefits.

The first type imposes a waiting period, i.e., the period of time that a person or object needs to be subscribed to a product before (part of) its benefits become active.

The second type of benefit specification imposes a requirement for an authorization. OHI Claims stores authorizations, which are sent in through an integration point. For each claim line that requires an authorization, a matching authorization needs to be present in order for the (full) benefits to apply. What actually constitutes a matching authorizations is a user configured piece of logic referred to as an authorization matching function.

The last type of benefits specification actually specifies the coverage. Based on the user configured cover withhold rules, OHI Claims calculates what part of claim should be covered, and what part should be withheld. Applicable limits are consulted and updated. Applicable cases are detected and created.

Once the benefits have been applied, the application can execute callouts to external components.

Re-evaluate External intervention Rules

At this step the external intervention rules are evaluated a second time. If the claim or one of the claim lines meets the conditions set by at least one of the external intervention rules, the claim pends and the benefits can be manually modified.

Execute End Benefits Callouts

At this step of the flow the application checks if any End Benefits callout rules apply to the claim. If so, the application halts the claim at its current location in the claims flow. The claim’s status is not changed. The callout rules that apply to the claim are then executed sequentially, in order of their specified sequence.

The application executes the End Benefits callout rules for claims independent of the Keep Benefit setting of the claim lines. Note that the claims flow does not cleanup the reults of a previous Benefits step for claim lines with Keep Benefits set to Yes. This means that calling out and resubmitting a claim with such claim lines more than once, can result in claim lines holding details from more than one callout.

If the callout definition specifies a "Response Logic" dynamic logic function, this logic processes the response message. The response message can update dynamic fields and add a message through a pre-defined method. Sending in (fatal) messages will however not impact the status of the claim or claim line that was set in the previous step. If the response of the callout has to set the claim or claim line status, or if it should lead to reprocessing the claim, the response should be send in through a Claims Update IP-SOAP/HTTP request message. This option is only available for callout definitions with an asynchronous messaging pattern.

Re-evaluate External Intervention Rules

As a final step the external intervention rules are evaluated a second time. If the claim or one of the claim lines meets the conditions set by at least one of the external intervention rules, the claim pends and the benefits can be manually modified.

Adjudication

This step filters out claims which require manual review. All other claims continue to be processed. Claims that require manual review are pended by executing the external intervention rules for the last time. If the claim or one of its claim lines meets the conditions set by at least one of the external intervention rules, the claim pends. The user is presented with the options of (1) accepting the way OHI Claims processed the claim, (2) denying the entire claim or (3) rerouting the claim to an earlier step in the flow in order to change the claim’s fields or results.

Finalization

The most important part of finalizing a claim is the detection of concurrent use of counters and cases. Concurrent use must be detected in order to prevent a counter from exceeding its limit due to the simultaneous processing of multiple claims. Likewise, the creation of the identical overlapping cases is detected. Once a claim is cleared and confirmed not to be in conflict with other claims, a snapshot of the claim, i.e., a claim transaction, is stored in the Claims Transaction Repository.

Finalized claims can be unfinalized through the user interface or an integration point. Unfinalizing a claim means that the claim is open for changes, but the claim will need to go through the entire processing flow in order to be finalized again.