...
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 is 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 REST WebSocked API). Before calling the Claim-AI REST 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 (https://www.hl7.org/fhir/references.html#contained) allows to integrate the referred resourced. In our case for 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 in from the POST call Claim sent by claim-ai-quality Claim-AI Quality module.
The mechanism to build Claim resource with Contained Resources is to be developed in the openIMIS FHIR R4 module.
...
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:
REST API Process endpoint
...
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.
| Code Block |
|---|
Call: POST /claim_ai/Claim Body: FHIR R4 Claim Bundle with Contained Resources Response: FHIR R4 ClaimResponse Bundle |