Generate Financial Message

A healthcare insurance claim is a reimbursement request for services the healthcare provider administers to a patient. The healthcare provider creates the claim and submits it to the payer at which the member is enrolled. Large healthcare payers typically process hundreds of thousands of claims per day. Oracle Health Insurance Claims processes these claims, determining the price and the member’s benefits. The claim leads to either a denial, a partially approved, or a fully approved claim. The approved claims lead to payment to the provider.

In some cases, a claim is processed more than once; that is, the claim is re-adjudicated. This can occur when the provider disagrees with how the claim is adjudicated. To remediate this situation, the payer may need to make changes to the claim, which may lead to a different result. After making those changes and adjudicating the claim, the application creates a financial transaction with the new results and also a reversal financial transaction to undo the previous results.

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. It 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 most recent financial transactions are part of the 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. The downstream accounts payable systems receive these financial messages to process or receive payments.

This page elaborates on the third step, the activity of Generating Financial Messages, in more detail.

Scenarios

Scenario 1: Generate the Financial Message in an XML File Format

The activity with XML file format has the following parameters. These parameters allow you to scope the processing of the financial transactions into a message.

Table 1. Generate the Financial Message in an XML File Format

Name	Description
Cut-Off Date	This applies only to financial transactions for which general financial processing is completed. The Generate Financial Message activity picks up the general financial processing completed DateTime on the base financial object that is before the cut-off date and time.
Cut-Off Time	The cut-off time is always combined with the cut-off date. Cut-off time must be entered in HHMM format.
Create Invoice Dynamic Logic Function	This dynamic logic function must have the Create Invoice XML signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Create Invoice Line Dynamic Logic Function	This dynamic logic function must have the Create Invoice Line XML signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Create Accounting Detail Dynamic Logic Function	This dynamic logic function must have the Create Accounting Detail XML signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Create Accounting Detail to Persist Dynamic Logic Function	This dynamic logic function must be of signature Create Accounting Detail or Create Accounting Detail with Dual.
Include Subject for Grouping Accounting?	Indicates whether the subject (Claim Code) should be added to the accounting bulking group or not.
Accounting Grouping on Reversal Indicator?	Indicates if a reversal indicator should be considered when grouping financial transaction details into accounting details or not.
Max Total Invoice Amount and Max Total Invoice Amount Curr	The maximum total invoice amount can prevent the total of all invoice amounts for the set from exceeding the value specified. If a currency is specified as well, then that currency is used. If not, then the default currency is used. Transactions already handled in the set also count towards the maximum. The total amount of the financial transaction field is used as input for this calculation. Because financial transaction details cannot span more than one currency, the total amount field and the total amount currency field are always present. All total amounts in the Currency of Max Total Invoice Amount Curr are added until the Max Total Invoice Amount is exceeded. If the sum of the selected financial transactions for the same base financial object is negative, it is not included in this count.
Include Unfinalized	Evaluates to false if the financial transaction (and thus the base financial object) references a claim that is currently Unfinalized. This prevents sending out a claim that is currently Unfinalized.
Automatic Remove	If set to Y or left unspecified, the Generate Financial Message activity does not handle all financial transactions in the financial transaction set (typically, financial transactions on hold are removed from the set, and the set is closed).
Financial Message Delivery Option	This parameter specifies the options that Claims supports to deliver the generated financial message to an external system. Message-Based: As they are generated, financial messages can be sent out individually to a pre-configured endpoint. File-Based: Financial messages are written to a data file, and the data file can be made available for download.

Scenario 2: Generate the Financial Message in a FLAT FILE Format

The activity with flat-file format has the following parameters. These parameters allow you to scope the processing of the financial transactions into a message.

Table 2. Generate the Financial Message in an XML File Format

