Overview

This section provides an overview of the context of the claim transaction repository and its main functionality.

The claims transaction repository holds the final results of processing claims. When the processing of a claim is complete (that is, the claim is finalized in Claims), a claim transaction is prepared for it. The claim transactions are in effect snapshots of claims and their referenced data at the time of finalization.

The main purposes of claim transactions are to:

keep a 'final' copy of the results of processing a claim each time a claim is processed (that is, a history of final claim versions), and
provide the results of claim processing in a format suitable for input to downstream processes that follow the finalization of a claim in Claims (for example, paying claims, storing it in the data warehouse, and including it in an explanation of benefits).

In addition, the repository holds 'reversals' of transactions for which there will be (or is already) a higher version transaction.

The following diagram illustrates the context of the claim transaction repository within Claims:

The claims flow steps create and update the claim entities (working copy) and when a claim is finalized a 'standalone' claim transaction is created with the details of claims and referenced entities that are required by downstream systems. The claim transaction data model is very similar to the model used during the processing of claims (working copy). The main differences between the models are:

besides the transaction model, additional financial detail can be stored in the Financial Transaction Model. This is not part of the Claims Transaction Repository itself, but also created when executing the transaction creation scenario,
the internal keys and references of the claims model are replaced with external meaningful values in the repository model,
some details of referenced entities are included in the repository model.

While a claim remains finalized, the working copy of the claim and the claim transaction representation of it contain essentially the same details. However, if updates are made to the entities that a claim refers to (for example, if an attribute of a relation was updated), the new values would show if viewing the claim but not if viewing the claim transaction.

If a claim transaction is 'unfinalized', the working copy of the claim will change while the claim transaction repository will preserve values as they were when it was finalized. The claim transaction for the unfinalized claim will be labeled as 'unfinalized' (but not otherwise changed) and a reversal transaction will be created for it. When the claim is refinalized, a new claim transaction will be made for the claim and the working copy and the new claim transaction will be the same. The earlier claim transaction will not be changed.

The functionality of the transaction repository is limited to storing claim transactions, sending out events to indicate that new transaction has arrived or that a claim has been unfinalized, and an integration point for providing claim transactions to downstream systems. Transaction repository contents are also accessible through reporting views. The events that may be sent out are configurable. Downstream applications may use the events to trigger their processing related to a claim or use the integration point to periodically query the repository. Downstream applications could use notifications of unfinalizing a claim to immediately reverse the effects of the transaction or choose to wait for the next version of the claim and handle the differences between the transactions.

The exact contents of claim transactions are configurable using dynamic fields and dynamic logic. Dynamic fields may be added to the repository model and dynamic logic functions are used to populate the fixed and dynamic fields of the claim transactions (from Claims claims and referenced entities).

Functional Overview and Context

This section provides a high-level description of the functionality of the repository and its context.

The following diagram illustrates the context and main internal logic of the repository:

Claims Finalize Step

The finalize step is the final step of the claims flow in Claims. In the finalize step, the final processing actions are completed (as described in the Claims Flow Implementation Guide) and a claim transaction is created (using the transaction generator).

The 're-finalization' of a claim also results in a transaction being created and stored in the repository. The only difference is that the transaction resulting from re-finalization is identified as being a new version of the claim (and it contains new values of the claim and referenced entities).

Transaction Generator

This transaction generator creates and stores claim transactions within the finalize step.

The transactions are created in the same unit of work as other finalize actions to ensure that transactions capture values at the time of finalization (and to ensure that transactions are always and only prepared if the claim is actually finalized).

The generator builds a claim transaction 'representation' of a claim from the Claims working copy 'representation' of it using dynamic logic functions. The functions are created as part of system configuration. They transfer the values from claims in Claims and referenced data entities that are needed by any downstream application to the claim transaction. The functions transfer values to both the fixed and dynamic fields of the repository from the fixed and dynamic fields of claims in Claims. This allows flexibility in filling of all fields (fixed and dynamic). The dynamic logic for creating claim transactions is defined within the context of transaction creation scenarios. Different scenarios can be created for different types of claims.

In addition, a financial transactions model is created which serve as a basis for creating payable invoices and accounting entries. They are also created using dynamic logic that is prepared during system configuration.

The transaction generator creates the transactions using the following logic:

A transaction creation scenario for the claim being processed is selected
The Create Claim Transaction Header dynamic logic function is executed
The claim transaction object is instantiated by the dynamic logic function
For each bill of the claim
- the Create Claim Transaction Bill dynamic logic function is executed
- the bill transaction object is attached to the claim transaction object
For each claim line of the claim:
- the Create Claim Transaction Claim Line dynamic logic function is executed
- The claim line transaction object is attached to the claim transaction object
For each claim transaction, create a financial transaction and financial transaction process data
- the Financial Transaction dynamic logic function is executed
- the financial transaction and financial transaction process data is attached to the claim transaction object
For each claim line transaction coverage (part of the claim line transaction object), create a financial transaction detail and financial transaction detail process data
- the Financial Transaction Detail dynamic logic function is executed
- the financial transaction detail and financial transaction detail process data is attached to the claim transaction object
For each claim transaction, modify the claim transaction object which might entail adding a financial transaction detail
- the Financial Transaction Change dynamic logic function is executed
- the financial transaction object is attached to the claim transaction object
The claim transaction object is written to the database

Strictly speaking, the financial transactions and its details are not part of the Claim Transaction Repository. They are, however, created at the same time when executing the transaction creation scenario.

This logic illustrates the role of the dynamic logic in creation of claim transactions. The main structure is fixed while the dynamic logic functions determine exactly what the main elements of the message (Claim Header, Bill, Claim Line, Financial Transaction, Financial Transaction Detail, Financial Transaction Change) contain. Note that in all cases, the dynamic logic functions of the selected scenario are used.

