Application Overview

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 Payments’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, for example, 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. For example, 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 example 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 applications include configuration rules that assign access privileges to user roles. These applications support 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 applications 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.