Application Overview

Introduction Claims Adjudication

Claims is an enterprise strength healthcare payer back office application. It is designed as a component that holds only limited information and relies on integration with contingent systems to retrieve the information it needs to adjudicate healthcare claims.

The calculation that determines the amount for which the payer is liable depends on two contracts.

The first is between the payer and the provider and specifies the height of the reimbursement for the health services that are performed by the provider. These are typically fee schedules that lists a large number of services in combination with the applicable reimbursement amount.
The second is between the payer and the member. This contract is the insurance Policy that the member has with the payer. The policy specifies for which costs the payer provides coverage and to what extent the member is liable. For example the policy may state that the member is liable for 10% of the incurred costs for a particular health care service.

Claims automates the execution of the second contract, that is, the one between the member and the payer. This process contains the steps listed below:

Accept repriced healthcare claims,
Calculate the applicable coverage based on the allowed amount, the member’s insurance and limit accumulation and the provider and his or her relation to the member’s insurance
Produce a representation of the adjudicated claim
Produce a financial transaction those that determine the benefit and calculation Claims adjudicates claims in real-time. New claim submissions are sent in through a standard integration point. As soon as the claim is accepted by the application it is picked up by the embedded calculation workflow. Once the claim is adjudicated and finalized, the application produces an event to notify downstream subscribers and stores a copy of the adjudicated claim and a separate financial transaction in its internal repository. The downstream applications that require the claim can retrieve a copy of the finalized claim and/or of the financial message through a standard integration point.

Within the context of this document a Claim represents a reimbursement request for the incurred cost of a healthcare services rendered by a healthcare professional (the Provider ) to an insured patient (the member ). The receiver of the reimbursement is typically also the party that submitted the claim; the member, the provider or a third party who submitted the claim on behalf of the provider. This reimbursement represents the amount for which the payer is liable and is referred to as the Covered Amount.

Adjudication Workflow

The adjudication process is an embedded workflow within Claims. It consists of a number of configurable steps, each of which has a specific purpose.

Enrollment Information

The first step in the embedded flow is to accept the submitted claim. If the request is well-formed the application builds an internal representation of the submitted claim with links to the member, provider and medical codes records.

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 unique policy number. It can also contain additional information that is relevant to the adjudication of the claim. For example:

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, for example, 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 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 calculation results and those that apply business rules. Claims includes several types of 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 suspend the claim from the embedded workflow so that either a human operator can make a judgement call or an external automated service recycles 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 can stamp additional information on the claim that can be used for calculation purposes or to inform downstream systems. For example, a rule to:

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

Callout 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 service 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, for example, the combination of medical codes that represent an office visit, from the configuration that is typically different between products, for example, the applicable networks, member liability amounts, limits and percentages. This design supports an architecture in which products are templates that are made specific through parameters. These parameters can be specific within the context of a group or individual member.This architecture promotes reuse of configuration These parameters are then retrieved from the member enrollment system while the claim is processed. This architecture promotes reuse of configuration and reduces 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 benefit is found, it drives what happens in the next step:

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 co-pays
whether a post coverage calculation applies, for example, within the context of coordination of benefits

Accumulate and Calculate Coverage

Claims benefit calculation configuration is rule driven. There are no embedded assumptions and hard-coded calculations in the application. Instead, it separates the semantics of a calculation from the math function. The math is set up through choice menus that refer to configuration building blocks such as accumulators, coverage labels and cover or withhold rules. Multiple rules are combined to form reusable calculation templates.

These templates drive the sequence of rules that apply, for example, first apply the deductible rule, followed by the co-payment rule. The actual accumulators that apply as well as their limit are retrieved as 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, suppose that the applicable calculation template specifies that the DEDUCTIBLE rule applies first, followed by a COVERED IN FULL rule. And suppose that the selected benefit is configured so 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

Once a claim enters the calculation flow, and the application has reached out to get enrollment data, 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

