Use a IA generativa para a gestão da utilização

Last reviewed 2024-08-19 UTC

Este documento descreve uma arquitetura de referência para seguradoras de saúde que pretendem automatizar o processamento de pedidos de autorização prévia (AP) e melhorar os respetivos processos de revisão de utilização (RU) através da Google Cloud. Destina-se a programadores de software e administradores de programas nestas organizações. Esta arquitetura ajuda a permitir que os fornecedores de planos de saúde reduzam os custos administrativos, aumentem a eficiência e melhorem a tomada de decisões através da automatização do carregamento de dados e da extração de estatísticas de formulários clínicos. Também lhes permite usar modelos de IA para a geração de comandos e recomendações.

Arquitetura

O diagrama seguinte descreve uma arquitetura e uma abordagem para automatizar o fluxo de trabalho de carregamento de dados e otimizar o processo de revisão da gestão de utilização (UM). Esta abordagem usa serviços de dados e IA em Google Cloud.

Vista geral de nível superior do processo de carregamento de dados e revisão da UM.

A arquitetura anterior contém dois fluxos de dados, que são suportados pelos seguintes subsistemas:

  • Ativador de dados de reivindicações (CDA), que extrai dados de fontes não estruturadas, como formulários e documentos, e carrega-os numa base de dados num formato estruturado legível por máquina. A CDA implementa o fluxo de dados para ingerir formulários de solicitação de PA.
  • Serviço de revisão de utilização (serviço de RU), que integra dados de pedidos de autorização prévia, documentos de políticas e outras diretrizes de cuidados para gerar recomendações. O serviço UR implementa o fluxo de dados para rever pedidos de PA através da IA generativa.

As secções seguintes descrevem estes fluxos de dados.

Fluxo de dados da CDA

O diagrama seguinte mostra o fluxo de dados para usar o CDA para carregar formulários de solicitação de PA.

Fluxo de dados dos gestores de registos de PA.

Conforme mostrado no diagrama anterior, o gestor de registos de PA interage com os componentes do sistema para carregar, validar e processar os pedidos de PA. Os gestores de registos de PA são os indivíduos da equipa de operações empresariais responsáveis pela receção dos pedidos de PA. O fluxo de eventos é o seguinte:

  1. Os gestores de casos de autorização prévia recebem os formulários de pedido de autorização prévia (pa_forms) do fornecedor de cuidados de saúde e carregam-nos para o contentor do pa_forms_bkt Cloud Storage.
  2. O serviço ingestion_service ouve o contentor pa_forms_bkt para detetar alterações. O serviço ingestion_service recolhe pa_formsformulários do contentor pa_forms_bkt. O serviço identifica os processadores de IA de documentos pré-configurados, denominados form_processors. Estes processadores são definidos para processar os formulários pa_forms. O serviço extrai informações dos formulários através dos processadores.ingestion_serviceform_processors Os dados extraídos dos formulários estão no formato JSON.
  3. O serviço ingestion_service escreve as informações extraídas com pontuações de confiança ao nível do campo na coleção da base de dados do Firestore, denominada pa_form_collection.
  4. A aplicação hitl_app obtém as informações (JSON) com pontuações de confiança da base de dados pa_form_collection. A aplicação calcula a pontuação de confiança ao nível do documento a partir das pontuações de confiança ao nível do campo disponibilizadas na saída pelos modelos de aprendizagem automática.form_processors
  5. A aplicação hitl_app apresenta as informações extraídas com os níveis de confiança dos campos e dos documentos aos gestores de casos de PA para que possam rever e corrigir as informações se os valores extraídos forem imprecisos. Os gestores de registos de PA podem atualizar os valores incorretos e guardar o documento na base de dados pa_form_collection.

Fluxo de dados do serviço UR

O diagrama seguinte mostra o fluxo de dados para o serviço UR.

Fluxo de dados do especialista de UR.

Conforme mostrado no diagrama anterior, os especialistas em UR interagem com os componentes do sistema para realizar uma revisão clínica dos pedidos de PA. Normalmente, os especialistas em UR são enfermeiros ou médicos com experiência numa área clínica específica que são contratados por seguradoras de saúde. O fluxo de trabalho de gestão e encaminhamento de registos para pedidos de PA está fora do âmbito do fluxo de trabalho descrito nesta secção.

O fluxo de eventos é o seguinte:

  1. A aplicação ur_app apresenta uma lista de pedidos de AP e o respetivo estado de revisão aos especialistas de UR. O estado é apresentado como in_queue, in_progress ou completed.
  2. A lista é criada através da obtenção dos dados pa_form information da base de dados pa_form_collection. O especialista em UR abre um pedido clicando num item da lista apresentada na aplicação ur_app.

  3. A aplicação ur_app envia os dados pa_form information para o modelo prompt_model. Usa a API Vertex AI Gemini para gerar um comando semelhante ao seguinte:

    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. A aplicação ur_app apresenta o comando gerado aos especialistas em UR para revisão e feedback. Os especialistas em UR podem atualizar o comando na IU e enviá-lo para a aplicação.

  5. A aplicação ur_app envia o comando para o modelo ur_model com um pedido para gerar uma recomendação. O modelo gera uma resposta e regressa à aplicação. A aplicação apresenta o resultado recomendado aos especialistas de UR.

  6. Os especialistas da UR podem usar a aplicação ur_search_app para pesquisar clinical documents, care guidelines e plan policy documents. Os elementos clinical documents, care guidelines e plan policy documents estão pré-indexados e acessíveis à aplicação ur_search_app.

Componentes

A arquitetura contém os seguintes componentes:

  • Contentores do Cloud Storage. Os serviços de aplicações da UM requerem os seguintes contentores do Cloud Storage no seu Google Cloud projeto:

    • pa_forms_bkt: Um contentor para carregar os formulários de PA que precisam de aprovação.
    • training_forms: um contentor para guardar formulários de PA históricos para formação dos processadores de formulários do DocAI.
    • eval_forms: Um contentor para guardar formulários de PA para avaliar a precisão dos processadores de formulários do DocAI.
    • tuning_dataset: um contentor para guardar os dados necessários para a otimização do grande modelo de linguagem (GML).
    • eval_dataset: Um contentor para guardar os dados necessários para a avaliação do MDG.
    • clinical_docs: um contentor para guardar os documentos clínicos que os fornecedores enviam como anexos aos formulários de autorização prévia ou posteriormente para apoiar o registo de autorização prévia. Estes documentos são indexados pela aplicação de pesquisa no serviço de aplicações de IA.
    • um_policies: um contentor para guardar as diretrizes de necessidade médica e cuidados, os documentos de políticas do plano de saúde e as diretrizes de cobertura. Estes documentos são indexados pela aplicação de pesquisa no serviço de aplicações de IA.

  • form_processors: Estes processadores são preparados para extrair informações dos formulários pa_forms.

  • pa_form_collection: um armazenamento de dados do Firestore para armazenar as informações extraídas como documentos JSON na coleção da base de dados NoSQL.

  • ingestion_service: um microsserviço que lê os documentos do contentor, transmite-os aos pontos finais da DocAI para análise e armazena os dados extraídos na coleção da base de dados do Firestore.

  • hitl_app: um microsserviço (aplicação Web) que obtém e apresenta valores de dados extraídos do pa_forms. Também renderiza a pontuação de confiança comunicada pelos processadores de formulários (modelos de ML) ao gestor de registos de PA para que este possa rever, corrigir e guardar as informações no repositório de dados.

  • ur_app: um microsserviço (aplicação Web) que os especialistas em UR podem usar para rever os pedidos de PA através da IA generativa. Usa o modelo denominado prompt_model para gerar um comando. O microsserviço transmite os dados extraídos dos formulários pa_forms para o modelo prompt_model para gerar um comando. Em seguida, transmite o comando gerado ao modelo ur_model para receber a recomendação de um registo.

  • MDIs/CEs ajustados para a área médica do Vertex AI: o Vertex AI tem uma variedade de modelos de base de IA generativa que podem ser ajustados para reduzir o custo e a latência. Os modelos usados nesta arquitetura são os seguintes:

    • prompt_model: um adaptador no GML otimizado para gerar comandos com base nos dados extraídos do pa_forms.
    • ur_model: um adaptador no GML otimizado para gerar uma recomendação de rascunho com base no comando de entrada.

  • ur_search_app: uma aplicação de pesquisa criada com aplicações de IA para encontrar informações personalizadas e relevantes para os especialistas de RU a partir de documentos clínicos, políticas de UM e diretrizes de cobertura.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos Google Cloud :

  • Vertex AI: uma plataforma de ML que lhe permite preparar e implementar modelos de ML e aplicações de IA, bem como personalizar MDIs/CE para utilização em aplicações com tecnologia de IA.
  • Aplicações de IA: uma plataforma que permite aos programadores criar e implementar agentes e aplicações com tecnologia de IA de nível empresarial.
  • Document AI: uma plataforma de processamento de documentos que recebe dados não estruturados de documentos e os transforma em dados estruturados.
  • Firestore: uma base de dados de documentos NoSQL criada para escala automática, elevado desempenho e facilidade de programação de aplicações.
  • Cloud Run: uma plataforma de computação sem servidor que lhe permite executar contentores diretamente na infraestrutura escalável da Google.
  • Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
  • Cloud Logging: um sistema de gestão de registos em tempo real com armazenamento, pesquisa, análise e alertas.
  • Cloud Monitoring: um serviço que oferece visibilidade do desempenho, da disponibilidade e do estado das suas aplicações e infraestrutura.

