Adjudication Workflow

Adjudication Workflow

The adjudication process is an embedded workflow within Oracle Health Insurance Claim Adjudication. It consists of a number of configurable steps, each of which has a specific purpose. This process includes steps that handle the following aspects:

Enrollment Information

The first step in the embedded flow is for the application to accept the submitted claim. If the request is well formed the application builds up the claim, matching member ID’s, provider ID’s and medical codes to the application’s reference tables.

Before the system is able to determine the appropriate benefit, it first needs to retrieve enrollment information on the member that is serviced on the claim. This happens through a web service call to the member enrollment system of record.

The response payload includes the health plan to which the member is enrolled as well as the member’s policy number. It could also contain additional information that is relevant to the adjudication of the claim. For example, the following information can be included in the response payload:

  • Products identifiers that represent the set of active benefits by which the member is covered

  • Family identifiers that represent the key for family based accumulation, e.g., for a family deductible

  • Member liability and benefit parameters

  • Reinsurance parameters

  • Provider network parameters

  • One or more system messages that should be stamped on the claim

  • One or more uses configured fields and values

The member liability, benefit and provider network parameters support configuration strategy where a subset of a health plan’s features features are controlled by the enrollment system, rather than as features of the static health plan configuration templates.

Business Rules

Within the embedded claims flow there are two categories of configurable rules; those that determine the benefit and and calculation results and those that apply business rules. OHI Claim Adjudication includes the following configurable business rules:

Dynamic Checks - These are rules that deny a claim for policy reasons. For example, a rule to

  • automatically deny a claim for which the filing limit has expired

  • automatically deny a claim that requires additional information that the provider failed to submit

  • automatically deny a claim that is an exact duplicate of another claim

Pend Rules - These are rules that will suspend the claim from being processed so that either a human operator can make a judgement call or an automated process reprocesses the claim based on a timed schedule. For example, a rule to

  • pend a claim for which the calculated covered amount exceeds the configured threshold, and requires an operator to approve

  • pend a claim that is a suspected duplicate and requires an operator to confirm

  • pend a claim that requires a authorization that has not been received yet

Derivation Rules - These are rules that automatically enrich the claim by deriving and stamping on additional information that can be used for calculation or to inform downstream systems. For example, a rule

  • derive and stamp on the date that is used to determine the benefit. Typical alternatives are the service date, member contract date or admission date, usually depending on the benefit.

  • derive and stamp on the input amount used to calculate the benefit. Typical alternatives are the priced amount, the charged amount or an adjusted amount within the context of coordination of benefits.

  • derive and stamp on the provider that is used to determine network status within the context of the claim

  • derive and stamp on additional member and provider data that needs to be included in the explanation of payment or the explanation of benefits

Call Out Rules - These are rules that call out to external services to retrieve information that is required to adjudicate the claim correctly. Examples are

  • a call out to a claims editor, which may update the claim and its medical codes to conform to industry accepted practices and standards

  • a call out to a grouper, which bundles separate charges into a single one that represents a composite medical procedure

  • a call out to an external rules engine

Note that all mentioned business rules have

  • a set of configurable criteria that specify when the rule applies.

        For example, a business rule that applies only to inpatient claims.
*   a configurable execution moment.
        For example, a high coverage pend is triggered after the coverage is calculated,
while an 'incomplete claim' pend is executed right after submission.

Benefit Selection

The second set of rules concern the benefit selection and calculation of coverage for a claim. Benefits plans are represented by a set of benefit specifications that are grouped together into products. These products then represent the health plan (or part of a health plan) on which a member can enroll.

Benefit specifications are a combination of medical codes that represent a healthcare service. They also specify the circumstances and conditions under which that benefit applies, such as the servicing provider’s participation status within the context of the applicable product or age and gender restrictions within the context of the serviced member.

