Claims Reprocess Integration Point

The purpose of this integration point is to support automated external intervention. The typical reason for reprocessing pended claims (in bulk) is to re-adjudicate against changed configuration or reference data.

Reprocess Claim Request

The reprocess claim request has the following structure:

<claim
   code=""
   overrideSkip=""
   preprocessingDone=""
   pricingDone=""
   setToHighPriority=""
   reprocessMessageCode="">
   <claimTagActionlist>
      <claimTagAction
         tag=""
         action=""
      >
      </claimTagAction>
      ...
   </claimTagActionList>
   <claimUnfinalizeReasonList>
      <claimUnfinalizeReason
         code=""
         sourceReference=""
      >
      </claimUnfinalizeReason >
      ...
   </claimUnfinalizeReasonList>
   <claimPendReasonList>
     <claimPendReason code="" />
   </claimPendReasonList>
</claim>

The request is posted to the uri: http://[hostName]:[portNumber]/[api-context-root]/claimsreprocess

It is possible to send dynamic fields on an unfinalized reason. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by the Oracle Health Insurance application, refer to the concepts in the Developer Guide.

Response Message

Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.

The system also returns a link to the status resource in the Location header:

Location: http://<host>:<port>/[api-context-root]/claims//status

This enables the external system to track the progress by issuing a GET to the status URI returned in the Location header. For details on the status resource refer section Operations in the HTTP API guide.

Reprocess Claims (Batch) Request

Batch requests enable the handling of multiple requests in one go. Because the volume of data can become quite extensive, these are file based requests. Please refer to the 'File Based Import' section in the HTTP API Integration Points part of the Common Features book for more details on how files are processed by Oracle Health Insurance.

Multiple claims request can be written to a file^[1].

The sample format of the file is described below:

<claimsReprocessRequest>
  <claim  -- This structure is same as the claim reprocess (online-XML) request
   code=""
   overrideSkip=""
   preprocessingDone=""
   pricingDone=""
   setToHighPriority=""
   reprocessMessageCode="">
   <claimTagActionlist>
      <claimTagAction
        tag=""
        action=""
      >
      </claimTagAction>
      ...
   </claimTagActionList>
   <claimUnfinalizeReasonList>
      <claimUnfinalizeReason
         code=""
         sourceReference=""
      >
      </claimUnfinalizeReason >
      ...
   </claimUnfinalizeReasonList>
   <claimPendReasonList>
     <claimPendReason code="" />
   </claimPendReasonList>
  </claim>
  <claim/>
  ...
</claimsReprocessRequest>

Response Message

Batch response messages have the following structure:

<claimsReprocessResponse>
  <resultMessages/>
</claimsReprocessResponse>

The elementId attribute that is included as part of the result messages element (refer to the 'Activity Integration Point' section in the HTTP API Integration Points part of the Common Features book for more details) contains the code of the claim for which the messages are raised.

For each claim that is successfully processed an info message CLA-IP-REPR-022 is added.

Reprocess Claims Criteria Request

The reprocess claims criteria request have the following structure:

<claimReprocessCriteriaRequest
   serviceStartDate=""
   serviceEndDate=""
   entryStartDate=""
   entryEndDate=""
   claimStatus=""
   claimForm=""
   claimType=""
   processType=""
   procedureGroupCode=""
   procedureConditionCode=""
   diagnosisGroupCode=""
   diagnosisConditionCode=""
   benefitsProviderGroupCode=""
   priceProviderGroupCode=""
   serviceProviderGroupCode=""
   locationProviderGroupCode=""
   claimantProviderGroupCode=""
   productCode=""
   feeScheduleCode=""
   coverageRegimeCode=""
   messageGroupCode=""
   pendReasonCode=""
   reprocessMessageCode=""
   reprocess=""
   overrideSkip=""
   setToHighPriority=""
   preprocessingDone=""
   pricingDone="">
   <servicedEntity
      typeCode=""
      code=""
   />
   <claimTagActionList>
     <claimTagAction
       tag=""
       action="">
     </claimTagAction>
     ...
   </claimTagActionList>
   <claimUnfinalizeReasonList>
      <claimUnfinalizeReason
         code=""
         sourceReference=""
      >
    </claimUnfinalizeReason>
      ...
   </claimUnfinalizeReasonList>
  <claimPendReasonList>
    <claimPendReason code="" />
  </claimPendReasonList>