Exemplo de utilização

A UM é um processo usado pelas seguradoras de saúde principalmente nos Estados Unidos, mas processos semelhantes (com algumas modificações) são usados a nível global no mercado de seguros de saúde. O objetivo da UM é ajudar a garantir que os pacientes recebem os cuidados adequados no ambiente correto, no momento ideal e ao custo mais baixo possível. A UM também ajuda a garantir que os cuidados médicos são eficazes, eficientes e estão em conformidade com as normas de cuidados baseadas em evidências. A PA é uma ferramenta de UM que requer a aprovação da seguradora antes de um paciente receber cuidados médicos.

O processo de UM que muitas empresas usam é um obstáculo à prestação e à receção de cuidados atempados. É dispendioso, demorado e excessivamente administrativo. Também é complexo, manual e lento. Este processo afeta significativamente a capacidade do plano de saúde de gerir eficazmente a qualidade dos cuidados e melhorar a experiência do fornecedor e do membro. No entanto, se estas empresas modificassem o respetivo processo de UM, poderiam ajudar a garantir que os pacientes recebem um tratamento rentável e de alta qualidade. Ao otimizar o respetivo processo de UR, os planos de saúde podem reduzir os custos e as recusas através do processamento rápido de pedidos de AP, o que, por sua vez, pode melhorar a experiência dos pacientes e dos prestadores. Esta abordagem ajuda a reduzir a carga administrativa dos prestadores de cuidados de saúde.

Quando os planos de saúde recebem pedidos de PA, os gestores de casos de PA criam casos no sistema de gestão de casos para monitorizar, gerir e processar os pedidos. Recebemos um número significativo destas solicitações por fax e correio, com documentos clínicos anexados. No entanto, as informações nestes formulários e documentos não são facilmente acessíveis às seguradoras de saúde para fins de estatísticas de dados e inteligência empresarial. O processo atual de introdução manual de informações destes documentos nos sistemas de gestão de registos é ineficiente, demorado e pode originar erros.

Ao automatizar o processo de carregamento de dados, os planos de saúde podem reduzir os custos, os erros de introdução de dados e o encargo administrativo sobre a equipa. A extração de informações valiosas dos formulários e documentos clínicos permite que as empresas de seguros de saúde acelerem o processo de UR.

Considerações de design

Esta secção fornece orientações para ajudar a usar esta arquitetura de referência para desenvolver uma ou mais arquiteturas que ajudem a cumprir os seus requisitos específicos de segurança, fiabilidade, eficiência operacional, custo e desempenho.

Segurança, privacidade e conformidade

Esta secção descreve os fatores que deve considerar quando usa esta arquitetura de referência para ajudar a conceber e criar uma arquitetura que lhe permita cumprir os seus requisitos de segurança, privacidade e conformidade.Google Cloud

