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 (mastered) outside of 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 'master' systems into Oracle Health Insurance through Relation Integration Point message calls. Thereafter, they could monitor the 'master' 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 sent (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.

Oracle Health Insurance stores the relation code with its copy of each relation. 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.

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 integration 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 integration guide.

Person

Person request messages have the following structure:

<person
  code=""
  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
      maritalStatusType=""
      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>
</person>

Organization

Organization request messages have the following structure:

<organization
  code=""
  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>
</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 integration 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 integration 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 integration 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 integration 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

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 integration guide).