Utiliser l'IA générative pour la gestion de l'utilisation

Last reviewed 2024-08-19 UTC

Ce document décrit une architecture de référence pour les compagnies d'assurance santé qui souhaitent automatiser le traitement des demandes d'autorisation préalable (AP) et améliorer leurs processus d'examen de l'utilisation à l'aide de Google Cloud. Il est destiné aux développeurs de logiciels et aux administrateurs de programmes de ces organisations. Cette architecture permet aux fournisseurs de régimes de santé de réduire les coûts administratifs, d'améliorer l'efficacité et de faciliter la prise de décision en automatisant l'ingestion des données et l'extraction d'insights à partir de formulaires cliniques. Il leur permet également d'utiliser des modèles d'IA pour générer des invites et des recommandations.

Architecture

Le schéma suivant décrit une architecture et une approche permettant d'automatiser le workflow d'ingestion des données et d'optimiser le processus d'examen de la gestion de l'utilisation. Cette approche utilise des services de données et d'IA dans Google Cloud.

Vue d'ensemble du processus d'ingestion des données et d'examen de la gestion de l'utilisation.

L'architecture précédente contient deux flux de données, qui sont compatibles avec les sous-systèmes suivants :

  • Claims Data Activator (CDA), qui extrait les données de sources non structurées, telles que des formulaires et des documents, et les ingère dans une base de données dans un format structuré et lisible par machine. CDA met en œuvre le flux de données pour ingérer les formulaires de demande d'autorisation préalable.
  • Service d'examen de l'utilisation (service UR), qui intègre les données des demandes d'autorisation préalable, les documents de règles et d'autres consignes de soins pour générer des recommandations. Le service UR met en œuvre le flux de données pour examiner les demandes d'autorisation préalable à l'aide de l'IA générative.

Les sections suivantes décrivent ces flux de données.

Flux de données CDA

Le schéma suivant illustre le flux de données permettant d'utiliser CDA pour ingérer des formulaires de demande d'autorisation préalable.

Flux de données des gestionnaires de cas des autorisations préalables.

Comme illustré dans le schéma précédent, le gestionnaire d'autorisation préalable interagit avec les composants du système pour ingérer, valider et traiter les demandes d'autorisation préalable. Les gestionnaires de demandes d'autorisation préalable sont des membres de l'équipe des opérations commerciales qui sont chargés de traiter les demandes d'autorisation préalable. Le flux d'événements est le suivant :

  1. Les gestionnaires des demandes d'autorisation préalable reçoivent les formulaires de demande d'AP (pa_forms) du professionnel de santé et les importent dans le bucket Cloud Storage pa_forms_bkt.
  2. Le service ingestion_service écoute le bucket pa_forms_bkt pour détecter les modifications. Le service ingestion_service récupère les formulaires pa_forms du bucket pa_forms_bkt. Le service identifie les processeurs Document AI préconfigurés, appelés form_processors. Ces processeurs sont définis pour traiter les formulaires pa_forms. Le service ingestion_service extrait les informations des formulaires à l'aide des processeurs form_processors. Les données extraites des formulaires sont au format JSON.
  3. Le service ingestion_service écrit les informations extraites avec des scores de confiance au niveau du champ dans la collection de bases de données Firestore, appelée pa_form_collection.
  4. L'application hitl_app récupère les informations (JSON) avec des scores de confiance à partir de la base de données pa_form_collection. L'application calcule le score de confiance au niveau du document à partir des scores de confiance au niveau du champ mis à disposition dans la sortie par les modèles de machine learning form_processors.
  5. L'application hitl_app affiche les informations extraites avec les scores de confiance au niveau du champ et du document pour les gestionnaires des demandes d'autorisation préalable afin qu'ils puissent examiner et corriger les informations si les valeurs extraites sont inexactes. Les gestionnaires des demandes d'autorisation préalable peuvent mettre à jour les valeurs incorrectes et enregistrer le document dans la base de données pa_form_collection.

Flux de données du service UR

Le schéma suivant illustre le flux de données du service UR.

Flux de données du spécialiste du service UR.

Comme le montre le schéma précédent, les spécialistes du service UR interagissent avec les composants du système pour examiner les demandes d'AP sur le plan clinique. Les spécialistes du service UR sont généralement des infirmiers ou des médecins ayant une expérience dans un domaine clinique spécifique et employés par des compagnies d'assurance santé. Le workflow de gestion des demandes d'AP et leur acheminement n'est pas couvert par le workflow décrit dans cette section.

