Utilizza l'IA generativa per la gestione dell'utilizzo

Last reviewed 2024-08-19 UTC

Questo documento descrive un'architettura di riferimento per le compagnie di assicurazione sanitaria che vogliono automatizzare l'elaborazione delle richieste di preautorizzazione (PA) e migliorare le procedure di revisione dell'utilizzo (UR) utilizzando Google Cloud. È destinato a sviluppatori di software e amministratori di programmi di queste organizzazioni. Questa architettura consente ai fornitori di piani sanitari di ridurre i costi amministrativi, aumentare l'efficienza e migliorare il processo decisionale automatizzando l&#3importazione datiti e l'estrazione di insight dai moduli clinici. Consente inoltre di utilizzare modelli di AI per la generazione di prompt e suggerimenti.

Architettura

Il seguente diagramma descrive un'architettura e un approccio per automatizzare il flusso di lavoro di importazione dati e ottimizzare il processo di revisione della gestione dell'utilizzo (UM). Questo approccio utilizza i servizi di dati e AI in Google Cloud.

Panoramica generale del processo di importazione dei dati e revisione dell'utilizzo.

L'architettura precedente contiene due flussi di dati, supportati dai seguenti sottosistemi:

  • Claims Data Activator (CDA), che estrae i dati da fonti non strutturate, come moduli e documenti, e li inserisce in un database in un formato strutturato e leggibile automaticamente. CDA implementa il flusso di dati per importare i moduli di richiesta PA.
  • Servizio di revisione dell'utilizzo (servizio UR), che integra i dati delle richieste di preautorizzazione, i documenti delle norme e altre linee guida per la cura per generare consigli. Il servizio UR implementa il flusso di dati per esaminare le richieste di PA utilizzando l'AI generativa.

Le sezioni seguenti descrivono questi flussi di dati.

Flusso di dati del CDA

Il seguente diagramma mostra il flusso di dati per l'utilizzo di CDA per l'importazione dei moduli di richiesta di PA.

Flusso di dati dei case manager PA.

Come mostrato nel diagramma precedente, il responsabile dei casi PA interagisce con i componenti del sistema per importare, convalidare ed elaborare le richieste PA. I responsabili dei casi di PA sono i membri del team di operazioni aziendali responsabili dell'acquisizione delle richieste di PA. Il flusso di eventi è il seguente:

  1. I responsabili delle pratiche di preautorizzazione ricevono i moduli di richiesta di preautorizzazione (pa_forms) dal fornitore di servizi sanitari e li caricano nel bucket Cloud Storage pa_forms_bkt.
  2. Il servizio ingestion_service è in ascolto del bucket pa_forms_bkt per rilevare le modifiche. Il servizio ingestion_service recupera i moduli pa_forms dal bucket pa_forms_bkt. Il servizio identifica i processori Document AI preconfigurati, chiamati form_processors. Questi responsabili del trattamento sono definiti per elaborare i moduli pa_forms. Il servizio ingestion_service estrae le informazioni dai moduli utilizzando i processori form_processors. I dati estratti dai moduli sono in formato JSON.
  3. Il servizio ingestion_service scrive le informazioni estratte con i punteggi di affidabilità a livello di campo nella raccolta del database Firestore, denominata pa_form_collection.
  4. L'applicazione hitl_app recupera le informazioni (JSON) con punteggi di confidenza dal database pa_form_collection. L'applicazione calcola il punteggio di confidenza a livello di documento dai punteggi di confidenza a livello di campo resi disponibili nell'output dai modelli di machine learning (ML) form_processors.
  5. L'applicazione hitl_app mostra le informazioni estratte con i punteggi di confidenza a livello di campo e documento ai responsabili dei casi di PA, in modo che possano rivedere e correggere le informazioni se i valori estratti sono imprecisi. I case manager del PA possono aggiornare i valori errati e salvare il documento nel database pa_form_collection.

Flusso di dati del servizio UR

Il seguente diagramma mostra il flusso di dati per il servizio UR.

Flusso di dati dello specialista UR.

Come mostrato nel diagramma precedente, gli specialisti UR interagiscono con i componenti del sistema per condurre una revisione clinica delle richieste di preautorizzazione. Gli specialisti UR sono in genere infermieri o medici con esperienza in un'area clinica specifica che lavorano per compagnie di assicurazione sanitaria. Il workflow di gestione e routing delle richieste di autorizzazione preventiva non rientra nell'ambito del workflow descritto in questa sezione.

