Arukas dokumenditöötlus AWS AI ja Analyticsi teenustega kindlustussektoris: 2. osa

In Osa 1 Selle seeria osas arutasime intelligentset dokumenditöötlust (IDP) ja seda, kuidas IDP saab kiirendada nõuete töötlemist kindlustussektoris. Arutasime, kuidas saame kasutada AWS AI teenuseid nõuete dokumentide ja tõendavate dokumentide täpseks kategoriseerimiseks. Arutasime ka seda, kuidas kindlustusnõuete paketist välja võtta erinevat tüüpi dokumente, näiteks blankette, tabeleid või eridokumente, nagu arveid, kviitungeid või isikut tõendavaid dokumente. Uurisime päranddokumendiprotsesside väljakutseid, mis on aeganõudvad, veaohtlikud, kallid ja mastaapselt raskesti töödeldavad, ning seda, kuidas saate AWS-i AI-teenuseid oma IDP-konveieri juurutamiseks kasutada.

Selles postituses tutvustame teile IDP täiustatud funktsioone dokumentide väljavõtmiseks, päringute tegemiseks ja rikastamiseks. Samuti uurime, kuidas nõuete andmetest eraldatud struktureeritud teavet edasi kasutada, et saada ülevaadet AWS Analyticsi ja visualiseerimisteenuste abil. Rõhutame, kuidas IDP-st eraldatud struktureeritud andmed võivad aidata AWS Analyticsi teenuseid kasutavate petturlike nõuete vastu.

Lahenduse ülevaade

Järgmine diagramm illustreerib faase, kui IDP kasutab AWS AI teenuseid. 1. osas arutasime IDP töövoo kolme esimest etappi. Selles postituses käsitleme ekstraheerimisetappi ja ülejäänud etappe, mis hõlmavad IDP integreerimist AWS Analyticsi teenustega.

Kasutame neid analüüsiteenuseid täiendava ülevaate saamiseks ja visualiseerimiseks ning petturlike väidete tuvastamiseks, kasutades IDP struktureeritud, normaliseeritud andmeid. Järgnev diagramm illustreerib lahenduse arhitektuuri.

Selles postituses käsitletavad etapid kasutavad järgmisi põhiteenuseid:

• Amazon Comprehend Medical on HIPAA-kõlbulik loomuliku keele töötlemise (NLP) teenus, mis kasutab masinõppe (ML) mudeleid, mis on eelnevalt koolitatud mõistma ja eraldama meditsiinitekstist terviseandmeid, nagu retseptid, protseduurid või diagnoosid.
• AWS liim on osa AWS Analyticsi teenuste virust ja on serverita andmeintegratsiooniteenus, mis muudab andmete avastamise, ettevalmistamise ja kombineerimise analüüsiks, ML-i ja rakenduste arendamiseks lihtsaks.
• Amazoni punane nihe on veel üks teenus Analyticsi virnas. Amazon Redshift on täielikult hallatav petabaitide skaala andmelaoteenus pilves.

Eeldused

Enne alustamist vaadake Osa 1 kõrgetasemelise ülevaate saamiseks IDP-ga kindlustuse kasutamise juhtumist ning andmete kogumise ja klassifitseerimise etappide üksikasjadest.

Koodinäidiste kohta lisateabe saamiseks vaadake meie GitHubi repo.

Ekstraheerimise faas

1. osas nägime, kuidas kasutada Amazon Textracti API-sid, et hankida dokumentidest teavet, nagu vormid ja tabelid, ning kuidas analüüsida arveid ja isikut tõendavaid dokumente. Selles postituses täiustame ekstraheerimisfaasi Amazon Comprehendiga, et ekstraheerida kohandatud kasutusjuhtudele spetsiifilised vaike- ja kohandatud olemid.

Kindlustusandjad puutuvad kindlustusnõuete avaldustes sageli kokku tiheda tekstiga, näiteks patsiendi väljakirjutamise kokkuvõttega (vt järgmist näidispilti). Seda tüüpi dokumentidest, kus puudub kindel struktuur, võib olla keeruline automaatselt teavet hankida. Selle probleemi lahendamiseks saame dokumendist põhilise äriteabe eraldamiseks kasutada järgmisi meetodeid.

Ekstraktige vaikeolemid Amazon Comprehend DetectEntities API abil

Käitame meditsiinilise transkriptsioonidokumendi näidises järgmise koodi:

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

Järgmine ekraanipilt näitab sisendtekstis tuvastatud olemite kogu. Väljundit on selle postituse jaoks lühendatud. Vaadake GitHub repo üksuste üksikasjaliku loendi jaoks.

Ekstraktige kohandatud olemid Amazon Comprehendi kohandatud olemituvastusega

Vastus DetectEntities API sisaldab vaikeoleme. Siiski soovime teada konkreetseid olemi väärtusi, näiteks patsiendi nime (tähistatakse vaikeolemiga PERSON) või patsiendi ID (tähistatakse vaikeolemiga). OTHER). Nende kohandatud olemite äratundmiseks koolitame välja Amazon Comprehendi kohandatud olemituvastusmudeli. Soovitame järgida kõikehõlmavaid samme, kuidas kohandatud olemi tuvastamise mudelit rakenduses välja õpetada ja juurutada GitHubi repo.

Pärast kohandatud mudeli juurutamist saame kasutada abifunktsiooni get_entities() kohandatud olemite hankimiseks nagu PATIENT_NAME ja PATIENT_D API vastusest:

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)

Järgmine ekraanipilt näitab meie tulemusi.

Rikastamise faas

Dokumendi rikastamise etapis teostame tervishoiuga seotud dokumentide rikastamise funktsioone, et saada väärtuslikke teadmisi. Vaatleme järgmisi rikastamise liike:

• Väljavõte domeenispetsiifiline keel - Kasutame Amazon Comprehend Medicalit meditsiinispetsiifiliste ontoloogiate (nt ICD-10-CM, RxNorm ja SNOMED CT) eraldamiseks.
• Redigeerige tundlikku teavet – Kasutame Amazon Comprehendi isikut tuvastava teabe (PII) redigeerimiseks ja Amazon Comprehend Medicalit kaitstud terviseteabe (PHI) redigeerimiseks

Eraldage meditsiiniline teave struktureerimata meditsiinilisest tekstist

Dokumendid, nagu meditsiiniteenuste osutajate märkmed ja kliiniliste uuringute aruanded, sisaldavad tihedat meditsiinilist teksti. Kindlustusnõuete kandjad peavad tuvastama seosed sellest tihedast tekstist eraldatud terviseteabe vahel ja siduma need meditsiiniliste ontoloogiatega, nagu ICD-10-CM, RxNorm ja SNOMED CT koodid. See on väga väärtuslik kindlustusseltside nõuete kogumise, kinnitamise ja kinnitamise töövoogude automatiseerimisel, et kiirendada ja lihtsustada nõuete töötlemist. Vaatame, kuidas saaksime Amazon Comprehend Medicalit kasutada InferICD10CM API võimalike terviseseisundite tuvastamiseks üksustena ja linkimiseks nende koodidega:

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

Sisendteksti jaoks, mille saame Amazon Textractist edasi anda DetectDocumentText API, InferICD10CM API tagastab järgmise väljundi (väljundit on lühiduse mõttes lühendatud).

Samamoodi saame kasutada Amazon Comprehend Medicali InferRxNorm API ravimite ja InferSNOMEDCT API meditsiiniliste üksuste tuvastamiseks tervishoiuga seotud kindlustusdokumentides.

Tehke PII ja PHI redigeerimine

Kindlustusnõuete paketid nõuavad palju privaatsusnõuete järgimist ja eeskirju, kuna need sisaldavad nii PII- kui ka PHI-andmeid. Kindlustusandjad saavad nõuete täitmise riski vähendada, redigeerides teavet, nagu poliisinumbrid või patsiendi nimi.

Vaatame näidet patsiendi väljutamise kokkuvõttest. Kasutame Amazon Comprehendi DetectPiiEntities API, mis tuvastab dokumendis PII-üksused ja kaitseb patsiendi privaatsust, redigeerides need olemid:

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)

Saame vastuses järgmised isikut tõendavad andmed detect_pii_entities() API:

Seejärel saame redigeerida dokumentidest tuvastatud isikuandmete tuvastamise üksused, kasutades dokumendis olevate olemite piirdekasti geomeetriat. Selleks kasutame abivahendit nimega amazon-textract-overlayer. Lisateabe saamiseks vaadake Tekst-ülekiht. Järgmistel ekraanipiltidel võrreldakse dokumenti enne ja pärast redigeerimist.

Sarnaselt Amazon Comprehendiga DetectPiiEntities API, saame kasutada ka DetectPHI API PHI andmete tuvastamiseks uuritavas kliinilises tekstis. Lisateabe saamiseks vaadake Tuvastage PHI.

Ülevaatamise ja kinnitamise etapp

Dokumentide läbivaatamise ja kinnitamise faasis saame nüüd kontrollida, kas kahjunõude pakett vastab ettevõtte nõuetele, sest kogu info on kogutud varasemate etappide paketis olevatest dokumentidest. Saame seda teha, tutvustades tsüklis inimest, kes saab kõik väljad üle vaadata ja kinnitada, või lihtsalt automaatse heakskiitmise protsessi madalate dollarite nõuete jaoks enne paketi saatmist järgnevatele rakendustele. Saame kasutada Amazoni laiendatud AI (Amazon A2I), et automatiseerida kindlustusnõuete töötlemise inimeste läbivaatamise protsessi.

Nüüd, kui oleme IDP jaoks tehisintellekti teenuste abil nõuete töötlemisest kõik vajalikud andmed ekstraheeritud ja normaliseerinud, saame laiendada lahendust integreerimiseks AWS Analyticsi teenustega, nagu AWS Glue ja Amazon Redshift, et lahendada täiendavaid kasutusjuhtumeid ning pakkuda täiendavaid analüüse ja visualiseerimisi.

Avastage petturlikud kindlustusnõuded

Selles postituses rakendame serverita arhitektuuri, kus väljavõetud ja töödeldud andmed salvestatakse andmejärves ning neid kasutatakse ML abil petturlike kindlustusnõuete tuvastamiseks. Me kasutame Amazoni lihtne salvestusteenus (Amazon S3) töödeldud andmete salvestamiseks. Seejärel saame kasutada AWS liim or Amazon EMR andmete puhastamiseks ja täiendavate väljade lisamiseks, et muuta need aruandluse ja ML-i jaoks tarbitavaks. Pärast seda kasutame Amazon Redshift ML luua pettuste tuvastamise ML-mudel. Lõpuks koostame aruandeid kasutades Amazon QuickSight andmetest ülevaate saamiseks.

Seadistage Amazon Redshifti väline skeem

Selle näite jaoks oleme loonud a näidisandmekogum emuleerib ETL-i (ekstrakti, teisendus- ja laadimisprotsessi) väljundit ja kasutab metaandmete kataloogina AWS-i liimiandmete kataloogi. Esiteks loome andmebaasi nimega idp_demo Andmekataloogis ja Amazon Redshifti välisskeemis idp_insurance_demo (vt järgmist koodi). Me kasutame an AWS-i identiteedi- ja juurdepääsuhaldus (IAM) roll, et anda Amazon Redshift klastrile õigused juurdepääsuks Amazon S3 ja Amazon SageMaker. Lisateavet selle IAM-i rolli seadistamise kohta kõige väiksemate õigustega leiate aadressilt Klasterdage ja konfigureerige Amazon Redshift ML-i halduse seadistus.

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

Looge Amazon Redshifti väline tabel

Järgmine samm on luua Amazon Redshiftis väline tabel, mis viitab S3 asukohale, kus fail asub. Sel juhul on meie fail komadega eraldatud tekstifail. Samuti tahame failist vahele jätta päiserea, mida saab seadistada tabeli omaduste jaotises. Vaadake järgmist koodi:

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

Looge koolitus- ja testiandmekogumeid

Pärast välise tabeli loomist valmistame oma andmestiku ML jaoks ette, jagades selle treeningkomplektiks ja testkomplektiks. Loome uue välise tabeli nimega claim_train, mis koosneb kõigist nõuete tabelist ID-ga <= 85000 kirjetest. See on treeningkomplekt, millel treenime oma ML mudelit.

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

Loome teise välise tabeli nimega claim_test mis koosneb kõigist kirjetest ID-ga > 85000, mis on testikomplekt, millega ML-mudelit testime:

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

Looge ML-mudel rakendusega Amazon Redshift ML

Nüüd loome mudeli kasutades LOO MUDEL käsk (vt järgmist koodi). Valime asjakohased veerud claims_train tabel, mis võimaldab määrata petturliku tehingu. Selle mudeli eesmärk on ennustada väärtust fraud veerg; seetõttu fraud lisatakse ennustuse sihtmärgiks. Pärast mudeli väljaõpetamist loob see funktsiooni nimega insurance_fraud_model. Seda funktsiooni kasutatakse SQL-lausete käitamise ajal järelduste tegemiseks, et ennustada parameetri väärtust fraud veergu uute kirjete jaoks.

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

Hinnake ML-mudeli mõõdikuid

Pärast mudeli loomist saame käivitada päringuid, et kontrollida mudeli täpsust. Me kasutame insurance_fraud_model funktsioon väärtuse ennustamiseks fraud veerg uute kirjete jaoks. Käivitage rakenduses järgmine päring claims_test tabel segadusmaatriksi loomiseks:

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;

Tuvastage pettus ML-mudeli abil

Pärast uue mudeli loomist, kui andmelattu või andmejärve sisestatakse uued nõuete andmed, saame kasutada insurance_fraud_model funktsioon petturlike tehingute arvutamiseks. Selleks laadime esmalt uued andmed ajutisse tabelisse. Seejärel kasutame insurance_fraud_model funktsioon arvutamiseks fraud liputage iga uue tehingu jaoks ja sisestage andmed koos lipuga lõpptabelisse, mis antud juhul on claims tabelis.

Visualiseerige nõuete andmed

Kui andmed on Amazon Redshiftis saadaval, saame QuickSighti abil visualiseerida. Seejärel saame jagada QuickSighti armatuurlaudu ärikasutajate ja analüütikutega. QuickSighti armatuurlaua loomiseks peate esmalt QuickSightis looma Amazon Redshifti andmestiku. Juhiste saamiseks vaadake Andmestiku loomine andmebaasist.

Pärast andmestiku loomist saate andmestikku kasutades QuickSightis luua uue analüüsi. Siin on mõned meie loodud näidisaruanded.

• Nõuete koguarv osariigi järgi, rühmitatud alusel fraud väli – See diagramm näitab meile petturlike tehingute osakaalu võrreldes konkreetse osariigi tehingute koguarvuga.
• Nõuete dollari koguväärtuse summa, mis on rühmitatud fraud väli – See diagramm näitab meile petturlike tehingute dollarisummade osakaalu võrreldes konkreetse osariigi tehingute kogusummaga dollarites.
• Tehingute koguarv kindlustusseltsi kohta, rühmitatud fraud väli – See diagramm näitab meile, kui palju nõudeid iga kindlustusseltsi kohta esitati ja kui paljud neist on petturlikud.

• USA kaardil kuvatud pettustehingute kogusumma osariikide kaupa – See diagramm näitab lihtsalt petturlikke tehinguid ja kuvab kaardil nende tehingute kogutasud osariikide kaupa. Sinise tumedam toon näitab suuremat kogutasu. Suundumuste paremaks mõistmiseks saame seda edasi analüüsida selle osariigi linnade ja linna sihtnumbrite kaupa.

Koristage

AWS-i kontolt tulevaste tasude vältimiseks kustutage seadistuses eraldatud ressursid, järgides Puhastusosa meie repos.

Järeldus

Selles kaheosalises seerias nägime, kuidas luua täielik IDP torujuhe vähese või üldse mitte ML-kogemusega. Uurisime kindlustussektoris nõuete töötlemise kasutusjuhtumeid ja seda, kuidas IDP saab aidata seda kasutusjuhtumit automatiseerida, kasutades selliseid teenuseid nagu Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical ja Amazon A2I. 1. osas näitasime, kuidas kasutada AWS AI teenuseid dokumentide väljavõtmiseks. 2. osas pikendasime ekstraheerimise faasi ja viisime läbi andmete rikastamise. Lõpuks laiendasime IDP-st eraldatud struktureeritud andmeid edasise analüüsi jaoks ja lõime visualiseeringud petturlike väidete tuvastamiseks AWS Analyticsi teenuste abil.

Soovitame tutvuda turvalisuse jaotistega Amazoni tekst, Amazoni mõistmineja Amazon A2I dokumentatsiooni ja järgides antud juhiseid. Lahenduse hinnakujunduse kohta lisateabe saamiseks vaadake üle hinnakujunduse üksikasjad Amazoni tekst, Amazoni mõistmineja Amazon A2I.

Autoritest

Chinmayee Rane on AI/ML spetsialistilahenduste arhitekt ettevõttes Amazon Web Services. Ta on kirglik rakendusmatemaatika ja masinõppe vastu. Ta keskendub intelligentsete dokumenditöötluslahenduste kavandamisele AWS-i klientidele. Väljaspool tööd naudib ta salsat ja bachata tantsu.

Uday Narayanan on AWS-i analüüsilahenduste spetsialist. Talle meeldib aidata klientidel leida uuenduslikke lahendusi keerukatele äriprobleemidele. Tema põhivaldkonnad on andmeanalüütika, suurandmesüsteemid ja masinõpe. Vabal ajal meeldib talle sportida, uisapäisa telesaateid vaadata ja reisida.

Sonali Sahu juhib Amazon Web Servicesi intelligentse dokumenditöötluse AI/ML Solutions Architect meeskonda. Ta on kirglik tehnofiil ja naudib koostööd klientidega, et lahendada keerulisi probleeme uuenduste abil. Tema põhivaldkonnaks on tehisintellekt ja masinõpe intelligentseks dokumenditöötluseks.