Claims Pre-Finalized Out Integration Point

Several steps in the claims processing flow can make alterations to the claim or one of its claim lines. In some scenarios the changes made actually require the claim to be sent back upstream to re-iterate one or more pre-processing steps. For example, changing the servicing provider on the claim may require that the claim is externally repriced. This chapter describes the integration point through which unfinalized claims leave the system in the upstream direction.

Design Choices

  • The claim response message contains all available information on the claim and claim line.

    • This includes dynamic fields on the claim, claim lines, claim sub lines and diagnoses.

    • This includes processing fields (e.g., the price provider)

    • This includes information on how claim lines are bundled or unbundled.

    • This includes information on fields that could not be matched.

  • Dynamic fields on referenced entities are not included. For example, a dynamic field on the serviced person or object is not included.

  • Providers, persons & objects are identified by their respective codes. Note that person, object & provider codes are not OHI Claims Adjudication internal codes, but codes issued outside of OHI Claims Adjudication. It is possible that a claim is sent out for (re)pricing while not all providers and/or persons or objects are matched. For this reason, any non matched information for persons, objects & providers is sent out as well. In addition, for both the provider and person/object the name and date is sent out.

  • When a claim qualifies to be sent out, OHI Claims Adjudication can sends out an event using Claims Events IP. Adjoining applications can keep track of these event based notifications. Upon request, OHI Claims Adjudication will send out a response message containing the claim that is to be further processed by another application.

  • The response message only contains messages for EXTERNAL and MANUAL claim messages, and claim line messages.

Request Message

In the event that an external application wants to receive a copy of the claim, it needs to send a GET request to OHI Claims Adjudication on uri : http://[hostName]:[portNumber]/[api-context-root]/claimsprefinalizedout/{claim code}

Response Message

When OHI Claims receives a request message, a response message is sent back. If the requested claim does not exists, or does not have a status indicating that it is to be sent out, the following result messages are returned:

Code Sev Message

CLA-IP-PRFO-001

Fatal

The claim code {code} is unknown

CLA-IP-PRFO-002

Fatal

The claim {code} is not in status that allows it to be sent out

Only claims in the status SENT OUT FOR PREPROCESSING or SENT OUT FOR PRICING can be accessed through this integration point.

The following response message is returned:

<claim>
  <claimLineList>
     <claimLine/>
     ...
  </claimLineList>
</claim>

The following snippet contains the structure of the claim:

<claim
  authorizationCode
  brandCode
  claimDate
  code
  claimSetCode
  dataAccessGroupCode
  dueDate
  expirationDate
  externalRemarks
  form
  emergency
  highPriority
  ignoreHistory
  manual
  locationTypeCode
  nextPayerCode
  paidDate
  payerCode
  precedingPayerCode
  priceDate
  processType
  providerEntityReference
  providerReference
  receiptDate
  referenceCode
  serviceSpecialtyCode
  status
  transactionSourceCode
  type >
  <totalAllowedAmount/>
  <totalClaimedAmount/>
  <claimantProvider/>
  <claimantRelation/>
  <claimDiagnosisList/>
  <claimMessageList/>

  <locationProvider/>
  <paymentBeneficiaryProvider/>
  <paymentBeneficiaryRelation/>
  <paymentReceiverProvider/>
  <paymentReceiverRelation/>
  <paymentSpecificationReceiverProvider/>
  <paymentSpecificationReceiverRelation/>
  <referralProvider/>
  <serviceProvider/>
  <unfinalizeReasonList/>
</claim>

The following snippet contains the structure of the claim line:

<claimLine
  allowedNumberOfUnits
  authorizationCode
  authorizationExceptionType
  claimedNumberOfUnits
  code
  endDate
  encounter
  emergency
  keepBenefits
  keepPricePrincipalProcs
  keepPricing
  replaced
  originalClaimLineCode
  pricePrincipalProcedure1
  pricePrincipalProcedure2
  pricePrincipalProcedure3
  locationTypeCode
  priceInputDate
  priceInputNumberOfUnits
  processAsIn
  providerEntityReference
  providerReference
  sequence
  serviceSpecialtyCode
  startDate
  replacementClaimLineCode
  referenceCode
  transactionSourceCode>
  <allowedAmount/>
  <benefitsInputAmount/>
  <benefitsProvider/>
  <claimedAmount/>
  <claimLineContractReferenceList/>
  <claimLineDiagnosisList/>
  <claimLineLimits/>
  <claimLineMessageList/>
  <claimLineModifierList/>
  <claimLineOverride/>
  <claimLineParameterList/>
  <claimSubLineList/>

  <locationProvider/>
  <paymentReceiverProvider/>
  <paymentReceiverRelation/>
  <precedingPayerPaidAmount/>
  <priceIndividualProvider/>
  <priceOrganizationProvider/>
  <procedure/>
  <procedure2/>
  <procedure3/>
  <referralProvider/>
  <serviceProvider/>
</claimLine>

Sending out unmatched codes

It is possible that a claim is sent out for (re)pricing while not all information on the claim has been mapped to reference data. If this is the case, then the response message contains the unmatched codes.

This is explained in more detail for insurable person/objects and providers. For all other elements that are possibly non-matched, the response message will simply contain the unmatched code. For example, if a procedure code could not be matched, then the <procedure> element will contain the non matched "code" & "flex code definition code" instead of an actual code & flex code definition code (as stored in the Procedure table).

Apart from the insurable person/object, relation(claimant, payment receiver,
provider, the following attributes may contain an unmatched code:

  • element procedure, procedure2 and procedure3, attribute 'code'

  • element procedure, procedure2 and procedure3, attribute 'flexCodeDefinitionCode'

  • element diagnosis on claim and claim line , attribute 'code'

  • element diagnosis on claim and claim line , attribute 'flexCodeDefinitionCode'

  • element diagnosis on claim and claim line , attribute 'typeCode'

  • elements claim and claimLine, attribute 'servicingSpecialtyCode'

  • elements claim and claimLine, attribute 'authorizationCode

  • elements claim and claimLine, attribute 'locationTypeCode''

  • element claimLineModifier, attribute 'code'

  • element message on claim and claim line, attribute 'code'

  • element claimLineContractReference, attribute 'code'

Sending out logically assumed values

The OHI claims model allows a number of fields to be stored on more than one level. For example, the list of diagnoses codes can be specified on both the claim header and the claim line. These fields are:

  • serviced person

  • serviced object

  • service provider

  • service specialty

  • location

  • referral provider

  • authorization code

  • emergency indicator

  • payment receiver

  • diagnoses

  • location type

In context of these fields, this integration point behaves as follows

  • If the claim line field is unspecified, then the value of its counter part field on the claim level is sent out.

    • If the fields has dynamic data(fields and/or records), only the data that is also configured on the claim line level, will be sent out.

      • Consider an example where there is a dynamic field on claim diagnosis as patientAttendance. In case there are no claim line diagnoses present, the claim diagnosis will be sent out on the claim line level. The dynamic field on the claim diagnosis will only be part of the claim line level, if the same is configured on claim line diagnosis also.

  • If the claim line field is specified, then that value is sent out.

Amounts

Each element that represents an amount holds a fixed set of attributes. Consider the <allowedAmount> element to clarify:

...
  <allowedAmount
    currencyCode>
    {value}
  </allowedAmount>
...

Dynamic fields

For details on how the dynamic fields and dynamic records are handled by the OHI application, refer to the refer to the concepts in the Integration Guide.

Diagnoses

The claim can contain one or more diagnoses on the claim and claim line level.

<claimDiagnosisList>
  <claimLineDiagnosis
   sequence
   typeCode />
    <diagnosis
      code
      flexCodeDefinitionCode/>
  </claimLineDiagnosis >
</claimDiagnosisList>

Procedures

Claim lines and claim sub lines can contain one or more procedures per line. The <procedure> element structure is the same for both levels.

<procedure
   code="56.00"
   flexCodeDefinitionCode="ICD-09-CM"
/>

Messages

The claim can contain one or more messages on the claim and claim line level. Each message contains the message code, the message origin (EXTERNAL or MANUAL) and the placeholders.

Consider the following example:

<claimLineMessageList>
  <claimLineMessage
    code
    origin
    value0
    value1
    value2
    value3
    value4
    value5
    value6
    value7
    value8
    value9
    transactionSourceCode
    referenceCode/>
</claimLineMessageList>

Providers

The following elements in the pre-finalized out claim message represent providers:

  • <serviceProvider>

  • <location>

  • <referralProvider>

  • <benefitsProvider>

  • <priceOrganizationProvider>

  • <priceIndividualProvider>

  • <claimantPovider>

  • <paymentBeneficiaryPovider>

  • <paymentReceiverPovider>

  • <paymentSpecificationReceiverPovider>

Providers, both organizations & individuals, are identified by their code and flex code definition.

The provider has the following structure (consider service provider to clarify)

<serviceProvider
  code
  flexCodeDefinitionCode
  name/>
  <matchingContext
    nonMatchedName
    nonMatchedAddress
    <dynamicField
     name
     value/>
  <matchingContext/>
</serviceProvider>

In the event that a provider was successfully matched, then the provider code, the provider code flex code definition code and the provider name are sent out. For individual providers, the formatted name is used.

Consider the following example:

...
<serviceProvider
  code="1234567890"
  flexCodeDefinitionCode="NPI"
  name="John Smith">
</serviceProvider>
...

However, in the event that OHI Claims is unable to find a matching record for a provider, any information that is stored for the purpose of establishing a manual match is sent out as well.

...
<serviceProvider
   code="1234567890"
   flexCodeDefinitionCode="NPI"
  />
  <matchingContext
   nonMatchedName ="John Smith"
   nonMatchedAddress="H.P. Hospital"
   <dynamicField
     name ='ReferenceNumber"
     value="7843748374"/>
  <matchingContext/>
</serviceProvider>
...

Relations

The following elements in the message represent relations

  • <claimantRelation>

  • <paymentBeneficiaryRelation>

  • <paymentReceiverRelation>

  • <paymentSpecificationReceiverRelation>

The relation has the following structure (consider claimant relation to clarify)

<claimantRelation>
  code
  dateOfBirth
  name>
  <matchingContext
    nonMatchedName
    nonMatchedAddress
    <dynamicField
      name
      value/>
  <matchingContext/>
</claimantRelation>

Serviced Person and Object

The following elements in the pre-finalized out claim message represent serviced persons:

  • <insurableEntityType.usageName>

The insurable entity of the type person has the following structure

  <matchingContext
    nonMatchedName
    nonMatchedAddress
    <dynamicField
      name
      value/>
  <matchingContext/>

In the event that the serviced person was successfully matched, only the code, formatted name and date of birth are sent out.

In case the serviced person is not matched, any information that is stored for the purpose of establishing a manual match is sent out as well. Consider the following example.

...
<persons
  code="HP23453" -- as in the SERVICED ENTITY CODE
  name=""
  dateOfBirth="2001-02-02" -- as in the SERVICED ENTITY DATE />
   <matchingContext
    nonMatchedName =""Jones, M.A.""  --as in the SERVICED ENTITY NAME
    nonMatchedAddress
    <dynamicField
      name ='ReferenceNumber"
      value="432423423"/>
    <matchingContext/>
...

In the event that the serviced object was successfully matched, only the code and description is sent out. In case the serviced object is not matched, any information that is stored for the purpose of establishing a manual match is sent out as well.

Unfinalize Reasons

The claim can contain one or more unfinalize reasons on the claim level.

Consider the following example:

...
<unfinalizeReasonList>
   <unfinalizeReason
      code="UNF44"
      sourceReference=""
   />
</unfinalizeReasonList>
...

Bundled and unbundled claim lines

A bundled claim line is a claim line that replaces one or more other claim lines in the same claim. This is stored in the claims model by maintaining a reference in the replaced lines to the replacing claim line.

Consider a scenario in which claim lines 1, 2 are replaced by (have been bundled into) claim line 3:

claim>
...
  <claimLineList>
    <Claimline code="1"
      ....
      replacementClaimLineCode ='3'
      replaced='Y'/>
    <Claimline code="2"
      ....
      replacementClaimLineCode ='3'
      replaced='Y'/>
     <Claimline code="3"
      ..../>
  <claimLineList>
<claim>

An unbundled claim line is a claim line that is replaced by one or more other claim lines in the same claim. This is stored in the claims model by maintaining a reference in all the replacing claim lines towards the original unbundled claim line.

Consider a scenario in which claim line 4 is replaced by (has unbundled into) claim line 5, 6:

<claim>
  <claimLineList>
    <Claimline code="4"
      ....
      indReplace='Y'/>
    <Claimline code="5"
      ...
      originalClaimLineCode ="4"/>
     <Claimline code="6"
      ...
      originalClaimLineCode ="4"/>
  </claimLineList>
</claim>

The claim line code attribute is used to identify claim lines within a claim message. A claim line code is unique within a claim.