Elaborazione intelligente dei documenti con i servizi di analisi e intelligenza artificiale di AWS nel settore assicurativo: parte 2

In Parte 1 di questa serie, abbiamo discusso dell'elaborazione intelligente dei documenti (IDP) e di come IDP può accelerare i casi d'uso dell'elaborazione dei sinistri nel settore assicurativo. Abbiamo discusso di come utilizzare i servizi di intelligenza artificiale di AWS per classificare accuratamente i documenti di reclamo insieme ai documenti di supporto. Abbiamo anche discusso di come estrarre vari tipi di documenti in un pacchetto di indennizzi assicurativi, come moduli, tabelle o documenti specializzati come fatture, ricevute o documenti di identità. Abbiamo esaminato le sfide nei processi dei documenti legacy, che richiedono tempo, sono soggetti a errori, sono costosi e difficili da elaborare su larga scala, e come puoi utilizzare i servizi di intelligenza artificiale di AWS per implementare la tua pipeline IDP.

In questo post, ti guideremo attraverso le funzionalità IDP avanzate per l'estrazione, l'interrogazione e l'arricchimento dei documenti. Esaminiamo anche come utilizzare ulteriormente le informazioni strutturate estratte dai dati dei reclami per ottenere informazioni dettagliate utilizzando AWS Analytics e i servizi di visualizzazione. Evidenziamo come i dati strutturati estratti da IDP possono aiutare contro reclami fraudolenti utilizzando i servizi di AWS Analytics.

Panoramica della soluzione

Il diagramma seguente illustra le fasi se l'IDP utilizza i servizi di intelligenza artificiale di AWS. Nella parte 1, abbiamo discusso le prime tre fasi del flusso di lavoro IDP. In questo post, espandiamo la fase di estrazione e le fasi rimanenti, che includono l'integrazione di IDP con i servizi di AWS Analytics.

Utilizziamo questi servizi di analisi per ulteriori approfondimenti e visualizzazioni e per rilevare reclami fraudolenti utilizzando dati strutturati e normalizzati di IDP. Il diagramma seguente illustra l'architettura della soluzione.

Le fasi di cui discutiamo in questo post utilizzano i seguenti servizi chiave:

• Amazon comprende medica è un servizio di elaborazione del linguaggio naturale (NLP) idoneo all'HIPAA che utilizza modelli di apprendimento automatico (ML) che sono stati pre-addestrati per comprendere ed estrarre dati sanitari dal testo medico, come prescrizioni, procedure o diagnosi.
• Colla AWS fa parte dello stack dei servizi di AWS Analytics ed è un servizio di integrazione dei dati serverless che semplifica l'individuazione, la preparazione e la combinazione dei dati per l'analisi, il machine learning e lo sviluppo di applicazioni.
• Amazon RedShift è un altro servizio nello stack di Analytics. Amazon Redshift è un servizio di data warehouse su scala petabyte completamente gestito nel cloud.

Prerequisiti

Prima di iniziare, fare riferimento a Parte 1 per una panoramica di alto livello del caso d'uso assicurativo con IDP e dettagli sulle fasi di acquisizione e classificazione dei dati.

Per maggiori informazioni sui campioni di codice, fare riferimento al ns Repository GitHub.

Fase di estrazione

Nella parte 1, abbiamo visto come utilizzare le API di Amazon Textract per estrarre informazioni come moduli e tabelle dai documenti e come analizzare fatture e documenti di identità. In questo post, miglioriamo la fase di estrazione con Amazon Comprehend per estrarre entità predefinite e personalizzate specifiche per casi d'uso personalizzati.

Le compagnie assicurative spesso trovano testo denso nelle domande di risarcimento assicurativo, come la lettera riepilogativa di dimissione di un paziente (vedere l'immagine di esempio seguente). Può essere difficile estrarre automaticamente informazioni da tali tipi di documenti in cui non esiste una struttura definita. Per risolvere questo problema, possiamo utilizzare i seguenti metodi per estrarre le informazioni aziendali chiave dal documento:

Estrai le entità predefinite con l'API Amazon Comprehend DetectEntities

Eseguiamo il codice seguente sul documento di trascrizione medica di esempio:

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"]}')

La schermata seguente mostra una raccolta di entità identificate nel testo di input. L'output è stato abbreviato ai fini di questo post. Fare riferimento al Repository GitHub per un elenco dettagliato delle entità.

Estrai entità personalizzate con Amazon Comprehend riconoscimento entità personalizzate

La risposta del DetectEntities L'API include le entità predefinite. Tuttavia, siamo interessati a conoscere valori di entità specifici, come il nome del paziente (indicato dall'entità predefinita PERSON) o l'ID del paziente (indicato dall'entità predefinita OTHER). Per riconoscere queste entità personalizzate, formiamo un modello di riconoscimento di entità personalizzato Amazon Comprehend. Ti consigliamo di seguire i passaggi completi su come addestrare e distribuire un modello di riconoscimento delle entità personalizzato in Repository GitHub.

