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 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 dei dati e l'estrazione di informazioni dalle schede cliniche. Inoltre, consente di usare 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 dei dati e ottimizzare la procedura di revisione della gestione dell'utilizzo (UM). Questo approccio utilizza dati e servizi di AI in Google Cloud.

Panoramica generale del processo di importazione dati e revisione UM.

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

  • Claims Data Activator (CDA), che estrae i dati da non strutturate, come moduli e documenti, e le importa in un in un formato strutturato e leggibile dalle macchine. Il CDA implementa il flusso per importare i moduli di richiesta AP.
  • Servizio di revisione dell'utilizzo (servizio UR), che integra i dati delle richieste PA, i documenti relativi alle norme e altri linee guida sull'assistenza 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 seguenti sezioni 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 responsabili delle richieste di PA.

Come mostrato nel diagramma precedente, il case manager PA interagisce con componenti di sistema per importare, convalidare ed elaborare le richieste PA. 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 responsabili delle richieste dell'AP ricevono i moduli di richiesta dell'AP (pa_forms) dal fornitore di servizi sanitari e li carica nella pa_forms_bkt bucket Cloud Storage.
  2. Il servizio ingestion_service monitora il bucket pa_forms_bkt per rilevare eventuali modifiche. Il servizio ingestion_service recupera i pa_formsmoduli dal bucket pa_forms_bkt. Il servizio identifica i processori Document AI preconfigurati, chiamati form_processors. Questi sono definiti processori 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 di database Firestore, denominato 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 responsabili delle richieste di PA possono aggiornare i valori errati e salvare il documento il 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 specialistico dell'UR.

Come illustrato nel diagramma precedente, gli specialisti UR interagiscono con il sistema per eseguire una revisione clinica delle richieste AP. Gli esperti UR sono generalmente infermieri o medici con esperienza in un'area clinica specifica dipendenti di compagnie di assicurazione sanitaria. Gestione delle richieste e routing per le richieste PA non rientra nell'ambito del flusso di lavoro descritto in questa sezione.

Il flusso degli eventi è il seguente:

  1. L'applicazione ur_app mostra agli esperti UR un elenco delle richieste di accesso ai dati personali 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 Gemini di Vertex AI 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 la invii 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 visualizza il risultato consigliato agli esperti 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 il quale conservare i dati richiesti per la valutazione dell'LLM.
    • clinical_docs: un bucket per contenere i documenti clinici che che i fornitori inviino come allegati ai moduli PA o in seguito per la richiesta dell'AP. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio Vertex AI Agent Builder.
    • um_policies: un contenitore per sostenere le necessità e le cure mediche linee guida, documenti sulle 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. Esegue anche il rendering dell'affidabilità riportato dai processori di moduli (modelli ML) al gestore dei casi PA in modo che che possono esaminare, correggere e salvare le informazioni nel datastore.

  • 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 a ur_model. per ottenere il suggerimento per una richiesta.

  • LLM Vertex AI ottimizzati dal punto di vista medico: Vertex AI dispone di una varietà di modelli di base dell'AI generativa che possono essere ottimizzato per ridurre costi e latenza. I modelli utilizzati in questo 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 consigliato in base al prompt di input.

  • ur_search_app: un'applicazione di ricerca creata con Vertex AI Agent Builder di trovare informazioni personalizzate e pertinenti per gli specialisti UR dal documenti clinici, criteri di messaggistica immediata e linee guida sulla copertura.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud:

  • Vertex AI: una piattaforma di ML che consente di addestrare ed eseguire il deployment di modelli ML applicazioni di IA e AI, nonché personalizzare gli LLM per l'utilizzo nelle applicazioni basate sull'AI.
  • 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 sfrutta dati non strutturati da documenti e li trasformano in dati strutturati.
  • Firestore: un database di documenti NoSQL creato per offrire scalabilità automatica, prestazioni elevate e la facilità di sviluppo delle applicazioni.
  • Cloud Run: una piattaforma di serverless computing che ti consente di eseguire i container direttamente sull'infrastruttura scalabile di Google.
  • Cloud Storage: un archivio di oggetti economico e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloud 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 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 è aiutare a garantire che i pazienti ricevano la la cura adeguata nell'impostazione corretta, nel momento ottimale e nel minor tempo i costi possibili. La messaggistica immediata aiuta anche a garantire che l'assistenza medica sia efficace, efficiente e in linea con gli standard di cura basati su prove concrete. 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. È un'operazione costosa, lunga ed eccessivamente amministrativa. Inoltre, è complessa, manuale e lenta. Questo processo influisce notevolmente sulla capacità del piano sanitario di gestire efficacemente la qualità dell'assistenza e di migliorare l'esperienza del fornitore e dei membri. Tuttavia, se queste aziende modificassero il loro processo di gestione della messaggistica immediata, possono contribuire a garantire ai pazienti un trattamento di alta qualità a costi contenuti. Ottimizzando il loro processo di UR, i piani sanitari possono ridurre costi e rifiuti mediante l'elaborazione rapida delle richieste PA, che a sua volta possono migliorare l'esperienza di pazienti e operatori. Questo approccio contribuisce a ridurre il carico amministrativo per i fornitori di servizi sanitari.