</claimReprocessCriteriaRequest>

The request is posted to the uri: http://[hostName]:[portNumber]/[api-context-root]/claimsreprocesscriteria

The claim criteria request holds a number of search criteria. Claims interprets this request as a query. Any claim that meets the criteria is to be reprocessed. This request message is meant to be used in scenarios where specific setup or reference data has been retroactively changed and a bulk reprocessing is required. The criteria in the request message are checked against Claim Line within a claim in one of the mentioned statuses. In the event that a claim line meets the search criteria, then the entire claim is reset to the initial status. This also includes any other claim lines under the claim that do not meet the search criteria.

Each criterion works in conjunction with other criteria. That is, at least one claim line under a claim must meet all criteria in order for the claim to be reprocessed. If a criterion is not listed in the request, then this is interpreted such that the criterion does not apply. For example, if no claim type is specified, the claim lines that belong to any type of claim are eligible for the selection.

The criterion in the request message is limited to one value per request message. An example to clarify: if a user wants to reprocess all claims that have benefits applied that belong to coverage regime A and B, then two separate request messages need to be sent: one that requests reprocessing for claims affected by regime A, one that requests reprocessing for regime B.

The following restrictions apply when using procedure groups/conditions and diagnosis groups/conditions in a reprocess request:

It is not allowed to specify both a procedure group code and a procedure condition code
It is not allowed to specify both a diagnosis group code and a diagnosis condition code
A diagnosis condition can only be specified in conjunction with a procedure group or procedure condition as well. The rationale is that the evaluation of a diagnosis condition can only be executed efficiently when eligible claim lines are pre-filtered on procedure code first.

The reprocess indicator specifies how Claims should process this request. If checked, then the claims that meet the criteria are picked up and reprocessed. If unchecked, then the claims that meet the criteria are left untouched. This enables an external system to retrieve a response message (from Claims) that lists the claims that are impacted without actually reprocessing those claims.

An explanation of the available search criteria follows:

Service start date and service end date: The claim line start date must be between (inclusive) the specified start and end date.
Serviced entity: The claim line serviced entity must have an insurable entity code and type code identical to the specified code and type.
Entry start date and entry end date: The claim entry date must be between (inclusive) the specified start and end date.
Claim form, type and status: The claim line must belong to a claim of the specified claim form and claim type. The claim to which the claim line belongs must be in the specified status. Note that the possible status are confined to: CHANGE, MANUAL PRICING, MANUAL PRICING ADJUDICATION, MANUAL BENEFITS, MANUAL ADJUDICATION, PRICING FINALIZED and FINALIZED.
Process type: The process type of the claim - Reservation or Claim. This is a mandatory criteria.
Procedure group or condition: One or more of the claim line procedures must belong to the procedure group on the service start date or one or more of the claim line procedures must meet the procedure condition.
Diagnosis group or condition: The primary claim line diagnosis must belong to the diagnosis group on the service start date, or the primary claim line diagnosis must meet the diagnosis condition. The primary claim line diagnosis is the diagnosis with the lowest sequence value.
Benefits provider group: The claim line benefits provider must belong to the provider group on the service start date of the claim line. "Belong to" implies the same functionality that is used to determine whether a provider is in the scope of a certain provider group (an extensive description including examples, is given in the Benefits part of the claims flow).
Price provider group: The claim line price individual provider or the price organization provider must belong to the provider group on the service start date of the claim line.
Service provider group: The claim line service provider must belong to the provider group on the service start date of the claim line.
Location provider group: The claim line location provider must belong to the provider group on the service start date of the claim line.
Claimant provider group: The claim claimant provider must belong to the provider group on the service start date of the claim line.
Product: The claim line has benefits applied from this product. Note that specifying a product in the request message implies that only those claims for which the benefits are actually applied are considered for reprocessing.
Coverage regime: The claim line has benefits applied from this coverage regime. Note that specifying a regime in the request message implies that only those claims for which the benefits are actually applied are considered for reprocessing.
Fee Schedule: The claim line is priced using a fee schedule line that belongs to this fee schedule
Message group: The claim line must have a message attached that is in the specified message group.
Pend reason (attribute pendReasonCode): The claim and/or claim line must have a pend reason with the specified code.