Le flux d'événements est le suivant :

  1. L'application ur_app affiche aux spécialistes du service UR une liste des demandes d'autorisation préalable et leur état d'examen. L'état est défini sur in_queue, in_progress ou completed.
  2. La liste est créée en extrayant les données pa_form information de la base de données pa_form_collection. Le spécialiste du service UR ouvre une demande en cliquant sur un élément de la liste affichée dans l'application ur_app.

  3. L'application ur_app envoie les données pa_form information au modèle prompt_model. Il utilise l'API Vertex AI Gemini pour générer une invite semblable à celle-ci :

    Review a PA request for {medication|device|medical service} for our member, {Patient Name}, who is {age} old, {gender} with {medical condition}. The patient is on {current medication|treatment list}, has {symptoms}, and has been diagnosed with {diagnosis}.

  4. L'application ur_app affiche l'invite générée aux spécialistes du service UR pour examen et commentaires. Les spécialistes du service UR peuvent mettre à jour l'invite dans l'interface utilisateur et l'envoyer à l'application.

  5. L'application ur_app envoie l'invite au modèle ur_model avec une requête pour générer une recommandation. Le modèle génère une réponse et renvoie à l'application. L'application affiche le résultat recommandé aux spécialistes du service UR.

  6. Les spécialistes du service UR peuvent utiliser l'application ur_search_app pour rechercher des clinical documents, care guidelines et plan policy documents. Les clinical documents, care guidelines et plan policy documents sont pré-indexés et accessibles à l'application ur_search_app.

Composants

L'architecture contient les composants suivants :

  • Buckets Cloud Storage Les services d'application de gestion de l'utilisation nécessitent les buckets Cloud Storage suivants dans votre projet Google Cloud :

    • pa_forms_bkt : bucket pour ingérer les formulaires d'autorisation préalable qui doivent être approuvés.
    • training_forms : bucket contenant les formulaires des précédentes demandes d'autorisation préalable pour l'entraînement des processeurs de formulaires DocAI.
    • eval_forms : bucket contenant des formulaires d'AP pour évaluer la précision des processeurs de formulaires DocAI.
    • tuning_dataset : bucket contenant les données requises pour ajuster le grand modèle de langage (LLM).
    • eval_dataset : bucket contenant les données requises pour l'évaluation du LLM.
    • clinical_docs : bucket contenant les documents cliniques que les fournisseurs envoient en tant qu'e-mails joints aux formulaires d'autorisation préalable ou ultérieurement pour accompagner le dossier d'autorisation préalable. Ces documents sont indexés par l'application de recherche dans le service Vertex AI Agent Builder.
    • um_policies : bucket contenant des directives sur la nécessité médicale des soins, des documents sur les règles du plan de santé et des directives sur la couverture. Ces documents sont indexés par l'application de recherche dans le service Vertex AI Agent Builder.

  • form_processors : ces processeurs sont entraînés pour extraire des informations des formulaires pa_forms.

  • pa_form_collection : un datastore Firestore permettant de stocker les informations extraites en tant que documents JSON dans la collection de bases de données NoSQL.

  • ingestion_service : microservice qui lit les documents du bucket, les transmet aux points de terminaison DocAI pour l'analyse et stocke les données extraites dans la collection de bases de données Firestore.

  • hitl_app : microservice (application Web) qui récupère et affiche les valeurs de données extraites de pa_forms. Il affiche également le score de confiance indiqué par les processeurs de formulaires (modèles de ML) au gestionnaire des demandes d'autorisation préalable afin qu'il puisse examiner, corriger et enregistrer les informations dans le datastore.

  • ur_app : microservice (application Web) que les spécialistes du service UR peuvent utiliser pour examiner les demandes d'autorisation préalable à l'aide de l'IA générative. Il utilise le modèle nommé prompt_model pour générer un message. Le microservice transmet les données extraites des formulaires pa_forms au modèle prompt_model pour générer une invite. Il transmet ensuite l'invite générée au modèle ur_model pour obtenir la recommandation pour un cas.

  • LLM Vertex AI médicalement ajustés : Vertex AI propose différents modèles de fondation d'IA générative qui peuvent être ajustés pour réduire les coûts et la latence. Les modèles utilisés dans cette architecture sont les suivants :

    • prompt_model : adaptateur du LLM configuré pour générer des invites en fonction des données extraites de pa_forms.
    • ur_model : adaptateur sur le LLM configuré pour générer un brouillon de recommandation en fonction de l'invite d'entrée.

  • ur_search_app : application de recherche créée avec Vertex AI Agent Builder pour trouver des informations personnalisées et pertinentes pour les spécialistes du service UR à partir de documents cliniques, de règles UM et de directives de couverture.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • Vertex AI : plate-forme de ML qui vous permet d'entraîner et de déployer des modèles de ML et des applications d'IA, et de personnaliser les LLM à utiliser dans des applications basées sur l'IA.
  • Vertex AI Agent Builder : plate-forme qui permet aux développeurs de créer et de déployer des agents et des applications d'IA de niveau entreprise.
  • Document AI : plate-forme de traitement de documents qui convertit les données non structurées des documents en données structurées.
  • Firestore : conçu pour le scaling automatique et les hautes performances, il s'agit d'une base de données de documents NoSQL qui simplifie le développement d'applications.
  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Cloud Storage : magasin d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.
  • Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
  • Cloud Monitoring : service qui offre une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure.

