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

In Del 1 av denne serien diskuterte vi intelligent dokumentbehandling (IDP), og hvordan IDP kan fremskynde brukssaker for behandling av skader i forsikringsbransjen. Vi diskuterte hvordan vi kan bruke AWS AI-tjenester for nøyaktig å kategorisere kravdokumenter sammen med støttedokumenter. Vi diskuterte også hvordan du trekker ut ulike typer dokumenter i en forsikringsskadepakke, for eksempel skjemaer, tabeller eller spesialiserte dokumenter som fakturaer, kvitteringer eller ID-dokumenter. Vi undersøkte utfordringene i eldre dokumentprosesser, som er tidkrevende, feilutsatte, dyre og vanskelige å behandle i stor skala, og hvordan du kan bruke AWS AI-tjenester for å implementere IDP-pipeline.

I dette innlegget leder vi deg gjennom avanserte IDP-funksjoner for dokumentutvinning, spørring og berikelse. Vi ser også på hvordan vi kan bruke den utpakkede strukturerte informasjonen fra kravdata for å få innsikt ved å bruke AWS Analytics og visualiseringstjenester. Vi fremhever hvordan ekstraherte strukturerte data fra IDP kan hjelpe mot uredelige krav ved bruk av AWS Analytics-tjenester.

Løsningsoversikt

Følgende diagram illustrerer fasene hvis IDP bruker AWS AI-tjenester. I del 1 diskuterte vi de tre første fasene av IDP-arbeidsflyten. I dette innlegget utvider vi utvinningstrinnet og de resterende fasene, som inkluderer integrering av IDP med AWS Analytics-tjenester.

Vi bruker disse analysetjenestene for ytterligere innsikt og visualiseringer, og for å oppdage uredelige påstander ved å bruke strukturerte, normaliserte data fra IDP. Følgende diagram illustrerer løsningsarkitekturen.

Fasene vi diskuterer i dette innlegget bruker følgende nøkkeltjenester:

• Amazon Comprehend Medical er en HIPAA-kvalifisert naturlig språkbehandlingstjeneste (NLP) som bruker maskinlæringsmodeller (ML) som er forhåndsopplært til å forstå og trekke ut helsedata fra medisinsk tekst, for eksempel resepter, prosedyrer eller diagnoser.
• AWS Lim er en del av AWS Analytics-tjenestestabelen, og er en serverløs dataintegrasjonstjeneste som gjør det enkelt å oppdage, forberede og kombinere data for analyse, ML og applikasjonsutvikling.
• Amazon RedShift er en annen tjeneste i Analytics-stakken. Amazon Redshift er en fullstendig administrert, petabyte-skala datavarehustjeneste i skyen.

Forutsetninger

Før du setter i gang, se Del 1 for en oversikt på høyt nivå over forsikringsbrukstilfellet med IDP og detaljer om datafangst- og klassifiseringsstadiene.

For mer informasjon om kodeeksemplene, se vår GitHub repo.

Utvinningsfase

I del 1 så vi hvordan man bruker Amazon Textract APIer til å trekke ut informasjon som skjemaer og tabeller fra dokumenter, og hvordan man analyserer fakturaer og identitetsdokumenter. I dette innlegget forbedrer vi utvinningsfasen med Amazon Comprehend for å trekke ut standard- og tilpassede enheter som er spesifikke for tilpassede brukstilfeller.

Forsikringsselskaper kommer ofte over tett tekst i søknader om forsikringskrav, for eksempel en pasients utskrivningsskrivelse (se følgende eksempelbilde). Det kan være vanskelig å automatisk hente ut informasjon fra slike typer dokumenter der det ikke er noen bestemt struktur. For å løse dette kan vi bruke følgende metoder for å trekke ut viktig forretningsinformasjon fra dokumentet:

Pakk ut standardenheter med Amazon Comprehend DetectEntities API

Vi kjører følgende kode på prøvedokumentet for medisinsk transkripsjon:

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 skjermbilde viser en samling av enheter identifisert i inndatateksten. Utdataene er forkortet i forbindelse med dette innlegget. Referere til GitHub repo for en detaljert liste over enheter.

