Oracle Health Insurance Claim Adjudication

Application Overview Guide

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Introduction

Oracle Health Insurance Claim Adjudication 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 extend 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.

Oracle Health Insurance Claim Adjudication automates the execution of the second contract, i.e., 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/her relation to the member's insurance
Produce a representation of the adjudicated claim
Produce a financial transaction

Oracle Health Insurance Claim Adjudication 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 Oracle Health Insurance Claim Adjudication. 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, 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. Oracle Health Insurance Claim Adjudication 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

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 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, e.g., the combination of medical codes that represent an office visit, from the configuration that is typically different beteen products, e.g., 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. These parameters are then retrieved from the member enrollment system while the claim is processed. This architecture promites reuse of configuation 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 a 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 copays
whether a post coverage calculation calculation applies, for example, within the context of coordination of benefits

Accumulate and Calculate Coverage

Oracle Health Insurance Claim Adjudication 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 / withhold rules. Multiple rules are comnined to form reusable calculation templates.

These templates drive the sequence of rules that apply, e.g., first apply the deductible rule, followed by the copayment 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, e.g., 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 application supports a several types of access protection:

entity / 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, applicabe to, e.g., 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 includes 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 OHI Claim Adjudication. 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, e.g., 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 unintenden access 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, e.g., 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 interfance.

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 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 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 of 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 do not lead to any financial transactions. 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. through.

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

Oracle Health Insurance Claim Adjudication includes 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, e.g., a sandbox, a configuration master , 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 master environment).