Oracle Health Insurance Authorizations

Introduction

Oracle Health Insurance Authorizations is an enterprise strength healthcare payer back office application. It is designed as an application that holds only limited information and relies on integration with contingent systems.

Oracle Health Insurance Authorizations stores Authorization information and includes an embedded workflow for new Authorizations and changes to existing Authorizations. It is possible to add user defined checks and rules to this workflow to ensure all Authorizations adhere to the customer’s business rules.

Oracle Health Insurance Authorizations is a rule engine that gives the flexibility to streamline the Authorization processes. It enables increase in auto-Authorization rates by automatically handling standard requests. The application also includes advanced decision table logic to detect non-standard requests and to delegate these to the clinical review staff.

Oracle Health Insurance Authorizations includes configurable integration points that are designed to share information with other systems. For example, the enrollment integration point can be used to retrieve plan information from the member enrollment system. The retrieved information can then be used to make an informed decision on whether to Approve or Deny the Authorization.

Oracle Health Insurance Authorizations tracks all business rules that are applied during the adjudication of the Authorization. It also supports notes, capturing relevant information on clinical decisions. As a result, providers and members can be given full insight in the outcome of a processed Authorization, which reduces the number of inquiries and appeals.

Within the context of this document an Authorization represents the fact that a specific service type, procedure of health care, that requires pre-approval before it can be claimed, is Approved or Denied. In addition to these pre-approval Authorizations Oracle Health Insurance Authorizations also supports storing and handling referrals and notifications.

Authorization Workflow

Oracle Health Insurance Authorizations is as the system of record for Authorization information. An Authorization (or pre-service Authorization request) is the advance approval a physician or other health care provider is required to obtain for a service or item furnished to a member. Authorizations information can include (but is not limited to):

• The type of Authorization 1) Authorization 2) Notification 3) Referral

• The Provider, Person or Organization requesting the Authorization for Services

• The member for whom the Authorization is requested

• The Provider delivering the services and the location at which the Services will be provided

• The Specialty for which the Authorization is requested

• The Amount, number or number of days of Service requested

• The Amount, number or number of days of Service authorized

• The time validity of the Authorization

Authorizations can be keyed into the application directly or can be sent in through an integration point (for example, when connected to a provider portal). After the Authorization has been entered it can be submitted for processing.

Process Authorizations

The embedded workflow has three main steps: the callout for enrollment information, the application of user defined business rules and the finalization of the process results.

Enrollment Callout

Oracle Health Insurance Authorizations does not persist enrollment information locally. Whenever an Authorization is processed, the system calls out to the member enrollment system and retrieves the member’s plan information. This information can then be used by subsequent steps.

Process Steps

The configurable processing logic can implement the various clinical rules that ensure the appropriateness and effectiveness of the requested services in relation to the current medical condition of the member but also the medical history as captured in previous Authorizations and in paid Claims.

The processing of an Authorization involves sequential execution of Process Steps. A process step groups various related and interdependent process rules - Callout Rules, Event Rules, Validation Rules and Pend Rules - to be executed in a specific order. Each Authorization is processed individually.

Callout rules

The Callout Rule calls out to other components with a real time request for information. The response payload can be used to drive decision rule logic. The callout is triggered during the processing of an Authorization. A condition can be added to the configuration of the rule to determine if the callout must be executed for a specific Authorization.

Event Rules

It might be of interest to external systems or users to know that a certain Authorization during processing has reached a certain Process Step or a certain Rule Step has got executed with a certain message. Event Rules can publish event messages to an external system when the configured condition(s) occur.

Validation Rules

The validation rule facilitates the business to perform specific checks on the data elements of the Authorization. Together with Callout Rules, Validation Rules form the central processing concept for Authorizations.

Typically, a Callout Rule will fetch information from another component on, for example, pricing information or benefits or fraud detection. This information will then come back to Oracle Health Insurance Authorizations and be stored there so that it can be used in a Validation Rule. The Validation Rule may use solely information on the Authorization, information provided by the Callout Rule or it may invoke pre-configured reference sheets.

The result of a validation evaluating to true, is that a message is attached to the Authorization. The message can be used to Pend or Deny the Authorization.

Pend Rules

In certain circumstances it might be necessary to Pend an Authorization for manual intervention for example, when the requested Amount exceeds a configured threshold or when the Person does not have an Enrollment Product for all the procedures for which the Authorization is requested.

The system evaluates all the configured Pend Rules for a process step. The Pend Rule describes the circumstance in which an Authorization Pends. When the specified criteria on the Pend Rule are satisfied, the Pend is said to be applicable and the Pend Reason is attached to the authorization.

If any of these Pend Reasons are required to be published to an external system the system communicates the Pend Reasons by sending out a message through an integration point.

The system then sets the status of the Authorization to Pended and adds a status history record and pend history records for all Pend Reasons that were raised in the current process step.

Finalizing the Result

After execution of all the process rules the system determines if the Authorization is Approved or Denied. The Authorization status is updated to Approved if there is no message of severity Fatal present on the Authorization. If there is a message of severity Fatal, then the Authorization status is updated to Denied.

An Approved or Denied Authorization can still be edited if required. Editing creates a new Version of the Authorization and makes it possible to modify and reprocess the Authorization while maintaining all older information in the previous version.

External Interfaces

Provider Contracts, Pricing, and Benefits

Oracle Health Insurance Authorizations uses the Provider contract configuration and pricing logic in Oracle Health Insurance Claims Adjudication and Pricing to determine the authorized Amounts for the services requested. Likewise, leverage the benefit configuration in Claims adjudication to determine the level of benefits for the requested services, to pro-actively inform the member.

Policy Enrollment

Oracle Health Insurance Authorizations communicates to the Enrollment system though the Enrollment Request integration point. It calls out for information directly related to the member’s Policy Enrollment status. The Enrollment information is persisted in such a way that it is available until the Authorization is submitted again for re-processing.

Authorization In

The system facilitates through this synchronous integration point the creation of an Authorization by an external system for example, a portal. Through this integration point an external system can create or update an Authorization. It is not possible to withdraw (delete) an Authorization request through this integration point.

Authorization Out

The Authorization Out integration point supports:

• receiving a request for information on an Authorization

• responding to that request by sending information on that Authorization through a response message

Whenever an Authorization outcome is finalized, the application logs the relevant status change. This enables other systems, such as the Claims adjudication system, to actively monitor the activity of Authorizations. If and when required, these subscribing systems can request additional information from Oracle Health Insurance Authorizations.

Key Features

Access Control

All the 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

• 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 the 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 Authorizations. 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 Authorizations, 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 support 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 to drive decisions in the Authorization work flow.

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.

Configuration Migration

Oracle Health Insurance Authorizations 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, for example, a sandbox, a primary configuration, 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 primary configuration environment).