...
| Plantumlcloud | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Adjudicate Claims with AI Use Case
...
The new Claim-AI adjudication process is executed between Rule-based engine and the manual adjudication (see AI-based Claim Adjudication Status section). Because we decided not to add additional statuses to Claim, requiring to modify the Claim module, we propose will 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_aito add information on Claim. The fieldwas_categorizedallow to filter automatically checked Claim that have not been categorized by AI and ‘hide’ them for manual adjudication.Code Block language json "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_itemto add information on ClaimItem and ClaimService. This is used to store AI categorisation result to allow the misclassification report.Code Block "json_ext": { "claim_ai_quality": { "ai_result": "integer" // claim adjudication value provided by Claim-AI module (for misclassification report) } }
| Plantumlcloud | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Because currently ClaimItem and ClaimService doesn’t support custom fields, these classes need to be extended with will also extend the ExtendableModel class.
Migrations
...
| Code Block | ||
|---|---|---|
| ||
{
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
page_limit: integer // Maximum number of claims to be sent to Claim AI module (0: unlimited). Default: 0
zip: boolean // Whether the communication payload is compressed or not. Default: False
} |
Claim-AI Adjudication Activation Methods
...
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 Compared to the Event-based activation, this trigger is also only pushing the checked Claims (the ones prepared during Event-based activation) 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.
...
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 this 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).
...
Because the communication is done through WebSocket protocol (see WebSocked API section), 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.
...
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. . In case of FHIR Claim, these are Patient, Condition, Medication, HealthcareService, Practitioner, ActivityDefinition. The mechanism to build Claim resource with Contained Resources is to be developed in the openIMIS FHIR R4 module. The construction based on In FHIR R4 module, the inclusion of Contained Resources should be possible based on the query variable contained=true/false. Default false (default false).
Pagination
Based on se server configuration (mainly the available memory), the total number of new checked Claims (more than 10,000 Claims) and integration of Contained Resources, the number of Claims sent should be limited. This means splitting the checked Claims in groups. The module configuration variable page_limit will allow to define the maximum number of Claims per Claim Bundle.
Getting the ClaimResponse from Claim-AI Module
After the categorisation by the Claim-AI Module, the second sends back the response as ClaimResponse. The ClaimResponse is then converted to Claim and is updated into the DB.
To ease the conversion from FHIR ClaimResponse to openIMIS Claim and saving into the DB, we have implemented the HTTP PUT method for ClaimResponse resource into openIMIS FHIR R4 Module.
Custom Claim Review Search Filters - Frontend
...
AI Categorisation Misclassification Report
A PDF report is generated that provides the following information (output 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
...
In order to generate this report, the user will have have to filter through the Review Claims search form and trigger the report through a button. Only the filtered Claims will be considered for the report.
Claim-AI Module
Claim-AI Responsibilities
WebSocket API accepting FHIR Claims to categorize them Claim Bundle and responding with FHIR ClaimRespose
Categorize Claims based on a ML model
...
model
...
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.
...
implement a WebSocked API (WebSocket vs REST article).
WebSocket API connection
This endpoint allows the client to connect to the WebSocket and sent the FHIR Claim Bundle to be adjudicated.
| Code Block |
|---|
ws://<server_IP>/claim_ai |
The connection to the WebSocket API is persistent and needs to be closed by the client. In case multiple clients connect to the WS, a new connection is created for each client.
Authentication
The client authentication is based on authentication key defined in the module configuration. This key represents a list of strings that is empty by default (= no authentication required). If the list contains at least one API key (string), the authentication is activated and the client needs to provide an API key that matches one of the strings from the list.
Communication protocol
The WS API accepts FHIR R4 Claim Bundle with Contained Resources and responds with FHIR R4 ClaimResponse Bundle.
| Note |
|---|
The FHIR R4 Claim and ClaimResponse is part of the openIMIS FHIR R4 Profile that defines the mapping of standard FHIR R4 resources with additional extensions. |
The communication is asynchronous. If the Client sends the Claim Bundles paginated/grouped, all Claim Bundles are added to a queue which, once treated, will send back the same grouped Claims as ClaimResponse. The update on the Client side will be done based on the Claim’s UUID.
To allow more claims to be send in one request, the payload can be compressed using ZIP. This will be activated based on the zip Module Configuration key. This option should be available on the Client too.
The communication protocol between the Client (Claim-AI Quality Module) and the server (Claim-AI Module) is described through the sequence diagram from Adjudicate Claims with AI Use Case section.
Module Configuration
The following module configuration is defined:
| Code Block | ||
|---|---|---|
| ||
{
authentication: [string] // Authentication key list. Default: []
zip: boolean // Whether the communication payload is compressed or not. Default: False
ai_model_file: string // AI Model file name with full path. Default: ./ai_model.pkl
} |
| Note |
|---|
The default AI Model filename will be defined after finalizing the AI Algorithm development. |
Claim data preparation
As explained in openIMIS-AI - 3. Normalised input data sets page, not all Claim data/fields is used for the AI Model generation. The remaining Moreover, this Claim data needs to go through a preparation process that includes conversion to AI input model, sanity check, categorical to numerical conversion and normalization. This process is the same used in data preparation for AI Algorithm execution and will be copied.
The AI input model is represented by a matrix having on each row one Medical Item/Service from a Claim. If the FHIR Claim Bundle contains multiple Claims then the AI input model will contain all Items/Services from all Claims. Each row contains the following informations (either FHIR Medical OR ActivityDefinition, representing an Item in FHIR Claim):
identifier (ItemUUID) | identifier (ServiceUUID) | identifier (ClaimUUID) | identifier (InsureeUUID, CHFID) | identifier (HfUUID) |
extension.unitPrice | unitPrice | billablePeriod (start, end) | birthDate (to calculate age) | location (HFLocationUUID) |
frequency | frequency | created | gender | category |
extension.useContext (ItemPatCat) | useContext (ItemPatCat) | type | extension.isHead | type |
item.quantity | link.type | |||
item.unitPrice | extension.povertyStatus | |||
diagnosis.diagnosisReference (for icd_0 and icd_1 get ICDID) | extension.locationCode (LocationUUID) | |||
enterer (ClaimAdminUUID) | extension.group (FamilyUUID) |
FHIR Contained Resources are used to include in the FHIR Claim resource all necessary information required in the above table.
AI Model execution
The research activities from this project has the objective to identify the appropriate AI/ML algorithm, develop the algorithm based on the data received from Nepal openIMIS implementation and to train and generate the AI Model that will be used in production to categorize new Claims (see also Deployment architecture). The AI Model contains the hyperparameters which are “calculated” based on the input dataset. It will be saved as a file on the server running the Claim-AI implementation.
| Note |
|---|
In this project, the generated AI Model is only valid for Nepal openIMIS implementation. Any usage in other context/implementation will give wrong categorization responses. For other context/implementation, the retraining of the AI Model, based on already categorized Claims, is mandatory. |
The AI Model file name with full path (or relative path) is configured in the modules configuration key ai_model_file. Each time the model is executed, the model file is loaded, allowing to change the filename on execution in the configuration (hot-reload).
For the execution, the selected AI methods will be used.
Build FHIR ClaimResponse
The response of the API is a ClaimResponse with the adjudication results generated by the AI Model execution. To support the