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

OHI 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.

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 property 'ohi.claimevent.endpoint.request' in the OHI Components application’s properties file. 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

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?

Log event indicator?

Display in UI indicator?

Enabled indicator?

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

Level

Topic

Event

Display in UI

CLAIM

LETTER

NEWBORN

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

Attribute

Description

Code

OUT_OF_POCKET_MAX_REACHED

Level

Topic

LETTER

Event

OOPMAXREACHED

Status

Finalized

Claim type

Procedure Group

Message group

OUT-OF-POCKET-MAX

Dynamic Logic Condition

Reraise event indicator?

Log event indicator?

Display in UI indicator?

Enabled indicator?

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

Level

Topic

Event

Display in UI

CLAIM WITH LINES

LETTER

OOPMAXREACHED

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

Attribute

Description

Code

UNSPECIFIED PROCEDURES

Level

Topic

LETTER

Event

UNSPECIFIED PROCEDURE

Status

Finalized

Claim type

Message group

UNMATCHED PROCEDURE

Procedure Group

Dynamic Logic Condition

Reraise event indicator?

Log event indicator?

Display in UI indicator?

Enabled indicator?

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

Level

Topic

Event

Display in UI

CLAIM WITH LINES

LETTER

UNSPECIFIED PROCEDURES

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

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>