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 callout 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://[hostName]:[portNumber]/[api-context-root]/generic/policies/{id}",
      "rel": "self"
    },
    {
      "href": "http://[hostName]:[portNumber]/[api-context-root]/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://[hostName]:[portNumber]/[api-context-root]/generic/policies/{id}",
    "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://[hostName]:[portNumber]/[api-context-root]/policies/{id}/examplecalculation/{calculationInputDate}

It is optional to specify the following additional parameter:

Table 1. Resource Representation

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=dynamicfieldusage1|dynamicfieldusage2 returns dynamicfieldusage1 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://[hostName]:[portNumber]/[api-context-root]/generic/\{insurableEntityType.resourcename}/{id}",
                   "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.

Response Messages

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.