Receive Change or Enter Claim

Receive Change or Enter Claim

Level 2: Receive, Change or Enter Claim

The flow for receiving a claim is schematically shown by the image above. Note that the pend reasons that are specified in decision point 'All pend reasons resolved?' are pend reasons with indicator 'Adjudication Only' set to false.

This chapter describes the steps between entering a claim and the start of automatically processing this claim. A claim can enter Claims in two ways:

  • Through a web service message for 'claims in' integration point.

  • Through manual entry in the Claims user interface pages.

Both ways are further detailed below.

Entry through the integration point

The integration point receives a message that carries a claim. Once a claim is imported, the integration point checks if the procedure codes, diagnosis codes and provider codes as provided in the message are known to the application. Consider an example of a mapping validation: the request message specifies a procedure code 1234. The logic embedded in the integration point will consequently try to find a procedure with the same code in the reference data stored in Claims. This may or may not succeed. With the exception of a few specific cases, failing to map a piece of information does not cause the import to fail. Instead, the unmapped information is stored in Claims. This allows an operator to manually map the reference data at a later point in the flow.

It is possible that a claim with the same claim code is already resident in Claims. If this is the case, and the "claims in" message is flagged as an intentional replacement, the existing claim is queried. What happens next depends on the status of the resident claim: if it is finalized, the Unfinalize Claim is initiated. If not, the existing claim is replaced by the claim in the "claims in" message and set to the INITIAL status. Before it is replaced, it is checked whether there is an open work flow task for the resident claim. If so, a work flow task done event is sent out.

More on the processing logic of the claims in integration point can be found in the implementation guide for claims.

Enter Page

The Enter Claim page allows a user to enter new claims. This page provides the claims operator with two options: save or submit. Saving the claim stores any changes to the claim, but does not initiate the process flow, and sets the status of the claim to ENTRY. When a claim is submitted, changes are stored and the flow proceeds to the following substep.

Change Page

The Change Claim page allows a user to change fields on existing claims that have returned from a later part of the flow in order to redo part of the process flow. This page provides the claims operator with two options: save or submit. Saving the claim stores any changes to the claim, but does not initiate the process flow. The claim’s status remains the same, that is, CHANGE.

When a claim is submitted, changes are stored, and it is checked whether there is an open work flow task for that claim. If so, the work flow integration point sends out a message to inform the work flow distribution system that the task can be closed.

Next, any resolved pend reasons are removed from the claim, bill and claim line. Note that these pend reasons are retained in the pend reason history. It is possible that one or more unresolved pend reasons remain attached to the claim, bill or claim line.

If any pend reasons with indicator 'Adjudication Only' set to false remain, the claim’s status remains CHANGE. If at least one of the remaining pend reasons with indicator 'Adjudication Only' set to false has a checked publish message indicator, a new work flow integration point message is sent out. In effect, a claim will not be picked up by the process flow until all pend reasons with indicator 'Adjudication Only' set to false have been resolved.

If no pend reasons with indicator 'Adjudication Only' set to false (no pend reasons at all or only pend reasons with indicator 'Adjudication Only' set to true) remain, the flow proceeds to the following substep.

Status and Skip Tag Actions

Claim tag actions (that is, the combination of a skip tag and an action) are created together with the claim record itself, based on the skip tag configuration at that time. However, because skip tag configuration may change over time, the last step in this flow adds new claim tag actions to the claim

IF

  • the corresponding skip tag is used on a replacement rule or a callout rule

  • and has either a matching claim form or no specified claim forms at all

Any new claim tag actions default to REDO. The claim status is set to INITIAL. INITIAL claims are ready to be picked up by the processing flow.