As the final step, the system combines the retrieved information and the configuration with the current levels of the relevant accumulators and calculates the applicable liability.

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. For example, whether accumulators apply simultaneously or sequentially and whether an accumulator can push a claim to the next rule once it’s limit has been met or which base amount to use to calculate a percentage.

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

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 to the workflow so that is calculated again. The typical occasion is an upheld provider appeal, which requires that the original claim is adjusted and reprocessed. When the adjusted claim re-finalizes, it generates a retraction message to undo the previous result and it generates a new version of the calculation result.

Financial Pre-Processing

Concurrent 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 pay the claim. Payment messages are generated in three consecutive steps.

These steps are implemented as system activities and can either be initiated by an end user or can be initiated through the application’s API, for example, by an external job scheduler.

The first step aggregates financial transactions into one or more sets, based on configurable aggregation criteria
The second step consolidates the transactions within set. It enforces that only the latest version of a transactions is processed (a resubmitted claim produces a retraction of the old transactions and a new (version) financial transaction that reflects the changes)
The final step produces a financial messages that is made available to downstream systems

Key Features

Access Control

All Oracle Health Insurance components include configuration rules that assign access privileges to user roles. These rules support several types of access protection:

entity or resource access, with separate settings for create, retrieval, update and delete privileges
business operation access, like the re-submission of a claim to the workflow
sensitive date masks, applicable to, for example, member contact information or and medical service codes on a claim
data access controls, that deny access specifically to employee or VIP claims but not to other claims

A user’s access privileges depend on the roles that are assigned to that user, and are enforced throughout the application. This includes the user interfaces pages as well as the application’s web services.

Integration

All Oracle Health Insurance components include a set of RESTful web services that support integration with contingent systems. There are two separate sets of services. All web services require authentication, either through basic authentication or OAuth 2.0.

The first set of web services is called the Generic Application Programming Interface, or Generic API for short. This service allows the customer to build an integration that hooks into the entity model of Claims. This API includes a query service, as well as operations to create, update and delete entities within the application. This API is perfectly suited for building lightweight customer specific screens and for building integration with other applications especially, for example, to synchronize information.

The generic API enforces the access restrictions as configured in the system. That means that Personal Health Information and Personally Identifiable Information is protected in the API layer, which prevents custom screens and custom integration have unintended access to protected information.

The second set of web services are dedicated Integration Points. These are designed to support specific business processes that require system to system integration, for example, to submit a claim, synchronize an accumulator or to install new benefit configuration.

Extensible Model and Logic

All entities within the application (like claims, members, benefits and business rules) have a set of embedded attributes. In addition, nearly all entities can be extended with customer defined fields and details, to accommodate market or customer specific data elements that are integral to those entities.

The application has rich settings that control the behavior of customer defined fields. This includes control over the data type, value domain, uniqueness and availability of the user defined fields. Customer defined fields are indistinguishable from fields that are native to the application. They automatically become available in the integration points as well as in the generic API and user interface.

The values of these customer defined fields can be set by, and also used in, the claim calculation work flow. For example, it is possible to derive the value of the customer field on a claim from other fields on that claim. It is also possible to have the system select the appropriate benefit based on the value of a customer defined field.

The configuration rules in the application have a set of embedded attributes that drive when the rule triggers and what they do. In addition, most rules provide one or more hooks for customer defined logic. This allows a customer to extend the embedded logic of that rule with customer specific requirements, such as a specific condition under which the rule should trigger.

The combination of an extensible entity model and the ability to extend the embedded system logic is a powerful tool that allows a customer to tailor the system behavior to the their specific needs.

Transaction Types

An approved claim typically leads to an update of the relevant accumulators and a financial transaction that represents a payment. In addition to this typical workflow, the application supports several other variants of workflow.

Encounter Claims: These are claims that update the accumulators but does not lead to any financial transaction. Encounter claims are typically processed to compare the costs that would be incurred if the claim were paid fee-for-service with the actual cost incurred by the applied alternative payment method (such as capitated payments).

