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.

Technical Columns

The underlying tables for entities have several technical columns. These are included in the views. These columns indicate information such as when records were created or last updated and by which user.

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 native 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 native 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.