Trekk ut egendefinerte enheter med Amazon Comprehend tilpasset enhetsgjenkjenning

Svaret fra DetectEntities API inkluderer standardenhetene. Vi er imidlertid interessert i å vite spesifikke enhetsverdier, for eksempel pasientens navn (angitt med standardenheten PERSON), eller pasientens ID (angitt med standardenheten OTHER). For å gjenkjenne disse tilpassede enhetene trener vi en Amazon Comprehend-modell for tilpasset enhetsgjenkjenning. Vi anbefaler å følge de omfattende trinnene for hvordan du trener og distribuerer en tilpasset enhetsgjenkjenningsmodell i GitHub repo.

Etter at vi har implementert den tilpassede modellen, kan vi bruke hjelpefunksjonen get_entities() for å hente egendefinerte enheter som PATIENT_NAME og 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 skjermbilde viser resultatene våre.

Anrikningsfase

I dokumentberikelsesfasen utfører vi berikelsesfunksjoner på helserelaterte dokumenter for å trekke verdifull innsikt. Vi ser på følgende typer berikelse:

• Pakk ut domenespesifikt språk – Vi bruker Amazon Comprehend Medical for å trekke ut medisinsk-spesifikke ontologier som ICD-10-CM, RxNorm og SNOMED CT
• Rediger sensitiv informasjon – Vi bruker Amazon Comprehend for å redigere personlig identifiserbar informasjon (PII), og Amazon Comprehend Medical for å redigere beskyttet helseinformasjon (PHI)

Trekk ut medisinsk informasjon fra ustrukturert medisinsk tekst

Dokumenter som medisinske leverandørers notater og kliniske utprøvingsrapporter inkluderer tett medisinsk tekst. Transportører av forsikringskrav må identifisere relasjonene mellom den ekstraherte helseinformasjonen fra denne tette teksten og koble dem til medisinske ontologier som ICD-10-CM, RxNorm og SNOMED CT-koder. Dette er svært verdifullt for å automatisere arbeidsflyter for skaderegistrering, validering og godkjenning for forsikringsselskaper for å akselerere og forenkle skadebehandlingen. La oss se på hvordan vi kan bruke Amazon Comprehend Medical InferICD10CM API for å oppdage mulige medisinske tilstander som enheter og koble dem til kodene deres:

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

For inndatateksten, som vi kan sende inn fra Amazon Textract DetectDocumentText API, den InferICD10CM API returnerer følgende utdata (utdataene er forkortet for korthet).

På samme måte kan vi bruke Amazon Comprehend Medical InferRxNorm API for å identifisere medisiner og InferSNOMEDCT API for å oppdage medisinske enheter innenfor helserelaterte forsikringsdokumenter.

Utfør PII og PHI redaksjon

Forsikringskravpakker krever mye overholdelse av personvern og forskrifter fordi de inneholder både PII- og PHI-data. Forsikringsselskaper kan redusere samsvarsrisikoen ved å redigere informasjon som forsikringsnummer eller pasientens navn.

La oss se på et eksempel på en pasients utskrivningsoppsummering. Vi bruker Amazon Comprehend DetectPiiEntities API for å oppdage PII-enheter i dokumentet og beskytte pasientens personvern ved å redigere disse enhetene:

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-enheter i svaret fra detect_pii_entities() API:

Vi kan deretter redigere PII-enhetene som ble oppdaget fra dokumentene ved å bruke grenseboksgeometrien til enhetene fra dokumentet. Til det bruker vi et hjelpeverktøy som heter amazon-textract-overlayer. For mer informasjon, se Textract-Overlag. Følgende skjermbilder sammenligner et dokument før og etter redigering.

Ligner på Amazon Comprehend DetectPiiEntities API, kan vi også bruke DetectPHI API for å oppdage PHI-data i den kliniske teksten som undersøkes. For mer informasjon, se Oppdag PHI.

Gjennomgang og valideringsfase

I dokumentgjennomgang og valideringsfasen kan vi nå verifisere om skadepakken oppfyller virksomhetens krav, fordi vi har all informasjon samlet inn fra dokumentene i pakken fra tidligere stadier. Vi kan gjøre dette ved å introdusere et menneske i løkken som kan gjennomgå og validere alle feltene eller bare en automatisk godkjenningsprosess for krav med lavt beløp før pakken sendes til nedstrømsapplikasjoner. Vi kan bruke Amazon Augmented AI (Amazon A2I) for å automatisere den menneskelige vurderingsprosessen for behandling av forsikringskrav.

Nå som vi har hentet ut og normalisert alle nødvendige data fra kravbehandling ved bruk av AI-tjenester for IDP, kan vi utvide løsningen til å integreres med AWS Analytics-tjenester som AWS Glue og Amazon Redshift for å løse flere brukstilfeller og gi ytterligere analyser og visualiseringer.

Oppdag falske forsikringskrav

I dette innlegget implementerer vi en serverløs arkitektur der de utpakkede og behandlede dataene lagres i en datainnsjø og brukes til å oppdage uredelige forsikringskrav ved bruk av ML. Vi bruker Amazon enkel lagringstjeneste (Amazon S3) for å lagre de behandlede dataene. Da kan vi bruke AWS Lim or Amazon EMR for å rense dataene og legge til flere felt for å gjøre dem forbrukbare for rapportering og ML. Etter det bruker vi Amazon Redshift ML å bygge en ML-modell for svindeldeteksjon. Til slutt bygger vi rapporter ved hjelp av Amazon QuickSight for å få innsikt i dataene.

Sett opp Amazon Redshift eksternt skjema

For formålet med dette eksemplet har vi laget en eksempel datasett emulerer utdataene fra en ETL-prosess (ekstrahere, transformere og laste), og bruker AWS Glue Data Catalog som metadatakatalog. Først lager vi en database som heter idp_demo i Data Catalog og et eksternt skjema i Amazon Redshift kalt idp_insurance_demo (se følgende kode). Vi bruker en AWS identitets- og tilgangsadministrasjon (IAM) rolle for å gi tillatelser til Amazon Redshift-klyngen for å få tilgang til Amazon S3 og Amazon SageMaker. For mer informasjon om hvordan du setter opp denne IAM-rollen med minst rettigheter, se Klynger og konfigurer oppsett for Amazon Redshift ML-administrasjon.

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

Lag Amazon Redshift ekstern tabell

Det neste trinnet er å lage en ekstern tabell i Amazon Redshift som refererer til S3-plasseringen der filen ligger. I dette tilfellet er filen vår en kommadelt tekstfil. Vi ønsker også å hoppe over overskriftsraden fra filen, som kan konfigureres i tabellegenskaper-delen. 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');

Lag opplærings- og testdatasett

Etter at vi har opprettet den eksterne tabellen, forbereder vi datasettet vårt for ML ved å dele det opp i treningssett og testsett. Vi oppretter en ny ekstern tabell kalt claim_train, som består av alle poster med ID <= 85000 fra kravtabellen. Dette er treningssettet som vi trener vår ML-modell 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 lager en annen ekstern tabell kalt claim_test som består av alle poster med ID >85000 for å være testsettet 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

Lag en ML-modell med Amazon Redshift ML

Nå lager vi modellen ved å bruke LAG MODELL kommando (se følgende kode). Vi velger de relevante kolonnene fra claims_train tabell som kan fastslå en uredelig transaksjon. Målet med denne modellen er å forutsi verdien av fraud kolonne; derfor, fraud legges til som prediksjonsmål. Etter at modellen er trent, oppretter den en funksjon kalt insurance_fraud_model. Denne funksjonen brukes for slutninger mens du kjører SQL-setninger for å forutsi verdien av 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-modellberegninger

Etter at vi har opprettet modellen, kan vi kjøre spørringer for å sjekke nøyaktigheten til modellen. Vi bruker insurance_fraud_model funksjon for å forutsi verdien av fraud kolonne for nye poster. Kjør følgende spørring på claims_test tabell for å lage en forvirringsmatrise:

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;

Oppdag svindel ved å bruke ML-modellen

Etter at vi har opprettet den nye modellen, ettersom nye kravdata settes inn i datavarehuset eller datasjøen, kan vi bruke insurance_fraud_model funksjon for å beregne de uredelige transaksjonene. Dette gjør vi ved først å laste de nye dataene inn i en midlertidig tabell. Da bruker vi insurance_fraud_model funksjon for å beregne fraud flagg for hver nye transaksjon og sett inn dataene sammen med flagget i den endelige tabellen, som i dette tilfellet er claims tabellen.

Visualiser skadedataene

Når dataene er tilgjengelige i Amazon Redshift, kan vi lage visualiseringer ved hjelp av QuickSight. Vi kan deretter dele QuickSight-dashbordene med forretningsbrukere og analytikere. For å lage QuickSight-dashbordet må du først opprette et Amazon Redshift-datasett i QuickSight. For instruksjoner, se Opprette et datasett fra en database.

Etter at du har opprettet datasettet, kan du opprette en ny analyse i QuickSight ved hjelp av datasettet. Følgende er noen eksempler på rapporter vi har laget:

• Totalt antall krav etter stat, gruppert etter fraud felt – Dette diagrammet viser oss andelen uredelige transaksjoner sammenlignet med det totale antallet transaksjoner i en bestemt stat.
• Summen av den totale dollarverdien av kravene, gruppert etter fraud felt – Dette diagrammet viser oss andelen av dollarbeløpet av uredelige transaksjoner sammenlignet med den totale dollarbeløpet for transaksjoner i en bestemt stat.
• Totalt antall transaksjoner per forsikringsselskap, gruppert etter fraud felt – Dette diagrammet viser oss hvor mange krav som ble inngitt for hvert forsikringsselskap og hvor mange av dem som er uredelige.

• Total sum av uredelige transaksjoner etter stat vist på et amerikansk kart – Dette diagrammet viser bare de uredelige transaksjonene og viser de totale kostnadene for disse transaksjonene etter stat på kartet. Den mørkere blåtonen indikerer høyere totale ladninger. Vi kan videre analysere dette etter by i den staten og postnummer med byen for å bedre forstå trendene.

Rydd opp

For å forhindre fremtidige belastninger på AWS-kontoen din, slett ressursene du tilordnet i oppsettet ved å følge instruksjonene i Oppryddingsseksjon i vår repo.

konklusjonen

I denne todelte serien så vi hvordan man bygger en ende-til-ende IDP-pipeline med liten eller ingen ML-erfaring. Vi utforsket en brukssak for skadebehandling i forsikringsbransjen og hvordan IDP kan hjelpe til med å automatisere denne brukssaken ved å bruke tjenester som Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical og Amazon A2I. I del 1 demonstrerte vi hvordan du bruker AWS AI-tjenester for dokumentutvinning. I del 2 utvidet vi utvinningsfasen og utførte databerikelse. Til slutt utvidet vi de strukturerte dataene hentet fra IDP for ytterligere analyser, og laget visualiseringer for å oppdage uredelige påstander ved å bruke AWS Analytics-tjenester.

Vi anbefaler å gå gjennom sikkerhetsdelene i amazontekst, Amazon Comprehendog Amazon A2I dokumentasjon og følge de gitte retningslinjene. For å lære mer om prissettingen av løsningen, se prisdetaljene til amazontekst, Amazon Comprehendog Amazon A2I.

Om forfatterne

Chinmayee Rane er en AI/ML-spesialistløsningsarkitekt hos Amazon Web Services. Hun brenner for anvendt matematikk og maskinlæring. Hun fokuserer på å designe intelligente dokumentbehandlingsløsninger for AWS-kunder. Utenom jobben liker hun salsa og bachata dans.

Uday Narayanan er en Analytics Specialist Solutions Architect hos AWS. Han liker å hjelpe kunder med å finne innovative løsninger på komplekse forretningsutfordringer. Hans kjernefokusområder er dataanalyse, store datasystemer og maskinlæring. På fritiden liker han å spille sport, se på TV-serier og reise.

Sonali Sahu leder teamet for Intelligent Document Processing AI/ML Solutions Architect hos Amazon Web Services. Hun er en lidenskapelig teknofil og liker å jobbe med kunder for å løse komplekse problemer ved hjelp av innovasjon. Hennes kjernefokusområde er kunstig intelligens og maskinlæring for intelligent dokumentbehandling.