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.
For the large claims, the Claim Transaction Event Rules do not apply. |
Claim Transaction Event Rules apply to sub-claims in the same manner as they do to regular claims. |
Claim transaction event rules have the following attributes:
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:
|
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.