Policies Introduction

In Oracle Health Insurance Enterprise Policy Administration (Policies), a policy represents a contractual agreement between a healthcare payer and a policyholder or a group. At a high level, the agreement is this: the payer reimburses (part of) the healthcare costs incurred by person or persons specified on the policy, that is, the members. In return, the policyholder or the group makes periodical payments to the payer.

Per member, the policy specifies the products that the member is enrolled on. Each product comprises a list of healthcare services for which the payer (partially) reimburses the incurred costs. The policyholder may or may not be one of the members.

There are two prevalent scenarios:

  • The payer has a contract with a group. In this scenario the group is typically an organization that seeks insurance for all of its affiliates. For example, an employer who seeks insurance for its employees.

  • The payer has a contract with a directly with single person, the policyholder. This scenario is common in markets where the people buy individual insurance on exchanges and web portals.

In Policies, a group consists of two or more levels, built up out of the following entities:

  • A group client represents the group as a whole. It comprises one or more group accounts.

  • A group account specifies an offering of products and options within the group for a specific segment of the group’s members. For more details on groups see Groups.

The premium is the periodical payment that the policyholder or the group makes to the payer. The exact amount depends on the products on which the members are enrolled, as well as various other factors.
For more information on how to configure premium schedules in Oracle Health Insurance see Premium Configuration. For more information on how Oracle Health Insurance calculates premium for a policy see Calculate Premium.

Policies are updated frequently to accurately reflect changes to the member’s situation. For example, when a new dependent is added to the policy member’s address changes. Every change leads to a new version of that policy.

Creating, Changing and Removing Policies

Policies can be created in the application’s user interface or via the Policy Update Request integration point. This integration point enables you to create or update a single policy or a file of policies.

When the application receives an update to a policy, it does not overwrite the active policy record. Instead it creates a copy of the active record and applies the update to the copy. Once the copy of the policy makes it through the pre-enrollment process the active record is archived as a previous version and the copy becomes the new active policy record.

Users can revert a policy copy record, either via the user interface or by calling the revert policy to previous version operation. This operation removes the policy copy from the application. The active policy record is unaffected.
Reverting a policy is the equivalent of rolling back an unwanted change to the policy, before effectuating the change on the active record.

Users can cancel a policy copy record, either via the user interface or by calling the Cancel Policy operation. This operation behaves like a regular update; the updated copy replaces the active policy record, with the difference that the new active record has the cancelled status. Cancelled policies are still visible in the user interface but they are treated as if they were removed from the application. The cancel operation optionally triggers a corrective premium calculation.

Finally, users have an option to purge a policy by calling the purge policy operation. This operation physically removes a policy, all of its details, and all previous version from the application. The intended use for this operation is to facilitate testing on non-production environments.

History

The policy keeps track of past changes and events relating the policy. This includes:

  • All previous versions of the policy

  • All status transitions that the policy has been subjected to, during the pre-enrollment process.
    This includes all pends, and who resolved those pends.

  • All business events that applied to the policy over time, as detected by the user configured business rules.
    The policy keeps track of past changes and events relating the policy. This includes:

  • All previous versions of the policy

  • All status transitions that the policy has been subjected to, during the pre-enrollment process.
    This includes all pends, and who resolved those pends.

  • All business events that applied to the policy over time, as detected by the user configured business rules.
    For example, the addition of new dependents and plan changes.

  • All bulk updates that the policy has been subjected to.
    For example, the addition of new dependents and plan changes.

Attributes and Settings

Identifiers

Every policy has a unique policy code that serves as its primary functional identifier. This code can either be generated by the application, or it can be assigned by an external source.

In addition, you can store an unlimited number of secondary identifiers on the policy. For example the primary member’s identifier or a legacy identifier. The application uses these alternative identifiers for processing incoming updates, in the event that it fails to find a matching policy code.

Line of Business

Policies enables you to run multiple lines of business and brands side-by-side in the same environment. A policy is linked to exactly one line of business and one brand.

The application enables you run both group-based health insurance, as well as individual health insurance.

Members and Other Roles

A single policy specifies the enrollment details for a subscriber and all of his or her dependents. Each insured person under the policy is represented by a policy enrollment.

Each policy enrollment can be associated with an enrollment type, for example, “Employee” or “Dependent”. The list of available enrollment types is user configurable and is used to determine the policy’s tier during the premium calculation process.

