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: http://[hostName]:[portNumber]/[api-context-root]/claims. The request message has the following structure:
Claims PUT Request Message
<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:
Claims PUT Request Message - Enrollment List
<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.
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:
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.
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 |
Attribute | Value |
---|---|
Description |
Code |
Object Date |
Service Date |
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. See Response Messages 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 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/{\id}/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.