Run Example Calculation for a Policy
This operation provides the ability to run Premium Calculation for a Policy using a specific Contract Period or Calculation Period, without storing the results of the calculation.
Instead, a response returns these calculation results.
The sample calculation follows the associated Policy process flow except for pend rules and call-out rules.
Resource Representation
Only a Policy in the Edit, Pend, or Approved (last Version) status is eligible for running an Example Calculation. Derive this by the presence or absence of the examplecalculation
link.
The resource representation of a Policy for running an Example Calculation looks like this:
{ ... policy properties ... "links": [ { "href": "http://<host>:<port>/<contextRoot>/generic/policies/", "rel": "self" }, { "href": "http://<host>:<port>/<contextRoot>/policies/\{id}/examplecalculation", "rel": "policy:examplecalculation", "httpMethod": "GET" } ] }
There is no provision for examplecalculation
link in the resource representation of a Policy that is not in the Edit, Pended, or Approved (last Version) status.
{ ... policy properties ... "links": [ { "href": "http://<host>:<port>/<contextRoot>/generic/policies/", "rel": "self" } ] }
It is important to provide a Calculation Input Date path parameter (in format YYYY-MM-DD).
This date is useful for selecting the Contract Period or Calculation Period to Run Example Calculation. The path looks like this:
http://<host>:<port>/<contextRoot>/policies/{id}/examplecalculation/{calculationInputDate}
It is optional to specify the following additional parameter:
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 after using the 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=dynamicfieldusgae1|dynamicfieldusage2
returns dynamicfieldusgae1
and dynamicfieldusage2
in the response.
Response Payload
The basis for the selection of the Calculation Periods for calculation is on the specified Calculation Input Date.
The system first triggers the generation of Policy Calculation Periods.
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.
Having no Policy contract sets the look-back
date to the Input Date.
The request specifies the setting of the billing cycle.
Sets the replace-from
date to the look-back
date.
Refer to the chapter "Generate Policy Calculation Periods" in the Operations Guide for details.
After generating periods for a contracted Policy as of 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.
Policy Calculation Periods have higher priority than system Calculation Period. It does not select the system period if there is a Policy Calculation Period that overlaps with the selected system period. |
For a non-contracted Policy, the system selects the Policy Calculation Period that includes the Input Date. It then selects all the Policy Calculation Periods having a Calculation Date that is the same as the Calculation Date of the selected Policy Calculation Period.
It selects the system Calculation Period that includes the specified input date if there is no Policy Calculation Period, provided there is no Policy Calculation Period overlap with the selected system period.
After selecting the Calculation Periods, a response returns Premium calculation results for all periods (in-detail description in the "Premium Calculation" of the Operations Guide).
Note that Policy Calculation Periods and calculation results do not store and there is no creation 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: "", "policyContractEndDate: "", "groupAccount": { "code": "", "displayName: "" }, "totalBasePremium": { "value": "", "currency": "" }, "totalAdjustment": { "value": "", "currency": "" }, "totalSurcharge": { "value": "", "currency": "" }, "totalResult": { "value": "", "currency": "" }, "calculationResultLineList": [ { "sequence": "", "referencedCalculationResultLine": { "sequence": "" }, "policyEnrollmentProduct": { "policyEnrollment": { "": { "link": { "href": "http://://generic//", "rel": "insurableEntityType.usageName" } } }, "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.
The system returns dynamic fields when Accept header specifies them (see "Request" section).
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 Oracle Health Insurance application handles them.
Response Messages
The Response Messages define the HTTP status codes that this operation provides.
It returns an appropriate HTTP status code and sends a notification containing error details if there is an error.
This way, executing the operation again is possible after fixing the reason for failure.
The following operation-specific errors can occur:
Code | Severity | Message Text |
---|---|---|
POL-HTTP-001 |
Fatal |
Policy must be the last version and in status Edit, Pended or Approved |
POL-HTTP-005 |
Fatal |
No calculation periods could be selected based on the specified calculation input date |
POL-HTTP-018 |
Fatal |
No more than 5 dynamic fields can be requested |
Authorization
The policies.example calculation IP
access restriction protects the above operation.
It is essential to provide a grant for this access restriction with the Read
flag set.
If there is a data access group restriction that restricts the access to a Policy, then it is also important to provide grant for that data access group restriction with the Read
flag set to perform this operation on that Policy.