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