Processamento inteligente de documentos com serviços AWS AI e Analytics no setor de seguros: Parte 2

In Parte 1 desta série, discutimos o processamento inteligente de documentos (IDP) e como o IDP pode acelerar os casos de uso de processamento de sinistros no setor de seguros. Discutimos como podemos usar os serviços de IA da AWS para categorizar com precisão documentos de reivindicações junto com documentos de suporte. Também discutimos como extrair vários tipos de documentos em um pacote de sinistros de seguros, como formulários, tabelas ou documentos especializados, como faturas, recibos ou documentos de identificação. Analisamos os desafios nos processos de documentos legados, que são demorados, propensos a erros, caros e difíceis de processar em escala, e como você pode usar os serviços de IA da AWS para ajudar a implementar seu pipeline de IDP.

Nesta postagem, orientamos você pelos recursos avançados de IDP para extração, consulta e enriquecimento de documentos. Também analisamos como usar ainda mais as informações estruturadas extraídas dos dados de sinistros para obter insights usando o AWS Analytics e os serviços de visualização. Destacamos como os dados estruturados extraídos do IDP podem ajudar contra reclamações fraudulentas usando os serviços do AWS Analytics.

Visão geral da solução

O diagrama a seguir ilustra as fases do IDP usando os serviços de IA da AWS. Na Parte 1, discutimos as três primeiras fases do fluxo de trabalho do IDP. Neste post, expandimos a etapa de extração e as fases restantes, que incluem a integração do IDP com os serviços do AWS Analytics.

Usamos esses serviços de análise para obter mais informações e visualizações e para detectar reivindicações fraudulentas usando dados estruturados e normalizados do IDP. O diagrama a seguir ilustra a arquitetura da solução.

As fases que discutimos neste post usam os seguintes serviços principais:

• Amazon Comprehend Medical é um serviço de processamento de linguagem natural (NLP) elegível para HIPAA que usa modelos de aprendizado de máquina (ML) que foram pré-treinados para entender e extrair dados de saúde de texto médico, como prescrições, procedimentos ou diagnósticos.
• Cola AWS faz parte da pilha de serviços do AWS Analytics e é um serviço de integração de dados sem servidor que facilita a descoberta, preparação e combinação de dados para análise, ML e desenvolvimento de aplicativos.
• Amazon RedShift é outro serviço na pilha do Analytics. O Amazon Redshift é um serviço de data warehouse em escala de petabytes totalmente gerenciado na nuvem.

Pré-requisitos

Antes de começar, consulte Parte 1 para obter uma visão geral de alto nível do caso de uso de seguro com IDP e detalhes sobre os estágios de captura e classificação de dados.

Para obter mais informações sobre os exemplos de código, consulte nosso Repo do GitHub.

Fase de extração

Na Parte 1, vimos como usar as APIs do Amazon Textract para extrair informações como formulários e tabelas de documentos e como analisar faturas e documentos de identidade. Nesta postagem, aprimoramos a fase de extração com o Amazon Comprehend para extrair entidades padrão e personalizadas específicas para casos de uso personalizados.

As operadoras de seguros geralmente se deparam com textos densos em solicitações de sinistros de seguros, como a carta de resumo de alta de um paciente (veja a imagem de exemplo a seguir). Pode ser difícil extrair informações automaticamente de tais tipos de documentos onde não há uma estrutura definida. Para resolver isso, podemos usar os seguintes métodos para extrair informações comerciais importantes do documento:

Extraia entidades padrão com a API Amazon Comprehend DetectEntities

Executamos o seguinte código no documento de transcrição médica de amostra:

comprehend = boto3.client('comprehend') 

response = comprehend.detect_entities( Text=text, LanguageCode='en')

#print enitities from the response JSON

for entity in response['Entities']:
    print(f'{entity["Type"]} : {entity["Text"]}')

A captura de tela a seguir mostra uma coleção de entidades identificadas no texto de entrada. A saída foi encurtada para os propósitos deste post. Consulte o GitHub repo para uma lista detalhada de entidades.

Extraia entidades personalizadas com o reconhecimento de entidades personalizadas do Amazon Comprehend

A resposta do DetectEntities A API inclui as entidades padrão. No entanto, estamos interessados ​​em conhecer valores de entidade específicos, como o nome do paciente (indicado pela entidade padrão PERSON), ou o ID do paciente (indicado pela entidade padrão OTHER). Para reconhecer essas entidades personalizadas, treinamos um modelo de reconhecedor de entidade personalizada do Amazon Comprehend. Recomendamos seguir as etapas abrangentes sobre como treinar e implantar um modelo de reconhecimento de entidade personalizado no Repo do GitHub.

