Membership Processing
Class Membership Rules were 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. The Class Membership Rules will be 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 employee/sponsor client grouping purpose and application of common treatment/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 to evaluate if a provided data set for a Client record and the associated data satisfies the requirements to allow Class Membership.
- The evaluation process for determination of Membership will be executed during Activity processing at the Client and/or Policy level.
- The Transaction will obtain Client, Address, and Group Customer Relationship data to using during the evaluation process.
- The common method of execution is completed via Transactions that occur during the data intake process (for determining class eligibility) at a Client or Policy level. Client level transactions associated with the Data Intake process will include determination of Plan Eligibility Class Membership for Eligibility and Population files.
Note: At the Client Level, the evaluation will occur on the client that activity is processed on. At the Policy Level, Class Membership will be evaluated for the Client designated as the Primary Member role on the Policy.
Transaction and Activity Level Membership Rule Processing
Both Client and Policy level transactions will make use of the Class Rule Variables and Class Rules during the execution of the Class Membership process.
Class Rule Variables can be defined at the Global, Group Customer, Class Group, and Class Levels. Rule Variables defined at the Class level are specific to that particular Class and not shared or viewed across Classes.
- The Class Rule Variables will house the specific demographic and employment type data for defining the Class Membership Rule being executed.
- The Class Rules will use the Variables in tests and conditions to aid in the funneling of employees to the proper leaf node class so they become a member of the appropriate class.
For Activity Processing at both the Client and Policy levels, the system will retrieve the Group Customer data for Policy and Client level activities through the Relationship Association. The Primary Relationship will indicate "Employment".
Important | Execution of Membership Rules will automatically assign any employees evaluated against the Class Group which do not resolve to any of the terminal/leafClass nodes will default to a default (Orphan) Class. |
Note: An Orphan Class is set up as a default Class anytime 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.
Important | The Client must have a Relationship to the Group Customer as an Employee to imply Membership / Eligibility to become a Member of a Class. |
The Data Intake File from the Group Customer containing a Member Record to Add will imply that eligibility/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.
Example:
- The Activity is added to the Client Level and processed. The Membership results are displayed within the Class Membership tab.
- 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.
- 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.
- The Class tree structure can be accessed under Class Groups and the user can select the applicable Class to view Members.
- 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.
- The Members tab allows the user to view the Clients who are now Members of the Class.
Class Membership Activity Results
A Class Membership tab 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.
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.