Cas d'utilisation

La gestion de l'utilisation est un processus utilisé par les compagnies d'assurance santé principalement aux États-Unis, mais des processus similaires (avec quelques modifications) sont utilisés dans le monde entier sur le marché de l'assurance maladie. L'objectif de la gestion de l'utilisation est de s'assurer que les patients reçoivent les soins appropriés dans le bon environnement, au moment idéal et au moindre coût. La gestion de l'utilisation permet également de s'assurer que les soins médicaux sont efficaces et conformes aux normes de soins basées sur des données probantes. L'autorisation préalable est un outil de gestion des soins qui nécessite l'approbation de la compagnie d'assurance avant qu'un patient ne reçoive des soins médicaux.

Le processus de gestion de l'utilisation utilisé par de nombreuses entreprises constitue un obstacle à la fourniture et à la réception de soins rapides. C'est coûteux, chronophage et trop administratif. Cette méthode est également complexe, manuelle et lente. Ce processus a un impact important sur la capacité du régime de santé à gérer efficacement la qualité des soins et à améliorer l'expérience des prestataires et des membres. Toutefois, si ces entreprises modifiaient leur processus de gestion de l'utilisation, elles pourraient contribuer à garantir aux patients un traitement de haute qualité et rentable. En optimisant leur processus d'examen de l'utilisation, les régimes de santé peuvent réduire les coûts et les refus grâce au traitement accéléré des demandes d'autorisation préalable, ce qui peut améliorer l'expérience des patients et des prestataires. Cette approche permet de réduire la charge administrative des prestataires de santé.

Lorsque les régimes de santé reçoivent des demandes d'autorisation préalable, les gestionnaires de dossiers d'autorisation préalable créent des dossiers dans le système de gestion des dossiers afin de suivre, gérer et traiter les demandes. Une part importante de ces demandes sont reçues par fax et par courrier, avec des documents cliniques en pièce jointe. Toutefois, les informations contenues dans ces formulaires et documents ne sont pas facilement accessibles aux compagnies d'assurance santé pour l'analyse des données et l'informatique décisionnelle. Le processus actuel de saisie manuelle des informations de ces documents dans les systèmes de gestion des dossiers est inefficace, chronophage et peut entraîner des erreurs.

En automatisant le processus d'ingestion des données, les mutuelles peuvent réduire les coûts, les erreurs de saisie des données et la charge administrative du personnel. L'extraction d'informations utiles à partir des formulaires et documents cliniques permet aux compagnies d'assurance santé d'accélérer le processus d'examen de l'utilisation.

Considérations de conception

Cette section fournit des conseils pour vous aider à utiliser cette architecture de référence afin de développer une ou plusieurs architectures répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, d'efficacité opérationnelle, de coût et de performances.

Sécurité, confidentialité et conformité

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer une architecture dans Google Cloud qui vous aide à répondre à vos exigences de sécurité, de confidentialité et de conformité.