Refer to the Repository Configuration section for more details on dynamic field and dynamic logic configuration possibilities.

Claims Transaction Repository

Data Model (Tables)

This component holds claim transactions. The details of a claim transaction in the repository are never updated, although an 'unfinalized' label can be added to a transaction. Dynamic fields may be added to the repository in a similar way as to how they can be added to the main claim entities (working copy). Note that the dynamic fields of the repository are not necessarily the same as the ones for the working copy. This is because the repository fields will often hold values from referenced entities in the repository claim entities. They would be fixed fields in the referenced entities but dynamic fields in the repository model. Likewise, dynamic fields on the referenced entities that are required in the repository would be defined on claim transaction entities as referenced entities are not in the repository (that is, they would be on different entities). Refer to the Dynamic Fields implementation guide for more details.

Event Generator

The repository has a configurable event generator. Whenever a transaction is created in the repository or labeled, the event generator checks if the transaction meets the criteria of one or more of the defined events. If it does, notifications for the events are published (with identification details of the transaction needed to retrieve it via the integration point or reporting views). Refer to the Repository Configuration section for details.

Integration Point

The repository also provides a set of services (Integration Point) to allow downstream applications to access the claim data. Requests to this integration point can result in working copy claims and / or claim transactions being returned. When a working copy claim is returned, it is transformed into a claim transaction without a version. In effect, it is a preview of what the claim transaction for the claim would be if it were finalized at the time of the request. This transformation is done using a transaction creation scenario in the same way that a claim transaction is created when a claim is finalized. The entire transactions are returned in an XML structure. Refer to the Integration Point section for details.

Financial Transactions

Data Model (Tables)

This parts holds:

Base Financial Object (corresponding to Claim)
Financial Transaction and Financial Transaction Process Data (corresponding to Claim Transaction)
Financial Transaction Detail and Financial Transaction Detail Process Data (corresponding to Claim Line Transaction Coverage)

For more detail, see the Financial Transaction Model.

Oracle Health Insurance Repository Reporting Views

This component provides read access to repository transactions for purposes where the full transaction is not required (via the integration point). Refer to the separate Repository Reporting Views Implementation Guide for details.

Oracle Health Insurance Unfinalize Function

The claim unfinalize functionality in Claims allows a finalized claim to be changed. When a claim is unfinalized, its transaction in the repository is labeled as being 'unfinalized' and the event generator sends out an event notification for each configured event that matches the details of the claim transaction being unfinalized. These notifications inform downstream applications that they can expect a new version of the claim.

In addition, a reversal transaction for the version being unfinalized as well as a reversal financial transaction is created. Reversal transactions are in effect copies of regular transactions with most amounts and values reversed. For full details, refer to the Reversal Transactions section.

The labeling of a claim and creation of a reversal transaction and reversal financial transaction is done in the same unit of work as the unfinalize operation in Claimsto ensure that labels and reversals are always and only applied if the unfinalize action succeeds. Unfinalized labels and reversal transactions are never updated or removed. When the claim is refinalized a new regular transaction will be created (without a label).

Downstream Applications

The downstream applications are the Claims Financial Processing (if being used) and other local external (not part of Claims) applications that need to respond to / process claim transactions. Examples include the data warehouses, EOB and EOP / EDI (835) producers, portals, and information services.

The downstream applications make use of the Claim Out Integration Point for accessing complete claim transactions and of the Repository Base Views for access to selected details of claims. In addition, they could use the Claim Out Integration Point, the main Claims Base Views and / or the Claims Functional Reporting Views for access to the working copy of claims.

Each downstream application will need to implement an approach to initiating transaction processing for 'new' claim transactions and to actually processing claim transactions. Several possible approaches are outlined below. Note that the approaches for initiating transactions have been separated from approaches to processing transactions. In general, each approach for initiating transactions can be used in combination with any of the approaches for processing transactions (leading to a significant number of possible combinations).

Approaches to Initiating Transaction Processing

Downstream applications can determine their own approach for initiating processing of transactions in the repository. The following three main approaches are expected to be used:

Use New Claim Transaction Notifications Only

With this approach, events would be configured to notify a downstream application of the arrival of transactions that they are interested in. Upon receipt of a notification, the application would process the transaction and delete the notification / mark it as processed. They would not be aware of transactions that do not meet the criteria of the events that have been configured or immediately of 'unfinalizations'. With the arrival of a new transaction for a claim, applications using this approach could infer that the previous version had been unfinalized.

Use New Claim Transaction Notifications and Unfinalize Notifications

With this approach, events would be configured to notify a downstream application of the arrival and unfinalization of transactions that they are interested in. Upon receipt of a notification, the application would process the transaction (or unfinalization of a transaction) and delete the notification / mark it as processed. They would not be aware of transactions or the unfinalization of transactions that do not meet the criteria of the events that have been configured.

Use Queries to Process Transactions in Batches

With this approach, a downstream application would query the repository (using the Claim Out Integration Point or Repository Base Views) for transactions that meet the criteria they are interested in and that have not yet been processed (for example, those with a date later than the last run date or not recorded as being already processed). It would then process each transaction returned by the query. The downstream application may decide to record which transactions have already been processed or rely on keeping track of the date ranges that have been processed.

The Claims Financial Processing can be referred to for use as a detailed example of this approach to initiating transaction processing.

Approaches to Transaction Processing

Downstream applications can determine their own approach to processing transactions. This section describes several possible approaches that could be combined with approaches to initiating processing (as described above). With all approaches, processing would be initiated upon receipt of a transaction notification or selection of a transaction for processing and full transactions could be retrieved using the Claim Out Integration Point or using the Repository Base Views.