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, including

• entity / resource access, with separate settings for create, retrieval, update and delete privileges

• business operation access, like the submission and reprocessing of claims

• the masking of sensitive date, like the masking of contact information or and medical service codes on a claim

• data access controls, such denying access to specific set of claims such as employee claims or VIP claims

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 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 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 submitting claims, synchronizing accumulators or installing 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, 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 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 by evaluating 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 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 do not lead to any financial transaction. Encounter claims are typically processed to have a better understanding of the costs that would be incurred if the claim were paid, so that they can be compared to 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 either expires or until a regular claim is matched to the reservation, meaning that it is free to use 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 during the time it takes for the actual claim to come 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 an 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 for maintaining and setting up (new) benefit plans rather than for 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 claims 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 one or more of these rules, the workflow will not produce a product file, but will throw the configured error message instead, forcing the end user to remediate the plan 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, automatically updating the configuration rules in that environment. This supports an implementation strategy that relies on separate environments for, for example, sand boxing, primary configuration, user acceptance testing and, of course, production.

Configuration rules typically follow a hierarchical model. Small reusable setup items (such as groupings of service codes or diagnosis codes) are the building blocks for configuration rules (such as pend rules or benefit specifications). The tool facilitates the migration process by automatically deriving and including the required setup up items for a given configuration rule.

The tool is designed to handle a waterfall migration path as well the incidental circular migration path, supporting a scenario where the target environment gets updated before the source environment.