Pend Resolution Integration Point

This integration point consists of two operation that provide way to resolve pended claims in an automated fashion and can be leveraged to release a large volume of pended claims back into the processing flow.

Rather than manual intervention, claims might also be pended for automated intervention, e.g., the claim needs to held for a period of time in order for a pre-authorization to come through or because the down stream systems are not ready to processes the claims yet. The main difference is that the claim itself does not require edits.

Claims that require automated intervention are pended in bulk. Once it is time for these claims to be released back into the flow, two options are available.

The first option is to call the claims reprocessing integration point and request that all of the pended claims (meeting certain conditions) are reprocessed from scratch. This is the appropriate option when the claim needs to re-adjudicate, e.g., to see if the required authorization is now available.

The second option is to call the pend resolution integration point and request that all of the pended claims (meeting certain conditions) are released to continue processing, i.e., without starting from scratch. This is the appropriate option when there is no need to re-adjudicate the claim. This second option is supported by the workflow operations described below, i.e., the <resolvePendReasonsClaimListRequest> and the <resolvePendReasonsClaimCriteriaRequest>.

Note that it is possible to use either operation to resubmit a claim that also has published pend reasons. In this case a <taskDone> event is sent out, just as if the claim had been resubmitted manually in the user interface.

Both pend resolution operations have as parameter indSetToHighPriority: if set to 'Y', then the pend resolution request marks all claims involved as high priority claims. If indSetToHighPriority is not set to 'Y', then the high priority indicator of all claims involved is left untouched.

Resolve Claim List Request

There are two operations to release pended claims. The first operation takes a list of claims as input and has the following structure:

<resolvePendReasonsClaimListRequest
  indSetToHighPriority=""
  processResponseFilePath="">
  <claims>  -- List of claims to be processed
    <claim code = ""/>
    ...
  </claims>
  <claimSelectionInputFilePath/>
  <pendReasons> -- List of pend reasons to be resolved
     <pendReason code = ""/>
     ...

The request must specify at least one claim and one pend reason. The request can contain no more than 15 pend reasons. The request either includes the <claims> or the <claimSelectionInputFilePath> element. If the number of claims to be resolved exceeds the limit of 100, use <claimSelectionInputFilePath> to select more by listing the claims in the specified file. The file has the following structure:

<resolveClaimSelection>
  indSetToHighPriority=""
  <claims>
    <claim code =""/>
    <claim code =""/>
    <claim code =""/>
    ...

Upon processing the request, the following happens: for each listed claim, all claim pend reasons, bill pend reasons and claim line pend reasons are checked; if the pend reason is listed in the request, it is immediately resolved. Only claims with status CHANGE, MANUAL PRICING, MANUAL PRICING ADJUDICATION, MANUAL BENEFITS or MANUAL ADJUDICATION are considered.

All claims on which at least one claim pend reason, bill pend reason or claim line pend reason has been resolved are submitted for further processing. If there are still unresolved pend reasons on a submitted claim, the system shows the same behavior as though the claim was submitted by a claims operator in the user interface:

• Claims with status CHANGE, MANUAL PRICING ADJUDICATION (internal benefits), MANUAL PRICING and MANUAL BENEFITS:

  • any resolved pend reasons are removed

  • if any pend reasons with indicator 'Adjudication Only' set to false remain, the claim remains in a pended status

  • else the claim continues in the flow

• Claims with status MANUAL PRICING ADJUDICATION (external benefits) and MANUAL ADJUDICATION:

  • any resolved pend reasons are removed

  • if any pend reasons irrespective of indicator 'Adjudication Only' remain, the claim remains in a pended status

  • else the claim continues in the flow

The response message has the following structure:

<resolvePendReasonsResponse>
  <resultMessages
      result=""
   >
       <resultMessage
         code=""
      >
      message text
      </resultMessage>
      ...
   </resultMessages>
   <claims>
      <claim
         code=""
      >
         <resultMessages
            result=""
         >
           <resultMessage
              code=""
           >
           message text
           </resultMessage>
           ...
        </resultMessages>
      </claim>
   </claims>
    ...

The response lists each claim that led to a fatal message as well as each claim that was resubmitted, and continued processing, i.e., the claims that are still pended due to remaining unresolved pend reasons are not listed. The following messages can thus be included in the response:

Code	Sev	Message
CLA-IP-WRKF-001	Fatal	The pend reasons on claim {code} cannot be resolved due to its current status
CLA-IP-WRKF-007	Fatal	Claim {code} is unknown
CLA-IP-WRKF-002	Fatal	Pend Reason {code} is unknown
CLA-IP-WRKF-008	Fatal	Claim {code} has none of the listed pend reasons
CLA-IP-WRKF-009	Fatal	Claim {code} cannot be resolved because it is locked by another process
CLA-IP-WRKF-010	Info	Claim {code} is resolved