Nos Estados Unidos, a Lei de Portabilidade e Responsabilidade dos Seguros de Saúde (conhecida como HIPAA, conforme alterada, incluindo pela Lei de Tecnologia da Informação de Saúde para Saúde Económica e Clínica – HITECH) exige a conformidade com a regra de segurança, a regra de privacidade e a regra de notificação de violação da HIPAA. O Google Cloud suporta a conformidade com a HIPAA, mas, em última análise, é responsável por avaliar a sua própria conformidade com a HIPAA. A conformidade com a HIPAA é uma responsabilidade partilhada entre si e a Google. Se a sua organização estiver sujeita à HIPAA e quiser usar quaisquer produtos relacionados com Informações de saúde protegidas (PHI), tem de rever e aceitar o Contrato de Associado Comercial (BAA) da Google. Google CloudOs produtos Google abrangidos pelo BAA cumprem os requisitos da HIPAA e estão alinhados com as nossas certificações ISO/IEC 27001, 27017 e 27018 e o relatório SOC 2.

Nem todos os MDIs alojados no Vertex AI Model Garden são compatíveis com a HIPAA. Avalie e use os MDIs que suportam a HIPAA.

Para avaliar como os produtos da Google podem satisfazer as suas necessidades de conformidade com a HIPAA, pode consultar os relatórios de auditoria de terceiros no centro de recursos de conformidade.

Recomendamos que os clientes considerem o seguinte ao selecionar exemplos de utilização de IA e que criem com estas considerações em mente:

Os produtos Google seguem os princípios da IA responsável.

Para ver princípios e recomendações de segurança específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: segurança no Well-Architected Framework.

Fiabilidade

Esta secção descreve os fatores de design que deve considerar para criar e operar uma infraestrutura fiável para automatizar o processamento de pedidos de PA.

O Document AI form_processors é um serviço regional. Os dados são armazenados de forma síncrona em várias zonas numa região. O tráfego é automaticamente balanceado por carga nas zonas. Se ocorrer uma interrupção de uma zona, os dados não são perdidos1. Se ocorrer uma indisponibilidade regional, o serviço fica indisponível até a Google resolver a indisponibilidade.

Pode criar contentores do Cloud Storage numa de três localizações: regional, de região dupla ou multirregional, através de contentores pa_forms_bkt, training_forms, eval_forms, tuning_dataset, eval_dataset, clinical_docs ou um_policies. Os dados armazenados em contentores regionais são replicados de forma síncrona em várias zonas numa região. Para uma maior disponibilidade, pode usar contentores de duas regiões ou multirregionais, onde os dados são replicados de forma assíncrona entre regiões.

No Firestore, as informações extraídas da base de dados pa_form_collection podem estar localizadas em vários centros de dados para ajudar a garantir a escalabilidade e a fiabilidade globais.

Os serviços do Cloud Run, ingestion_service,hitl_app e ur_app, são serviços regionais. Os dados são armazenados de forma síncrona em várias zonas numa região. O tráfego é automaticamente equilibrado entre as zonas. Se ocorrer uma indisponibilidade de zona, as tarefas do Cloud Run continuam a ser executadas e os dados não são perdidos. Se ocorrer uma indisponibilidade de uma região, as tarefas do Cloud Run param de ser executadas até que a Google resolva a indisponibilidade. As tarefas ou os trabalhos individuais do Cloud Run podem falhar. Para processar essas falhas, pode usar novas tentativas de tarefas e a criação de pontos de verificação. Para mais informações, consulte o artigo Práticas recomendadas para novas tentativas e pontos de verificação de tarefas. O artigo Dicas gerais de desenvolvimento do Cloud Run descreve algumas práticas recomendadas para usar o Cloud Run.

O Vertex AI é uma plataforma de aprendizagem automática abrangente e fácil de usar que oferece um ambiente unificado para o ciclo de vida da aprendizagem automática, desde a preparação de dados à implementação e monitorização de modelos.

Para ver princípios e recomendações de fiabilidade específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: fiabilidade no Well-Architected Framework.

Otimização de custos

Esta secção fornece orientações para otimizar o custo de criação e execução de uma arquitetura para automatizar o processamento de pedidos de PA e melhorar os processos de UR. A gestão cuidadosa da utilização de recursos e a seleção dos níveis de serviço adequados podem ter um impacto significativo no custo geral.

Classes de armazenamento do Cloud Storage: Use as diferentes classes de armazenamento (Standard, Nearline, Coldline ou Archive) com base na frequência de acesso aos dados. O Nearline, o Coldline e o Archive são mais rentáveis para dados acedidos com menor frequência.

