Queue Resolution

Queue resolution is the process that the system uses to determine the queue for a work item when a claim is pended.

  • Trigger: A claim enters a pended state.

  • Output: A winning queue is identified and a work item is created against it.

  • Failure path: If no queue is identified, an error task is raised in the OHI Task Framework.

Worklist System Property

Before starting queue resolution, the system checks the following system property to determine whether work item creation is enabled.

Property Value

ohi.worklist.enabled = true

Queue resolution proceeds and a work item is created.

ohi.worklist.enabled = false

Queue resolution is skipped. No work item is created.

Queue Resolution

Step 1: Identify the Primary Pend Reason

The system collects all pend reasons from the claim header and claim lines. The collected pend reasons are ordered using the following sequence:

  1. Priority, in ascending order

  2. Pend reason code, in ascending order

The first pend reason in the ordered list becomes the primary pend reason.

Step 2: Identify and Order Eligible Queues

A queue is considered eligible if all the following conditions are met:

  • The queue’s configured dimension values match the corresponding attributes of the claim, or the queue has no dimension value specified for a given attribute.

  • The amount must fall within the queue’s configured minimum and maximum range, or the queue must have no minimum or maximum value specified for the amount.

  • The queue contains the primary pend, or the queue has no pend reason configured.

  • Any message attached to the claim belongs to the queue’s configured message group, or the queue has no message group configured.

For claim fields, see Queue Definition.

For amount range dimensions, a queue with no minimum or maximum value configured for that amount type is considered a match for any transaction value.

Order Eligible Queues

The system orders the eligible queues using the following sequence:

  • Queue contains the primary pend reason (queues containing it first, null last)

  • Queue priority (ascending)

  • Queue code (ascending)

The output of this stage is the ordered eligible queue list, which is passed to Step 3.

Step 3: Execute Condition Dynamic Logic

The system evaluates the dynamic logic condition configured on each queue, working through the ordered eligible queue list from top to bottom.

Table 1. Dynamic Logic Evaluation Results
Rule Result

No dynamic logic configured

The queue automatically passes evaluation and is selected as the winning queue.

Dynamic logic evaluates to true

The queue is selected as the winning queue. Evaluation stops immediately; remaining queues are not evaluated.

Dynamic logic evaluates to false

The system moves to the next queue in the ordered list.

  • If no queue is found, an error task is raised in the OHI Task Framework with task type No work item queue found.

  • The user can adjust the queue configuration and reprocess the errored task via the Task Framework. If the configuration is valid, the work item is created on reprocessing.

Initial Work Item Attributes

A work item is created when queue resolution identifies the winning queue. The system links the work item to both the winning queue and the associated claim, and appends the following initial attribute values.

  • Status set to Open.

  • Hold indicator set to N.

  • Escalate indicator set to N.

  • Primary pend added.

Work Item Default SLA Calculation

After the winning queue is identified, the system computes default SLA timestamps for the work item. The system reads the SLA configuration from the winning queue and calculates the default work item and global SLA datetime.

Work Item SLA

Read from winning queue

Table 2. Work Item SLA Configuration
Field Description

SLA UOM

Unit of measure enum, for example, Minutes or Days.

SLA Due Time Value

Numeric value representing the due threshold.

SLA Risk Time Value

Numeric value representing the risk warning threshold.

Compute

Table 3. Work Item SLA Calculation
Output Field Formula Output Type

Work Item SLA Due Time Value

Work Item creation datetime + SLA Due Time Value (in SLA Time UOM)

Datetime stamp

Work Item SLA Risk Time Value

Work Item creation datetime + SLA Risk Time Value (in SLA Time UOM)

Datetime stamp
If the queue SLA due or risk time value is null, the queue has no work item SLA threshold configured. No work item SLA datetime stamps are computed.

Global SLA

The system reads the linked global SLA definition from the winning queue and resolves the SLA clock start date from the latest version of the claim.

Read from winning queue

Table 4. Global SLA Configuration
Field Description

Referenced SLA Definition

The global SLA definition linked to the winning queue.

Compute

Table 5. Global SLA Calculation
Output Field Formula Output Type

Global SLA Due Time Value

SLA Clock Start Date + Global SLA Due Time Value (in Global SLA Time UOM)

Datetime stamp

Global SLA Risk Time Value

SLA Clock Start Date + Global SLA Risk Time Value (in Global SLA Time UOM)

Datetime stamp

SLA clock start date = claim latest version creation date.

If no SLA definition is referenced on the winning queue, or the SLA definition value is null, the queue has no global SLA threshold configured. No global SLA datetime stamps are computed.

Execute Function Dynamic Logic

This step runs only if a dynamic logic function is configured on the winning queue. The function can optionally set the following values on the work item. For more information, see Queue Parameter Dynamic Logic.

  • Set dynamic fields.

  • Set priority.

  • Set work item SLA due time value.

  • Set global SLA due time value.

Work Item Creation and Closure

This section applies to claim processing.

Claim Work Item Creation

When a claim is submitted through the Submit IP, Large Claim IP, Claims In IP, or a similar operation and pended in one of the claim statuses listed below, the system initiates queue resolution and creates a work item for the submitted claim.

The queue resolution process described earlier on this page determines the winning queue.

Regular Claim Work Item Creation Statuses

  • Manual Pricing

  • Manual Benefits

  • Manual Pricing Adjudication

  • Manual Adjudication

Large Claim Work Item Creation Statuses

  • Manual Adjudication

  • In Process

A sub-claim can pend in the same statuses as a regular claim. However, when the sub-claim is processed as part of a large claim, work item creation is handled at the parent large claim level. The sub-claim pend reason is the trigger, but the resulting work item is created for the large claim.

Work Item Closure

When a claim is submitted through Submit IP, Large Claim Submit IP, Claims In IP, or a similar operation, the system checks for an open work item on the claim.

  • If an open work item exists, the system closes the work item and updates its status history.

  • If the open work item is on hold (ind_hold = Y), the system performs the following actions before closing it:

    1. Releases the hold.

    2. Updates the hold history.

    3. Sets the hold indicator to N.

    4. Closes the work item.

    5. Updates the work item status history.

  • Work item creation and work item closure are both triggered from within the claim submit process. This applies to both regular and large claims.

  • For large claims, work item creation and closure always occur at the large claim level, never at the sub-claim level, regardless of which sub-claim triggered the pend.

Large Claim Scenario

In this scenario, a sub-claim pend creates a work item for the parent large claim.

  • A large claim is submitted with five sub-claims. Sub-claim 3 is pended on Manual Benefits.

  • Queue resolution runs. A work item is created on the parent large claim, not one work item for each sub-claim.