Älykäs asiakirjojen käsittely AWS AI- ja Analytics-palveluilla vakuutusalalla: Osa 2

In Osa 1 Tässä sarjassa keskustelimme älykkäästä dokumenttien käsittelystä (IDP) ja siitä, kuinka IDP voi nopeuttaa korvausten käsittelyä vakuutusalalla. Keskustelimme siitä, kuinka voimme käyttää AWS AI -palveluita korvausasiakirjojen ja tositteiden täsmälliseen luokitteluun. Keskustelimme myös siitä, miten vakuutuskorvauspaketissa voidaan poimia erityyppisiä asiakirjoja, kuten lomakkeita, taulukoita tai erikoisasiakirjoja, kuten laskuja, kuitteja tai henkilöllisyystodistuksia. Pohdimme vanhojen dokumenttiprosessien haasteita, jotka ovat aikaa vieviä, virhealttiita, kallista ja vaikeasti prosessoitavissa, sekä sitä, kuinka voit käyttää AWS AI -palveluita IDP-putken toteuttamiseen.

Tässä viestissä opastamme sinut edistyneiden IDP-ominaisuuksien läpi asiakirjojen poimimiseen, kyselyihin ja rikastamiseen. Tutkimme myös, kuinka vaatimustiedoista poimittuja strukturoituja tietoja voidaan käyttää edelleen saadakseen oivalluksia AWS Analyticsin ja visualisointipalvelujen avulla. Korostamme, kuinka IDP:stä poimitut strukturoidut tiedot voivat auttaa torjumaan AWS Analytics -palveluita käyttäviä vilpillisiä vaatimuksia.

Ratkaisun yleiskatsaus

Seuraava kaavio havainnollistaa vaiheita, jos IDP käyttää AWS AI -palveluita. Osassa 1 keskustelimme IDP-työnkulun kolmesta ensimmäisestä vaiheesta. Tässä viestissä laajennamme purkamisvaihetta ja muita vaiheita, joihin kuuluu IDP:n integrointi AWS Analytics -palveluihin.

Käytämme näitä analytiikkapalveluita lisätietoihin ja visualisointeihin sekä vilpillisten vaatimusten havaitsemiseen käyttämällä IDP:n jäsenneltyä, normalisoitua dataa. Seuraava kaavio havainnollistaa ratkaisun arkkitehtuuria.

Tässä viestissä käsittelemämme vaiheet käyttävät seuraavia avainpalveluita:

• Amazon ymmärtää lääketieteen on HIPAA-kelpoinen luonnollisen kielen käsittelypalvelu (NLP), joka käyttää koneoppimismalleja (ML), jotka on valmiiksi koulutettu ymmärtämään ja poimimaan terveystietoja lääketieteellisistä teksteistä, kuten reseptejä, toimenpiteitä tai diagnooseja.
• AWS-liima on osa AWS Analytics -palvelupinoa, ja se on palvelimeton tietojen integrointipalvelu, jonka avulla on helppo löytää, valmistella ja yhdistää tietoja analytiikkaa, ML- ja sovelluskehitystä varten.
• Amazonin punainen siirto on toinen palvelu Analytics-pinossa. Amazon Redshift on täysin hallittu, petatavuinen tietovarastopalvelu pilvessä.

Edellytykset

Ennen kuin aloitat, katso Osa 1 korkean tason yleiskatsauksen vakuutuksen käyttötapauksesta IDP:n kanssa ja tietoja tiedonkeruu- ja luokitteluvaiheista.

Lisätietoja koodinäytteistä saat osoitteestamme GitHub-repo.

Uuttovaihe

Osassa 1 näimme, kuinka Amazon Textract -sovellusliittymiä käytetään tietojen, kuten lomakkeiden ja taulukoiden, poimimiseen asiakirjoista ja kuinka analysoidaan laskuja ja henkilöllisyystodistuksia. Tässä viestissä tehostamme purkamisvaihetta Amazon Comprehendin avulla poimimaan oletus- ja mukautettuja entiteettejä mukautetuille käyttötapauksille.

