Claim Transaction Event Rules

Claim transaction event rules define events that trigger a notification to an external system. Each rule specifies the conditions under which a particular event is to be raised. When a new claim transaction is created, or a transaction is labeled as unfinalized, the configured claim transaction event rules are evaluated, and a claim transaction event notification is published for each rule that specifies conditions that are met by the claim transaction.

Claim transaction event rules have the following attributes:

Claim Transaction Event Rule

Table 1. Claim Transaction Event Rule
Field Description Mandatory

Code

Unique identifying code.

yes

Topic

Topic to be sent in the published message that is used to group related events together.

no

Event

Event 'name' to be sent in the notification.

no

Trigger

Transition that triggers the evaluation of the event criteria. The possible values are:

  • Create Transaction, and

  • Label Transaction (Unfinalize)

yes

Dynamic Logic Condition (Claim)

Condition dynamic logic of signature 'Claim Transaction Event Rule (Claim)'. Evaluating the claim transaction, it will only fire when returning true.

no

Dynamic Logic Condition (Claim Line)

Condition dynamic logic of signature 'Claim Transaction Event Rule (Claim Line)'. Evaluating the claim line transaction, it will only fire when returning true.

no

Dynamic Logic Function (Claim Fields)

Function dynamic function of signature 'Claim Transaction Event Rule (Fields Map)' that produces a list of name value pairs to be included in the claim transaction event in the <fields> element at the claim transaction level.

no

Dynamic Logic Function (Request Message Claim Line)

Function dynamic logic of signature 'Claim Transaction Event Rule (Request Message)'. The function dynamic logic is completely responsible for composing the payload.

no

Dynamic Logic Function (Event Payload Claim)

Function dynamic logic of signature 'Claim Transaction Event Rule (Event Payload)'. The dynamic logic function is responsible for creating the payload.

no

Limit

The limit on which consumption by the claim line transaction should trigger the event rule.

no

Enabled indicator?

The event rule is only executed when this box is checked

yes

Although configured in one model, claim transaction event rules support two different ways of sending a notification:

  • structured format

In structured format, the topic and event (both mandatory) and the function dynamic logic for fields map (optional) together dictate the event notification, which has a fixed structure. The function dynamic logic for the request message and the reference to limit is prevented from being specified by a business rule.

The structured format is meant for executing once per claim transaction and therefore only condition dynamic logic at claim transaction level is allowed

  • free format

In free format, the composition of a payload is the sole responsibility of the function dynamic logic for the request message. Topic, event and the function dynamic logic for fields map are prevented from being specified by a business rule.

The free format is meant for executing once per claim line transaction and therefore only condition dynamic logic at claim line transaction level is allowed. Also the reference to limit is restricted to use at claim line transaction level, because the limit consumption is stored at claim line level.

Structured Format (HTTP)

<claimEvent
  level="CLAIM"
  claimCode=""
  version=""
  topic=""
  event="">
  <timeStamp>/<timeStamp>
  <field1>..</field1>
  <field2>..</field2>
...
  <fieldn>..</fieldn>
</event>

Note - The headerRequest bind variable can be use to specify request headers to be set for REST based events. For details refer to "Dynamic Logic" chapter of the Developer Guide.

The generic endpoint can be configured as property 'ohi.ctrclaimevent.endpoint.request'. Refer to Property Management for more information on setting a property. The event endpoint can be overridden for specific claim transaction event codes, for example, specify property 'ohi.ctrclaimevent.{0}.endpoint.request' where the placeholder is replaced with claim transaction event code to have the system deliver claim event for code XXX to a specific endpoint.

If the claim transaction event endpoint is configured on the specific event code, all other properties are also fetched based on event code or else defaults are used. Similarly if the endpoint for the claim event is configured without the event code, then all other properties are fetched on a generic usecase code CtrClaimEventClient. Please see section "Outbound RESTful Service Invocations" page in the Security Guide for the process and more properties.

Element Details

The elements have the following meanings:

  • level - always = 'CLAIM'

  • claimCode - code of claim transaction that meets the criteria of the event

  • version - version of claim transaction that meets the criteria of the event

  • fields - a list of name value pairs that are added through a dynamic logic function

  • topic - topic of rule that lead to the notification

  • event - event of rule that lead to the notification

  • timeStamp - date / time the claim transaction was created or unfinalized

If claim transaction events are being sent to the the same end point as claim events, the message topics and events need to be coordinated with claim events. For more details of "Claim Events" and the use of topics and events, refer to the Process Rules chapter of the Configuration Guide.

Free Format

In free format the composition of the payload is completely configured in the dynamic logic function; the base url should be configured in the properties file.

Note that, because the event rules are evaluated per claim line transaction, multiple payloads could be sent at (un)finalization.

More details on the groovy configuration possibilities can be found in the "Dynamic Logic" chapter of the Developer Guide.