Il flusso di eventi è il seguente:

  1. L'applicazione ur_app mostra un elenco di richieste di preautorizzazione e il relativo stato di revisione agli esperti di revisione dell'utilizzo. Lo stato viene visualizzato come in_queue, in_progress o completed.
  2. L'elenco viene creato recuperando i dati pa_form information dal database pa_form_collection. L'esperto UR apre una richiesta facendo clic su un elemento dell'elenco visualizzato nell'applicazione ur_app.

  3. L'applicazione ur_app invia i dati pa_form information al modello prompt_model. Utilizza l'API Vertex AI Gemini per generare un prompt simile al seguente:

    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'applicazione ur_app mostra il prompt generato agli specialisti di UR per la revisione e il feedback. Gli esperti di UR possono aggiornare il prompt nell'interfaccia utente e inviarlo all'applicazione.

  5. L'applicazione ur_app invia il prompt al modello ur_model con una richiesta di generare un suggerimento. Il modello genera una risposta e torna all'applicazione. L'applicazione mostra il risultato consigliato agli specialisti di UR.

  6. Gli specialisti di UR possono utilizzare l'applicazione ur_search_app per cercare clinical documents, care guidelines e plan policy documents. clinical documents, care guidelines e plan policy documents sono preindicizzati e accessibili all'applicazione ur_search_app.

Componenti

L'architettura contiene i seguenti componenti:

  • bucket Cloud Storage. I servizi applicativi UM richiedono i seguenti bucket Cloud Storage nel tuo progetto Google Cloud :

    • pa_forms_bkt: un bucket in cui inserire i moduli PA che richiedono l'approvazione.
    • training_forms: un bucket per contenere i moduli PA storici per l'addestramento dei processori di moduli DocAI.
    • eval_forms: un bucket per contenere i moduli PA per valutare l'accuratezza dei processori di moduli DocAI.
    • tuning_dataset: un bucket per contenere i dati necessari per l'ottimizzazione del modello linguistico di grandi dimensioni (LLM).
    • eval_dataset: un bucket per contenere i dati necessari per la valutazione dell'LLM.
    • clinical_docs: Un bucket per contenere i documenti clinici che i fornitori inviano come allegati ai moduli di preautorizzazione o successivamente per supportare la pratica di preautorizzazione. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio AI Applications.
    • um_policies: un bucket per contenere le linee guida sulla necessità medica e sull'assistenza, i documenti delle norme del piano sanitario e le linee guida sulla copertura. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio AI Applications.

  • form_processors: questi processori sono addestrati per estrarre informazioni dai moduli pa_forms.

  • pa_form_collection: un datastore Firestore per archiviare le informazioni estratte come documenti JSON nella raccolta di database NoSQL.

  • ingestion_service: un microservizio che legge i documenti dal bucket, li passa agli endpoint DocAI per l'analisi e memorizza i dati estratti nella raccolta del database Firestore.

  • hitl_app: un microservizio (applicazione web) che recupera e visualizza i valori dei dati estratti da pa_forms. Inoltre, esegue il rendering del punteggio di affidabilità segnalato dai programmi di elaborazione dei moduli (modelli ML) al responsabile dei casi di PA in modo che possa esaminare, correggere e salvare le informazioni nel datastore.

  • ur_app: un microservizio (applicazione web) che gli specialisti UR possono utilizzare per esaminare le richieste di autorizzazione preventiva utilizzando l'AI generativa. Utilizza il modello denominato prompt_model per generare un prompt. Il microservizio passa i dati estratti dai moduli pa_forms al modello prompt_model per generare un prompt. Quindi, passa il prompt generato al modello ur_model per ottenere il suggerimento per una richiesta.

  • LLM ottimizzati per il settore medico di Vertex AI: Vertex AI dispone di una serie di modelli di base di AI generativa che possono essere ottimizzati per ridurre costi e latenza. I modelli utilizzati in questa architettura sono i seguenti:

    • prompt_model: un adattatore sull'LLM ottimizzato per generare prompt in base ai dati estratti da pa_forms.
    • ur_model: un adattatore sull'LLM ottimizzato per generare una bozza di consiglio in base al prompt di input.

  • ur_search_app: un'applicazione di ricerca creata con AI Applications per trovare informazioni personalizzate e pertinenti per gli specialisti UR da documenti clinici, norme UM e linee guida sulla copertura.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

  • Vertex AI: una piattaforma ML che ti consente di addestrare ed eseguire il deployment di modelli ML e applicazioni AI e personalizzare LLM da utilizzare in applicazioni basate sull'AI.
  • Applicazioni AI: una piattaforma che consente agli sviluppatori di creare ed eseguire il deployment di agenti e applicazioni basati sull'AI di livello enterprise.
  • Document AI: una piattaforma di elaborazione dei documenti che prende dati non strutturati dai documenti e li trasforma in dati strutturati.
  • Firestore: un database di documenti NoSQL creato per offrire scalabilità automatica, prestazioni elevate e facilità di sviluppo delle applicazioni.
  • Cloud Run: una piattaforma di computing serverless che ti consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
  • Cloud Monitoring: un servizio che offre visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura.

