Oracle Health Insurance Claims Pricing

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 Claims Pricing 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 reprice 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 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 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 Claims Pricing automates the execution of the first contract, i.e., 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

Oracle Health Insurance Claims Pricing 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 Oracle Health Insurance Claims Pricing. 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. Oracle Health Insurance Claims Pricing 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

Call Out Rules - These are rules that call out to external services to retrieve information that is required to price 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 '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. 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.

Pricing Templates

Oracle Health Insurance Claims Pricing 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

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

Configuration Migration

Oracle Health Insurance Claims Pricing 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).