Intelligent dokumentbehandling med AWS AI och Analytics-tjänster inom försäkringsbranschen: Del 2

In del 1 i den här serien diskuterade vi intelligent dokumentbearbetning (IDP) och hur IDP kan påskynda användningsfallen för skadehantering inom försäkringsbranschen. Vi diskuterade hur vi kan använda AWS AI-tjänster för att korrekt kategorisera anspråksdokument tillsammans med stödjande dokument. Vi diskuterade också hur man extraherar olika typer av dokument i ett försäkringsskadepaket, såsom blanketter, tabeller eller specialiserade dokument som fakturor, kvitton eller ID-handlingar. Vi tittade på utmaningarna i äldre dokumentprocesser, som är tidskrävande, felbenägna, dyra och svåra att bearbeta i stor skala, och hur du kan använda AWS AI-tjänster för att implementera din IDP-pipeline.

I det här inlägget går vi igenom avancerade IDP-funktioner för dokumentextraktion, sökning och berikning. Vi undersöker också hur man ytterligare kan använda den extraherade strukturerade informationen från anspråksdata för att få insikter med hjälp av AWS Analytics och visualiseringstjänster. Vi lyfter fram hur extraherad strukturerad data från IDP kan hjälpa mot bedrägliga anspråk med AWS Analytics-tjänster.

Lösningsöversikt

Följande diagram illustrerar faserna om IDP använder AWS AI-tjänster. I del 1 diskuterade vi de tre första faserna av IDP-arbetsflödet. I det här inlägget utökar vi extraktionssteget och de återstående faserna, som inkluderar integrering av IDP med AWS Analytics-tjänster.

Vi använder dessa analystjänster för ytterligare insikter och visualiseringar och för att upptäcka bedrägliga anspråk med hjälp av strukturerad, normaliserad data från IDP. Följande diagram illustrerar lösningsarkitekturen.

Faserna vi diskuterar i det här inlägget använder följande nyckeltjänster:

• Amazon Comprehend Medical är en HIPAA-kvalificerad NLP-tjänst (natural language processing) som använder maskininlärningsmodeller (ML) som har förutbildats för att förstå och extrahera hälsodata från medicinsk text, såsom recept, procedurer eller diagnoser.
• AWS-lim är en del av AWS Analytics Services-stacken och är en serverlös dataintegrationstjänst som gör det enkelt att upptäcka, förbereda och kombinera data för analys, ML och applikationsutveckling.
• Amazon RedShift är en annan tjänst i Analytics-stacken. Amazon Redshift är en helt hanterad, petabyte-skala datalagertjänst i molnet.

Förutsättningar

Innan du börjar, se del 1 för en översikt på hög nivå av försäkringsanvändningsfallet med IDP och detaljer om datafångst och klassificeringsstadier.

För mer information om kodexemplen, se vår GitHub -repo.

Extraktionsfas

I del 1 såg vi hur man använder Amazon Textract API:er för att extrahera information som formulär och tabeller från dokument, och hur man analyserar fakturor och identitetsdokument. I det här inlägget förbättrar vi extraktionsfasen med Amazon Comprehend för att extrahera standard- och anpassade enheter som är specifika för anpassade användningsfall.

Försäkringsbolag stöter ofta på tät text i ansökningar om försäkringsersättningar, till exempel ett sammanfattningsbrev för en patients utskrivning (se följande exempelbild). Det kan vara svårt att automatiskt extrahera information från sådana typer av dokument där det inte finns någon bestämd struktur. För att åtgärda detta kan vi använda följande metoder för att extrahera viktig affärsinformation från dokumentet:

Extrahera standardenheter med Amazon Comprehend DetectEntities API

Vi kör följande kod på det medicinska transkriptionsdokumentet:

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öljande skärmdump visar en samling enheter som identifieras i inmatningstexten. Utdata har förkortats för detta inlägg. Referera till GitHub repo för en detaljerad lista över enheter.

Extrahera anpassade enheter med anpassad enhetsigenkänning av Amazon Comprehend

Svaret från DetectEntities API inkluderar standardenheterna. Vi är dock intresserade av att veta specifika entitetsvärden, till exempel patientens namn (betecknas med standardentiteten PERSON), eller patientens ID (betecknas med standardenheten OTHER). För att känna igen dessa anpassade enheter tränar vi en anpassad enhetsidentifieringsmodell från Amazon Comprehend. Vi rekommenderar att du följer de omfattande stegen för hur man tränar och distribuerar en anpassad enhetsigenkänningsmodell i GitHub -repo.

Efter att vi har distribuerat den anpassade modellen kan vi använda hjälpfunktionen get_entities() för att hämta anpassade enheter som PATIENT_NAME och PATIENT_D från 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öljande skärmdump visar våra resultat.

Anrikningsfas

I dokumentberikningsfasen utför vi berikningsfunktioner på sjukvårdsrelaterade dokument för att dra värdefulla insikter. Vi tittar på följande typer av berikning:

• Extrahera domänspecifikt språk – Vi använder Amazon Comprehend Medical för att extrahera medicinsk-specifika ontologier som ICD-10-CM, RxNorm och SNOMED CT
• Redigera känslig information – Vi använder Amazon Comprehend för att redigera personlig identifierbar information (PII), och Amazon Comprehend Medical för att redigera skyddad hälsoinformation (PHI)

Extrahera medicinsk information från ostrukturerad medicinsk text

Dokument som läkares anteckningar och rapporter om kliniska prövningar innehåller tät medicinsk text. Försäkringsförsäkringsföretag måste identifiera sambanden mellan den extraherade hälsoinformationen från denna täta text och länka dem till medicinska ontologier som ICD-10-CM, RxNorm och SNOMED CT-koder. Detta är mycket värdefullt för att automatisera arbetsflöden för skadeinsamling, validering och godkännande för försäkringsbolag för att påskynda och förenkla skadehanteringen. Låt oss titta på hur vi kan använda Amazon Comprehend Medical InferICD10CM API för att upptäcka möjliga medicinska tillstånd som entiteter och länka dem till deras 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}')

För inmatningstexten, som vi kan skicka in från Amazon Textract DetectDocumentText API, den InferICD10CM API returnerar följande utdata (utdata har förkortats för korthet).

På samma sätt kan vi använda Amazon Comprehend Medical InferRxNorm API för att identifiera mediciner och InferSNOMEDCT API för att upptäcka medicinska enheter inom sjukvårdsrelaterade försäkringsdokument.

Utför PII- och PHI-redaktion

Försäkringskravspaket kräver mycket efterlevnad av sekretess och regler eftersom de innehåller både PII- och PHI-data. Försäkringsbolag kan minska efterlevnadsrisken genom att redigera information som försäkringsnummer eller patientens namn.

Låt oss titta på ett exempel på en patients utskrivningssammanfattning. Vi använder Amazon Comprehend DetectPiiEntities API för att upptäcka PII-enheter i dokumentet och skydda patientens integritet genom att redigera dessa enheter:

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öljande PII-enheter i svaret från detect_pii_entities() API:

Vi kan sedan redigera PII-entiteterna som upptäcktes från dokumenten genom att använda bounding box-geometrin för entiteterna från dokumentet. För det använder vi ett hjälpverktyg som heter amazon-textract-overlayer. För mer information, se Textract-Overlayer. Följande skärmdumpar jämför ett dokument före och efter redigering.

Liknar Amazon Comprehend DetectPiiEntities API kan vi också använda DetectPHI API för att detektera PHI-data i den kliniska texten som undersöks. För mer information, se Upptäck PHI.

Granskning och valideringsfas

I dokumentgransknings- och valideringsfasen kan vi nu verifiera om skadepaketet uppfyller verksamhetens krav, eftersom vi har all information insamlad från dokumenten i paketet från tidigare skeden. Vi kan göra detta genom att introducera en människa i slingan som kan granska och validera alla fält eller bara en automatisk godkännandeprocess för anspråk på låga dollar innan vi skickar paketet till nedströmsapplikationer. Vi kan använda Amazon Augmented AI (Amazon A2I) för att automatisera processen för mänsklig granskning för behandling av försäkringsskador.

Nu när vi har all nödvändig data extraherad och normaliserad från anspråksbehandling med AI-tjänster för IDP, kan vi utöka lösningen till att integrera med AWS Analytics-tjänster som AWS Glue och Amazon Redshift för att lösa ytterligare användningsfall och tillhandahålla ytterligare analyser och visualiseringar.

Upptäck bedrägliga försäkringskrav

I det här inlägget implementerar vi en serverlös arkitektur där den extraherade och bearbetade datan lagras i en datasjö och används för att upptäcka bedrägliga försäkringskrav med hjälp av ML. Vi använder Amazon enkel lagringstjänst (Amazon S3) för att lagra bearbetade data. Vi kan då använda AWS-lim or Amazon EMR att rensa data och lägga till ytterligare fält för att göra den förbrukningsbar för rapportering och ML. Efter det använder vi Amazon Redshift ML att bygga en ML-modell för upptäckt av bedrägeri. Slutligen bygger vi rapporter med hjälp av Amazon QuickSight för att få insikter i data.

Ställ in Amazon Redshift externt schema

För detta exempel har vi skapat en exempeluppsättning emulerar utdata från en ETL-process (extrahera, transformera och ladda) och använder AWS Glue Data Catalog som metadatakatalog. Först skapar vi en databas med namnet idp_demo i datakatalogen och ett externt schema i Amazon Redshift kallas idp_insurance_demo (se följande kod). Vi använder en AWS identitets- och åtkomsthantering (IAM) roll för att ge behörigheter till Amazon Redshift-klustret för att komma åt Amazon S3 och Amazon SageMaker. För mer information om hur du ställer in denna IAM-roll med minsta privilegium, se Klustra och konfigurera inställningar för Amazon Redshift ML-administration.

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

Skapa Amazon Redshift extern tabell

Nästa steg är att skapa en extern tabell i Amazon Redshift som refererar till S3-platsen där filen finns. I det här fallet är vår fil en kommaseparerad textfil. Vi vill också hoppa över rubrikraden från filen, som kan konfigureras i avsnittet tabellegenskaper. Se följande kod:

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

Skapa utbildnings- och testdatauppsättningar

Efter att vi skapat den externa tabellen förbereder vi vår datauppsättning för ML genom att dela upp den i träningsuppsättning och testuppsättning. Vi skapar en ny extern tabell som heter claim_train, som består av alla poster med ID <= 85000 från skadetabellen. Det här är träningssetet som vi tränar 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 skapar en annan extern tabell som heter claim_test som består av alla poster med ID >85000 för att vara testsetet som vi testar 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

Skapa en ML-modell med Amazon Redshift ML

Nu skapar vi modellen med hjälp av SKAPA MODELL kommando (se följande kod). Vi väljer de relevanta kolumnerna från claims_train tabell som kan fastställa en bedräglig transaktion. Målet med denna modell är att förutsäga värdet av fraud kolumn; därför, fraud läggs till som förutsägelsemål. Efter att modellen har tränats skapar den en funktion som heter insurance_fraud_model. Denna funktion används för slutledning när du kör SQL-satser för att förutsäga värdet av fraud kolumn för nya rekord.

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

Utvärdera ML-modellmått

När vi har skapat modellen kan vi köra frågor för att kontrollera modellens riktighet. Vi använder insurance_fraud_model funktion för att förutsäga värdet av fraud kolumn för nya rekord. Kör följande fråga på claims_test tabell för att skapa en förvirringsmatris:

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;

Upptäck bedrägeri med ML-modellen

När vi har skapat den nya modellen, när nya anspråksdata infogas i datalagret eller datasjön, kan vi använda insurance_fraud_model funktion för att beräkna de bedrägliga transaktionerna. Vi gör detta genom att först ladda den nya datan i en tillfällig tabell. Då använder vi insurance_fraud_model funktion för att beräkna fraud flagga för varje ny transaktion och infoga data tillsammans med flaggan i finalbordet, vilket i det här fallet är claims tabell.

Visualisera anspråksdata

När data är tillgänglig i Amazon Redshift kan vi skapa visualiseringar med QuickSight. Vi kan sedan dela QuickSights instrumentpaneler med affärsanvändare och analytiker. För att skapa QuickSight-instrumentpanelen måste du först skapa en Amazon Redshift-datauppsättning i QuickSight. För instruktioner, se Skapa en datauppsättning från en databas.

När du har skapat datasetet kan du skapa en ny analys i QuickSight med hjälp av datamängden. Följande är några exempelrapporter som vi skapade:

• Totalt antal anspråk per stat, grupperat efter fraud fält – Det här diagrammet visar oss andelen bedrägliga transaktioner jämfört med det totala antalet transaktioner i en viss stat.
• Summan av det totala dollarvärdet av fordringarna, grupperade efter fraud fält – Det här diagrammet visar oss andelen dollarbelopp av bedrägliga transaktioner jämfört med det totala dollarbeloppet för transaktioner i en viss stat.
• Totalt antal transaktioner per försäkringsbolag, grupperat efter fraud fält – Det här diagrammet visar hur många anspråk som lämnats in för varje försäkringsbolag och hur många av dem som är bedrägliga.

• Den totala summan av bedrägliga transaktioner per stat som visas på en USA-karta – Det här diagrammet visar bara de bedrägliga transaktionerna och visar de totala avgifterna för dessa transaktioner per stat på kartan. Den mörkare blå nyansen indikerar högre totala laddningar. Vi kan ytterligare analysera detta per stad inom den staten och postnummer med staden för att bättre förstå trenderna.

Städa upp

För att förhindra framtida avgifter för ditt AWS-konto, radera resurserna som du tillhandahållit i konfigurationen genom att följa instruktionerna i Rengöringsavdelning i vår repo.

Slutsats

I denna tvådelade serie såg vi hur man bygger en end-to-end IDP-pipeline med liten eller ingen ML-erfarenhet. Vi undersökte ett användningsfall för skadehantering inom försäkringsbranschen och hur IDP kan hjälpa till att automatisera detta användningsfall med hjälp av tjänster som Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical och Amazon A2I. I del 1 visade vi hur man använder AWS AI-tjänster för dokumentextraktion. I del 2 utökade vi extraktionsfasen och utförde databerikning. Slutligen utökade vi den strukturerade data som extraherades från IDP för ytterligare analyser och skapade visualiseringar för att upptäcka bedrägliga påståenden med hjälp av AWS Analytics-tjänster.

Vi rekommenderar att du granskar säkerhetsdelarna i amazontext, Amazon Comprehendoch Amazon A2I dokumentation och följa de riktlinjer som tillhandahålls. För att lära dig mer om prissättningen av lösningen, granska prisinformationen för amazontext, Amazon Comprehendoch Amazon A2I.

Om författarna

Chinmayee Rane är en AI/ML Specialist Solutions Architect på Amazon Web Services. Hon brinner för tillämpad matematik och maskininlärning. Hon fokuserar på att designa intelligenta dokumentbehandlingslösningar för AWS-kunder. Utanför jobbet tycker hon om att dansa salsa och bachata.

Uday Narayanan är en Analytics Specialist Solutions Architect på AWS. Han tycker om att hjälpa kunder att hitta innovativa lösningar på komplexa affärsutmaningar. Hans kärnområden är dataanalys, big data-system och maskininlärning. På fritiden tycker han om att spela sport, titta på tv-program och att resa.

Sonali Sahu leder teamet Intelligent Document Processing AI/ML Solutions Architect på Amazon Web Services. Hon är en passionerad tenofil och tycker om att arbeta med kunder för att lösa komplexa problem med hjälp av innovation. Hennes kärnfokus är artificiell intelligens och maskininlärning för intelligent dokumentbehandling.