Summary

Claim AI-based Adjudication System

Use cases

AI-based Claim Adjudication Status

The following state diagram corresponds to the Claim fields status with the updated adjudication process.

AI-based Claim Adjudication Process

The following activity diagram proposes the updated adjudication process.

Adjudicate Claims with AI Use Case

Deployment architecture

Claim-AI Quality Module

Claim-AI Quality Responsibilities

• Contribute to Claim Review Search with Medical Item/Service and AI-categorized filters

• Prepare the new checked claims for AI categorisation

• Push Claims to Claim-AI module on scheduled task and/or event-based activation and update Claims based on the response

• Reports Claim adjudication misclassifications

Models

The new Claim-AI adjudication process is executed between Rule-based engine and the manual adjudication. Because we decided not to add additional statuses to Claim, requiring to modify the Claim module, we propose to use the JSON extensions that can be added and updated from the Claim-AI Quality module.

The following JSON extensions will be created to support the Claim AI-based Categorisation:

• claim_ai to add information on Claim. The field was_categorized allow to filter automatically checked Claim that have not been categorized by AI and ‘hide’ them for manual adjudication.

  "json_ext": {
    "claim_ai_quality": {
      "was_categorized": "boolean", // whether the claim has been categorized by Claim-AI module or not
      "request_time": "datetime", // time when the claim has been sent to Claim-AI module
      "response_time": "datetime" // time when the claim adjudication response has been received from Claim-AI module
    }
  }

• claim_ai_item to add information on ClaimItem and ClaimService. This is used to store AI categorisation result to allow the misclassification report.

  "json_ext": {
    "claim_ai_quality": {
      "ai_result": "integer" // claim adjudication value provided by Claim-AI module (for misclassification report)
    }
  }

Because ClaimItem and ClaimService doesn’t support custom fields, these classes need to be extended with ExtendableModel class.

Migrations

Because the Claim-AI modules are activated after Claims have been adjudicated (the data used for the training), a migration script needs to be created to insert the JSON fields into the available data. The following initializations will be used:

Claim.json_ext.claim_ai_quality.was_categorized = true
Claim.json_ext.claim_ai_quality.request_time = Claim.ValidityFromReview
Claim.json_ext.claim_ai_quality.response_time = Claim.ValidityFromReview
ClaimService.json_ext.claim_ai_quality.ai_result = ClaimService.ClaimServiceStatus
ClaimItem.json_ext.claim_ai_quality.ai_result = ClaimItem.ClaimItemStatus

Module Configuration

The following module configuration is accepted:

{
  claim_ai_url: string // URL of the openIMIS instance running Claim-AI module. Default: ""
  event_based_activation: boolean // True if the checked Claims are sent to Claim-AI module immediatly after check. Default: False 
}

Claim-AI Adjudication Activation Methods

Two activation methods, allowing to start the Claim-AI module processing, are available in the Claim-AI Quality module.

Event-based activation

This activation is based on the openIMIS mutation signal signal_mutation_module_after_mutating on SubmitClaimMutation mutation (red AcceptSignalAction in AI-based Claim Adjudication Process). First, this event allows to prepare the Claims for the Claim-AI adjudication processing. Second, it would allow to push the Claims to Claim-AI module for the actual adjudication. Because we are interested to activate the processing using this event, we propose to define the module configuration variable event_based_activation, allowing to push the checked Claims immediately after Rule Engine check.

The event-based activation allows a continuously communication flow between the openIMIS implementation and the Claim-AI implementation.

Schedule Task activation

This activation is using the DjangoScheduler to schedule the sending of Claim to Claim-AI module (pink AcceptSignalAction in AI-based Claim Adjudication Process). As the Event-based activation, this trigger is also pushing the checked Claims to Claim-AI module.

In case the Event-based activation is activated (event_based_activation=True), the triggering of the Schedule Task will not do anything because all the checked Claims have already been sent immediately after the Rule Engine execution.

Claims Preparation

