Claim Event Integration Point
The claim process flow is a chain of steps, each of which performs a check or calculation. The status of the claim indicates how far it has progressed in that flow. Some external systems may require to be informed when a claim reaches a certain status.
The purpose of the claim event integration point is to publish claim event messages to external consumers.
Design Choices
The trigger for this integration point is a (specified) status transition. Triggered events have no impact on the processing of the claim.
Beside the status transition, additional triggering conditions can be configured. The conditions that cause an event to be generated are configured through claim event rules. See the chapter on claim event rules in the Claims Flow Configuration guide for a description of claim event rules.
A distinction can be made between informing external consumers of the claim status, sending claim business events to external consumers:
-
The "claim status inform" triggers solely on the status of the claim and publishes data oriented status change events.
-
The "claim business event" triggers on a combination of conditions, including the status of the claim. The message published represents a business event.
This integration point combines both purposes. The term 'event' in the remainder of this document can either mean business event, or status change event.
The message structure for status change event and business event isidentical. They can be distinguished by using different values for the topic or event attribute. See examples below. Note that topic and event are not domain based, but free text items. |
A message is published if the following conditions are met:
-
A claim reaches a status during processing.
-
A claim event rule is defined for that status.
-
The conditions are met in the following way:
-
Claim level. The claim matches the fixed criteria defined in the claim event rule.
-
Claim line level. A claim line matches the criteria defined in the claim event rule. Note that locked claim lines and replaced claim lines are ignored.
-
Claim with lines level. One or more claim lines match the criteria defined in the claim event rule. Note that locked claim lines and replaced claim lines are ignored.
-
-
The configuration of the reraise event indicator is met. The claim event rule can be configured whether or not to take into account the claim event history to evaluate if it is meaningful to sent a claim event a second time; obviously, this only makes sense when - for this rule - the claim event history is being kept. If the reraise event indicator is set to 'Yes', then no further evaluation needs to take place. If the reraise event indicator is set to 'N' then it has to be determined if a similar event already exists in the claim event history. The same event exists if:
-
for CLAIM level events, a claim event history record exists for that claim with the same topic and event.
-
for CLAIMLINE level events, a claim event history record exists for that claim with the same topic and event and also a claim line event history record exists for that claim line referring to the claim event history record.
-
for CLAIM WITH LINES events, a claim event history record exists for that claim with the same topic and event and also a claim line event history record exists for that claim line referring to the claim event history record. However, if the new set of claim lines minus the old set of claim lines still leaves some claim lines, the event is beiing fired for exactly those claim lines. Example: let’s suppose a claim event history record exists for level CLAIM WITH LINES having claim line event history records for claim line codes C1, C2 and C3. When evaluating the claim event rule, let’s suppose this would lead to new claim line event history records for claim line codes C2 and C4. Now the claim event rule should still fire, but should only mention claim line code C4. Thus a new claim event history record is made, but only with a claim line event history record for C4.
-
The processing of this interface is triggered when a claim reaches a status. The statuses of a claim are:
-
'Entry'. The claim is being entered but not yet ready to be processed.
-
'Initial'. The claim is being picked up by the automatic process.
-
'Sent out for pricing'. The claim is sent out to an external system for pricing.
-
'Sent out for preprocessing' : The claims is sent out for external processing
-
'Manual pricing'. The claim is pended for manual pricing.
-
'Pricing done'. The claim has been priced, either manually or automatically.
-
'Manual pricing adjudication': The claim is pended for manual pricing adjudication.
-
'Pricing adjudication done': The claim has been adjudicated for pricing, either manually or automatically.
-
'Pricing finalized'. The claim is sent out to an external system for benefits.
-
'Manual benefits'. The claim is pended for manual benefits.
-
'Benefits done'. The benefits are calculated, either manually or automatically.
-
'Manual adjudication'. The claim is pended for manual adjudication.
-
'Adjudication done'. The claim has been adjudicated, either manually or automatically.
-
'Finalized'. The claim is completely processed.
-
'Change'. The claim can be changed, during manual pricing, manual benefits, manual adjudication of after unfinalize
Note that the triggering not only takes place when the processing of the claim stops in a status, but also when the automatic processing proceeds. So when a new claim is processed straight-through to the Finalized status, all statuses reached in between can be used to trigger this integration point.
The event is being logged if the log event indicator is set to 'Y'. For a CLAIM level event rule, only a claim event history record is logged. For a CLAIM LINE or CLAIM WITH LINES level event rule, also the appropriate claim line event history records are logged. In both cases, the display in UI indicator is taken from the claim event rule. The "on technical error" events only log claim event history records, no claim line event history records.
Claim Event Message
Claims publishes a claim event message for every claim that matches a claim event rule. The granularity of the messages is as follows
Claim level rule
-
Per claim, per matching claim event rule, one event is published
Claim line level rule
-
Per claim line, per matching claim event rule, one event is published. The event contains a reference to the claim line that matches the claim event rule.
Claim with lines level rule
-
Per claim, per matching claim event rule, one event is published. The event contains a list of the claim lines that match the claim event rule.
<claimEvent level="C/L/B" claimCode="" topic="" event=""> <field1></field1> <field2></field2> ... <fieldn></fieldn> <timestamp>timestamp value</timestamp> <claimEventLines> <claimEventLine code=""> <field1></field1> <field2></field2> <field3></field3> </claimEventLine> </claimEventLines> </claimEvent>
Explanation of message attributes:
Attribute | Description |
---|---|
level |
The level of the event. Is this event triggered at the Claim level ©, at the Claim line level (L) or at the Claim with lines level (B, for both). |
claimCode |
The code of the claim that triggered the message. |
topic |
The topic as defined in the claim event rule. Can be used to group related messages together. See use cases below. |
event |
The event as defined in the claim event rule. Describes the event type that occurred. See use cases below. |
timestamp |
Date and time that the claim entered the status. Time has precision of milliseconds. |
claimEventLines |
The list of one or more claim lines for a Claim line level or a Claim with lines level event. |
claimEventLine code |
The claim line identifier |
fields |
The fields that are additionally sent out on the claim event are produced by a dynamic function. This dynamic function produces a list of name value pairs. These fields can be at the claim or the claim line level. Note that a claim line dynamic function has no impact whatsoever when used in an event rule of level 'CLAIM'. |
requestHeaders |
The function dynamic logic that specifies the claim field list can also return header map, the values returned by the header map is set as request headers of the claim event. |
The generic claim event endpoint can be configured as system property 'ohi.claimevent.endpoint.request'. The claim event endpoint can be overridden for specific event codes, e.g. specify property 'ohi.claimevent.{0}.endpoint.request' where the placeholder is replaced with claim event code to have the system deliver claim event for code XXX to a specific endpoint.
If the claim 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 'ClaimsEventClient'.
Please see section Outbound RESTful Service Invocations in Integration Guide for the process and more properties.
Use cases
This section describes some typical use cases of this integration point.
Enrollment new born
Purpose
A letter needs to be sent for every new born baby. To trigger the sending of the letter, a claim event message must be published.
Triggering condition
A claim for a new born enters status 'Initial'. The presence of a date of birth on the claimline within 60 days of the start date of the claimline signals a possible newborn.
Setup
To achieve the publishing of the message, the following setup is needed:
-
The relevant procedures are put in a procedure group 'NEWBORN'.
-
A claim event rule is needed (non-mentioned attributes are left empty):
Claim Event Rule
Attribute | Description |
---|---|
Code |
NEW_BORN |
Level |
CLAIMLINE |
Topic |
LETTER |
Event |
NEWBORN |
Status |
Initial |
Claim type |
|
Procedure group |
NEWBORN |
Message group |
|
Dynamic Logic Condition |
'Date of birth on the claimline within 60 days of start date' |
Reraise event indicator? |
Y |
Log event indicator? |
Y |
Display in UI indicator? |
Y |
Enabled indicator? |
Y |
For every claimline for which the date of birth on claimline is within 60 days of the start date of the claimline, a message is sent with this content:
<claimEvent level="L" claimCode="<code of the claim>" topic="LETTER" event="NEWBORN" timestamp="<date and time>"> </claimEvent>
A claim event history record is logged
Level | Topic | Event | Display in UI |
---|---|---|---|
CLAIM |
LETTER |
NEWBORN |
Y |
Out of pocket max reached
Purpose
A letter needs to be sent when the out of pocket max is reached. To trigger the sending of the letter, a claim event message must be published.
Triggering condition
When the out of pocket max is reached or exceeded, the claims processing attaches messages to the claim line. See the implementation guide for benefit rules for details on how to configure a limit. These messages can be used to trigger the publishing of the message.
Setup
-
The messages for the out of pocket max are put in a message group 'Out-of-pocket-max'.
-
A claim event rule is needed (non-mentioned attributes are left empty):
Claim Event Rule
Attribute | Description |
---|---|
Code |
OUT_OF_POCKET_MAX_REACHED |
Level |
B |
Topic |
LETTER |
Event |
OOPMAXREACHED |
Status |
Finalized |
Claim type |
|
Procedure Group |
|
Message group |
OUT-OF-POCKET-MAX |
Dynamic Logic Condition |
|
Reraise event indicator? |
Y |
Log event indicator? |
Y |
Display in UI indicator? |
Y |
Enabled indicator? |
Y |
For every claim where the out of pocket max is met or exceeded in at least one claim line, a message is published with this content:
<claimEvent level="B" claimCode="<code of the claim>" topic="LETTER" event="OOPMAXREACHED" timestamp="<date and time>"> <claimEventLines> <claimEventLine code=""/> </claimEventLines> </claimEvent>
A claim event history record is logged
Level | Topic | Event | Display in UI |
---|---|---|---|
CLAIM WITH LINES |
LETTER |
OOPMAXREACHED |
Y |
with claim line event history records for each claim line that has an OOPMA message.
Unspecified procedures
Purpose
A letter needs to be sent out when a claim contains one or more procedure codes that cannot be recognized. This letter needs to contain a reference to all the claim lines with an unspecified procedure code.
Triggering condition
When a procedure is not matched claims processing attaches a message to the claim line. For this or these messages a message group 'Unmatched procedure message group' is used.
Setup
-
The messages for non matched procedures are put in a message group 'Unmatched procedure message group'
-
A claim event rule is set up
Claim Event Rule
Attribute | Description |
---|---|
Code |
UNSPECIFIED PROCEDURES |
Level |
B |
Topic |
LETTER |
Event |
UNSPECIFIED PROCEDURE |
Status |
Finalized |
Claim type |
|
Message group |
UNMATCHED PROCEDURE |
Procedure Group |
|
Dynamic Logic Condition |
|
Reraise event indicator? |
Y |
Log event indicator? |
Y |
Display in UI indicator? |
Y |
Enabled indicator? |
Y |
For every claim where the out of pocket max is met or exceeded, a message is published with this content:
<claimEvent level="B" claimCode="<code of the claim>" topic="LETTER" event="UNSPECIFIED PROCEDURE" timestamp="<date and time>"> <claimEventLines> <claimEventLine code=""/> </claimEventLines> </claimEvent>
A claim event history record is logged
Level | Topic | Event | Display in UI |
---|---|---|---|
CLAIM WITH LINES |
LETTER |
UNSPECIFIED PROCEDURES |
Y |
with claim line event history records for each claim line that has an unmatched procedure.
Claim Fields and Claim Line Fields
The following claim event rules are configured:
Level | Diagnosis group | Topic | Event | Status | Claim fields function | Claim line fields function |
---|---|---|---|---|---|---|
Claim |
STATINF |
BEN_DONE |
Benefits Done |
claimProvRef |
— |
|
Line |
Rare diags |
MEMLTR |
UNKN_DIAG |
Benefits Done |
LineDiag |
|
Claim with lines |
Rare procedures |
PROVTtR |
UNKN_PROC |
Benefits Done |
claimProvRef |
LineProc |
Function: claimProvRef
//Function claimProvRef Map fieldsMap fieldsMap = [providerCode: claim.serviceProvider.code ,providerReference: claim.providerReference ] return fieldsMap
Function: LineProc
//Function LineProc Map fieldsMap fieldsMap = [procedureCode: claimLine.procedure.code ] return fieldsMap
Function: LineDiag
//Function LineDiag Map fieldsMap fieldsMap = [diagnosisCode: claimLine.diagnosis.code ] return fieldsMap
And claim 6789 is processed and reaches the status Benefits Done. This Claim has 4 claim lines
-
1 Rare procedure code
-
2 Rare diagnosis code
-
3 Rare procedure code
-
4 Rare diagnosis code
Then the following 4 ClaimEvents are produced.
1 event at the claim level
<claimEvent level="C" claimCode="6789" version="" topic="STATINF" event="BEN_DONE" timestamp="20110606 16:36:26"> <providerCode">564353<providerCode/> <providerReference">20110606-26<providerReference/> </claimEvent>
2 events at the line level
<event level="L" claimCode="6789" version="" topic="MEMLTR" event="UNKN_DIAG" timestamp="20110606 16:36:26"> <claimLines> <claimline code="2"> <diagnosisCode">9781<diagnosisCode/> </claimline> </claimLines> </event>
<event level="L" claimCode="6789" version="" topic="MEMLTR" event="UNKN_DIAG" timestamp="20110606 16:36:26"> <claimLines> <claimline code="4"> <diagnosisCode">9782<diagnosisCode/> </claimline> </claimLines> </event>
And 1 event at the Claim with Lines level for 2 lines
<claimEvent level="B" claimCode="6789" version="" topic="PROV_LETTER" event="UNKN_PROC" timestamp="20110606 16:36:26"> <providerCode">564353<providerCode/> <providerReference">20110606-26<providerReference/> <claimLines> <claimline code="1"> <procedureCode">99218<procedureCode/> </claimline> <claimline code="3"> <procedureCode">99219<procedureCode/> </claimline> </claimLines> </claimEvent>