Application Overview

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

Policies stores the member enrollment information and uses that information to automate the corresponding premium (re) calculation cycles:

Per configured cycle, the application:

  • selects the member policies for which a calculation is due

  • selects previously calculated policies that have been affected by retroactive changes

  • (re) calculates the premium amount for the selected member policies

  • produces financial messages to be consumed by the downstream Billing and Collection application

Policies includes an embedded workflow for new member policies and changes to existing member policies. It is possible to add user defined checks and rules to this workflow to ensure all enrollments adhere to the customer’s business rules. Member policies that have not been approved are not part of the premium calculation.

Policies also includes configurable integration points that are designed to share information with other systems. It includes, for example, an integration point that can be used to provide the claims adjudication engine with current enrollment information upon adjudication of a claim.

Within the context of this document a policy represents a contract between the payer and the member (or the payer and the group to which that member belongs). The contract lists all the insurance products to which the member, including dependents, are enrolled, including effective dates, chosen options and other member specific settings that affect either the coverage or the related premium of those products.

Enrollment and Premium Calculation

Member Enrollment

Policies acts as the system of record for member enrollment information. This is the information required to determine the applicable coverage and also to determine the applicable premium rate and includes but is not limited to:

  • the benefit plan on which the member is enrolled

  • the provider networks that are selected

  • the group to which that member belongs (if group insurance applies)

  • the member liability levels that are selected

  • the additional coverage options that are selected

Member policies can be keyed into the application directly or can be submitted through integration points (for example when connected to a member portal). When a new policy is submitted, it first goes through an automated workflow before being approved and activated. The workflow includes user configured business rules that can:

  • enrich the policy records by stamping on additional information

  • call out to other applications to retrieve relevant information

  • pend the policy for review if it meets the configured pend criteria

At the end of the flow the policy is approved and becomes active. Active policies are picked up for premium calculation and appear as active to contingent systems like the claims adjudication engine.

When updating a member policy the application automatically creates an identical copy of the current active policy. All edits are performed on the copy policy and it is the copy that goes through the embedded workflow. Once the copy successfully completes the workflow, it replaces its original and becomes the active policy. This pattern ensures that the system keeps a record for each policy version that was active at one point in time and that the system never picks up a policy that is in an inconsistent state; it always uses the last approved version of a policy for calculation purposes.

Group Clients

Policies includes native support for both group and individual health insurance. Group clients can be set up as multi layered organizations where product availability and premium schedules can be controlled on each layer / node in the hierarchy.

Group configuration is also hierarchical in the sense that rules and schedules that are set up at the highest level apply to all parts of the group, unless overridden by rules or schedules attached to a specific part of the group. This pattern allows for a flexible and transparent group configuration.

The financial transactions that originate from group members can be rolled up and aggregated into consolidated financial messages, while retaining the detail line items that specify the rates and adjustment per individual group member.

Premium Calculation

Policies has several embedded calculation methods to calculate premium. The primary method relies on premium rate schedules and adjustment rules.

A premium schedule is a re-usable look-up table for premium amounts. It consists of one or more premium schedule lines. Each line consists of a configurable number of fields (columns) that represent conditions and a single premium amount field. This is the premium amount that applies if all the conditions on the line are met.

New schedule dimensions are set up quickly. The configuration user selects which fields on the member / product / policy are relevant (such as the 'smoking?' indicator on a member record) and the application will automatically show a corresponding column in the schedule. During the calculation the application will compare the value on the member record with the value in the schedule without the need for any further configuration.

An adjustment rule is similar to a premium schedule, except that it leads to a percentual or absolute adjustment rather than a base amount. For example, if the group client pays all premiums

  • the month it is due, there is no discount

  • six months in advance, the total base premium is discounted by 1.5%

  • a year in advance, the total base premium is discounted by 3%

A benefit plan can have can have multiple applicable premium rate schedules and multiple applicable adjustment rules. Adjustment rules can be applied simultaneously or in a configured sequence.

Besides calculating premium rates based on (discrete) schedules, the application also supports rate calculations through analog functions or through rates that are externally calculated and stamped on the member policy records.

Each calculation (result) is versioned and persisted in the application. The system keeps track of each calculation detail down to the most specific level, that is, per member, per product, per schedule or rule and per time period.

Change Events

Policies 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 policies are affected. A single change can affect many policies, for example consider a retroactive change to a group client setting. When the calculation activity is next initiated the flagged policies are automatically recalculated. This means that 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 premium has to be recalculated as of the day the plan is now no longer effective. A second example is when retro enrolling a member the premium 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 rules support several types of access protection:

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

  • business operation access, like the (re)submission of a policy to the validation workflow

  • sensitive date masks, applicable to, for example, member contact information

  • data access controls, that deny access specifically to employee or VIP polices but not to other policies

A user’s access privileges depend on the roles that are assigned to that user, and are enforced throughout the application. This includes the user interfaces pages as well as the application’s web services.

Integration

All Oracle Health Insurance applications 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 ofPolicies. 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, for example, to synchronize 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 having unintended access to 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, for example, to submit a policy, synchronize a member record or to install a new group configuration.

Extensible Model and Logic

All entities within the application (like policies, members, products 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. This includes control over the data type, value domain, uniqueness and availability of the user defined fields. Customer defined fields are indistinguishable from fields that are native to the application. They automatically become available in the integration points as well as in the generic API and user interface.

The values of these customer defined fields can be set by, and used in, the premium calculation workflow and the enrollment workflow. For example, it is possible to derive the value of the customer field on a member policy by evaluating other fields on the policy.

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.

Document Source File Generation

Policies includes configurable rules that produce source files for document generation purposes. Examples are source files for member ID cards and member plan descriptions.

For each type of source file, the user configure the syntax and the scope of the payload. The application relies on change events in combination with a preconfigured cycle to detect what information has to be included in the source file.

For example, this feature can be configured to produce an entry for a new member ID card for each member either once every five years or when a data element that is on the card changes, such as the member’s name or date of birth. Whichever happens first.

Configuration Migration

Policies 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 configuration master, 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 handles the 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 an environment that is typically the source (such as the configuration master environment).