Claims In Integration Point

This integration point is the primary entry point for claims into the application. This integration point supports both the creation of new claims and the replacement of existing claims.

Claims In Request

Claims In request message must be sent to PUT: uri: http://[hostName]:[portNumber]/[api-context-root]/claims. The request message has the following structure:

<claim
  code
  authorizationCode
  brandCode
  claimDate
  dataAccessGroupCode
  dueDate
  externalRemarks
  expirationDate
  formCode
  claimSetCode
  emergency
  externalBenefits
  externalPricing
  highPriority
  ignoreHistory
  overwriteClaim
  preprocessingDone
  pricingDone
  sendOutForPreprocessing
  sendOutForPricing
  locationTypeCode
  nextPayerCode
  paidDate
  payerCode
  precedingPayerCode
  priceDate
  providerEntityReference
  providerReference
  processType
  serviceSpecialtyCode
  receiptDate
  referenceCode
  transactionSourceCode
  type>
  <claimantProvider/>
  <claimantRelation/>
  <claimDiagnosisList/>
  <claimMessageList/>
  <enrollmentList/>
  <locationProvider/>
  <paymentBeneficiaryProvider/>
  <paymentBeneficiaryRelation/>
  <paymentReceiverProvider/>
  <paymentReceiverRelation/>
  <paymentSpecificationReceiverProvider/>
  <paymentSpecificationReceiverRelation/>
  <referralProvider/>

  <serviceProvider/>
  <claimTagActionList/>
  <claimUnfinalizeReasonList>
    <claimUnfinalizeReason
      code=""
      sourceReference=""
    />
  </claimUnfinalizeReasonList>
  <claimLineList>
    <claimLine/>
      ...
  </claimLineList>
</claim>

The following snippet contains the structure of the claim line

<claimLineList>
  <claimLine
    allowedNumberOfUnits
    authorizationCode
    authorizationExceptionType
    benefitsAgeInputDate
    benefitsInputDate
    claimedNumberOfUnits
    code
    endDate
    encounter
    emergency
    keepBenefits
    keepPricePrincipalProcs
    keepPricing
    pricePrincipalProcedure1
    pricePrincipalProcedure2
    pricePrincipalProcedure3
    unlock
    locationTypeCode
    orginalClaimLineCode
    priceInputDate
    priceInputNumberOfUnits
    processAsIn
    providerEntityReference
    providerReference
    referenceCode
    replacementClaimLineCode
    serviceSpecialtyCode
    sequence
    startDate
    transactionSourceCode
    waitingPeriodInputDate>
    <allowedAmount/>
    <benefitInputAmount/>
    <benefitsProvider/>
    <claimedAmount/>
    <claimLineContractReferenceList/>
    <claimLineDiagnosisList/>
    <claimLineLimits/>
    <claimLineMessageList/>
    <claimLineModifierList/>
    <claimLineOverride/>
    <claimLineParameterList/>
    <claimSubLineList/>
    <locationProvider/>
    <paymentReceiverProvider/>
    <paymentReceiverRelation/>
    <precedingPayerPaidAmount/>
    <priceIndividualProvider/>
    <priceOrganizationProvider/>
    <procedure/>
    <procedure2/>
    <procedure3/>
    <referralProvider/>

    <serviceProvider/>
  <claimLine>
  ...
</claimLinesList>

Relations and Providers

A claim contains a number of roles. Each role is represented by a relation or provider. In the claims model, such a role is stored by creating a reference from the claim entity to the relation or provider entity. Some roles can be represented by either a relation or a provider, e.g., the claimant. On restitution claims the claimant is likely to be a person, i.e., a person in the OHI Claims Adjudication and Pricing data model, while on provider claims the claimant is likely to be a provider. In order to support this situation, the message has both the provider and relation element type for the following roles: the claimant, the payment receiver, the payment specification receiver and the payment beneficiary. However only one needs to be specified. When both are specified system returns GEN-RULE-008: Of the following items, a maximum of one may be used: "{0}, {1)".

A claimant that is represented as a provider the <claimantProvider> element is included and if the claimant is a relation, a <claimantRelation> element is included.

Provider Element

The provider element contains the following attributes:

Subtype, INPR for individual providers, ORPR for organization providers. Default is organization provider. This element is used in combination with the autocreate functionality.
Provider code, correlation key & definition
Name, first name, gender, initials & suffix
Street, house number & house number addition
City, zip code & country
A single dynamic field value
The matching strategy that is to be applied; for details on matching strategy refer to the section 'Mapping' in the guide
The check date in the matching strategy
The name as it should be stored and displayed when the provider cannot be matched
The address as it should be stored and displayed when the provider cannot be matched

Consider the <claimantProvider> element to clarify:

