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

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

  • 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.

Pricing Templates

Oracle Health Insurance Claim 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 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 the their specific needs.

Configuration Migration

Oracle Health Insurance Claim 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, automatically updating the configuration rules in that environment. This supports an implementation strategy that relies on separate environments for, e.g., sand boxing, mastering 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.