Oracle Health Insurance Value-Based Payments

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 Value-Based Payments 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 access the information it needs to generate payments. These payments represent reimbursment for health care services that are not reimbursed fee-for-service, such as a capitation arrangement in which the payer reimburses the provider for a fixed amount per member per month.

The contract between the payer and the provider is the basis for the reimbursment schedule. For example, a contract may specify that for a specifc list of services the provider is reimbursed 15 USD per month for each member that is assigned to that provider, in lieu of fee for service payments.

Oracle Health Insurance Value-Based Payments automates the reimbursement calculation of such the contract. This process contains the steps listed below:

The application holds a local copy of the member data that is synchronized with the member system of record
Per contract, the application selects the members that are aligned with that contract, typically based on the member's plan
Per aligned member, the application determines if member falls within the boundaries of the contract
Per aligned member, the application determines to which provider that member is to be attributed (if applicable)
Per attributed member, the application determines the reimbursment rate and stores the calculation details
The application produces a payment file that servces as input for the accounts payable system

A key feature of the application are the configurable business rules that detect specific retro-active changes to member data and configuration settings. Such changes can affect previous calculation results and consequently require a corrective calculation. When a retro change occurs that potentially invalidates previous results, the application flags the changed data and derives which contracts and members are affected. The next time the affected members and contracts are included in a calculation, the system automatically corrects for past calculation results as well.

Attribution and Rate Determination

Oracle Health Insurance Value-Based Payment's core functionality is to calculate financial transactions that represent non-fee-for-service reimbursment for provided healthcare services. Such arrangements typically seek to reduce cost and improve upon healthcare quality, by shifting the financial risk from the payer towards the provider.

Contract records are the operational data within the application. The calculation process is a function of a contract. It uses the member enrollment information as the source data to calculate the remimbursement that is due within the context of a contract. This calculation process consists of two steps, attribution and rate determination.

Attribution

The contract between a provider (network) and the payer in which the method of reimbursment is specified, can specify additional restrictions. These restrictions can apply to the member and the provider. For example:

Only generate payments for members that are over the age of 18
Only reimburse providers if they are in a specific network
Only reimburse providers if they have more than 10 members attributed to them

The first step of the process selects all eligible members and determines for whom payment should be generated. For each eligble member, the application creates an attribution. An attribution represents a record that states that: "Member A is attrbuted to Provider B from effective date C through date D."

Note that attributes are volatile operational data and need to be re-established on regular intervals. All of the frequently occuring following events may impact attributions:

Members that change from one benefit plan to another
Members that change from one primary care provider to another
Providers that end their affilation with the network that controls the capitation contract

Rate Determination

The calculation process takes the generated attributions as input, determines the applicable rates and adjustments and produces financial transactions as output. The reimbursment rate is determined by the rate schedule and rate adjustments that are set up onder the contract.

A rate schedule is a re-usable look-up table for reimbursment amounts. It consists of one or more rate lines. Each line consists of a configurable number of fields (columns) that represent conditions and a rate amount field. The amount represents the reimbursment that applies if all the conditions on the line are met. Typical rate schedules include columns for the member's age, gender and details from the plan on which they are enrolled.

New schedule dimensions are set up quickly. The configuration user selects which fields on the member / provider / contract are relevant and the application then automatically show a corresponding column in the schedule. During the calculation the application compares the value on the input data with the value in the schedule without the need for any further configuration.

A rate adjustment rule is similar to a rate schedule, except that it leads to a percentual or absolute adjustment rather than a base amount. For example, if the member falls into a high health risk category, the base rate is increased by 20%. This means that the provider is reimbursed more for patients that are liable to require more healthcare services.

Besides calculating reimbursement rates based on (discrete) schedules, the application also supports rate calculations through analog functions.

Each calculation (result) is versioned and persisted in the application. The system keeps track of each calculation detail down to the most specific level, i.e., per contract, member, provider, schedule and adjustment.

Change Events

Oracle Health Insurance Value-Based Payments has a very powerful feature that supports the automated detection and recalculation within the context of retro active changes that can potentially lead to corrective calculation.

The user can set up change detection rules for each entity in the system. These rules can be broad in scope (such as the insertion of a new member record) or more specific (such as an update to a member's date of birth). When the system detects the specified change, it will automatically flag the entity as having been subject to a change.

Once flagged the system derives which contract / member combinations are affected. A single change can affect many calculations e.g., consider a retroactive change to a rate schedule. When the calculation activity is next initiated the flagged contract / member combinations are automatically recalculated. Their previous calculation results are retracted and is replaced by a new calculation result that takes into account the retroactive change.

The user configured detects rule controls which fields are susceptible to a recalculation event. This way the application knows which changes are irrelevant for calculation purposes (such as updating a person's name) versus which changes may be significant (such as updating the effective date for a particular benefit plan). These rules also control the effective date of the change. E.g. when retro terminating a benefit plan, the capitation payments have to be recalculated as of the day the plan is now no longer effective. A second exmplr is when retro enrolling a member. In this case the capitation has to be calculated as per the effective date of the new benefit plan.

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, such as starting a calculation
the masking of sensitive date, like the masking of contact information on member records/li>
data access controls, such denying access to specific set of members such as payer employees

A user's access privileges depend on the roles that are assigned to that user, and are enforced throughout the application including 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 Oracle Health Insurance Value-Based Payments. 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 when it comes to synchronizing 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 from accessing 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, such as synchronizing member records or installing contract configuration.

Extensible Model and Logic

All entities within the application (like contracts, members 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, including the data type, value domain, uniqueness and conditions to appear for these user defined fields. Once configured, these customer defined fields are indistinguishable from embedded fields. They automatically become available as attributes in the relevant integration points as well as in the generic API. They automatically appear in the user interface.

The values of these customer defined fields can be used in the calculation work flow. For example, the contract can be set up to select the reimbursment rate based on the value of a customer defined field on the member record.

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.