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 Developer Guide.
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 Mailing) |
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 example, States and Departments) |
County |
Name of the county where the address is located |
State and County Code |
State and county code of the address |
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
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
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
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 Claims 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
|
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
Marital Statuses
A person can have one and only one marital status at any given point in time. Note that marital statuses are not available in the Oracle Health Insurance Authorizations and Oracle Health Insurance Value-Based Payments applications. A marital status has the following fields:
Field | Description |
---|---|
Person |
The person that has the marital status |
Type |
The reference to a marital status type |
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
Organizations
In the Oracle Health Insurance 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.
Person Covered Services
The person covered service holds information to determine whether wait periods have been served and whether current coverage is better / worse than previous ones.
Person covered services also support storing 'Transfer Certificates', that is enrollment information from other payers that can be used for serving a waiting period. |
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 |
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 |
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 |
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:
|
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 "User Access Restrictions Model" chapter of the Security Guide for more details) |
Access restriction |
The access restriction restricting access to the person (see the "User Access Restrictions Model" chapter of the Security Guide 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
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 enabled? |
Relation Links
Persons and organization can have links to other persons and organizations. Relation links store these relationships.
A relation link has the following fields:
Field | Description |
---|---|
Relation |
The person or organization that is linked to another relation |
Relation link type |
The type of relation link, like PARENT_CHILD |
Linked relation |
The relation that is the subject of the link |
Link direction |
The direction of the link Possible Values:
|
Enabled? |
Is the relation link enabled? |
Relation links are always created in pairs. So whenever a relation link is created from relation A to relation B, the system creates the corresponding relation link from relation B to relation A automatically. Also, when a relation link is deleted or disabled, the corresponding relation link is deleted or disabled as well.
When the relation link has a link type where auto disable is checked, the system disables existing relation links for the same relation and relation link type. For example when a relation link type of 'Legal representative' is configured as auto disable and a new 'Legal representative' link is created for a relation, the existing 'Legal representative' relation links for that relation are disabled.
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 Policies, 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 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.
Address Type
An address type specifies the purpose of an address.
Field | Description |
---|---|
Code |
Unique identifier for an address type |
Ind default |
Is this the default address type? |
Display name |
Description of the address type |
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
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
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.
Field | Description |
---|---|
Code |
The unique code of the country. |
Name |
The standard name of the country. |
Ind Upper Street |
Should a street in this country display in uppercase? |
Ind Upper City |
Should a city in this country display in uppercase? |
Ind Upper Nr Addition |
Should a number addition in this country display in uppercase? |
Integer Format |
The format of standard integers (including thousand separator) in the UI |
Ind Upper Additional Part 1 |
Should the first additional part in this country display in uppercase? |
Ind Upper Additional Part 2 |
Should the second additional part in this country display in uppercase? |
Ind Upper Additional Part 3 |
Should the third additional part in this country display in uppercase? |
Ind default |
Is this country the default? |
Ind Active |
If unchecked, this type is not available when creating or updating addresses. |
Primary Date Format |
The format for a date field. |
Secondary Date Format |
The shorthand format for a date field. |
Ind Upper Region |
Should a region in this country display in uppercase? |
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.
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.
Field | Description |
---|---|
Code |
The unique code of the country region group |
Description |
The description of the country region group |
Field | Description |
---|---|
Country region group |
The reference to the country region group |
Country region |
The reference to the country region |
Covered Service Tiers
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?. |
Gender Identities
Gender identity represents the gender of an individual.
Field | Description |
---|---|
Display Name |
Display name for a gender identity |
CODE |
Unique identifier for a gender identity |
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 Policies, Oracle Health Insurance Authorizations and Oracle Health Insurance Value-Based Payments 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
Identifier Types
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 |
Unique? |
Are identifier of this type unique across relations? |
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 an access restriction is defined on the identifier type.
-
An identifier type cannot be set to unique when identifiers exist.
-
A concealment expression must be a valid regular expression.
Type | Entities | Description | Message |
---|---|---|---|
Validation |
Identifier Type |
An identifier type cannot be set to unique when identifiers exist for the identifier type |
An identifier type cannot be set to unique when identifiers exist |
Note that the following Covered Service Type, Waiver Reason and Person Covered Service are only available in Policies and Claims applications. |
Marital Status Types
Marital Status Types define the list of possible marital statuses that a relation can have. Marital status types, like marital statuses are not available in the Oracle Health Insurance Authorizations and Oracle Health Insurance Value-Based Payments applications. A marital status type has the following fields:
Field | Description |
---|---|
Code |
The code of the marital status type |
Descr |
The description of the marital status type |
Active? |
Is this marital status type still in use? |
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.
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 |
Relation Link Types
Relation Link Types define the list of possible link types that a relation can have.
A relation link type has the following fields:
Field | Description |
---|---|
Code |
The code of the relation link type |
Descr |
The description of the relation link type |
Forward link name |
The name of a forward link. E.g. Parent of |
Backward link name |
The name of a backward link. E.g. Child of |
Auto Disable? |
Is the relation link disabled automatically when a new relation link is created for the relation of the same relation link type? |
Duplicate? |
Is the relation link type configured to register duplicate relations? |
Active? |
Is the relation link type active for use in new relation links? |
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 Policies, 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
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.
Waiver Reasons
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 |