<claimantProvider
  code
  correlationKey
  flexCodeDefinitionCode
  initials
  name
  firstName
  gender
  nameSuffix
  subtype>

  <matchingContext
    matchingDate
    matchingStrategy
    nonMatchedName
    nonMatchedAddress
    <dynamicField
      name
      value/>
  <matchingContext/>
 </claimantProvider>

Relation Element

The relation element contains the following attributes:

Subtype, PERS for persons, ORGA for organizations. Default is organization. This element is used in combination with the autocreate functionality.
Relation code & correlationkey
Name, first name, gender, initials, suffix, partner name
Date of birth
Street, house number & house number addition
City, zip code & country
A single dynamic field value
The applicable matching strategy
The check date in the matching strategy
The name as it should be stored and displayed when the relation cannot be matched
The address as it should be stored and displayed when the relation cannot be matched

Consider the element Claimant as relation to clarify:

<claimantRelation>
  code
  correlationKey
  dateOfBirth
  initials
  name
  firstName
  gender
  namePartner
  nameSuffix
  subtype>

  <matchingContext
     matchingDate
     matchingStrategy
     nonMatchedName
     nonMatchedAddress
     <dynamicField
       name
       value/>
    <matchingContext/>
</claimantRelation>

Insurable Entity

The insurable entity has the following structure:

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

The following are applicable to the insurable entity of the type object :

code
date
description

The following are applicable to the insurable entity of the type person

code
correlationkey
dateOfBirth
initials
name
firstName
gender
namePartner
nameSuffix
address
matchingContext

Amounts

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

<allowedAmount
  currency>
  {value}
</allowedAmount>

Diagnoses

The diagnosis element may be included multiple times within claim and/or claim line. In the event that multiple diagnoses are provided, the sequence attribute specifies the order of importance of those diagnoses specifically for that claim. This sequence is an attribute of the cross reference entity between a diagnosis and a claim (or claim line) and is provided in the message in the <claimDiagnosisList><claimlinediagnosis sequence=""> attribute. Consider the <claimDiagnosisList> element to clarify:

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

Claim Tag Actions

Through this integration point claim tag actions can be set.

<claimTagActionList>
  <claimTagAction
    tag
    action
  >
  </claimTagAction>
  ...
</claimTagActionList>

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.

The allowable values for action are R (Redo), S (Skip), H (Hold) and F (Force).

Enrollment

Instead of relying on the enrollment call-out to reach out to an enrollment system to gather enrollment information for persons or obects on the claim, it is also possible to send in enrollment information along with the claim in 1 request. The block below contains the enrollmentList element in pseudo code:

<enrollmentList>
 <enrollment>
   insurableEntityType=""
   insurableEntityCode=""
   correlationKey=""
 >
  <families>
    <family
      code=""
      startDate=""
      endDate=""
    />
    ...
  </families>
  <waitingPeriodStartDates>
    <waitingPeriodStartDate
      serviceOptionServiceCode=""
      coverageLevel=""
      startDate=""
    />
    ...
  </waitingPeriodStartDates>
  <products>
    <product
      productCode=""
      employerCode=""
      startDate=""
      endDate=""
      contractDate=""
      contractEndDate=""
      factor=""
      coverageLevel=""
    >
      <parameters>
        <parameter
          aliasCode=""
          percentage=""
          number=""
          serviceDays=""
        >
          <parameterAmount
            currency="">
            {value}
          </parameterAmount>
        </parameter>
        ...
      </parameters>
      <providerGroups>
        <providerGroup
          assignmentLabel=""
          providerGroupCode=""
          startDate=""
          endDate=""
        />
        ...
      </providerGroups>
    </product>
    ...
  </products>
    ...
  </enrollment>
    ...
 </enrollmentList>

The list holds enrollment information for serviced persons or objects on the claim. For each person or object in the list, enrollment is validated and stored in the same way as the enrollment call out validates and stores enrollment information.

In the situation where enrollment information is sent in for a person or object that does not exist in OHI Claims Adjudication and Pricing and the auto-create functionality is enabled, the person or object is created and enrollment data is stored for that person or object. If the auto-create functionality is not enabled and the person or objects does not exist in OHI Claims Adjudication and Pricing, the enrollment information in the request is ignored. Enrollment data is then gathered through the enrollment integration point.

Whenever an error occurs in validating the enrollment data (e.g. the product doesn’t exist in OHI Claims Adjudication and Pricing), the claim is created in OHI Claims Adjudication and Pricing without enrollment data. No import error is created for this.

Enrollment data is not validated and stored for persons or objects in the enrollment list that are not a serviced person or object on the claim or claim line.

