Reseeding (Specific to Health Insurance Domain)

In the self-funded health insurance business, there might be situations when you may want to disaggregate the claim, enrollment, and ancillary transactions. The system enables you to disaggregate the claim, enrollment, and ancillary transactions until these transactions are not billed to the customer. If a transaction is billed to the customer, you cannot disaggregate the transaction using the normal transaction disaggregation process.

In the following scenarios, you may want to disaggregate the claim or ancillary transactions once these are billed to the customer:

• The changes are made to the specific stop-loss (SSL), aggregate stop-loss (ASL), discount arrangement, or level funded pricing rule which is used during the transaction aggregation process.

• A new pricing rule is created using a specific stop-loss (SSL) or aggregate stop-loss (ASL) pricing rule type which is added in the claim or ancillary pricing rule type using which the claim or ancillary transaction is processed.

• A new pricing rule is created using a discount arrangement pricing rule type which is added in the claim or ancillary pricing rule type using which the claim or ancillary transaction is processed.

• A new pricing rule is created using a level funded pricing rule type which is added in the claim or ancillary pricing rule type using which the claim or ancillary transaction is processed.

• A specific stop-loss, aggregate stop-loss, discount arrangement, or level funded pricing rule type is added as related pricing rule type in the claim or ancillary pricing rule type using which the claim or ancillary transaction is processed.

The former scenario arises due to change in pricing rule, whereas the latter four scenarios arise due to the late setup. In such scenarios, you can create the Accumulation Group Based Disaggregation Request (also known as Reseeding Request) to disaggregate the claim and ancillary transactions. In the Accumulation Group Based Disaggregation (also known as Reseeding) feature, the system allows you to create the reseeding requests for the accounts using a parent accumulation group. At present, you can create the reseeding requests for the accounts only from the user interface and not through the Disaggregation Request Creation (C1-DISTG) batch.

While creating a reseeding request using the Parent Accumulation Group request type, you can specify the accumulation type (i.e. whether it is stop-loss or discount arrangement). If the accumulation type is set to Stop Loss, the system provides the Disaggregate All Account option. If you select the Disaggregate All Account option, the system considers accounts of all bill groups of the parent customer (for whom the parent accumulation group is created) and then creates a reseeding request for each such account. However, if you do not select the Disaggregate All Account option, the system considers accounts of only those bill groups where the parent accumulation group is used for creating the specific stop-loss and aggregate stop-loss pricing rules and then creates a reseeding request for each such account. In addition, the system creates a reseeding request for the ASSL and ASL Credit accounts which are specified in the specific stop-loss and aggregate stop-loss pricing rules, respectively. Note that the reseeding requests are created for the ASSL and ASL Credit accounts irrespective of whether the Disaggregate All Account option is selected or not.

However, if the accumulation type is set to Discount Arrangement, the system does not provide the Disaggregate All Account option. In this case, the system, by default, considers accounts of all bill groups of the parent customer (for whom the parent accumulation group is created) and then creates a reseeding request for each such account.

In the Reseeding process, you need to execute the following batches in the specified sequence:

1. Identify Transactions for Disaggregation (C1-IDENT) - It fetches the reseeding requests for accounts and then identifies the claim or ancillary transactions for disaggregation. If the reseeding request is created due to change in a pricing rule, the BILLABLE_​CHG_​ACT_​CD column corresponding to the specific stop-loss, aggregate stop-loss, discount, or level-funded billable charges in the CI_​DISAGG_​BCHG_​DETAIL table is set to Billable Charge is Part of Frozen Bill Segment (40). It indicates that no action must be taken on these billable charges. And, if the reseeding request is created due to the late setup scenarios, the claim or ancillary transaction and its legs are moved to the CI_​TXN_​DETAIL_​STG and CI_​TXN_​DTL_​PRITM_​STG tables, respectively. In addition, the status of the claim or ancillary transaction is changed to Uploaded. For more information about the parameters, refer to ORMB - Transaction Feed Management - Batch Execution Guide.

2. Process Non-Aggregated Transactions (C1-PDTXN) - If the reseeding request is created due to change in a pricing rule, it does the following:

   • The specific stop-loss, aggregate stop-loss, discount arrangement, and stop-loss and discount specific level funded transaction legs, whose corresponding bill segments are in the Frozen or Pending Cancel status, are forcibly deleted from the CI_​TXN_​DTL_​PRITM table.

   • The specific stop-loss, aggregate stop-loss, discount arrangement, and stop-loss and discount specific level funded transaction legs, whose corresponding bill segments are in a status other than Frozen or Pending Cancel, are moved to the CI_​TXN_​DTL_​PRITM_​STG table. And, the claim or ancillary transaction is moved to the CI_​TXN_​DETAIL_​STG table and its status is changed to Uploaded.

   Irrespective of whether the reseeding request is created due to change in a pricing rule or the late setup scenarios, this batch does not perform any actions on the claim, claim based fee, and ancillary transaction legs and their billable charges. For more information about the parameters, refer to ORMB - Transaction Feed Management - Batch Execution Guide.

3. Transaction Cleanup Batch (C1-TXNCU) - While executing the Clean Up (C1-TXNCU) batch during reseeding, you must set the Request Type parameter to DISAGG. For more information about the parameters, refer to ORMB - Transaction Feed Management - Batch Execution Guide.

4. Update Disaggregation Request Status (C1-DRSUA) - Once the claim or ancillary transaction is successfully disaggregated, the status of the reseeding request is changed to COMPLETE. For more information about the parameters, refer to ORMB - Transaction Feed Management - Batch Execution Guide.

When you re-aggregate the claim or ancillary transactions which were disaggregated due to late setup, the system creates the specific stop-loss, aggregate stop-loss, discount arrangement, and stop-loss and discount specific level funded transaction legs and their billable charges. However, when you re-aggregate the claim or ancillary transactions which were disaggregated due to change in a pricing rule, the system creates the specific stop-loss, aggregate stop-loss, discount arrangement, and stop-loss and discount specific level funded transaction legs and the billable charges for the delta amount (which resulted due to change in pricing).

If the accumulation type is set to Stop Loss, the system deletes the specific stop-loss transaction legs. In addition, it deletes the aggregate stop-loss transaction legs (if any), discount arrangement transaction legs (if any), and level funded transaction legs (if any) whose calculation is based on the specific stop-loss transaction legs.

However, if the accumulation type is set to Discount Arrangement, the system deletes the discount arrangement transaction legs. It deletes the specific stop-loss transaction legs (if any), aggregate stop-loss transaction legs (if any), and level funded transaction legs (if any) when the discount arrangement pricing rule is used in the specific stop-loss pricing rule. However, it deletes the aggregate stop-loss transaction legs (if any) and level funded transaction legs (if any) when the discount arrangement pricing rule is used in the aggregate stop-loss pricing rule.

For example, the CLAIM pricing rule type contains the SSL, ASL, DISCOUNT, and LEVEL FUNDED pricing rule types as the related pricing rule types, and the SSL and ASL pricing rules contain the following discount arrangement pricing rules:

Now, if the reseeding request (where the accumulation type is set to Stop Loss) is created for an account due to change in the SSL pricing rule, the system behaves in the following manner for the C1 claim transaction:

However, if the reseeding request (where the accumulation type is set to Discount Arrangement) is created for an account due to change in the DISCOUNT2 pricing rule, the system behaves in the following manner for the C1 claim transaction:

Let us take another example where the related pricing rule types are not specified in the CLM1 pricing rule type. Therefore, the system just created claim-specific transaction legs and billable charges for the C2 claim transaction. These claim billable charges are then billed to the customer. Now, if you add the SSL and ASL pricing rule types as the related pricing rule types in the CLM1 pricing rule type and create a reseeding request (where the accumulation type is set to Stop Loss) for an account, the system behaves in the following manner for the C2 claim transaction when the transaction incurred and paid dates fall within the incurred and paid date ranges defined in the parent accumulation group: