Automatizzare la revisione dell'utilizzo delle richieste di rimborso dell'assicurazione sanitaria utilizzando l'AI generativa

Last reviewed 2024-08-19 UTC

Questo documento descrive un'architettura di riferimento per le compagnie assicurative sanitarie che vogliono automatizzare l'elaborazione delle richieste di autorizzazione preventiva (PA) e migliorare i processi di revisione dell'utilizzo (UR) utilizzando Google Cloud. È rivolto agli sviluppatori di software e agli amministratori di programmi di queste organizzazioni. Questa architettura aiuta i fornitori di piani sanitari a ridurre i costi amministrativi, aumentare l'efficienza e migliorare il processo decisionale automatizzando l'importazione dati e l'estrazione di insight dai moduli clinici. Inoltre, consente loro di utilizzare modelli di AI per la generazione di prompt e i suggerimenti.

Architettura

Il seguente diagramma descrive un'architettura e un approccio per automatizzare il workflow 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 acquisizione dei dati e di revisione della gestione dell'utilizzo.

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

  • Attivatore dati delle richieste di risarcimento (CDA), che estrae i dati da fonti non strutturate, come moduli e documenti, e li importa in un database in un formato strutturato e leggibile da macchina. CDA implementa il flusso di dati per l'importazione dei moduli di richiesta di AP.
  • Servizio di revisione dell'utilizzo (servizio UR), che integra i dati delle richieste di AP, i documenti delle policy e altre linee guida per l'assistenza per generare suggerimenti. Il servizio UR implementa il flusso di dati per esaminare le richieste di AP utilizzando l'AI 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 l'importazione dei moduli di richiesta di AP.

Flusso di dati dei gestori dei casi PA.

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

  1. I case manager di AP ricevono i moduli di richiesta di AP (pa_forms) dal fornitore di servizi sanitari e li caricano nel bucket Cloud Storage pa_forms_bkt.
  2. Il servizio ingestion_service rimane in ascolto del bucket pa_forms_bkt per rilevare eventuali modifiche. Il servizio ingestion_service preleva 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 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 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 i punteggi di affidabilità dal database pa_form_collection. L'applicazione calcola il punteggio di affidabilità a livello di documento dai punteggi di affidabilità a livello di campo resi disponibili nell'output dai modelli di machine learning (ML) di form_processors.
  5. L'applicazione hitl_app mostra le informazioni estratte con i punteggi di affidabilità a livello di campo e di documento ai gestori dei casi di AP, in modo che possano esaminare e correggere le informazioni se i valori estratti non sono accurati. I case manager di 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 AP. Gli specialisti di UR sono in genere infermieri o medici con esperienza in un'area clinica specifica che lavorano per compagnie assicurative sanitarie. Il flusso di lavoro per la gestione e il routing delle richieste di AP 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 specialisti UR un elenco di richieste di AP 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 Agent Platform 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 UR per la revisione e il feedback. Gli specialisti 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 generazione di un suggerimento. Il modello genera una risposta e la restituisce all'applicazione. L'applicazione mostra il risultato consigliato agli specialisti di UR.

  6. Gli specialisti 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 delle 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 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 AP o successivamente per supportare la richiesta di AP. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio Agent Search.
    • um_policies: un bucket per contenere le linee guida per la necessità medica e l'assistenza, i documenti delle polizze del piano sanitario e le linee guida per la copertura. Questi documenti vengono indicizzati dall'applicazione di ricerca nel servizio Agent Search.

  • 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 archivia 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, mostra il punteggio di affidabilità riportato dai processori di moduli (modelli ML) al case manager della PA, in modo che possa esaminare, correggere e salvare le informazioni nel datastore.

  • ur_app: un microservizio (applicazione web) che gli specialisti di UR possono utilizzare per esaminare le richieste di PA 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 un caso.

  • LLM ottimizzati per la medicina di Agent Platform: Agent Platform dispone di una varietà 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 all'estrazione dati da pa_forms.
    • ur_model: un adattatore sull'LLM ottimizzato per generare una bozza di suggerimento in base al prompt di input.

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

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

  • Gemini Enterprise Agent Platform: una piattaforma completa che ti consente di creare, scalare, gestire e ottimizzare agenti AI di livello enterprise.
  • Agent Search: una piattaforma che ti consente 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 i 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 serverless computing che ti consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
  • Cloud Storage: un archivio 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 fornisce visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e dell'infrastruttura.

Caso d'uso

La gestione dell'utilizzo è un processo utilizzato dalle compagnie assicurative sanitarie principalmente negli Stati Uniti, ma processi simili (con alcune modifiche) vengono utilizzati a livello globale nel mercato delle assicurazioni sanitarie. L'obiettivo della gestione dell'utilizzo è contribuire a garantire che i pazienti ricevano le cure appropriate nel contesto corretto, al momento ottimale e al costo più basso possibile. La gestione dell'utilizzo contribuisce inoltre a garantire che l'assistenza medica sia efficace, efficiente e in linea con gli standard di assistenza basati su prove. L'AP è uno strumento di gestione dell'utilizzo che richiede l'approvazione della compagnia assicurativa prima che un paziente riceva cure mediche.

Il processo di gestione dell'utilizzo (UM) utilizzato da molte aziende rappresenta un ostacolo alla fornitura e alla ricezione di un'assistenza tempestiva. È costoso, richiede molto tempo ed è eccessivamente amministrativo. È anche un processo complesso, manuale e lento. Questo processo influisce in modo significativo sulla capacità del piano sanitario di gestire in modo efficace la qualità dell'assistenza e di migliorare l'esperienza dei fornitori e dei membri. Tuttavia, se queste aziende modificassero il loro processo di UM, potrebbero contribuire a garantire che i pazienti ricevano un trattamento di alta qualità ed economicamente vantaggioso. Ottimizzando il processo di UR, i piani sanitari possono ridurre i costi e i rifiuti tramite l'elaborazione accelerata delle richieste di AP, il che a sua volta può migliorare l'esperienza di pazienti e fornitori. Questo approccio contribuisce a ridurre l'onere amministrativo per gli operatori sanitari.

Quando i piani sanitari ricevono richieste di AP, i case manager di AP creano casi nel sistema di gestione dei casi per monitorare, gestire ed elaborare le richieste. Una quantità significativa di queste richieste viene ricevuta via fax e posta, con documenti clinici allegati. Tuttavia, le informazioni contenute in questi moduli e documenti non sono facilmente accessibili alle compagnie assicurative per l'analisi dei dati e la business intelligence. L'attuale processo 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 l'onere amministrativo per il personale. L'estrazione di informazioni preziose dai moduli e dai documenti clinici consente alle compagnie assicurative di accelerare il processo di UR.

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 inGoogle 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, emendamenti inclusi, anche 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 dell'HIPAA. Google Cloud supporta la conformità HIPAA, ma in ultima analisi sei tu ad avere la responsabilità di valutare la tua conformità HIPAA. La conformità all'HIPAA è una responsabilità condivisa tra te e Google. Se la tua organizzazione è soggetta all'HIPAA e vuoi utilizzare i prodotti Google Cloudin relazione ai 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 gli LLM ospitati in Model Garden supportano l'HIPAA. Valuta e utilizza gli LLM che supportano l'HIPAA.

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

Consigliamo ai clienti di tenere conto di quanto segue quando selezionano i casi d'uso dell'AI e di progettare tenendo conto di queste considerazioni:

I prodotti Google seguono i principi dell'AI responsabile.

Per i principi e i suggerimenti di sicurezza specifici per i workload di AI e ML, consulta Prospettiva di 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 AP.

Document AI form_processors è un servizio regionale. 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 della zona, i dati non vengono persi1. Se si verifica un'interruzione della regione, il servizio non è disponibile finché Google non risolve il problema.

Puoi creare bucket Cloud Storage in una delle tre località: singola regione, a due regioni o multiregionale, utilizzando 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 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 trovarsi in più data center per contribuire a 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. I singoli job o task di Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i tentativi di ripetizione delle attività e il checkpointing. Per saperne di più, consulta Best practice per i nuovi tentativi e i checkpoint dei job. Suggerimenti generali per lo sviluppo con Cloud Run descrive alcune best practice per l'utilizzo di Cloud Run.

Agent Platform è 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 del modello.

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

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 AP e migliorare i processi di UR. 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 di 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 ad accesso meno frequente.

Policy del ciclo di vita di Cloud Storage: implementa policy del ciclo di vita per trasferire automaticamente gli oggetti in classi di archiviazione a costo inferiore o eliminarli in base all'età e ai pattern di accesso.

I prezzi di Document AI si basano sul numero di processori di cui è stato eseguito il deployment e sul numero di pagine elaborate dai processori di Document AI. Considera quanto segue:

  • Ottimizzazione dei processori: analizza i pattern dei workload per determinare il numero ottimale di processori Document AI di cui eseguire il deployment. Evita l'overprovisioning delle risorse.
  • Gestione del volume delle pagine: l'elaborazione preliminare dei documenti per rimuovere le pagine non necessarie o ottimizzare la risoluzione può contribuire a ridurre i costi di elaborazione.

I prezzi di Firestore si basano sull'attività relativa ai documenti, alle voci dell'indice, allo spazio di archiviazione utilizzato dal database e alla 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 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 addebiti eccessivi. Valuta la possibilità di memorizzare nella cache i dati ad accesso frequente.

I costi di Cloud Run vengono calcolati in base all'utilizzo di 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 workload. Utilizza la scalabilità automatica per adattare dinamicamente le risorse in base alla domanda.

Agent Platform Gli LLM vengono generalmente 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 delle risposte per una maggiore efficienza.

I costi del motore di ricerca Agent Search dipendono dalle funzionalità che utilizzi. Per gestire 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 di ricerca sul sito web.
  • Componente aggiuntivo LLM per la ricerca, che offre funzionalità di riassunto 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 consoleGoogle Cloud per identificare le tendenze e ottimizzare l'utilizzo delle risorse.
  • Valuta gli sconti per impegno di utilizzo: se hai workload prevedibili, valuta la possibilità di impegnarti a utilizzare queste risorse per un periodo di tempo specificato per ottenere prezzi scontati.

Un'attenta valutazione di questi fattori e l'implementazione delle strategie consigliate possono aiutarti a gestire e ottimizzare in modo efficace il costo di esecuzione dell'architettura di automazione PA e UR su Google Cloud.

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

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 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 gli script di deployment di 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 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.  ↩