Quando i piani sanitari ricevono richieste per l'AP, i responsabili delle PA creano casi il sistema di gestione delle richieste di assistenza 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, errori di inserimento e oneri amministrativi 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 aiutino a soddisfare i tuoi requisiti specifici in termini di 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 e successive modifiche, anche da parte dell'Health Information Technology for Economic e Clinical Health — HITECH — Act) richiede la conformità alle Security Regola, Regola sulla privacy, e Breach Notification Regola. Google Cloud supporta la conformità HIPAA, ma, in ultima analisi, spetta a te valutare la tua conformità alla normativa HIPAA. La conformità alla normativa HIPAA è una responsabilità condivisa fra 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 la normativa HIPAA. Valutare e utilizzare 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 di controllo di terze parti nel Centro risorse per la conformità.

Consigliamo ai clienti di tenere in considerazione quanto segue quando selezionano i casi d'uso dell'IA: e la progettazione tenendo a mente queste considerazioni:

I prodotti di Google seguono 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 protetto.

Document AI form_processors è un servizio regionale. I dati sono archiviati in modo sincrono tra più zone all'interno di una regione. Il traffico viene bilanciato automaticamente tra le zone. In caso di interruzione di una zona, i dati non si perda. In caso di interruzione di una regione, il servizio non sarà disponibile fino a quando Google che risolve l'interruzione.

Puoi creare bucket Cloud Storage in uno dei tre seguenti locations: una singola regione o una o più regioni utilizzando pa_forms_bkt, training_forms, eval_forms, tuning_dataset, eval_dataset, clinical_docs o um_policies bucket. 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 due o più regioni dei bucket, dove i dati vengono replicati in modo asincrono tra le regioni.

In Firestore le informazioni estratte dal database pa_form_collection possono trovarsi 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 tra più zone all'interno 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 una regione un'interruzione del servizio, l'esecuzione dei job Cloud Run viene interrotta finché Google o un'interruzione del servizio. I singoli job o le singole attività Cloud Run potrebbero non riuscire. Per gestire tali errori, puoi usare i nuovi tentativi di attività e i checkpoint. Per ulteriori informazioni, vedi Best practice per i nuovi tentativi di job e i checkpoint. 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 per automatizzare l'elaborazione delle richieste PA e migliorare nei tuoi processi 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 di Cloud Storage: Usa 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 a cui si accede con meno frequenza e i dati di Google Cloud.

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 l'overprovisioning delle risorse.
  • Gestione del volume delle pagine: pre-elabora i documenti per rimuovere i non necessari pagine o ottimizzare la risoluzione possono aiutare a ridurre i costi di elaborazione.

Firestore ha un prezzo basato sulle attività relative a documenti, voci di indice, spazio di archiviazione usi del database e la quantità di larghezza di banda della rete. Considera quanto segue:

  • Modellazione dei dati: progetta il tuo modello dei dati per ridurre al minimo il numero di indicizzare e ottimizzare i pattern di query per una maggiore efficienza.
  • Larghezza di banda della rete: monitora e ottimizza l'utilizzo della rete per evitare un uso eccessivo addebiti. 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 Gli LLM sono in genere addebitati in base all'input e l'output del testo o dei contenuti multimediali. I conteggi di token di input e output influiscono direttamente sui costi degli LLM. Ottimizza i prompt e la generazione di risposte per migliorare l'efficienza.

Ricerca di Vertex AI Agent Builder le cariche del motore dipendono dalle funzioni utilizzate. Per aiutarti a gestire i costi, puoi scegliere fra le tre opzioni seguenti:

  • Search Standard Edition, che offre funzionalità di ricerca non strutturate.
  • 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 nel 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 specifico a 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 PA e UR su Google Cloud.

Deployment

Il codice di implementazione di riferimento per questa architettura è disponibile in licenze open source. L'architettura implementata da questo codice è un prototipo e potrebbe non includere tutte le funzionalità e l'hardening di cui hai bisogno per un deployment di produzione. Per implementare ed espandere questa architettura di riferimento per soddisfare al meglio le tue esigenze, ti consigliamo di contattare consulenze Google Cloud.

Il codice di avvio per questa architettura di riferimento è disponibile in 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 opzioni seguenti per implementare l'assistenza e per questa architettura di riferimento:

Passaggi successivi

Collaboratori

Autore: Dharmesh Patel | Industry Solutions Architect, Healthcare

Altri collaboratori: