Règlement des sinistres basé sur l'IA dans openIMIS

Digital Square D1 proposal: Claim categorization using Artificial Intelligence: a proof of concept

Teams:

• Swiss TPH (@Dragos Dobre @Simona Dobre @Siddharth Srivastava) 

• SolDevelo (@Kamil Madej (Deactivated) @Damian Borowiecki (Deactivated) )

Objectifs

L'objectif de ce projet est de développer un module de catégorisation automatique des remboursements pour openIMIS, basé sur des algorithmes, des normes et des méthodologies d'intelligence artificielle (IA) de pointe, qui réduira considérablement la main-d'œuvre, les ressources et le temps nécessaires à l'examen d'un sinistre. Ce processus est centré sur le processus de réponse aux sinistres. Voici quelques détails sur ce processus.

Processus actuel de règlement des sinistres dans openIMIS

Un sinistre est ce que le médecin ou le service de santé soumet à la compagnie d'assurance du patient afin d'être payé pour les services médicaux et/ou les articles (prescriptions médicales). Ainsi, un sinistre peut être composé d'un ou plusieurs services et articles médicaux. Après la visite dans l'établissement de santé, le sinistre sera soumis à l'assurance par l'administrateur de l'établissement de santé (appelé aussi administrateur des sinistres). Après la soumission, un processeur de sinistre - basé sur un moteur de règles qui prend en considération la configuration d'openIMIS (produit d'assurance, articles et services médicaux, assuré, police, etc.) - vérifiera si la demande est complète, précise et si le service/article est couvert par l'assurance du patient.  Si tous les services et articles contenus dans un sinistre sont rejetés par le moteur de règles, le HF recevra une réponse négative pour le sinistre en question. Tous les articles et services qui ont été validés statiquement par le moteur de règles peuvent être soumis à une évaluation manuelle par un expert médical, qui peut accepter, accepter partiellement ou rejeter les articles/services sélectionnés. Comme un sinistre est composé d'un ou plusieurs services et/ou éléments médicaux, le résultat du processus peut être le suivant :

• Article/service accepté après validation statique et évaluation manuelle ;

• Article/service rejeté après validation statique ou évaluation manuelle.

Si tous les articles et services liés à une réclamation spécifique sont acceptés, la réclamation respective peut être considérée comme acceptée, alors que si une partie des articles/services sont acceptés, la réclamation sera considérée comme partiellement acceptée. Si tous les éléments et services liés à un sinistre sont rejetés, l'HF recevra une réponse négative pour ce sinistre.

La mise en œuvre d'openIMIS au Népal reçoit jusqu'à 14 000 sinistres par jour, comme on peut l'observer sur la figure 1. Parmi tous ces sinistres, l'équipe composée de cinq médecins-conseils n'est en mesure d'examiner qu'environ 1 000 sinistres par jour.

Open

Comme les médecins-conseils ne peuvent pas vérifier physiquement tous les sinistres soumis, le module de demande de remboursement a été implémenté dans openIMIS afin de sélectionner les sinistres (acceptés ou partiellement acceptés par le moteur de règles) à examiner plus en détail par les médecins-conseils. Ce processus manuel de règlement des sinistres est illustré à la figure 2.

Open

Processus de règlement automatique des sinistres basé sur l'IA dans le futur openIMIS (vision)

Pour l'algorithme de catégorisation des sinistres de l'IA, la saisie est représentée par un service ou un article, qui a été validé statiquement par le moteur de règles. La sortie d'un tel modèle sera l'acceptation ou le rejet de l'article ou du service. Ce module d'IA permettra au médecin-conseil de se concentrer uniquement sur les sinistres qui doivent vraiment être examinés, comme les cas incohérents ou erronés. En outre, afin de détecter les cas faussement positifs ou faussement négatifs mal classés par l'algorithme, un module d'assurance qualité sélectionnera les sinistres classés par l'IA qui seront examinés par les médecins-conseils. Ce processus est illustré dans le Fig. 3.

Project realization

The following wiki pages present the project realization:

This page in other languages