Workflow Integration Point (HTTP)

Not all claims are auto-adjudicated; some claims require intervention. This might be because the claim is a suspected duplicate of another claim, or because the claim needs to be held up because the required authorization has not come through yet.

External intervention rules are configured to detect these situations. If one or more of these rule trigger the claim leaves the processing flow and its status is updated to reflect that is is now pended.

If the claim requires manual intervention an event is published to notify an external work flow system of the pended claim. The notification contains identifying information for the claim and claim lines, and includes the reasons why the claim pended.

This chapter describes the workflow notification integration point.

Design Principles

External intervention rules can be configured to trigger at several points in the process. Depending on this configuration, a claim can be pended in one of the following statuses: change, manual pricing, manual pricing adjudication, manual benefits or manual adjudication.

The moment a claim is pended, one or more pend reasons are attached to the claim. If at least one of the pend reasons is configured to cause a notification, i.e., if the "publish message?" check box on the pend reason is checked, the system sends out a notification.

The work flow system that receives the event is responsible for assigning the task of resolving the pend to a claims operator. Once the operator has finished working the claim, then he or she submits the claim for further processing by clicking a button in the OHI page. This will trigger the generation of a second event, sent from OHI Claims to the work flow system, that informs the work flow system that the pend has been resolved and the task can be closed.

When a claims operator resolves a pend, he or she checks the pend reasons in the OHI Claims user interface. Each pend reasons is checked off individually, so in a situation where a claim has multiple pend reasons, each reason has to be checked off separately.

If an operator should submit the claim without having resolved all pend reasons, a task done event is sent out to close the open task. This will effectively also close the task for the unresolved pend reasons, so directly after sending out the task done event, the system also sends out a a new event for the remaining unresolved pend reasons.

Task events contain a URL which can be leveraged by an external work flow system to direct the claims operators towards the claim that needs work. Before sending URIs out, the system will encode these following the format for HTML form encoding (application/x-www-form-urlencoded MIME format, with encoding schema UTF-8, following the World Wide Web Consortium Recommendation recommendation). The receiving system is expected to decode the URI before it is used.

The task event is sent in a fire-and-forget mode. That means that once OHI Claims receives the acknowledgment that the notification message has reached its endpoint, no further reply is expected. It is the responsibility of the middleware and/or the work flow management system to handle errors.

If an acknowledgment is received that the task event has reached its endpoint, but the task event has not been delivered successfully to the work flow management system, the claims reprocessing integration point can be used to reprocess that claim. Reprocessing causes the redelivery of the message.

This integration point sends out events to open new tasks and events with type taskDone once the claim has been resubmitted. In order for the receiving workflow system to tie these two events together, both events contain a correlation ID. In order to keep track of the correlation ID while a claim is pended, the system stores it on the claim. The endpoint to send workflow event can be configured using 'ohi.workflowtaskstart.endpoint.request'.

 If the workflow endpoint requires Authentication, please use Authentication
Use Case: WorkflowEventClient to set authentication. Please see section Outbound
RESTful Service Invocations in Integration Guide for the process and more
properties.

This chapter does not discuss logging, time stamps etc. These aspects are covered by the overall messaging framework.

New Task Event

OHI Claims sends this event when manual intervention is before a claim can continue automated processing. A task event contains information on a single claim. A work flow task event has the following structure:

<workFlowTask type =""
              taskEventId =""
              claimsPageURL="">
  <workflowClaim code ="">
    <fields/>
    <workflowPendReasons/>
    <workflowClaimLines>
      <workflowClaimLine code ="">
        <fields/>
       < workflowPendReasons/>
    <workflowClaimLines/>
  <workflowClaim>
<workflowTask>

The content of the <fields> element:

   <field1></field1>
   <field2></field2>
...
   <fieldn></fieldn>

The content of the <pendReasons> element:

<workflowPendReasons>
  <workflowPendReason
    code =""
    description =""
    priority =""
    externalCode=""/>
</workflowPendReasons>

The type attribute can be used to distinguish the different types of external intervention. Values for this attribute are 'MANUAL_PRICING', 'MANUAL_PRICING_ADJUDICATION', 'MANUAL_BENEFITS', 'MANUAL_ADJUDICATION' and 'CHANGE'.

Only pend reasons for which the field 'Publish message?' is checked are included in the task event.

Enriching the event

