Utilizza l'AI 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 autorizzazione preventiva e migliorare le loro procedure di revisione dell'utilizzo utilizzando Google Cloud. È rivolto agli sviluppatori software e agli 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'importazione dati e l'estrazione di informazioni dalle schede cliniche. Inoltre, consente loro di utilizzare modelli di AI per la generazione di prompt e i consigli.

Architettura

Il seguente diagramma descrive un'architettura e un approccio per automatizzare il flusso di lavoro di importazione dati e ottimizzare la procedura 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 della revisione UM.

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 importa in un database in un formato strutturato leggibile dalla macchina. CDA implementa il flusso di dati per importare i moduli di richiesta di accesso ai dati.
  • Servizio di revisione dell'utilizzo (servizio UR), che integra i dati delle richieste di assistenza pubblica, 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 accesso ai dati personali utilizzando l'IA generativa.

Le sezioni seguenti descrivono questi flussi di dati.

Flusso di dati CDA

Il seguente diagramma mostra il flusso di dati per l'utilizzo di CDA per importare i moduli di richiesta di assistenza ai pazienti.

Flusso di dati dei gestori delle richieste di assistenza in Pennsylvania.

Come mostrato nel diagramma precedente, il gestore delle richieste di adesione al programma Partner di AdSense interagisce con i componenti del sistema per importare, convalidare ed elaborare le richieste. I gestori delle richieste di accesso ai dati sono le persone del team di operazioni aziendali responsabili dell'accettazione delle richieste di accesso ai dati. Il flusso di eventi è il seguente:

  1. I gestori dei casi di assistenza ai pazienti ricevono i moduli di richiesta di assistenza ai pazienti (pa_forms) dal fornitore di servizi sanitari e li caricano nel pa_forms_bkt bucket Cloud Storage.
  2. Il servizio ingestion_service monitora il 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 processori sono definiti per elaborare i moduli pa_forms. Il ingestion_service servizio estrae le informazioni dai moduli utilizzando i form_processors processori. 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, chiamata pa_form_collection.
  4. L'applicazione hitl_app recupera le informazioni (JSON) con i relativi punteggi di attendibilità 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 di documento ai gestori dei casi PA in modo che possano esaminare e correggere le informazioni se i valori estratti non sono accurati. I gestori delle richieste di assistenza 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 per gli esperti UR.

Come mostrato nel diagramma precedente, gli specialisti UR interagiscono con i componenti del sistema per effettuare una revisione clinica delle richieste di assistenza sanitaria. Gli specialisti UR sono in genere infermieri o medici con esperienza in un'area clinica specifica che sono impiegati da compagnie di assicurazione sanitaria. Il flusso di lavoro di gestione e inoltro delle richieste di assistenza in primo piano non rientra nell'ambito del flusso di lavoro descritto in questa sezione.

Il flusso di eventi è il seguente:

  1. L'applicazione ur_app mostra agli esperti UR un elenco delle richieste di adesione al programma partner e il relativo stato di revisione. 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. Lo specialista 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 esperti UR per la revisione e il feedback. Gli esperti UR possono aggiornare la richiesta nell'interfaccia utente e inviarla all'applicazione.

  5. L'applicazione ur_app invia il prompt al modello ur_model con una richiesta di generazione di un consiglio. Il modello genera una risposta e torna all'applicazione. L'applicazione mostra il risultato consigliato ai professionisti UR.

  6. Gli esperti 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 pre-indicizzati e accessibili all'applicazione ur_search_app.

Componenti

L'architettura contiene i seguenti componenti:

  • Bucket Cloud Storage. I servizi per le applicazioni UM richiedono i seguenti bucket Cloud Storage nel tuo progetto Google Cloud:

    • pa_forms_bkt: un bucket per importare i moduli PA che richiedono l'approvazione.
    • training_forms: un bucket per contenere i moduli PA storici per la formazione dei processori dei moduli DocAI.
    • eval_forms: un bucket per contenere i moduli PA per valutare la precisione dei processori dei 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 PA o successivamente per supportare la richiesta PA. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio Vertex AI Agent Builder.
    • um_policies: un bucket per contenere linee guida sulla necessità e sull'assistenza medica, documenti relativi alle norme dei piani sanitari e linee guida sulla copertura. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio Vertex AI Agent Builder.
  • 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 del 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 mostra i valori dei dati estratti da pa_forms. Inoltre, mostra al gestore dei casi PA il punteggio di affidabilità riportato dagli elaboratori dei moduli (modelli ML) in modo che possa esaminare, correggere e salvare le informazioni nel data store.

  • ur_app: un microservizio (applicazione web) che gli esperti UR possono utilizzare per esaminare le richieste di assistenza pubblica utilizzando l'IA 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 consiglio per una richiesta.

  • Modelli LLM di Vertex AI ottimizzati per la medicina: Vertex AI offre una serie di modelli di base dell'AI generativa che possono essere ottimizzati per ridurre i costi e la latenza. I modelli utilizzati in questa architettura sono i seguenti:

    • prompt_model: un'opzione dell'LLM ottimizzata per generare prompt basati sui 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 Vertex AI Agent Builder per trovare informazioni personalizzate e pertinenti per gli specialisti UR da documenti clinici, norme di 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 IA e personalizzare LLM da utilizzare nelle applicazioni basate sull'IA.
  • Vertex AI Agent Builder: una piattaforma che consente agli sviluppatori di creare ed eseguire il deployment di agenti e applicazioni basati sull'IA di livello enterprise.
  • Document AI: una piattaforma di elaborazione di documenti che acquisisce 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 calcolo 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 Cloud e vengono replicati in più località per garantire la ridondanza.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
  • Cloud Monitoring: un servizio che fornisce visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e dell'infrastruttura.

Caso d'uso

L'UM è un processo utilizzato dalle compagnie di assicurazione sanitaria principalmente negli Stati Uniti, ma procedimenti simili (con alcune modifiche) vengono utilizzati a livello globale nel mercato dell'assicurazione sanitaria. L'obiettivo dell'UM è contribuire a garantire che i pazienti ricevano l'assistenza appropriata nel contesto corretto, al momento ottimale e al costo più basso possibile. L'UM contribuisce inoltre a garantire che l'assistenza medica sia efficace, efficiente e in linea con gli standard di cura basati sulle evidenze. La PA è uno strumento di UM che richiede l'approvazione della compagnia assicurativa prima che un paziente riceva cure mediche.

La procedura UM utilizzata da molte aziende rappresenta un ostacolo alla fornitura e alla ricezione di assistenza tempestiva. È costoso, richiede tempo e comporta un'eccessiva burocrazia. Inoltre, è complessa, manuale e lenta. Questo processo influisce notevolmente sulla capacità del piano sanitario di gestire efficacemente la qualità delle cure e di migliorare l'esperienza del fornitore e dei membri. Tuttavia, se queste aziende modificassero la procedura di UM, potrebbero contribuire a garantire ai pazienti un trattamento di alta qualità a costi contenuti. Ottimizzando la procedura di UR, i piani sanitari possono ridurre i costi e i rifiuti tramite l'elaborazione accelerata delle richieste di PA, il che a sua volta può migliorare l'esperienza di pazienti e fornitori. Questo approccio contribuisce a ridurre il carico amministrativo per i fornitori di servizi sanitari.

Quando i piani sanitari ricevono richieste di assistenza sanitaria, i gestori delle richieste creano richieste nel sistema di gestione delle richieste per monitorare, gestire ed elaborare le richieste. Un gran numero di queste richieste viene ricevuto via fax e posta, con i documenti clinici allegati. Tuttavia, le informazioni contenute in questi moduli e documenti non sono facilmente accessibili alle compagnie di assicurazione sanitaria per l'analisi dei dati e l'intelligence aziendale. L'attuale procedura di inserimento manuale delle informazioni di questi documenti nei sistemi di gestione delle richieste è inefficiente e 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 per il personale. L'estrazione di informazioni utili dai moduli e dai documenti clinici consente alle compagnie di assicurazione sanitaria di velocizzare la procedura di UR.

Note sul layout

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

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da tenere presenti 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 - HITECH - Act) richiede la conformità alle Security Rule, Privacy Rule e Breach Notification Rule dell'HIPAA. Google Cloud supporta la conformità HIPAA, ma in ultima analisi sei responsabile della valutazione della tua conformità HIPAA. La conformità a HIPAA è una responsabilità condivisa tra te e Google. Se la tua organizzazione è soggetta al Regolamento HIPAA e vuoi utilizzare qualsiasi prodotto Google Cloud 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 soddisfano 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 gli LLM ospitati in Vertex AI Model Garden supportano HIPAA. Valutare e utilizzare gli LLM che supportano HIPAA.

Per valutare in che modo i prodotti Google possono soddisfare le tue esigenze di conformità HIPAA, puoi fare riferimento ai report di controllo 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'IA e di progettarli tenendo presenti queste considerazioni:

I prodotti di Google rispettano i principi dell'IA responsabile.

Affidabilità

Questa sezione descrive i fattori di progettazione che devi prendere in considerazione per creare e gestire un'infrastruttura affidabile per automatizzare l'elaborazione delle richieste di accesso ai dati personali.

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. Se si verifica un'interruzione di servizio nella zona, i dati non vengono persi. Se si verifica un'interruzione in una regione, il servizio non è disponibile fino a quando Google non risolve il problema.

Puoi creare bucket Cloud Storage in una di tre località: regionale, a due regioni o multiregione, 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 i bucket a due regioni o multiregionali, 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 contribuire a garantire scalabilità e affidabilità a livello globale.

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. Se si verifica un'interruzione del servizio in una zona, i job Cloud Run continuano a essere eseguiti e i dati non vengono persi. Se si verifica un'interruzione del servizio in una regione, i job Cloud Run non vengono eseguiti finché Google non risolve l'interruzione. I singoli job o le singole attività Cloud Run potrebbero non riuscire. Per gestire questi fallimenti, puoi utilizzare i tentativi di esecuzione delle attività e i checkpoint. Per ulteriori informazioni, consulta Best practice per i tentativi di ripetizione e i checkpoint dei job. La guida all'affidabilità 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.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della creazione e dell'esecuzione di un'architettura per automatizzare l'elaborazione delle richieste di adesione al programma partner e migliorare le procedure UR. La gestione attenta dell'utilizzo delle risorse e la selezione di livelli di servizio appropriati possono influire notevolmente 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 meno di frequente.

Criteri del ciclo di vita di Cloud Storage: implementa i criteri del ciclo di vita per eseguire automaticamente la transizione degli oggetti a classi di archiviazione a costi inferiori o eliminarli in base all'età e ai modelli di accesso.

Document AI viene calcolato in base al numero di processori impiegati e al numero di pagine elaborate dai processori Document AI. Considera quanto segue:

  • Ottimizzazione del processore: analizza i pattern di carico di lavoro per determinare il numero ottimale di processori Document AI da implementare. Evita di eseguire 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.

Il prezzo di Firestore si basa sulle attività correlate a documenti, voci dell'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 dell'indice e ottimizzare i pattern di query per l'efficienza.
  • Larghezza di banda della rete: monitora e ottimizza l'utilizzo della rete per evitare costi aggiuntivi. Valuta la possibilità di memorizzare nella cache i dati a cui si accede di frequente.

Gli addebiti di Cloud Run vengono calcolati in base all'utilizzo on demand della CPU, alla memoria e al numero di richieste. Valuta attentamente l'allocazione delle risorse. Alloca risorse di CPU e memoria in base alle caratteristiche del carico di lavoro. Utilizza la scalabilità automatica per regolare le risorse in modo dinamico 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 di output influiscono direttamente sui costi degli LLM. Ottimizza la generazione di prompt e risposte per l'efficienza.

I costi del motore di ricerca di Vertex AI Agent Builder dipendono dalle funzionalità che utilizzi. Per aiutarti a gestire i costi, puoi scegliere tra le tre seguenti opzioni:

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

Puoi anche prendere in considerazione le seguenti considerazioni aggiuntive per ottimizzare i costi:

  • Monitoraggio e avvisi: configura Cloud Monitoring e gli avvisi relativi alla 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 la possibilità di usufruire degli sconti per impegno di utilizzo: se hai carichi di lavoro prevedibili, valuta la possibilità di impegnarti a utilizzare queste risorse per un periodo specificato per usufruire di prezzi scontati.

Prendere in considerazione attentamente questi fattori e implementare le strategie consigliate può aiutarti a gestire e ottimizzare in modo efficace il costo di esecuzione dell'architettura di automazione di PA e UR su Google Cloud.

Deployment

Il codice di implementazione di riferimento per questa architettura è disponibile in base alle licenze open source. L'architettura implementata da questo codice è un prototipo e potrebbe non includere tutte le funzionalità e le misure di protezione di cui hai bisogno per un deployment in produzione. Per implementare ed espandere questa architettura di riferimento in modo da soddisfare più da vicino i tuoi requisiti, ti consigliamo di contattare Google Cloud Consulting.

Il codice di avvio 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 due seguenti opzioni per implementare assistenza e servizi per questa architettura di riferimento:

Passaggi successivi

Collaboratori

Autore: Dharmesh Patel | Industry Solutions Architect, settore sanitario

Altri collaboratori: