Authorization Integration Point

To successfully process a claim that requires an authorization, Claims stores local copies of authorizations that are maintained outside of Claims. Claims keeps the local copies up to date by actively monitoring replication logs of the authorization source system(s) and requesting for additional information whenever needed. Response messages returned by the authorization source system(s) are then used by Claims to create or update its database.

Design principles

Creating and updating authorizations

In order for Claims to be able to recognize when an update to an authorization’s details is being sent (as opposed to the details of a new authorization) and to know which authorization in Claims is to be updated, the code is used. Based on the code, Claims detects whether a new authorization or an existing one is sent.

Authorization updates are not restricted. An authorization can be updated even if there has already been consumption based on it. For example, removing a line from an authorization is allowed even if there has been a counter, counter periods and consumptions related to the line (the counter, counter periods and consumptions are then also deleted).

The logic in this integration point that handles updates for authorizations is almost identical to the logic described in the 'Property Representation and Handling' section in the HTTP API/IP Concepts part of the Integration Guide. That means that:

Attributes that are not provided in the updated authorization message are not discarded when the existing authorization is updated.
Attributes that are provided in the updated authorization message are overwritten. It is possible to overwrite with an empty value, effectively removing an attribute of the authorization.
When updating a detail that is effectively part of a list of values, all values in the list have to be resent. The new values will replace the existing values, except for authorization lines and authorization baskets:
- It is not possible to simply replace the existing authorization lines and authorization baskets with the new lists, because authorization lines and baskets can have counters. So instead of replacing the entire list of details when an authorization is updated, the details in the request message are matched with the existing details on specific attributes (authorization lines on code / authorization baskets on basket code and start date). Existing details that match with details in the request are updated (only if there is a change), details in the request that do not match with existing details are inserted and existing details that do not match with details in the request are deleted.

Deleting Authorizations

This integration point does not support the physical removal of an authorization in Claims through the integration point.

Mapping Reference Data

This interface maps a number of codes unto the reference data in Claims. Examples are the provider code and the data access group code. In the event that one of these codes cannot be mapped, the authorization message is denied in its entirety. A fatal message explaining the cause of failure is added to the response message. As a consequence, it is not possible for an authorization to be imported with non-matched information.

The rationale behind this is that Claims will not process authorizations, nor provide support to create and edit authorizations through the user interface.

Message

Each request is for one single authorization. This Integration Point does not enable the handling of multiple requests ('File Based Import' ) in one go.

E.g. use the URI api/authorizations/{id} like "api/authorizations/1234". The id is the primary key reference of the authorization .

The payload has the following structure:

<authorization
  code=""
  authorizationType=""
  formCode=""
  brandCode=""
  requesterRelationCode=""
  providerGroupScope=""
  serviceSpecialtyCode=""
  requesterAuthorizationReference=""
  startDate=""
  endDate=""
  status=""
  renewalReference=""
  renewalPeriodLength=""
  renewalPeriodUnitOfMeasure=""
  authorizedNumberOfUnits=""
  authorizedServiceDays=""
  indOverrideCoverLimits=""
  internalRemarks=""
  dataAccessGroupCode=""
  transactionSourceCode=""
  referenceCode=""
>

  <authorizedAmount
    currency="" >
    {value}
  </authorizedAmount>
  <requesterProvider
    flexCodeDefinitionCode="">
    {value}
  </requesterProvider>
  <serviceProvider
    flexCodeDefinitionCode="">
    {value}
  </serviceProvider>
  <locationProvider
    flexCodeDefinitionCode="">
    {value}
  </locationProvider>
  <authorizationBasketList>
    <authorizationBasket
      code=""
      startDate=""
      endDate=""
    />
    ...
  </authorizationBasketList>
  <authorizationServiceTypeList>
    <authorizationServiceType
      code=""
    />
    ...
   </authorizationServiceTypeList>
   <authorizationLineList>
    <authorizationLine
      code=""
      startDate=""
      endDate=""
      procedureGroupCode=""
      renewalReference=""
      renewalPeriodLength=""
      renewalPeriodUnitOfMeasure=""
      authorizedNumberOfUnits=""
      authorizedServiceDays=""
    >
      <authorizedAmount
        currency="">
        {value}
      </authorizedAmount>
      <procedure
        flexCodeDefinitionCode="">
        {value}
      <procedure/>
    />
    ...
  </authorizationLineList>
  <authorizationDiagnosisList>
    <authorizationDiagnosis>
      <diagnosis
        flexCodeDefinitionCode="">
        {value}
      </diagnosis>
    </authorizationDiagnosis>
    ...
  <authorizationDiagnosisList/>
  <authorizationMessageList>
    <authorizationMessage
      code=""
      indInherit=""
      value0=""
      value1=""
      value2=""
      value3=""
      value4=""
      value5=""
      value6=""
      value7=""
      value8=""
      value9=""
    />
    ...
  </authorizationMessageList>
