Relations

This guide elaborates on the data model used to store demographic information in Oracle Health Insurance applications. This model is used to store demographic information for persons and organizations. Both of these roles are referred to as relations. Data of this type is referred to as reference data (as opposed to operational data and configuration data). In order to feed the relation data into Oracle Health Insurance applications there is an integration point. This integration point is also described in this implementation guide.

Persons

A person record stores the demographic information for a person. It has the following fields:

Field	Description
Code	The unique key that is used to identify the person
Initials	The abbreviation of the first names of the person
First name	The first name of the person
Middle name	The middle name of the person
Prefix	The prefix to the last name of that person
Name	The name of the person
Prefix partner	The last name prefix of the partner of the person
Name partner	The last name of the partner of the person
Suffix	The suffix of the person
Name format function	The dynamic logic function that is used to format the name (applicable only fro ADF). For JET formatted name is rendered based on application property ohi.jsui.formatted.name
Gender	The gender of the person
Date of birth	The date of birth of the person
Date of birth interpretation	The way the date of birth should be interpreted. There are three possible values: The date is exact Only the month and year are accurate (all date of birth related checks will treat this date as though it specifies the first day of the month) Only the year is accurate (all date of birth related checks will treat this date as though it specifies the first day of the year)
Business phone number	The phone number that is used for business purposes
Private phone number	The private phone number
Mobile phone number	The mobile phone number
Fax number	The fax number
Email address 1	The email address
Email address 2	A second email address
Preferred language	Preferred language for correspondence with this person
Language	Language for correspondence with this person
End date	The end date of the person
Contact details access restriction	The access restriction restricting access to the contact details of the person (see the implementation guide on User Access for more details)
Access restriction	The access restriction restricting access to the person (see the implementation guide on User Access for more details)

A person can have the following details: addresses, tags, bank account numbers, marital statuses, titles, assigned providers and contract alignments.

Constraints:

• The end date of a person may not lie in the future

• A person can only be linked to an access restriction of type Non-Address Contact Detail for the non-address contact details and type Person Details for all details

• The prefix for the partner may only be specified if the name partner is also specified

• A specified e-mail address must comply with standards for specifying e-mail addresses

• The language of a relation needs to be an installed language

Organizations

In OHI applications, all organizations are stored as an organization. An organization has the following fields:

Field	Description
Code	The unique key that is used to identify the organization
Name	The name of the organization
Business phone number	The phone number that is used for business purposes
Private phone number	The private phone number
Mobile phone number	The mobile phone number
Fax number	The fax number
Email address 1	The email address
Email address 2	The second email address
Preferred language	Preferred language for correspondence with this organization
Language	Language for correspondence with this organization
End date	The end date of the organization

An organization can have the following details: addresses, tags and bank account numbers.

Constraints:

• A specified e-mail address must comply with standards for specifying e-mail addresses

• The language of a relation needs to be an installed language

Addresses

A person or organization can have one address at any give point in time, per address type. In other words, a person can have multiple site addresses over time, but can never have two site addresses on the same day. An address has the following fields:

Field	Description
Relation	The person or organization that has the address
Type	The type of the address (Site or Postal)
Street	The street of the address
House number	The house number of the address
Number addition	The house number addition, such as a floor or apt. number
City	The city where the address is situated
Postal code	The postal code of the address
Additional part 1	An address contains three generic fields that can be used to further specify the address
Additional part 2	Additional part 3
Country	The country in which the address is situated
Country region	The region of the country in which the address is situated (can be used for e.g. States and Departments)
Start date	The start date of the address
End date	The end date of the address
Access restriction	The access restriction restricting access to the address (see the implementation guide on User Access for more details)

Constraints:

• It is not allowed to have an overlap in time validity for addresses for the same type and relation

• The country and the country region of an address should match

• If the upper indicators (specified on country level) for street, city, number addition, and the additional parts are true, the values should be entered in uppercase

• The address parts should comply with the dynamic logic for address parts that may be specified at country level

• An address can only be linked to an access restriction of type Address Contact Detail

Relation Tags

Relation tags serve to categorize persons and organizations. A person or organization can have multiple tags. Note that relation tags are not available in the OHI Enterprise Policy Administration, Oracle Health Insurance Authorizations and Oracle Health Insurance Value-Based Payments applications. A relation tag has the following fields:

Field	Description
Relation	The person or organization that has the tag
Tag type	The type of tag
Start date	The start date of the tag
End date	The end date of the tag

Constraints:

• It is not allowed to have an overlap in time validity for tags for the same relation and tag type

Relation Identifiers

A person or an organization can have multiple identifiers for example the Social Security Number, Driver License number etc.

A relation Identifier has the following fields:

Field	Description
Relation	The person or organization that has the identifier.
Identifier type	The unique key that is used to identify the identifier type.
Identifier	The identifier with ID (can contain digits and characters).
Ind enabled?	Is the relation identifier valid?

Bank Account Numbers

A person or organization can have multiple bank account numbers. A bank account number has the following fields:

Field	Description
Relation	The person or organization that has the bank account number
Bank account number	The bank account number (can contain digits and characters)
Debit bank account number	The debit bank account number
Special name	The name of the person or organization, different from the relation name, that is to be used for the bank account number
Start date	The start date of the bank account number
End date	The end date of the bank account number
Preferred?	Is this the preferred bank account number for a relation?
Bank account validation	The validation that applies to the bank account number

Constraints:

• It is not allowed to have an overlap in time validity for bank account numbers for the same relation, bank and bank account number

• There may only be one preferred bank account number at any point in time for the same relation

• If the bank account number references a bank account validation with indicator bank mandatory true then the bank should be specified

• If the bank account number references a bank account validation with indicator debit number true then the debit bank account number should be specified else it should be unspecified

• The bank account number should comply with the dynamic logic for bank account validation that it references

Marital Statuses

A person can have one and only one marital status at any given point in time. The domain of statuses is: (1) single, (2) married, (3) divorced, (4) widow and (5) living together. Note that marital statuses are not available in the OHI Authorizations and OHI Capitation applications. A marital status has the following fields:

Field	Description
Person	The person that has the marital status
Status	The marital status
Start date	The start date of the marital status
End date	The end date of the marital status

Constraints:

• It is not allowed to have an overlap in time validity for marital statuses for the same person

• The time validity of the marital status must be within the time validity of the person

Person Titles

A person can have multiple titles. A person title has the following fields:

Field	Description
Person	The person that has the title
Title	The title that the person has

Assigned Providers

An assigned provider is a provider who is assigned to a person with a specific assignment. A person can have multiple assigned providers. Note that assigned providers are not available in the Oracle Health Insurance Authorizations application.

Example:

• Provider Bob Smith is assigned to person John Doe as his Primary Care Provider from 01-Jan-2017 to 12-Dec-2017.

An assigned provider has the following fields:

Field	Description
Person	The person that has the assigned provider
Provider	The provider that is assigned to the person
Provider assignment type	The type of assignment of the provider assigned to the person
Start date	The start date of the assigned provider
End date	The end date of the assigned provider

Constraints:

• It is not allowed to have an overlap in time validity for assigned providers for the same person and provider assignment type

Contract Alignments

Contract alignments specify which persons are possibly relevant to which capitation contracts. A person can have multiple contract alignments. Note that contract alignments are not available in the OHI Claims Adjudication and Pricing and [authComponent]applications.

Example:

• Member John Smith is possibly relevant to capitation contract CONTR123 from 01-Jan-2017 to 12-Dec-2017

A contract alignment has the following fields:

Field	Description
Person	The person that has the contract alignment
Capitation Contract	The capitation contract that is aligned to the person Capitation contracts in OHI Capitation are described in the Capitation Contracts section of the OHI Capitation implementation guide Capitation contracts in OHI Enterprise Policy Administration only contain a code and a description
Start date	The start date of the contract alignment
End date	The end date of the contract alignment

Constraints:

• It is not allowed to have an overlap in time validity for contract alignments for the same person and capitation contract