Dopo aver distribuito il modello personalizzato, possiamo utilizzare la funzione di supporto get_entities() per recuperare entità personalizzate come PATIENT_NAME ed PATIENT_D dalla risposta dell'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)

Lo screenshot seguente mostra i nostri risultati.

Fase di arricchimento

Nella fase di arricchimento documentale, eseguiamo funzioni di arricchimento su documenti sanitari per trarre preziose informazioni. Esaminiamo i seguenti tipi di arricchimento:

• Estrai la lingua specifica del dominio – Usiamo Amazon Comprehend Medical per estrarre ontologie mediche specifiche come ICD-10-CM, RxNorm e SNOMED CT
• Redigere le informazioni sensibili – Usiamo Amazon Comprehend per oscurare le informazioni di identificazione personale (PII) e Amazon Comprehend Medical per la redazione di informazioni sanitarie protette (PHI)

Estrarre informazioni mediche da testi medici non strutturati

Documenti come le note dei fornitori di servizi sanitari e i rapporti sugli studi clinici includono un fitto testo medico. Le compagnie assicurative devono identificare le relazioni tra le informazioni sanitarie estratte da questo denso testo e collegarle a ontologie mediche come i codici ICD-10-CM, RxNorm e SNOMED CT. Questo è molto prezioso per automatizzare i flussi di lavoro di acquisizione, convalida e approvazione dei sinistri per le compagnie assicurative per accelerare e semplificare l'elaborazione dei sinistri. Diamo un'occhiata a come possiamo utilizzare Amazon Comprehend Medical InferICD10CM API per rilevare possibili condizioni mediche come entità e collegarle ai loro codici:

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}')

Per il testo di input, che possiamo trasmettere da Amazon Texttract DetectDocumentText API, il InferICD10CM API restituisce il seguente output (l'output è stato abbreviato per brevità).

Allo stesso modo, possiamo utilizzare Amazon Comprehend Medical InferRxNorm API per identificare i farmaci e il InferSNOMEDCT API per rilevare le entità mediche all'interno di documenti assicurativi relativi all'assistenza sanitaria.

Eseguire la redazione di PII e PHI

I pacchetti di indennizzi assicurativi richiedono molta conformità e normative sulla privacy perché contengono sia dati PII che PHI. Le compagnie assicurative possono ridurre il rischio di conformità oscurando informazioni come i numeri di polizza o il nome del paziente.

Diamo un'occhiata a un esempio di riepilogo delle dimissioni di un paziente. Usiamo Amazon Comprehend DetectPiiEntities API per rilevare le entità PII all'interno del documento e proteggere la privacy del paziente oscurando queste entità:

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)

Otteniamo le seguenti entità PII nella risposta da detect_pii_entities() API:

Possiamo quindi redigere le entità PII che sono state rilevate dai documenti utilizzando la geometria del riquadro di delimitazione delle entità dal documento. Per questo, utilizziamo uno strumento di supporto chiamato amazon-textract-overlayer. Per ulteriori informazioni, fare riferimento a Sovrapposizione di testo. Le schermate seguenti confrontano un documento prima e dopo la redazione.

Simile ad Amazon Comprensione DetectPiiEntities API, possiamo anche utilizzare il DetectPHI API per rilevare i dati PHI nel testo clinico in esame. Per ulteriori informazioni, fare riferimento a Rileva PHI.

Fase di revisione e validazione

Nella fase di revisione e convalida dei documenti, ora possiamo verificare se il pacchetto di richieste soddisfa i requisiti dell'azienda, perché disponiamo di tutte le informazioni raccolte dai documenti nel pacchetto delle fasi precedenti. Possiamo farlo introducendo un essere umano nel circuito in grado di rivedere e convalidare tutti i campi o semplicemente un processo di approvazione automatica per richieste di denaro a basso costo prima di inviare il pacchetto alle applicazioni a valle. Possiamo usare AI aumentata di Amazon (Amazon A2I) per automatizzare il processo di revisione umana per l'elaborazione dei reclami assicurativi.

