Intelligens dokumentumfeldolgozás AWS AI és Analytics szolgáltatásokkal a biztosítási ágazatban: 2. rész

In rész 1 Ebben a sorozatban az intelligens dokumentumfeldolgozásról (IDP) beszéltünk, és arról, hogy az IDP hogyan tudja felgyorsítani a kárigények feldolgozását a biztosítási ágazatban. Megbeszéltük, hogyan használhatjuk az AWS AI-szolgáltatásokat a követelésdokumentumok és az igazoló dokumentumok pontos kategorizálására. Megbeszéltük azt is, hogyan lehet a biztosítási kárigénycsomagban különféle dokumentumokat, például nyomtatványokat, táblázatokat, vagy speciális dokumentumokat, például számlákat, nyugtákat vagy személyi igazolványokat kivonni. Megvizsgáltuk a régi dokumentum-folyamatok kihívásait, amelyek időigényesek, hibákra hajlamosak, költségesek és nehezen feldolgozhatóak, valamint azt, hogy hogyan használhatja az AWS AI-szolgáltatásokat az IDP-folyamat megvalósításához.

Ebben a bejegyzésben bemutatjuk a fejlett IDP-funkciókat a dokumentumok kinyeréséhez, lekérdezéséhez és gazdagításához. Azt is megvizsgáljuk, hogyan használhatjuk tovább a követelésadatokból kinyert strukturált információkat, hogy betekintést nyerjünk az AWS Analytics és a vizualizációs szolgáltatások segítségével. Kiemeljük, hogy az IDP-ből kinyert strukturált adatok hogyan segíthetnek az AWS Analytics szolgáltatásait használó csalárd követelések ellen.

Megoldás áttekintése

A következő diagram bemutatja a fázisokat, ha az IDP AWS AI-szolgáltatásokat használ. Az 1. részben az IDP munkafolyamat első három fázisát tárgyaltuk. Ebben a bejegyzésben kitérünk a kibontási lépésre és a fennmaradó fázisokra, amelyek magukban foglalják az IDP és az AWS Analytics szolgáltatások integrálását.

Ezeket az analitikai szolgáltatásokat további betekintésre és vizualizációra, valamint az IDP strukturált, normalizált adatainak felhasználásával észleljük a csalárd követeléseket. A következő ábra a megoldás architektúráját mutatja be.

Az ebben a bejegyzésben tárgyalt fázisok a következő kulcsszolgáltatásokat használják:

• Amazon Comprehend Medical egy HIPAA-kompatibilis természetes nyelvi feldolgozási (NLP) szolgáltatás, amely gépi tanulási (ML) modelleket használ, amelyeket előre betanítottak arra, hogy megértsék és kinyerjék az egészségügyi adatokat, például recepteket, eljárásokat vagy diagnózisokat.
• AWS ragasztó az AWS Analytics szolgáltatáscsomag része, és egy kiszolgáló nélküli adatintegrációs szolgáltatás, amely megkönnyíti az adatok felfedezését, előkészítését és kombinálását az elemzéshez, az ML-hez és az alkalmazásfejlesztéshez.
• Amazon RedShift egy másik szolgáltatás az Analytics veremben. Az Amazon Redshift egy teljesen felügyelt, petabyte méretű adattárház szolgáltatás a felhőben.

Előfeltételek

Mielőtt elkezdené, olvassa el a rész 1 az IDP biztosítási használati esetének magas szintű áttekintése, valamint az adatrögzítési és besorolási szakaszok részletei.

A kódmintákkal kapcsolatos további információkért tekintse meg oldalunkat GitHub repó.

Extrakciós fázis

Az 1. részben láthattuk, hogyan lehet az Amazon Textract API-kat használni olyan információk kinyerésére, mint például űrlapok és táblázatok a dokumentumokból, és hogyan lehet elemezni a számlákat és a személyazonosító dokumentumokat. Ebben a bejegyzésben az Amazon Comprehend segítségével továbbfejlesztjük az extrakciós fázist, hogy az egyedi használati esetekre jellemző alapértelmezett és egyéni entitásokat kinyerjük.