Relation Configuration

The following section describes the setup that supports the relation data model. These are typically the value domains that are used by the reference data, such as the list of available countries, tags etc.

Titles

A person can have one or more titles.

Field	Description
Code	The unique code for this title
Display code	The displayed text for this title
Before?	Indicates whether this title should go before or after a person’s name
Display order	Specifies the displayed order in case a person has multiple titles
Active?	Indicates whether this title can be selected when creating or updating a person

The actual display code, order or whether a title goes before or after a person’s name is ultimately determined by the dynamic logic function specified in a persons name format. In other words, the 'display code, 'display order' and 'before?' fields have no inherent logic behind them, but serve as input for the name format function.

Prefixes

A person can have a single prefix.

Field	Description
Code	The unique code for this prefix
Display code	The displayed text for this prefix
Active?	Indicates whether this prefix can be selected when creating or updating a person

The actual display code is ultimately determined by the dynamic logic function specified in a persons name format. In other words, the 'display code' has no inherent logic behind it, but serves as input for the name format function.

Countries, Country Regions, Country Region Groups and Country Region Group

Countries are used by relation addresses. A country region represents a part of a country, such as a state or a province.

Country

Field	Description
Code	The unique code of the country
Name	The standard name of the country
Indication upper street	Should a street in this country display in uppercase?
Indication upper city	Should a city in this country display in uppercase?
Indication upper country region	Should a region in this country display in uppercase?
Ind default	Is this country the default?
Active?	If unchecked, this type is not available when creating or updating addresses

Constraints:

• There should be one and only one default country and this should be an active one

A country can have zero, one or more country regions. Country regions are also used on relation addresses.

Country Regions

Field	Description
Country	The country that has the country region
Code	The code of the country region, unique within the country
Display code	The display code of the country region

Constraints:

• If the upper indicator for country region (specified on country level) is true, the code of the region should be in uppercase

Country regions can be part of country region groups. This grouping then can be used to make a benefit specification or a product benefit specification only applicable for persons, providers or employers in a specific country region group.

Country Region Group

Field	Description
Code	The unique code of the country region group
Description	The description of the country region group

Country Region Group Detail

Field	Description
Country region group	The reference to the country region group
Country region	The reference to the country region

Geographic Regions

Geographic regions represent demographic regions rather than topographic regions, such as a low income area. Geographic regions are not directly connected to an address, but are accessible in dynamic logic through the 'inGeographicRegion' method. See the implementation guide for dynamic logic for details. Note that geographic regions and conditions are not available in the OHI Enterprise Policy Administration, Oracle Health Insurance Authorizations and [capComponent} applications.

Field	Description
Code	The unique code of the geographic region
Description	The description of the geographic region

Geographic Condition

A geographic region can have one more conditions attached to it. These conditions are tested against an address when calling the 'inGeographicRegion' method.

Field	Description
Geographic region	The geographic region that has the geographic condition
Dynamic logic condition	The condition (on a person’s address)
Start date	The first date that an address must qualify for this condition
End date	The last date that an address must qualify for this condition

Constraints:

• It is not allowed to have an overlap in time validity for geographic conditions for the same geographic region

Banks

A bank can be specified on a bank account number.

Field	Description
Code	The unique code of the bank
Name	The name of the bank
Bank identifier code	The BIC (Bank identifier Code) of the bank.
Bank routing number	The ABA Number or Bank Routing Number
IBAN bank code	The IBAN Bank Code
Active?	If unchecked, no new references can be made to this bank
Business phone number	The phone number
Private phone number	The private phone number
Mobile phone number	The mobile phone number
Fax number	The fax number
Email address 1	The email address
Email address 2	A second email address
Preferred language	Preferred language for correspondence with this bank
Language	Language for correspondence with this bank

Constraints:

• For bank identifier number, IBAN bank code and bank routing number:

  • bank identifier code and IBAN bank code are specified with bank routing number unspecified OR

  • bank routing number is specified with bank identifier code and IBAN bank code unspecified OR

  • bank identifier number, IBAN bank code and bank routing number are unspecified