Please refer to the sections Receive Enrollment Data and Storing Enrollment Data in the 'Gathering Enrollment Data' chapter in the Claims Flow guide for more details on the enrollment data processing in OHI Claims Adjudication and Pricing.

Dynamic fields and records

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 Integration Guide.

Processing a request message

Whenever a claim is sent in through this integration point, the code is checked against the existing claim codes. If it does not exist yet, a new claim is created with indicator manual set to 'N'. If it does, and the overwrite indicator is checked as well, then the existing claim is replaced by the new claim if the existing claim is not in process (that is, has no pending task with the status 'In Process'); the indicator manual is then not updated. If the code is empty, the claim is considered a new claim; a unique code is generated by the system using a dynamic logic function with the signature 'Claim Code Generation'. If no dynamic logic function with the signature 'Claim Code Generation' exists, the claim id is assigned to claim code.

Similarly, within a claim, claim line code is used to identify an existing claim line. If the code is empty or if it does not yet exist, then the system considers the claim line as new.

High priority claims

It is possible to mark a claim as high priority, meaning that it will be picked up for processing with the highest priority possible. All submits for processing from the UI will automatically result in those claims being picked up with the highest priority because an operator is waiting for the results. For a claim that is sent in, it’s a choice: normally no high priority is needed, but there could be exceptions. If left unspecified, then the claim gets processed with standard priority.

Process fields

Process fields are fields required by the application to process the claim, but for which the value cannot be derived through hard coded logic. Consider the starting amount used to calculate benefits (benefits input amount). Some payers use the allowed amount, other payers also take into account specific surcharges or benefits paid by other payers. The application supports two scenarios:

A claim comes in without values for these process fields and the rules to derive the right values are configured in the application
A claim comes in with values for these process fields

Creating a new claim

The application attempts to take and store all claims that comes in through this integration point, even those can’t be processed, e.g., because the application can’t find a person record for the specified ID. The following list describes the scenarios in which the application is unable to take the claim

The brand code provided in the message does not match any brand codes in OHI Claims Adjudication and Pricing (CLA-IP-CLAI-001);
The payer code provided in the message does not match any payer codes in OHI Claims Adjudication and Pricing (CLA-IP-CLAI-002);
The process type is unknown;
The claim form provided in the message does not match any claim form code in OHI Claims Adjudication and Pricing (CLA-IP-CLAI-003);
The transaction source code provided in the message is not specified for the CLAIM or CLAIM LINE (GEN-TRAS-002);
The product code provided in the message does not match any product code (CLA-IP-CLAI-010);
The funding arrangement provided in the message does not match any funding arrangement code (CLA-IP-CLAI-019);
The product line provided in the message does not match any product line code (CLA-IP-CLAI-020);
The product family provided in the message does not match any product family code (CLA-IP-CLAI-021);
The coverage regime code provided in the messages does not match any coverage regime code (CLA-IP-CLAI-011);
The authorization regime code provided in the messages does not match any authorization regime code (CLA-HTTP-006);
The waiting period regime code provided in the messages does not match any waiting period regime code (CLA-HTTP-007);
The post benefits regime code provided in the messages does not match any post benefits regime code (CLA-HTTP-008);
The coverage specification code provided in the messages does not match any coverage specification code (CLA-HTTP-009);
Bundled and unbundled claim lines cannot be processed:
- The original claim line or replaced claim line holds a reference to a non-existing claim line code number (CLA-IP-CLAI-005);
- A claim line code is part of more than one bundling or unbundling or replaces itself (CLA-IP-CLAI-006)
A dynamic field specified in the message cannot be imported. Examples:
- The flex code value does not exist; (GEN-DYNA-007)
- The flex code definition code does not exist; (GEN-DYNA-006)
- The dynamic field name does not exist; (GEN-DYNA-008)
The claim has no claim lines (CLA-IP-CLAI-009)
A claim line limit code provided in the messages does not match any limit code in OHI Claims Adjudication and Pricing (CLA-IP-CLAI-017)
A claim line limit cover withhold category code provided in the messages does not match any cover withhold category code in OHI Claims (CLA-IP-CLAI-015)
A claim line parameter cover withhold category code provided in the messages does not match any cover withhold category code in OHI Claims Adjudication and Pricing (CLA-IP-CLAI-015)
A claim unfinalize reason code provided in the messages does not match any unfinalize reason code in OHI Claims Adjudication and Pricing(CLA-IP-CLAI-012)

For any of these situations an explanatory message is logged. The failing claim in the request message is not stored.

Replacing an existing claim

If the request payload is a claim with a code that already in use, and the attribute <claimHeader indOverwriteClaim> is set to “Y” then the system discards the existing claim with the same code and replaces it with the claim in the request payload. If the latter condition is not met then the payload is ignored without throwing a message; this indicates an unintended duplicate message of the original claim has been sent in.