A biztosítási szolgáltatók gyakran találkoznak sűrű szöveggel a biztosítási kárigénylési kérelmekben, például a beteg elbocsátását összefoglaló levélben (lásd a következő példaképet). Nehéz lehet automatikusan információt kinyerni az ilyen típusú dokumentumokból, ahol nincs határozott szerkezet. Ennek megoldására a következő módszerekkel kinyerhetjük a legfontosabb üzleti információkat a dokumentumból:

Bontsa ki az alapértelmezett entitásokat az Amazon Comprehend DetectEntities API-val

A következő kódot futtatjuk a minta orvosi átírási dokumentumon:

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

A következő képernyőképen a beviteli szövegben azonosított entitások gyűjteménye látható. A kimenetet lerövidítettük e bejegyzés céljaira. Utal GitHub repo az entitások részletes listájához.

Egyéni entitások kibontása az Amazon Comprehend egyéni entitásfelismeréssel

A válasz a DetectEntities Az API tartalmazza az alapértelmezett entitásokat. Mindazonáltal szeretnénk tudni konkrét entitásértékeket, például a páciens nevét (ezt az alapértelmezett entitás jelöli PERSON), vagy a páciens azonosítóját (az alapértelmezett entitás jelöli). OTHER). Ezen egyéni entitások felismeréséhez egy Amazon Comprehend egyéni entitásfelismerő modellt tanítunk. Javasoljuk, hogy kövesse az egyéni entitásfelismerési modell betanítására és telepítésére vonatkozó átfogó lépéseket GitHub repó.

Az egyéni modell telepítése után használhatjuk a helper funkciót get_entities() egyéni entitások lekéréséhez, mint pl PATIENT_NAME és a PATIENT_D az API válaszból:

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)

Az alábbi képernyőképen az eredményeink láthatók.

Dúsítási fázis

A dokumentumbővítési szakaszban az egészségügyhöz kapcsolódó dokumentumokon gazdagító funkciókat hajtunk végre, hogy értékes betekintést nyerjünk. A következő típusú dúsításokat vizsgáljuk:

• Domainspecifikus nyelv kibontása – Az Amazon Comprehend Medicalt használjuk olyan orvosi ontológiák kinyerésére, mint az ICD-10-CM, RxNorm és SNOMED CT
• Kényes információk törlése – Az Amazon Comprehend szolgáltatást használjuk a személyazonosításra alkalmas adatok (PII) törlésére, az Amazon Comprehend Medicalt pedig a védett egészségügyi információk (PHI) szerkesztésére.

Gyógyászati ​​információk kinyerése strukturálatlan orvosi szövegből

Az olyan dokumentumok, mint az egészségügyi szolgáltatók feljegyzései és a klinikai vizsgálati jelentések, sűrű orvosi szöveget tartalmaznak. A biztosítási kárigények hordozóinak azonosítaniuk kell az ebből a sűrű szövegből kinyert egészségügyi információk közötti kapcsolatokat, és össze kell kapcsolniuk azokat olyan orvosi ontológiákkal, mint az ICD-10-CM, RxNorm és SNOMED CT kódok. Ez nagyon értékes a kárfelvételi, érvényesítési és jóváhagyási munkafolyamatok automatizálásában a biztosítótársaságok számára a kárigényfeldolgozás felgyorsítása és egyszerűsítése érdekében. Nézzük meg, hogyan használhatjuk az Amazon Comprehend Medicalt InferICD10CM API a lehetséges egészségügyi állapotok entitásokként való észlelésére és a kódjaikkal való összekapcsolására:

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

A bemeneti szöveghez, amit az Amazon Textractból tudunk átadni DetectDocumentText API, a InferICD10CM Az API a következő kimenetet adja vissza (a kimenetet a rövidség kedvéért lerövidítettük).

