Quote Integration Point
The system provides Premium quotes to external systems through this synchronous integration point, for example, portals. It is important to send a request that contains the Policy and the related Persons or Objects to provide a Premium quote. It returns a response containing the calculation results after Premium calculation.
Besides the request payload, it is essential to provide a Calculation Input Date path as a parameter (in format YYYY-MM-DD). This date is useful for selecting the Contract Period or Calculation Period for running the Premium Calculation. The path looks like this:
http://<host>:<port>/<contextRoot>/policies/quote/{calculationInputDate}
Provide a query parameter billingCycle
to influence the settings of the Calculation Date and Pay Date of the Policy Calculation Period.
Refer to the "Policy Calculation Period Generation" section in the Operations Guide for more details on the billing cycle.
Parameter | Description |
---|---|
billingCycle |
I - Immediate Billing |
F- Forward Billing |
It is also possible to fetch up to five calculation result dynamic fields in the response by using fields
accept header parameter. This parameter takes the dynamic field usagenames
with a |
symbol separating each value.
For example, setting Accept header as application/json;fields=dynamicfieldusage1|dynamicfieldusage2
returns dynamicfieldusage1
and dynamicfieldusage2
in the response.
The Quote Integration Point follows the Policy process flow except for pend rules and callout rules.
Request Payload
The request payload has the same structure as the request payload of the Policy In Integration Point. The integration point handles the Policy in the request as a virtual new Policy. So the system neither stores nor updates the Policy, Persons, or Objects specified in the request. Note that if specifying Policy Code in the request, it must be unique (that is, it must not match the Code of any existing Policy).
Response Payload
The system first triggers Policy Calculation Periods generation. If a Policy Contract Period exists for the Policy in the context that includes the specified Input Date, then it generates Policy Calculation Periods with 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.
The system generates periods up-to-the specified Input Date with the look-back date set to the Input Date if there is no Policy Contract. Refer to chapter "Generate Policy Periods" under the Premium Calculation section of the Operations Guide for details.
The request specifies the setting of the billing cycle.
The basis for the selection of the Calculation Periods for calculation is on the specified Calculation Input Date.
If a Policy Contract Period exists for the Policy in context and includes the specified Input Date, it selects all Calculation Periods (system and Policy) that overlap with that Policy Contract Period and creates a single Calculation Period timeline. Note that the Policy Calculation Periods have higher priority over the system Calculation Period. Removal of the system period from the selection occurs if there is a Policy Calculation Period that overlaps with the selected system period.
The system selects Policy Calculation Period that includes the Input Date if there is no Policy Contract. It then selects all the Policy Calculation Periods having Calculation Date same as the Calculation Date of the selected Policy Calculation Period. If there is no Policy Calculation Period, then it selects the Calculation Period that includes the specified Input Date.
Calculates the Premium for all selected periods (in-detail description in the "Premium Calculation" section in the Operations Guide) and returns the results in response after selecting the Calculation Periods. Note that there is no storing of calculation results nor creating of financial transactions. 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 it is possible to add dynamic fields to the calculation result in the present implementation of the Oracle Health Insurance application. Accept header (see "Request" section) specifies the dynamic fields that the system returns. Refer to the "Property Representation and Handling" section in the HTTP API/IP Concepts part of the Developer Guide for details on how external interfaces can access the values for dynamic fields and how the Oracle Health Insurance application handles them.
Response Messages
The Response Messages define the HTTP status codes that the integration point provides. This integration point returns an appropriate HTTP status code and sends a notification containing error details if there is an error. This way, sending the request again is possible after fixing the reason for failure.
This integration point performs the same checks as in the Policy In Integration Point and returns the same error messages (Policies interface messages, Relation interface messages, functional business rule messages, and standard messages that relate to dynamic fields and dynamic records).
For example, it returns an error message POL-IP-POLI-003
if the Group Account Code is unknown or returns an error message REL-IP-RELA-009
when the Country Code is unknown.
Besides, the integration point also returns any error that it encounters during the Policy Calculation Period generation and Premium Calculation process.
Returns the following integration point-specific error messages besides the ones mentioned above:
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 |