In case the Schedule Task activation is used, the time-lapse from when the Claims are submitted and automatically checked by the Rule Engine and when they are adjudicated by the Claim-AI module can be very long. During the time-lapse, the Medical Officers reviewing manually the Claims should not be allowed to select any checked Claim that was not processed by the Claim-AI module. To realize this mechanism, we are adding additional JSON extension (see Models) and additional filter based on the JSON extension (see Custom Claim Review Search Filters).

Pushing Claims to Claim-AI Module

Connecting to the Claim-AI Instance

Because the communication is done through WebSocket protocol, the Claim-AI Quality module needs first to connect to the Claim-AI module (see Adjudicate Claims with AI Use Case). This connection is persistant and remains opened until all responses are received.

Build FHIR Claim Bundle

The Claim-AI module is accepting FHIR Claim Bundle resource and respond with FHIR ClaimResponse Bundle resource (see WebSocked API). Before calling the Claim-AI API, we are transforming all prepared Claims to FHIR Claim Bundle (see partition Build FHIR-Claim Bundle in AI-based Claim Adjudication Process).

FHIR Contained Resources

FHIR Contained Resources feature allows to integrate the referred resourced. In case of FHIR Claim, these are Patient, Condition, Medication, HealthcareService, Practitioner, ActivityDefinition.

Because AI-model is requiring information from other resources referenced by the Claim, these resources must to be accessible from the Claim sent by Claim-AI Quality module.

The mechanism to build Claim resource with Contained Resources is to be developed in the openIMIS FHIR R4 module.

The construction based on Contained Resources should be possible based on query variable contained=true/false. Default false.

Custom Claim Review Search Filters - Frontend

The following contributor filters to claim.ReviewsFilter are defined:

• ClaimFilterMedicalItem allows Medical Officers to filter the Claims list based on a specific Medical Item (only one from autocomplete list)

• ClaimFilterMedicalService allows Medical Officers to filter the Claims list based on a specific Medical Service (only one from autocomplete list)

• ClaimFilterAIProcessed allows Medical Officers to display or hide the non AI-processed Claims (checkbox, decision if this is hidden or not )

AI Categorisation Misclassification Report

A report is generated that provides the following information (based on manual reviewed Claims ):

• accuracy scores

• number of True Positives results

• number of True Negative results

• number of False Positive results

• number of False Negative results

Decision:

• should this report be a webpage or a PDF

• which trigger: button, link, menu entry

Claim-AI Module

Claim-AI Responsibilities

• WebSocket API accepting FHIR Claims to categorize them based on a ML model

AI-model execution

WebSocked API

The Claim-AI module will define the following endpoints. The base URL for this module is /claim_ai.

Reasoning

The following constraints are taken in consideration:

• In case of event base activation, high interactions modes

First, we have to select the communication mode:

• In Synchronous mode, the Claim-AI Quality module needs to wait before the continuing its execution.

• In Asynchronous mode, the Claim-AI Quality module continue to execute without waiting for the response.

Because the execution of AI Model can take time, the solution is to use Asynchronous mode.

We have identified 3 interactions modes:

• The REST API Asynchronous Request-Reply pattern (i.e. https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply) allows the client to request the status of the operation and get the response when the operation is completed. If we chose to use the event base activation, there could be too many processes that request the operations status, so we will not chose this interaction mode.

• The REST API Request with ResponseURL allows the server to send back the response to the ResponseURL endpoint provided by the client. This interaction mode suppose that both server and client provide REST API endpoints. To reduce the Claim-AI Quality module complexity, we sill not use this interaction mode.

• WebSocket API is a persistent connection between a client and server. WebSockets provide a bidirectional, full-duplex communications channel that operates over HTTP through a single TCP/IP socket connection. At its core, the WebSocket protocol facilitates message passing between a client and server. WebSocket is ideal for a scenario where high loads are a part of game.

WebSocket API connection endpoint

This endpoint allows the client to connect through WebSocket and sent the FHIR Claim Bundle to be adjudicated.

Call: /claim_ai/Claim