Depois de implantar o modelo personalizado, podemos usar a função auxiliar get_entities() para recuperar entidades personalizadas como PATIENT_NAME e PATIENT_D da resposta da API:

def get_entities(text):
try:
    #detect entities
    entities_custom = comprehend.detect_entities(LanguageCode="en",
                      Text=text, EndpointArn=ER_ENDPOINT_ARN) 
    df_custom = pd.DataFrame(entities_custom["Entities"], columns = ['Text',  
                'Type', 'Score'])
    df_custom = df_custom.drop_duplicates(subset=['Text']).reset_index()
    return df_custom
except Exception as e:
    print(e)

# call the get_entities() function 
response = get_entities(text) 
#print the response from the get_entities() function
print(response)

A imagem a seguir mostra nossos resultados.

Fase de enriquecimento

Na fase de enriquecimento de documentos, realizamos funções de enriquecimento em documentos relacionados à saúde para obter insights valiosos. Analisamos os seguintes tipos de enriquecimento:

• Extrair idioma específico do domínio – Usamos o Amazon Comprehend Medical para extrair ontologias médicas específicas, como ICD-10-CM, RxNorm e SNOMED CT
• Redigir informações confidenciais – Usamos o Amazon Comprehend para redigir informações de identificação pessoal (PII) e o Amazon Comprehend Medical para redigir informações de saúde protegidas (PHI)

Extraia informações médicas de texto médico não estruturado

Documentos como notas de provedores médicos e relatórios de ensaios clínicos incluem texto médico denso. Os portadores de sinistros de seguros precisam identificar as relações entre as informações de saúde extraídas desse texto denso e vinculá-las a ontologias médicas como os códigos ICD-10-CM, RxNorm e SNOMED CT. Isso é muito valioso para automatizar os fluxos de trabalho de captura, validação e aprovação de sinistros para que as seguradoras acelerem e simplifiquem o processamento de sinistros. Vejamos como podemos usar o Amazon Comprehend Medical InferICD10CM API para detectar possíveis condições médicas como entidades e vinculá-las aos seus códigos:

cm_json_data = comprehend_med.infer_icd10_cm(Text=text)

print("nMedical codingn========")

for entity in cm_json_data["Entities"]:
      for icd in entity["ICD10CMConcepts"]:
           description = icd['Description']
           code = icd["Code"]
           print(f'{description}: {code}')

Para o texto de entrada, que podemos passar do Amazon Textract DetectDocumentText API, o InferICD10CM A API retorna a seguinte saída (a saída foi abreviada para abreviar).

Da mesma forma, podemos usar o Amazon Comprehend Medical InferRxNorm API para identificar medicamentos e o InferSNOMEDCT API para detectar entidades médicas em documentos de seguro relacionados à saúde.

Realize a redação de PII e PHI

Os pacotes de sinistros de seguro exigem muita conformidade e regulamentos de privacidade porque contêm dados PII e PHI. As operadoras de seguros podem reduzir o risco de conformidade redigindo informações como números de apólices ou o nome do paciente.

Vejamos um exemplo de resumo de alta de um paciente. Usamos o Amazon Comprehend DetectPiiEntities API para detectar entidades PII dentro do documento e proteger a privacidade do paciente redigindo estas entidades:

resp = call_textract(input_document = f's3://{data_bucket}/idp/textract/dr-note-sample.png')
text = get_string(textract_json=resp, output_type=[Textract_Pretty_Print.LINES])

# call Amazon Comprehend Detect PII Entities API
entity_resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en") 

pii = []
for entity in entity_resp['Entities']:
      pii_entity={}
      pii_entity['Type'] = entity['Type']
      pii_entity['Text'] = text[entity['BeginOffset']:entity['EndOffset']]
      pii.append(pii_entity)
print(pii)

Obtemos as seguintes entidades PII na resposta do detect_pii_entities() API:

Podemos então redigir as entidades PII que foram detectadas nos documentos utilizando a geometria da caixa delimitadora das entidades do documento. Para isso, utilizamos uma ferramenta auxiliar chamada amazon-textract-overlayer. Para obter mais informações, consulte Sobreposição de texto. As capturas de tela a seguir comparam um documento antes e depois da redação.

Semelhante ao Amazon Comprehend DetectPiiEntities API, também podemos usar a DetectPHI API para detectar dados de PHI no texto clínico que está sendo examinado. Para obter mais informações, consulte Detectar PHI.

Fase de revisão e validação

Na fase de revisão e validação de documentos, agora podemos verificar se o pacote de sinistro atende aos requisitos do negócio, pois temos todas as informações coletadas dos documentos no pacote das etapas anteriores. Podemos fazer isso introduzindo um humano no loop que pode revisar e validar todos os campos ou apenas um processo de aprovação automática para declarações de baixo valor antes de enviar o pacote para aplicativos downstream. Podemos usar IA aumentada da Amazon (Amazon A2I) para automatizar o processo de revisão humana para o processamento de sinistros de seguros.

