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
    overturned
  />
    ...
</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 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,CANCEL 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

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,CANCEL 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

Use cases

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

Code

Description

Publish message?

PICAU

Pend in change for an automatic update

The following message is configured:

Message

Code	Message
FRAUD	Line is denied for suspect fraud

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