Adjudication Case Integration Point

The Adjudication Case Integration Point provides the ability to start and end adjudication cases from an outside source. This can be used for the following purposes

to migrate historical cases from an old system to OHI Claims.
to open an adjudication case as result of a transaction in another system. This can be used to
- open an adjudication case when an authorization is used as the evidence for the fact that the person or object is in an adjudication case and that certain procedure codes for the person or object should be seen as ancillary to this authorization induced adjudication case.
- open an adjudication case that is triggered by a claim line in another claims adjudication system.

Design principles

This interface is implemented by XML messages. The XML messages are defined in pairs using XML schemas (XSDs). Each pair of messages consists of a request and a response. Request messages are sent by external interfaces. Each contains details an adjudication case that be needs to be recorded or updated in OHI Claims. For each request message that an external interface sends, exactly one response message is returned. The response message will return 'S' (Success) if the adjudication case has been successfully inserted or updated. It will return 'F' (Failure) if the insert or update was not successful accompanied by one or more result messages to provide further details.

External interfaces will determine when request messages are sent and what data they contain. This chapter does not discuss logging, time stamps and message (correlation) identifiers (e.g. as needed for matching a given response message with its request message). These aspects are covered by the overall messaging framework.

Note that this change does not allow for the Read and Write of external consumption to an Adjudication Case. This needs to be catered for in a change to the Counter Integration Point.

Write Case

Request

If the adjudication case does not exist a new case with the specified details is opened. For new adjudication cases, a primary case detail is mandatory.

If an adjudication case with the same case definition, person or object code and start date already exists the existing adjudication case is updated. This is done in the following way

End date

The registered end date is replaced by the end date in the write case request. When the end date in the request is empty and the registered end date is populated then the registered end date is nullified. When ancillary claim lines are attached to an adjudication case and the end date is updated in such a way that the service date of the ancillary claim line is now outside of the period of the adjudication case then the update will still take place without automatically reprocessing the ancillary claim lines. If an existing, partially overlapping case for the same serviced person or object and case definition exists, then either the existing case is end dated one day prior to the start date of the new case or the new case is end dated one day prior to the existing case.

Adjudication case details

If a list of adjudication case details is sent then all the existing adjudication case details are replaced by the new list. If the list of adjudication case details is not present in the request, so if there is no adjudicationCaseDetails element, the current adjudication case details are kept. This only applies to adjudication case details that have been sent in through this Adjudication Case Integration Point. Adjudication case details that link internal claim lines to an adjudication case are neither removed nor automatically reprocessed as a result of the replacement of the external adjudication case details.

Provider Group Scope and Ind Denied

When a new case is inserted and a external primary claim line is specified, OHI Claims needs to know whether the primary external claim line was denied and how to evaluate the provider group scope inheritance for ancillary lines. For this reason, an external primary claim line needs to inform OHI Claims with respect to the provider group scope and the denied indicator. Likewise, this information should not be given for ancillary external claim lines. These validations are done though business rules.

Once used by claims processing for ancillary internal claim lines, this information can be updated through the Adjudication Case Integration Point, but it will not have effect by means of automatic reprocessing. Consider the following situation

An adjudication case has been sent in through the integration point and this adjudication case is used to attach ancillary internal claim lines.
These internal claim lines have either inherited the provider group scope or have been denied because of the denied indicator.
The adjudication case is updated through the Integration point and the value for the provider group scope or the denied indicator are changed

Then these changes in provider group scope and/or denied indicator will have no effect on the ancillary internal claim lines.

Remove

Adjudication cases cannot be removed nor invalidated through this integration point.

<writeCaseRequest
  <adjudicationCase
    caseDefinitionCode=""
    startDate=""
    endDate=""
  >

    <dynamicFields/>
  </adjudicationCase>
  <adjudicationCaseDetails>
    <adjudicationCaseDetail
      subtype="P/A"
      externalDescription=""
      providerGroupScope="I/O"
      indDenied="Y/N"
      transactionSourceCode=""
      referenceCode= ""
    >
    <dynamicFields/>
    </adjudicationCaseDetail>
  </adjudicationCaseDetails>
</writeCaseRequest>

Response

The structure of the response message is as follows:

<writeCaseResponse
  caseDefinitionCode=""
  startDate=""
  endDate=""
>

  <resultMessages
    result=""
  >
    <resultMessage
      code=""
      messageText=""
    </resultMessage>
  </resultMessages>
</writeCaseResponse>

The following messages may be returned in the response:

Code	Sev	Message
CLA-IP-CASE-001	Fatal	Case definition code {0} is unknown
CLA-IP-CASE-002	Fatal	Insurable entity identified by code {code} and type {code} is unknown
GEN-TMVL-003	Fatal	{0} should be later than or the same as {1}
CLA-IP-CASE-003	Fatal	An adjudication case should contain a primary line

Code

Sev

Message

CLA-IP-CASE-001

Fatal

Case definition code {0} is unknown

CLA-IP-CASE-002

Fatal

Insurable entity identified by code {code} and type {code} is unknown

GEN-TMVL-003

Fatal

{0} should be later than or the same as {1}

CLA-IP-CASE-003

Fatal

An adjudication case should contain a primary line

Use cases

Registering a case

John Doe with person code JD678123 has been admitted into a hospital for a long term admission. This has been registered in the old Claims adjudication system. The employer group for John Doe is now migrated to OHI Claims. In that context the adjudication case for the admission has to be migrated. This is done by sending the following request to OHI Claims.

<writeCaseRequest
  <adjudicationCase
    caseDefinition="HOSPADMISSION"
    startDate="2011-07-01"
  >

  </adjudicationCase>
  <adjudicationCaseDetails>
    <adjudicationCaseDetail
      subtype="P"
      externalDescription='Transferred from claim 987123, line 3'
      providerGroupScope='I'
      indDenied='N'
      transactionSourceCode="OLDCLAIMS"
      referenceCode= "987123-3"
    />
   <adjudicationCaseDetail
      subtype="A"
      externalDescription='Transferred from claim 987189, line 2'
      transactionSourceCode="OLDCLAIMS"
      referenceCode= "987189-2"
    />
 </adjudicationCaseDetails>
</writeCaseRequest>

Updating the end date of a case

When a case has initially been registered without an end date and this end date needs to be set, or an existing end date needs to be changed, then this can be done by sending a request for the specific case definition, person and start date with a populated end date.

To set the end date for the previous request

<writeCaseRequest
  <adjudicationCase
    caseDefinition="HOSPADMISSION"
    startDate="2011-07-01"
    endDate="2011-09-30"
  >

  </adjudicationCase>
</writeCaseRequest>

This sets the end date of the adjudication case to september 30th, 2011.

To change the end date for an adjudication case the following request can be sent.

<writeCaseRequest
  <adjudicationCase
    caseDefinition="HOSPADMISSION"
    startDate="2011-07-01"
    endDate="2011-10-31"
  >

  </adjudicationCase>
</writeCaseRequest>

This updates the end date of the adjudication case to october 31th, 2011.

To erase the end date the following request can be sent.

<writeCaseRequest
  <adjudicationCase
    caseDefinition="HOSPADMISSION"
    startDate="2011-07-01"
    endDate=""
  >

  </adjudicationCase>
</writeCaseRequest>

Registering a case for an authorization:

The registration of a case for an authorization is similar to the registration of an adjudication case for migration purposes. Note however that the logic to decide when an adjudication case for an authorization needs to be created is situated in the integration handler between the Authorization Component and OHI Claims, so this logic does not reside in OHI Claims.

<writeCaseRequest
  <adjudicationCase
    caseDefinition="HOME_HEALTH_CARE"
    startDate="2011-07-01"
    endDate="2011-08-20"
  >

  </adjudicationCase>
  <adjudicationCaseDetails>
    <adjudicationCaseDetail
      subtype="P"
      externalDescription='Authrozation 566512'
      providerGroupScope='I'
      indDenied='N'
      transactionSourceCode="AUTH_SYS"
      referenceCode= "566512"
    />
 </adjudicationCaseDetails>
</writeCaseRequest>