Agora que todos os dados necessários foram extraídos e normalizados do processamento de declarações usando serviços de IA para IDP, podemos estender a solução para integração com serviços do AWS Analytics, como AWS Glue e Amazon Redshift, para resolver casos de uso adicionais e fornecer análises e visualizações adicionais.

Detectar sinistros de seguro fraudulentos

Neste post, implementamos uma arquitetura serverless onde os dados extraídos e processados ​​são armazenados em um data lake e são usados ​​para detectar sinistros de seguros fraudulentos usando ML. Nós usamos Serviço de armazenamento simples da Amazon (Amazon S3) para armazenar os dados processados. Podemos então usar Cola AWS or Amazon EMR para limpar os dados e adicionar campos adicionais para torná-los consumíveis para relatórios e ML. Depois disso, usamos Amazon RedshiftML para construir um modelo de ML de detecção de fraude. Por fim, criamos relatórios usando AmazonQuickSight para obter insights sobre os dados.

Configurar o esquema externo do Amazon Redshift

Para este exemplo, criamos um amostra de conjunto de dados o emula a saída de um processo ETL (extrair, transformar e carregar) e usa o Catálogo de dados do AWS Glue como o catálogo de metadados. Primeiro, criamos um banco de dados chamado idp_demo no Data Catalog e um esquema externo no Amazon Redshift chamado idp_insurance_demo (veja o código a seguir). Usamos um Gerenciamento de acesso e identidade da AWS (IAM) para conceder permissões ao cluster do Amazon Redshift para acessar o Amazon S3 e Amazon Sage Maker. Para obter mais informações sobre como configurar essa função do IAM com privilégio mínimo, consulte Agrupe e defina a configuração para administração do Amazon Redshift ML.

CREATE EXTERNAL SCHEMA idp_insurance_demo
FROM DATA CATALOG
DATABASE 'idp_demo' 
IAM_ROLE '<<>>'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Criar tabela externa do Amazon Redshift

A próxima etapa é criar uma tabela externa no Amazon Redshift referenciando o local do S3 onde o arquivo está localizado. Nesse caso, nosso arquivo é um arquivo de texto separado por vírgulas. Também queremos pular a linha de cabeçalho do arquivo, que pode ser configurada na seção de propriedades da tabela. Veja o seguinte código:

create external table idp_insurance_demo.claims(id INTEGER,
date_of_service date,
patients_address_city VARCHAR,
patients_address_state VARCHAR,
patients_address_zip VARCHAR,
patient_status VARCHAR,
insured_address_state VARCHAR,
insured_address_zip VARCHAR,
insured_date_of_birth date,
insurance_plan_name VARCHAR,
total_charges DECIMAL(14,4),
fraud VARCHAR,
duplicate varchar,
invalid_claim VARCHAR
)
row format delimited
fields terminated by ','
stored as textfile
location '<<>>'
table properties ( 'skip.header.line.count'='1');

Criar conjuntos de dados de treinamento e teste

Depois de criar a tabela externa, preparamos nosso conjunto de dados para ML dividindo-o em conjunto de treinamento e conjunto de teste. Criamos uma nova tabela externa chamada claim_train, que consiste em todos os registros com ID <= 85000 da tabela de declarações. Este é o conjunto de treinamento no qual treinamos nosso modelo de ML.

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_train
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/train'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id <= 850000

Criamos outra tabela externa chamada claim_test que consiste em todos os registros com ID >85000 para ser o conjunto de teste no qual testamos o modelo de ML:

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_test
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/test'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id > 850000

Crie um modelo de ML com o Amazon Redshift ML

Agora criamos o modelo usando o CRIAR MODELO comando (veja o código a seguir). Selecionamos as colunas relevantes do claims_train tabela que pode determinar uma transação fraudulenta. O objetivo deste modelo é prever o valor do fraud coluna; Portanto, fraud é adicionado como o destino de previsão. Depois que o modelo é treinado, ele cria uma função chamada insurance_fraud_model. Esta função é usada para inferência durante a execução de instruções SQL para prever o valor da fraud coluna para novos registros.

CREATE MODEL idp_insurance_demo.insurance_fraud_model
FROM (SELECT 
total_charges ,
fraud ,
duplicate,
invalid_claim
FROM idp_insurance_demo.claims_train
)
TARGET fraud
FUNCTION insurance_fraud_model
IAM_ROLE '<<>>'
SETTINGS (
S3_BUCKET '<<>>'
);

Avalie as métricas do modelo de ML

