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 mutuelles de santé de réduire les frais administratifs, d'améliorer l'efficacité et de renforcer la prise de 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 des données et d'optimiser le processus d'examen de la gestion de l'utilisation. Cette approche utilise les données et les services 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 pris en charge par les sous-systèmes suivants:

  • Claims data activator (CDA), qui extrait des données à partir 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 à partir 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 des 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 la base de données Firestore, appelée pa_form_collection.
  4. L'application hitl_app extrait 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 (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 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 requête 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 de génération d'une recommandation. Le modèle génère une réponse et revient à 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. 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 régler 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 du 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 du service Vertex AI Agent Builder.

  • 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 en tant que documents JSON dans la collection de bases de données NoSQL.

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

  • hitl_app: microservice (application Web) qui extrait 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 du LLM configuré pour générer des requêtes en fonction des données extraites de pa_forms.
    • ur_model: adaptateur du LLM configuré pour générer une recommandation préliminaire en fonction de la requête 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 professionnel.
  • 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. Il est coûteux, long et trop administratif. Il est également complexe, manuel et lent. Ce processus a un impact significatif sur la capacité du plan 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 pour les 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 postal, avec des documents cliniques joints. 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 et long, et peut entraîner des erreurs.

En automatisant le processus d'ingestion des données, les régimes de santé peuvent réduire les coûts, les erreurs de saisie de données et la charge administrative imposée au 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). Google Cloud permet de se conformer à la loi HIPAA, mais il vous incombe d'évaluer votre propre conformité avec la loi HIPAA. 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 Google Cloud produits 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 Model Garden Vertex AI 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 prendre en compte les points suivants lorsqu'ils sélectionnent des cas d'utilisation de l'IA et de les garder à l'esprit lors de la conception:

Les produits de 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 la section Perspective IA et ML: sécurité du framework d'architecture.

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 la résolve.

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 se trouver dans plusieurs centres de données pour garantir une évolutivité et une fiabilité mondiales.

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 régionale, les tâches Cloud Run ne s'exécutent plus 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. 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 connaître les principes et recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: fiabilité du framework d'architecture.

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. La gestion minutieuse de l'utilisation des ressources et la sélection des niveaux de service appropriés peuvent avoir un impact significatif 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 consultées moins fréquemment.

Règles de cycle de vie Cloud Storage: implémentez des règles de cycle de vie pour transférer automatiquement des 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.

Document AI est facturé en fonction du nombre de processeurs déployés et du nombre de pages traitées par les processeurs Document AI. Réfléchissez aux éléments suivants :

  • Optimisation des processeurs: analysez les tendances 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.

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 réduire le nombre d'entrées d'index et optimiser les modèles de requêtes afin d'améliorer l'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, de la mémoire et du nombre de requêtes à la demande. 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 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 des médias. Le nombre de jetons d'entrée et de sortie affecte directement les coûts du LLM. Optimisez les invites et la génération 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 avez le choix entre trois options:

  • Search Standard Edition, qui offre des fonctionnalités de recherche non structurée.
  • Search Enterprise Edition, qui propose 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 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 console Google Cloud pour identifier les tendances et optimiser l'utilisation des ressources.
  • Envisagez des 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 connaître les principes et les recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: optimisation des coûts du framework d'architecture.

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 et n'inclut peut-être pas toutes les fonctionnalités et le durcissement dont vous avez besoin pour un déploiement en production. Pour implémenter et développer cette architecture de référence afin de mieux répondre à vos exigences, 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 de cette architecture de référence:

Étape suivante

Contributeurs

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

Autres contributeurs :

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