Repository Configuration

This section is an introduction to the configuration of the Claims Transaction Repository. Configuration involves:

  • adding dynamic fields to the repository,

  • preparing one or more sets of dynamic logic to be used in creation of claim transactions from claim working copies (transaction creation scenarios), and

  • configuring the events that are to be triggered on the arrival of a new claim transaction or the unfinalization of a claim

In preparation for configuration, analysis is required to determine which details from Claims are to be included in the repository and what the format of those details should be in the repository. In most cases the format of values would be the same, but it is possible to decide to change the formats if needed.

The details from Claims that may be placed in the repository include both direct claim details and referenced details. Direct claim details refer to those in the claims (working copy) data model, referenced details refer to those from other data model areas such as relation, provider, or procedures that are referenced from claims. This analysis needs to take into account the needs of all the downstream applications. Details only need to be included once regardless of how many downstream applications use them. Although the repository is not specific to any one downstream application, it may be that some fields are used exclusively by a particular downstream application.

The financial information requires special attention. It is important to evaluate what level of financial details are required for the financial application being used. It could be for a given configuration of the system, the coverages are at the correct level of granularity for the financial application. In this case financial transaction details would simply need to correspond 1:1 with coverages. However, if the granularity is different, logic would need to be added to break (some) coverages into multiple financial transaction details (for example, to handle allocations of a single covered amount to more than one payment receiver).

There may also be other cases where special attention being required (that is, where dynamic logic does not simply transfer / format values). For example, it may be that a value needs to be set on a claim transaction based on a complex condition or logic (that is, derived from multiple values).

The downstream applications that receive / access information from the repository are treated as 'trusted' components in the overall SOA architecture. It is important that access restriction labels are filled to enable the components to enforce and / or make restrictions visible. Also, if adding dynamic fields to hold secured attributes that are not already covered by a label the label should also be added. For example, if adding an address for claimants, persons or objects the access restriction code for the address should be added as well whereas if adding a contact detail of a claimant, person or object no additional label would be required as the contact details label is already included as a fixed attribute.

Once analysis is complete, dynamic fields need to be added to the entity model of the repository for required details that are not in the fixed entity model of the repository or seeded dynamic fields that have been installed. Then transaction creation scenarios need to be created to populate both the repository native fields and the dynamic fields.

For a more detailed example of how configuration may be approached, refer to the Repository Configuration Approach - Example.

Adding Dynamic Fields and Records

The transaction repository data model may be extended with dynamic fields in a similar way to the Claims data model. Only free fields without dynamic logic may be used. It is not the intention that the transaction repository validates data (as would be the case if dynamic logic was defined).

In addition, dynamic records may be added to the repository.

Refer to the "Extensibility" chapter of the Configuration Guide for details on defining dynamic fields and dynamic records for the repository.

Note that transactions scenarios may also have dynamic fields. These are regular 'working copy' dynamic fields.

Create Transaction Creation Scenarios

Creation of a transaction creation scenarios involves:

  • determining which scenarios are needed, and

  • creating one scenario (without selection criteria) or more scenarios (with selection criteria).

Specification of which fields of the repository are populated and how values are transformed for placement in the transaction repository is done through the coding of transaction creation logic (using dynamic logic as elsewhere in Claims). Transaction creation logic is created as dynamic logic functions that may be prepared for use in a single or several scenarios. It may use convenience and 'helper' methods.

Definition of the transaction creation logic consists of:

  • determining all claim and claim detail entity attributes that need to be included in the repository

  • determining all information from entities referenced by claims and claim detail entities that needs to be included in the repository

  • determining any formatting that is required

  • coding transaction creation logic needed to retrieve and format the required information into the claim transaction object.

Optionally, dynamic fields may be added to transaction creation scenarios to be used to specify parameters for the dynamic logic functions.

Refer to the Transaction Creation Scenario section for details.

Configure Claim Transaction Event Rules

Create the claim transaction event rules that are required for each downstream system.

Refer to the Claim Transaction Event Rules section for details.