Repository Base Views
This section describes the transaction repository base views. These views provide access to the repository with dynamic fields presented as regular columns and tables. Dynamic fields are represented as regular columns and dynamic records are presented as child tables. There is one view for each entity of the repository model as well as one view for each dynamic record that has been configured for the repository.
The views are generated as part of system configuration and need to be regenerated when repository dynamic fields and dynamic records are added or changed. View generation is not covered in this section.
There are separate working copy reporting views which are described separately. The working copy base reporting views are very similar to the repository views. The main differences are:
-
there are working copy reporting views for the entities that are referenced from working copy claim entities whereas the repository claims do not have reference entities,
-
the working copy views resolve multi-lingual aspects of the working copy data model; this does not apply to the repository views as the repository is not multi-lingual,
-
the working copy does not have dynamic records; however, some working copy dynamic fields are presented in views in a very similar way to repository dynamic records, and
-
there are no functional views for the repository as the repository is already an 'external functional view' of a claim transaction.
The following sections describe each of the main types of repository views in detail.
Repository Model Entity Views
The entity views correspond to the entities that are described in the repository model section. There is one physical table for each of the repository entities.
View Columns
The view for each transaction repository model entity has:
-
a column holding the internal id of the entity,
-
a column holding the internal id of the immediate parent entity (except for CTR Claim)
-
a column for each fixed attribute of the entity it is for,
-
a column for each dynamic field that has been configured for the entity (in the repository), and
-
standard technical columns.
Each of these 'categories' of columns is explained in more detail below:
Internal Id
The internal id column shows the arbitrary unique record id of the underlying repository table record id.
Parent Internal Id
The parent internal id shows the internal id of a detail record’s parent record. The parent internal id is included for use in joining the view of an entity with its parent (for example, to join the claim line view to the claim view).
Fixed Attribute Columns
The fixed attribute columns show the columns that hold the fixed attributes of an entity. The fixed attributes are described in the repository model section. These columns have the same names and data types as in the underlying table columns. The contents of columns are not transformed by the views.
Dynamic Field Columns
These columns hold the values of repository dynamic fields. There is one of these columns for each repository dynamic field of the entity of the view. The name of the column for a dynamic field is based on the field usage name from its definition. The column name is the field usage name in upper case with each upper case letter in the field usage name preceded by an '_'. For example, 'mainOccupation' becomes MAIN_OCCUPATION.
It is important for procedures to be in place to prevent changes to the 'field usage name' without considering the impact on 'saved' queries.
Security
The reporting views must only be made available to fully 'trusted' users and applications. The reporting views do not restrict access to specific rows in any way. If a user has direct access to a view, they have access to all rows that can be accessed with the view. The access restriction labels are included in each view and could be used as a basis for enforcing any fine grained security that is needed in downstream applications. All fine grained security would be completely implemented in the downstream application (outside of Claims) and would require a detailed understanding of the Claims user access model and concepts.
Examples
The following examples illustrate the views for the claim and claim line entities. For the purposes of this example, the dynamic fields for US Seed Data have been configured.
CTR_CLAIMS_V
ID |
NUMBER |
Unique internal id for this claim. |
CODE |
VARCHAR2 |
|
VERSION |
NUMBER |
|
AUTHORIZATION_CODE |
VARCHAR2 |
|
BRAND_CODE |
VARCHAR2 |
|
BRAND_DESCRIPTION |
VARCHAR2 |
|
BRAND_PAYER_REL_CODE |
VARCHAR2 |
|
BRAND_PAYER_REL_NAME |
VARCHAR2 |
|
CLAIM_DATE |
DATE |
|
CLAIMANT_PROV_CODE |
VARCHAR2 |
|
CLAIMANT_PROV_CODE_DEF |
VARCHAR2 |
|
CLAIMANT_REL_CODE |
VARCHAR2 |
|
CLAIMANT_REL_DOB |
VARCHAR2 |
|
CLAIMANT_REL_DOB_INTERP |
VARCHAR2 |
|
CLAIMANT_REL_NAME |
VARCHAR2 |
|
… all other fixed fields from CTR Claim … |
||
ACCIDENT_DATE |
DATE |
|
ACCIDENT_STATE |
VARCHAR2 |
|
… all other US Seed single value dynamic fields … |
||
… locally defined single value dynamic fields … |
||
… technical columns … |
CTR_CLAIM_LINES_V
ID |
NUMBER |
Unique internal id for this claim. |
CLAIM_ID |
NUMBER |
Internal id of the immediate parent entity |
CODE |
VARCHAR2 |
|
VERSION |
NUMBER |
|
ALLOWED_AMOUNT |
NUMBER |
|
AUTHORIZATION_CODE |
VARCHAR2 |
|
AUTHORIZATION_EXCEPTION_TYPE |
VARCHAR2 |
|
BENEFITS_INPUT_AMOUNT |
NUMBER |
|
BENEFITS_PROV_CODE |
VARCHAR2 |
|
BENEFITS_PROV_CODE_DEF |
VARCHAR2 |
|
CLAIM_DATE |
DATE |
|
CLAIMED_AMOUNT |
NUMBER |
|
… all other fixed fields from CTR Claim Line … |
||
ANESTHESIA_MINUTES |
anesthesiaMinutes |
|
AREA_ORAL_CAVITY |
areaOralCavity |
|
… all other US Seed single value dynamic fields … |
||
… locally defined single value dynamic fields … |
||
… technical columns … |
The following query can be used to retrieve a claim line with its claim details.
select claim.code , claim.version , claim.claimant_prov_code , claim_line.sequence , claim_line.allowed_amount , claim.accident_date , claim.accident_state from ctr_claims_v claim , tcla_claim_lines_v claim_line where claim.id = claim_line.claim_id
Note that join between claim and claim line is implemented using the internal ID columns.
Dynamic Record Views
The view for each dynamic record has:
-
a column holding the internal id for a row of values
-
a column holding the internal id of the parent record (of the row of values)
-
a column for each field that has been configured for the dynamic record, and
-
columns for start date and end date.
View Naming
The names of these views will be the parent table internal Claims table alias + '_' + the dynamic record usage name. The Claims table alias is 4 characters.
When naming dynamic field usages, it is important to keep usage names short enough to be valid table names after addition of the table alias. The maximum length including prefixes is 30. Therefore, the maximum length of dynamic record usage name is 23.
Example
This example shows the view for a dynamic record defined on the claim transaction entity with the following details:
-
Dynamic Record Name: Occupations
-
Dynamic Record Fields
-
1: Code
-
2: Risk Level
-
-
Dynamic Record Usage Name: Person Occupations
TCLA_PERSON_OCCUPATIONS
ID |
NUMBER |
Unique Internal ID for a Row of Values |
CLAIM_ID |
NUMBER |
Internal id of the immediate parent entity |
CODE |
VARCHAR2 |
Dynamic record value 1 |
RISK_LEVEL |
VARCHAR2 |
Dynamic record value 2 |
START_DATE |
DATE |
Date values are effective from. |
END_DATE |
DATE |
Date values are effective to. |
The following query can be used to retrieve the list of person occupations for version 1 of claim 123.
select occupation.code , occupation.risk_level , occupation.end_date , occupation.start_date from ctr_claims_v claim , tcla_person_occupations occupation where claim.id = occupation.claim_id and claim.code = '123' and claim.version = '1'
Note that join between claim and person occupations is implemented using the internal ID columns.