Each policy enrollment can be associated with an insurable class, for example. “Full time employees” or “Part time employees”. The list of available insurable classes is user configurable and is used to determine group plan availability.

Each policy enrollment is linked to one more policy enrollment products. These represent the health plans and riders that the member is enrolled on.

Besides members, there are several other persons associated with a policy, including

  • the person that holds the policy, also known as the subscriber

  • the person that is billed, in case of direct billing

  • the person or organization that acts as broker.

Contract Periods and Policy Calculation Periods

You have the option to set up one or more contract periods under a policy. The purpose of contract periods is to enable the 'Contract based'' premium calculation method. This method calculates premium amounts per calendar year and the contract period is used to prorate the charged premium in case of early disenrollment and to ensure accurate rounding when the yearly premium calculated in monthly segments.

Alternatively, you have the option to set up one or more policy calculation periods. The purpose of policy calculation periods is to enable the ‘Policy calculation period based’ calculation method. This method calculates premium for a series consecutive periods of irregular length, supporting a pay-as-you-go insurance model, as opposed to premium calculation based on predefined set periods such as calendar months.

Collection Settings and Split Bill Allocations

Collection settings control who is billed, and how often they are billed, for the calculated premium. For group policies the collection settings are optional, as they are defined on the group level.

Premium bill allocations control premium splits in the scenario where the calculated premium is split up in separate segments, and each segment is billed towards a different a different person or organization.

Cost Share Parameters

Policies enables you to control the key cost share parameters, such as the plan deductible and out-of-pocket costs on the policy enrollment product level, that is per member per product. The selected parameters drive the applicable premium rate, and when Policies used in combination with Claims, the parameters are used in the claims adjudication process.

Policy Accounts

Policy accounts are balance accounts that are linked to the policy, for example to represents Health Savings Accounts. When Policies used in combination with Claims, an adjudicated claim can draw from such a policy account to pay for the member liable costs.

Processes

Pre-enrollment processing

Newly created policies to go through the pre-enrollment process before they are installed as active policies. Likewise, an updated policy needs to go through the same pre-enrollment process before the update is effectuated.

The pre-enrollment process comprises a series of user configured business rules that the new or updated policy must pass. If it does, the new or changed policy is effectuated. If it does not, the change is submitted to manual review and possibly to remediation.

Pre-enrollment business rules are user configured rules that serve a variety of purposes, including

  • Checking that the policy data elements are correct and complete

  • Calling out to other components to apply business logic that is hosted outside of Policies

  • Detecting the relevant differences between the active and the updated policy

  • Detecting situations that require manual review.

Premium calculation

Policies has a sophisticated premium calculation function, that supports a variety of calculation methods. The premium calculation results are fully versioned, supporting complex corrective billing scenarios, in conjunction with the native change event rules that automatically detect retro-active changes that require recalculation and rebilling.

Example premium calculation

The example calculation function is identical to the regular premium calculation function, with the difference that it does not create permanent calculation results. This function is ideal to support what-if scenarios for existing policies, either directly in the user interface for testing purposes, or invoked by a member portal to support a member inquiry.

Premium quote calculation

The quote calculation function is identical to the regular premium calculation function, with the difference that it is not invoked on an existing policy, but on a theoretical in-memory policy. This function is ideal to calculate the expected premium for a new policy, prior to enrollment.

Bulk Updates

Every policy can be subject to bulk updates. A bulk update is a pre-defined change that is applied across multiple policies, such as future end-dating all policy enrollments for a specific group.

Access Controls

A policy and its details can be subject to multiple layers of access controls. A user requires access grants for all of these layers to access the policy. The different layers are:

  • Line of Business.
    You can restrict access to policies based on the line of business that they belong to. For example, consider a single environment that runs multiple lines of business, where user access is restricted to one specific line of business.

  • Brand
    You can restrict access to policies based on the brand that they belong to. For example, consider an environment that includes multiple brands for the same line of business, where user access is restricted to one specific brand.

  • Data Access Group
    You can restrict access to a subset of policies within a line of business. For example, consider a data access group that is used to restrict access to all payer employees.

  • Identifier Type
    You can restrict the visibility of policy identifiers. This is relevant when an identifier is based on personally identifiable information, such as a social security number.

  • Person Details
    You can restrict access to a specific person. Users that do not have access to the person, but do have access to the policy can still see the enrollment, but are not able to see the person itself.

  • Dynamic Field Usage
    You can restrict access to specific user configured field on a policy.