Claims Pre-Finalized Out Integration Point
Several steps in the claims processing flow can make alterations to the claim or one of its claim lines. In some scenarios the changes made actually require the claim to be sent back upstream to re-iterate one or more pre-processing steps. For example, changing the service provider on the claim may require that the claim is externally repriced. This chapter describes the integration point through which un-finalized claims leave the system in the upstream direction.
Design Choices
-
The claim response message contains all available information on the claim and claim line.
-
This includes dynamic fields on the claim, claim lines, claim sub lines, and diagnoses.
-
This includes processing fields (for example, the price provider)
-
This includes information on how claim lines are bundled or unbundled.
-
This includes information on fields that could not be matched.
-
-
Dynamic fields on referenced entities are not included. For example, a dynamic field on the serviced person or object is not included.
-
Providers, persons and objects are identified by their respective codes. Person, object and provider codes are not Claims internal codes, but codes issued outside of Claims. It is possible that a claim is sent out for (re)pricing while not all providers and/or persons or objects are matched. For this reason, any non-matched information for persons, objects, and providers is sent out as well. In addition, for both the provider and person or object the name and date is sent out.
-
When a claim qualifies to be sent out, Claims can send out an event using Claims Events IP. Adjoining applications can keep track of these event based notifications. Upon request, Claims will send out a response message containing the claim that is to be further processed by another application.
-
The response message only contains messages for EXTERNAL and MANUAL claim messages, and claim line messages.
Request Message
In the event that an external application wants to receive a copy of the claim, it needs to send a GET request to Claims on uri : http://[hostName]:[portNumber]/[api-context-root]/claimsprefinalizedout/{claim code}
Response Message
When Claims receives a request message, a response message is sent back. If the requested claim does not exist, or does not have a status indicating that it is to be sent out, the following result messages are returned:
Code | Sev | Message |
---|---|---|
CLA-IP-PRFO-001 |
Fatal |
The claim code {code} is unknown |
CLA-IP-PRFO-002 |
Fatal |
The claim {code} is not in status that allows it to be sent out |
Only claims in the status SENT OUT FOR PREPROCESSING or SENT OUT FOR PRICING can be accessed through this integration point.
The following response message is returned:
<claim> <claimLineList> <claimLine/> ... </claimLineList> </claim>
The following snippet contains the structure of the claim:
<claim authorizationCode brandCode claimDate code claimSetCode dataAccessGroupCode dueDate expirationDate externalRemarks form emergency highPriority ignoreHistory manual locationTypeCode nextPayerCode paidDate payerCode precedingPayerCode priceDate processType providerEntityReference providerReference receiptDate referenceCode serviceSpecialtyCode status transactionSourceCode type > <totalAllowedAmount/> <totalClaimedAmount/> <claimantProvider/> <claimantRelation/> <claimDiagnosisList/> <claimMessageList/> <locationProvider/> <paymentBeneficiaryProvider/> <paymentBeneficiaryRelation/> <paymentReceiverProvider/> <paymentReceiverRelation/> <paymentSpecificationReceiverProvider/> <paymentSpecificationReceiverRelation/> <referralProvider/> <serviceProvider/> <unfinalizeReasonList/> </claim>
The following snippet contains the structure of the claim line:
<claimLine allowedNumberOfUnits authorizationCode authorizationExceptionType claimedNumberOfUnits code endDate encounter emergency keepBenefits keepPricePrincipalProcs keepPricing replaced originalClaimLineCode pricePrincipalProcedure1 pricePrincipalProcedure2 pricePrincipalProcedure3 locationTypeCode priceInputDate priceInputNumberOfUnits processAsIn providerEntityReference providerReference replacementClaimLineCode referenceCode reservationCode reservationLineCode sequence serviceSpecialtyCode startDate transactionSourceCode> <allowedAmount/> <benefitsInputAmount/> <benefitsProvider/> <claimedAmount/> <claimLineContractReferenceList/> <claimLineDiagnosisList/> <claimLineLimits/> <claimLineMessageList/> <claimLineModifierList/> <claimLineOverride/> <claimLineParameterList/> <claimSubLineList/> <locationProvider/> <paymentReceiverProvider/> <paymentReceiverRelation/> <precedingPayerPaidAmount/> <priceIndividualProvider/> <priceOrganizationProvider/> <procedure/> <procedure2/> <procedure3/> <referralProvider/> <serviceProvider/> </claimLine>
Sending Out Unmatched Codes
It is possible that a claim is sent out for (re)pricing while not all information on the claim has been mapped to reference data. If this is the case, then the response message contains the unmatched codes.
This is explained in more detail for insurable person or objects and providers. For all other elements that are possibly non-matched, the response message will simply contain the unmatched code. For example, if a procedure code could not be matched, then the <procedure> element will contain the non-matched Code. and Flex Code Definition Code instead of an actual code and flex code definition code (as stored in the Procedure table).
Apart from the insurable person or object, relation (claimant, payment receiver, provider, the following attributes may contain an unmatched code:
-
element procedure, procedure2 and procedure3, attribute Code
-
element procedure, procedure2 and procedure3, attribute
-
flexCodeDefinitionCode
-
-
element diagnosis on claim and claim line , attribute Code
-
element diagnosis on claim and claim line , attribute
-
flexCodeDefinitionCode
-
-
element diagnosis on claim and claim line , attribute
typeCode
-
elements claim and claimLine, attribute
servicingSpecialtyCode
-
elements claim and claimLine, attribute
authorizationCode
-
elements claim and claimLine, attribute
locationTypeCode
-
element claimLineModifier, attribute Code
-
element message on claim and claim line, attribute Code
-
element claimLineContractReference, attribute Code
Sending Out Logically Assumed Values
The Claims model allows a number of fields to be stored on more than one level. For example, the list of diagnoses codes can be specified on both the claim header and the claim line. These fields are:
-
serviced person
-
serviced object
-
service provider
-
service specialty
-
location
-
referral provider
-
authorization code
-
emergency indicator
-
payment receiver
-
diagnoses
-
location type
In context of these fields, this integration point functions as follows:
-
If the claim line field is unspecified, then the value of its counterpart field on the claim level is sent out.
-
If the fields has dynamic data(fields and/or records), only the data that is also configured on the claim line level, will be sent out.
-
Consider an example where there is a dynamic field on claim diagnosis as patientAttendance. In case there are no claim line diagnoses present, the claim diagnosis will be sent out on the claim line level. The dynamic field on the claim diagnosis will only be part of the claim line level, if the same is configured on claim line diagnosis also.
-
-
-
If the claim line field is specified, then that value is sent out.
Amounts
Each element that represents an amount holds a fixed set of attributes. Consider the <allowedAmount> element to clarify:
... <allowedAmount currencyCode> {value} </allowedAmount> ...
Dynamic Fields
For details on how the dynamic fields and dynamic records are handled by the Oracle Health Insurance application, refer to the concepts in the Developer Guide.
Diagnoses
The claim can contain one or more diagnoses on the claim and claim line level.
<claimDiagnosisList> <claimLineDiagnosis sequence typeCode /> <diagnosis code flexCodeDefinitionCode/> </claimLineDiagnosis > </claimDiagnosisList>
Procedures
Claim lines and claim sub lines can contain one or more procedures per line. The <procedure> element structure is the same for both levels.
<procedure code="56.00" flexCodeDefinitionCode="ICD-09-CM" />
Messages
The claim can contain one or more messages on the claim and claim line level. Each message contains the message code, the message origin (EXTERNAL or MANUAL) and the placeholders.
Consider the following example:
<claimLineMessageList> <claimLineMessage code origin value0 value1 value2 value3 value4 value5 value6 value7 value8 value9 transactionSourceCode referenceCode/> </claimLineMessageList>
Providers
The following elements in the pre-finalized out claim message represent providers:
-
<serviceProvider>
-
<location>
-
<referralProvider>
-
<benefitsProvider>
-
<priceOrganizationProvider>
-
<priceIndividualProvider>
-
<claimantPovider>
-
<paymentBeneficiaryPovider>
-
<paymentReceiverPovider>
-
<paymentSpecificationReceiverPovider>
Providers, both organizations and individuals, are identified by their code and flex code definition.
The provider has the following structure (consider service provider to clarify)
<serviceProvider code flexCodeDefinitionCode name/> <matchingContext nonMatchedName nonMatchedAddress <dynamicField name value/> <matchingContext/> </serviceProvider>
In the event that a provider was successfully matched, then the provider code, the provider code flex code definition code and the provider name are sent out. For individual providers, the formatted name is used.
Consider the following example:
... <serviceProvider code="1234567890" flexCodeDefinitionCode="NPI" name="John Smith"> </serviceProvider> ...
However, in the event that Claims is unable to find a matching record for a provider, any information that is stored for the purpose of establishing a manual match is sent out as well.
... <serviceProvider code="1234567890" flexCodeDefinitionCode="NPI" /> <matchingContext nonMatchedName ="John Smith" nonMatchedAddress="H.P. Hospital" <dynamicField name ="ReferenceNumber" value="7843748374"/> <matchingContext/> </serviceProvider> ...
Relations
The following elements in the message represent relations
-
<claimantRelation>
-
<paymentBeneficiaryRelation>
-
<paymentReceiverRelation>
-
<paymentSpecificationReceiverRelation>
The relation has the following structure (consider claimant relation to clarify):
<claimantRelation> code dateOfBirth name> <matchingContext nonMatchedName nonMatchedAddress <dynamicField name value/> <matchingContext/> </claimantRelation>
Serviced Person and Object
The following elements in the pre-finalized out claim message represent serviced persons:
-
<insurableEntityType.usageName>
The insurable entity of the type person has the following structure:
<matchingContext nonMatchedName nonMatchedAddress <dynamicField name value/> <matchingContext/>
In the event that the serviced person was successfully matched, only the code, formatted name and date of birth are sent out.
In case the serviced person is not matched, any information that is stored for the purpose of establishing a manual match is sent out as well. Consider the following example:
... <persons code="HP23453" -- as in the SERVICED ENTITY CODE name="" dateOfBirth="2001-02-02" -- as in the SERVICED ENTITY DATE /> <matchingContext nonMatchedName =""Jones, M.A."" --as in the SERVICED ENTITY NAME nonMatchedAddress <dynamicField name ="ReferenceNumber" value="432423423"/> <matchingContext/> ...
In the event that the serviced object is successfully matched, only the code and description is sent out. In case the serviced object is not matched, any information that is stored for the purpose of establishing a manual match is sent out as well.
Unfinalize Reasons
The claim can contain one or more un-finalize reasons on the claim level.
Consider the following example:
... <unfinalizeReasonList> <unfinalizeReason code="UNF44" sourceReference="" /> </unfinalizeReasonList> ...
Bundled and Unbundled Claim Lines
A bundled claim line is a claim line that replaces one or more other claim lines in the same claim. This is stored in the claims model by maintaining a reference in the replaced lines to the replacing claim line.
Consider a scenario in which claim lines 1, 2 are replaced by (have been bundled into) claim line 3:
claim> ... <claimLineList> <Claimline code="1" .... replacementClaimLineCode ="3" replaced="Y"/> <Claimline code="2" .... replacementClaimLineCode ="3" replaced="Y"/> <Claimline code="3" ..../> <claimLineList> <claim>
An unbundled claim line is a claim line that is replaced by one or more other claim lines in the same claim. This is stored in the claims model by maintaining a reference in all the replacing claim lines towards the original unbundled claim line.
Consider a scenario in which claim line 4 is replaced by (has unbundled into) claim line 5, 6:
<claim> <claimLineList> <Claimline code="4" .... indReplace="Y"/> <Claimline code="5" ... originalClaimLineCode ="4"/> <Claimline code="6" ... originalClaimLineCode ="4"/> </claimLineList> </claim>
The claim line code attribute is used to identify claim lines within a claim message. A claim line code is unique within a claim.