Intelligent dokumentbehandling med AWS AI og Analytics-tjenester i forsikringsbranchen: Del 2

In del 1 i denne serie diskuterede vi intelligent dokumentbehandling (IDP), og hvordan IDP kan fremskynde brugssager i forsikringsbranchen. Vi diskuterede, hvordan vi kan bruge AWS AI-tjenester til nøjagtigt at kategorisere skadesdokumenter sammen med understøttende dokumenter. Vi diskuterede også, hvordan man udtrækker forskellige typer dokumenter i en forsikringsskadepakke, såsom formularer, tabeller eller specialiserede dokumenter, såsom fakturaer, kvitteringer eller ID-dokumenter. Vi undersøgte udfordringerne i ældre dokumentprocesser, som er tidskrævende, fejltilbøjelige, dyre og svære at behandle i skala, og hvordan du kan bruge AWS AI-tjenester til at hjælpe med at implementere din IDP-pipeline.

I dette indlæg guider vi dig gennem avancerede IDP-funktioner til dokumentudtrækning, forespørgsel og berigelse. Vi ser også på, hvordan man yderligere kan bruge den udtrukne strukturerede information fra kravdata til at få indsigt ved hjælp af AWS Analytics og visualiseringstjenester. Vi fremhæver, hvordan ekstraherede strukturerede data fra IDP kan hjælpe mod svigagtige krav ved brug af AWS Analytics-tjenester.

Løsningsoversigt

Følgende diagram illustrerer faserne, hvis IDP bruger AWS AI-tjenester. I del 1 diskuterede vi de første tre faser af IDP-arbejdsgangen. I dette indlæg udvider vi ekstraktionstrinnet og de resterende faser, som inkluderer integration af IDP med AWS Analytics-tjenester.

Vi bruger disse analysetjenester til yderligere indsigt og visualiseringer og til at opdage svigagtige krav ved hjælp af strukturerede, normaliserede data fra IDP. Følgende diagram illustrerer løsningsarkitekturen.

De faser, vi diskuterer i dette indlæg, bruger følgende nøgletjenester:

• Amazon Comprehend Medical er en HIPAA-godkendt NLP-tjeneste, der bruger maskinlæringsmodeller (ML), der er blevet foruddannet til at forstå og udtrække sundhedsdata fra medicinsk tekst, såsom recepter, procedurer eller diagnoser.
• AWS Lim er en del af AWS Analytics-servicestakken og er en serverløs dataintegrationstjeneste, der gør det nemt at opdage, forberede og kombinere data til analyse, ML og applikationsudvikling.
• Amazon rødforskydning er en anden tjeneste i Analytics-stakken. Amazon Redshift er en fuldt administreret, petabyte-skala datavarehustjeneste i skyen.

Forudsætninger

Inden du går i gang, henvises til del 1 for et overblik på højt niveau over forsikringsbrugssagen med IDP og detaljer om datafangst- og klassificeringsstadierne.

For mere information om kodeeksemplerne henvises til vores GitHub repo.

Udvindingsfase

I del 1 så vi, hvordan man bruger Amazon Textract API'er til at udtrække information som formularer og tabeller fra dokumenter, og hvordan man analyserer fakturaer og identitetsdokumenter. I dette indlæg forbedrer vi udvindingsfasen med Amazon Comprehend for at udtrække standard- og brugerdefinerede enheder, der er specifikke for brugertilpassede anvendelsestilfælde.

Forsikringsselskaber støder ofte på tæt tekst i ansøgninger om forsikringsskader, såsom et resumé af en patients udskrivelsesbrev (se følgende eksempelbillede). Det kan være svært automatisk at udtrække information fra sådanne typer dokumenter, hvor der ikke er en bestemt struktur. For at løse dette kan vi bruge følgende metoder til at udtrække vigtige forretningsoplysninger fra dokumentet:

Udpak standardenheder med Amazon Comprehend DetectEntities API

Vi kører følgende kode på prøvedokumentet for medicinsk transkription:

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

Følgende skærmbillede viser en samling af enheder identificeret i inputteksten. Outputtet er blevet forkortet til formålet med dette indlæg. Der henvises til GitHub repo for en detaljeret liste over enheder.

