SCE updates the claim with line item details received from ClaimsXten. For each ClaimsXten code an equivalent SCE event code and/or action code may be reported on the claim. Based on the event code configuration, SCE may pend or deny the claim or report the event as informational. When an action code is reported, SCE may reprocess the claim to apply the changes recommended by ClaimsXten.

The CXTResponseToSCECodes decision table uses the following data to determine whether an event code or action code should be reported on the claim and which one(s) to report:

• Form type
• Rule acronym
• Certainty
• Case action
• Rule type
• Claim line action
• Customer adjustment code
• Audit type

The detailed steps followed by SCE when the outbound XML is received from ClaimsXten are:

• SCE receives the outbound XML from ClaimsXten and loads the claim header and claim line level fields along with the additional ClaimsXten fields received.
• If a recommendation for an adjustment of a history claim is received from ClaimsXten (for example, a denial recommendation or a change in revenue code or diagnosis code) SCE creates a work object and routes it to a work queue for review and action by a claims examiner.
• For recommendations pertaining to the current claim, SCE checks the “Claim Line Action” for each service line. SCE maps each claim line action to an event code and/or action code based on the CXTResponseToSCECode decision table. Claim line actions that may be received on the response are:
  • DENY – Disallow a payment for the referenced claim line.
  • ADD – Create net-new line, associated with other DENY line(s) in the same case.
  • SUPPORT – Support other case lines only, not an actionable case line.
  • PAYPERCENT – Lines with a multiplier to be considered in the determination of reimbursement on the claim line.
• If the Claim Line Action = Deny
  • SCE maps the response received to the event code and/or action code defined in the CXTResponseToSCECode decision table.
  • The claim line status is set to Denied.
  • The claim line denial is captured in the user interface and the Process History.
• If the Claim Line Action = Support
  • SCE maps the response received to the event code and/or action code defined in the CXTResponseToSCECode decision table.
  • The support line is not subject to further processing
• If the Claim Line Action = Add
  • SCE maps the response received to the event code and/or action code defined in the CXTResponseToSCECode decision table.
• ClaimsXten provides a new line number for each line it adds; the new line is added to the claim and the line number is displayed with an “A” to indicate it was added.
• Action codes A1 or A2 are added to the claim. These action codes are configured in the module bypass for ClaimsXten so that when the claim is reprocessed, ClaimsXten is not called again.
  • A1 – Assigned when an ADD action is received from ClaimsXten
  • A2 – Assigned for all other ClaimsXten responses
• The claim is reprocessed with the new information.
  • Note that when the claim is reprocessed, the ClaimsXten module will be bypassed based on the action codes reported. Viewing the process history tab will show the history of each execution. The Visualize claim process only shows the last execution.

SCE populates the Audit type column in CXTResponseToSCECode decision table by following the logic outlined below:

• SCE parses the outbound XML response from ClaimsXten.
• If the response has errors, it maps the errors to the appropriate event code(s).
• Using the DetermineAuditType decision table, SCE determines the Audit type based on the rule acronym, claim line action on the current claim line and other lines within the same case, and other factors seen in the screenshot below.
• An Audit type is calculated for each claim line.