Exemple détaillé. Ceci est un exemple détaillé et illustratif, pas un résultat client. Le groupe de cliniques et chaque chiffre sont des hypothèses. Il montre l'ia pour l'accord préalable : un logiciel qui lit le dossier patient, en extrait les faits demandés par l'assureur et assemble le dossier. Il ne décide pas de la nécessité médicale et n'envoie rien seul. Un coordinateur valide.
Imaginez un groupe de plusieurs cliniques où la préparation des dossiers d'accord préalable est lente. Pour l'illustration, supposez que les coordinateurs passent leur temps à copier des faits entre un dossier patient, un portail d'assureur et une liste de contrôle. Cet article déroule le design et ce qu'il faut mesurer. Il ne rapporte aucun résultat.
Le groupe est hypothétique, il n'y a donc aucun client à nommer. Un détail compte plus qu'un nom : le pipeline extrait et assemble, mais n'envoie jamais automatiquement. Un coordinateur valide chaque dossier, et chaque exécution conserve un journal d'audit de ce que le modèle a lu et de ce qu'il a produit.
#Où passe le temps dans un dossier d'accord préalable ?
Commencez par mesurer, pas par construire. Observez des coordinateurs préparer un échantillon de dossiers et chronométrez chaque étape. Rédiger est rapide. Chercher, lire et ressaisir est lent.
- Lire le dossier patient pour repérer le diagnostic, les médicaments essayés sans succès et les notes du médecin prescripteur.
- Faire correspondre ces faits aux exigences de l'assureur concerné, qui diffèrent selon le contrat.
- Tout ressaisir dans le dossier et le portail, puis revérifier, au fil des interruptions.
- Attendre. Un dossier à moitié monté reste en plan jusqu'à ce que le coordinateur y revienne.
L'objectif n'a donc jamais été « écrire plus vite ». C'était « arrêter de faire chercher à une personne des informations déjà présentes dans le dossier ».
#Comment l'ia pour l'accord préalable réduit-elle le travail de préparation ?
Comment l'ia réduit-elle le temps de préparation d'un accord préalable ?
Elle lit le dossier patient, extrait les faits cliniques exigés par l'assureur et rédige le dossier pour qu'un coordinateur relise au lieu de ressaisir. Un groupe de cliniques mesurerait le temps de préparation et les heures de coordination avant et après. Le coordinateur valide toujours chaque envoi avant qu'il n'atteigne l'assureur.
Le pipeline fonctionne en quatre étapes : extraire les informations pertinentes du dossier, les assembler dans le format de dossier de l'assureur, valider que les champs requis sont présents et cohérents entre eux, puis acheminer le dossier vers la file de validation d'un coordinateur. Rien ne sort de cette file sans qu'un humain clique sur valider.
Le design reprend le même schéma de traitement de documents que nos exemples détaillés sur les réclamations logistiques et l'intégration, adapté à un secteur de santé réglementé. Sa forme est décrite sur notre page d'implémentation ia : extraire, valider, router, file de validation humaine. La différence ici est le journal d'audit. Comme il s'agit de santé, on enregistre chaque champ que le modèle a lu et chaque champ qu'il a écrit, pour qu'un relecteur puisse remonter n'importe quelle ligne du dossier jusqu'à sa source dans le dossier patient.
#Que se passe-t-il quand l'IA se trompe sur un fait ?
C'est rattrapé, parce qu'une personne le lit. C'est tout l'intérêt de la file de validation. Attendez-vous à ce qu'une partie des dossiers rédigés demande à un coordinateur de corriger ou d'ajouter un champ, et suivez ce taux. Ce n'est pas un échec du pipeline. C'est le pipeline qui fait son travail : livrer vite un brouillon pour qu'un humain passe son temps à relire plutôt qu'à chercher.
We are
Stennir construit un pipeline de traitement documentaire qui rédige les dossiers de préautorisation pour qu'un coordinateur les valide, avec une piste d'audit complète.
We aren't
Stennir n'est pas un bot à soumission automatique qui déciderait de la nécessité médicale ou déposerait des dossiers auprès d'un assureur tout seul.
Il n'y a pas de citation client ici, parce qu'il n'y a pas de client. Le test du design est de savoir si les coordinateurs cessent de ressaisir le dossier patient pendant que le modèle ne décide rien.
#Que mesurerait un groupe de cliniques ?
Le temps de préparation par dossier et les heures de coordination, avant et après, dans les mêmes cliniques, avec les mêmes coordinateurs et le même mix d'assureurs, la référence étant prise avant que quoi que ce soit ne change. C'est ainsi qu'on distingue une vraie amélioration d'une démo. Aucun résultat n'est revendiqué ici.
Si vous dirigez les opérations d'un groupe de cliniques et que votre équipe ressaisit des dossiers dans des portails d'assureurs, c'est exactement le type de travail concerné. Nous commençons par mesurer, comme le fait cet exemple, avant de construire quoi que ce soit. Vous pouvez lire comment nous cadrons cela sur notre page de conseil en ia, et comment nous pensons dans le reste du journal. Si cela ressemble à votre semaine, dites-nous ce que vous construisez.
