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 s'adresse 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 frais administratifs, d'améliorer l'efficacité et de prendre de meilleures décisions en automatisant l'ingestion de 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 requêtes et des recommandations.

Architecture

Le diagramme suivant décrit une architecture et une approche permettant d'automatiser le workflow d'ingestion de données et d'optimiser le processus d'examen de la gestion de l'utilisation (UM). 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 :

  • Le 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 du 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 les modifications apportées au bucket pa_forms_bkt. 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 des champs dans la collection de base 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 des champs disponibles dans le résultat des modèles de machine learning (ML) 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 pour le 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 in_queue, in_progress ou completed.
  2. La liste est créée en récupérant 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 Gemini Vertex AI pour générer une requête semblable à la suivante :

    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 le prompt au modèle ur_model en demandant de générer une recommandation. Le modèle génère une réponse et la 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 évaluer le 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 du service AI Applications.
    • 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 du service Applications d'IA.

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

  • pa_form_collection : un datastore Firestore pour stocker les informations extraites sous forme de documents JSON dans la collection de base 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 base de données Firestore.

  • hitl_app : microservice (application Web) qui récupère et affiche les valeurs de données extraites du 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 une requête. 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 la requête générée au modèle ur_model pour obtenir la recommandation pour une demande.

  • 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 sur le LLM ajusté pour générer des requêtes en fonction des données extraites de pa_forms.
    • ur_model : adaptateur sur le LLM ajusté pour générer une recommandation provisoire en fonction de la requête d'entrée.

  • ur_search_app : application de recherche créée avec AI Applications 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.
  • Applications d'IA : plate-forme permettant aux développeurs de créer et de déployer des agents et des applications optimisés par l'IA et adaptés aux entreprises.
  • 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 : store 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. Elle est coûteuse, prend du temps et est trop administrative. Il est également complexe, manuel et lent. Ce processus a un impact considérable sur la capacité du régime de santé à gérer efficacement la qualité des soins et à améliorer l'expérience des fournisseurs 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 professionnels 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. Un grand nombre 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 demandes est inefficace, chronophage et peut entraîner des erreurs.

En automatisant le processus d'ingestion de données, les organismes de santé peuvent réduire les coûts, les erreurs de saisie de 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 dansGoogle 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 la conformité avec la Security Rule (Règle de sécurité), la Privacy Rule (Règle de confidentialité) et la Breach Notification Rule (Règle de notification en cas de violation) de la loi HIPAA. Google Cloud permet la conformité avec la loi HIPAA, mais il vous incombe en définitive d'évaluer votre propre conformité avec ladite 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 Clouden lien avec des données de santé protégées, 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 consulter les rapports d'audit tiers dans le Centre de ressources sur la conformité.

Nous recommandons aux clients de tenir compte des points suivants lorsqu'ils sélectionnent des cas d'utilisation de l'IA et de concevoir leurs systèmes en gardant ces points à l'esprit :

Les produits Google respectent les principes d'IA responsable.

Pour connaître les principes et recommandations de sécurité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : sécurité dans le framework Well-Architected.

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 perdues1. En cas de panne régionale, 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 des 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 pour garantir l'évolutivité et la fiabilité à l'échelle mondiale.

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 jobs Cloud Run continuent de s'exécuter et les données ne sont pas perdues. En cas de panne régionale, les jobs 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. La page Conseils de développement généraux pour Cloud Run décrit quelques bonnes pratiques d'utilisation de Cloud Run.

Vertex AI est une plate-forme de machine learning complète et conviviale 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.

Pour obtenir des principes et des recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : fiabilité dans le framework Well-Architected.

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. Nearline, Coldline et Archive sont plus économiques pour les données auxquelles vous accédez moins souvent.

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.

La tarification de Document AI est basée 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 des processeurs : analysez les modèles de charge de travail pour déterminer le nombre optimal de processeurs Document AI à déployer. Évitez de surprovisionner les 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.

Firestore est facturé en fonction de 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 minimiser le nombre d'entrées d'index et optimiser les modèles de requête pour l'efficacité.
  • Bande passante réseau : surveillez et optimisez l'utilisation du réseau pour éviter les frais supplémentaires. 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. Allouez 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 façon dynamique en fonction de la demande.

Les LLM Vertex AI 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 les requêtes et la génération de réponses pour l'efficacité.

Les frais du moteur de recherche Applications d'IA dépendent des fonctionnalités que vous utilisez. Pour vous aider à gérer vos coûts, vous pouvez choisir l'une des 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.
  • Module complémentaire LLM pour la recherche, qui offre des fonctionnalités de synthèse et de recherche multitours.

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

  • Surveillance et alertes : configurez Cloud Monitoring et des 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 consoleGoogle Cloud pour identifier les tendances et optimiser l'utilisation des ressources.
  • Envisagez les remises sur engagement d'utilisation : si vos charges de travail sont prévisibles, envisagez de vous engager à utiliser ces ressources pendant une période spécifiée pour 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.

Pour obtenir des principes et des recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des coûts dans le framework Well-Architected.

Déploiement

Le code d'implémentation de référence pour cette architecture est disponible sous licence Open Source. L'architecture que ce code implémente est un prototype et peut ne pas inclure toutes les fonctionnalités et le renforcement dont vous avez besoin pour un déploiement en production. Pour implémenter et étendre cette architecture de référence afin de mieux répondre à 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 :

Étapes suivantes

Contributeurs

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

Autres contributeurs :

  1. Pour en savoir plus sur les considérations spécifiques à la région, consultez Zones géographiques et régions.  ↩