Aux États-Unis, la loi HIPAA (Health Insurance Portability and Accountability Act, telle qu'elle a été amendée, y compris par la loi HITECH, Health Information Technology for Economic and Clinical Health Act) exige le respect de la règle de sécurité, de la règle de confidentialité et de la règle de notification en cas de faille de sécurité de la loi HIPAA. Google Cloud est conforme à la loi HIPAA, mais il vous appartient d'évaluer votre propre conformité avec cette loi. La conformité avec la loi HIPAA est une responsabilité partagée entre vous et Google. Si votre organisation est soumise à la loi HIPAA et que vous souhaitez utiliser des produits Google Cloud en lien avec des données de santé protégées (PHI), vous devez lire et accepter l'accord de partenariat avec Google. Google garantit que les produits couverts par cet accord répondent aux exigences de la loi HIPAA et sont conformes à nos certifications ISO/IEC 27001, 27017 et 27018, ainsi qu'au rapport SOC 2.

Tous les LLM hébergés dans Vertex AI Model Garden ne sont pas compatibles avec la loi HIPAA. Évaluez et utilisez les LLM compatibles avec la loi HIPAA.

Pour évaluer dans quelle mesure les produits Google peuvent répondre à vos besoins en matière de conformité avec la loi HIPAA, vous pouvez vous référer aux rapports d'audit tiers disponibles dans le Centre de ressources sur la conformité.

Nous recommandons aux clients de prendre en compte les points suivants lorsqu'ils sélectionnent des cas d'utilisation de l'IA et de les prendre en compte dans leur conception :

Les produits Google respectent les principes de l'IA responsable.

Fiabilité

Cette section décrit les facteurs de conception à prendre en compte pour créer et exploiter une infrastructure fiable permettant d'automatiser le traitement des requêtes d'autorisation préalable.

Document AI form_processors est un service régional. Les données sont stockées de manière synchrone dans plusieurs zones d'une même région. Le trafic est automatiquement équilibré entre les zones. En cas de panne zonale, les données ne sont pas perdues. En cas de panne dans une région, le service est indisponible jusqu'à ce que Google résolve le problème.

Vous pouvez créer des buckets Cloud Storage dans l'un des trois emplacements suivants : régional, birégional ou multirégional, à l'aide de buckets pa_forms_bkt, training_forms, eval_forms, tuning_dataset, eval_dataset, clinical_docs ou um_policies. Les données stockées dans des buckets régionaux sont répliquées de manière synchrone dans plusieurs zones d'une même région. Pour une disponibilité plus élevée, vous pouvez utiliser des buckets birégionaux ou multirégionaux, dans lesquels les données sont répliquées de manière asynchrone entre les régions.

Dans Firestore, les informations extraites de la base de données pa_form_collection peuvent être réparties sur plusieurs centres de données afin de garantir une évolutivité et une fiabilité globales.

Les services Cloud Run, ingestion_service, hitl_app et ur_app, sont des services régionaux. Les données sont stockées de manière synchrone dans plusieurs zones d'une même région. Le trafic est automatiquement équilibré entre les zones. En cas de panne zonale, les tâches Cloud Run continuent de s'exécuter et les données ne sont pas perdues. En cas de panne dans une région, les tâches Cloud Run cessent de s'exécuter jusqu'à ce que Google résolve la panne. Des jobs ou des tâches Cloud Run individuelles peuvent échouer. Pour gérer ces échecs, vous pouvez utiliser les nouvelles tentatives d'exécution de tâches et la création de points de contrôle. Pour en savoir plus, consultez la section Bonnes pratiques en matière de nouvelles tentatives d'exécution et de points de contrôle de tâches. Le guide de fiabilité Cloud Run décrit certaines bonnes pratiques pour utiliser Cloud Run.

Vertex AI est une plate-forme de machine learning complète et facile à utiliser qui fournit un environnement unifié pour le cycle de vie du machine learning, de la préparation des données au déploiement et à la surveillance des modèles.

Optimisation des coûts

Cette section fournit des conseils pour optimiser le coût de création et d'exécution d'une architecture permettant d'automatiser le traitement des demandes d'autorisation préalable et d'améliorer vos processus d'examen de l'utilisation. Une gestion minutieuse de l'utilisation des ressources et la sélection de niveaux de service appropriés peuvent avoir un impact considérable sur le coût global.

Classes de stockage Cloud Storage : utilisez les différentes classes de stockage (Standard, Nearline, Coldline ou Archive) en fonction de la fréquence d'accès aux données. Les stockages Nearline, Coldline et Archive sont plus économiques pour les données auxquelles vous accédez moins fréquemment.

Règles de cycle de vie Cloud Storage : implémentez des règles de cycle de vie pour transférer automatiquement les objets vers des classes de stockage moins coûteuses ou les supprimer en fonction de leur âge et de leurs modèles d'accès.

Le prix de Document AI est basé sur le nombre de processeurs déployés et sur le nombre de pages traitées par les processeurs Document AI. Réfléchissez aux éléments suivants :

  • Optimisation du processeur : analyse les modèles de charge de travail pour déterminer le nombre optimal de processeurs Document AI à déployer. Évitez de provisionner trop de ressources.
  • Gestion du volume de pages : le prétraitement des documents pour supprimer les pages inutiles ou optimiser la résolution peut contribuer à réduire les coûts de traitement.

Le prix de Firestore est basé sur l'activité liée aux documents, aux entrées d'index, à l'espace de stockage utilisé par la base de données et à la quantité de bande passante réseau. Réfléchissez aux éléments suivants :

  • Modélisation des données : concevez votre modèle de données pour réduire le nombre d'entrées d'index et optimiser les modèles de requête pour plus d'efficacité.
  • Bande passante réseau : surveillez et optimisez l'utilisation du réseau pour éviter les frais excessifs. Envisagez de mettre en cache les données fréquemment consultées.

Les frais Cloud Run sont calculés en fonction de l'utilisation du processeur à la demande, de la mémoire et du nombre de requêtes. Réfléchissez bien à l'allocation des ressources. Allouer des ressources de processeur et de mémoire en fonction des caractéristiques de la charge de travail Utilisez l'autoscaling pour ajuster les ressources de manière dynamique en fonction de la demande.

Vertex AI Les LLM sont généralement facturés en fonction de l'entrée et de la sortie du texte ou du contenu multimédia. Le nombre de jetons d'entrée et de sortie affecte directement les coûts du LLM. Optimisez la génération d'invites et de réponses pour plus d'efficacité.

Les frais du moteur de recherche Vertex AI Agent Builder dépendent des fonctionnalités que vous utilisez. Pour vous aider à gérer vos coûts, vous pouvez choisir parmi les trois options suivantes :

  • Search Standard Edition, qui offre des fonctionnalités de recherche non structurée.
  • Search Enterprise Edition, qui offre des fonctionnalités de recherche non structurée et de recherche sur site Web.
  • Le module complémentaire LLM de recherche, qui offre des fonctionnalités de synthèse et de recherche multitours.

Vous pouvez également prendre en compte les considérations supplémentaires suivantes pour optimiser les coûts :

  • Surveillance et alertes : configurez Cloud Monitoring et les alertes de facturation pour suivre les coûts et recevoir des notifications lorsque l'utilisation dépasse les seuils.
  • Rapports sur les coûts : examinez régulièrement les rapports sur les coûts dans la console Google Cloud pour identifier les tendances et optimiser l'utilisation des ressources.
  • Envisagez des remises sur engagement d'utilisation : si votre charge de travail est prévisible, envisagez de vous engager à utiliser ces ressources pendant une période spécifiée afin de bénéficier de tarifs réduits.

En tenant compte de ces facteurs et en appliquant les stratégies recommandées, vous pouvez gérer et optimiser efficacement le coût d'exécution de votre architecture d'automatisation des autorisations préalables et de l'examen d'utilisation sur Google Cloud.

Déploiement

Le code d'implémentation de référence de cette architecture est disponible sous licence Open Source. L'architecture implémentée par ce code est un prototype. Elle peut ne pas inclure toutes les fonctionnalités et tous les renforcements dont vous avez besoin pour un déploiement en production. Pour implémenter et développer cette architecture de référence afin de répondre plus précisément à vos besoins, nous vous recommandons de contacter Google Cloud Consulting.

Le code de démarrage de cette architecture de référence est disponible dans les dépôts Git suivants :

Vous pouvez choisir l'une des deux options suivantes pour implémenter l'assistance et les services pour cette architecture de référence :

Étape suivante

Contributeurs

Auteur : Dharmesh Patel | Industry Solutions Architect, Secteur Santé

Autres contributeurs :