Extending Tables

The purpose of dynamic fields is to enable customers to extend the Oracle Health Insurance data model with market-, business line- and customer specific fields. These fields can be used to simply persist information and even leveraged to affect the way a claim, policy, authorization or contract is processed. This chapter explains how system records can be extended to hold additional information.

An entity can be extended in three ways; by adding a field, a code or a record. A 'field' stores a that is not bound by a predefined domain, like a date field or a secondary ID field. A 'code' is similar, except that it can only hold values from a pre-defined list of choices, like a drop-down menu. A 'record' adds a user defined detail entity to the subject entity.

Adding Dynamic Fields and Records

A dynamic field usage is the link between a table (entity) and the dynamic field that extends that table. Not all tables in the Oracle Health Insurance schema can be extended. Furthermore, some tables that can be extended, can only be extended by dynamic fields that have no time validity. The rationale behind this is that these tables already embed time validity, which then also applies to the dynamic field that extends the table. A dynamic field usage has the following attributes:

Field	Description
Table	The table that is extended
Name	The name that is used by interfaces and dynamic logic scripts. The name can be specified in mixed case, to support the coding conventions in use. The name for a dynamic field usage cannot be equal to the name of a fixed field or another dynamic field usage for the same table
Display Name	The label of the field as shown in the user interface
Sub Type	Field, Code or Record
Field	The field that defines this dynamic field
Code Definition	The single flex code definition or flex code set that represents the domain of allowed flex codes
Record Definition	The dynamic record definition that defines what kind of records the table is extended with
Sequence	Drives the placement of this dynamic field in standard user interface
Condition	Determines whether or not a dynamic field or record value may be set
Mandatory Condition	Determines whether or not a dynamic field or record value is mandatory
Mandatory?	A dynamic field or record value must be specified
Unique?	The value of the field must be unique across all records in the extended table
Multiple values?	The dynamic field or record can store more than one value
Time valid?	The dynamic field or record value(s) are stored with a start and end date
Search?	The field appears in the advanced search feature for the extended table
In LOV?	The dynamic field is displayed in the LOV on the extended table
Search in LOV?	If checked, then it is possible to search on that dynamic field in the default LOV.
Display in Overflow?	This indicates whether the dynamic field should be shown in the overflow area in a multi record block
Number Format Type	The format in which a numeric dynamic field should be displayed
Access Restriction	Determines whether or not the access to the usage is restricted
Start date	The first date that a value can be set for the specified dynamic field
End date	The last date that a value can be set for the specified dynamic field
PII?	The field or record contains Personal Identifiable Information (PII)

Field

Description

Table

The table that is extended

Name

The name that is used by interfaces and dynamic logic scripts. The name can be specified in mixed case, to support the coding conventions in use. The name for a dynamic field usage cannot be equal to the name of a fixed field or another dynamic field usage for the same table

Display Name

The label of the field as shown in the user interface

Sub Type

Field, Code or Record

Field

The field that defines this dynamic field

Code Definition

The single flex code definition or flex code set that represents the domain of allowed flex codes

Record Definition

The dynamic record definition that defines what kind of records the table is extended with

Sequence

Drives the placement of this dynamic field in standard user interface

Condition

Determines whether or not a dynamic field or record value may be set

Mandatory Condition

Determines whether or not a dynamic field or record value is mandatory

Mandatory?

A dynamic field or record value must be specified

Unique?

The value of the field must be unique across all records in the extended table

Multiple values?

The dynamic field or record can store more than one value

Time valid?

The dynamic field or record value(s) are stored with a start and end date

Search?

The field appears in the advanced search feature for the extended table

In LOV?

The dynamic field is displayed in the LOV on the extended table

Search in LOV?

If checked, then it is possible to search on that dynamic field in the default LOV.

Display in Overflow?

This indicates whether the dynamic field should be shown in the overflow area in a multi record block

Number Format Type

The format in which a numeric dynamic field should be displayed

Access Restriction

Determines whether or not the access to the usage is restricted

Start date

The first date that a value can be set for the specified dynamic field

End date

The last date that a value can be set for the specified dynamic field

PII?

The field or record contains Personal Identifiable Information (PII)

Depending on the sub type, a dynamic field usage refers to either a field, code definition or record definition. The fields "Search?", "In LOV?" and "Search in LOV?" apply only to single value non time valid dynamic fields.

Only usages for fields can be configured as unique. A dynamic field usage of the type Field cannot be both unique and have multiple values. The unique indicator can no longer be checked once actual values have been stored for that usage.

Start- And End Date

The start and end date on a usage represent the period in which it is possible to populate the dynamic field with a value. The as of date that is used depends on the table that the dynamic field or record extends. For example, for a claim line, this would be the service start date. Consider the following scenario:

The user sets up a dynamic field usage, specifying a 'no claim amount' on a claim line. The dynamic field usage has a start and end date of 1-JAN-2006 through 31-DEC-2007. This setup ensures that only claim lines that have a service start date in 2006 or 2007 can have a field 'no claim amount'.

The following as of dates are used: claim date for claims, bill date for bills, start date for claim lines, start date for authorizations, start date for procedure setting, start date for diagnosis setting and the system date for all other tables.

The start and end date essentially impose a condition on the usage of a dynamic field. The start and end date do not constitute the time validity of the dynamic field usage as a record. To clarify, it is not possible to have two dynamic field usages named "SSN", one being valid from 1-JAN-2008 through 31-DEC-2008 and a second one being valid from 1-JAN-2009 through 31-DEC-2009.

The start and end date of a 'flex code' dynamic field usage are bound by the start and end date of the referenced flex code definition.

Time Valid?

If the time validity indicator is checked, then the value(s) that are stored in the dynamic field are have a start and end date. To clarify, consider the following example:

In order to keep track of its person’s occupation, the user wants to extend the relation table with a field that stores an occupation. The time validity indicator on the dynamic field usage is checked. It is now possible for the same person record to have occupation A from from 1-JAN-2008 through 31-DEC-2008 and occupation B from 1-JAN-2009 through 31-DEC-2009 through a single dynamic field 'occupation'.

Creating a time valid dynamic field is like adding a detail table to a master table, in which each record in the detail table has a start and end date. Once a value has been stored for the field or record usage, the time-valid indicator can no longer be checked or unchecked

Multiple Values?

It is possible for a user to set up a dynamic field that contains more that a single value. To clarify consider the following example:

A user wants to keep track of the teeth that are subject of dental procedures on a claim line. The claim line table is extended with a dynamic field named 'tooth codes'. Because it is possible that a single dental procedure affects multiple teeth, the user checks the multi value indicator in the dynamic field usage. This setup makes it possible for a claim line to be imported with a 'tooth codes' field that has two or more values, e.g, the field 'tooth codes' has the values 16, 15 and 14.

Creating a multi value dynamic field is like adding a detail table to a master table. Note that multi value dynamic fields are restricted such that no two values can be identical. This check does not apply to dynamic records.

Note that it is possible for a dynamic field to be both time valid AND have multiple values. A single valued time valid dynamic field can have multiple values over time, but no more than one at any one point. A multi valued time valid dynamic field can have multiple values over time and multiple values may be time valid at any one point.

Once at least one value has been stored for the field or record usage, the multiple values indicator can no longer be unchecked.

Condition

It is possible for a user to set up a dynamic condition on the usage of a dynamic field. The subject of this condition is always the record in the table that the dynamic field usage extends. The actual condition is configured as a dynamic logic condition. How to set up a dynamic logic condition is specified in the Implementation Guide for Foundation. Consider the following scenario:

In order to keep track of person’s occupation, a user wants to extend the relation table with a field that stores an occupation. However, the relation table contains both persons and organizations. Since it only makes sense to extend a person with an occupation, the user sets up a dynamic logic condition that checks if the relation record represents a person. This condition will be evaluated whenever someone tries to set a value for the occupation field. If the records does not represent a person, then it is not allowed to provide a value for the 'occupation' dynamic field.

A dynamic logic condition can be tied to a message. This message is generated whenever the dynamic condition evaluates false. In this event, the substitution parameter {0} holds the dynamic field usage display name by default. Consider the following example.

"Hobby" is a dynamic logic condition that ensures that this dynamic field can only be entered for relations of the subtype person.

return relation.isPerson()

The dynamic field usage "HOBBY" with display name "Favorite hobby" specifies a dynamic field that is tied to this condition. The message that is tied to the condition reads: "It is not allowed to specify a {0} for this relation". When (through the relation integration point) a relation request message attempts to specify the HOBBY dynamic field for a relation of the subtype "organization", OHI Claims Adjudication and Pricing will respond with the message: "It is not allowed to specify a Favorite hobby for this relation".

Mandatory Condition

It is possible to set up a condition under which a dynamic field is mandatory. The subject of this condition is always the record in the table that the dynamic field usage extends. Consider the following scenario:

A user wants to store a social security number (SSN) for each person. Therefore, the user specifies a dynamic field usage for the SSN, on the relation table, with the mandatory indicator checked. However, this poses a problem for new born persons, for which no SSN has been issued yet. The user resolves this by setting up a condition on which the SSN is mandatory. This condition checks the age of the person: a SSN is only mandatory if the person is over one year old.

Note that it is only allowed to specify a condition on whether or not a dynamic field is mandatory, if the mandatory indicator is check. If the condition evaluates to be false, then the indicator is overruled and no field value is required. If the mandatory indicator is checked while no condition has been specified, then the dynamic field is always mandatory.

Number format type

Any fixed number column is assigned a number format type that specifies the way it is displayed in the UI; these types exist:

Amount

This format displays a thousands separator in combination with 2 decimals, so 1234 is shown as 1,234.00 and 1234.5 is shown as 1,234.50

Number

This format displays a thousands separator in combination with as many decimals as are specified, so 1234 is shown as 1,234 and 1234.5 is shown as 1,234.5

Integer

This format displays no thousands separator, so 1234 is shown as 1234 (useful for e.g. a house number in an address)

Formatted Integer

This format displays a thousands separator, so 1234 is shown as 1,234 (useful for e.g. a maximum number of units)

All these number columns are right aligned.

Numeric dynamic fields can also be assigned one of the above number format types; if none is assigned, then it defaults to 'Number'.

Dynamic Field Values

Dynamic field values can be set and updated through both user interface pages and integration points. Once a table has been extended with a dynamic field, that dynamic field is visible in the appropriate page. For example, when a user extends the provider table with a dynamic field 'license number', a license number field will appear in the individual provider and organization provider pages. The user interface typically shows dynamic fields grouped together in a single designated area on the page.

Visually, single value non-time valid dynamic fields appear the same as fields native to the system. If multiple values exist for a dynamic field the are sorted on the start date (if applicable) in descending order and value (key value in case of flex codes) in ascending order. Note that this applies to both dynamic fields that are displayed in the overflow and to the dynamic fields that are displayed in the table (only non-time valid dynamic fields are displayed in the table).

In the case that a table can be populated through an integration point, it is also possible to set the dynamic fields that extend that table. For example, through the claims in integration point, it is possible to set dynamic fields that extend the claim, claim lines, bills, claim sub lines, claim diagnosis, claim line diagnosis and bill diagnosis tables. In a similar fashion, dynamic fields on the procedure settings, diagnosis settings, providers and relations, can be set through their respective integration points.

The implementation guide on common Soap Integration Point features provides further insight on how OHI handles dynamic fields on incoming Soap Integration Point messages; the implementation guide on common HTTP API Integration Point features provides further insight on how OHI handles dynamic fields on incoming HTTP API Integration Point messages.

Scenarios

Scenario 1

A customer wants to extend the relation table with a field that captures a user remark. Creating a new field is a two step process. The first step is to create a new field (definition), the second step is to create the link between that field and the entity to which it is added.

The user creates a new field with the code 'C4000'. The description is 'Generic text 4000 chars', data type is 'char' and maximum length is '4000'. There is no need to set the decimal and validation properties.

The user creates a new dynamic field usage for the relation table. The name is 'remark' and the display name is 'Remark'. The customer sets the display sequence to 1, meaning that in the standard pages for persons and organizations, this is the first dynamic field listed in the designated section. The free field 'C4000 is referenced'.

The value of the remark field is not unique, has only a single value, is not (conditionally) mandatory and is not time valid. There is no condition on whether or not a value is allowed. There are no time constraints that determine whether or not a remark is allowed. The result of our setup is that the Relation page now shows a new field, labeled 'Remark' that may contain up to 4000 characters.

Scenario 2

Whenever a diagnosis is specified on an incoming institutional (hospital) claim, the user wants to know whether or not the diagnosis was present on admission (or whether the diagnosis was made after admission). This piece of information is an attribute of a diagnosis within the context of a particular claim, that is, the same diagnosis code can be present on admission on one claim, while not present on admission on another claim. For this reason the table that connects a claim with a diagnosis has to be extended with the indicator.

A 'present on admission' (POA) indicator is only applicable to institutional claim diagnoses and not for other types of claims, such as dental claims or professional claims. The user wants to ensure this through the correct setup.

The user sets up a flex code system named 'POA' that allows the following values:

N, meaning 'not present',
Y, meaning 'present',
U, meaning 'unknown',
W, meaning 'clinically undetermined'.

Specifics on how to set up a flex code system are detailed in Code definitions. The user creates a new dynamic field usage for the 'Claim diagnosis' table, that is, the table that connects a diagnosis with a claim.

The dynamic field usage is set up as follows:

Name - PresentOnAdmission
Display name - 'Present on admission?'
Type - Code
Flex code system - POA
Condition - INST

Note that any fields that are not mentioned are left blank or unchecked. The condition 'INST' is a dynamic logic condition that takes the 'claim' to which the 'claim diagnosis' is attached and ensures that it is an institutional claim. This way, the user ensures that only institutional claims have a POA indicator on their attached diagnoses.

Scenario 3

This scenario is an extension of scenario 2. The user wants to set the 'presentOnAdmission' indicator through the OHI Claims claims in integration point. Consider the following piece of XML, that shows how two diagnosis, including the 'presentOnAdmission' indicator, are sent in:

<claim>
      <diagnoses>
      <diagnosis code='123.01' flexCodeDefinitionCode='ICD-09-D' presentOnAdmission='Y'/>
      <diagnosis code='456.01' flexCodeDefinitionCode='ICD-09-D' presentOnAdmission='N'/>
    </diagnoses>
      ...

To clarify the example, other information that is sent in on a claim, such as a billing provider code and person code, is left out of the XML.