The criteria request also contains information that is used during processing of the claims. For example the unfinalized reason that should be attached to unfinalize a claim for re-process it.

Response message

The system validates the criteria request and accepts it for processing. It sends out a response as per the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book. The response message can have failure message related to the validation of the criterion or attributes to be used in claims processing e.g., "Product code ABC unknown" or Unfinalize reason {code} is unknown or 'The process type is unknown'. The system also returns a link to the asynchronous process that it starts in the location header :

Location: http://[hostName]:[portNumber]/[api-context-root]/activities/{activityid}

The external system can track the status of the process by using GET operation on the mentioned uri. For details refer to the section Get Activity Status of the chapter Activity Integration Point in the Integration Points guide.

Once the request is validated and accepted; the system picks up claims for re-processing. When all the claims are scheduled for processing, a notification message can be sent out if an endpoint is configured. The endpoint to send notification can be configured using 'ohi.reprocessclaims.datafile.notification.endpoint'.

If the notification endpoint requires Authentication, please use Authentication Use Case: ClaimReprocessCriteriaResponseNotificationClient to set authentication. Please see section Outbound RESTful Service Invocations in Integration Guide for the process and more properties. The notification message has the following/common structure:

<notification correlationId="" workId="{activityId}" status="">
   <links>
     <link rel="file" href="http://host:port/api/datafilesets/{datafilesetcode}/datafile/{datafilecode}/data"/>
     <link rel="file" href="http://host:port/api/datafilesets/{datafilesetcode}/datafile/{datafilecode}/data"/>
     ...
    </links>
</notification>

The data file can be downloaded by using the "Get details of a data file" request from the data file set integration point. GET to uri : datafilesets/{datafilesetcode}/datafile/{datafilecode}/data will initiate a request to download the response message data file.

The data file has the following structure :

<claimsReprocessResponse>
  <resultMessages/>
</claimsReprocessResponse>

The elementId attribute that is included as part of the result messages element contains the code of the claim for which the messages are raised.

For each claim that is successfully processed an info message CLA-IP-REPR-022 is added.

If the request message was a <claimReprocessingCriteriaRequest> request and the attribute reprocess was unchecked, then the data file includes all the claim codes for which the request is successful (without additional details) with the response message CLA-IP-REPR-023.

Get Reprocess Count Request

The claim reprocess count request has the following structure:

<claimReprocessCountRequest
  serviceStartDate=""
  serviceEndDate=""
  entryStartDate=""
  entryEndDate=""
  claimStatus=""
  claimForm=""
  claimType=""
  processType=""
  procedureGroupCode=""
  diagnosisGroupCode=""
  benefitsProviderGroupCode=""
  priceProviderGroupCode=""
  claimantProviderGroupCode=""
  serviceProviderGroupCode=""
  locationProviderGroupCode=""
  productCode=""
  feeScheduleCode=""
  coverageRegimeCode=""
  messageGroupCode=""
  pendReasonCode="">
  <servicedEntity
    typeCode=""
    code=""/>
</claimReprocessCountRequest>

The request is posted to the uri: http://[hostName]:[portNumber]/[api-context-root]/claimsreprocesscount

This integration point provides an external system the ability to query and get the total number of claims, the total allowed amount, and the total covered amount that will get reprocessed when a particular criteria-request is processed. The system applies the same rules as listed above in processing each criterion.

Response Message

Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.

The response message holds the total number of claims, the total allowed amount and the total covered amount that will get reprocessed when a particular criteria-request is processed. When claims with differing currencies apply to the criteria only the total number of claims is returned, no total amounts.

<claimReprocessCountResponse count="">
   <totalAllowedAmout
     currency>
     {value}
   </totalAllowedAmout>
   <totalCoveredAmount
     currency>
     {value}
   </totalCoveredAmount>
</claimReprocessCountResponse>

Processing Details

The following flow shows what happens to a claim when it is picked up for reprocessing triggered by either 1) Claims Reprocess Online Request 2) Claims Reprocess Batch Request or 3) Claims Reprocess Criteria Request.

