HTTP Pend Resolution Integration Point

This integration point consists of two operations 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, for example, 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 process 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.

Option 1: Call the claims re-processing integration point and request that all the pended claims (meeting certain conditions) are re-processed from scratch. This is the appropriate option when the claim needs to re-adjudicate, for example, to see if the required authorization is now available. In this process the user uploads a data file that contains pended claims. In order to process this data file a long-running operation gets initiated by sending in the HTTP POST request.

We recommend uploading files with sizes under 20 MB. Larger files impact the stability of the system.

Option 2 A long-running operation to call the pend resolution batch integration point and request that all the pended claims (meeting certain conditions) are released to continue processing, that is, without starting from scratch. This is the appropriate option when there is no need to re-adjudicate the claim.

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 clai

Pend Batch Resolution Request

This request enables handling of multiple claims with pend reasons in one go. Since the volume of data can become quite extensive, the input for this process comes from a data file set. For more information about how to create a data file set please refer to Data File Set Integration Point.

Claim List batch elements that are contained in the datafiles that are part of the input data file set have the following structure - in here the <claims> are the root element of an individual datafile.

This data file has the following structure:

  <claims>  -- List of claims to be processed
    <claim code = ""/>
    ...
  </claims>

The metadata for the above structure can be accessed on the /[api-context-root]/pendresolutionbatch /payload/definition as definition.

A long-running operation is used to process the datafile that is initiated by a HTTP POST request to: http://[hostName]:[portNumber]/[api-context-root]/pendresolutionbatch.

A pendresolutionbatch batch (initiation) request has the following structure:

{
"dataFileSetCode" : "...",
“pendReasonCodeList" : "...",
"indSetToHighPriority": "...",
"responseDataFileSetCode" : "...",
 }

Processing

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

Response

As is described in long-running Operations through REST there are multiple ways in which one can get the response or result of this long-running operation. Typically, though one would opt for using notification events.

A notification message can be sent out to a pre-configured endpoint. The notification endpoint can be configured on 'ohi.activityprocessing.notification.endpoint.PEND_RESO_BATCH_IMPORT' respectively or to a more generic endpoint: ohi.activityprocessing.notification.endpoint.

If the notification endpoint is configured on the specific: PEND_RESO_BATCH_IMPORT, other related properties like media type, authentication, etc. are also fetched based on PEND_RESO_BATCH_IMPORT or else defaults are used. Similarly, if the endpoint for the notification is configured without the specific code, then all other properties are fetched on a generic use case code 'ActivityNotificationClient'. Please see section "Outbound RESTful Service Invocations" in Security Guide for the process and more properties.

The notification message has the common notification structure as described in the chapter "long-running Operations through REST" in the Security Guide.

The response notification includes a data file set link of the completed pendresolutionbatch and of the generated response files. The endpoint to which the notification is sent is expected to respond with HTTP 201 Response code.

Any activity messages that are created have the element Id’s set to claim codes.

Error Messages

The response lists each claim that led to a fatal message as well as each claim that was resubmitted, and continued processing, that is, 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:

Table 1. Error Messages

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

Authorization

A grant for access restriction 'Pend Resolution Batch Request IP’ ' must be provided to be able to initiate this operation

Resolve Claim Criteria Request

A Post request initiates this long-running operation http://[hostName]:[portNumber]/[api-context-root]/pendresolutioncriteria

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

<pendresolutioncriteria
   indSetToHighPriority
   -- 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 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, that is, 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 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 claimantProvider and the claimType. These criteria also apply when looking to resolve bill and claim line pend reasons, for example, 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, 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, for example, 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 the criterion, then any claim pend reason that is listed in the request is immediately resolved; if a bill meets all the criteria, then any bill pend reason that is listed in the request is immediately resolved; if a claim line meets all 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

Response

As is described in long-running Operations through REST there are multiple ways in which one can get the response/result of this long-running operation. Typically, though one would opt for using notification events.

A notification message can be sent out to a pre-configured endpoint. The notification endpoint can be configured on 'ohi.activityprocessing.notification.endpoint.PEND_RESOLUTION_CRITERIA' respectively or to a more generic endpoint: ohi.activityprocessing.notification.endpoint.

If the notification endpoint is configured on the specific: PEND_RESOLUTION_CRITERIA, other related properties like media type, authentication, etc. are also fetched based on PEND_RESOLUTION_CRITERIA respectively or else defaults are used. Similarly, if the endpoint for the notification is configured without the specific code, then all other properties are fetched on a generic use case code 'ActivityNotificationClient'. Please see section "Outbound RESTful Service Invocations" in Security Guide for the process and more properties.

The notification message has the common notification structure as described in the chapter "long-running Operations through REST" in the Security Guide.

The response notification includes a data file set link of the completed pendresolutioncriteriarequest and of the generated response files.

The endpoint to which the notification is sent is expected to respond with HTTP 201 Response code.

Any activity messages that are created have the element Id’s set to claim codes.

Error Messages

The response lists each claim that led to a fatal message as well as each claim that was resubmitted, and continued processing, that is, 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:

Table 2. Error Messages

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

Authorization

A grant for access restriction 'Pend Resolution Criteria Request IP’ ' must be provided to be able to initiate this operation