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
    episodeIdentifier
    keepBenefits
    keepPricePrincipalProcs
    keepPricing
    pricePrincipalProcedure1
    pricePrincipalProcedure2
    pricePrincipalProcedure3
    unlock
    locationTypeCode
    orginalClaimLineCode
    priceInputDate
    priceInputNumberOfUnits
    processAsIn
    providerEntityReference
    providerReference
    referenceCode
    replacementClaimLineCode
    reservationCode
    reservationLineCode
    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. Represent each role by a relation or provider. In the claims model, store such a role 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, For example, the claimant. On restitution claims the claimant is likely to be a person, that is, a person in the Claims 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. Use this element in combination with the auto-create functionality.
Provider code, correlation key and definition
Name, first name, gender, initials, and suffix
Street, house number and house number addition
City, zip code and 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
  startDate>

  <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. Use this element in combination with the auto-create functionality.
Relation code and correlationkey
Name, first name, gender, initials, suffix, partner name
Date of birth
Street, house number and house number addition
City, zip code and 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
date of Birth
initials
name
firstName
gender
namePartner
nameSuffix
address
matchingContext

The insurable entity is in all caps: PERSON.

Amounts

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

<allowedAmount
  currency>
  {value}
</allowedAmount>

Diagnoses

Include the diagnosis element multiple times within claim and/or claim line. When provided with multiple diagnoses, 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>

Through a business rule first create the claim tag actions that are configured as being possible. The claim tag actions that are sent in are just updates of the existing claim tag actions. If a claim tag action will be sent in for a skip tag that was not created as a claim tag action, then nothing happens: no claim tag action will be created nor any message will be generated.

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

Enrollment

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

<enrollmentList>
 <enrollment>
   insurableEntityType=""
   insurableEntityCode=""
   correlationKey=""
 >
  <families>
    <family
      code=""
      startDate=""
      endDate=""
    />
    ...
  </families>
  <products>
    <product
      productCode=""
      employerCode=""
      startDate=""
      endDate=""
      contractDate=""
      contractEndDate=""
      factor=""
    >
      <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, validate the enrollment and store in the same way as the enrollment call out validates and stores enrollment information.

Send enrollment information for a person or object that does not exist in Claims and the auto-create functionality will be enabled, the person or object will be created and enrollment data will be stored for that person or object. Not enabling the auto-create functionality and if the person or objects does not exist in Claims, the enrollment information in the request will be ignored. Enrollment data will be then gathered through the enrollment integration point.

Whenever an error occurs in validating the enrollment data (For example, the product doesn’t exist in Claims), the claim will be created in Claims without enrollment data. No import error will be created for this.

Enrollment data will not be 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 Operations Guide for more details on the enrollment data processing in Claims.

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

Processing a Request Message

While sending a claim through this integration point, the code will be checked against the existing claim codes. If it does not exist yet, a new claim will be created with indicator manual set to N.

If it does, and the overwrite indicator will be checked as well, then the existing claim will be 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 will then not update. If the code is empty, the claim will be considered a new claim; a unique code will be 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, assign the claim id to claim code.