Only claims with the status CHANGE, MANUAL PRICING, MANUAL PRICING ADJUDICATION, MANUAL BENEFITS, MANUAL ADJUDICATION, PRICING FINALIZED and FINALIZED can be reprocessed.

Settled claims (finalized claims with a settlement reason on the external claims data) are not picked up for reprocessing. If a request includes a settled claim, message CLA-IP-REPR-027 is added to the response.

A reprocess request must specify the unfinalize reasons if the claim that is to be reprocessed is pricing finalized or finalized. It can also specify values for the dynamic fields on the unfinalized reason. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by the Oracle Health Insurance application, refer to the 'Attribute Handling' section in the HTTP API Integration Points part of the Common Features book.

When a reprocess request is for a claim that is in a pended status -The claim is set to the status CHANGE (if not in CHANGE). All pend reasons attached to the claim or claim line are removed. The pend history is updated as resolved based on the information from the user context. If there is an open task for one of the removed pend reasons, a workflow event (pend done) is sent out.

What happens next depends on the presence of pend reasons in the request. The request can specify one or more pend reasons. If so, the system pends the claim in the CHANGE status and the indicator preprocessingDone and pricingDone are set to N. All pend reasons specified in the request are attached to the claim. A new workflow task event is sent out in case at least one of the pend reasons has a checked "publish message" indicator. If no pend reasons are specified, the claim is resubmitted (brought to INITIAL status) and the pricingDone is unchecked (false)

The request allows the claim field preprocessingDone to be updated. Setting this attribute to the value true means that the claim is not sent out for preprocessing. The claim field pricingDone can also be updated through the request. Setting this attribute to the value true means that the claim is not sent out for pricing.

An update of the claim tag actions is also possible through the integration point(s). The allowable values are R (Redo), S (Skip), H (Hold) and F (Force). Note that the claim tag actions that are configured as being possible are first created through a business rule. The claim tag actions that are sent in are just updates of the existing claim tag actions. If a claim tag action is sent in for a skip tag that was not created as a claim tag action, then nothing happens: no claim tag action is created nor any message is generated. There is a provision: an existing tag action of Skip is left untouched unless it is explicitly overruled through a checked override skip indicator.

The message specified as the 'reprocessMessageCode' is attached to the claim header. This provides the requesting party with a way to 'mark' a reprocessed claim or to provide an explanation as to why the claim is reprocessed.

All the claims that are being reprocessed are marked as high priority claims if the indicator setToHighPriority is true. If setToHighPriority is not set to true, then the high priority indicator of all claims involved is left untouched.

The following messages are the result of the inability to validate or process any of the above request.