Name	Description
Cut-Off Date	This applies only to financial transactions for which general financial processing is completed. The Generate Financial Message activity picks up the general financial processing completed DateTime on the base financial object that is before the cut-off date and time.
Cut-Off Time	The cut-off time is always combined with the cut-off date. Cut-off time must be entered in HHMM format.
Create Invoice Dynamic Logic Function	This dynamic logic function must have the Create Invoice Flat File signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Create Invoice Line Dynamic Logic Function	This dynamic logic function must have the Create Invoice Line Flat File signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Create Accounting Detail Dynamic Logic Function	This dynamic logic function must have the signature Create Accounting Detail Flat File signature. If it has another signature, the error message FIN-VL-CRFM-004 is attached to the activity.
Max Total Invoice Amount and Max Total Invoice Amount Curr	The maximum total invoice amount prevents the total invoice amounts from exceeding the specified value. If a currency is specified as well, then that currency is used. If not, then the default Currency is used. The total amount of the financial transaction field is used as input for this calculation. Because financial transaction details cannot span more than one currency, the total amount field and the total amount currency field are always present. All total amounts in the Currency of Max Total Invoice Amount Curr are added until the Max Total Invoice Amount is exceeded. If the sum of the selected financial transactions for the same base financial object is negative, it is not included in this count.
Include Unfinalized	Evaluates to false if the financial transaction (and thus the base financial object) references a claim that is currently Unfinalized. This prevents sending out a claim that is currently Unfinalized.

Processing

The process of creating financial messages has the following steps:

• Selecting the Financial Transactions

• Grouping the Financial Transactions

• Financial Message Structure

• Delivery of the Financial Messages

• Error Messages

• Use Case

Selecting The Financial Transactions

The financial message generation process takes a financial transaction set as input. This is the set to which all eligible transactions are added. In the financial processing activity, the application selects financial transactions, including reversal transactions that are:

• Included in the financial transaction set

• Not yet included in a financial message

• Not superseded

• Not on hold (See financial holds for more information)

As an option, you can set the maximum amount parameter. If you set, the application behaves as follows:

• The financial transactions in the set are sorted based on their payment due dates (earliest date first) followed by invoice amount (largest amount first).

• The application processes the financial transactions in sorted order, accumulating the total invoice amount. If the amount of a financial transaction pushes the total over the maximum, then that financial transaction is removed from the set, and it will be picked up in the next payment run. When this happens, the application raises the message FIN-FL-CRFM-001 and then continues to consider the following financial transaction.

• Financial transactions that use a currency other than the maximum amount of currency do not count towards the maximum but are always included in the set.

• The application continues to iterate over all financial transactions in this way until all have been considered.

Grouping The Financial Transactions

The system groups financial transactions and their details at different levels and provides the following alternatives to maximize adaptability across different financial systems and configurations:

The Generate financial message activity produces one or more financial messages. Each of these financial messages has one or more invoices.

Grouping of Financial Transactions into Financial Messages

The attribute Financial Message Bulking Group groups the financial transactions into messages. Each separate value generates one financial message. For example, if this attribute is set to the claim code (in the financial transaction scenario), then each claim gets its financial message. This attribute is available at the claim level.

Grouping of Financial Transaction Details into Invoices

The following attributes group the financial transactions into invoices. These attributes are available at the claim line level. Each separate combination of the below attributes leads to a separate invoice. For example, a claim with claim lines that have different attribute values end up in different invoices:

• Counterparty Code and Counterparty Qualifier (Payment Receiver Code and Payment Receiver Flex Code Def Code)

• Invoice Destination

• Pay From Bank Account

• Invoice Bulking Group

• Amount Currency

Grouping of Financial Transaction Details into Invoice Lines

Each financial transaction with an Invoice line grouping indicator set to No generates a separate invoice line. If this indicator is set to Yes, multiple financial transaction details within an invoice are consolidated into one invoice line based on the value in the invoice line bulking group. This attribute is available at the claim line level.

• Invoice Line Bulking Group (from Financial Transaction Detail Process Data)

• Reversal Indicator (from Financial Transaction)

The system’s default behavior is to create separate invoice lines for reversal and non-reversal transactions. To group the reversal and non-reversal transactions into one invoice line, set the parameter Disable Reversal Grouping (Invoice Line) to Y. The invoice line amount then holds the sum of the reversal and non-reversal amounts.

If this parameter is not set or set to N, the system applies the default behavior. Setting this parameter to Y also stamps the value Yes on the financial transaction process data.

Grouping of Invoiced Financial Transaction Details into Accounting Details

The attribute accountingDetailBulkingGroup enables the system to create one or more accounting details for selected financial transaction details with the invoice indicator set to Yes. It is available at the claim line level.

If the accounting detail grouping indicator on the financial transaction detail is set to No, the system creates a single accounting detail for each financial transaction detail. When set to Yes, the system consolidates multiple financial transaction details in the same invoice into a single accounting detail. In cases where multiple details lack a specified accounting detail-bulking group, the system consolidates them into a single accounting detail.

