Financial Preprocessing – Supersede
A health insurance claim is a reimbursement request for services administered to a patient by a healthcare provider. The healthcare provider creates this request and sends it to the payer for that patient’s insurance. The payer has the member registered in one of its plans. Large healthcare payers typically process tens of thousands of claims per day. Oracle Health Insurance Claims processes these claims, determining the price and the member’s benefits. The fully adjudicated claim can be denied or approved at the end of that process. When approved, the claim typically leads to a payment. To represent this, Oracle Health Insurance Claims creates a financial transaction whenever a payment is due.
Sometimes, after the claim is paid, the same claim is re-adjudicated. There are several possible causes for this. One common reason is that the payment receiver disagrees with how the claim adjudication happened. As a result, you need to change the payment amount. This requires you to unfinalize, modify, and reprocess the claims. The application creates a new financial transaction and a reversal financial transaction for the previous payments of the claims. Financial preprocessing is the process of converting all these financial transactions into a financial message for the subsequent accounts payable systems to make or collect payments. In general, the generation of a financial message happens daily.
Financial preprocessing consists of the following three steps:
Step I: Select Financial Transactions into a Set
Step II: Supersede
Step III: Generate a Financial Message
In the first step, you run the process that selects financial transactions into a set. The financial transaction set represents the unit of work for financial preprocessing.
In the second step, you run 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.
In the third step, you run the Generate Financial Message activity. This activity consolidates all of the financial transactions in the collection and maps them to financial messages.
Now, let’s take a closer look at step II, Supersede.
Superseding is applicable for a financial transaction. A financial transaction supersede happens when a more recent version of the same transaction is available. Only financial transactions that have never been included in a financial message are eligible for superseding.
Example 1: Consider a claim. It has been fully processed and finalized. As a result, the application generates a Financial Transaction version 1. However, as of right now, version 1 is not included in the financial message. After that, the claim is changed, and the application creates version 2 of the claim. Supersede applies only to financial transactions that have not yet been sent out. The most recent version is version 2, and the version 1 is not yet sent. Therefore, version 2 supersedes version 1 because version 1 is never included in a financial message.
Financial message generation, at this point, results in the following behavior:
| Version | Superseded | Included in the Financial Message |
|---|---|---|
Version 1 |
Yes |
No |
Version 1 Reversal |
Yes |
No |
Version 2 |
No |
Yes |
Example 2: Now consider a slightly more complex example. Consider a claim. It has been fully processed and finalized. As a result, the application creates a Financial Transaction version 1. You generate a financial message. Then, after a week, you create version 2 on an appeal. However, the operator realizes the moment that they submitted version 2, they made a mistake, so they immediately unfinalize before any financial message generation, create version 3, and submit that. At the end of the day, the supersede runs, and version 2 is superseded by version 3. However, as version 1 was previously included in the prior financial message, the version 1 reversal supersede does not occur.
For some claims, providers require that any modifications to a claim be included in the financial message. Even if there are supersedes, include them in the financial message. To support this requirement, we have a Financial Message Mandatory parameter. The parameter is set during the claim submission process.
Financial message generation, at this point, results in the following behavior when the Financial Message Mandatory parameter is set to No.
| Version | Superseded | Included in the Financial Message |
|---|---|---|
Version 1 Reversal |
No |
Yes |
Version 2 |
Yes |
No |
Version 2 Reversal |
Yes |
No |
Version 3 |
No |
Yes |
Financial message generation, at this point, results in the following behavior when the Financial Message Mandatory parameter is set to Yes.
| Version | Superseded | Included in the Financial Message |
|---|---|---|
Version 1 Reversal |
No |
Yes |
Version 2 |
No |
Yes |
Version 2 Reversal |
No |
Yes |
Version 3 |
No |
Yes |
Use Case
For the claims application, the common use case is to generate a financial message for all of the finalized claims on that day. The following is a stepwise explanation of how this works.
-
Consider the following three claims. They have been fully processed and finalized.
Figure 1. Financial Preprocessing - Supersede - Three Claims -
When a claim finalizes, the application creates a financial transaction for that claim. The financial transaction contains the payment amount that is equivalent to the covered amount in the claim. For claims 1, 2, and 3, the corresponding covered amounts are 80 dollars, 450 dollars, and 170 dollars.
Figure 2. Financial Preprocessing - Supersede - Financial Transactions -
In this step, you run the Select Transactions into Set activity. This activity bundles the financial transactions into a set. Later in the process, you use this set to create a financial message.
Figure 3. Financial Preprocessing - Supersede - Financial Transactions in a set -
The previous step creates a set of financial transactions. Now, let us say you received an appeal for claim 2 from the provider, Dr. Allen. The appeal is about a disagreement in the claim. A provider appeals over a claim that was denied but believes it should have been accepted under the benefits of the plan. The claims operator unfinalizes the claim and changes the claim accordingly. After the claim is finalized, it is adjudicated to be the covered amount of 450 dollars instead of 490 dollars. As a result, the application creates a new financial transaction and a reversal financial transaction with covered amounts of 450 dollars and -490 dollars for the initial payment. The financial transaction set does not automatically include the latest transactions. Run the select transactions into the set activity again to add them. The financial transactions of version 2 and the reversal of version 1 of claim 2 are now included in the set.
Figure 4. Financial Preprocessing - Supersede - Updated Claim - New Financial Transactions -
In this step, you run the Supersede activity. This activity prevents the application from sending out unnecessary financial transactions. This activity consolidates all financial transactions for the same claim and sends out only the latest transactions. In our example for claim 2, this means that version 1, as well as the reversal of version 1, are ignored in the next steps. The application only needs to send version 2 of the financial transaction because it represents the first payment for this claim.
Figure 5. Financial Preprocessing - Supersede - Superseded Transactions -
In this step, you run the Generate Financial Message activity. This activity takes all the financial transactions in the set and generates a financial message.
Figure 6. Financial Preprocessing - Supersede - Financial Message - Set Closed