Table 1. Processing Details
Code	Sev	Internal Message	Request
CLA-IP-REPR-001	Fatal	Product code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-002	Fatal	Provider group code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-003	Fatal	Procedure group code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-004	Fatal	Procedure condition code {code} is unknown	Reprocess Claims Criteria Request
CLA-IP-REPR-005	Fatal	Diagnosis group code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-006	Fatal	Diagnosis condition code {code} is unknown	Reprocess Claims Criteria Request
CLA-IP-REPR-007	Fatal	Regime code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-008	Fatal	Message code {code} is unknown	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-009	Fatal	Claim Form {code} is unknown.	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-010	Fatal	Claim code {code} is unknown	Reprocess Claim Request Reprocess Claims (Batch) Request
CLA-IP-REPR-011	Fatal	Serviced entity code {code} with type {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-012	Fatal	Message group code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-013	Fatal	Claim {code} cannot be reprocessed due to its current status	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-014	Fatal	Claim {code} is finalized. At least 1 unfinalize reason must be supplied to unfinalize the claim	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-015	Fatal	Unfinalize reason {code} is unknown	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-017	Fatal	It is not allowed to specify both a procedure group and a procedure condition	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-018	Fatal	It is not allowed to specify both a diagnosis group and a diagnosis condition	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-019	Fatal	A diagnosis condition must be specified in conjunction with a procedure group or procedure condition	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-025	Fatal	Start date must be before end date	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-026	Fatal	Pend reason code {code} is unknown	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-027	Fatal	The claim cannot be unfinalized because it is settled	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-028	Fatal	Claim {code} cannot be reprocessed because it is locked by another process	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-029	Fatal	Skip tag code {code} is unknown	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-031	Fatal	Skip tag action UNDO cannot be specified	Reprocess Claim Request Reprocess Claims (Batch) Request Reprocess Claims Criteria Request
CLA-IP-REPR-032	Fatal	Fee schedule code {code} is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-033	Fatal	Claim type is unknown	Reprocess Claims Criteria Request Get Reprocess Count Request
CLA-IP-REPR-034	Fatal	Claim status {status} is not a valid status for the request	Reprocess Claims Criteria Request Get Reprocess Count Request

Table 2. Confirmation Messages
Code	Sev	Internal message	Additional information
CLA-IP-REPR-022	Info	Claim with code {0} is scheduled for reprocessing	Reprocess Claims Criteria Request and reprocess = true
CLA-IP-REPR-023	Info	Claim with code {0} matches the given search criteria	Reprocess Claims Criteria Request and reprocess = false

Use Cases

Late Authorizations

It is possible that on the moment that a claim gets processed, the required authorization is not yet present in Claims. To prevent the premature denial of such claims, the payer wants to reprocess all claims that have been entered and finalized in the last month which were denied specifically because an authorization was required, but not found. By this, the payer aims to approve any claims for which an authorization has arrived in the time since the claim was first processed.

Additionally, the payer wants to attach a message to those claim lines that are reprocessed, to make it clear which claim lines have been reconsidered for authorization. The payer sets up the following message:

CUST1 - This claim line has been reprocessed for possible late authorizations.

Suppose, there are two messages that reflect a situation where an authorization was not found:

AUTH1 - Authorization required, but no authorization matches the search criteria - added to AUTHGroup1 message group.
AUTH2 - Authorization required. An authorization is found but has been fully consumed - added to AUTHGroup2 message group.

Suppose the current date is 2009-08-01. The payer would send the following request messages:

<claimReprocessCriteriaRequest
   claimStatus="FINALIZED"
   entryStartDate="2009-07-01"
   messageGroupCode="AUTHGroup1"
   reprocess="true"
   reprocessMessageCode = "CUST1"
   pricingDone="true">
</claimReprocessCriteriaRequest>

and

<claimReprocessCriteriaRequest
  claimStatus="FINALIZED"
  entryStartDate="2009-07-01"
  messageGroupCode="AUTHGroup2"
  peprocess="true"
  reprocessMessageCode = "CUST1"
  pricingDone="true">
</claimReprocessCriteriaRequest>

Note that two separate request messages are sent, one for claim lines with the messages "AUTHGroup1" and one for claim lines with a message "AUTHGroup2". These two messages will cause the following events:

Any final claim that has an entry date on or later than 2009-07-01 and has at least one claim line with the message AUTH1 or AUTH2 attached, is set back to the 'initial' status.
Any claim that is final and that has an entry date on or later than 2009-07-01 and has at least one claim line that has the message AUTH1 or AUTH2 attached, will now have a new message attached, i.e., the message with the code CUST1.

Suppose that Claims holds three claims that qualify for the first request message (claim codes C001, C002, C003) and one claim that qualifies for the second request message (claim code C004). Assuming the requests are processed successfully, Claims generates two response data files, one for each request:

<claimsReprocessResponse>
  <resultMessages result="S" elementId="C001">
    <resultMessage
      code ="CLA-IP-REPR-022">
      Claim with code C001 is scheduled for reprocess
    </resultMessage>
  </resultMessages>
  <resultMessages result="S" elementId="C002">
    <resultMessage
      code ="CLA-IP-REPR-022">
      Claim with code C002 is scheduled for reprocess
    </resultMessage>
  </resultMessages>
 <resultMessages result="S" elementId="C003">
    <resultMessage
      code ="CLA-IP-REPR-022">
      Claim with code C003 is scheduled for reprocess
    </resultMessage>
  </resultMessages>
</claimsReprocessResponse>

<claimsReprocessResponse>
 <resultMessages result="S" elementId="C004">
    <resultMessage
      code ="CLA-IP-REPR-022">
      Claim with code C004 is scheduled for reprocess
    </resultMessage>
  </resultMessages>
</claimsReprocessResponse>

1. It is recommended to process claims having process type reservation first and not to mix the claims with the different process types in a file.