Repository Configuration Approach - Example
This document outlines a possible approach to configuring the Claims Transaction Repository. The approach is based on the US context and is only intended as an example to help customers get started with determining their own approach.
| Only configuration of the repository is covered; each downstream application also requires a strategy for either responding to notifications from the repository or querying the repository. The strategy needs to cover the arrival of new claim transactions (of initial claim versions and new versions of claims) as well as claims being unfinalized. |
Context
This section provides an overview of the context in which configuration of the repository is done.
Oracle Health Insurance and Local Field Usage Descriptions
These descriptions are to be created by clients (as a deliverable of this procedure). These descriptions should indicate the following for each Claims Fixed Field and US Seed Dynamic Field:
-
if the field is used or not
-
how the field is used (as needed to indicate 'nuances' of usage or an alternate usage to that described in the Developer Guide)
For each Local Dynamic Field, only a full description of the field is required.
Claims Fields
The Claims Fields are the fields of the main OHI claim working copy data model and fields of other working copy entities that are referred to by claims (for example, relations and procedures).
Fixed Fields
The Configuration Guide and the Operations Guide provide descriptions of the fixed fields. The main sections of the guides that are likely to be useful are:
-
Claims Operations Guide - Claims Model
-
"Providers" page of the Configuration Guide - Provider Data Model
-
"Relations" page of the Configuration Guide - Relation Data Model
-
"Procedures" page of the Configuration Guide - Procedure Model
-
"Diagnoses" page of the Configuration Guide - Diagnosis Model
Claims to Oracle Health Insurance Transaction Repository Field Mappings
These mappings are to be created by clients (as a deliverable of this procedure). These mappings should indicate the following for each Claims Field:
-
if the field is required in the repository and the name of the corresponding repository field(s)
-
any formatting / transformation of values needed when being placed in the repository
Claims Transaction Repository Fields
Fixed Fields
The "Repository Model" section of the "Claims Transaction Repository" chapter in the Developer Guide describes these fields.
US Seed Dynamic Fields and Records
The fields and records that are being delivered as seed data, are described in the Claims Transaction section of US Localization ⇒ Dynamic Fields. Essentially, all US specific dynamic fields defined for the working copy claim structure, are also defined for the Claim Transaction Repository.
Oracle Health Insurance Transaction Repository to Downstream Application Field Mappings
These mappings are to be created by clients (as a deliverable of this procedure) for each downstream application. These mappings should indicate the following for each Claims Transaction Repository Field:
-
if the field is used or not by the application
-
how the field is used (as needed to indicate 'nuances' of usage or an alternate usage to that described in the Claims to Oracle Health Insurance Transaction Repository Field Mappings)
-
any formatting / transformation of values needed when being used to populate interface fields
Note that this 'deliverable' could be a new version of the original Claims to Downstream Application Field Mappings (with the addition of OHI Claim Transaction Repository Fields).
Downstream Application Interface Fields
These fields are the fields of other application interfaces that need values from Oracle Health Insurance.
Claims to Downstream Application Field Mappings
These mappings are to be created by clients (as a deliverable of this procedure) for each downstream application. These mappings should indicate the following for each Claims Field:
-
if the field is used or not by the application
-
how the field is used (as needed to indicate 'nuances' of usage or an alternate usage to that described in the Claims to Oracle Health Insurance Transaction Repository Field Mappings)
-
any formatting / transformation of values needed when being used to populate interface fields
Starting Point
The approach is based on the expectation that basic analysis has been done to determine which Claims fields will be used to support claims processing and how they will be used. More specifically, the Oracle Health Insurance and Local Field Usage Descriptions deliverable should have been completed.
Determine Downstream Application Information Needs (Per Application)
The purpose of this step is to determine which fields of the downstream application interface message(s) need to have values (from Claims) and ensure it is clear what the fields should hold (e. g. how they are used). This step needs to be done for each downstream application.
The output of the step is an overview of the information that is required by a given downstream application from Claims and a detailed description of the fields that are required.
Map Downstream Application Fields to Claims Fields (Per Application)
The purpose of this step is to determine the source of the information that is required by a downstream application. This step needs to be done for each downstream application.
For each downstream application interface message field that requires a value from Claims, determine if there is an Claims fixed field, US seed dynamic field or a local dynamic field that could provide a value for it. If so, record this as Claims to Downstream Application Field mapping.
If there is no Claims field that is a suitable source, choose one of the following solutions:
Get Value from External Source
-
If the field is not required by Claims or for any other purpose, consider if it should be collected by an external call from the interface that will load values from Claims.
Derive from Existing Fields
-
If the field can be derived from fields already in Claims, indicate this as well as the logic for deriving the required value. Also consider if it would be better for the downstream application to be changed to determine the value from the other values instead.
Pass through Claims
-
If the field could be provided to Claims (for example, on claims coming in or via another integration point), consider adding it as a local dynamic field to Claims (or using a fixed field that was not going to be used). In this case, the value would in effect be 'passed through' Claims just for the downstream application.
The output of this step is the Claims to Downstream Application Field Mappings for an application.
Review Mappings
The purpose of this step is to review the mappings of each downstream application to check if any of the fields that have been added to Claims for other downstream applications would be a better source of values. This step would be done after all the downstream applications have had their fields mapped (initially) to Claims fields.
The output of this step is confirmed mappings between Claims and the downstream applications.
Add Dynamic Fields to Claims
The purpose of this step is to add local dynamic fields that are required to pass values through Claims to the main Claims model (that is, claims and / or reference data areas).
The output of this step is the definition of the required dynamic fields as well as any changes to the interfaces that are needed to provide the values for these fields.
Create Repository Dynamic Fields
The purpose of this step is to add local dynamic fields to the Claims repository that are needed to hold values (from the main OHI Claims model) required by any downstream application that are not available in the fixed repository model or as seeded dynamic fields. Local dynamic fields are required for each main Claims model field that is required downstream that does not have a corresponding repository fixed field or local seed dynamic field. This applies to all types of fields (for example, fixed, seeded dynamic fields, and local dynamic fields). In other words, the repository local dynamic fields may correspond to fixed, seed dynamic fields, and local dynamic fields).
In addition, local dynamic fields are required for derived values that are to be provided for downstream applications.
The output of this step is the definitions and usages of the required repository dynamic fields.
The Repository Configuration page of the Developer Guide provides details on creation of repository dynamic fields.
Map Downstream Application Fields to Claims Transaction Repository Fields
The purpose of this step is to prepare the final mappings between the repository fields and downstream application interfaces. This can be done by adding a column to hold the repository field to the Claims to Downstream Application Mappings. For example, the new column could be filled as follows:
-
for fields that map to a main Claims model field that has the same name in the repository, use the same name
-
for fields that map to a main Claims model field that has a different name in the repository, use the name of the one from the repository
-
for fields that do not map directly to a main Claims model field, add the name of the field from the repository
Prepare Transaction Creation Logic
The purpose of this step is to define the dynamic logic that is needed to create claim transactions.
A possible approach to this would be to start with the example dynamic logic and (for each dynamic logic function) to do the following:
-
remove assignment statements for fixed repository fields and US Seed fields that are not needed by any downstream application
-
add logic as needed to set values for repository fields that do not have a single direct source
-
add formatting logic as needed to set values for repository fields that have a direct mapping to a main Claims model field but require values in different formats
-
add simple assignment statements for other values