Transaction Aggregation

Once the claim, enrollment, and ancillary transactions are uploaded, you can create billable charges for the following using the Transaction Aggregation process in the Transaction Feed Management (TFM) module:

• Claim

• Claim Based Fees

• Retroactive Enrollment Fees

• Non-retroactive Enrollment Fees

• Ancillary

The transaction calculation lines for specific stop-loss and aggregate stop-loss are created during the Transaction Aggregation process. Earlier, the Transaction Aggregation process was designed to meet the requirements of the Payments and Financial Services industries. Now, in addition, it is tuned slightly to meet the requirements of the self-funded health insurance business. The changes are made in the following batches which are executed in the Transaction Aggregation process:

• Validate Transaction and Derive Price Item (C1-TXNIP) - During this batch execution, the system validates the transaction. If the transaction validation fails due to any reason, the status of the transaction is changed to Error. If the transaction validation is successful, the system checks whether a primary pricing rule type is specified in the respective transaction record type. If a primary pricing rule type is not specified in the transaction record type, the system maps the transaction to one or more price item, price item parameters, and account combinations using the rules which are invoked through the rule type. However, if a primary pricing rule type is specified in the transaction record type, the system calls the primary pricing rule type and invokes the algorithms which are attached to the following system events of the primary pricing rule type in the specified sequence:

  1. Transaction Validation - At present, the product has not shipped an algorithm type for the Transaction Validation system event. If required, you can create a custom algorithm type which validates the transaction before deriving the transaction legs.

  2. Bill Group Derivation - For more information, refer to the Bill Group Derivation section.

  3. Account and Price Item Derivation - Depending on the category to which the pricing rule type belongs, you need to attach different algorithm to the Account and Price Item Derivation system event. The following table lists the algorithms that you can attach to a primary pricing rule types with different category:

     Pricing Rule Type Category	Algorithm	For more information on how the system derives the transaction legs, refer to...
     Claim	C1_​ACCPRIDRV	Account and Price Item Derivation (for the Claim Pricing Rule Type Category)
     Retention Type Enrollment Based	C1_​ACCPRIDRV	Account and Price Item Derivation (for the Retention Type Enrollment Based Pricing Rule Type Category)
     Ancillary	C1_​ACCPRIDRV	Account and Price Item Derivation (for the Ancillary Pricing Rule Type Category)

  This batch then calls the eligible related pricing rule types (if any) defined in the primary pricing rule type. Note that the related pricing rule types are called one by one in the specified sequence. The system invokes the algorithms which are attached to the following system events of the related pricing rule type in the specified sequence:

  1. Transaction Validation - At present, the product has not shipped an algorithm type for the Transaction Validation system event. If required, you can create a custom algorithm type which validates the transaction before deriving the transaction legs.

  2. Account and Price Item Derivation - Depending on the category to which the pricing rule type belongs, you need to attach different algorithm to the Account and Price Item Derivation system event. The following table lists the algorithms that you can attach to a related pricing rule type with different category:

     Pricing Rule Type Category	Algorithm	For more information on how the system derives the transaction legs, refer to...
     Specific Stop-Loss	C1_​ACCPRISL	Account and Price Item Derivation (for the Specific Stop-Loss and Aggregate Stop-Loss Pricing Rule Type Categories)
     Aggregate Stop-Loss	C1_​ACCPRISL	Account and Price Item Derivation (for the Specific Stop-Loss and Aggregate Stop-Loss Pricing Rule Type Categories)
     Retention Type Claim Based	C1_​ACCPRIDRV	Account and Price Item Derivation (for the Retention Type Claim Based Pricing Rule Type Category)

  The following figure graphically explains the execution process of the Validate Transaction and Derive Price Item (C1-TXNIP) batch:

• Price Item Pricing Verification (C1-TXNVP) - During this batch execution, the system derives an effective pricing for each transaction leg on the processing date. For more information, refer to the Price Item Pricing Verification section. In addition, the system invokes the algorithms attached to the following algorithm spots of the derived account's division in the specified sequence for the self-funded health insurance business:

  1. TFM - Contract Derivation - You can attach an algorithm created using the SA_​DERV_​POPC algorithm type to this algorithm spot. If the account has multiple active contracts of the contract type which is associated with the price item, this algorithm derives the contract which is associated with the policy and maps it to the transaction leg. The manner in which the system derives the active contract for the account differs in the following scenarios:

     If the effective pricing rule stamped against the transaction leg is defined at ...	Then...
     The bill group level	The system first fetches the policy derived for the transaction and then derives the active contract which is associated with the policy.
     The parent customer level	The system first fetches the bill group to which the account belongs and then the policy where the bill group is associated with the policy using the policy person role which is specified in the Bill Group Policy Person Role option type of the C1-ASOBLLNG feature configuration. Once the policy is derived, the system derives the active contract which is associated with the policy.

  2. TFM - Verify Pricing Post-Processing - You can attach an algorithm created using the C1-VRPR_​POPC algorithm type to this algorithm spot. This algorithm removes the price assignment ID and price item parameter group ID from the summary ID column of each transaction leg.

• Service Quantity Calculation (C1-TXNSQ) - During this batch execution, the system aggregates the transaction legs, creates a billable charge, and updates the SQI values in the billable charge. For more information, refer to the Aggregation section. In addition, the system invokes the algorithm attached to the following algorithm spot of the derived account's division for the self-funded health insurance business:

  • TFM - Billable Charge Post Processing - You can attach an algorithm created using the C1_​BCHG_​POPC algorithm type to this algorithm spot. This algorithm invokes the algorithm which is attached to the Bill After Date Determination system event of the respective pricing rule type. For more information, refer to the Bill After Date Determination section.