Payment Status Integration Point

The purpose of this interface is to check the payment status of a serviced person or object, before any benefits are paid. Depending on the adjudication rules and the severity of the response messages, certain payment statuses may cause a claim to pend or automatically deny.

Design Choices

A payment status request is sent per serviced person or serviced object.
The response consists of a number of message codes. These codes match customer defined message codes set up in OHI Claims. Each of these messages should reflect specific information regarding the payment status. It is possible to specify parameters in the response message that will populate the message text placeholders.
The message codes in the response are listed per (Executable) Product
Pends based on the payment status are handled as follow: The payer has to make sure that the message codes in the payment status response refer to informative messages, rather than fatal messages. The payer has to set up an external intervention rule that triggers whenever a payment status info message is encountered. The effect of the triggered external intervention rule is that the OHI Claims pends the claim and sends out a workflow notification through the workflow integration point.
For each request message that OHI Claims sends out, exactly one response message is expected to return. OHI Claims expects exactly one response, per sent request.
Within the context of this integration point, OHI Claims generates the request message.
The use of this integration point is optional. In the event that the payment status information is provided through another integration point (or not at all) this integration point can be disabled by a setting in the OHI properties file.

Request

XML schema for the request in pseudo code:

<paymentStatusRequest
  startDate=""
  endDate=""
>

   <product
      code=""
   />
   ...
</paymentStatusRequest>

At the point that the payment request is sent out, OHI Claims will have collected the enrollment information of the serviced person or object. The request contains an identifier of the person or object, and the time period for which the payment status is to be checked. Additionally, the request specifies one or more products.

The start and end date are included in the request to inform the responding in which OHI Claims is interested in the payment status.

Response

XML schema for the response in pseudo code:

<paymentStatusResponse>
  <insurableEntity
    typeCode=""
    code=""
  />
  <products>
    <product
      code=""
      startDate=""
      endDate=""
    >
      <messages>
        <message
          code=""
          parameter0=""
          (through)
          parameter9=""
          referenceCode
          transactionSourceCode=""
         />
         ...
       </messages>
     </product>
    ...
  </products>
</paymentStatusResonse>

The insurableEntity is included for reference purposes only. It is not used to match a payment status request to a response. Matching a response to the correct request is the responsibility of the interface protocol.

Time validity

A payer may want to respond differently given the moment on which that person or object is first marked as "behind on payment" and the service date on claims for it. For this reason, messages in the response are listed per product and each product has a time period. To clarify the possible ways to respond, consider the following scenario:

A person has two products: product BASIC and product DENTAL. The person is behind on payments only for the DENTAL product, and only since May 2009.

In August 2009 the payer receives a claim for that person that is covered by the DENTAL product. The claim service date is in February 2009. The payer now has two ways to resolve this situation:

The payer denies (or pends) the claim, because the person is behind on payments on the day that the claim is processed.
The payer pays the claim, because the person was not behind on payment on the claim service date.

Both resolutions are supported by this integration point. The choice is manifest in the response message: if the response states that any claim that is covered by the DENTAL product, for the entire requested time period, should be marked as late for payment, then the first resolution is realized. If the response states that any claim that is covered by the DENTAL product, which has a service date in or after May 2009, should be marked as late for payment, then the second resolution is realized.

Note that whether payment status information causes a claim to pend or automatically deny is setup choice. There is no logic in the interface, i.e., the interface merely provides the information upon which an adjudication rule may trigger.

Multiple products

As stated before, one serviced person or object can have multiple products simultaneously. It is up to the payer how to resolve situations where the person’s or object’s payments for one product are behind the schedule, but not for the other. Consider the following addition to the scenario mentioned earlier:

In October 2009, the payer receives a claim for the person that is covered by the BASIC product. The person is still behind on payment for the DENTAL product. The payer has two ways to resolve the situation:

The payer denies (or pends) the claim, because the person is behind on payments on a product (regardless of which product)
The payer pays the claim, because the person was not behind on payment on the product that provides the coverage, i.e., the BASIC product.

