Authorizations In Integration Point

The system facilitates through this synchronous integration point the creation of an authorization by an external system for example a portal. Through this integration point an external system can: * Create an authorization * Update an existing authorization

It is not possible to withdraw (delete) an authorization request through this integration point.

Request

Each request message may contain the details of one authorization. The external interfaces will create request messages for the initial data load, in response to entry of new authorizations and updates to previously sent authorizations. 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 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 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 Developer Guide.

This request enables an external system to save or save-and-submit an authorization. The URI that is used determines how the system processes the request. Use URI:

• /authorizations to save an authorization but not submit it yet.

• /authorizations/submit to save an authorization and immediately submit it.

Authorization

The system accepts the authorization request message in the following format:

<authorization
  code=""
  authorizationType=""
  formCode=""
  brandCode=""
  requesterRelationCode=""
  providerGroupScope=""
  serviceSpecialtyCode=""
  requesterAuthorizationReference=""
  currencyCode=""
  startDate=""
  endDate=""
  requestedRenewalReference=""
  requestedRenewalPeriodLength=""
  requestedRenewalPeriodUnitOfMeasure=""
  renewalReference=""
  renewalPeriodLength=""
  renewalPeriodUnitOfMeasure=""
  requestedNumberOfUnits=""
  requestedServiceDays=""
  authorizedNumberOfUnits=""
  authorizedServiceDays=""
  indOverrideCoverLimits=""
  internalRemarks=""
  dataAccessGroupCode=""
  unfinalizeReasonCode=""
>

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

All information in the authorization message is mapped and matched to the authorization data model and reference data. In the event that some piece of information cannot be matched to a record in the authorizations model the authorization will not be imported and a fatal message will be generated. An example is that the authorization type has to map to the allowed values for the authorization type. Another example is that the procedure code in the authorization line has to map to the code of a procedure configured in Oracle Health Insurance Authorizations.

The system does not support creating new reference information like providers, relations, insurable objects, procedures or diagnoses. The system only supports matching on codes. Matching relations for example on name and date of birth is not supported.

Dynamic fields and records can be added through the integration point as long as they are already configured in the setup.

Create and update authorizations

The authorization code drives whether an authorization is created or an existing authorization is updated. * If the authorization code does not exist then a new authorization with the provided authorization code is added to the system. * If the authorization code exists then the authorization details are updated as per the data provided in the request. * If the authorization code is empty, the authorization is considered a new authorization. A unique code is generated by the system using a dynamic logic function with the signature 'Authorization Code Generation'. If no dynamic logic function with the signature 'Authorization Code Generation' exists, id will be assigned to authorization Code.

The integration point does not offer the possibility to set the status of the authorization. A new authorization is by default created with the status Entry.

Whenever a new authorization is created or when the status of an authorization is changed, the system creates an authorization status history record.

• If an authorization with the status Entry or Change is updated, the status is not changed. No authorization status history is added.

• If an authorization with the status Approved or Denied is updated, a new version is created with status Change. The message must contain an unfinalize reason. If the message does not contain an unfinalize reason then a fatal error is raised and message AUT-IP-AUTI-015 is added.

• If an authorization with the status Change is updated, all authorization pend reasons are removed from the authorization. The authorization pend reason is not resolved, that is, the authorization pend history records are not updated. If a pend notification was sent out when the authorization pended, then the system also sends out a 'Pend Done' notification through Outbound Restful Service Invocation to the external system for the removed pends. On submit, the authorization is reprocessed.

• If an authorization with the status Pended is updated, its status is set to Change. All authorization pend reasons are removed from the authorization. The authorization pend reason is not resolved, that is, the authorization pend history records are not updated. If a pend notification was sent out when the authorization pended, then the system also sends out a 'Pend Done' notification through Outbound Restful Service Invocation to the external system for the removed pends. On submit, the authorization is reprocessed.

• If an authorization with the status In Process that has stopped with technical errors, is updated, then its status is set to Change. Any existing technical error tasks for this authorization are deleted. Updates for authorizations are handled as follows:

• 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. For example, suppose that the original authorization is for procedures A, B and C (specified on three different authorization lines). If the goal is to remove the authorization line for procedure C from the list of authorizations, then the message that represents the update should contain an authorization with two authorization lines (for procedure A and B).

Requester

The requester is the person or organization or provider requesting the authorization for services. Therefore only the requesterRelationCode or the <requesterProvider> element can exist.

Insurable Entity

The insurable entity type must exist as a supported insurable entity type for the insurance type of the form (authorization formCode) in the message (AUT-IP-AUTI-019).

If the insurable entity type is 'Person' then the insurable entity code must be an existing (relation of type) Person. If the insurable entity type is an object then the insurable entity code must be an existing object of that insurable object type (AUT-IP-AUTI-008).

Unfinalize Reason

The unfinalize reason of the authorization will be overwritten if an authorization is finalized / unfinalized multiple times. No history is kept of unfinalize reasons.

An unfinalize reason can only be added if the current status is Approved or Denied. When an unfinalize reason is added for an authorization in another status then the unfinalize reason is ignored. No message is raised for this situation.

Messages

Only non system specific messages can be linked to an authorization through the IP. If the import tries to send in a system specific message a fatal error is raised and message AUT-IP-AUTI-014 is added.

The indProcessing of the authorization message is by default set to No.

Whenever an authorization is updated through the IP, all the authorization messages are replaced by the ones that are in the message. As a consequence, authorization messages that were added by the system (authorization message with indicator processing set to 'Yes') will always be removed from the authorization.

Each <message> element may contain up to 10 values: attributes "value0" through "value9". These values 0 through 9 are used to populate the respective placeholders in the message text. In the event that no place holder exists for the specified value, the value is simply not used. In the event that no value is specified for a place holder, that placeholder remains empty.

Currency

A currency code can be sent in to denote that all amount fields (when specified) are given that currency. If a currency code is not provided for and one or more amount fields are sent in, then the default currency will be used. That way, it’s only necessary to send in a currency code when deviating from the default.

Authorization Line Code

When left blank the code will be generated using the Authorization Line Code Generation dynamic logic function or using the sequence of the line within the authorization if the code generation function is not configured.

Immediate Submit

If the /authorizations/submit URI is used, the authorization is submitted for processing immediately after completing the create or update. The create or update must be completed including all steps like the setting of the status, creating status history records and, if applicable, removing pend reasons, sending out 'Pend Done' notifications or adding unfinalize reasons before submitting the authorization for processing. If the create or update of an existing authorization was not successful the authorization will not be submitted for processing. See Submit Authorization for a detailed description of submitting an authorization for processing.

Response Messages

Response messages are created by the Oracle Health Insurance application in response to request messages received from external interfaces. Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.

Batches

This Integration Point does not support the handling of multiple requests ('File Based Import') in one go.

Error Messages

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

Table 1. Error Messages

Code	Severity	Message
AUT-IP-AUTI-001	Fatal	Authorization form code {code} is unknown
AUT-IP-AUTI-002	Fatal	Brand code {code} is unknown
AUT-IP-AUTI-003	Fatal	Service specialty code {code} is unknown
AUT-IP-AUTI-004	Fatal	Requester relation code {code} is unknown
AUT-IP-AUTI-005	Fatal	Requester provider with code {code} and flex code definition {code} is unknown
AUT-IP-AUTI-006	Fatal	Service provider with code {code} and flex code definition {code} is unknown
AUT-IP-AUTI-007	Fatal	Location provider with code {code} and flx code definition {code} is unknown
AUT-IP-AUTI-008	Fatal	Insurable entity {usageName} with code {code} is unknown
AUT-IP-AUTI-009	Fatal	Service type code {code} is unknown
AUT-IP-AUTI-010	Fatal	Procedure with code {code} and flex code definition {code} is unknown
AUT-IP-AUTI-011	Fatal	Diagnosis with code {code} and flex code definition {code} is unknown
AUT-IP-AUTI-012	Fatal	Unfinalize reason code {code} is unknown
AUT-IP-AUTI-013	Fatal	Message code {code} is unknown
AUT-IP-AUTI-014	Fatal	Only non system specific messages can be linked to an authorization
AUT-IP-AUTI-015	Fatal	An unfinalize reason is required when updating an authorization with status 'APPROVED' or 'DENIED'
AUT-IP-AUTI-016	Fatal	Data access group code {code} is unknown
AUT-IP-AUTI-017	Fatal	Currency code is unknown
AUT-IP-AUTI-019	Fatal	The insurable entity type {code} must exist as a supported insurable entity type for the insurance type {code} of the authorization {code}
AUT-IP-AUTI-022	Fatal	Procedure group code {code} is unknown
AUT-IP-AUTI-023	Fatal	Basket code {code} is unknown
AUT-IP-AUTI-024	Fatal	Authorizations in status {status} cannot be Denied
AUT-IP-AUTI-025	Fatal	Authorizations cannot be brought back to Change status from status {status}
AUT-IP-AUTI-026	FATAL	Authorizations in status {status} cannot be Unfinalized

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/IP Concepts part of the Developer Guide).