Create Mutation for a Policy

Output generation or fee generation starts with creating a policy mutations for a certain policy of the type output definition or fee definition; it might be at the policy level or for a specific policy enrollment level. This can be triggered through the UI (View and Edit Policy page), but is also useful to provide the ability through a specific operation. This operation can then be called upon from for exmple a portal. An individual can initiate the request on the portal or a group account can initiate all the requests, resulting in calling the operation whenever needed.

Resource Representation

Only policies in status Edit, Pended or Approved (last version) are eligible for creating a policy mutation for. This can be derived by the presence or absence of the "mutation" link.

The resource representation of a policy that can store a policy mutation looks like

{
  ... policy properties ...
  "links": [
    {
      "href": "http://<host>:<port>/<contextRoot>/generic/policies/<id>",
      "rel": "self"
    },
    {
      "href": "http://<host>:<port>/<contextRoot>/policies/<id>/mutation",
      "rel": "<strong>policy:mutation</strong>",
      "httpMethod": "POST"
    }
  ]
}

In the resource representation of a policy that is not in status Edit, Pended or Approved (last version), the mutation link is missing:

{
  ... policy properties ...
  "links": [
    {
    "href": "http://<host>:<port>/<contextRoot>/generic/policies/<id>",
    "rel": "self"
    }
  ]
}

Payload

The payload needs to provide the necessary information for the policy mutation to be stored, it looks like this:

{
  "cause"                      : "Lost",
  "effectiveDate"              : "2017-04-07",
  "feeDefinition"              : { “code” : “ID-CARD” },
  "outputDefinition"           : { “code” : “POLICY-ID-CARD” },
  “<insurableEntityUsageName>” : { “code” : "MEM8723489" },
  "type"                       : <"F"> or <"O">
}

If the mutation is of the type 'F' then only fee definition mutation gets triggered. If the mutation is of the type 'O' then output generation mutation gets triggered (this is described in more detail in the implementation Guide for Output and Fee Generation).

Note

The creation of policy mutation is based on the type argument. If both output definition and fee definition are present in the payload, then one gets ignored based on the type argument.

Response Messages

This operation will provide HTTP status codes as defined in Response Messages. If an error occurs, HTTP status code 401, 403, 409 or 422 is returned and a notification is sent containing error details. This way, the operation can be sent again after the reason for failure has been fixed.

If the operation led to creation of a policy mutation, the response will be HTTP status code 201 with the location header containing the link to the newly created mutation. If the operation did not lead to creation of a policy mutation, as it already existed, the response will be HTTP Status code 200, along with the existing policy mutation object as the payload.

The following HTTP 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-002	Fatal	A fee definition of level Enrollment must have an insurable entity specified; a fee definition of level Policy must have no insurable entity specified
POL-HTTP-015	Fatal	An output definition of level Enrollment must have an insurable entity specified; an output definition of level Policy must have no insurable entity specified.
POL-HTTP-007	Fatal	Policy mutation of type Fee should specify a fee definition
POL-HTTP-012	Fatal	Policy mutation of type Output should specify an output definition
POL-HTTP-013	Fatal	Policy mutation of type {0} is unknown.

Authorization

The operation "Create Mutation for a Policy" can be protected by access restriction "policies.mutation IP".