Vakuutusyhtiöt törmäävät usein tiheään tekstiin vakuutuskorvaushakemuksissa, kuten potilaan kotiutusyhteenvetokirjeessä (katso seuraava esimerkkikuva). Tietojen automaattinen poimiminen sellaisista asiakirjoista, joissa ei ole tarkkaa rakennetta, voi olla vaikeaa. Tämän ratkaisemiseksi voimme käyttää seuraavia menetelmiä tärkeimpien liiketoimintatietojen poimimiseen asiakirjasta:

Pura oletuskokonaisuudet Amazon Comprehend DetectEntities API:lla

Suoritamme seuraavan koodin lääketieteellisen transkription malliasiakirjassa:

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

Seuraava kuvakaappaus näyttää kokoelman syöttötekstissä tunnistettuja entiteettejä. Tulosta on lyhennetty tätä viestiä varten. Viittaavat GitHub repo yksityiskohtaisen luettelon kokonaisuuksista.

Pura mukautettuja kokonaisuuksia Amazon Comprehend mukautetun kokonaisuuden tunnistuksen avulla

Vastaus DetectEntities API sisältää oletuskokonaisuudet. Olemme kuitenkin kiinnostuneita tietämään tietyt entiteettiarvot, kuten potilaan nimen (merkitty oletusentiteetillä PERSON) tai potilaan tunnus (merkitty oletuskokonaisuudella). OTHER). Näiden mukautettujen entiteettien tunnistamiseksi koulutamme Amazon Comprehend mukautetun entiteetin tunnistusmallin. Suosittelemme noudattamaan kattavia vaiheita mukautetun entiteetin tunnistusmallin kouluttamiseen ja käyttöönottoon GitHub-repo.

Kun olemme ottaneet käyttöön mukautetun mallin, voimme käyttää aputoimintoa get_entities() hakeaksesi mukautettuja kokonaisuuksia, kuten PATIENT_NAME ja PATIENT_D API-vastauksesta:

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)

Seuraava kuvakaappaus näyttää tuloksemme.

Rikastusvaihe

Asiakirjojen rikastusvaiheessa suoritamme terveydenhuoltoon liittyvien asiakirjojen rikastamista arvokkaiden näkemysten saamiseksi. Tarkastelemme seuraavia rikastustyyppejä:

• Pura verkkotunnuskohtainen kieli – Käytämme Amazon Comprehend Medicalia lääketieteellisten ontologioiden, kuten ICD-10-CM, RxNorm ja SNOMED CT, poimimiseen.
• Poista arkaluontoiset tiedot – Käytämme Amazon Comprehendia poistamaan henkilökohtaisia ​​tunnistetietoja (PII) ja Amazon Comprehend Medicalia suojattujen terveystietojen (PHI) poistamiseen.

Poimi lääketieteelliset tiedot jäsentämättömästä lääketieteellisestä tekstistä

Asiakirjat, kuten lääketieteen tarjoajien muistiinpanot ja kliiniset tutkimusraportit, sisältävät tiheää lääketieteellistä tekstiä. Vakuutuskorvausten harjoittajien on tunnistettava tästä tiheästä tekstistä poimittujen terveystietojen väliset suhteet ja linkitettävä ne lääketieteellisiin ontologioihin, kuten ICD-10-CM, RxNorm ja SNOMED CT -koodeihin. Tämä on erittäin arvokasta vakuutusyhtiöiden korvausten keräämisen, validoinnin ja hyväksymisen työnkulkujen automatisoinnissa, mikä nopeuttaa ja yksinkertaistaa korvausten käsittelyä. Katsotaanpa, kuinka voimme käyttää Amazon Comprehend Medicalia InferICD10CM API tunnistaa mahdolliset sairaudet kokonaisuuksina ja linkittää ne koodiinsa:

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

Syötetekstiä varten, jonka voimme välittää Amazon Textractista DetectDocumentText API, InferICD10CM API palauttaa seuraavan tulosteen (tulosta on lyhennetty lyhennyksen vuoksi).

