Authorization Integration Point
To successfully process a claim that requires an authorization, OHI Claims stores local copies of authorizations that are maintained outside of OHI Claims. OHI 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 OHI Claims to create or update its database.
Creating and updating authorizations
In order for OHI 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 OHI Claims is to be updated, the code is used. Based on the code, OHI 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 OHI Claims through the integration point.
Mapping Reference Data
This interface maps a number of codes unto the reference data in OHI Claims. Examples are the provider code & 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 OHI 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 OHI 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 OHI 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 |
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).