The information returned in an event by default is limited; it identifies the pended claim and the reason(s) why it pended. However, the work flow system that receives the events might require more information to put the task in the right queue. For example, the person’s benefit plan might be key in determining which claims operator should resolve the pend. In order to support such a situation, an event can be enriched with information from the claim.

The set of information that should be appended to the event depends strongly on the pend reason. Consequently, the pend reason configuration specifies the additional information relevant for that specific reason, in the form of a dynamic logic function. Such a dynamic function defines a list of name value pairs. This list of name value pairs appears in the <fields> element, which is a sub element in the event. These fields can be at the claim or the claim line level.

If a claim has more than one pend reason, then for each unresolved pend reason (with a checked 'publish?' indicator)

at the claim level, the 'Claim fields function' is applied
at the claim line level, the 'Claim line fields function' and the 'Claim fields function' are applied.

The lists of name value pairs returned by each function will be concatenated to one list within the <fields> element in the Workflow message. Note that if the claim has two or more pend reasons that share the same fields function, then it is applied only once. If the concatenated list contains the same name more than once, then only the first instance will be used.

The function dynamic logic - 'Claim Fields' can also return values to be set as request headers, when specified they are as request headers of the workflow event.

The following scenarios elaborate on the described enrichment feature. The following external intervention rules all apply in the step Manual Adjudication:

Configured External Intervention Rules

Level	Mess. group	Diag group	Condition dynamic logic	Pend reason
Claim			Covered over $ 10,000.00	HIGH_DOLLAR
Claim			Out of state provider	OOS_PROV
Line		Neuromotor diags		RARE_DIAGS
Line	SUSPDUP			SUSP_DUPE

Level

Mess. group

Diag group

Condition dynamic logic

Pend reason

Claim

Covered over $ 10,000.00

HIGH_DOLLAR

Claim

Out of state provider

OOS_PROV

Line

Neuromotor diags

RARE_DIAGS

Line

SUSPDUP

SUSP_DUPE

The pend reasons are set up with the following dynamic functions

Configured Pend Reasons

Code	Claim fields function	Claim line fields function
HIGH_DOLLAR	CLAIM_MEM_AMOUNT
OOS_PROV	CLAIM_PROV
RARE_DIAGS	CLAIM_PROV	LINE_PROC_DIAG
SUSP_DUPE		LINE_MESS

Code

Claim fields function

Claim line fields function

HIGH_DOLLAR

CLAIM_MEM_AMOUNT

OOS_PROV

CLAIM_PROV

RARE_DIAGS

CLAIM_PROV

LINE_PROC_DIAG

SUSP_DUPE

LINE_MESS

Dynamic Logic Function CLAIM_PROV

//Function claimProv
Map fieldsMap
fieldsMap = [providerCode: claim.serviceProvider.code
            ,providerState: claim.serviceProvider.relation.getCountryRegion()
            ]

return fieldsMap

Dynamic Logic Function CLAIM_MEM_AMOUNT

//Function claimMemAmt
Map fieldsMap
fieldsMap = [personCode: claim.servicedMember.code
            ,totalCoveredAmt: claim.totalCoveredAmount
            ]

return fieldsMap

Dynamic Logic Function LINE_PROC_DIAG

//Function LineProcDiag
Map fieldsMap
fieldsMap = [procedureCode: claimLine.procedure.code
            ,diagnosisCode: claimLine.diagnosis.code
            ]

return fieldsMap

Function LINE_MESS

//Function LineMess
Map fieldsMap
fieldsMap = [messageCode: claimLine.message.code
            ]

return fieldsMap

Suppose claim 1234 is processed. The claim has 3 lines. All described external intervention rules trigger; the HIGH DOLLAR and OOS_PROV pend reasons are attached to the claim, the RARE_DIAGS and SUSP_DUPE pend reasons are attached to line 1 and the SUSP_DUPE pend reasons is attached to line 3. Based on the field map functions attached to the pend reasons, the event is enriched in the following way:

<workflowTask
  type="MANUAL_ADJUDICATION"
  taskEventId="2134234"
  claimsPageURL="http://yourmachine:7002/base.functional/ManualAdjucation">
  <workflowClaim code="1234" >
    <providerCode>123123</providerCode>
    <providerState>CA</providerState>
    <personCode>6812398</personCode>
    <totalCoveredAmt>11221.95"</totalCoveredAmt>
    <workflowPendReasons>
      <workflowPendReason
        code="HIGH_DOLLAR"
        description=""
        priority=""
        externalCode=""/>
      <workflowPendReason
        code="OOS_PROV"
        description=""
        priority=""
        externalCode=""/>
    </workflowPendReasons>
    <workflowClaimLines>
      <workflowClaimLine code="1">
        <procedureCode>99218<procedureCode/>
        <diagnosisCode>5477<diagnosisCode/>
        <messageCode">2315<messageCode/>
        <workflowPendReasons>
          <workflowPendReason
            code="RARE_DIAGS"
            description=""
            priority=""
            externalCode="">
          <workflowPendReason
            code="SUSP_DUPE"
            description=""
            priority=""
            externalCode="">
        </workflowPendReasons>
      </workflowClaimLine>
      <workflowClaimLine code="3">
        <messageCode>2316<messageCode/>
        <workflowPendReasons>
          <workflowPendReason
            code="SUSP_DUPE"
            description=""
            priority=""
            externalCode="">
        </workflowPendReasons>
      </workflowClaimLine>
    </workflowClaimLines>
  </workflowClaim>
</workflowEvent>

When the requirement is to have a common set of fields in all work flow messages sent out, then the following approach can be used.

Configured External Intervention Rules

Level	Mess. group	Diag group	Condition dynamic logic	Pend reason
Claim			Covered over $ 10,000.00	HIGH_DOLLAR
Claim			Provider on review	PROVREV

Level

Mess. group

Diag group

Condition dynamic logic

Pend reason

Claim

Covered over $ 10,000.00

HIGH_DOLLAR

Claim

Provider on review

PROVREV

The pend reasons are set up with the following dynamic functions

Configured Pend Reasons

Pend reason	Claim fields function	Claim line fields function
HIGH_DOLLAR	CLAIM_AMT
PROVREV	CLAIM_PROV_REV

Pend reason

Claim fields function

Claim line fields function

HIGH_DOLLAR

CLAIM_AMT

PROVREV

CLAIM_PROV_REV

Dynamic Logic Function CLAIM_AMT

//Function claimAmt
Map fieldsMap
fieldsMap = [formType: claim.claimForm
            ,restricted: claim.servicedMember.accessRestriction
            ,providerState: claim.serviceProvider.relation.getCountryRegion()
            ,totalCoveredAmt: claim.totalCoveredAmount ]

return fieldsMap

Dynamic Logic Function CLAIM_PROV_REV

//Function claimProvRev
Map fieldsMap
fieldsMap = [formType:      claim.claimForm
            ,restricted:    claim.servicedMember.accessRestriction
            ,providerState: claim.serviceProvider.relation.getCountryRegion()
            ,providerCode:  claim.serviceProvider.code
            ]

return fieldsMap

When both external intervention rules trigger on Claim 4321 then the fields that are present in both claim level field functions (providerState in this example) are included only once:

<workflowTask
  type="MANUAL_ADJUDICATION"
  taskEventId="2134234"
  claimsPageURL="http://yourmachine:7002/base.functional/ManualAdjucation">
  <workflowClaim code="4321" >
    <formType">123123<formType/>
    <restricted">N<restricted/>
    <providerState">CA<providerState/>
    <totalCoveredAmt">19000.95<totalCoveredAmt/>
    <providerCode">87612391<providerCode/>
    <workflowPendReasons>
      <workflowPendReason
        code="HIGH_DOLLAR"
        description=""
        priority=""
        externalCode=""/>
      <workflowPendReason
        code="PROVREV"
        description=""
        priority=""
        externalCode=""/>
    </workflowPendReasons>
  </workflowClaim>
</event>

Task Done Event

OHI Claims sends this event when a claim is in a pended status and is either resubmitted for processing or picked up by a reprocessing request sent in through the reprocessing integration point. A task done event contains information on a single claim. A work flow task done event has the following structure:

<taskDoneRequest taskEventId="..."/>

The taskEventId is identical to the task event identifier that originally opened the task. As soon as the task done has been successfully sent out, the correlation id of the task event on the claim is cleared. The endpoint to send task done event can be configured using 'ohi.workflowtaskstart.endpoint.request'.

 If the workflow endpoint requires Authentication, please use Authentication
Use Case: __TaskDoneEventClient__ to set authentication. Please see section
Outbound RESTful Service Invocations in Integration Guide for the process and
more properties.