For example, if the existing claim has a field A with value 1, and the request payload does not specify field A at all, then after the payload has been processed the existing claim no longer has a value for field A.

Replacing finalized claims

If the existing claim is in the status PRICING FINALIZED or FINALIZED then the payload also has to specify one or more unfinalize reasons. If not, then the payload is rejected with message CLA-IP-CLAI-012 or 013.

Otherwise, the existing claim unfinalized with the specified reason before it is replaced by the claim in the request payload. In the event that the existing claim has the status FINALIZED and is also settled, then the request payload is rejected with message CLA-IP-CLAI-016.

Replacing claims that are in process

If the existing claim is in any other status than PRICING FINALIZED or FINALIZED, then any unfinlize reasons that may be in the request payload are ignored and the claim is directly replaced. A ‘task done’ event is sent out if there are outstanding workflow tasks.

If the claim has unresolved pend reasons, the system immediately resolves these pends reasons. This remains visible in the claim pend reason history.

If the claim has triggered a asynchronous call out rule that is still in progress, then its wait cycle is immediately aborted and any response that may be received later is ignored.

Replacement Logic

The system clears all information on the claim header – including details - and replaces it with the information in the request payload, with the exception of the claim status history and claim pend history; this information remains intact.

Next the system determines, line by line, whether a line is replaced, partially updated or remains untouched. The business context is that some lines may be flagged to be immutable for business reasons, and so have to remain intact regardless of the information in the request payload. Claim lines are matched on their code, i.e., if a line in the request payload and the existing claim have the same code, the systems works on the assumption that these are the same line.

If the claim line in the request payload and the existing claim line both have the keepPricing and keepBenefits flags set to (Y)es then the line and its processing results remain untouched. The line in the request payload is ignored.
If the claim line in the existing claim is locked and the line in the request payload either does not specify the unlock flag or specifies it with value (N)o, then the line and its processing results remain locked and untouched. The line in the request payload is ignored. If the system is unable to match the existing locked line to a line in the request payload then the request is rejected with message CLA-CLLI-007.
If the claim line in the request payload and the existing claim line both have the keepPricing set to (Y)es, but neither of the previous two situations apply, then the claim line is only partially cleared and replaced. The following information is retained and remains untouched: the claim line provider pricing clauses, the allowed amount and currency, the allowed number of units and claim line messages that originated from the PRICING, PRICING LIMIT and PRICING NO RECALCULATION step.
In all other scenarios the existing claim line is discarded and replaced by the claim line in the request payload.

Replacing Claim Lines with Tags

Some lines may be tagged. This means that these lines are either included in (or the result of) a bundling of lines. Consequently the system considers the replacement of these lines within the context of the bundle, rather than on a line by line basis.

Claim lines with a reference to a line skip tag are updated rather than removed. All attributes and details on the line are cleared and overwritten by the information in the payload with the exception of: the line skip tag, the claim line provider pricing clauses.
Claim lines with a reference to an allowed amount skip tag are updated rather than removed. All attributes and details on the line are cleared and overwritten by the information in the payload with the exception of: the allowed amount skip tag, the claim line provider pricing clauses, the allowed amount and currency, the allowed number of units.
Claim line messages that are tagged remain untouched. If the request payload includes the exact same message for the exact same line with the exact same placeholder values then it is ignored. This prevents duplicate messages.

Replaced lines

The request message specifies which claim lines are replaced by which other claim lines. In the data model, each claims line directly references either the line that it replaces or the line by which it is replaced (Note that only 1-to-n and n-to-1 replacements are allowed.). The claim line replacement taken into account the values of the element originalClaimLine and replacementClaimLine on the claim line

Consider a sample message:

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

    <Claimline code="2"
      replacementClaimLineCode ='3'/>
    </Claimline>
    <Claimline code="3"
      ..../>
    </Claimline>
    <Claimline code="4"
      .../>
    <Claimline code="5"
      originalClaimLineCode ="4"/>
    </Claimline >
    <Claimline code="6"
      originalClaimLineCode ="4"/>
    </Claimline>
  </claimLineList>
</claim>

The message reflects a claim with lines 1 through 6, where line 1 and 2 is replaced by line 3, and line 5 and 6 replaces line 4. The resulting claim line references:

In order to replace existing claimLines and matching them against the existing claimLines, it is necessary that when a claim is sent in for replacement, all the claim lines within the scope of (un)bundling should have code present, else import fails with message (CLA-IP-CLAI_005).

Attributes on multiple levels

A set of fields in the claim model can be stored on multiple levels. For example, both the claim and the claim line can specify a list of diagnosis codes, possibly within the same claim. This set consists of the following fields:

serviced person
serviced object
service provider
location
referral provider
diagnoses
service specialties
authorization code
emergency indicator
payment receiver
location type

The following set of rules define the behavior of the application in context of these fields:

If the claim line field is unspecified, then it logically assumes the value of its counter part field on the claim.
If the claim line field is specified, then that value is used for adjudication. The values of its counterpart fields on the claim level are ignored

The values are not physically inherited (in the database). So even though the system adjudicates these claim lines as if they have these logically assumed values, these values are accessible in the object model and these values are visible in the user interface, they will not appear in the operational reporting views (as these are generated of the database).

Note that the above logic does not apply to non-matched values; only matched values are inherited from higher levels to lower levels.

In context of these rules, the list of diagnosis codes is treated as a single field value. In other words, the application will not merge the set of diagnoses on the claim header with the diagnoses on the claim line; if the line specifies a list of diagnoses, those are the diagnoses used for adjudication of that line; if the line does not specify diagnoses, then the list on the claim is used for the adjudication of that line. Note that the logical assumption of the diagnoses values extends to the dynamic field values that may be specified on the intersection entities: claim diagnosis and claim line diagnoses .

Because the emergency indicator can never be unspecified (it is either true or false) the value 'false' is treated as unspecified. This means that unless the emergency indicator is false on the claim and claim line level, the line will adjudicate as if the emergency indicator has the value 'true'.

De-duplicate diagnoses

Within a claim, the included combinations of diagnosis and diagnosis type must be unique. This goes likewise for a claim line. However, to be able to handle request messages which erroneously contain duplicate entries, eventual duplicate entries are ignored: only unique combinations of diagnosis and diagnosis type are stored.

For example, consider the following combinations of diagnosis and diagnosis type, which are sent in on a claim header:

Seq.	Diagnosis	Diagnosis type	Stored?
1	123	A - Admitting	Yes
2	345	R - Reason for patient visit	Yes
3	678	O - Other	Yes
4	123	O - Other	Yes
5	678	O - Other	No: duplicate entry, is ignored.

Note that this is intended to de-duplicate claim/claim line diagnoses which are sent in with a unique sequence number. The duplicate claim/claim line diagnosis with the highest sequence number is ignored. Sending in claim/claim line diagnoses with the same sequence number is not supported and will result in a fatal error message.

Mapping

All information in the claim message is mapped and matched to the claim data model and reference data. In the event that some piece of information cannot be matched to a record in the claims model, the information in the claim message is stored in fields that are specifically meant to store non-matched information, with the purpose storing the claim without loss of information so that manual mapping is supported.

A few attributes are of such a nature that a claim cannot be processed without them. In such an event the claim will not be imported and a fatal message will be generated. An example is that the brand or payer code on the claim always has to map to the brands and payer codes configured in OHI Claims.

Relation, Provider, Objects and Matching Strategy

The matching of relations, providers and objects depends on system property settings for autocreation of non-matched relations and providers. Two system properties support this functionality (see the Configure OHI Claims Adjudication and Pricing properties file section in the Install Guide for details on the properties):

Autocreate Relations and Objects
Autocreate Providers

When the property is not set in the property file, no autocreate is presumed.

Autocreate

When the property is set to autocreate, matching is done on code or the combination of flexcode and code in case of provider matching only. If the relation or the provider that is being sent in does not match on code then the enabled relation or provider identifiers are used for matching, thus enabling the system to recognize if it is the same relation or provider. A relation or a provider can have multiple identifiers that are stored in the OHI system. The identifiers could be of any type for example policy enrollment number, social security number or drivers license number etc. If the relation or provider is unmatched on the enabled identifiers then a new relation or provider is generated. The user needs to have access to the identifier type in order for the identifiers to be applied during matching.

If no matching record could be found, the system creates a new person or provider with the information (e.g. name and date of birth) that is included in the message.

The following attributes are required when creating a new relation or provider. When no value for such an attribute is included in the message, the values listed in the table below are used.

Relation or Person

Attribute	Value
Name	Code
Gender	U (Unknown)
Date of Birth	Service Date
Date of Birth Interpretation	E (Exact)
Name Format	First pick on dynamic logic functions with signature Name Format
Language	Default Language
Address Type	Default address type

Attribute

Value

Name

Code

Gender

U (Unknown)

Date of Birth

Service Date

Date of Birth Interpretation

E (Exact)

Name Format

First pick on dynamic logic functions with signature Name Format

Language

Default Language

Address Type

Default address type

Object

Attribute	Value
Description	Code
Object Date	Service Date

Attribute

Value

Description

Code

Object Date

Service Date

Provider

Attribute	Value
Type	Organization Provider
Name	Code
Flex Code Def Code	First pick on flex code definition codes for Providers
Start Date	Service Date
Language	Default Language