Benefit Quotes: These are example claims for which the result is persisted, but these claims do not make permanent changes to the accumulators, nor do they lead to financial transactions. These quotes typically support member portal features, where member can get information on how a theoretical claim would adjudicate.

Reservation Claims: These are claims that reserve the accumulators that are used for the calculation, but no invoices are generated. The reservation lasts until it expires or until a claim is matched to the reservation and uses the reserved accumulators to adjudicate. Reservation claims are typically submitted shortly before the actual healthcare service is provided. The purpose of the reservation claim is to ensure that the reserved benefit is not used or reduced by another unrelated claim before the matching claim is submitted.

Product Definition

For benefit selection, the workflow relies on a representation of the benefit plan that is optimized for computation. This representation of the benefit plan can be set up directly by end users or loaded into the application through a integration point.

The product definition application is a separate tool that holds a representation of the benefit plan that is aligned with the business. It is optimized to support the maintenance and configuration of benefit plans rather than computation. The tool also includes an embedded workflow that takes the business representation of the benefit plan and transforms it into the representation optimized for computation. The result is a payload that can be uploaded into the claim adjudication application directly.

In addition to the transformation, the embedded workflow also allows end users to set up validation rules. These rules can be leveraged to implement customer specific business rules around how benefit plans should be configured. If a new or updated benefit plan violates a validation rule, the workflow does not produce a product file but throws the configured error message instead. This ensures that the end user remediates the plan configuration before it is loaded into the claims environment.

Configuration Migration

Claims includes an embedded configuration migration tool. This tool allows the customer to create a selection of configuration rules and settings and create an export file. This file can then be uploaded into other environments and automatically updates the configuration rules in that environment. This supports an implementation strategy that relies on separate environments, for example, a sandbox, a primary configuration , a user acceptance and, of course, a production environment.

Configuration rules typically follow a hierarchical model. Small reusable setup items (such as service code or diagnosis code groups) are the building blocks for configuration rules (such as pend rules or benefit specifications). The tool automatically derives the dependencies between configuration items and includes the required setup up items for a given configuration rule.

The tool is designed to handle a single direction migration path as well the incidental circular migration path. In a circular path the environment that is usually the target environment (for example the production environment) becomes the source environment to environments that is typically the source (such as the configuration primary environment).

Introduction Claims Pricing

The calculation that determines the amount for which the payer is liable depends on two contracts.

The first is between the payer and the provider and specifies the height of the reimbursement for the health services that are performed by the provider. These are typically fee schedules that lists a large number of services and their corresponding prices.
The second is between the payer and the member. This contract is the insurance Policy that the member has with the payer. The policy specifies for which costs the payer provides coverage and to what extent the member is liable. For example the policy may state that the member is liable for 10% of the incurred costs for a particular health care service.

Claims automates the execution of the first contract, that is, the one between the health service provider and the payer. The footprint of the core functionality offered by this component is best described by the following sequence of steps:

It takes submitted healthcare claims
It calculates the allowable amount taking into account the provider’s network status and the applicable reimbursement method (like a fee schedule) for that provider
It applies the applicable adjustments and restrictions for that provider
It stamps the applicable allowable amount per line of the claim

Claims prices claims in real-time. New claim submissions are sent in through a standard integration point. As soon as the claim is accepted by the application it is picked up by the embedded pricing workflow. Once the claim is priced, the application produces an event to notify downstream subscribers that the claim is ready for further processing. The down stream consuming systems can then retrieve a copy of the priced claim standard integration point.

Within the context of this document a Claim represents a reimbursement request for the incurred cost of a healthcare services rendered by a healthcare professional ( referred to as the Provider ) to an insured patient (referred to as the member ). The receiver of the reimbursement is typically also the party that submitted the claim, and could be either the member or the provider. This repriced amount represents the amount that flows from the contractual agreement between the payer and the provider and is referred to as the allowed Amount.

Pricing Workflow

The pricing process is an embedded workflow within Claims. 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 price, 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 repricing 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
Provider network parameters
One or more system messages that should be stamped on the claim
One or more uses configured fields and values