When the system groups financial transaction details into accounting details, and no accounting grouping criteria are configured, then the system applies the following default criteria for grouping:

• General Ledger Account (from Financial Transaction Detail Process Data).

• Accounting Bulking Group (from Financial Transaction Detail Process Data).

• Reversal Indicator (from Financial Transaction; included when Accounting Grouping on Reversal Indicator is set to true).

• Policy Gid (included when Include Subject for Grouping Accounting is set to true).

For each group, an accounting detail is created within 'its' invoice using the Create Accounting Detail (XML/Flat File/persists; see dynamic logic functions for more information) dynamic logic routine that has been configured. The system persists in accounting details if the parameter Create Accounting Detail to Persist is used to specify the dynamic logic. A unique Oracle Health Insurance Accounting Detail ID is generated for each accounting detail. This ID is included in the financial message, stamped on persisted accounting detail, and used for stamping on the Financial Transaction Detail Process Data.

Grouping of Non-invoiced Financial Transaction Details into Accounting Details

The attribute accountingDetailBulkingGroup enables the system to create one or more accounting details for selected financial transaction details with the invoice indicator set to Yes. This attribute is available at the claim line level.

If the accounting detail grouping indicator on the financial transaction details is No, then the system creates one accounting detail for each financial transaction detail. Suppose the accounting detail grouping indicator on the financial transaction data is Yes. In that case, the system combines multiple financial transaction details into a single accounting detail depending on the grouping criteria (Claim Code is included in a grouping when Include Subject for Grouping Accounting? is set to true).

For each group, an accounting detail is created if the system property ohi.financialmessage.create.noninvoiceaccdetail has the value true. Within 'its' invoice using the Create Accounting Detail (XML/Flat File/persists; see dynamic logic functions for more information) dynamic logic routine that has been configured. The system persists in accounting details if the parameter Create Accounting Detail to Persist is used to specify the dynamic logic. A unique Oracle Health Insurance Accounting Detail ID is generated for each accounting detail. This ID is included in the financial message, stamped on persisted accounting detail, and used for stamping on the Financial Transaction Detail Process Data.

If false, the system does not create accounting details for non-invoiced financial transactions.

Financial Message Structure

The application supports Generate Financial Messages in XML and flat file structures.

Financial Message Structure – XML

This structure facilitates the consolidation of numerous financial transactions into a single financial message. In this structure, invoices, invoice lines, and accounting details serve as aggregates for multiple transaction lines across various transactions within a single message. This method reduces the abundance of financial messages that the system transmits to the financial system, along with related invoices, invoice lines, and accounting information.

The following image summarizes the process:

Figure 1. XML Message Creation

The above image is related to a financial message processing system. Here is a breakdown of the process described:

1. Create Financial Message 'Tag': The initial step involves creating a financial message tag.

2. Non-Invoiced Transactions: For each non-invoiced transaction detail in the Accounting Grouping, execute the Create Accounting Details dynamic logic function and create a Non-Invoiced Accounting Detail element.

3. Invoiced Transactions: For each transaction detail in the Invoice Grouping, execute the Create Invoice dynamic logic function and create an Invoice Element.

4. Invoice Lines: For each transaction detail in the Invoice Line Grouping, execute the Create Invoice Line dynamic logic function and create an Invoice Line Element.

5. Accounting Details: For each transaction detail in the Accounting Grouping, execute the Create Accounting Detail dynamic logic function and create an Accounting Detail element.

6. Stamping of Results: After the above processes, the results are stamped.

7. Financial Message Generation:

   • The final financial message is created.

   • Depending on the system design, this can either be:

     • Message-Based: The financial message is sent out directly.

     • File-Based: A file is created containing financial messages for the run.

The steps marked with an asterisk (*) indicate dynamic logic functions, suggesting that these steps involve dynamic or conditional processing based on specific logic or rules.

The XML schema definition (XSD) includes two sections dedicated to accounting details. One section includes accounting details about non-invoiced financial transaction information, and the other section includes accounting details associated with an invoice.

The financial message has the following top-level structure:

<financialMessage jobId="123">
    <accountingDetails>
    <accountingDetail>
       <accountingDetailBulkingCriteria>
         ...
       </accountingDetailBulkingCriteria>
    </accountingDetail>
     …
  </accountingDetails>
        ...
  </InvoiceDetails>
        </InvoiceLineDetails>
        …
        <accountingDetails>
          <accountingDetail>
           <accountingDetailBulkingCriteria>
            ...
            </accountingDetailBulkingCriteria>
             ...
          </accountingDetail>
        </accountingDetails>
   ...

</financialMessage>

Financial Message Element

The financial message element specifies attributes that apply to the entire message. The Generate Financial Message activity sets the values of these attributes. These attributes are:

Table 3. Financial Message Element

Element	Source of Value	Note
Id	Simple Sequence	Unique ID of message generated by Oracle Health Insurance.
jobId	Activity ID that created this financial message	Unique ID of the Financial Message Creation activity.
messageDate	System Date and time	Date/Time the message was created.
messageBulkingCriteria	Financial Transaction Process Data.Fin Message Bulking Group

Invoice Element

The attributes of this element capture identifying information at the invoice header level. The source of value column shows the intended values to use and their expected source.

Table 4. Invoice Element

Element	Updatable in Dynamic Logic?	Source of Value	Note
invoiceBulkingCriteria
invoiceBulkingGroup	No	Financial Transaction Detail Process Data.Invoice Bulking Group	Shows additional invoice bulking. The attribute may not contain any value. This value cannot be updated in the dynamic logic function.
invoiceDestination	No	Financial Transaction Process Data.Invoice Destination	Payable or Receivable.
counterpartyCode	No	Financial Transaction Detail Process Data.Counterparty Code	Counterparty code is a fixed grouping criterion for invoices. This value cannot be updated in the dynamic logic function.
counterpartyQualifier	No	Financial Transaction Detail Process Data.Counterparty Qualifier	Counterparty qualifier is a fixed grouping criterion for invoices. This value cannot be updated in the dynamic logic function.
payFromBankAccount	No	Financial Transaction Detail Process Data.Pay From Bank Account	Pay from a bank account is a fixed grouping criterion for invoices. This value cannot be updated in the dynamic logic function.
invoice attributes:
ohiInvoiceId	No	Sequence	Unique identifier for Oracle Health Insurance invoices generated by Oracle Health Insurance.
documentId		Defaulted with Oracle Health Insurance invoice ID but can be changed in the dynamic logic function.	Used as an invoice number in the financial system. The invoice number is defined in the dynamic logic function and is not validated in Oracle Health Insurance.
organization			Organizational unit in which the invoice is accounted. Defined in dynamic logic.
invoiceType		Message generation logic.	STANDARD if amount > 0 or 0 or CREDIT if amount < 0.
invoiceDate		Financial Transaction Process Data.Fin Message Handled Date Time
paymentBeneficiaryFlexCode		Financial Transaction Detail Process Data.Payment Ben Flex Code Def Code	If the Payment Beneficiary Flex Code Value is empty, the Counterparty qualifier value is used for this attribute.
paymentBeneficiaryCode		Financial Transaction Detail Process Data.Payment Beneficiary Code	If the Payment Beneficiary Code is empty, the Counterparty Code is used for this attribute.
	Financial Transaction Detail. Amount Curr
invoiceAmount	No		Sum of all Financial Transaction Detail amounts included in the invoice. Negative for invoice type CREDIT.
paymentTerms			Fixed IMMEDIATE if invoicing is being done just in time to meet due date. Otherwise, provided in dynamic field (determined upstream based on payment agreements with providers and general rules).
description		Claims	The default value that can be overridden in dynamic logic.
source		Claims	The default value that can be overridden in dynamic logic.
invoiceCategory			Defined in dynamic logic.
attribute1 .. attribute90			Free format elements for additional configuration defined attributes Defined in dynamic logic.

Invoice Line Element

This element has attributes that store identifying information down to the invoice line level. The source of value column shows the intended values to use and their expected source.

Table 5. Invoice Line Element