Ora che disponiamo di tutti i dati richiesti estratti e normalizzati dall'elaborazione dei reclami utilizzando i servizi di intelligenza artificiale per IDP, possiamo estendere la soluzione per l'integrazione con i servizi di AWS Analytics come AWS Glue e Amazon Redshift per risolvere ulteriori casi d'uso e fornire ulteriori analisi e visualizzazioni.

Rileva richieste di risarcimento fraudolente

In questo post, implementiamo un'architettura serverless in cui i dati estratti ed elaborati vengono archiviati in un data lake e vengono utilizzati per rilevare sinistri assicurativi fraudolenti utilizzando il riciclaggio. Noi usiamo Servizio di archiviazione semplice Amazon (Amazon S3) per memorizzare i dati elaborati. Possiamo quindi utilizzare Colla AWS or Amazon EMR per ripulire i dati e aggiungere campi aggiuntivi per renderli utilizzabili per la creazione di report e ML. Dopo di che, usiamo Amazon RedshiftML per costruire un modello di rilevamento delle frodi ML. Infine, creiamo report utilizzando Amazon QuickSight per ottenere informazioni dettagliate sui dati.

Configura lo schema esterno Amazon Redshift

Ai fini di questo esempio, abbiamo creato un set di dati di esempio emula l'output di un processo ETL (estrazione, trasformazione e caricamento) e utilizza AWS Glue Data Catalog come catalogo di metadati. Innanzitutto, creiamo un database denominato idp_demo nel Catalogo dati e uno schema esterno in Amazon Redshift chiamato idp_insurance_demo (vedi codice seguente). Usiamo un Gestione dell'identità e dell'accesso di AWS (IAM) per concedere le autorizzazioni al cluster Amazon Redshift per accedere ad Amazon S3 e Amazon Sage Maker. Per ulteriori informazioni su come configurare questo ruolo IAM con il privilegio minimo, fare riferimento a Cluster e configurazione della configurazione per l'amministrazione di Amazon Redshift ML.

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

Crea una tabella esterna Amazon Redshift

Il passaggio successivo consiste nel creare una tabella esterna in Amazon Redshift che faccia riferimento alla posizione S3 in cui si trova il file. In questo caso, il nostro file è un file di testo separato da virgole. Vogliamo anche saltare la riga di intestazione del file, che può essere configurata nella sezione delle proprietà della tabella. Vedere il codice seguente:

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');

Crea set di dati di addestramento e test

Dopo aver creato la tabella esterna, prepariamo il nostro set di dati per ML suddividendolo in set di addestramento e set di test. Creiamo una nuova tabella esterna chiamata claim_train, che consiste in tutti i record con ID <= 85000 dalla tabella delle attestazioni. Questo è il set di allenamento su cui formiamo il nostro modello 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

Creiamo un'altra tabella esterna chiamata claim_test che consiste in tutti i record con ID >85000 come set di test su cui testiamo il modello 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

Crea un modello ML con Amazon Redshift ML

Ora creiamo il modello usando il CREA MODELLO comando (vedere il codice seguente). Selezioniamo le colonne pertinenti dal claims_train tabella che può determinare una transazione fraudolenta. L'obiettivo di questo modello è di prevedere il valore del fraud colonna; dunque, fraud viene aggiunto come obiettivo di previsione. Dopo che il modello è stato addestrato, crea una funzione denominata insurance_fraud_model. Questa funzione viene utilizzata per l'inferenza durante l'esecuzione di istruzioni SQL per prevedere il valore di fraud colonna per i nuovi record.

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 '<<>>'
);

Valuta le metriche del modello ML

Dopo aver creato il modello, possiamo eseguire query per verificare l'accuratezza del modello. Noi usiamo il insurance_fraud_model funzione per prevedere il valore di fraud colonna per i nuovi record. Eseguire la query seguente su claims_test tabella per creare una matrice di confusione:

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;

Rileva le frodi utilizzando il modello ML

