Membership Processing

Class Membership rules are created in OIPA using math variable-like syntax within Class Rules and Class Rule Variables. The Membership rules define the characteristics and requirements of each class. Class Membership rules are used to evaluate employee/sponsor clients to determine if they can be included for membership into a particular class. Establishing membership in classes within a Class Group can be used for any grouping purpose and application of common values, such as for plan eligibility, billing or reporting. See Classes for Class Rules and Class Rule Variables.

How it Works

The membership process was implemented to invoke Membership rules that evaluate whether a provided data set for a client record and the associated data satisfy the requirements to allow class membership. The evaluation process for determining membership is executed during activity processing at the client and/or policy level. The transaction pulls client, address and Group Customer relationship data to use during the evaluation process.

This process typically occurs via a client level transaction that is processed during the data intake process. The transaction determines if Membership rules exist for the client and returns an error if class membership cannot be determined. Client level transactions associated with the data Intake process determine plan eligibility, class membership for eligibility and Population files.

Important

At the Client Level, the evaluation occurs on the client the transaction is processed on. At the Policy Level, Class Membership is evaluated for the client designated as the Primary Member role on the policy.

In addition, multiple Policy level transactions can execute Class Membership processing. At the Policy level, the evaluation occurs on the client assigned to the Primary Member role.

Transaction and Activity Level Membership Rule Processing

Both Client and Policy level transactions make use of the Rule variables and Class Rules during the execution of the Class Membership process. Class Rule variables can be defined at the Global, Group Customer and Class Group levels. They are used in the XML then created, stored, and executed at the Class level for each specific class. The Class Rule variables house the specific demographic and employment type data for defining the Class Membership rule being executed.

For Activity Processing at both the Client and Policy levels, the system retrieves the Group Customer data for Policy and Client level activities through the relationship association. The Primary Relationship will indicate Employment. Execution of Membership rules automatically assigns any employees evaluated against the Class Group that do not resolve to any of the defined classes to a default (Orphan) class.

Important

An Orphan class is set up as a default classwhen a new Class Group is set up in OIPA.

Membership Activity Processing

A transaction is configured in the Rules Palette at the Client or Policy level that will evaluate membership to a class.

Note: The Client must have a Relationship to the Group Customer as an Employee to imply Membership to become a Member of a Class.

Employee Relationship with Group Customer

The Data Intake File containing a Member Record to Add will imply that membership needs to be assessed and a Membership related activity will be spawned for processing at the Client or Policy Level.

The system code pulls in the Class Rule Variables and Class Rules, not the configuration. The configuration within the Transaction will be comprised of the Membership Element and its components for the Class Groups, Write Membership, Effective From/To.

We have developed Membership syntax within the configuration specific to writing the Membership records to the database. For more information, please consult the XML Configuration Guide> Transactions > Membership Element.

The Activity is added to the Client (in this example) and processed. The Membership results are displayed within the Class Membership tab.

Activity Results > Class Membership

The system views the Class Rule Variables in order to facilitate that funneling through to get to the last possible terminal leaf node or orphan Class to where the Member will be matched.

Activity Results > Class Rule Variables

The Class Rules facilitate the filtering to the next Class or Orphan Class using syntax that is formed using the predefined Class Rule Variables to form tests and conditions. The tests and conditions evaluate whether or not to move on to the next Class or to stop because a suitable Class was found to which the Client will become a Member.

Activity Results > Class Rules

The Class tree structure can be accessed under ClassGroups and the user can select the applicable Class to view Members.

Class Tree Structure

The Class Rules contain a condition or test that if True, places the Client into Membership with the specific Class. If the condition is false, the system goes to look at the next Parent Class and Child, and if still the condition ends in a False response, the Client will go into Membership within the Orphan Class.

Class Rules

The Members tab allows the user to view the Clients who are now Members of the Class.

Members Tab > Class > Part Time Union Employees

Navigation > Membership Process > Class Membership Activity Results

A Class Membershiptab will be housed on the Activity Results screen of the Activities determining Class Membership. The Class Membership tab will contain a table listing all available Class Names and Class Group Names.

A Class Membership tab will be housed on the Activity Results screen of any Activities that include determination of Class Membership. The Class Membership tab will contain a table listing all available Class Names and Class Group Names.

If the Class Membership syntax was not used within the Transaction, a message will display indicating “No Membership Processing Performed”.

Membership records will be committed to the database (optional) unless the process is to provide a quote. We allow the override of writing the records to the database. The default action is to write the records, but the quote capabilities in the application provides an instance / circumstances where the need is not necessary to write a record to the database. Membership records will exist for the "leaf" records only - the leaf Class Membership only.

Activity Results > Class Membership