Políticas de ciclo de vida do Cloud Storage: implemente políticas de ciclo de vida para fazer a transição automática dos objetos para classes de armazenamento de custo inferior ou eliminá-los com base na idade e nos padrões de acesso.

O Document AI tem um preço baseado no número de processadores implementados e no número de páginas processadas pelos processadores do Document AI. Considere o seguinte:

  • Otimização do processador: analise os padrões de carga de trabalho para determinar o número ideal de processadores do Document AI a implementar. Evite o aprovisionamento excessivo de recursos.
  • Gestão do volume de páginas: o pré-processamento de documentos para remover páginas desnecessárias ou otimizar a resolução pode ajudar a reduzir os custos de processamento.

O Firestore tem um preço baseado na atividade relacionada com documentos, entradas de índice, armazenamento que a base de dados usa e a quantidade de largura de banda da rede. Considere o seguinte:

  • Modelagem de dados: crie o seu modelo de dados para minimizar o número de entradas de índice e otimizar os padrões de consulta para maior eficiência.
  • Largura de banda da rede: monitorize e otimize a utilização da rede para evitar cobranças excessivas. Considere colocar em cache os dados acedidos com frequência.

As cobranças do Cloud Run são calculadas com base na utilização da CPU a pedido, na memória e no número de pedidos. Pense cuidadosamente na atribuição de recursos. Atribua recursos de CPU e memória com base nas caraterísticas da carga de trabalho. Use a criação de escala automática para ajustar os recursos dinamicamente com base na procura.

Vertex AI Normalmente, os MDIs/CEs são cobrados com base na entrada e saída do texto ou multimédia. As contagens de tokens de entrada e saída afetam diretamente os custos dos MDIs. Otimizar os comandos e a geração de respostas para eficiência.

Os custos do motor de pesquisa das aplicações de IA dependem das funcionalidades que usa. Para ajudar a gerir os seus custos, pode escolher entre as seguintes três opções:

  • Pesquisa Standard Edition, que oferece capacidades de pesquisa não estruturada.
  • Search Enterprise Edition, que oferece funcionalidades de pesquisa não estruturada e de pesquisa de websites.
  • Suplemento de MDIs de pesquisa, que oferece capacidades de resumo e pesquisa com várias interações.

Também pode considerar as seguintes considerações adicionais para ajudar a otimizar os custos:

  • Monitorização e alertas: configure o Cloud Monitoring e os alertas de faturação para acompanhar os custos e receber notificações quando a utilização exceder os limites.
  • Relatórios de custos: reveja regularmente os relatórios de custos na Google Cloud consola para identificar tendências e otimizar a utilização de recursos.
  • Considere os descontos de fidelidade: se tiver cargas de trabalho previsíveis, considere comprometer-se a usar esses recursos durante um período especificado para obter preços com desconto.

Considerar cuidadosamente estes fatores e implementar as estratégias recomendadas pode ajudar a gerir e otimizar eficazmente o custo de execução da sua arquitetura de automatização de PA e UR no Google Cloud.

Para ver princípios e recomendações de otimização de custos específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: otimização de custos no Well-Architected Framework.

Implementação

O código de implementação de referência para esta arquitetura está disponível sob licenças de código aberto. A arquitetura que este código implementa é um protótipo e pode não incluir todas as funcionalidades e o reforço de segurança de que precisa para uma implementação de produção. Para implementar e expandir esta arquitetura de referência de forma a cumprir mais rigorosamente os seus requisitos, recomendamos que contacte a consultoria do Google Cloud.

O código inicial desta arquitetura de referência está disponível nos seguintes repositórios git:

  • Repositório git da CDA: Este repositório contém scripts de implementação do Terraform para o aprovisionamento de infraestrutura e a implementação de código de aplicação.
  • Repositório Git do serviço UR: Este repositório contém exemplos de código para o serviço UR.

Pode escolher uma das seguintes duas opções para implementar apoio técnico e serviços para esta arquitetura de referência:

O que se segue?

Colaboradores

Autor: Dharmesh Patel | Industry Solutions Architect, Healthcare

Outros colaboradores:

  1. Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.  ↩