Relations Integration Point
This chapter describes the Relation Integration Point messages and how they are used by external interfaces to initially load relation data copies into Oracle Health Insurance and to keep the copies up-to-date.
Design Principles
Oracle Health Insurance requires relation details of members that may be maintained (primary) outside Oracle Health Insurance. Where this is the case, Oracle Health Insurance needs to store an up-to-date copy of these relations. This copy in Oracle Health Insurance is maintained by external (not part of Oracle Health Insurance) interfaces using Relation Integration Point message. The external interfaces will initially load details of all required relations from the 'primary' systems into Oracle Health Insurance through Relation Integration Point message calls. Thereafter, they could monitor the 'primary' system(s) for updates and new relations and make message calls to provide Oracle Health Insurance with updated details and to add new relations.
External interfaces determine when request messages are sent and what they contain. Each request message will contain one of the following:
-
Person details
-
Organization details
Note that this integration point does not support relations of subtype bank.
Relation Matching
In order for Oracle Health Insurance to be able to recognize when an update to a relation’s details (person or organization) is being send (as opposed to the details of a new relation) and to know which relation in Oracle Health Insurance is to be updated, the relation code is used, in combination with the identifier type.
Oracle Health Insurance stores the relation code with its copy of each relation, as well as a list of relation identifiers. When the details of a relation are received in a message, Oracle Health Insurance will consider the details to be a new relation if there is not already a relation stored with the same relation code, and it will consider the details to be an update to an existing relation if there is one with the same relation code or identifier.
If the relation could not be matched to an existing person or organization and an identifier type is send in along with the code, the system generates a new OHI relation code and stores the code from the request as an identifier of the specified identifier type.
If the relation code is empty, the relation is considered a new relation. A unique code is generated by the system using a dynamic logic function with the signature 'Person Code Generation' or 'Organization Code Generation' (depending on a person, or an organization being send in). If no dynamic logic function with the correct signature exists, the code is set to the id.
The signatures 'Person Code Generation' and 'Organization Code Generation' are only available in the Oracle Health Insurance that are the system of record for relation data. |
Relation codes are assumed to be unique across all relations within Oracle Health Insurance regardless of the source of the relation.
Request Messages
Each request message may contain the details of one relation (person or organization). The external interfaces will create request messages for the initial data load, in response to entry of new relations and updates to previously sent relations. The details of exactly what information needs to be in a given request message varies based on factors such as whether details have been sent before and the category of details that have been added or updated.For details on how values in the request messages are handled, refer to the "Property Representation and Handling" section in the HTTP API/IP Concepts part of the Developer Guide.
A given implementation of Oracle Health Insurance could have dynamic fields and dynamic records added to the relation entity that need to be interfaced. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by Oracle Health Insurance, refer to the "Property Representation and Handling" section in the HTTP API/IP Concepts part of the Developer Guide.
Person
Person request messages have the following structure:
<person code="" identifierTypeCode="" name="" initials="" firstName="" gender="" genderIdentificationCode="" prefixCode="" suffix="" middleName="" nameFormatCode="" dateOfBirth="" dobInterpretation="" namePartner="" partnerPrefixCode="" phoneNumberBusiness="" phoneNumberMobile="" phoneNumberPrivate="" emailAddress1="" emailAddress2="" faxNumber="" outputLanguageCode="" preferredLanguageCode="" endDate="" accessRestrictionCode="" contactDetailsAccessRestrictionCode="" > <relationIdentifierList> <relationIdentifier identifierTypeCode="" identifier="" enabled="" /> </relationIdentifierList> <maritalStatusList> <maritalStatus maritalStatusTypeCode="" startDate="" endDate="" /> </maritalStatusList> <personTitleList> <personTitle titleCode="" /> </personTitleList> <addressList> <address addressTypeCode="" street="" houseNumber="" numberAddition="" additionalPart1="" additionalPart2="" additionalPart3="" city="" postalCode="" countryRegionCode="" countryCode="" startDate="" endDate="" accessRestrictionCode="" /> </addressList> <bankAccounts> <bankAccount bankAccountNumber="" bankAccountNumberDebit="" bankCode="" bankAccountValidationCode="" specialName="" indPreferred="" startDate="" endDate="" /> </bankAccounts> <relationTagList> <relationTag tagTypeCode="" startDate="" endDate="" /> </relationTagList> <assignedProviderList> <assignedProvider providerAssignmentTypeCode="" startDate="" endDate="" > <provider code="" flexCodeDefinitionCode="" /> </assignedProvider> </assignedProviderList> <personCoveredServiceList> <personCoveredService productCode="" serviceOptionServiceCode="" coveredServiceTierCode="" coveredServiceType="" score="" startDate="" endDate="" waitStartDate="" indWaiver="" waiverReason="" /> </personCoveredServiceList> <contractAlignmentList> <contractAlignment capitationContractCode="" startDate="" endDate="" /> </contractAlignmentList> <relationLobAccessRestrictionList> <relationLobAccessRestriction accessRestrictionCode="" /> </relationLobAccessRestrictionList> </person>
Organization
Organization request messages have the following structure:
<organization code="" identifierTypeCode="" name="" phoneNumberBusiness="" phoneNumberMobile="" phoneNumberPrivate="" emailAddress1="" emailAddress2="" faxNumber="" outputLanguageCode="" preferredLanguageCode="" endDate="" > <relationIdentifierList> <relationIdentifier identifierTypeCode="" identifier="" enabled="" /> </relationIdentifierList> <addressList> <address addressTypeCode="" street="" houseNumber="" numberAddition="" additionalPart1="" additionalPart2="" additionalPart3="" city="" postalCode="" countryRegionCode="" countryCode="" startDate="" endDate="" /> </addressList> <bankAccounts> <bankAccount bankAccountNumber="" bankAccountNumberDebit="" bankCode="" bankAccountValidationCode="" specialName="" indPreferred="" startDate="" endDate="" /> </bankAccounts> <relationTagList> <relationTag tagTypeCode="" startDate="" endDate="" /> </relationTagList> <relationLobAccessRestrictionList> <relationLobAccessRestriction accessRestrictionCode="" /> </organization>
Response Messages
Response messages are created by Oracle Health Insurance in response to request messages received from external interfaces. Please refer to the "Response Messages" section in the HTTP API/IP Concepts part of the Developer Guide for more details.
Batches
Batch requests enable the handling of multiple requests in one go. Because the volume of data can become quite extensive, these are file based requests. Please refer to the "File Based Import" section in the HTTP API Integration Points part of the Developer Guide for more details.
Person
Person batch request messages have the following structure:
<persons> <person/> -- refer to Person Request for details </persons>
Person batch response messages have the following structure:
<personsResponse> <resultMessages/> </personsResponse>
The elementId attribute that is included as part of the result messages element (refer to the "Activity Integration Point" section in the HTTP API Integration Points part of the Developer Guide for more details) contains the code of the person for which the messages are raised.
Organization
Organization batch request messages have the following structure:
<organizations> <organization/> -- refer to Organization Request for details </organizations>
Organization batch response messages have the following structure:
<organizationsResponse> <resultMessages/> </organizationsResponse>
The elementId attribute that is included as part of the result messages element (refer to the "Activity Integration Point" section in the HTTP API Integration Points part of the Developer Guide for more details) contains the code of the organization for which the messages are raised.
Error Messages
The following error messages that are specific to the relation interface may be returned in the response messages:
Code | Severity | Response | Message |
---|---|---|---|
REL-IP-RELA-004 |
Fatal |
Prs |
Title code {code} is unknown |
REL-IP-RELA-005 |
Fatal |
Prs |
Tag type code {code} is unknown |
REL-IP-RELA-006 |
Fatal |
Prs |
Prefix code {code} is unknown |
REL-IP-RELA-007 |
Fatal |
Prs |
Name format code {code} is unknown |
REL-IP-RELA-008 |
Fatal |
Prs and Org |
Language code {code} is unknown |
REL-IP-RELA-009 |
Fatal |
Prs and Org |
Country code {code} is unknown |
REL-IP-RELA-010 |
Fatal |
Prs and Org |
Bank code {code} is unknown |
REL-IP-RELA-011 |
Fatal |
Prs and Org |
Bank account validation code {code} is unknown |
REL-IP-RELA-012 |
Fatal |
Prs and Org |
Country region code {code} is unknown |
REL-IP-RELA-015 |
Fatal |
Prs |
Provider identified by code {code} and flex code definition code {code} is unknown |
REL-IP-RELA-016 |
Fatal |
Prs |
Provider assignment type code {code} is unknown |
REL-IP-RELA-017 |
Fatal |
Prs |
Capitation contract code {code} is unknown |
REL-IP-RELA-018 |
Fatal |
Prs and Org |
Identifier type code {code} is unknown |
REL-IP-RELA-019 |
Fatal |
Prs and Org |
Address type code {code} is unknown |
REL-IP-RELA-020 |
Fatal |
Prs |
Gender identification code {code} is unknown |
REL-IP-RELA-021 |
Fatal |
Prs |
Waiver reason code {code} is unknown |
REL-IP-RELA-022 |
Fatal |
Prs |
Product code {code} is unknown |
REL-IP-RELA-023 |
Fatal |
Prs |
Covered service tier code {code} is unknown |
REL-IP-RELA-024 |
Fatal |
Prs |
There are pending changes to this person, updates not allowed [1] |
REL-IP-RELA-025 |
Fatal |
Prs |
Marital Status Type Code {code} is unknown |
In addition, functional business rule messages may be returned as well as the standard messages related to dynamic fields and dynamic records (refer to the "Response Messages" section in the HTTP API/IP Concepts part of the Developer Guide).