Resolve Claim Criteria Request

The second operation that releases pended claims takes a list of criteria as input and has the following structure:

<resolvePendReasonsClaimCriteriaRequest
   -- Lines with service date between
   serviceStartDate
   serviceEndDate
   -- Claims with entry date between
   entryStartDate
   entryEndDate
   claimForm
   claimType
   benefitsProviderGroupCode
   priceProviderGroupCode
   serviceProviderGroupCode
   locationProviderGroupCode
   claimantProviderGroupCode
   productCode
>
  <pendReasons/> -- List of pend reasons to be resolve
     <pendReason
       code
     />
     ...

The request must specify at least one pend reason, but all of the criteria are optional. If a criteria is not listed in the request, it is not applied. For example, if no claim type is specified, both provider and restitution claims are considered are picked up. Consequently, a request without any criteria, is processed against all pended claims, i.e., claims in the status CHANGE, MANUAL PRICING, MANUAL PRICING ADJUDICATION, MANUAL BENEFITS or MANUAL ADJUDICATION. The request can contain no more than 15 pend reasons.

The productCode criteria is satisfied if the claim line has at least one claim line coverage that refers to that particular product. It is not matched against the claim line field "productCode". A provider group criteria is satisfied if the claim or line specifies a provider that is in that group on the claim or claim line start date.

Upon processing the request, claim (headers), bills and lines are evaluated separately. The reason is that some of the criteria are matched against fields on the claim header while others are matched against fields on the bill and claim line.

Some criteria match against fields only on the claim (header), such as the the claimantProvider and the claimType. These criteria also apply when looking to resolve bill and claim line pend reasons, e.g., if the request specifies a claim type then the claim type of the claim to which that line belongs must match. In other words claim level criteria also apply to when looking to resolve bill and claim line pend reasons.

The reverse is not true; if the request contains criteria that can only be found on the claim line, then claim and bill pend reasons are precluded from resolution. For example, e.g., if the request specifies a product code and / or benefits provider (fields that are only on the claim line), then the request can only result in claim line pend reason resolutions.

Some criteria match against fields that appear on claim, bill and / or claim line level, e.g., the service provider. In this case, matches are made per level. For example, if the service provider is set on claim header level, then the service provider on the line automatically has the same value, and the request with a service provider criteria potentially resolves both claim and claim line pend reasons. If the claim header does not specify a service provider, but each individual line does, then a request with a service provider criteria can only resolve claim line pend reasons. Even if the service provider is the same on each line.

If a claim meets all of the criteria, then any claim pend reason that is listed in the request is immediately resolved; if a bill meets all of the criteria, then any bill pend reason that is listed in the request is immediately resolved; if a claim line meets all of the criteria then any claim line pend reason that is listed in the request is immediately resolved.

All claims on which at least one claim pend reason, bill pend reason or claim line pend reason has been resolved are submitted for further processing. If there are still unresolved pend reasons on a submitted claim, the system shows the same behavior as though the claim was submitted by a claims operator in the user interface:

• Claims with status CHANGE, MANUAL PRICING ADJUDICATION (internal benefits), MANUAL PRICING and MANUAL BENEFITS:

  • any resolved pend reasons are removed

  • if any pend reasons with indicator 'Adjudication Only' set to false remain, the claim remains in a pended status

  • else the claim continues in the flow

• Claims with status MANUAL PRICING ADJUDICATION (external benefits) and MANUAL ADJUDICATION:

  • any resolved pend reasons are removed

  • if any pend reasons irrespective of indicator 'Adjudication Only' remain, the claim remains in a pended status

  • else the claim continues in the flow

The response message has the following structure:

<resolvePendReasonClaimListResponse>
  <resultMessages/>
  <claims>
    <claim
      code
    ...

The response lists each claim that led to a fatal message as well as each claim that was resubmitted, and continued processing, i.e., the claims that are still pended due to remaining unresolved pend reasons are not listed. The following messages can thus be included in the response:

Code	Sev	Message
CLA-IP-WRKF-002	Fatal	Pend Reason {code} is unknown
CLA-IP-WRKF-003	Fatal	Provider Group {code} is unknown
CLA-IP-WRKF-004	Fatal	Claim form {code} is unknown
CLA-IP-WRKF-005	Fatal	Product Code {code} is unknown
CLA-IP-WRKF-006	Fatal	Start date must be before end date
CLA-IP-WRKF-009	Fatal	Claim {code} cannot be resolved because it is locked by another process
CLA-IP-WRKF-010	Info	Claim {code} is resolved