Enrollment Callout

In this step Oracle Health Insurance Authorizations calls out for information directly related to the person’s or object’s policy enrollment status. Oracle Health Insurance Authorizations requires policy enrollment information to process an authorization. As Oracle Health Insurance Authorizations is not the system of record for policy enrollment data, a callout has to be made to an enrollment system to retrieve the required information. The purpose of this step is to retrieve the products on which the serviced person or object is enrolled; this information is further used by the subsequent steps for the benefit selection (through call outs to OHI Claims Adjudication and Pricing).

The Oracle Health Insurance Authorizations system communicates to the enrollment system though the Enrollment Request Integration Point (Integration Guide). The system initiates the callout only if there is no Authorization Message of severity 'Fatal' on the authorization that is being processed.

An enrollment request contains five attributes:

• The type of the insurable entity.
  For example PERSON or CAR

• The serviced person’s relation code or the serviced object’s object code

• The line of business code

• The start date of the period for which enrollment information is requested.
  This is the start date in the authorization request

• The end date of the period for which enrollment information is requested.
  This is the end date in the authorization request

The enrollment interface presumes that providing the combination of the insurable entity type, the person’s or object’s unique code and the line of business code will suffice in order to get a correct response.

In the event that request could not be sent out, or no response is received, or a technically erroneous response is received (for example the response XML cannot be parsed), the authorization automatically pends with a technical error. A technically pended authorization is accessible and can be re-processed in the "View Technical Errors" page once the interface has been restored.

The content of the response to enrollment request is validated. The following situations will result in a fatal message on the authorization:

• The product code is unknown.

• The message code is unknown.

• The currency code is unknown (through GEN-CURR-001).

• The dynamic field name, flex code definition or value (percentage, number of units, service days or amount in combination with currency) is unknown or not in line with configuration - these are taken care of by generic checks.

Messages

Code	Sev	Text
AUT-IP-ENRO-001	Fatal	Product code {code} is unknown
AUT-IP-ENRO-003	Fatal	Message code {code} is unknown

In addition, this integration point can return fatal messages in the context of ill defined dynamic field or dynamic record elements, for example the dynamic field name specified in the response does not match with a dynamic field usage on the AUT_POLICY_PRODUCTS table.

Storing Enrollment Data

The enrollment information is persisted in such a way that it is available until the authorization is brought back to status "Change" and submitted again for re-processing. In case of re-processing a new request for enrollment data is sent out and therefore, the previously obtained response is discarded.

The enrollment information is stored in the following entities:

Policy Product

Field	Description
Authorization	The authorization version that initiated the enrollment request
Product	The product for which the person or object is enrolled
Contract Date	First day of the person’s or object’s contract for this product
Start Date	First day of validity
End Date	Last day of validity

To determine the benefits for a person or object, Oracle Health Insurance Authorizations needs to know to what products that person or object is subscribed to. The response message contains the code for the product, which is expected to match a product code that is setup in Oracle Health Insurance Authorizations. In turn, Oracle Health Insurance Authorizations derives the applicable benefits for that product through call outs to {claimsComponnent} the callout rules needs to be configured in the system. For more details on rules configuration refer to Rules Configuration section in the guide ).

A person or object can have multiple products at any given point in time. The time validity of the product is specified by the Start Date and End Date attributes and is ideally bounded by the time period specified in the request message. The product information before and beyond the requested period is not stored in the system.

The Contract Date specifies the date on which the person’s or object’s subscription on that product started. This is the reference date which should be used to determine waiting times and limits that apply per contract year, rather than for example, per calendar year (specifically when interacting with OHI Claims Adjudication and Pricing through callouts)

Example: if the request message specified a period from 2015-01-01 to 2015-12-31 and that person’s enrollment contract started on 2014-05-01 (no end date specified), then the replied <product> would ideally contain startDate 2015-01-01, endDate 2015-12-31 and contract date 2014-05-01.

The entity "Policy Products", is extensible with dynamic fields and records. The response message can specify the values for the dynamic fields or records on this table.

Policy Product Parameter

The parameters that belong to a policy product are stored as follows:

Field	Description
Policy Product	The policy product
Alias Code	The alias code of the parameter
Percentage	The value (percentage) of the parameter
Number of Units	The value (number) of the parameter
Service Days	The value (service days) of the parameter
Amount	The value (amount) of the parameter
Currency	The currency code of the amount value

It is possible that the copayment, coinsurance and limit values come in through the enrollment response. These parameters are required to be applied to determine the level of benefits in a call out to OHI Claims; the value in the enrollment response must then be used.

If no currency is provided for an amount parameter, then the default currency is used.

Authorization Messages

Upon processing the response message, the messages returned in the enrollment response are attached to the authorization. Once the authorization is processed further, the attached message is taken into account, for example, it may lead to pends or even automatic denial.

A message in an enrollment response is meant to reflect something about the policy enrollment. The severity of the message is configured in Oracle Health Insurance Authorizations. Up to 10 parameters are supported per message. These 10 parameters are used to populate the respective placeholders in the actual message text.