The benefit configuration model separates the covered services, i.e., the combination of medical codes that represent an office visit, from the more volatile product specific configuration, i.e., the networks and the member liability amounts, limits and percentages that apply. This division supports a configuration strategy where a product template is reused for different health plans through parameters. These can even be specific within the context of a specific enrolled member, i.e., the member liability and applicable networks are retrieved from the member enrollment system while the claim is processed, rather than being persisted static piece of configuration embedded in the product settings. Such a strategy greatly reduces the volume of configuration and maintenance effort required to support it.

The benefit selection step takes the enrollment information that is retrieved earlier to establish the total set of covered benefits within the context of the claim. Once established, the application finds the benefit that matches the medical service and circumstances represented by the claim. If the a benefit is found, it drives what happens in the next step, including:

  • whether a qualification period applies

  • whether the benefit requires a pre-authorization

  • the calculation that determines the coverage

  • the parameters that are relevant to this calculation, such as benefit limits, deductibles and copays

  • whether a post coverage calculation calculation applies, for example, within the context of coordination of benefits

Accumulate and Calculate Coverage

Oracle Health Insurance Claims Adjudication benefit calculation configuration is rule driven. There are no embedded assumptions and hard-coded calculations in the application. Instead, it separate the semantics of a calculation from the math by providing set of configuration building blocks such as accumulators, coverage labels and cover / withhold rules that can be brought together to form calculation templates.

These templates drive the sequence of rules that apply, e.g., first apply the deductible followed by the copayment or the other way around. The actual accumulators that apply are retrieved as separate parameters from the selected benefit.

At this point in the claims flow, all the retrieved information comes together in order to execute the coverage calculation. For example,

  • the applicable calculation template specifies that the DEDUCTIBLE rule applies first, followed by a COVERED IN FULL rule.

  • the selected benefit specifies that the following accumulators count towards the DEDUCTIBLE

    • The individual in network deductible

    • The family in network deductible

    • The individual out of pocket

    • The family out of pocket

  • the retrieved member enrollment record specifies that

    • The individual in network deductible is set at 500 USD

    • The family in network deductible is set at 1.000 USD

    • The individual out of pocket is set at 2.000 USD

    • The family out of pocket is set at 4.000 USD

The application has an embedded accumulation repository. When a calculation includes one or more accumulators, the current balance of those accumulators become an integral part of the calculation: every time an accumulator applies, the system increments the accumulator until the set limit is met. Once met, the coverage calculation proceeds to the next rule.

The configuration settings support many subtle variants of a calculation, specifying - for example - whether accumulators apply simultaneously or sequentially, whether an accumulator can push a claim to the next rule and which base amount to use when calculating with percentages.

To make the benefit selection and calculation results fully transparent the application stamps all the selected benefits, applied calculation rules and retrieved liability parameter values and network parameters on the claim.

Finalize Claim

After the claim liability is calculated, the application finalizes the claim. This means that all related increments to accumulators are made permanent and that the incurred increments to the accumulators become visible to other claims that are still in the process.

When the claim finalizes the application stores a immutable snapshot of the claim. These are called claim transactions and are stored in the internal claim transaction repository.

It is possible to select a finalized claim and resubmit that claim for processing. A typical occasion is an accepted provider appeal, which requires that the original claim adjusted and reprocessed. When the adjusted claim re-finalizes, it generates retractions and a new version for the all accumulator increments as well as for the previous claim transaction.

Financial Pre-Processing

Concurrently with the creation of the claim transactions the application also generates a financial transaction. This transaction is also stored in an internal repository and carries the information that is required by downstream financial applications that are responsible for paying the claim. The application implements a three step approach for generating payment message.

These steps can either be initiated by an end user or can be initiated through the application’s API, e.g., by an external job scheduler. These jobs prepare the financial transactions to be published to a downstream application by

  1. Aggregating financial transactions into one or more sets, depending on configurable aggregation criteria

  2. Consolidating the transactions in set by making sure only the latest version of a transactions is processed (reprocessing a claim produces a retraction of the old transactions and a new (version) financial transaction that reflects any changes)

  3. Generating financial messages that are made available to downstream systems