Provider Integration Point

This chapter describes the Provider Integration Point messages and how they are used by external interfaces to initially load provider data copies into the OHI application and to keep the copies up-to-date.

Design Principles

The OHI application requires details of providers that may be maintained (mastered) outside of the OHI application. Where this is the case, the OHI application needs to store an up-to-date copy of these providers. This copy in the OHI application is maintained by external (not part of the OHI application) interfaces using Provider Integration Point messages. The external interfaces will initially load details of all required providers from the 'master' systems into the OHI application through Provider Integration Point message calls. Thereafter, they could monitor the 'master' system(s) for updates and new providers and make message calls to provide the OHI application with updated details and to add new providers.

External interfaces determine when request messages are sent and what they contain. Each request message will contain one of the following:

Individual provider details
Organization provider details

Provider Matching

In order for the OHI application to be able to recognize when an update to a provider’s details is being sent (as opposed to the details of a new provider) and to know which provider in the OHI application is to be updated, provider code in combination with its flex code definition is used. Provider codes are unique within a given provider flex code definition. If the provider code is not included in the message, the system will generate a code using the signature 'Provider Code Generation' for that provider. If no dynamic logic function with the signature 'Provider Code Generation' exists, id will be assigned to provide code. The provider flex code definition must be included in each message.

The OHI application stores the provider code and its definition with its copy of each provider. When the details of a provider are received in a message, the OHI application will consider the details to be a new provider if there is not already a provider stored with the same provider code / definition combination and it will consider the details to be an update to an existing provider if there is one with the same combination.

Provider code / definition combinations are assumed to be unique across all providers within the OHI application regardless of the source of the provider.

Request Messages

Each request message may contain the details of one provider (individual or organization). The external interfaces will create request messages for the initial data load and in response to entry and update of providers. 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 the OHI application could have dynamic fields and dynamic records added to the provider 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 the OHI application, refer to the 'Property Representation and Handling' section in the HTTP API/IP Concepts part of the integration guide.

Individual Provider

Individual provider request messages have the following structure:

  <providerIdentifierList>
    <providerIdentifier
      identifierTypeCode=""
      identifier=""
      enabled=""     />
  </providerIdentifierList>
  <providerTitleList>
    <providerTitle
      titleCode=""
    />
  </providerTitleList>
  <renderingAddressList>
    <renderingAddress
      startDate=""
      endDate=""
    >
      <serviceAddress
        street=""
        houseNumber=""
        numberAddition=""
        additionalPart1=""
        additionalPart2=""
        additionalPart3=""
        city=""
        postalCode=""
        countryRegionCode=""
        countryCode=""
      />
    </renderingAddress>
  </renderingAddressList>
  <providerSpecialtyList>
    <providerSpecialty
      specialtyCode=""
      startDate=""
      endDate=""
    />
  </providerSpecialtyList>
  <providerGroupAffiliationList>
    <providerGroupAffiliation
      providerGroupCode=""
      startDate=""
      endDate=""
    />
  </providerGroupAffiliationList>
  <bankAccount
    relationCode=""
    bankCode=""
    bankAccountNumber=""
  />

Provider Group Affiliations

Provider group affiliations are handled as time valid details of the individual provider. This means that all provider group affiliations of that individual provider (in all provider groups) are replaced by the new list of provider group affiliations (if specified).

Addresses

Rendering addresses are handled as time valid details. Upon insert a new service address (with the same start and end date as the rendering address) and a new rendering address with a reference to the new service address are created. If an update to an individual provider results in the deletion of a rendering address, the related service address is deleted if it has no reference to an organization provider and if it is not referenced by any other rendering address.

Organization Provider

Organization provider request messages have the following structure:

<organizationProvider
  code=""
  flexCodeDefinitionCode=""
  name=""
  phoneNumberBusiness=""
  phoneNumberMobile=""
  phoneNumberPrivate=""
  emailAddress1=""
  emailAddress2=""
  faxNumber=""
  outputLanguageCode=""
  preferredLanguageCode=""
  startDate=""
  endDate=""
>
  <providerIdentifierList>
    <providerIdentifier
      identifierTypeCode=""
      identifier=""
      enabled=""     />
  </providerIdentifierList>
    <parentOrganizationProvider
    code=""
    flexCodeDefinitionCode=""
  />
  <serviceAddressList>
    <serviceAddress
      street=""
      houseNumber=""
      numberAddition=""
      additionalPart1=""
      additionalPart2=""
      additionalPart3=""
      city=""
      postalCode=""
      countryRegionCode=""
      countryCode=""
      startDate=""
      endDate=""
    >
      <renderingAddressList>
        <renderingAddress
          startDate=""
          endDate=""
        >

        </renderingAddress>
      </renderingAddressList>
    </serviceAddress>
  </serviceAddressList>
  <providerSpecialtyList>
    <providerSpecialty
      specialtyCode=""
      startDate=""
      endDate=""
    />
  </providerSpecialtyList>
  <providerGroupAffiliationList>
    <providerGroupAffiliation
      providerGroupCode=""
      startDate=""
      endDate=""
    />
  </providerGroupAffiliationList>
  <bankAccount
    relationCode=""
    bankCode=""
    bankAccountNumber=""
  />
</organizationProvider>

Provider Group Affiliations

Provider group affiliations are handled as time valid details of the organization provider. This means that all provider group affiliations of that organization provider (in all provider groups) are replaced by the new list of provider group affiliations (if specified).

Addresses

Service addresses are handled as time valid details. Upon insert a new service address and new rendering addresses related to that service address (if specified) are created. If an update to an organization provider results in the deletion of a service address, the related rendering addresses are also deleted.

Response Messages

Response messages are created by the OHI application 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.

Individual Provider

Individual provider batch request messages have the following structure:

   -- refer to Individual Provider Request for details

Individual provider batch response messages have the following structure:

  <resultMessages/>

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 and the flex code definition code (separated by a space; for example elementId="1234567890 US_PROVIDER") of the individual provider for which the messages are raised.

Organization Provider

Organization provider batch request messages have the following structure:

<organizationProviders>
  <organizationProvider/> -- refer to Organization Provider Request for details
</organizationProviders>

Organization provider batch response messages have the following structure:

<organizationProvidersResponse>
  <resultMessages/>
</organizationProvidersResponse>

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 and the flex code definition code (separated by a space; for example elementId="1234567890 US_PROVIDER") of the organization provider for which the messages are raised.

Error Messages

The following error messages that are specific to the provider interface may be returned in the response messages:

Code	Severity	Response	Message
REL-IP-PROV-003	Fatal	Org	Parent organization provider identified by code {code} and flex code definition code {code} is unknown
REL-IP-PROV-004	Fatal	Ind and Org	Bank account number {bank account number} is unknown
REL-IP-PROV-005	Fatal	Ind and Org	Provider bank account number matching returned more than one bank for bank account number {bank account number}
REL-IP-PROV-014	Fatal	Ind and Org	Flex code definition code {code} is unknown
REL-IP-PROV-015	Fatal	Ind and Org	Provider group code {code} is unknown
REL-IP-PROV-016	Fatal	Ind and Org	Specialty code {code} is unknown
REL-IP-PROV-027	Fatal	Ind	Title code {code} is unknown
REL-IP-PROV-028	Fatal	Ind	Prefix code {code} is unknown
REL-IP-PROV-029	Fatal	Ind	Name format code {code} is unknown
REL-IP-PROV-030	Fatal	Ind and Org	Language code {code} is unknown
REL-IP-PROV-031	Fatal	Ind and Org	Country code {code} is unknown
REL-IP-PROV-032	Fatal	Ind and Org	Country region code {code} is unknown
REL-IP-PROV-033	Fatal	Org	Individual provider identified by code {code} and flex code definition code {code} for rendering address is unknown
REL-IP-PROV-035	Fatal	Ind and Org	Identifier type code {code} is unknown

Code

Severity

Response

Message

REL-IP-PROV-003

Fatal

Org

Parent organization provider identified by code {code} and flex code definition code {code} is unknown

REL-IP-PROV-004

Fatal

Ind and Org

Bank account number {bank account number} is unknown

REL-IP-PROV-005

Fatal

Ind and Org

Provider bank account number matching returned more than one bank for bank account number {bank account number}

REL-IP-PROV-014

Fatal

Ind and Org

Flex code definition code {code} is unknown

REL-IP-PROV-015

Fatal

Ind and Org

Provider group code {code} is unknown

REL-IP-PROV-016

Fatal

Ind and Org

Specialty code {code} is unknown

REL-IP-PROV-027

Fatal

Ind

Title code {code} is unknown

REL-IP-PROV-028

Fatal

Ind

Prefix code {code} is unknown

REL-IP-PROV-029

Fatal

Ind

Name format code {code} is unknown

REL-IP-PROV-030

Fatal

Ind and Org

Language code {code} is unknown

REL-IP-PROV-031

Fatal

Ind and Org

Country code {code} is unknown

REL-IP-PROV-032

Fatal

Ind and Org

Country region code {code} is unknown

REL-IP-PROV-033

Fatal

Org

Individual provider identified by code {code} and flex code definition code {code} for rendering address is unknown

REL-IP-PROV-035

Fatal

Ind and Org

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