Dopo aver creato il nuovo modello, poiché i nuovi dati sui reclami vengono inseriti nel data warehouse o nel data lake, possiamo utilizzare il insurance_fraud_model funzione per calcolare le transazioni fraudolente. Lo facciamo caricando prima i nuovi dati in una tabella temporanea. Quindi utilizziamo il insurance_fraud_model funzione per calcolare il fraud flag per ogni nuova transazione e inserisci i dati insieme al flag nel tavolo finale, che in questo caso è il claims tabella.

Visualizza i dati dei sinistri

Quando i dati sono disponibili in Amazon Redshift, possiamo creare visualizzazioni utilizzando QuickSight. Possiamo quindi condividere i dashboard di QuickSight con utenti aziendali e analisti. Per creare il dashboard QuickSight, devi prima creare un set di dati Amazon Redshift in QuickSight. Per istruzioni, fare riferimento a Creazione di un set di dati da un database.

Dopo aver creato il set di dati, puoi creare una nuova analisi in QuickSight utilizzando il set di dati. Di seguito sono riportati alcuni report di esempio che abbiamo creato:

• Numero totale di sinistri per stato, raggruppati per fraud campo – Questo grafico mostra la proporzione di transazioni fraudolente rispetto al numero totale di transazioni in un determinato stato.
• Somma del valore totale in dollari dei crediti, raggruppato per il fraud campo – Questo grafico mostra la proporzione dell'importo in dollari delle transazioni fraudolente rispetto all'importo totale in dollari delle transazioni in un particolare stato.
• Numero totale di transazioni per compagnia di assicurazione, raggruppate per fraud campo – Questo grafico mostra quante richieste di risarcimento sono state presentate per ciascuna compagnia di assicurazioni e quante di esse sono fraudolente.

• Somma totale delle transazioni fraudolente per stato visualizzata su una mappa degli Stati Uniti – Questo grafico mostra solo le transazioni fraudolente e mostra gli addebiti totali per tali transazioni per stato sulla mappa. La tonalità di blu più scura indica addebiti totali più elevati. Possiamo analizzarlo ulteriormente per città all'interno di quello stato e codici postali con la città per comprendere meglio le tendenze.

ripulire

Per evitare di incorrere in addebiti futuri sul tuo account AWS, elimina le risorse di cui hai eseguito il provisioning durante la configurazione seguendo le istruzioni nella Sezione pulizia nel nostro repository.

Conclusione

In questa serie in due parti, abbiamo visto come creare una pipeline IDP end-to-end con poca o nessuna esperienza di machine learning. Abbiamo esaminato un caso d'uso per l'elaborazione dei reclami nel settore assicurativo e come IDP può aiutare ad automatizzare questo caso d'uso utilizzando servizi come Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical e Amazon A2I. Nella parte 1, abbiamo dimostrato come utilizzare i servizi di intelligenza artificiale di AWS per l'estrazione di documenti. Nella parte 2, abbiamo esteso la fase di estrazione ed eseguito l'arricchimento dei dati. Infine, abbiamo esteso i dati strutturati estratti da IDP per ulteriori analisi e creato visualizzazioni per rilevare reclami fraudolenti utilizzando i servizi di AWS Analytics.

Si consiglia di rivedere le sezioni di sicurezza del Testo Amazon, Amazon Comprehende AmazonA2I documentazione e seguendo le linee guida fornite. Per ulteriori informazioni sui prezzi della soluzione, consultare i dettagli sui prezzi di Testo Amazon, Amazon Comprehende AmazonA2I.

Informazioni sugli autori

Chinmayee Rane è un architetto di soluzioni specializzato in AI/ML presso Amazon Web Services. È appassionata di matematica applicata e machine learning. Si concentra sulla progettazione di soluzioni intelligenti per l'elaborazione dei documenti per i clienti AWS. Al di fuori del lavoro, le piace ballare la salsa e la bachata.

Uday Narayan è un esperto di analisi in soluzioni Architect presso AWS. Gli piace aiutare i clienti a trovare soluzioni innovative per sfide aziendali complesse. Le sue principali aree di interesse sono l'analisi dei dati, i sistemi di big data e l'apprendimento automatico. Nel tempo libero gli piace fare sport, guardare programmi TV e viaggiare.

Sonali Sahu è a capo del team di Intelligent Document Processing AI/ML Solutions Architect di Amazon Web Services. È un'appassionata tecnofila e le piace lavorare con i clienti per risolvere problemi complessi utilizzando l'innovazione. La sua principale area di interesse è l'intelligenza artificiale e l'apprendimento automatico per l'elaborazione intelligente dei documenti.