Hasonlóképpen használhatjuk az Amazon Comprehend Medicalt InferRxNorm API azonosítani a gyógyszereket és a InferSNOMEDCT API egészségügyi entitások észlelésére az egészségügyi ellátással kapcsolatos biztosítási dokumentumokon belül.

Végezze el a PII és PHI szerkesztését

A biztosítási kártérítési csomagok sok adatvédelmi megfelelést és szabályozást követelnek meg, mivel mind PII-, mind PHI-adatokat tartalmaznak. A biztosítási szolgáltatók csökkenthetik a megfelelési kockázatot azáltal, hogy törlik az információkat, például a kötvényszámokat vagy a páciens nevét.

Nézzünk egy példát a páciens elbocsátásának összegzésére. Az Amazon Comprehend-et használjuk DetectPiiEntities API a személyazonosításra alkalmas adatok azonosítására a dokumentumban, és a páciens adatainak védelmében az alábbi entitások törlésével:

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)

A következő személyazonosításra alkalmas entitásokat kapjuk a következő válaszában detect_pii_entities() API:

Ezt követően a dokumentumokból észlelt személyazonosításra alkalmas entitásokat a dokumentumból származó entitások határolókeret-geometriájának felhasználásával szerkeszthetjük. Ehhez egy segédeszközt használunk, az úgynevezett amazon-textract-overlayer. További információkért lásd: Textact-Overlayer. A következő képernyőképek egy dokumentumot hasonlítanak össze a szerkesztés előtt és után.

Hasonló az Amazon Comprehendhez DetectPiiEntities API-t is használhatjuk DetectPHI API a PHI adatok kimutatására a vizsgált klinikai szövegben. További információkért lásd: PHI észlelése.

Felülvizsgálati és érvényesítési szakasz

A dokumentum-ellenőrzési és érvényesítési szakaszban most már ellenőrizhetjük, hogy a kárigénycsomag megfelel-e a vállalkozás követelményeinek, mert a csomagban lévő dokumentumokból a korábbi szakaszokból összegyűjtött összes információ birtokunkban van. Ezt úgy tehetjük meg, hogy bevezetünk egy embert a hurokban, amely át tudja tekinteni és érvényesíteni tudja az összes mezőt, vagy csak egy automatikus jóváhagyási folyamatot az alacsony dolláros igények esetén, mielőtt elküldi a csomagot a későbbi alkalmazásokhoz. Tudjuk használni Amazon kiterjesztett AI (Amazon A2I) a biztosítási igények feldolgozásának emberi felülvizsgálati folyamatának automatizálására.

Most, hogy minden szükséges adatot kinyertünk és normalizáltunk a követelések feldolgozásából az IDP AI-szolgáltatásaival, kiterjeszthetjük a megoldást az AWS Analytics szolgáltatásokkal, például az AWS Glue-val és az Amazon Redshift-tel való integrációra, hogy további használati eseteket oldjunk meg, és további elemzéseket és vizualizációkat biztosítsunk.

A csalárd biztosítási igények észlelése

Ebben a bejegyzésben egy szerver nélküli architektúrát valósítunk meg, ahol a kinyert és feldolgozott adatokat egy Data Lake-ben tároljuk, és az ML segítségével csalárd biztosítási igények felderítésére használják. Használjuk Amazon egyszerű tárolási szolgáltatás (Amazon S3) a feldolgozott adatok tárolására. Utána használhatjuk AWS ragasztó or Amazon EMR az adatok megtisztításához és további mezők hozzáadásához, hogy felhasználhatóak legyenek a jelentésekhez és az ML-hez. Ezt követően használjuk Amazon Redshift ML csalásfelderítési ML modell felépítéséhez. Végül jelentéseket készítünk a használatával Amazon QuickSight hogy betekintést nyerjen az adatokba.

Állítsa be az Amazon Redshift külső sémáját

A példa céljaira létrehoztuk a minta adatkészlet az ETL (extract, transform, and load) folyamat kimenetét emulálja, és metaadat-katalógusként használja az AWS ragasztóadat-katalógust. Először létrehozunk egy nevű adatbázist idp_demo az Adatkatalógusban és egy külső sémát az Amazon Redshiftben idp_insurance_demo (lásd a következő kódot). Használunk egy AWS Identity and Access Management (IAM) szerepkör, amely engedélyeket ad az Amazon Redshift fürt számára az Amazon S3 és az Amazon SXNUMX eléréséhez Amazon SageMaker. Az IAM-szerep legkisebb jogosultságokkal történő beállításával kapcsolatos további információkért lásd: Fürtözzön és konfiguráljon beállítást az Amazon Redshift ML adminisztrációjához.

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

Hozzon létre Amazon Redshift külső táblázatot

A következő lépés egy külső táblázat létrehozása az Amazon Redshiftben, amely hivatkozik arra az S3 helyre, ahol a fájl található. Ebben az esetben a fájlunk egy vesszővel elválasztott szövegfájl. Szintén ki akarjuk hagyni a fejléc sort a fájlból, amit a táblázat tulajdonságai részben lehet beállítani. Lásd a következő kódot:

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

Képzési és tesztadatkészletek létrehozása

A külső tábla létrehozása után előkészítjük az adatkészletünket az ML-hez úgy, hogy felosztjuk azt képzési készletre és tesztkészletre. Létrehozunk egy új külső táblát, melynek neve claim_train, amely az összes olyan rekordból áll, amelyek azonosítója <= 85000 a követelések táblájából. Ez az a képzési készlet, amelyen az ML modellünket edzünk.

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

Létrehozunk egy másik külső táblát, melynek neve claim_test amely az összes >85000 azonosítójú rekordból áll, hogy legyen az a tesztkészlet, amelyen teszteljük az ML modellt:

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

Hozzon létre egy ML-modellt az Amazon Redshift ML segítségével

Most elkészítjük a modellt a MODELL LÉTREHOZÁSA parancsot (lásd a következő kódot). Kiválasztjuk a megfelelő oszlopokat a claims_train táblázat, amely meghatározhatja a csalárd tranzakciót. Ennek a modellnek az a célja, hogy előre jelezze a fraud oszlop; ebből adódóan, fraud hozzáadásra kerül az előrejelzési célpontként. A modell betanítása után létrehoz egy nevű függvényt insurance_fraud_model. Ezt a függvényt következtetések levonására használják SQL utasítások futtatása közben, hogy megjósolják az értékét fraud oszlop az új rekordok számára.

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

Értékelje az ML modell mérőszámait

A modell létrehozása után lekérdezéseket futtathatunk a modell pontosságának ellenőrzésére. Használjuk a insurance_fraud_model függvény értékének előrejelzésére fraud oszlop az új rekordok számára. Futtassa a következő lekérdezést a claims_test táblázat a zavaros mátrix létrehozásához:

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;

Csalás észlelése az ML modell segítségével

Az új modell létrehozása után, amikor új követelési adatok kerülnek be az adattárházba vagy az adattóba, használhatjuk a insurance_fraud_model funkció a csalárd tranzakciók kiszámításához. Ezt úgy tesszük, hogy először betöltjük az új adatokat egy ideiglenes táblába. Ezután használjuk a insurance_fraud_model függvény kiszámításához a fraud jelölje be minden új tranzakcióhoz, és helyezze be az adatokat a zászlóval együtt a végső táblázatba, amely ebben az esetben a claims táblázat.

Vizualizálja a követelések adatait

Ha az adatok elérhetők az Amazon Redshiftben, akkor a QuickSight segítségével vizualizációkat készíthetünk. Ezután megoszthatjuk a QuickSight irányítópultjait az üzleti felhasználókkal és elemzőkkel. A QuickSight irányítópult létrehozásához először létre kell hoznia egy Amazon Redshift adatkészletet a QuickSight alkalmazásban. Az utasításokat lásd: Adatkészlet létrehozása adatbázisból.

