Groups Introduction

A policy represents a contractual agreement between a healthcare payer and a policyholder or a group. In this context, a group is an organization that offers the people affiliated with that organization an option to enroll on a health insurance plan. For example, a group could be an employer seeking to insure its employees.

Some groups have elaborate structures that consist of multiple levels, while others are simple, single-level organizations. An example of an elaborate group is an employer with employees in multiple countries and departments, with each country and department acting a as an independent subsidiary. An example of a simple group is a small business owner that seeks insurance for its 30 employees.

In Oracle Health Insurance, a group is represented by a group client and one or more underlying group accounts. You can create complex group structures by creating multiple group clients and linking them to the same parent group client. There is no limit to the number of levels you can introduce this way. Each distinguishable segment within a group client is represented by a group account. The group account specifies which products are available for members assigned to that group account.

If you think of a group as a tree structure of subsidiaries and departments, in [ohi], each node in the tree is a group client and each leaf is a group account.

In Oracle Health Insurance, a simple group consists of a single group client with one single group account. In contrast, a very complex group consist dozens of group clients that form a multi-level tree, each branch ending in a leaf of multiple group accounts.

Group Clients

The group client entity represents a node in the hierarchy of the group structure. Each group client can be linked to a parent group client, enabling you to create complex group structures.

Each group client has a variety of settings, affecting all of underlying details in the hierarchy, especially the members, products and premium rates. Many of these settings are available both at the top level of the group as well as on the more granular levels below, enabling you to maintain default settings for the entire group at the top, while also keeping overriding exception settings at the granular level. This flexibility prevents redundancy in the group configuration and increases the ease of maintenance. See Group Settings and Overrides for more details.

The application has a native process flow for group client validation. The user can set up any number or group validation rules. These rules enrich the group client and ensure the quality of the group configuration.

Whenever a new group is created, or an existing group is updated, this validation process is initiated, and all rules are applied in the configured sequence. Once the group client passes all of the validation rules, the status of the group is set to ‘Approved’.

Group Accounts

The group account entity represents a separate segment of a group. It controls which products and product options are available for the group members with the segment and it controls which billing accounts are used for premium billing.

Like group clients, each group account has a variety of settings, affecting all of underlying details in the hierarchy, especially the members, products and premium rates. Any settings that are specified at the group account level, override those set at the group client level.

Within the context of a group account, you can specify one or multiple insurable classes. These are member sub segments that provide additional control over which products and options are available to the member.

When a group member enrolls, the application links that member’s policy to the group account under which the member enrolled, and the group member is assigned to one of the insurable classes. Both the link to the group account and the assigned insurable class have an effective start and end date, to support the scenario that a group member moves from one group account to another, or from one insurable class to another.

Group settings and Overrides

Many settings and controls can be configured on either the policy level, the group account level or the group client level. In the scenario where the same settings is configured at two or more levels, the application always applies the setting at the most specific level.

For example, the premium collection setting controls whether premiums are direct billed to the member or billed to the group. This setting can be configured at the policy, group account and group client level. If the group client level specifies that all premium is billed to the group, then this applies to all underlying policies. However, if one specific policy also has a setting that specifies that the premium is direct-billed to the member, then for that one specific policy the premium is direct billed, overriding the setting at the group client level.

Table 1. Multi Level Policy Properties and Their Priorities
Property	Level Priority
Premium Schedule	1st Group Account Product 2nd Group Account 3rd Group Client 4th Enrollment Product
Adjustment	Enrollment Product 1st Group Account Product 2nd Group Account 3rd Group Client NOTE If the configuration holds adjustment rules at enrollment product level and at group level, the premium calculation applies both. If group adjustment rules exist at different group levels, the premium calculation applies group adjustments according to the listed priority. Group Account Periods enable overriding the adjustment values for a specific adjustment for a specific period of time.
Broker Agent	1st Policy 2nd Group Account 3rd Group Client
Collection Setting	1st Policy 2nd Group Account 3rd Group Client 4th Parent Group Client (and further up the Group Client hierarchy)
Billing Account	1st Policy 2nd Group Client
Bill Allocation	1st Group Account 2nd Group Client
Group Commission Rate	1st Group Account 2nd Group Client
Process Flow	1st Policy 2nd Group Client
Assigned Provider Group	1st Group Account Product 2nd Enrollment Product
Parameter value	1st Group Account Product 2nd Enrollment Product

Group Maintenance

Policies provides several user interface pages and web services to facilitate the creation and maintenance of groups and group configuration:

The seeded JET user interface pages
The Group Client integration point
The Group Client Note integration point
The Group Account Note integration point
The Group Account Product Adjustment Rules operation
The generic groupClients and groupAccounts API’s

Group Status

Each group client has a status attribute. The status indicates whether the group configuration is complete (status “Approved”) or whether it is presently undergoing a change that is yet to be completed and validated (status “Changed”).

Groups that have the status “Changed” can be excluded from the premium calculation process, preventing the application from creating billable charges based on incomplete configuration.

There are multiple ways that a group can transition from the “Approved” status to the “Changed” status, including via the API, integration points, user interface and dynamic logic.

There is only one way to transition from the “Changed” status to the “Approved” status. To do so, the user starts the group client validation process, either by calling the API or submitting the group client changes in the user interface. This process applies a series of user configured validation and enrichment rules. Once the application has applied all rules and checks without encountering a violation, the status of the group client is set to “Approved”.

User Access

The application enables restrict access to a group client or group account. The following access restriction types impact the accessibility of a group client or group account.

Data Access Group: A Data Access Group Restriction on a group client or group account restricts the access to that group client or group account and its details.
Data Access Group on Policies: A Data Access Group Restriction on a policy restricts the access to a policy. This setting can be configured so that one single data access group controls access to all policies in the group.
Line of Business: A Line of Business Restriction on a line of business restricts the access to group clients for that line of business and their details.
Dynamic Field Usages: A Dynamic Field Usage Restriction on the (usage of a) dynamic record or dynamic field restricts the access to those dynamic records and dynamic fields on the group or its details.

The application supports Data Access Group and Line of Business access restrictions on group clients, group accounts and policies. These access restrictions do not inherit the group account’s or group client’s access restrictions.

These restrictions apply in addition to the function access restrictions on the api.