Element	Updatable in Dynamic Logic?	Source of Value	Note
invoiceLineBulkingCriteria
invoiceLineBulkingGroup	No	Financial Transaction Detail Process Data.Invoice Line Bulking Group	Shows additional invoice line bulking. The attribute may not contain any value. This value cannot be updated in the dynamic logic function.
reversal	No	Financial Transaction.Ind Reversal	The reversal indicator is a fixed grouping criterion for invoices. This value cannot be updated in the dynamic logic function.
invoiceLine attributes:
ohiLineId	No	Sequence	A unique identifier for Oracle Health Insurance invoice lines generated by Oracle Health Insurance.
lineNumber			A unique number within invoice. Used to ensure line number is unique for an invoice.
lineType		ITEM	Defined in dynamic logic.
amount	No	Financial Transaction Detail. Amount	Sum of all Financial Transaction Detail amounts included in the invoice line.
description		Claims	The default value that can be overridden in dynamic logic.
distributionAccount		Financial Transaction Detail Process Data. General Ledger Account	The default value that can be overridden in dynamic logic.
attribute1 .. attribute90			Free format elements for additional configuration defined attributes. Defined in dynamic logic.

Accounting Detail Element

This element contains the attributes needed by the general ledger.

Table 6. Accounting Detail Element

Element	Updatable in Dynamic Logic?	Source of Value	Note
accountingDetailBulkingCriteria
accountingDetailBulkingGroup	No	Financial Transaction Detail Process Data.Accounting Bulking Group	Shows additional accounting bulking. The attribute may not contain any value. This value cannot be updated in the dynamic logic function.
reversal	No	Financial Transaction.Ind Reversal	Reversal indicator is a fixed grouping criterion for invoices. This value cannot be updated in the dynamic logic function.
subject	No	Claim Code	Set when grouping on subject is set to true.
distributionAccount		Financial Transaction Detail Process Data. General Ledger Account
accountingDetail attributes:
ohiAccountingDetailId	No	Sequence	Unique identifier for Oracle Health Insurance accounting details generated by Oracle Health Insurance.
ledgerId			Identification of the ledger to which the accounting details are interfaced.
accountingDate		Financial Transaction Process Data.Fin Message Handled Date Time
transactionDate		Financial Transaction Process Data.Fin Message Handled Date Time
category			Defined in dynamic logic.
source			Defined in dynamic logic.
currencyCode		Financial Transaction Detail. Amount Curr
amountDebit	No	Financial Transaction Detail. Amount	Sum of all Financial Transaction Detail amounts included in the accounting detail. This element is populated if the amount is a debit amount.
amountCredit	No	Financial Transaction Detail. Amount	Sum of all Financial Transaction Detail amounts included in the accounting detail. This element is populated if the amount is a credit amount
description		Claims	Default value that can be overridden in dynamic logic
accountingPeriod			Defined in dynamic logic.
glSegment1.. glSegment30		Financial Transaction Detail Process Data. General Ledger Account	Mapping to the various GL accounting segments. Up to 30 segments are available to match the required chart of accounts structures.
attribute1 .. attribute30			Free format elements for additional configuration defined attributes. Defined in dynamic logic.

Financial Message Structure - Flat File

The system enables the creation of Flat Files, for example, to import into Fusion Financial.

The following image shows the process of the creation of a Flat File:

Figure 2. Flat File Message Creation

The dynamic logic functions drive the contents of the file. Each dynamic logic function takes a combination of relevant contexts, including financial message, invoice, invoice line, accounting line detail, and financial transaction detail, as input. The later section describes these contexts in more detail.

The dynamic logic function returns one or more rows, along with the file details (file identifier and row content) to which it needs to be written. See dynamic logic function signature for more details.

The system creates one data file for each distinct file identifier found in any of the rows created by the dynamic logic functions during the activity processing.

For the detailed attributes, See the previous section - Financial Message Structure – XML.

Accounting Detail Line