Az adatkészlet létrehozása után új elemzést hozhat létre a QuickSightban az adatkészlet használatával. Íme néhány általunk készített mintajelentés:

• A követelések teljes száma államonként, a szerint csoportosítva fraud mező – Ez a diagram a csalárd tranzakciók arányát mutatja az adott állam tranzakcióinak teljes számához viszonyítva.
• A követelések teljes dollárértékének összege, csoportosítva a fraud mező – Ez a diagram a csalárd tranzakciók dollárban kifejezett összegének arányát mutatja az adott állam tranzakcióinak teljes dollárösszegéhez viszonyítva.
• Az ügyletek teljes száma biztosítótársaságonként, a szerint csoportosítva fraud mező – Ez a diagram azt mutatja, hogy az egyes biztosítóknál hány kárigényt nyújtottak be, és ezek közül hány csalás.

• A csalárd tranzakciók teljes összege államonként az Egyesült Államok térképén – Ez a diagram csak a csalárd tranzakciókat mutatja, és megjeleníti a tranzakciók teljes díját államonként a térképen. A kék sötétebb árnyalata magasabb össztöltést jelez. Tovább elemezhetjük ezt az adott államon belüli városok és irányítószámok szerint a várossal, hogy jobban megértsük a trendeket.

Tisztítsuk meg

Az AWS-fiókja jövőbeni terheléseinek elkerülése érdekében törölje a beállítás során biztosított erőforrásokat a Tisztító rész a mi repo.

Következtetés

Ebben a kétrészes sorozatban láthattuk, hogyan lehet végponttól végpontig terjedő IDP-folyamatot kis ML-tapasztalattal vagy egyáltalán nem. Megvizsgáltunk egy követelésfeldolgozási esetet a biztosítási ágazatban, és azt, hogy az IDP hogyan segíthet automatizálni ezt a használati esetet olyan szolgáltatásokkal, mint az Amazon Textract, az Amazon Comprehend, az Amazon Comprehend Medical és az Amazon A2I. Az 1. részben bemutattuk, hogyan használhatók az AWS AI szolgáltatások dokumentumkinyerésre. A 2. részben kiterjesztettük a kinyerési fázist és elvégeztük az adatok gazdagítását. Végül kiterjesztettük az IDP-ből kinyert strukturált adatokat további elemzésekhez, és vizualizációkat hoztunk létre az AWS Analytics-szolgáltatások használatával elkövetett csaló követelések észlelésére.

Javasoljuk, hogy tekintse át a biztonsági részeket Amazon szöveg, Amazon Comprehendés Amazon A2I dokumentációt, és kövesse a megadott irányelveket. Ha többet szeretne megtudni a megoldás áráról, tekintse át az árképzés részleteit Amazon szöveg, Amazon Comprehendés Amazon A2I.

A szerzőkről

Chinmayee Rane AI/ML Specialist Solutions Architect az Amazon Web Servicesnél. Szenvedélye az alkalmazott matematika és a gépi tanulás. Arra összpontosít, hogy intelligens dokumentumfeldolgozási megoldásokat tervezzen az AWS-ügyfelek számára. Munkán kívül szeret salsát és bachatát táncolni.

Uday Narayanan az AWS analitikai megoldások specialistája. Szívesen segít ügyfeleinek innovatív megoldásokat találni összetett üzleti kihívásokra. Fő területe az adatelemzés, a big data rendszerek és a gépi tanulás. Szabadidejében szeret sportolni, nagyot néz tévéműsorokat és utazni.

Sonali Sahu az Amazon Web Services Intelligens Dokumentumfeldolgozó AI/ML Solutions Architect csapatának vezetője. Szenvedélyes technofil, és szívesen dolgozik az ügyfelekkel, hogy komplex problémákat oldjon meg az innováció segítségével. Fő területe a mesterséges intelligencia és a gépi tanulás az intelligens dokumentumfeldolgozáshoz.