Quote Integration Point

The system provides through this synchronous integration point premium quotes to external systems, for example portals. To be able to provide a premium quote, a request containing the policy and the related persons/objects has to be sent in. After the premium has been calculated, a response containing the calculation results is returned.

Besides the request payload, a calculation input date path parameter (in format YYYY-MM-DD) must be provided. This date is used to select the contract period or calculation period for which the premium calculation has to be run. The path looks like this:

http://<host>:<port>/<contextRoot>/policies/quote/{calculationInputDate}

Query parameter "billingCycle" can be provided to influence the settings of the calculation date and pay date of the policy calculation period. For more details on billing cycle refer to policy calculation period generation process.

Parameter	Description
billingCycle	I - Immediate Billing
	F- Forward Billing

It is also possible to fetch up to 5 calculation result dynamic fields in the response by using accept header parameter "fields". This parameter takes the dynamic field usagenames separated by '|'.

For example: To get dynamicfieldusgae1 and dynamicfieldusage2 in the response, the accept header must be set as application/json;fields=dynamicfieldusgae1|dynamicfieldusage2.

Request Payload

The request payload has the same structure as the request payload of the Policy In Integration Point. The policy in the request is handled as a virtual new policy, so the policy and the persons/objects that are specified in the request are not stored nor are existing policies, persons and objects updated. Note that if a policy code is specified in the request, it must be unique (that is, it must not match the code of any existing policy).

Response Payload

System first triggers generation of policy calculation periods. If a policy contract period exists for the policy in context that includes the specified input date the policy calculation periods are generated with generate up-to date set to the specified input date and with the look back date set to the contract period start date. The system continues to generate periods including the contract end date.

If there is no policy contract, then the system generates periods up-to the specified input date, with the look back date set to the input date. Refer chapter generate policy periods in the premium calculation guide for details.

The billing cycle is set as specified in the request.

The calculation periods that are to be calculated are selected based on the specified calculation input date:

If a policy contract period exists for the policy in context that includes the specified input date then all calculation periods (system and policy) that overlap with that policy contract period are selected and single calculation period time line is created. Note policy calculation periods have higher priority over system calculation period. If there is a policy calculation period that overlaps with the selected system period, then the system period is removed from the selection

If there is no policy contract, system selects policy calculation period that includes the input date. It then selects all the policy calculation periods having calculation date same as the calculation date of the selected policy calculation period. If no policy calculation period is found then the calculation period that includes the specified input date is selected.

After the calculation periods are selected, premium is calculated for all selected periods (this is described in detail in the Implementation Guide for Premium Calculation) and the results are returned in a response. Note that the calculation results are not stored nor are financial transactions created. The response payload containing the calculation results looks like this:

{
  "calculationResultSetTotalBasePremium": {
    "value": "",
    "currency": ""
  },
  "calculationResultSetTotalAdjustment": {
    "value": "",
    "currency": ""
  },
  "calculationResultSetTotalSurcharge": {
    "value": "",
    "currency": ""
  },
  "calculationResultSetTotalResult": {
    "value": "",
    "currency": ""
  },
  "calculationResultList": [
    {
      "calculationPeriod: {
        "startDate": "",
        "endDate": "",
        "displayName": ""
      },
      "calculationDate":"",
      "referenceDate":"",
      "policyContractStartDate: "",
      "groupAccount: {
        "code": "",
        "displayName: ""
      },
      "totalBasePremium": {
        "value": "",
        "currency": ""
      },
      "totalAdjustment": {
        "value": "",
        "currency": ""
      },
      "totalSurcharge": {
        "value": "",
        "currency": ""
      },
      "totalResult": {
        "value": "",
        "currency": ""
      },
      "calculationResultLineList": [
        {
          "sequence": "",
          "referencedCalculationResultLine": {
            "sequence": ""
          },
          "policyEnrollmentProduct": {
            "policyEnrollment": {
              "": {
                "code": "",
                "descr": "",
                "name: "",
                "firstName": "",
                "dateOfBirth": "",
                "entityDate": ""
              }
            },
            "enrollmentProduct": {
              "code": "",
              "displayName": ""
            }
          },
          "scheduleDefinition": {
            "code": "",
            "type": "",
            "surchargeRuleEvaluation": ""
          },
          "premiumSchedule": {
            "code": ""
          },
          "addOn": {
            "code": "",
            "displayName: ""
          },
          "resultAmount": {
            "value": "",
            "currency": ""
          },
          "retrievedAmount": {
                "currency": "",
                "value":
          },
          "percentage":""
        }
      ]
    }
  ]
}

Note, that a given implementation of the Oracle Health Insurance application could have dynamic fields added to the calculation result. The system returns dynamic fields that are specified in the accept header (see Request). For details on how external interfaces can access the values for dynamic fields 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.

Response Messages

This integration point will provide HTTP status codes as defined in Response Messages. If an error occurs, the appropriate HTTP status code is returned and a notification is sent containing error details. This way, the request can be sent again after the reason for failure has been fixed.

The same checks as in the Policy In Integration Point are performed, so the same error messages (policies interface messages, relation interface messages, functional business rule messages and standard messages related to dynamic fields and dynamic records) can be returned by this integration point. For example if the group account code is unknown error message POL-IP-POLI-003 is returned or if the country code is unknown error message REL-IP-RELA-009 is returned. Besides, any error encountered in policy calculation period generation and premium calculation process may also be returned by this integration point.

Besides the above mentioned errors messages, the following integration point specific error message can be returned:

Code	Severity	Message Text
POL-HTTP-005	Fatal	No calculation periods could be selected based on the specified calculation input date
POL-HTTP-019	Fatal	No more than 5 dynamic fields can be requested