Caso d'uso

L'UM è una procedura utilizzata dalle compagnie di assicurazione sanitaria principalmente negli Stati Uniti, ma procedure simili (con alcune modifiche) vengono utilizzate a livello globale nel mercato delle assicurazioni sanitarie. L'obiettivo della gestione dell'utilizzo è garantire che i pazienti ricevano le cure appropriate nel contesto corretto, al momento ottimale e al costo più basso possibile. L'UM contribuisce inoltre a garantire che le cure mediche siano efficaci, efficienti e in linea con gli standard di cura basati su evidenze. L'autorizzazione preventiva è uno strumento di gestione dell'utilizzo che richiede l'approvazione della compagnia assicurativa prima che un paziente riceva cure mediche.

La procedura di autorizzazione preventiva utilizzata da molte aziende è un ostacolo alla fornitura e alla ricezione di cure tempestive. È costoso, richiede molto tempo ed è eccessivamente amministrativo. Inoltre, è complessa, manuale e lenta. Questo processo influisce in modo significativo sulla capacità del piano sanitario di gestire efficacemente la qualità delle cure e migliorare l'esperienza di fornitori e membri. Tuttavia, se queste aziende modificassero la procedura di autorizzazione preventiva, potrebbero contribuire a garantire che i pazienti ricevano un trattamento di alta qualità ed economicamente vantaggioso. Ottimizzando la procedura di revisione dell'utilizzo, i piani sanitari possono ridurre i costi e i rifiuti tramite l'elaborazione rapida delle richieste di preautorizzazione, il che a sua volta può migliorare l'esperienza di pazienti e fornitori. Questo approccio contribuisce a ridurre il carico amministrativo sui fornitori di servizi sanitari.

Quando i piani sanitari ricevono richieste di preautorizzazione, i responsabili delle pratiche di preautorizzazione creano casi nel sistema di gestione delle pratiche per monitorare, gestire ed elaborare le richieste. Una quantità significativa di queste richieste viene ricevuta via fax e posta, con allegati documenti clinici. Tuttavia, le informazioni contenute in questi moduli e documenti non sono facilmente accessibili alle compagnie di assicurazione sanitaria per l'analisi dei dati e la business intelligence. L'attuale procedura di inserimento manuale delle informazioni di questi documenti nei sistemi di gestione delle richieste è inefficiente, richiede molto tempo e può portare a errori.

Automatizzando il processo di importazione dati, i piani sanitari possono ridurre i costi, gli errori di inserimento dei dati e il carico amministrativo del personale. L'estrazione di informazioni preziose dai moduli e dai documenti clinici consente alle compagnie di assicurazione sanitaria di accelerare la procedura di revisione dell'utilizzo.

Considerazioni sulla progettazione

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare una o più architetture che ti aiutino a soddisfare i tuoi requisiti specifici di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare un'architettura in Google Cloud che ti aiuti a soddisfare i requisiti di sicurezza, privacy e conformità.