• A specified e-mail address must comply with standards for specifying e-mail addresses

• The language of a relation needs to be an installed language

Bank Account Validations

A bank account number must specify a bank account validation. Such a validation is a check to which the account number needs to comply. For example, consider a validation where the bank account has nine or ten digits and must be dividable by eleven. Another example is the international IBAN-format.

Field	Description
Code	The unique code of the bank account validation
Description	The description of the bank account validation
Ind default	Is this bank account validation the default?
Ind debit number	Will there be a debit number?
Default debit number	The default debit number
Ind bank mandatory	Is it mandatory to specify a bank?
Ind direct debit	Is direct debit allowed?
Active?	If unchecked, this type is not available when creating or updating bank account numbers

Constraints:

• There should be one and only one default bank account validation and this should be an active one

• The default debit number is mandatory if the debit number indicator is true; it may not be specified if the debit number indicator is false

Tag Types and Messages

Tag types define the list of possible tags that can be used for tagging a relation. Note that tag types and tag type messages are not available in the OHI Enterprise Policy Administration, Oracle Health Insurance Authorizations and Oracle Health Insurance Value-Based Payments applications.

Field	Description
Code	The unique code of this tag type
Description	The description of this tag type
Active?	If unchecked, this type is not available when creating or updating relation tags

A tag type can specify one or more tag type messages.

Field	Description
Tag type	The tag type that has the tag type message
Message	The message associated with this tag type
Start date	The start date of the tag type message
End date	The end date of the tag type message

Constraints:

• It is not allowed to have an overlap in time validity for tag type messages for the same tag type

• It is not allowed to have a gap in time validity for tag type messages

Provider Assignment Types

Provider assignment types define the list of possible assignment types that an assigned provider of a person can have.

Field	Description
Code	The unique code of the provider assignment type
Description	The description of the provider assignment type

Identifiers Type

The identifier type defines the list of possible identifier types that a relation can have.

An identifier type has the following fields:

Field	Description
Code	The type of identifier
Display Name	The display name of the identifier
Access restriction	The access restriction restricting access to the identifiers.
Concealment expression	This field specifies a regular expression, that controls the concealment of restricted identifiers.

Constraints:

• A concealment expression can only be specified if access restriction is

Note that the following Covered Service Type, Waiver Reason and Person Covered Service are only available in the OHI Enterprise Policy Administration and OHI Claims Adjudication and Pricing applications.

Covered Service Tier

The product service tier differentiates between multiple wait times within the same service.

A product service tier has the following fields:

Field	Description
Code	The code of the covered service tier
Description	The description of the covered service tier
Ind Active	Is this covered service tier still in use?.

Waiver Reason

When waiving a waiting period a waiver reason indicates the reason for the waiver.

A waiver reason has the following fields:

Field	Description
Code	The code of the waiver reason
Description	The description of the waiver reason
Ind Active	Is this waiver reason still in use?
Message	Reference to the message that is attached to the person covered service when it is waived for this reason

Person Covered Service

The person covered service holds information to determine whether wait periods have been served and whether current coverage is better / worse than previous ones.

NOTE

Person covered services also support storing 'Transfer Certificates', that is enrollment information from other payers that can be used for serving a waiting period.
Specify a (no-enrollment, no-cover) product for that purpose and create the person covered services under that product. Set the Locked? indicator to true if these person covered services should be protected from removal when regenerating person covered services.

Field	Description
Person	The reference to the person
Product	The reference to the product
Service Option Service Code	The service option service code of the covered service
Covered Service Tier	The reference to the covered service tier
Covered Service Type	The type of the covered service (Limit or Parameter)
Wait Start Date	Earliest date as of when member has held this combination of service and type with the same or better level
Score	The numerical value of how good this covered service is
Ind Waived	Is the waiting period for this service waived?
Ind Blocked	Should this person covered serviced be protected from removal when regenerating person covered services?
Waiver Reason	The reference to the waiver reason
Start Date	The start date of the person covered service
End Date	The end date of the person covered service