The 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 reimbursement method and rules and those that apply Business Rules. Claims 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 repriced 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 has been submitted by a provider that is not contracted

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 reimbursement method. Typical alternatives are the service date, member contract date or admission date.
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 for downstream purposes

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

a callout to a claims editor, which may update the claim and its medical codes to conform to industry accepted practices and standards
a callout to a grouper, which bundles separate charges into a single one that represents a composite medical procedure
a callout 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 'non-contracted provider' pend is triggered right after submission, while a 'operator review' pend is executed after the claim went through the embedded pricing workflow.

Reimbursement Method and Rule Selection

The second set of rules concern the selection of reimbursement method and pricing rules for a claim. Provider contracts are represented by a set of pricing specifications that are grouped together into templates. These pricing templates represent sets of pricing specifications that are reused for different providers, allowing for provider specific agreements through parameters that are built into the template.

These pricing specifications are referred to as Provider Pricing Clauses. Each of provider pricing clause specifies a combination of medical codes that represent a healthcare service, and specific reimbursement method or rule that applies within the context of that 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’s network.

The pricing configuration model includes a number of different reimbursement methods and pricing rules. A reimbursement method represents a configured calculation or look-up that determines the base allowable amount. Pricing rules are configuration rules that make adjustments to that base amount. The application includes the following reimbursement methods:

Fee schedules with configurable dimensions (columns)
Percent of charge
Block rates that are correlated with the claimed volume
Analog Payment Functions
Percent Increase

The application includes the following adjustment rules:

percent increase or reduction based on line information
percent increase or reduction based on other services provided
episode of care detection episode based pricing
line replacement rules for custom edits
accumulation to enforce provider budgets

Finalize Claim

After the claim is priced the application finalizes the claim (for pricing). 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.

Pricing finalized claims can be retrieved through an embedded integration point, for the purpose of further adjudication.

Key Features

Access Control

All Oracle Health Insurance components include configuration rules that assign access privileges to user roles. This application supports several types of access protection:

entity or resource access, with separate settings for create, retrieval, update and delete privileges
business operation access, like the re-submission of a claim to the workflow
sensitive date masks, applicable to, for example, member contact information or and medical service codes on a claim
data access controls, that deny access specifically to employee or VIP claims but not to other claims

Pricing Templates

Claims includes integration point that is able to load pricing contract configuration directly into the application. In addition, the application has an embedded module that supports end users keying in new (or updating existing) contract details.

The pricing templates consist of modular building blocks that take a number of parameters, designed in such a way that they can be combined to quickly set up new provider contracts. Before the filled out template becomes active configuration, the application enforces several validations and checks to make sure that the configuration is complete and consistent.

Integration

The first set of web services is called the Generic Application Programming Interface, or Generic API for short. This service allows the customer to build an integration that hooks into the entity model of Claims. This API includes a query service, as well as operations to create, update and delete entities within the application. This API is perfectly suited for building lightweight customer specific screens and for building integration with other applications especially, for example, to synchronize information.

The second set of web services are dedicated Integration Points. These are designed to support specific business processes that require system to system integration, for example, to submit a claim, synchronize an accumulator or to install new benefit configuration.

Extensible Model and Logic

The configuration rules in the application have a set of embedded attributes that drive when the rule triggers and what they do. In addition, most rules provide on or more hooks for customer defined logic. This allows a customer to extend the embedded logic of that rule with customer specific requirements, such as a specific condition under which the rule should trigger.

The combination of an extensible entity model and the ability to extend the embedded system logic is a powerful tool that allows a customer to tailor the system behavior to their specific needs.

Configuration Migration

Claimsincludes an embedded configuration migration tool. This tool is allows the customer to create a selection of configuration rules and settings and create an export file. This file can then be uploaded into other environments and automatically updates the configuration rules in that environment. This supports an implementation strategy that relies on separate environments, for example, a sandbox, a configuration primary , a user acceptance and, of course, a production environment.