Both resolutions are supported by this integration point. Again, the payer’s choice is manifest in the response message. If the payer wants to deny (or pend) the claim it will mark the BASIC product as "late for payment" even though the payment is really only behind on the DENTAL product. If the payer wants to pay the claim, then it will simply not mark the BASIC product.

Note that, even though it is not explicitly mentioned in the scenario, time validity can also be relevant in a scenario with multiple products. For example, a payer can choose to deny (or pend) only those claims that are covered by the product that is behind on payments AND only if the service date is after the moment that the person’s or object’s payment were actually first behind.

Response Acknowledgement

Upon receiving the payment status response, OHI Claims sends back an acknowledgement message. This acknowledgement can contain the following error messages.

Code	Sev	Message
CLA-IP-PMSS-005	Fatal	Payment status response with correlation id {id} is already received
CLA-IP-PMSS-006	Fatal	Payment status request with correlation id {0} could not be found
CLA-IP-PMSS-007	Fatal	Payment status request with correlation id {0} has already timed out

Code

Sev

Message

CLA-IP-PMSS-005

Fatal

Payment status response with correlation id {id} is already received

CLA-IP-PMSS-006

Fatal

Payment status request with correlation id {0} could not be found

CLA-IP-PMSS-007

Fatal

Payment status request with correlation id {0} has already timed out

Notes:

CLA-IP-PMSS-005 is raised when a payment status response contains correlation information that refers to a payment status request message for which a response was already received earlier.
CLA-IP-PMSS-006 is raised when a payment status response contains correlation information for which the correlating payment request message cannot be found. I.e. when the payment status response message refers to a payment status request message that does not exist.
CLA-IP-PMSS-007 is raised when a payment status response is received after the payment status request has timed out. In this case an error task for the time out is already displayed in the UI page "View Technical Errors" (Operations menu). This task needs to be reprocessed to re-execute the payment status callout from the start.

Processing

For each claim, the distinct persons and objects on that claim are listed, including the products on which the they are enrolled. The start and end date in the request equal the start and end date on the claim. For each distinct person or object, a single request message is sent out. If one claim contains multiple serviced persons and objects, then multiple requests are sent out for that claim.

Once a response message is received, the following happens:

All claim lines in the processed claim for the pertaining serviced person or object are selected. For each <product> in the response message two criteria are evaluated, per claim line:

Is one of the policy products for the claim the same as identified by the code in the <product> element?
Is the service start date on the claim line in between the start & end date on in the <product> element?

If the claim line meets these conditions, the message(s) in the response is(are) attached to the claim line. The severity of the message (fatal or informative) depends on the setup of the message. Note that the code of the product to which the message applies is also stored.

Note that by adding a message to the claim line, it is now possible to setup a criteria for manual adjudication that will trigger on this message, thus supporting the concept of pending a claim due to late payments. Such criteria for manual adjudication must be setup separately.

Note that locked claim lines and replaced claim lines are ignored during the processing.

Use cases

Consider the following situation:

A person is enrolled on two products: BASIC & DENTAL. The person is behind on payments only for the DENTAL product since 2009-08-01. The person’s relation code is 1234. The person sends in a claim with three claim lines:

line 1 has service date 2009-05-15 (will be covered by DENTAL)
line 2 has service date 2009-10-01 (will be covered by BASIC)
line 3 has service date 2009-11-02 (will be covered by DENTAL)

Note that is unknown which line is covered by which product at the time that the payment status request is sent out.

The claim is processed on 2009-12-01. The payment status request looks like this:

<paymentStatusRequest
   startDate="2009-05-15"
   endDate="2009-11-02"
>

   <product
      code="DENTAL"
   />
   <product
      code="BASIC"
   />
</paymentStatusRequest>

The payer can handle this a number of ways. Let us consider four scenarios.

In the first scenario, the payer wants to automatically deny those claim lines - and only those claim lines - that are covered by benefits in a product for which the person is currently behind on payment. Following this logic, the payer wants to deny payment on line 1 & 3, but pay claim line 2.

The payer sets up a fatal message with the code LATE. The response would have to look like this:

<paymentStatusResponse>
    <insurableEntity
    typeCode="PERSON"
    code="1234"
  />
  <product
    code="DENTAL"
    startDate="2009-05-15"
    endDate="2009-11-02"
  >
    <message
      code="LATE"
    />
  </product>
</paymentStatusResponse>

The message with the code "LATE" is set up to have a fatal severity. Note that the period covers the entire requested period, because the payer wants to pay or deny based on the current payment status.

The message LATE is attached to all three claim lines, as all service dates fall within the response start and end date
Once OHI Claims determines the coverages, it becomes apparent that line 2 is not covered by DENTAL. As a consequence the product (DENTAL) specific message LATE is ignored for this line. Assuming that there are no other applicable fatal messages, line 2 is approved.
Since line 1 and 3 are covered by DENTAL, the product (DENTAL) specific message LATE applies to both lines. Both lines are denied.

In the second scenario, the payer wants to automatically deny those claim lines - and only those claim lines - that are covered by benefits in a product for which the person was behind on payment at the time that the service was provided. Following this logic, the payer wants pay claim lines 1 & 2, but deny line 3. The response would have to look like this:

<paymentStatusResponse>
    <insurableEntity
    typeCode="PERSON"
    code="1234"
  />
  <product
    code="DENTAL"
    startDate="2009-08-01"
    endDate="2009-11-02"
  >
    <message
      code="LATE"
    />
  </product>
</paymentStatusResponse>

The message with the code "LATE" is set up to have a fatal severity. Note that the period start date is the moment from which the person was behind on payment, because the payer wants to pay or deny based on the payment status at the time of the service date.

The message LATE is attached to claim lines 2 and 3, as both service dates for these lines fall within the response start and end date. Because line 1 has a service date prior to 2009-08-01 it does not get the 'LATE' message. Assuming that there are no other applicable fatal messages, line 1 is approved.
Once OHI Claims determines the coverages, it becomes apparent that line 2 is not covered by DENTAL. As a consequence the product (DENTAL) specific message LATE is ignored for this line. Assuming that there are no other applicable fatal messages, line 2 is approved.
Since line 3 is covered by DENTAL, the product (DENTAL) specific message LATE applies. Line 3 is denied.

In the third scenario, the payer wants to automatically deny all claim lines for a serviced person who is behind on at least one product, regardless of whether or not that is also the product that provides coverage, based on the current payment status. Following this logic, the payer wants to deny both payment on line 1, 2 and 3.

The payer sets up two fatal messages:

message LATE, implying that the serviced person is behind on payments on the covering product
message OTHERLATE, implying that the person is behind on payments for a product other than the covering product.

The response would look like this:

<paymentStatusResponse>
  <insurableEntity
    typeCode="PERSON"
    code="1234"
  />
  <product
    code="DENTAL"
    startDate="2009-05-15"
    endDate="2009-11-02"
  >
   <messageCodes>
     <messageCode
       code="LATE"
      />
      ...
    </messageCodes>
  </product>
  <product
    code="BASIC"
    startDate="2009-05-15"
    endDate="2009-11-02"
  >
    <message
      code="OTHERLATE"
    />
  </product>
</paymentStatusResponse>

The response contains messages for every covering product. Claim lines 1 and 3 will have the LATE message attached. Claim line 2 will have the OTHERLATE message attached. All claim lines are denied.

Note that the payer uses two different fatal messages. This is a configuration choice, e.g., using different messages allows for a more specific explanation of the reason for denial on the claim specification.

In the fourth scenario, the payer wants to pend all claims for persons who are currently behind on payments for one of the covering products. The payer sets up a single INFO message:

message LATEPEND, implying that the person is behind on payments an enrolled product

The response would look like this:

<paymentStatusResponse>
    <insurableEntity
    typeCode="PERSON"
    code="1234"
  />
  <product
    code="DENTAL"
    startDate="2009-05-15"
    endDate="2009-11-02"
  >
    <messageCodes>
      <messageCode
        code="LATEPEND"
      />
      ...
    </messageCodes>
  </product>
</paymentStatusResponse>

Additionally the payer has set up an external intervention rule that pends a claim whenever the LATEPEND message is attached to one of the claim lines.