Uddrag tilpassede enheder med Amazon Comprehend tilpasset enhedsgenkendelse

Svaret fra DetectEntities API inkluderer standardenheder. Vi er dog interesserede i at kende specifikke enhedsværdier, såsom patientens navn (angivet med standardenheden PERSON), eller patientens ID (angivet af standardenheden OTHER). For at genkende disse brugerdefinerede entiteter træner vi en Amazon Comprehend brugerdefineret enhedsgenkendelsesmodel. Vi anbefaler at følge de omfattende trin til, hvordan man træner og implementerer en tilpasset enhedsgenkendelsesmodel i GitHub repo.

Efter at vi har implementeret den tilpassede model, kan vi bruge hjælpefunktionen get_entities() for at hente brugerdefinerede enheder som PATIENT_NAME , PATIENT_D fra API-svaret:

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)

Følgende skærmbillede viser vores resultater.

Berigelsesfase

I dokumentberigelsesfasen udfører vi berigelsesfunktioner på sundhedsrelaterede dokumenter for at opnå værdifuld indsigt. Vi ser på følgende former for berigelse:

• Udpak domænespecifikt sprog – Vi bruger Amazon Comprehend Medical til at udtrække medicinsk-specifikke ontologier som ICD-10-CM, RxNorm og SNOMED CT
• Redigér følsomme oplysninger – Vi bruger Amazon Comprehend til at redigere personligt identificerbare oplysninger (PII), og Amazon Comprehend Medical til at redigere beskyttede sundhedsoplysninger (PHI)

Uddrag medicinsk information fra ustruktureret medicinsk tekst

Dokumenter såsom medicinske udbyderes notater og rapporter om kliniske forsøg indeholder tæt medicinsk tekst. Transportører af forsikringskrav skal identificere forholdet mellem de udtrukne sundhedsoplysninger fra denne tætte tekst og knytte dem til medicinske ontologier som ICD-10-CM, RxNorm og SNOMED CT-koder. Dette er meget værdifuldt til at automatisere arbejdsgange for registrering, validering og godkendelse af skader for forsikringsselskaber for at fremskynde og forenkle sagsbehandlingen. Lad os se på, hvordan vi kan bruge Amazon Comprehend Medical InferICD10CM API til at opdage mulige medicinske tilstande som enheder og knytte dem til deres koder:

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

Til inputteksten, som vi kan sende ind fra Amazon Textract DetectDocumentText API, den InferICD10CM API returnerer følgende output (outputtet er blevet forkortet for korthed).

På samme måde kan vi bruge Amazon Comprehend Medical InferRxNorm API til at identificere medicin og InferSNOMEDCT API til at opdage medicinske enheder inden for sundhedsrelaterede forsikringsdokumenter.

Udfør PII og PHI redaktion

Forsikringskravpakker kræver en masse overholdelse af privatlivets fred og regler, fordi de indeholder både PII- og PHI-data. Forsikringsselskaber kan reducere overholdelsesrisikoen ved at redigere oplysninger som policenumre eller patientens navn.

Lad os se på et eksempel på en patients udskrivningsoversigt. Vi bruger Amazon Comprehend DetectPiiEntities API til at detektere PII-enheder i dokumentet og beskytte patientens privatliv ved at redigere disse entiteter:

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)

Vi får følgende PII-enheder i svaret fra detect_pii_entities() API:

Vi kan derefter redigere de PII-enheder, der blev detekteret fra dokumenterne, ved at bruge afgrænsningsrammegeometrien for entiteterne fra dokumentet. Til det bruger vi et hjælpeværktøj kaldet amazon-textract-overlayer. For mere information, se Textract-Overlayer. Følgende skærmbilleder sammenligner et dokument før og efter redigering.

Svarende til Amazon Comprehend DetectPiiEntities API, kan vi også bruge DetectPHI API til at detektere PHI-data i den kliniske tekst, der undersøges. For mere information, se Opdag PHI.

Gennemgang og valideringsfase

I dokumentgennemgangen og valideringsfasen kan vi nu verificere, om skadespakken lever op til virksomhedens krav, fordi vi har alle informationer indsamlet fra dokumenterne i pakken fra tidligere stadier. Vi kan gøre dette ved at introducere et menneske i løkken, der kan gennemgå og validere alle felterne eller blot en automatisk godkendelsesproces for krav med lavt beløb, før pakken sendes til downstream-applikationer. Vi kan bruge Amazon Augmented AI (Amazon A2I) for at automatisere den menneskelige gennemgang af behandling af forsikringsskader.

Nu hvor vi har alle nødvendige data udtrukket og normaliseret fra behandling af krav ved hjælp af AI-tjenester til IDP, kan vi udvide løsningen til at integrere med AWS Analytics-tjenester såsom AWS Glue og Amazon Redshift for at løse yderligere use cases og levere yderligere analyser og visualiseringer.

Opdag svigagtige forsikringskrav

I dette indlæg implementerer vi en serverløs arkitektur, hvor de udtrukne og behandlede data gemmes i en datasø og bruges til at opdage svigagtige forsikringskrav ved hjælp af ML. Vi bruger Amazon Simple Storage Service (Amazon S3) for at gemme de behandlede data. Så kan vi bruge AWS Lim or Amazon EMR at rense dataene og tilføje yderligere felter for at gøre det forbrugsdygtigt til rapportering og ML. Derefter bruger vi Amazon Redshift ML at bygge en ML-model for opdagelse af bedrageri. Til sidst bygger vi rapporter vha Amazon QuickSight for at få indsigt i dataene.

Konfigurer Amazon Redshift eksternt skema

Til formålet med dette eksempel har vi lavet en eksempeldatasæt emulerer output fra en ETL-proces (ekstrahere, transformere og indlæse) og bruge AWS Glue Data Catalog som metadatakatalog. Først opretter vi en database med navnet idp_demo i datakataloget og et eksternt skema i Amazon Redshift kaldet idp_insurance_demo (se følgende kode). Vi bruger en AWS identitets- og adgangsstyring (IAM) rolle for at give tilladelser til Amazon Redshift-klyngen for at få adgang til Amazon S3 og Amazon SageMaker. For mere information om, hvordan du konfigurerer denne IAM-rolle med mindst privilegium, se Klynge og konfigurer opsætning til Amazon Redshift ML-administration.

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

Opret Amazon Redshift ekstern tabel

Det næste trin er at oprette en ekstern tabel i Amazon Redshift, der refererer til den S3-placering, hvor filen er placeret. I dette tilfælde er vores fil en kommasepareret tekstfil. Vi ønsker også at springe overskriftsrækken over fra filen, som kan konfigureres i tabelegenskabssektionen. Se følgende kode:

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

Opret trænings- og testdatasæt

Efter at vi har oprettet den eksterne tabel, forbereder vi vores datasæt til ML ved at opdele det i træningssæt og testsæt. Vi opretter en ny ekstern tabel kaldet claim_train, som består af alle poster med ID <= 85000 fra skadestabellen. Dette er træningssættet, som vi træner vores ML-model på.

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

Vi opretter en anden ekstern tabel kaldet claim_test der består af alle poster med ID >85000 for at være det testsæt, som vi tester ML-modellen på:

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

Opret en ML-model med Amazon Redshift ML

Nu laver vi modellen ved hjælp af OPRET MODEL kommando (se følgende kode). Vi vælger de relevante kolonner fra claims_train tabel, der kan fastslå en svigagtig transaktion. Målet med denne model er at forudsige værdien af fraud kolonne; derfor, fraud tilføjes som forudsigelsesmål. Efter at modellen er trænet, opretter den en funktion med navnet insurance_fraud_model. Denne funktion bruges til inferens, mens du kører SQL-sætninger for at forudsige værdien af fraud kolonne for nye poster.

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

Evaluer ML model metrics

Efter at vi har oprettet modellen, kan vi køre forespørgsler for at kontrollere modellens nøjagtighed. Vi bruger insurance_fraud_model funktion til at forudsige værdien af fraud kolonne for nye poster. Kør følgende forespørgsel på claims_test tabel for at skabe en forvirringsmatrix:

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;

Opdag svindel ved hjælp af ML-modellen