Similarly, within a claim, use claim line code 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 picking up those claims 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 will be 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 will be 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 that can’t be processed, For example, 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 Claims (CLA-IP-CLAI-001);
The payer code provided in the message does not match any payer codes in Claims (CLA-IP-CLAI-002);
The process type is unknown;
The claim form provided in the message does not match any claim form code in Claims (CLA-IP-CLAI-003);
The transaction source code provided in the message will not be 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 un-bundled 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 un-bundling or replaces itself (CLA-IP-CLAI-006)
A dynamic field specified in the message cannot be imported. For example,
- 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 Claims (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 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 Claims (CLA-IP-CLAI-015);
A claim un-finalize reason code provided in the messages does not match any un-finalize reason code in Claims(CLA-IP-CLAI-012);

For any of these situations an explanatory message will be logged. The failing claim in the request message will not be 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 does not meet the condition then the payload will be ignored without throwing a message; this indicates an unintended duplicate message of the original claim has been sent.

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 has to specify one or more un-finalize reasons. If not, the payload will be rejected with message CLA-IP-CLAI-012 or 013.

Otherwise, the existing claim should be un-finalized with the specified reason before it is replaced by the claim in the request payload. If the existing claim has the status FINALIZED and is also settled, then the request payload will be 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 un-finalize reasons that may be in the request payload are ignored and the claim will be 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 pend reasons. This remains visible in the claim pend reason history.

If the claim has triggered an asynchronous callout rule that is still in progress, then its wait cycle will be 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 an exception to the claim status-history and claim pend history; this information remains intact.

The system determines, line by line, whether a line has been replaced, partially updated or remains untouched. Maybe flagging some lines in the business context are immutable for business reasons, and so have to remain intact, regardless of the information in the request payload.

Match claim lines on their code, that is, if a line in the request payload and the existing claim have the same code, the system works on the assumption that these are the same lines.

If the claim line in the request payload and the existing claim line both have the keepPricing and keepBenefits flags set to Yes then the line and its processing results remain untouched. The line in the request payload will be 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 No, then the line and its processing results remain locked and untouched. The line in the request payload will be ignored. If the system is unable to match the existing locked line to a line in the request payload then the request will be 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 Yes, but neither of the previous two situations apply, then the claim line will be partially cleared and replaced. The following information will be 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 discard the existing claim line and replace with the claim line in the request payload.

Replacing Claim Lines with Tags

Some lines will be tagged. This means that these lines will either be 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.

Update claim lines with a reference to a Line skip tag rather than remove. Clear all attributes and details on the line and overwrite with the information in the payload except: the line skip tag, the claim line provider pricing clauses.
Update claim lines with a reference to an Allowed Amount skip tag rather than remove. Clear all attributes and details on the line and overwrite with the information in the payload except: 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 will be 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 (only 1-to-n and n-to-1 replacements will be 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 sending a claim for replacement, all the claim lines within the scope of bundling or unbundling 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 counterpart field on the claim.
If the claim line field will be specified, then that value will be used for adjudication. Ignore the values of its counterpart fields on the claim level.

The values will not be physically inherited (in the database). 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).

The above logic does not apply to non-matched values; inherit only matched values from higher levels to lower levels.

In context of these rules, treat the list of diagnosis codes as a single field value. 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 use the list on the claim 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 .

Since 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 as 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 will be ignored: only unique combinations of diagnosis and diagnosis type will be stored.

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

Table 1. De-Duplicate Diagnoses
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

This is intended to de-duplicate claim or claim line diagnoses which are sent in with a unique sequence number. Ignore the duplicate claim or claim line diagnosis with the highest sequence number. Sending in claim or claim line diagnoses with the same sequence number cannot be supported and will result in a fatal error message.

Mapping

Map all information in the claim message and match to the claim data model and reference data. In the event that some information cannot be matched to a record in the claims model, store the information in the claim message in fields that are specifically meant to store non-matched information, with the purpose storing the claim without loss of information and supporting manual mapping.

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 Claims.

Relation, Provider, Objects, and Matching Strategy

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

Auto-create Relations and Objects
Auto-create Providers

When the property has not been set in the property file, no auto-create is presumed.

Auto-create

When the property has been set to auto-create, matching is done on code or the combination of flex-code 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 use the enabled relation or provider identifiers 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 driver’s license number etc. If the relation or provider is unmatched on the enabled identifiers then a new relation or provider will be 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 (For example, name and date of birth) that is included in the message.

Required are the following attributes when creating a new relation or provider. When including no value for such an attribute in the message, use the values listed in the table below.

Table 2. Relation or Person
Attribute	Value
Name	Code
Gender	U (Unknown)
Date of Birth	Service Date
Date of Birth Interpretation	E (Exact)
Language	Default Language
Address Type	Default address type

Table 3. Object
Attribute	Value
Description	Code
Object Date	Service Date

Table 4. 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

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

No Auto-create

When setting the property to Not Auto create, matching relies on a matching strategy. If sending no matching strategy 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 use the enabled relation or provider identifiers 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 driver’s license number etc. If the relation or provider is unmatched on the enabled identifiers then generate a new relation or provider. The user should 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 Claims 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 Electronic Data Interchange (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.

Claims 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 or providers. For each relation or provider in the claims in message, the message dictates which matching strategy to use. Matching strategies to be set up as dynamic logic functions. The matching strategy code in the message has to match a dynamic logic function code.

The information in Claims that is used to find a match may be time valid, such as the address. The message has an optional as-of date that specifies at which moment the information in the relation or provider element was accurate. It is also possible to set up a uniquely identifying dynamic field in Claims 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. Capture a reference to a dynamic field by two separate elements in the message: The name of the usage of that dynamic field, that is, 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). If none or more than one relation or provider has been found, Claims still stores the information on that provider or 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 create the foreign key in the claims data model. Discard the information in the claims message used for the match.

If one of the following events occur:

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

then the relation or provider information will be 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. Leaving the provider code 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 using both person codes and correlation keys, then matching the provider code prevails above matching on correlation key. Not specifying both code and correlation key, no providers will be created.

It works similarly as above for <relation> element and the element.

Only use matching on correlation key 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 will be stored in the event of a non-matching relation or provider.

Use The Correlation Key only with the auto-create functionality.

Specific for Relations:

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

<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 and 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, store the data elements 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, store the unmatched information on the claim or claim line.

Claim Message
Claim Diagnosis
Claim Line Contract Reference
Claim Line Diagnosis
Claim Line Modifier
Claim Line Procedure
Claim or Claim Line Location Type
Claim or 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 store the provided value 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
    overturned
    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 will simply not be used. In the event that no parameter will be specified for a placeholder, that placeholder remains empty. The placeholder parameters will always be stored, regardless of whether the message will be matched or not.

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

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

Other Details

Take the following actions 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; set the currency for the total claimed amount 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; set the currency for the total allowed amount as well. Do not include claim lines without an allowed amount 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 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, that is, value No.
If the ignoreHistory is not set explicitly, then take the value from the value set in the property file for the instance (if not specified in the property file, set it to No).
If the sendOutForPreprocessing is not set explicitly then
- if externalPricing is set to Yes then set sendOutForPreprocessing to No
- if externalPricing is set to No then set sendOutForPreprocessing to Yes

To set indicators (For example, pricingDone) to Yes, the set value in payload as true. To set the value as No, set the value in payload as false.

Response Message

Response messages will be created by the Oracle Health Insurance 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.

Table 5. Response Message
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 bundling or unbundling purposes, is unknown
CLA-IP-CLAI-006	Fatal	The claim line replacements 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 un-finalize reason code {code} is unknown
CLA-IP-CLAI-013	Fatal	When sending in a new version of a finalized claim {code}, at least one un-finalize 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 un-finalized 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	Allow only message origins MANUAL or EXTERNAL
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 chapter of the Developer Guide.