Attribute

Value

Type

Organization Provider

Name

Code

Flex Code Def Code

First pick on flex code definition codes for Providers

Start Date

Service Date

Language

Default Language

When the code could be matched to an existing relation or provider, the relation or provider is updated with the element values in the message if they are different from the values in the Oracle Health Insurance reference data.

No Autocreate

When the property is set to Not Autocreate, matching relies on a matching strategy. If no matching strategy is sent in in the request message, matching is done on code for relations and objects and on the combination of flex code def code and code for providers.

If the relation or the provider that is being sent in does not match on code then the enabled relation or provider identifiers are used for matching, thus enabling the system to recognize if it is the same relation or provider. A relation or a provider can have multiple identifiers that are stored in the Oracle Health Insurance system. The identifiers could be of any type for example policy enrollment number, social security number or drivers license number etc. If the relation or provider is unmatched on the enabled identifiers then a new relation or provider is generated. The user needs to have access to the identifier type in order for the identifiers to be applied during matching.

Matching

The matching strategy represents the logic that will tie the information provided in the claims request message to the matching provider or relation record in the OHI Claims Adjudication and Pricing database. The message dictates which matching strategy to use, because the choice of applicable strategy is strongly dependent on the source of the claim file. For example, some claims may come from an EDI source that only supplies the person’s demographics - requiring matching strategy A - while another EDI source only provides the person subscription number - requiring matching strategy B.

OHI Claims Adjudication and Pricing allows multiple matching strategies to be set up. A matching strategy describes which of the fields in the message should be (partially) identical to the corresponding fields in the data model in order to establish a match for relations/providers. For each relation/provider in the claims in message, the message dictates which matching strategy to use. Matching strategies are set up as dynamic logic functions. The matching strategy code in the message has to match a dynamic logic function code.

The information in OHI Claims Adjudication and Pricing that is used to find a match may be time valid, such as the address. For this reason, the message has an optional 'as of' date that specifies on which moment the information in the relation or provider element was accurate. It is also possible to set up an uniquely identifying dynamic field in OHI Claims Adjudication and Pricing and to use that field when matching a relation or provider provided on the claim.

The claims model and message supports a single value dynamic field for each provider or relation that can be used for matching. A reference to a dynamic field is captured by two separate elements in the message: The name of the usage of that dynamic field, i.e., the nature of the dynamic field value within the context of the extended entity and the actual value of the dynamic field.

The matching strategy produces a single relation or provider (record). Note that if no or more than one relation or provider has been found, OHI Claims Adjudication and Pricing still stores the information on that provider/relation as provided in the message. The elements of the incoming object can be used in the matching strategy. The way they can be used will normally be a combination of various search mechanisms.

If the matching process is successful, then the foreign key in the claims data model is created. The information in the claims message used for the match is discarded.

If one of the following events occur:

the matching strategy code is unknown in OHI Claims Adjudication and Pricing;
a run-time error occurs during the execution of the matching strategy;
no match can be made;

then the relation/provider information is stored in the claim data model.

Correlation key :It is used in the following manner to match individual providers. If the Individual provider is the same person and this person is new to the system, the provider in the provider element must have the same provider code in the request. If the provider codes are left empty, with the purpose to have them generated by the system, a correlation key must be used. By adding the same correlation key to the provider, they are recognized as being the same person. The system will create only one person who is the provider. If both person codes and correlation keys are used, then matching the provider code prevails above matching on correlation key. When both code and correlation key are not specified no providers are created.

It works in a similar way as above for <relation> element and the element.

Matching on correlation key is only used for new persons where the request holds no person code. Correlation keys will be ignored for person updates and are not available for enrollment of insured entities that are not persons.

The following examples aim to clarify what information is stored in the event of a non matching relation or provider.

Note: The Correlation Key is used only with the auto-create functionality.

Specific for relations:

<relation code="" dateOfBirth=""> are stored in the dedicated _REL_CODE and _DOB colums.

<claim>
  <claimantRelation
    code="AK1235"
    dateOfBirth="19810306"/>
...

// the following is stored in the data model in case of a non-match:
CLAIM.CLAIMANT_REL_CODE = "AK1235"
CLAIM.CLAIMANT_DOB = "19810306"

Specific for providers:

<provider><code code="" flexCodeDefinitionCode=""> are stored in the dedicated _CODE and _CODE_DEF columns.

<claim>
  <serviceProvider>
    <code="1234567890"
     flexCodeDefinitionCode="NPI"/>
...
// the following is stored in the data model in case of a non-match:
CLAIM.SERVICE_PROVIDER_CODE = "1234567890"
CLAIM.SERVICE_PROVIDER_CODE_DEF = "NPI"

For both relation and for providers:

<name nonMatchedName=""> is stored in the dedicated _NAME column.

<claim>
  <claimantRelation
    nonMatchedName="Bob Steward MD"/>
...
// the following is stored in the data model in case of a non-match:
CLAIM.CLAIMANT_NAME = "Bob Steward MD"

is stored in the dedicated _ADDRESS column.

<claim>
  <claimantRelation>

...
// the following is stored in the data model in case of a non-match:
CLAIM.CLAIMANT_ADDRESS = "2345 Commonwealth ave, Newton MA"

<dynamicField name="" value=""/> are stored in the dedicated columns FIELD_NAME & FIELD_VALUE columns.

<claim>
  <paymentBeneficiaryProvider>
    <dynamicField
      name="SSN"
      value="12345"
    />
...
// the following is stored in the data model in case of a non-match:
CLAIM.PAY_BENEFICIARY_FIELD_NAME = "SSN"
CLAIM.PAY_BENEFICIARY_FIELD_VALUE = "12345"

Insurable Objects

If the serviced object could not be matched uniquely based on the provided data by using matching strategy, the data elements are stored on the claim or claim line to enable manual matching.

Other Attributes

For the following, a failure to map will not cause the claim import to fail. Instead the unmatched information is stored on the claim/claim line.

Claim Message
Claim Diagnosis
Claim Line Contract Reference
Claim Line Diagnosis
Claim Line Modifier
Claim Line Procedure
Claim/Claim Line Location Type
Claim/Claim Line Service Specialty

Messages

The claim message can contain messages on the following entities: Claim and Claim Line. The attribute 'code' in the message element should match the code of a "message" record. In case of a non-match the provided value is stored in a dedicated field. Consider claim line message to clarify:

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

Each (claim or claimLine) message element may contain up to 10 parameters: attributes "value0" through "value9". These values 0 through 9 are used to populate the respective placeholders in the message text. In the event that no placeholder exists for the specified parameter, the parameter value is simply not used. In the event that no parameter is specified for a placeholder, that placeholder remains empty. Note that the placeholder parameters are always stored, regardless of whether the message is matched or not.

It is possible to specify the origin of the message (EXTERNAL or MANUAL). If the origin is not specified then the message added as a result of using this integration point is considered to have originated from an external source (origin EXTERNAL).

Duplicate messages in the request are de-duplicated, i.e. only unique messages are stored. To determine whether a message is a duplicate, all attributes of the message are taken into account: i.e. code, origin, parameter 0 through 9, transaction source and reference code.

Other Details

The following actions are taken automatically when processing the request message:

The attribute claim.entryDate is set to sysdate.
The field claim.totalClaimedAmount is set to the sum of the claimLine.claimedAmounts as long as all the currencies of the claim line claimed amounts are equal; the currency for the total claimed amount is set as well.
The field claim.totalAllowedAmount is set to the sum of the claimLine.allowedAmounts as long as all the currencies of the claim line allowed amounts are equal; the currency for the total allowed amount is set as well. Claim lines without an allowed amount are not included in this sum (as if they specify a 0 allowed amount).
The claim.authorizationCode is stored as text and not as a reference to an authorization present in OHI Claims. It is up to the authorization matching function to find the correct authorization for a claim line. The value of this field could be used in that matching function. The same is true for the authorizationCode fields on the claimLine.
The field claim.startDate is set to the earliest claimLine.startDate that belongs to the claim.
The field claim.endDate is set to the latest date out of all claimLine.endDates and claimLine.startDates that belong to the claim.
The fields claimLine.keepBenefits, claimLine.manualBenefits, claimLine.keepPricing and claimLine.manualPricing are all unchecked, i.e., value N(o).
If the ignoreHistory is not set explicitly, then the value is taken from the value set in the property file for the instance (if not specified in the property file, it is set to N(0)).
If the sendOutForPreprocessing is not set explictily then
- if externalPricing is set to Y(es) then set sendOutForPreprocessing to N(o)
- if externalPricing is set to N(o) then set sendOutForPreprocessing to Y(es

^** To set indicators (e.g. pricingDone) to Y(es), the value is payload is set as true. To set the value as N(o) the value in payload is set as false.

Response Message

Response messages are created by the OHI application in response to request messages received from external interfaces. Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.

When processing a request message this integration point can generate the following messages. These messages are returned in the response.

Code	Sev	Internal message
CLA-IP-CLAI-001	Fatal	The brand code {code} is unknown
CLA-IP-CLAI-002	Fatal	The payer code {code} is unknown
CLA-IP-CLAI-003	Fatal	The form {code} is unknown
CLA-IP-CLAI-004	Fatal	The data access group {code} is unknown
CLA-IP-CLAI-005	Fatal	The claim line code {code}, specified for (un)bundling purposes, is unknown
CLA-IP-CLAI-006	Fatal	The claim line replacements are not specified consistently
CLA-IP-CLAI-009	Fatal	A claim must have at least one claim line
CLA-IP-CLAI-010	Fatal	The specified product code {code} is unknown
CLA-IP-CLAI-011	Fatal	The specified coverage regime code {code} is unknown
CLA-IP-CLAI-012	Fatal	The specified unfinalize reason code {code} is unknown
CLA-IP-CLAI-013	Fatal	When sending in a new version of a finalized claim {code}, at least one unfinalize reason should be specified
CLA-IP-CLAI-015	Fatal	The cover withhold category code {code} is unknown
CLA-IP-CLAI-016	Fatal	The claim {code} cannot be unfinalized because it is settled
CLA-IP-CLAI-017	Fatal	The limit code {code} is unknown
CLA-IP-CLAI-018	Fatal	Field {procedure field} is not configured for this claim form
CLA-IP-CLAI-019	Fatal	The funding arrangement code {code} is unknown
CLA-IP-CLAI-020	Fatal	The product line code {code} is unknown
CLA-IP-CLAI-021	Fatal	The product family code {code} is unknown
CLA-IP-CLAI-022	Fatal	The skip tag code {code} is unknown
CLA-IP-CLAI-026	Fatal	Only message origins MANUAL or EXTERNAL are allowed
CLA-IP-CLAI-027	Fatal	Skip tag action UNDO cannot be specified
CLA-IP-CLAI-028	Fatal	Claim {code} is in process. It cannot be submitted.
CLA-HTTP-006	Fatal	The specified authorization regime code {code} is unknown
CLA-HTTP-007	Fatal	The specified waiting period regime code {code} is unknown
CLA-HTTP-008	Fatal	The specified post benefits regime code {code} is unknown
CLA-HTTP-009	Fatal	The specified coverage specification code {code} is unknown
CLA-IP-CLAI-035	Fatal	The specified relation subtype {code} is unknown
CLA-IP-CLAI-036	Fatal	The specified provider subtype {code} is unknown

Code

Sev

Internal message

CLA-IP-CLAI-001

Fatal

The brand code {code} is unknown

CLA-IP-CLAI-002

Fatal

The payer code {code} is unknown

CLA-IP-CLAI-003

Fatal

The form {code} is unknown

CLA-IP-CLAI-004

Fatal

The data access group {code} is unknown

CLA-IP-CLAI-005

Fatal

The claim line code {code}, specified for (un)bundling purposes, is unknown

CLA-IP-CLAI-006

Fatal

The claim line replacements are not specified consistently

CLA-IP-CLAI-009

Fatal

A claim must have at least one claim line

CLA-IP-CLAI-010

Fatal

The specified product code {code} is unknown

CLA-IP-CLAI-011

Fatal

The specified coverage regime code {code} is unknown

CLA-IP-CLAI-012

Fatal

The specified unfinalize reason code {code} is unknown

CLA-IP-CLAI-013

Fatal

When sending in a new version of a finalized claim {code}, at least one unfinalize reason should be specified

CLA-IP-CLAI-015

Fatal

The cover withhold category code {code} is unknown

CLA-IP-CLAI-016

Fatal

The claim {code} cannot be unfinalized because it is settled

CLA-IP-CLAI-017

Fatal

The limit code {code} is unknown

CLA-IP-CLAI-018

Fatal

Field {procedure field} is not configured for this claim form

CLA-IP-CLAI-019

Fatal

The funding arrangement code {code} is unknown

CLA-IP-CLAI-020

Fatal

The product line code {code} is unknown

CLA-IP-CLAI-021

Fatal

The product family code {code} is unknown

CLA-IP-CLAI-022

Fatal

The skip tag code {code} is unknown

CLA-IP-CLAI-026

Fatal

Only message origins MANUAL or EXTERNAL are allowed

CLA-IP-CLAI-027

Fatal

Skip tag action UNDO cannot be specified

CLA-IP-CLAI-028

Fatal

Claim {code} is in process. It cannot be submitted.

CLA-HTTP-006

Fatal

The specified authorization regime code {code} is unknown

CLA-HTTP-007

Fatal

The specified waiting period regime code {code} is unknown

CLA-HTTP-008

Fatal

The specified post benefits regime code {code} is unknown

CLA-HTTP-009

Fatal

The specified coverage specification code {code} is unknown

CLA-IP-CLAI-035

Fatal

The specified relation subtype {code} is unknown

CLA-IP-CLAI-036

Fatal

The specified provider subtype {code} is unknown

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

Location:http://[hostName]:[portNumber]/[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.