Efter at vi har oprettet den nye model, efterhånden som nye kravdata indsættes i datavarehuset eller datasøen, kan vi bruge insurance_fraud_model funktion til at beregne de svigagtige transaktioner. Det gør vi ved først at indlæse de nye data i en midlertidig tabel. Så bruger vi insurance_fraud_model funktion til at beregne fraud flag for hver ny transaktion, og indsæt dataene sammen med flaget i den endelige tabel, som i dette tilfælde er claims tabel.

Visualiser skadesdataene

Når dataene er tilgængelige i Amazon Redshift, kan vi oprette visualiseringer ved hjælp af QuickSight. Vi kan derefter dele QuickSight-dashboards med forretningsbrugere og analytikere. For at oprette QuickSight-dashboardet skal du først oprette et Amazon Redshift-datasæt i QuickSight. For instruktioner, se Oprettelse af et datasæt fra en database.

Når du har oprettet datasættet, kan du oprette en ny analyse i QuickSight ved hjælp af datasættet. Følgende er nogle eksempler på rapporter, vi har oprettet:

• Samlet antal krav efter stat, grupperet efter fraud felt – Dette diagram viser os andelen af ​​svigagtige transaktioner sammenlignet med det samlede antal transaktioner i en bestemt stat.
• Summen af ​​den samlede dollarværdi af kravene, grupperet efter fraud felt – Dette diagram viser os andelen af ​​dollarbeløb af svigagtige transaktioner sammenlignet med den samlede dollarmængde af transaktioner i en bestemt stat.
• Samlet antal transaktioner pr. forsikringsselskab, grupperet efter fraud felt – Dette diagram viser os, hvor mange krav der blev indgivet for hvert forsikringsselskab, og hvor mange af dem, der er svigagtige.

• Samlet sum af svigagtige transaktioner efter stat vist på et amerikansk kort – Dette diagram viser blot de svigagtige transaktioner og viser de samlede gebyrer for disse transaktioner efter stat på kortet. Den mørkere blå nuance indikerer højere samlede ladninger. Vi kan yderligere analysere dette efter by i den pågældende stat og postnumre med byen for bedre at forstå tendenserne.

Ryd op

For at forhindre fremtidige debiteringer på din AWS-konto skal du slette de ressourcer, du har leveret i opsætningen ved at følge instruktionerne i Oprydningssektion i vores repo.

Konklusion

I denne todelte serie så vi, hvordan man bygger en end-to-end IDP-pipeline med ringe eller ingen ML-erfaring. Vi undersøgte en brugssag til behandling af skader i forsikringsbranchen, og hvordan IDP kan hjælpe med at automatisere denne brugssag ved hjælp af tjenester som Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical og Amazon A2I. I del 1 demonstrerede vi, hvordan man bruger AWS AI-tjenester til dokumentudtrækning. I del 2 udvidede vi ekstraktionsfasen og udførte databerigelse. Endelig udvidede vi de strukturerede data, der blev udtrukket fra IDP til yderligere analyser, og skabte visualiseringer til at opdage svigagtige krav ved hjælp af AWS Analytics-tjenester.

Vi anbefaler at gennemgå sikkerhedsafsnittene i amazontekst, Amazon Comprehendog Amazon A2I dokumentation og følge retningslinjerne. Hvis du vil vide mere om prissætningen af ​​løsningen, kan du gennemgå prisoplysningerne for amazontekst, Amazon Comprehendog Amazon A2I.

Om forfatterne

Chinmayee Rane er AI/ML Specialist Solutions Architect hos Amazon Web Services. Hun brænder for anvendt matematik og maskinlæring. Hun fokuserer på at designe intelligente dokumentbehandlingsløsninger til AWS-kunder. Uden for arbejdet nyder hun salsa og bachata dans.

Uday Narayanan er en Analytics Specialist Solutions Architect hos AWS. Han nyder at hjælpe kunder med at finde innovative løsninger på komplekse forretningsmæssige udfordringer. Hans kernefokusområder er dataanalyse, big data-systemer og maskinlæring. I sin fritid nyder han at dyrke sport, overse tv-serier og rejse.

Sonali Sahu leder teamet Intelligent Document Processing AI/ML Solutions Architect hos Amazon Web Services. Hun er en passioneret teknofil og nyder at arbejde med kunder for at løse komplekse problemer ved hjælp af innovation. Hendes kernefokusområde er kunstig intelligens og maskinlæring til intelligent dokumentbehandling.