Samoin voimme käyttää Amazon Comprehend Medicalia InferRxNorm API tunnistaa lääkkeet ja InferSNOMEDCT API tunnistaa lääketieteellisiä kokonaisuuksia terveydenhuoltoon liittyvistä vakuutusasiakirjoista.

Suorita PII- ja PHI-muokkaus

Vakuutuskorvauspaketit vaativat paljon yksityisyydensuojan noudattamista ja säännöksiä, koska ne sisältävät sekä PII- että PHI-tietoja. Vakuutusyhtiöt voivat vähentää noudattamisriskiä poistamalla tiedot, kuten vakuutusnumerot tai potilaan nimi.

Katsotaanpa esimerkkiä potilaan kotiutusyhteenvedosta. Käytämme Amazon Comprehendia DetectPiiEntities API tunnistaa PII-entiteetit asiakirjassa ja suojaa potilaan yksityisyyttä poistamalla nämä entiteetit:

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)

Saamme seuraavat PII-entiteetit vastauksessa detect_pii_entities() API:

Voimme sitten poistaa asiakirjoista havaitut PII-entiteetit käyttämällä asiakirjan entiteettien rajauslaatikon geometriaa. Tätä varten käytämme aputyökalua nimeltä amazon-textract-overlayer. Lisätietoja on kohdassa Teksti-peittokerros. Seuraavissa kuvakaappauksissa verrataan asiakirjaa ennen ja jälkeen editoinnin.

Samanlainen kuin Amazon Comprehend DetectPiiEntities API, voimme myös käyttää DetectPHI API PHI-tietojen havaitsemiseen tutkittavasta kliinisestä tekstistä. Lisätietoja on kohdassa Tunnista PHI.

Tarkastus- ja validointivaihe

Asiakirjojen tarkistus- ja validointivaiheessa voimme nyt varmistaa, vastaako korvauspaketti yrityksen vaatimuksia, koska meillä on kaikki tiedot, jotka on kerätty paketissa olevista asiakirjoista aikaisemmista vaiheista. Voimme tehdä tämän ottamalla käyttöön ihmisen, joka voi tarkistaa ja vahvistaa kaikki kentät tai vain automaattisen hyväksymisprosessin alhaisen dollarin vaatimuksille ennen paketin lähettämistä myöhempien sovellusten käyttöön. Voimme käyttää Amazonin laajennettu AI (Amazon A2I) automatisoimaan vakuutuskorvausten käsittelyn ihmisen suorittaman tarkistusprosessin.

Nyt kun meillä on kaikki tarvittavat tiedot poimittu ja normalisoitu vaatimuskäsittelystä käyttämällä IDP:n tekoälypalveluita, voimme laajentaa ratkaisua integroitumaan AWS Analytics -palveluihin, kuten AWS Glue ja Amazon Redshift, ratkaistaksemme lisäkäyttötapauksia ja tarjotaksemme lisää analyysejä ja visualisointeja.

Tunnista vilpilliset vakuutuskorvaukset

Tässä postauksessa toteutamme palvelimettoman arkkitehtuurin, jossa poimitut ja käsitellyt tiedot tallennetaan datajärveen ja niitä käytetään petollisten vakuutuskorvausten havaitsemiseen ML:n avulla. Käytämme Amazonin yksinkertainen tallennuspalvelu (Amazon S3) tallentaaksesi käsitellyt tiedot. Voimme sitten käyttää AWS-liima or Amazonin EMR puhdistaa tiedot ja lisätä kenttiä, jotta ne voidaan kuluttaa raportointia ja ML:ää varten. Sen jälkeen käytämme Amazon Redshift ML petosten havaitsemisen ML-mallin rakentamiseen. Lopuksi rakennamme raportteja käyttämällä Amazon QuickSight saada tietoa tiedoista.

Asenna ulkoinen Amazon Redshift -skeema

Tätä esimerkkiä varten olemme luoneet a näytetiedosto emuloi ETL-prosessin tulosta (extract, transform and load) ja käyttää AWS Glue Data Catalogia metatietoluettelona. Ensin luodaan tietokanta nimeltä idp_demo Data Catalogissa ja ulkoinen skeema Amazon Redshiftissä nimeltä idp_insurance_demo (katso seuraava koodi). Käytämme an AWS-henkilöllisyyden ja käyttöoikeuksien hallinta (IAM) -rooli myöntää Amazon Redshift -klusterille oikeudet käyttää Amazon S3:a ja Amazon Sage Maker. Lisätietoja tämän IAM-roolin määrittämisestä vähiten oikeuksilla on kohdassa Klusteroi ja määritä asetukset Amazon Redshift ML -hallintaa varten.

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

Luo ulkoinen Amazon Redshift -taulukko

Seuraava vaihe on luoda Amazon Redshiftissä ulkoinen taulukko, joka viittaa S3-sijaintiin, jossa tiedosto sijaitsee. Tässä tapauksessa tiedostomme on pilkuilla erotettu tekstitiedosto. Haluamme myös ohittaa tiedostosta otsikkorivin, joka voidaan määrittää taulukon ominaisuudet -osiossa. Katso seuraava 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');

Luo koulutus- ja testitietojoukkoja

Kun olemme luoneet ulkoisen taulukon, valmistelemme tietojoukkomme ML:ää varten jakamalla sen harjoitusjoukkoon ja testijoukkoon. Luomme uuden ulkoisen taulukon nimeltä claim_train, joka koostuu kaikista korvaustaulukon tietueista, joiden tunnus on <= 85000. Tämä on koulutussarja, jolla harjoitamme ML-malliamme.

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

Luomme toisen ulkoisen taulukon nimeltä claim_test joka koostuu kaikista tietueista, joiden ID > 85000 on testijoukko, jolla testaamme ML-mallia:

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

Luo ML-malli Amazon Redshift ML:n avulla

Nyt luomme mallin käyttämällä Luo malli komento (katso seuraava koodi). Valitsemme asiaankuuluvat sarakkeet claims_train taulukko, joka voi määrittää vilpillisen tapahtuman. Tämän mallin tavoitteena on ennustaa arvo fraud sarake; siksi, fraud lisätään ennustekohteeksi. Kun malli on koulutettu, se luo funktion nimeltä insurance_fraud_model. Tätä funktiota käytetään päätelmien tekemiseen suoritettaessa SQL-käskyjä arvon ennustamiseksi fraud sarake uusia tietueita varten.

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

Arvioi ML-mallin mittareita

Kun olemme luoneet mallin, voimme suorittaa kyselyitä mallin tarkkuuden tarkistamiseksi. Käytämme insurance_fraud_model funktion arvon ennustamiseen fraud sarake uusia tietueita varten. Suorita seuraava kysely claims_test taulukko hämmennysmatriisin luomiseksi:

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;

Tunnista petokset ML-mallin avulla

Kun olemme luoneet uuden mallin, kun uusia vaatimustietoja lisätään tietovarastoon tai datajärveen, voimme käyttää insurance_fraud_model toiminto laskea vilpilliset tapahtumat. Teemme tämän lataamalla ensin uudet tiedot väliaikaiseen taulukkoon. Sitten käytämme insurance_fraud_model funktio laskeaksesi fraud lippu jokaiselle uudelle tapahtumalle ja lisää tiedot lipun kanssa lopputaulukkoon, joka tässä tapauksessa on claims pöytä.

Visualisoi vaatimustiedot

Kun tiedot ovat saatavilla Amazon Redshiftissä, voimme luoda visualisointeja QuickSightin avulla. Voimme sitten jakaa QuickSight-hallintapaneelit yrityskäyttäjien ja analyytikoiden kanssa. QuickSight-hallintapaneelin luomiseksi sinun on ensin luotava Amazon Redshift -tietojoukko QuickSightissa. Katso ohjeet kohdasta Tietojoukon luominen tietokannasta.

Kun olet luonut tietojoukon, voit luoda uuden analyysin QuickSightissa tietojoukon avulla. Seuraavassa on joitain esimerkkiraportteja, jotka olemme luoneet:

• Vaatimusten kokonaismäärä osavaltioittain ryhmiteltynä fraud ala – Tämä kaavio näyttää meille vilpillisten tapahtumien osuuden suhteessa tapahtumien kokonaismäärään tietyssä osavaltiossa.
• Vaatimusten dollarin kokonaisarvon summa ryhmiteltynä fraud ala – Tämä kaavio näyttää meille vilpillisten tapahtumien dollarimäärän osuuden suhteessa tapahtumien kokonaismäärään tietyssä osavaltiossa.
• Tapahtumien kokonaismäärä vakuutusyhtiötä kohden ryhmiteltynä fraud ala – Tämä kaavio näyttää meille, kuinka monta korvausvaatimusta kullekin vakuutusyhtiölle on tehty ja kuinka moni niistä on vilpillisiä.

• Vilpillisten tapahtumien kokonaissumma osavaltioittain Yhdysvaltain kartalla – Tämä kaavio näyttää vain vilpilliset tapahtumat ja näyttää näiden tapahtumien kokonaiskulut osavaltioittain kartalla. Sinisen tummempi sävy osoittaa korkeampia kokonaislatauksia. Voimme analysoida tätä tarkemmin kyseisen osavaltion kaupunkien ja postinumeroiden mukaan kaupungin kanssa ymmärtääksemme suuntauksia paremmin.

Puhdistaa

Estä AWS-tilisi tulevien maksujen syntyminen poistamalla asennuksessa määrittämäsi resurssit noudattamalla Puhdistusosio meidän repossa.

Yhteenveto

Tässä kaksiosaisessa sarjassa näimme kuinka rakentaa päästä päähän IDP-putki ilman tai vähän ML-kokemusta. Tutkimme korvauskäsittelyn käyttötapausta vakuutusalalla ja kuinka IDP voi auttaa automatisoimaan tämän käyttötapauksen käyttämällä palveluita, kuten Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical ja Amazon A2I. Osassa 1 osoitimme, kuinka AWS AI -palveluita käytetään asiakirjojen poimimiseen. Osassa 2 pidensimme poimintavaihetta ja suoritimme tietojen rikastamisen. Lopuksi laajensimme IDP:stä poimittua strukturoitua dataa lisäanalytiikkaa varten ja loimme visualisointeja vilpillisten vaatimusten havaitsemiseksi AWS Analytics -palveluiden avulla.

Suosittelemme tutustumaan tietoturvaosioihin Amazonin teksti, Amazonin käsitysja Amazon A2I dokumentaatiota ja noudattamalla annettuja ohjeita. Saat lisätietoja ratkaisun hinnoittelusta tutustumalla tuotteen hinnoitteluun Amazonin teksti, Amazonin käsitysja Amazon A2I.

Tietoja Tekijät

Chinmayee Rane on AI/ML Specialist Solutions -arkkitehti Amazon Web Servicesissä. Hän on intohimoinen soveltavaan matematiikkaan ja koneoppimiseen. Hän keskittyy älykkäiden asiakirjojen käsittelyratkaisujen suunnitteluun AWS-asiakkaille. Työn ulkopuolella hän harrastaa salsaa ja bachata-tanssia.

Uday Narayanan on Analyticsin asiantuntijaratkaisujen arkkitehti AWS:ssä. Hän haluaa auttaa asiakkaita löytämään innovatiivisia ratkaisuja monimutkaisiin liiketoiminnan haasteisiin. Hänen painopistealueensa ovat data-analytiikka, isot datajärjestelmät ja koneoppiminen. Vapaa-ajallaan hän nauttii urheilusta, televisio-ohjelmien katselusta ja matkustamisesta.

Sonali Sahu johtaa Intelligent Document Processing AI/ML Solutions Architect -tiimiä Amazon Web Services -palvelussa. Hän on intohimoinen teknofiili ja nauttii työskentelystä asiakkaiden kanssa monimutkaisten ongelmien ratkaisemiseksi innovaatioiden avulla. Hänen painopistealueensa ovat tekoäly ja koneoppiminen älykkään asiakirjojen käsittelyyn.