Le tiers payant expliqué à une équipe technique

Sur OptiBot, l’application d’auto-saisie du tiers payant pour les opticiens, la première difficulté n’a pas été technique. Elle a été de faire partager à l’équipe de développement un modèle mental correct du métier.

Sans ce modèle, on écrit du code raisonnable qui traite mal les cas réels — parce qu’on suppose un déroulement simple là où le métier en a un complexe. Voici ce qu’il faut avoir en tête, dans l’ordre où ça devient utile.

Deux payeurs, pas un

Un client paie ses lunettes. Chez un opticien pratiquant le tiers payant, il ne paie pas tout : une partie est prise en charge par l’assurance maladie obligatoire — l’AMO — une autre par sa complémentaire santé — l’AMC — et le reste, s’il y en a, par lui.

Ces deux sigles ne sont pas du jargon décoratif : ce sont les termes qu’emploient les documents, les flux et les messages de retour. Une équipe qui les nomme autrement dans son code passera son temps à traduire, et se trompera un jour de sens.

Trois flux, trois interlocuteurs, trois calendriers. C’est la première chose à modéliser.

Un développeur qui pense « facture → paiement » se trompe de forme. La bonne forme est : un dossier, plusieurs demandes de remboursement, chacune avec son destinataire, son statut et son échéance propre. Une demande peut être acceptée pendant qu’une autre du même dossier est rejetée. Le dossier n’a donc pas un statut unique — il a un état agrégé, dérivé de l’état de ses demandes.

C’est une nuance de modélisation, et elle décide de beaucoup de choses en aval.

Les droits ne sont pas connus au moment de la vente

Deuxième point contre-intuitif : au moment où l’opticien saisit le dossier, il ne connaît pas exactement ce qui sera pris en charge.

Il connaît les droits déclarés — ce que le client annonce, ce que porte sa carte, ce que dit son attestation de complémentaire. Les droits réels dépendent de la situation du client au moment du soin : contrat résilié, changement d’employeur, période de carence, plafond annuel déjà consommé.

L’écart entre les deux est la source principale des rejets. Une application qui traite les droits déclarés comme certains produira des dossiers qui semblent parfaits et qui reviendront.

La conséquence : il faut représenter explicitement l’incertitude. Un montant attendu n’est pas un montant dû. Un dossier « complet » n’est pas un dossier « payé ». Confondre les deux, c’est afficher au commerçant une trésorerie qui n’existe pas.

Photo : domaine public (CC0).

Le rejet est le cas normal, pas l’exception

C’est le point qui change le plus la conception, et celui que nous répétons le plus.

Un rejet n’est pas un incident rare. C’est un événement courant, attendu, qui fait partie du fonctionnement. Il arrive plusieurs semaines après l’envoi, ce qui a trois conséquences lourdes :

Il faut pouvoir rattacher un retour tardif au bon dossier. Les retours de l’assurance maladie arrivent par un flux dédié — les retours NOEMIE — et contiennent les identifiants du régime, pas nécessairement les vôtres. Le rapprochement doit être conçu, pas improvisé, et il doit pouvoir échouer proprement : une file de retours non rattachés que quelqu’un traite à la main vaut infiniment mieux qu’un rattachement approximatif fait au plus proche.

Il faut pouvoir corriger sans réécrire l’histoire. Un dossier rejeté est corrigé et renvoyé. L’état antérieur ne doit pas disparaître : en cas de litige, il faut savoir ce qui a été envoyé, quand, et ce qui a été répondu. Un modèle qui met à jour le dossier en place perd cette information, et on ne s’en aperçoit que le jour où on en a besoin.

Il faut classer les motifs. Tous les rejets ne se traitent pas pareil. Certains sont des erreurs de saisie — corrigeables immédiatement. D’autres relèvent des droits du client — il faut le contacter. D’autres encore viennent d’un délai dépassé — le dossier est perdu, et c’est une perte sèche pour l’opticien. Un écran qui affiche « rejeté » sans dire lequel de ces trois cas ne rend aucun service.

Photo : domaine public (CC0).

Ce que l’automatisation peut et ne peut pas

OptiBot lit les documents et pré-remplit les dossiers. Deux limites à poser d’emblée.

L’extraction ne crée pas d’information absente. Si une attestation est illisible ou périmée, aucune lecture automatique ne rétablira le droit. L’outil doit donc savoir dire « je ne sais pas » — et c’est plus utile qu’une valeur inventée avec une confiance moyenne. Une donnée fausse non signalée coûte un rejet ; une donnée manquante signalée coûte trente secondes de saisie.

L’automatisation ne réduit pas le taux de rejet lié aux droits. Elle réduit le taux de rejet lié à la saisie. C’est une distinction importante à tenir en avant-vente, parce que la promesse « zéro rejet » est intenable : une partie des rejets ne dépend pas de la qualité de la saisie.

Nous préférons annoncer précisément sur quoi porte le gain plutôt que de laisser entendre qu’il porte sur tout. C’est moins vendeur en réunion, et ça évite un désaccord au premier bilan.

Photo : domaine public (CC0).

Le vocabulaire minimal

Pour finir, les cinq termes qu’il faut savoir distinguer avant d’écrire une ligne de code, parce qu’ils sont couramment confondus par les équipes qui découvrent le domaine :

• Part obligatoire : ce que prend en charge l’assurance maladie.
• Part complémentaire : ce que prend en charge la mutuelle.
• Reste à charge : ce qui reste au client, après les deux.
• Droits : ce à quoi le client peut prétendre, à une date donnée — pas ce qu’il déclare.
• Rejet : refus de prise en charge, avec un motif, qui peut ou non être corrigé.

Deux termes de plus, qui désignent les tuyaux plutôt que les concepts, et qu’on rencontre dès qu’on ouvre le sujet : la télétransmission, l’envoi des demandes aux organismes, et SESAM-Vitale, le cadre dans lequel elle s’effectue.

Une application qui nomme correctement ces cinq concepts dans son modèle et ses écrans est déjà à moitié juste. Une application qui les mélange sous un « montant » et un « statut » produira des écrans que les opticiens ne sauront pas lire — et ils reviendront à leur logiciel de caisse.