Claims Workflow Integration Point (Fixed Payload)
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 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, that is, 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 Oracle Health Insurance page. This will trigger the generation of a second event, sent from 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 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 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 Security 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
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:
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
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.
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
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
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.