Claims Update Integration Point
This chapter describes the Claims Update Integration Point. The purpose of this integration point is to support claim edits through a web service call, i.e., in an automated fashion and without the need for manual intervention.
Design Choices
This integration point can update claims that are either in the Change, Entry, Manual Pricing, Manual Pricing Adjudication, Pricing Finalized, Manual Benefits, Manual Adjudication or Finalized status. For updating pricing finalized or finalized claims one or more unfinalize reasons need to be provided.
This integration point supports the updating claims, and the updating, adding and removing of claim lines. This integration point does not support the creation of new claims, nor the removal of existing claims.
Existing claims and claim lines are identified and matched by their code. It is assumed that the service or component that sends the claim update request knows the codes of the existing claim and claim lines that need to be updated or - for claim lines only - deleted:
-
Specifying a claim code that does not exist will result in a fatal message.
-
Specifying a claim line code that does not exist will create a new claim line.
Upon specifying a list element in the request message, all existing list details will be replaced by the list details specified in the request messages. For example, if the update specifies a diagnoses element on the claim line, the complete existing list of claim line diagnoses is replaced. Note though that existing claim lines are exempted from this functionality and will only be deleted if this is specified explicitly. Also note that the messages list element features an option to retain existing message instead of replacing them.
This integration point can be used to mark claim lines as 'replaced' by other claim lines. It also allows edits to process fields.
An update request can indicate that a claim should be resubmitted after doing the update. Resubmitting the claim through this integration point triggers the exact same process as resubmitting a claim manually.
High priority claims
It is possible to mark a claim as high priority, meaning that it will be picked up for processing with the highest priority possible. All submits for processing from the UI will automatically result in those claims being picked up with the highest priority because an operator is waiting for the results. For a claim that is updated through the IP, it’s a choice: normally no high priority is needed, but there could be exceptions.
Claims Update Request
The claims update request message must be sent as HTTP PUT to the URI:
-
http://[hostName]:[portNumber]/[api-context-root]/claimsupdate/{claimCode} to only update
-
http://[hostName]:[portNumber]/[api-context-root]/claimsupdate/{claimCode}/submit to update and submit claims for processing
The request message has the following structure:
<claim authorizationCode claimDate dataAccessGroupCode dueDate expirationDate externalRemarks emergency externalPricing externalBenefits highPriority overwriteMessages preprocessingDone pricingDone sendOutForPreprocessing sendOutForPricing locationTypeCode nextPayerCode paidDate precedingPayerCode priceDate providerEntityReference providerReference receiptDate serviceSpecialtyCode type claimSetCode > <claimDiagnosisList/> <claimMessageList/> <claimPendReasonList/> <claimTagActionList/> <claimUnfinalizeReasonList/> <claimantProvider/> <claimantRelation/> <locationProvider/> <paymentBeneficiaryProvider/> <paymentBeneficiaryRelation/> <paymentReceiverProvider/> <paymentReceiverRelation/> <paymentSpecificationReceiverProvider/> <paymentSpecificationReceiverRelation/> <referralProvider/> <serviceProvider/> <claimLineList/> </claim>
The following snippet contains the claim line structure:
<claimLine code allowedNumberOfUnits authorizationCode authorizationExceptionType benefitsAgeInputDate benefitsInputDate claimedNumberOfUnits endDate delete encounter emergency keepBenefits keepPricing overwriteMessages originalClaimLineCode pricePrincipalProcedure1 pricePrincipalProcedure2 pricePrincipalProcedure3 releaseOverride unlock locationTypeCode priceInputDate priceInputNumberOfUnits processAsIn providerEntityReference providerReference sequence serviceSpecialtyCode startDate replacementClaimLineCode waitingPeriodInputDate > <allowedAmount/> <benefitsInputAmount/> <benefitsProvider/> <claimedAmount/> <claimLineContractReferenceList/> <claimLineDiagnosisList/> <claimLineLimitList/> <claimLineMessageList/> <claimLineModifierList/> <claimLineOverride/> <claimLineParameterList/> <claimLinePendReasonList/> <claimSubLineList/> <locationProvider/> <paymentReceiverProvider/> <paymentReceiverRelation/> <precedingPayerPaidAmount/> <priceIndividualProvider/> <priceOrganizationProvider/> <procedure/> <procedure2/> <procedure3/> <referralProvider/> <serviceProvider/> </claimLine>
Consider the following snippet to understand the diagnosis element structure
<claimDiagnosisList> <claimDiagnosis sequence typeCode/> <diagnosis code flexCodeDefinitionCode/> </claimDiagnosis> </claimDiagnosisList>
Consider the following snippet to understand the message element structure
<claimMessageList> <claimMessage code origin value0 value1 value2 value3 value4 value5 value6 value7 value8 value9 transactionSourceCode referenceCode /> ... </claimMessageList>
This integration point requires the correct functional identifiers for an update of a provider or serviced person or object. The following types are used to identify serviced person/object and providers.
-- example of a serviced person or object -- example of a provider <serviceProvider code flexCodeDefinitionCode />
The following snippet describes the claims tag element
<claimTagActionList> <claimTagAction tag action> </claimTagAction> ... </claimTagActionList>
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 OHI application, refer to the concepts in the Integration Guide.
Claims Update Response
Please refer to the 'Response Messages' section in the HTTP API Integration Points part of the Common Features book for more details.
The system also returns a link to the status resource in the Location header when a claim is submitted for processing:
Location: http://[hostName]:[portNumber]/[api-context-root]/claims//status
This enables the external system to track the progress by issuing a GET to the status URI returned in the Location header. For details on the status resource refer section Operations in the HTTP API guide.
Processing
Updating Claim and Claim Lines
A field can be cleared by sending the attribute without sending a value (an empty string). Not all claim fields can be updated due to their non-transferable or technical nature. Non-updateable claim fields are not included in the request message. Once all updates are executed, the claim is saved (this is the same effect as clicking the save button in the Change Enter Claim page). If within a claim, any of the updates fail, then none of the updates for that claim are saved.
The indicator changedInUi is reset (set to null) when a claim is successfully updated (this indicator is set to the value true when a claim is changed in the Manual Change page after finalization; it needs to be reset if the claim afterward is updated by the Claims Update Integration Point).
Note that updating a field that was previously unmatched, removes the unmatched information.
Locked claim lines (if the unlock is not sent in as true) cannot be updated or deleted.
A locked claim line must be first unlocked in order to update or delete it. Both the actions can be performed through a single request (unlocking to update or unlocking to delete). For example to delete a locked claim line indicator delete and unlock both should be set to true in the request message.
Existing claim lines that have been marked as replaced, cannot be updated. However, if a replacement is voided* because the replacing line(s) is (are) removed, the previously replaced line is no longer considered replaced and may then be updated. Thus, it is possible to update a replaced line by specifying in the request both the update of that line as the removal of its replacing line(s).
(*) See "Adding and removing claim lines" below.
If the update specifies a unfinalize reasons element and the claim has status Pricing Finalized, then the claim enters the level 2: unfinalize flow. If the update specifies a unfinalize reason element and the claim has status Finalized, then the claim enters the level 2: unfinalize flow as long as there is no settlement reason specified on the external claims data; if there is a settlement reason specified on the external claims data, then the update will fail. Through the unfinalize flow, the claim is set to status Change, the old unfinalize reasons are removed and the new unfinalize reasons are attached to the claim. If the update specifies a unfinalize reason element and the claim does not have the status Pricing Finalized or Finalized, then this element is ignored. The rationale for this is that claim unfinalize reasons can never be updated, their sole purpose is being added when unfinalizing.
The request allows the claim field preprocessingDone and pricingDone to be updated. Setting preprocessingDone to the value true means that the claim is not sent out for preprocessing. Setting pricingDone to the value true means that the claim is not sent out for pricing.
The diagnosis element may specify dynamic fields that extend the Claim Diagnoses and Claim Line Diagnoses tables. Duplicate combinations of diagnosis and diagnosis type are ignored, as in the Claims In Integration Point.
If the update specifies a messages element, processing depends on the indicator overwriteMessages. If this is set to true (or not specified), all existing messages that originated from either a manual edit or an external source are removed and replaced with the messages specified in the request. If overwriteMessages is set to false, existing messages are retained and the messages specified in the request are added to the claim or claim line.
To prevent duplicates, any message specified in the request is only added to the claim or claim line, if it’s not already present. To determine whether a message is already present (and as such is a duplicate), all attributes of the message (except origin) are taken into account: i.e. code, parameter 0 through 9, transaction source and reference code. Messages in the request itself are de-duplicated almost in the same manner; all attributes (including origin) are taken into account.
It is possible to specify the origin of the message (EXTERNAL or MANUAL). If the origin is not specified then the message added as a result of using this integration point is considered to have originated from an external source (origin EXTERNAL). OHI Claims requires knowledge of message origins especially when reprocessing a claim.
Through this integration point claim tag actions can be set. The allowable values are R (Redo), S (Skip), H (Hold), F (Force) and U (Undo). For all actions except Undo, this means a straightforward update of the claim tag action.Note that the claim tag actions that are configured as being possible are first created through a business rule. The claim tag actions that are sent in are just updates of the existing claim tag actions. If a claim tag action is sent in for a skip tag that was not created as a claim tag action, then nothing happens: no claim tag action is created nor any message is generated.
Undo mimics the Undo functionality in the MANUAL CHANGE page: it first discards the existing tagged results for that claim and ends by setting the skip tag action to Redo. So if, e.g., a skip action of Skip exists for iCes edits and Undo is sent in then the iCes edits tagged results are removed after which the skip tag action for iCes edits gets the value Redo.
Updating pends
Update Request
The status of the claim is set to CHANGE. The indicators preprocessingDone and pricingDone are unchecked if they are not explicitly set in the request.
If there are new pend reasons in the request, they are then attached to the claim/claimline in the status 'CHANGE'.
Attaching of the pend reasons deviates from the standard HTTP behavior of working with a detail list. Here, the system looks at each pend reason sent in the request. The pend reason is attached to the the claim/claimline if it is a new one, otherwise it is ignored (when an existing one is sent in the request). The pend reason code determines the uniqueness. Also, the existing pend reasons are not removed when an existing pend reason is not sent in the list.
Update and submit
The system first resolves the relevant* pends for the current claim (status) only if the user has access privileges to all the relevant pend reasons. The resolved pend reasons are removed from the claim, bill and claim line. If there is a relevant unresolved pend reason for which the current user has no access, no change is made to the claim at all. System returns error CLA-IP-CLAI-023 "Unresolved pend reasons exist and you don’t have the privileges to resolve them" in the response.
If no relevant pend reasons remain, the system also checks for an open work flow task for that claim. If so, the work flow integration point sends out a message to inform the work flow distribution system that the task can be closed. The status of the claim is then set to CHANGE (is not already). The indicators preprocessingDone and pricingDone are unchecked if they are not explicitly set in the request. Next, the system attaches the pend reasons that are sent in the request ( this is same as described for the update request). The claim is then submitted and it re-enters the level 2: Receive, Enter and Change Claim flow and triggers the exact same process as submitting a claim in the status 'CHANGE' manually (through UI - Change page). That is, if any relevant pend reasons remain (this is possible when new pends are sent in the request), the claim’s status remains CHANGE. If at least one of the remaining relevant pend reasons has a checked publish message indicator, a new work flow integration point message is sent out. In effect, a claim will not be picked up by the process flow until all the relevant pend reasons have been resolved.
* Relevant pend reasons - For a claim in the status other than Manual Adjudication or Manual Pricing Adjudication with external benefits, all the unresolved pend reasons with the indicator Adjudication only set to false are considered as relevant. For the status Manual Adjudication and Manual Pricing Adjudication, all the unresolved pend reasons are considered relevant.
Unlocking claims lines
When a locked claim line is unlocked using the indicator unlock, updates and delete on the claim line is allowed. The status of the locked claim line is cleared.
The system ignores this indicator for an already unlocked line.
Updating allowed amount and/or allowed number of units
When updating the allowed amount and/or the allowed number of units ( on a reservation or claim), the new values will normally be no longer in sync with the provider limit consumptions. This typically happens in a situation where the allowed amount and/or allowed number of units are determined by an external party, but the callouts need to be done internally.
This functionality is similar to changing the allowed amount and/or allowed number of units in the Manual Pricing page, but then restricted to the effects on the claim line at hand.
Therefore, for each line on which at least one of allowed amount and allowed number of units was edited, take the following actions:
-
The keep pricing and manual pricing indicators
-
are checked for a request that is not the result of a callout rule
-
are untouched for a request that is the result of a callout rule
-
-
Uncheck the keep benefits indicator if checked
-
Remove all claim line messages that originated from provider limits (origin PRICING LIMIT)
-
Recalculate the provider limit consumptions of the claim line based on the edited allowed amount and/or allowed number of units:
-
It is possible that existing provider limit consumption has to be updated
-
It is possible that existing provider limit consumption (plus counter period/counter) has to be deleted
-
It is possible that new provider limit consumption (plus counter period/counter) has to be created
-
-
Reevaluate and create new provider limit category messages and/or reservation regime messages.
The allowed amount element:
<allowedAmount currencyCode >{value} </allowedAmount> ...
which opens up the possibility that the currency of an existing allowed amount is changed. Because this is illogical, a fatal message is raised (CLA-IP-UPDT-042).
Updating expiration date
When expiration date on the reservation claim is updated, the expiration date on the provider limit consumptions of all the claim lines that are not locked is updated to the new date.
Updating price principal procedure indicators
Price principal procedure indicators will typically be set either through Claims In or through the process field derivation rules. It is, however, also possible to update one or more of these indicators through either the UI or the Claims Update IP; the functionality of these updates is analogous.
If releaseOverride has value true then the indicator to keep principal procedures is set to false, irrespective of one of the price principal procedures indicators being set or not. This has the effect that the process field derivation rules for the price principal procedure indicators are not skipped.
if releaseOverride is not specified or has value false and one or more price principal procedure indicators are specified in the Claims Update IP then the indicator to keep principal procedures is set to true. This has the effect that the process field derivation rules for the price principal procedure indicators are skipped.
Adding and removing claim lines
A new claim line is created if the claim line code specified in the request does not match with any existing claim line. A value must be provided for all required fields (e.g. for field 'Sequence').
To delete claim lines, the element claimline features the indicator deleted. If delete is set to true, the existing claim line (matched on code) is deleted.
Claim line replacements
New claim line replacements can be designated by this integration point: For an elaborate description of this functionality, refer to the text on the Claims In integration point (HTTP) (in the implementation guide for claims).
Note the following specifics with regard to the Claims Update integration point:
-
Replacements can only be designated for claim lines which are not yet replaced. A fatal error message is raised when the request message designates a replacement for a claim line that is already replaced by another line (CLA-IP-UPDT-037).
-
It is not possible to update replaced claim lines (i.e. claim lines replaced by other claim lines). Trying to do so will raise a fatal error message (CLA-IP-UPDT-015).
-
It is not possible to delete replaced claim lines (i.e. claim lines replaced by other claim lines). Trying to do so will raise a fatal error message (CLA-IP-UPDT-035).
-
It is possible to delete replacement claim lines (i.e. claim lines which replace other claim lines). Upon deleting a claim line which is itself the replacement of one or more other claim lines, those claim line replacements are voided. I.e. the replaced claim lines will then no longer be marked as replaced. However, note that a replacement must be voided in its entirety or not at all. If a claim line is replaced by multiple other claim lines (i.e. an unbundling) either all of the replacement lines must be deleted (which would void the replacement), or none of them. Deleting one or more of the replacement lines but not all will raise a fatal error message (CLA-IP-UPDT-036).
-
It is not possible to update the serviced entity type of an existing claim (line). Trying to do so will raise a fatal error message (CLA-IP-UPDT-044).
To avoid conflicting situations during processing, the following execution order is applied:
-
Deletes of replacement claim lines are executed before execution of claim line updates, deletes and (new) claim line replacements. This entails that existing claim line replacements are voided first (where applicable) so that updates, deletes and new claim line replacements can be executed.
-
Addition of new claim lines is executed before execution of claim line replacements. This makes it possible to specify claim line replacements both for existing claim lines as well as for new claim lines.
Response Messages
The following messages can be returned to clarify why an update request failed to execute.
Code | Sev | Message |
---|---|---|
CLA-IP-UPDT-001 |
Fatal |
The claim code {code} is unknown |
CLA-IP-UPDT-002 |
Fatal |
The claim line code {code} is unknown |
CLA-IP-UPDT-003 |
Fatal |
The provider with code {code} ({flexCodeDefinitionCode}) is unknown |
CLA-IP-UPDT-004 |
Fatal |
The diagnosis code {code} ({flexCodeDefinitionCode}) is unknown |
CLA-IP-UPDT-005 |
Fatal |
The procedure code {code} ({flexCodeDefinitionCode}) is unknown |
CLA-IP-UPDT-006 |
Fatal |
The serviced person code {code} is unknown |
CLA-IP-UPDT-007 |
Fatal |
The message code {code} is unknown |
CLA-IP-UPDT-008 |
Fatal |
The data access group code {code} is unknown |
CLA-IP-UPDT-009 |
Fatal |
The specialty code {code} is unknown |
CLA-IP-UPDT-010 |
Fatal |
The coverage regime code {code} is unknown |
CLA-IP-UPDT-011 |
Fatal |
The product code {code} is unknown |
CLA-IP-UPDT-012 |
Fatal |
The pend reason code {code} is unknown |
CLA-IP-UPDT-013 |
Fatal |
The modifier code {code} is unknown |
CLA-IP-UPDT-015 |
Fatal |
The claim line {code} cannot be updated as it is a replaced line |
CLA-IP-UPDT-016 |
Fatal |
Cannot add pend reasons to claim {code} as it has the Entry status |
CLA-IP-UPDT-017 |
Fatal |
Cannot add pend reasons to claim line {code} as its claim has the Entry status |
CLA-IP-UPDT-018 |
Fatal |
The cover withhold category code {code} is unknown |
CLA-IP-UPDT-019 |
Fatal |
The unfinalize reason code {code} is unknown |
CLA-IP-UPDT-020 |
Fatal |
The claim cannot be unfinalized because it is settled |
CLA-IP-UPDT-022 |
Fatal |
The diagnosis type code {typeCode} is unknown |
CLA-IP-UPDT-023 |
Fatal |
The limit code {code} is unknown |
CLA-IP-UPDT-026 |
Fatal |
The location type code {code} in combination with claim form code {code} is unknown |
CLA-IP-UPDT-027 |
Fatal |
The second procedure code {code} ({flexCodeDefinitionCode}) is unknown |
CLA-IP-UPDT-028 |
Fatal |
The third procedure code {code} ({flexCodeDefinitionCode}) is unknown |
CLA-IP-UPDT-030 |
Fatal |
Field {procedure field} is not configured for this claim form |
CLA-IP-UPDT-031 |
Fatal |
The contract reference {code} is unknown |
CLA-IP-UPDT-032 |
Fatal |
The claim line code {code}, specified for (un)bundling purposes, is unknown |
CLA-IP-UPDT-033 |
Fatal |
The claim line replacements are not specified consistently |
CLA-IP-UPDT-034 |
Fatal |
A claim must have at least one claim line |
CLA-IP-UPDT-035 |
Fatal |
Claim line {code} cannot be deleted because it is replaced |
CLA-IP-UPDT-036 |
Fatal |
Replacement claim line(s) {claim line codes separated by ","} cannot be deleted without also deleting co-replacement claim line(s) {claim line codes separated by ","} |
CLA-IP-UPDT-037 |
Fatal |
Claim line {code} cannot be replaced by claim line {code} because it is already replaced by claim line(s) {claim line codes separated by ","} |
CLA-IP-UPDT-038 |
Fatal |
The funding arrangement code {code} is unknown |
CLA-IP-UPDT-039 |
Fatal |
The product line code {code} is unknown |
CLA-IP-UPDT-040 |
Fatal |
The product family code {code} is unknown |
CLA-IP-UPDT-041 |
Fatal |
The skip tag code {code} is unknown |
CLA-IP-UPDT-042 |
Fatal |
The new allowed amount currency should not differ from the existing one |
CLA-IP-UPDT-043 |
Fatal |
The serviced object code {code} and type {code} is unknown |
CLA-IP-UPDT-044 |
Fatal |
The serviced entity type {singular display name} in the request does not match with the serviced entity type {singular display name} on the existing claim |
CLA-IP-UPDT-045 |
Fatal |
Claim {code} with status {status} cannot be updated |
CLA-IP-UPDT-046 |
Fatal |
Claim {code} cannot be updated without specifying an unfinalize reason |
CLA-IP-UPDT-047 |
Fatal |
Only message origins MANUAL or EXTERNAL are allowed |
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 |
Attaching a fatal message to a finalized claim
A payer has a process where a claim goes through a fraud or abuse check. Because this check takes a fair amount of time, and only a relatively small number of claim lines are actually indicative of fraud, the payer chooses not to pend claims in OHI Claims for the duration of this check, but rather to do the check after the claims have been finalized. As a consequence, some claim lines are originally accepted but have to be denied once the fraud check turns out to be positive.
This process could be automated using the Claims Update Integration Point.
Assume a finalized claim with code "1234" and 4 claim lines with the following data:
Claim lines
Code | Procedure | Start Date | Messages |
---|---|---|---|
1 |
99218 |
03-01-2010 |
|
2 |
99761 |
03-01-2010 |
|
3 |
88880 |
03-01-2010 |
|
4 |
99900 |
03-02-2010 |
The following pend reason is configured:
Pend reason
Code | Description | Publish message? |
---|---|---|
PICAU |
Pend in change for an automatic update |
No |
The following message is configured:
Message
Code | Message |
---|---|
FRAUD |
Line is denied for suspect fraud |
When using the Claims Update Integration Point , it is called with the following message
<claims> <claim code="1234"> <claimUnfinalizeReasonList> <claimUnfinalizedReason code="Unfinalized for automatic update" sourceReference="AUTOUPD"/> </claimUnfinalizeReasonList> <claimPendReasonList> <claimPendReason code="PICAU" sourceReference="AUTOUPD"/> </claimPendReasonList> <claimLineList> <claimLine code="3"> <claimLineMessageList> <claimLineMessage code="FRAUD"/> </claimLineMessageList> </claimLine> </claimLineList> </claim> </claims>
This will cause claim 1234 to be unfinalized and pended in the status Change. Because the pend reason "PICAU" has a publish message indicator "NO", no workflow event is published. This request will take also update claim line 3 of claim "1234" by attaching the FRAUD message