Financial Preprocessing Overview

A health insurance claim is a reimbursement request that a service provider or an insurable entity raises to the insurance company to avail the benefits and facilities covered under a health insurance plan. When the claim is adjudicated and finalized, the application creates a financial transaction.

Financial preprocessing is the process of converting financial transactions into a financial message for the subsequent accounts payable systems to make or collect payments.

Financial preprocessing consists of the following three steps:

Step I: Select Financial Transactions into a Set

The user runs the select transactions into a set activity. This activity creates a collection of financial transactions. Grouping financial transactions happens according to brand, hospital, provider, date, etc. This step is necessary because it is common practice to create a financial message for a collection of financial transactions.

Step II: Supersede

The user runs the supersede activity. This activity filters out financial transactions that are no longer relevant because a newer version is available. Always run this activity to ensure that only the necessary financial transactions become part of the further processing.

Step III: Generate a Financial Message

The user runs the generate financial message activity. This activity generates a financial message for the financial transactions in the set. For payment, downstream systems use this financial message. This step is necessary because it manages the application’s financial activities and conveys the payment information. Both XML and flat file formats are available to create financial communications.

In summary, financial preprocessing is the process of gradually adding financial transactions to a set daily, bi-weekly, monthly, etc., and then creating a message that only contains the most recent additions that help the downstream accounts payable systems send or receive payments.

Use Case

The following steps explain how financial preprocessing works:

1. Consider the following three claims that are fully processed and finalized, and ensure the use of the same brand in all claims for this use case.

   

   Figure 1. Financial pre-processing use case step 1. Three claims.

2. When a claim finalizes, the application creates a financial transaction for that claim. The financial transaction contains the payment amount equivalent to the covered amount. For claims 1, 2, and 3, the corresponding covered amounts are $80, $490, and $170, respectively.

   

   Figure 2. Financial pre-processing use case step 2. Financial transactions.

3. Set the parameters such that all the financial transactions end up in the same set and run the select transactions into a set activity. This activity bundles the financial transactions into a set. Use brand as the activity parameter, as all claims belong to the same brand. Later in the process, this set is used to create a financial message.

   

   Figure 3. Financial pre-processing use case step 3. Financial transactions in a set.

4. The previous step creates a set of financial transactions. Now, let us say an appeal is received for claim 2 from a provider. The appeal is about a mistake in the claim. As a result, the payment amount needs to change from $490 to $450. The appeal requires you to unfinalize, modify, and reprocess the claim. This results in a new version of the claim with a different covered amount. As a result, the application creates a new financial transaction and a reversal financial transaction with covered amounts of $450 and -$490 for the initial payment.
   The financial transaction set does not automatically include the latest transactions. Run the select transactions into set activity again to add them. As a result, the set now includes the transactions of claim 2’s version 2 and the reversal of version 1.

   

   Figure 4. Financial pre-processing use case step 4. Updated claim, new financial transactions.

5. Run the supersede activity. This activity prevents the application from sending out unnecessary financial transactions. When this activity is completed, claim 2’s version 1 and reversal version 1 are excluded from the financial message because the downstream systems do not need to be aware of their existence. Version 2 represents the initial payment for this claim within the downstream systems.

   

   Figure 5. Financial pre-processing use case step 5. Superseded transactions.

6. Run the generate financial message activity. This activity takes all the financial transactions in the set and creates a financial message. The financial message includes the covered amount of $80 for Claim 1, $450 for Claim 2, and $170 for Claim 3. The application automatically closes the financial transaction set after the creation of the financial message and the completion of all financial transactions. Any additional claims processing requires a new set.

   

   Figure 6. Financial pre-processing use case step 6. Financial message, set closed.

7. Steps 1 through 6 explain the smooth flow of the financial preprocessing, where the application successfully generates a financial message for downstream systems. Consider a situation when you need to modify a claim after sending the message. For example, the provider appeals the results of claim 1 a week after the financial message generation and downstream systems payment. After inspection, you decide to uphold the appeal. You unfinalize, update, and reprocess that claim. When the claim finalizes again, the covered amount is now set to $90. The application generates a new financial transaction for $90 and reverses $80 of the previous transaction. Repeat step 3 and create a new set for claim 1 because the application does not allow you to add financial transactions to a closed set.

   

   Figure 7. Financial pre-processing use case step 7. Updated claim, new financial transactions, new transaction set.

8. Repeat steps 5 and 6. The supersede activity does not filter the reversal transaction because the application has already delivered the financial message for version 1 to the downstream systems. The creation of the financial message includes both the reversal transaction and the new transaction. The application then generates a message containing the new payment of $90 and the reversal payment of $80, which results in a delta payment of $10. The application automatically closes the Financial Transaction Set after the creation of the financial message and the completion of all financial transactions.

   

   Figure 8. Financial pre-processing use case step 8. New financial message, new set closed.