Fields	Description
Accounting ID	Accounting ID as stamped on financial transaction details.
Financial Message ID	Financial message ID.
Description	Defined in dynamic logic.
Subject	Claim Code.
Brand Code	The code of the brand.
Bulking Group	Accounting bulking group from FinancialTransactionDetailProcessData.
Bulking group GL File	Defined in dynamic logic. This is used to bulk the accounting details into consolidated entries when generating the accounting message.
Reversal?	Indicates whether the accounting entry is for a reversal financial transaction or not.
Invoiced?	Invoiced or non-invoiced accounting details.
Distribution Account	Defined in dynamic logic.
Ledger Id	Defined in dynamic logic.
Accounting Date	Defined in dynamic logic.
Transaction Date	Financial Transaction Process Data.Fin Message Handled Date Time.
Category	Defined in dynamic logic.
Source	Defined in dynamic logic.
Currency Code	Currency code of debit/credit amount.
Amount Debit	The sum of all Financial Transaction Details amounts is included in the accounting details. This element is only populated if the amount is debited (the sum of amounts is less than zero). For registrations-based accounting, this is defined in the dynamic logic.
Amount Credit	The sum of all Financial Transaction Details amounts is included in the accounting details. This element is only populated if the amount is a credit amount (the sum of amounts is greater than zero). For registrations-based accounting, this is defined in the dynamic logic.
accountingPeriod	Defined in dynamic logic.
glSegment1.. glSegment30	Mapping to the various GL accounting segments. Up to 30 segments are available to match the required chart of accounts structure.
attribute1 .. attribute30	Free format elements for additional configuration-defined attributes. Defined in dynamic logic.
GL Extraction Batch ID	ID of the batch in which the details were sent out.
GL Extraction Date Time	Date time the GL entries were extracted.

Delivery of the Financial Messages

Generate Financial Message XML

Once the Generate Financial Message XML activity has created financial messages, the next step is to deliver them to the financial system. Following are the two delivery options; one is used depending on the value of the Financial Message Delivery Option parameter:

Message Based

The system delivers these messages one by one to the financial message endpoint. This integration point is described in the "Financial Message Integration Point" in the Developer Guide. The system logs an activity message if it cannot deliver a message.

File Based

The system writes all the messages to one or more XML files and puts them in a data file set. Once it sends a notification message to an external system, the system logs an activity message, ACT-FL-DAFI-001.

See “Financial Message Integration Point" page in the Developer Guide for more information.

Generate Financial Message Flat File

The Generate Financial Message Flat File-based activity type delivers financial messages through the file-based delivery integration point. For Flat Files, the system creates a data file set and generates the data file. It logs FIN-FL-CRFM-002 for each created data file set.

Error Messages

All of the activities mentioned above apply validation checks before running. The following errors can occur. They appear in the response messages for this activity.

Table 7. Error Message

Code	Sev	Message
FIN-FL-CRFM-001	Informative	Financial transactions for claim {code} are not processed because it would exceed the maximum amount.
FIN-VL-CRFM-001	Fatal	The status of the financial transaction set must be Open
FIN-VL-CRFM-002	Fatal	Message creation for {message bulking group} failed
FIN-VL-CRFM-004	Fatal	Invalid signature for dynamic logic function {dyn logic code}
FIN-VL-CRFM-005	Fatal	The financial transaction set cannot be processed because of an active financial hold
FIN-VL-CRFM-006	Fatal	Either the "Create Accounting Detail Dynamic Logic Function" or the "Create Accounting Detail to Persist Dynamic Logic Function" must be specified.
ACT-FL-DAFI-001	Informative	Messages are written to the Data File Set {comma separated list of data file set ids}

Use Case

The claims application’s 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.

Step I: Consider the following three claims. They have been fully processed and finalized.

Figure 3. Claims - Fully Processed and Finalized

Step II: When a claim is finalized, the application creates a financial transaction for that claim. The financial transaction contains the payment amount equivalent to the covered amount in the claim. For claims 1, 2, and 3, the corresponding covered amounts are 80 dollars, 490 dollars, and 170 dollars.

Figure 4. Financial Transactions for Created for the Claims

Step III: Run the Select Transactions into Set activity. This activity bundles the financial transactions into a set. Later in the process, this set is used to create a financial message.

Figure 5. Run the Financial Transactions into Set Activity

Step IV: The previous step creates a set of financial transactions. Now, let us say you received an appeal for claim 2 from 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 covered amount of 490 dollars instead of 450 dollars. As a result, the application creates a new financial transaction and a reversal financial transaction with covered amounts of 490 dollars and -450 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 6. Claims - with New Financial Transactions.

Step V: In this step, you run the supersede activity. This activity prevents the application from sending 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 and the reversal of version 1 are ignored in the following steps. The application only needs to send version 2 of the financial transaction because it represents the first payment for this claim.

Figure 7. Claims - Superseded Transactions

Step VI: Run the Generate Financial Message activity. This activity takes all the financial transactions in the set and generates a financial message.

Figure 8. Run Generate Financial Message Activity - Set Closed