Negli Stati Uniti, l'Health Insurance Portability and Accountability Act (noto come HIPAA, come modificato, incluso dall'Health Information Technology for Economic and Clinical Health Act, o HITECH) richiede la conformità alla Security Rule, alla Privacy Rule e alla Breach Notification Rule. Google Cloud supporta la conformità HIPAA, ma in definitiva sei responsabile della valutazione della tua conformità HIPAA. La conformità all'HIPAA è una responsabilità condivisa tra te e Google. Se la tua organizzazione è soggetta alla normativa HIPAA e vuoi utilizzare qualsiasi Google Cloud prodotto in connessione con dati sanitari protetti (PHI), devi esaminare e accettare il Contratto di società in affari (BAA) di Google. I prodotti Google coperti dal BAA rispettano i requisiti previsti dalla normativa HIPAA e sono conformi alle nostre certificazioni ISO/IEC 27001, 27017 e 27018 e al report SOC 2.

Non tutti i LLM ospitati in Vertex AI Model Garden supportano l'HIPAA. Valuta e utilizza gli LLM che supportano la normativa HIPAA.

Per valutare in che modo i prodotti Google possono soddisfare le tue esigenze di conformità HIPAA, puoi fare riferimento ai report dei controlli di terze parti nel Centro risorse per la conformità.

Consigliamo ai clienti di prendere in considerazione quanto segue quando selezionano i casi d'uso dell'AI e di progettare tenendo conto di questi aspetti:

I prodotti Google seguono i principi dell'AI responsabile.

Per principi e consigli di sicurezza specifici per i workload di AI e ML, consulta Prospettiva AI e ML: sicurezza nel framework Well-Architected.

Affidabilità

Questa sezione descrive i fattori di progettazione da considerare per creare e gestire un'infrastruttura affidabile per automatizzare l'elaborazione delle richieste di preautorizzazione.

Document AI form_processors è un servizio regionale. I dati vengono memorizzati in modo sincrono in più zone all'interno di una regione. Il traffico viene bilanciato automaticamente tra le zone. In caso di interruzione della zona, i dati non vengono persi1. Se si verifica un'interruzione a livello di regione, il servizio non è disponibile finché Google non risolve l'interruzione.

Puoi creare bucket Cloud Storage in una delle tre posizioni: regionale, dual-region o multi-region, utilizzando i bucket pa_forms_bkt, training_forms, eval_forms, tuning_dataset, eval_dataset, clinical_docs o um_policies. I dati archiviati nei bucket regionali vengono replicati in modo sincrono in più zone all'interno di una regione. Per una maggiore disponibilità, puoi utilizzare bucket multiregionali o in due regioni, in cui i dati vengono replicati in modo asincrono tra le regioni.

In Firestore, le informazioni estratte dal database pa_form_collection possono essere distribuite su più data center per garantire scalabilità e affidabilità globali.

I servizi Cloud Run ingestion_service,hitl_app e ur_app sono servizi regionali. I dati vengono archiviati in modo sincrono in più zone all'interno di una regione. Il traffico viene bilanciato automaticamente tra le zone. In caso di interruzione di una zona, i job Cloud Run continuano a essere eseguiti e i dati non vengono persi. Se si verifica un'interruzione della regione, i job Cloud Run smettono di essere eseguiti finché Google non risolve l'interruzione. Singoli job o attività Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i nuovi tentativi di esecuzione delle attività e il checkpointing. Per ulteriori informazioni, consulta le best practice per i tentativi ripetuti e i checkpoint dei job. Suggerimenti generali per lo sviluppo di Cloud Run descrive alcune best practice per l'utilizzo di Cloud Run.

Vertex AI è una piattaforma di machine learning completa e facile da usare che fornisce un ambiente unificato per il ciclo di vita del machine learning, dalla preparazione dei dati al deployment e al monitoraggio dei modelli.

Per principi e consigli di affidabilità specifici per i workload AI e ML, consulta Prospettiva AI e ML: affidabilità nel framework Well-Architected.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo di creazione ed esecuzione di un'architettura per automatizzare l'elaborazione delle richieste di preautorizzazione e migliorare i processi di revisione dell'utilizzo. La gestione attenta dell'utilizzo delle risorse e la selezione dei livelli di servizio appropriati possono influire in modo significativo sul costo complessivo.

Classi di archiviazione Cloud Storage: utilizza le diverse classi di archiviazione (Standard, Nearline, Coldline o Archive) in base alla frequenza di accesso ai dati. Nearline, Coldline e Archive sono più convenienti per i dati a cui si accede con minore frequenza.

Norme del ciclo di vita di Cloud Storage: implementa le norme del ciclo di vita per trasferire automaticamente gli oggetti a classi di archiviazione a costi inferiori o eliminarli in base all'età e ai modelli di accesso.

Document AI ha un prezzo basato sul numero di processori di cui è stato eseguito il deployment e sul numero di pagine elaborate dai processori Document AI. Considera quanto segue:

  • Ottimizzazione del processore: analizza i pattern dei workload per determinare il numero ottimale di processori Document AI da eseguire il deployment. Evita il provisioning eccessivo delle risorse.
  • Gestione del volume di pagine: la pre-elaborazione dei documenti per rimuovere le pagine non necessarie o ottimizzare la risoluzione può contribuire a ridurre i costi di elaborazione.

Firestore ha un prezzo basato sull'attività relativa a documenti, voci di indice, spazio di archiviazione utilizzato dal database e quantità di larghezza di banda di rete. Considera quanto segue:

  • Modellazione dei dati: progetta il modello dei dati per ridurre al minimo il numero di voci di indice e ottimizzare i pattern di query per l'efficienza.
  • Larghezza di banda della rete: monitora e ottimizza l'utilizzo della rete per evitare addebiti eccessivi. Valuta la memorizzazione nella cache dei dati a cui si accede di frequente.

Gli addebiti di Cloud Run vengono calcolati in base all'utilizzo della CPU on demand, alla memoria e al numero di richieste. Pensa attentamente all'allocazione delle risorse. Alloca le risorse di CPU e memoria in base alle caratteristiche del carico di lavoro. Utilizza la scalabilità automatica per regolare dinamicamente le risorse in base alla domanda.

Vertex AI In genere, gli LLM vengono addebitati in base all'input e all'output del testo o dei contenuti multimediali. I conteggi dei token di input e output influiscono direttamente sui costi degli LLM. Ottimizza i prompt e la generazione di risposte per l'efficienza.

I costi del motore di ricerca AI Applications dipendono dalle funzionalità che utilizzi. Per gestire meglio i costi, puoi scegliere tra le seguenti tre opzioni:

  • Search Standard Edition, che offre funzionalità di ricerca non strutturata.
  • Search Enterprise Edition, che offre funzionalità di ricerca non strutturata e ricerca sul sito web.
  • Componente aggiuntivo LLM per la ricerca, che offre funzionalità di riepilogo e ricerca in più passaggi.

Puoi anche prendere in considerazione i seguenti aspetti aggiuntivi per ottimizzare i costi:

  • Monitoraggio e avvisi: configura Cloud Monitoring e gli avvisi di fatturazione per monitorare i costi e ricevere notifiche quando l'utilizzo supera le soglie.
  • Report sui costi: esamina regolarmente i report sui costi nella console Google Cloud per identificare le tendenze e ottimizzare l'utilizzo delle risorse.
  • Valuta gli sconti per impegno di utilizzo: se hai carichi di lavoro prevedibili, valuta la possibilità di impegnarti a utilizzare queste risorse per un periodo di tempo specificato per ottenere prezzi scontati.

Se prendi in considerazione attentamente questi fattori e implementi le strategie consigliate, puoi gestire e ottimizzare in modo efficace il costo di esecuzione dell'architettura di automazione di PA e UR su Google Cloud.

Per principi e suggerimenti di ottimizzazione dei costi specifici per i carichi di lavoro di AI e ML, consulta Prospettiva AI e ML: ottimizzazione dei costi nel framework Well-Architected.

Deployment

Il codice di implementazione di riferimento per questa architettura è disponibile con licenza open source. L'architettura implementata da questo codice è un prototipo e potrebbe non includere tutte le funzionalità e l'hardening necessari per un deployment di produzione. Per implementare ed espandere questa architettura di riferimento per soddisfare più da vicino i tuoi requisiti, ti consigliamo di contattare Google Cloud Consulting.

Il codice iniziale per questa architettura di riferimento è disponibile nei seguenti repository Git:

  • Repository Git CDA: Questo repository contiene script di deployment Terraform per il provisioning dell'infrastruttura e il deployment del codice dell'applicazione.
  • Repository Git del servizio UR: Questo repository contiene esempi di codice per il servizio UR.

Puoi scegliere una delle seguenti due opzioni per implementare l'assistenza e i servizi per questa architettura di riferimento:

Passaggi successivi

Collaboratori

Autore: Dharmesh Patel | Industry Solutions Architect, Healthcare

Altri collaboratori:

  1. Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.  ↩