</authorizationRequest>

The allowed values for the authorization status are:

APPROVED
DENIED
VOIDED

If the authorization has a different status a fatal error is raised and a message is added.

The allowed values for the authorization type are:

AUTHORIZATION
NOTIFICATION
REFERRAL

If the authorization has a different type a fatal error is raised and a message is added

The allowed values for the provider group scope are:

E (Either)
I (In)
O (Out)

If the authorization has a different provider group scope a fatal error is raised and a message is added.

The requester is the person or organization or provider requesting the authorization for services. Therefore only the requesterRelationCode or the <requesterProvider> will be filled.

It is assured that when an amount is sent in (at either authorization level or authorization line level) without an accompanying currency code, that then the default currency code is taken automatically.

A given implementation of the Oracle Health Insurance application could have dynamic fields and records added to the authorization entity and its details 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 Oracle Health Insurance application, refer to the 'Property Representation and Handling' section in the HTTP API/IP Concepts part of the Integration Guide.

Error Messages

The following messages may be returned in the response:

Code	Severity	Message
CLA-IP-AUTI-001	Fatal	Authorization form {code} is unknown
CLA-IP-AUTI-002	Fatal	Brand code {code} is unknown
CLA-IP-AUTI-003	Fatal	Service specialty code {code} is unknown
CLA-IP-AUTI-004	Fatal	Requester relation code {code} is unknown
CLA-IP-AUTI-005	Fatal	Requester provider with code {code} and flex code definition {code} is unknown
CLA-IP-AUTI-006	Fatal	Service provider with code {code} and flex code definition {code} is unknown
CLA-IP-AUTI-007	Fatal	Location provider with code {code} and flex code definition {code} is unknown
CLA-IP-AUTI-008	Fatal	Insurable entity {usageName} with code {code} is unknown
CLA-IP-AUTI-009	Fatal	Service type code {code} is unknown
CLA-IP-AUTI-010	Fatal	Procedure with code {code} and flex code definition {code} is unknown
CLA-IP-AUTI-011	Fatal	Diagnosis with code{code} and flex code definition {code} is unknown
CLA-IP-AUTI-012	Fatal	Message code {code} is unknown
CLA-IP-AUTI-013	Fatal	Data access group code {code} is unknown
CLA-IP-AUTI-014	Fatal	All amounts on an authorization must be in the same currency
CLA-IP-AUTI-015	Fatal	Insurable entity type code \{code) is unknown for the line of business {code} of authorization form {code}
CLA-IP-AUTI-016	Fatal	Procedure group code {code} is unknown
CLA-IP-AUTI-017	Fatal	Basket code {code} is unknown

Code

Severity

Message

CLA-IP-AUTI-001

Fatal

Authorization form {code} is unknown

CLA-IP-AUTI-002

Fatal

Brand code {code} is unknown

CLA-IP-AUTI-003

Fatal

Service specialty code {code} is unknown

CLA-IP-AUTI-004

Fatal

Requester relation code {code} is unknown

CLA-IP-AUTI-005

Fatal

Requester provider with code {code} and flex code definition {code} is unknown

CLA-IP-AUTI-006

Fatal

Service provider with code {code} and flex code definition {code} is unknown

CLA-IP-AUTI-007

Fatal

Location provider with code {code} and flex code definition {code} is unknown

CLA-IP-AUTI-008

Fatal

Insurable entity {usageName} with code {code} is unknown

CLA-IP-AUTI-009

Fatal

Service type code {code} is unknown

CLA-IP-AUTI-010

Fatal

Procedure with code {code} and flex code definition {code} is unknown

CLA-IP-AUTI-011

Fatal

Diagnosis with code{code} and flex code definition {code} is unknown

CLA-IP-AUTI-012

Fatal

Message code {code} is unknown

CLA-IP-AUTI-013

Fatal

Data access group code {code} is unknown

CLA-IP-AUTI-014

Fatal

All amounts on an authorization must be in the same currency

CLA-IP-AUTI-015

Fatal

Insurable entity type code \{code) is unknown for the line of business {code} of authorization form {code}

CLA-IP-AUTI-016

Fatal

Procedure group code {code} is unknown

CLA-IP-AUTI-017

Fatal

Basket code {code} is unknown

In addition, functional business rule messages may be returned as well as the standard messages related to dynamic fields and records (refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book).