Depois de criarmos o modelo, podemos executar consultas para verificar a precisão do modelo. Nós usamos o insurance_fraud_model função para prever o valor do fraud coluna para novos registros. Execute a seguinte consulta no claims_test table para criar uma matriz de confusão:

SELECT 
fraud,
idp_insurance_demo.insurance_fraud_model (total_charges ,duplicate,invalid_claim ) as fraud_calculcated,
count(1)
FROM idp_insurance_demo.claims_test
GROUP BY fraud , fraud_calculcated;

Detecte fraudes usando o modelo de ML

Depois de criarmos o novo modelo, à medida que novos dados de sinistros são inseridos no data warehouse ou data lake, podemos usar o insurance_fraud_model função para calcular as transações fraudulentas. Fazemos isso primeiro carregando os novos dados em uma tabela temporária. Então usamos o insurance_fraud_model função para calcular o fraud sinalizador para cada nova transação e insira os dados junto com o sinalizador na tabela final, que neste caso é a claims tabela.

Visualize os dados de sinistros

Quando os dados estão disponíveis no Amazon Redshift, podemos criar visualizações usando o QuickSight. Podemos então compartilhar os painéis do QuickSight com analistas e usuários de negócios. Para criar o painel do QuickSight, primeiro você precisa criar um conjunto de dados do Amazon Redshift no QuickSight. Para obter instruções, consulte Criando um conjunto de dados a partir de um banco de dados.

Depois de criar o conjunto de dados, você pode criar uma nova análise no QuickSight usando o conjunto de dados. Veja a seguir alguns exemplos de relatórios que criamos:

• Número total de reclamações por estado, agrupadas por fraud campo – Este gráfico nos mostra a proporção de transações fraudulentas em relação ao número total de transações em um determinado estado.
• Soma do valor total em dólares dos sinistros, agrupados pelo fraud campo – Este gráfico nos mostra a proporção do valor em dólares de transações fraudulentas em comparação com o valor total de transações em dólares em um determinado estado.
• Número total de operações por seguradora, agrupadas por fraud campo – Este gráfico mostra quantos sinistros foram feitos para cada seguradora e quantos deles são fraudulentos.

• Soma total de transações fraudulentas por estado exibidas em um mapa dos EUA – Este gráfico mostra apenas as transações fraudulentas e exibe o total de cobranças dessas transações por estado no mapa. O tom mais escuro de azul indica cargas totais mais altas. Podemos analisar ainda mais isso por cidade dentro desse estado e CEPs com a cidade para entender melhor as tendências.

limpar

Para evitar cobranças futuras em sua conta da AWS, exclua os recursos que você provisionou na configuração seguindo as instruções no Seção de limpeza em nosso repositório.

Conclusão

Nesta série de duas partes, vimos como criar um pipeline de IDP de ponta a ponta com pouca ou nenhuma experiência em ML. Exploramos um caso de uso de processamento de sinistros no setor de seguros e como o IDP pode ajudar a automatizar esse caso de uso usando serviços como Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical e Amazon A2I. Na Parte 1, demonstramos como usar os serviços de IA da AWS para extração de documentos. Na Parte 2, estendemos a fase de extração e realizamos o enriquecimento de dados. Por fim, estendemos os dados estruturados extraídos do IDP para análises adicionais e criamos visualizações para detectar declarações fraudulentas usando os serviços do AWS Analytics.

Recomendamos revisar as seções de segurança do amazontext, Amazon Comprehend e Amazônia A2I documentação e seguindo as orientações fornecidas. Para saber mais sobre os preços da solução, consulte os detalhes de preços de amazontext, Amazon Comprehend e Amazônia A2I.

Sobre os autores

Chinmayee Rane é arquiteto de soluções especialista em IA/ML na Amazon Web Services. Ela é apaixonada por matemática aplicada e aprendizado de máquina. Ela se concentra em projetar soluções inteligentes de processamento de documentos para clientes da AWS. Fora do trabalho, ela gosta de dançar salsa e bachata.

Uday Narayanan é um arquiteto de soluções especialista em análise na AWS. Ele gosta de ajudar os clientes a encontrar soluções inovadoras para desafios de negócios complexos. Suas principais áreas de foco são análise de dados, sistemas de big data e aprendizado de máquina. Em seu tempo livre, ele gosta de praticar esportes, assistir a programas de TV e viajar.

Sonali Sahu está liderando a equipe do Intelligent Document Processing AI/ML Solutions Architect na Amazon Web Services. Ela é uma tecnófila apaixonada e gosta de trabalhar com clientes para resolver problemas complexos usando inovação. Sua principal área de foco é inteligência artificial e aprendizado de máquina para processamento inteligente de documentos.