การประมวลผลเอกสารอัจฉริยะด้วยบริการ AWS AI และ Analytics ในอุตสาหกรรมประกันภัย: ตอนที่ 2

In 1 หมายเลข ในชุดนี้ เราได้พูดถึงการประมวลผลเอกสารอัจฉริยะ (IDP) และวิธีที่ IDP สามารถเร่งการประมวลผลการเคลมกรณีการใช้งานในอุตสาหกรรมประกันภัย เราได้พูดคุยถึงวิธีที่เราสามารถใช้บริการ AWS AI เพื่อจัดหมวดหมู่เอกสารการเรียกร้องได้อย่างถูกต้องพร้อมกับเอกสารสนับสนุน นอกจากนี้เรายังกล่าวถึงวิธีการดึงเอกสารประเภทต่างๆ ในชุดเคลมประกัน เช่น แบบฟอร์ม ตาราง หรือเอกสารเฉพาะทาง เช่น ใบแจ้งหนี้ ใบเสร็จ หรือเอกสารแสดงตน เราตรวจสอบความท้าทายในกระบวนการเอกสารแบบเดิม ซึ่งใช้เวลานาน เกิดข้อผิดพลาด มีราคาแพง และดำเนินการตามขนาดได้ยาก และคุณจะใช้บริการ AWS AI เพื่อช่วยปรับใช้ไปป์ไลน์ IDP ของคุณได้อย่างไร

ในโพสต์นี้ เราจะแนะนำคุณเกี่ยวกับฟีเจอร์ IDP ขั้นสูงสำหรับการดึงเอกสาร การสืบค้น และการตกแต่ง เรายังพิจารณาถึงวิธีการใช้ข้อมูลที่มีโครงสร้างที่ดึงออกมาจากข้อมูลการอ้างสิทธิ์เพิ่มเติมเพื่อรับข้อมูลเชิงลึกโดยใช้ AWS Analytics และบริการการแสดงภาพ เราเน้นว่าข้อมูลที่แยกโครงสร้างจาก IDP สามารถช่วยป้องกันการอ้างสิทธิ์ที่เป็นการฉ้อโกงโดยใช้บริการ AWS Analytics ได้อย่างไร

ภาพรวมโซลูชัน

ไดอะแกรมต่อไปนี้แสดงขั้นตอนต่างๆ หาก IDP ใช้บริการ AWS AI ในตอนที่ 1 เราได้พูดถึงสามขั้นตอนแรกของเวิร์กโฟลว์ IDP ในโพสต์นี้ เราขยายขั้นตอนการแยกและขั้นตอนที่เหลือ ซึ่งรวมถึงการรวม IDP กับบริการ AWS Analytics

เราใช้บริการวิเคราะห์เหล่านี้สำหรับข้อมูลเชิงลึกและการแสดงภาพเพิ่มเติม และเพื่อตรวจจับการอ้างสิทธิ์ที่เป็นการฉ้อโกงโดยใช้ข้อมูลที่มีโครงสร้างและเป็นมาตรฐานจาก IDP ไดอะแกรมต่อไปนี้แสดงสถาปัตยกรรมโซลูชัน

ขั้นตอนที่เราพูดถึงในโพสต์นี้ใช้บริการหลักดังต่อไปนี้:

• Amazon Comprehen Medical เป็นบริการประมวลผลภาษาธรรมชาติ (NLP) ที่มีสิทธิ์ HIPAA ที่ใช้โมเดลการเรียนรู้ของเครื่อง (ML) ที่ได้รับการฝึกอบรมล่วงหน้าเพื่อทำความเข้าใจและดึงข้อมูลด้านสุขภาพจากข้อความทางการแพทย์ เช่น ใบสั่งยา หัตถการ หรือการวินิจฉัย
• AWS กาว เป็นส่วนหนึ่งของกองบริการ AWS Analytics และเป็นบริการการรวมข้อมูลแบบไร้เซิร์ฟเวอร์ที่ทำให้ง่ายต่อการค้นหา จัดเตรียม และรวมข้อมูลสำหรับการวิเคราะห์ ML และการพัฒนาแอปพลิเคชัน
• อเมซอน Redshift เป็นบริการอื่นในกลุ่ม Analytics Amazon Redshift เป็นบริการคลังข้อมูลขนาดเพตะไบต์ที่มีการจัดการเต็มรูปแบบในระบบคลาวด์

เบื้องต้น

ก่อนที่คุณจะเริ่มต้น โปรดดูที่ 1 หมายเลข สำหรับภาพรวมระดับสูงของกรณีการใช้งานประกันภัยกับ IDP และรายละเอียดเกี่ยวกับการเก็บข้อมูลและขั้นตอนการจำแนกประเภท

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวอย่างโค้ด โปรดดูที่ ที่เก็บ GitHub

ขั้นตอนการสกัด

ในส่วนที่ 1 เราได้เห็นวิธีการใช้ Amazon Texttract API เพื่อดึงข้อมูล เช่น แบบฟอร์มและตารางจากเอกสาร และวิธีการวิเคราะห์ใบแจ้งหนี้และเอกสารระบุตัวตน ในโพสต์นี้ เราปรับปรุงขั้นตอนการแยกข้อมูลด้วย Amazon Comprehend เพื่อแยกเอนทิตีเริ่มต้นและเอนทิตีแบบกำหนดเองเฉพาะสำหรับกรณีการใช้งานแบบกำหนดเอง

ผู้ให้บริการประกันภัยมักพบข้อความหนาแน่นในใบสมัครเรียกร้องค่าสินไหมทดแทน เช่น จดหมายสรุปการจำหน่ายของผู้ป่วย (ดูภาพตัวอย่างต่อไปนี้) อาจเป็นเรื่องยากที่จะดึงข้อมูลจากเอกสารประเภทดังกล่าวโดยอัตโนมัติซึ่งไม่มีโครงสร้างที่แน่นอน เพื่อแก้ไขปัญหานี้ เราสามารถใช้วิธีการต่อไปนี้เพื่อดึงข้อมูลทางธุรกิจที่สำคัญจากเอกสาร:

แยกเอนทิตีเริ่มต้นด้วย Amazon Comprehend DetectEntities API

เราเรียกใช้รหัสต่อไปนี้ในเอกสารการถอดความทางการแพทย์ตัวอย่าง:

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

ภาพหน้าจอต่อไปนี้แสดงคอลเล็กชันของเอนทิตีที่ระบุในข้อความอินพุต เอาต์พุตได้รับการย่อให้สั้นลงเพื่อจุดประสงค์ของโพสต์นี้ อ้างถึง repo GitHub สำหรับรายการรายละเอียดของหน่วยงาน

แยกเอนทิตีแบบกำหนดเองด้วยการรับรู้เอนทิตีแบบกำหนดเองของ Amazon Comprehend

คำตอบจาก DetectEntities API รวมเอนทิตีเริ่มต้น อย่างไรก็ตาม เราสนใจที่จะทราบค่าเอนทิตีที่เฉพาะเจาะจง เช่น ชื่อของผู้ป่วย (แสดงโดยเอนทิตีเริ่มต้น PERSON) หรือ ID ของผู้ป่วย (แสดงโดยเอนทิตีเริ่มต้น OTHER). เพื่อให้รู้จักเอนทิตีแบบกำหนดเองเหล่านี้ เราฝึกอบรมโมเดลตัวรู้จำเอนทิตีแบบกำหนดเองของ Amazon Comprehend เราแนะนำให้ทำตามขั้นตอนที่ครอบคลุมเกี่ยวกับวิธีการฝึกอบรมและปรับใช้แบบจำลองการรับรู้เอนทิตีแบบกำหนดเองใน ที่เก็บ GitHub

หลังจากที่เราปรับใช้โมเดลแบบกำหนดเอง เราก็สามารถใช้ฟังก์ชันตัวช่วย get_entities() เพื่อดึงเอนทิตีที่กำหนดเองเช่น PATIENT_NAME และ PATIENT_D จากการตอบสนอง API:

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)

ภาพหน้าจอต่อไปนี้แสดงผลลัพธ์ของเรา

ขั้นตอนการเสริมสิริมงคล

ในขั้นตอนการทำให้สมบูรณ์ของเอกสาร เราดำเนินการฟังก์ชันการตกแต่งในเอกสารที่เกี่ยวข้องกับการดูแลสุขภาพเพื่อดึงข้อมูลเชิงลึกอันมีค่า เราดูประเภทของการตกแต่งต่อไปนี้:

• แยกภาษาเฉพาะโดเมน – เราใช้ Amazon Comprehend Medical เพื่อแยก ontology เฉพาะทางการแพทย์ เช่น ICD-10-CM, RxNorm และ SNOMED CT
• แก้ไขข้อมูลที่ละเอียดอ่อน – เราใช้ Amazon Comprehend เพื่อตรวจทานข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) และ Amazon Comprehend Medical สำหรับการปกปิดข้อมูลด้านสุขภาพที่ได้รับการคุ้มครอง (PHI)

ดึงข้อมูลทางการแพทย์จากข้อความทางการแพทย์ที่ไม่มีโครงสร้าง

เอกสารต่างๆ เช่น บันทึกของผู้ให้บริการทางการแพทย์และรายงานการทดลองทางคลินิก รวมถึงข้อความทางการแพทย์ที่หนาแน่น ผู้ให้บริการเคลมประกันจำเป็นต้องระบุความสัมพันธ์ระหว่างข้อมูลสุขภาพที่ดึงมาจากข้อความที่หนาแน่นนี้ และเชื่อมโยงข้อมูลเหล่านี้กับ ontology ทางการแพทย์ เช่น รหัส ICD-10-CM, RxNorm และ SNOMED CT สิ่งนี้มีค่ามากในการดำเนินการเก็บเคลมอัตโนมัติ การตรวจสอบ และการอนุมัติเวิร์กโฟลว์สำหรับบริษัทประกันภัยเพื่อเร่งรัดและทำให้การประมวลผลการเคลมง่ายขึ้น มาดูกันว่าเราจะใช้ Amazon Comprehend Medical ได้อย่างไร InferICD10CM API เพื่อตรวจหาเงื่อนไขทางการแพทย์ที่เป็นไปได้ในฐานะหน่วยงานและเชื่อมโยงเข้ากับรหัส:

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

สำหรับข้อความเข้า ซึ่งเราสามารถส่งผ่านจาก Amazon Texttract . ได้ DetectDocumentText API, การ InferICD10CM API ส่งคืนเอาต์พุตต่อไปนี้ (เอาต์พุตถูกย่อให้สั้น)

ในทำนองเดียวกัน เราสามารถใช้ Amazon Comprehend Medical InferRxNorm API เพื่อระบุยาและ InferSNOMEDCT API เพื่อตรวจหาหน่วยงานทางการแพทย์ภายในเอกสารประกันที่เกี่ยวข้องกับการดูแลสุขภาพ

ดำเนินการแก้ไข PII และ PHI

แพ็คเกจการเคลมประกันต้องมีการปฏิบัติตามข้อกำหนดและข้อบังคับด้านความเป็นส่วนตัวเป็นจำนวนมาก เนื่องจากมีทั้งข้อมูล PII และ PHI ผู้ให้บริการประกันภัยสามารถลดความเสี่ยงในการปฏิบัติตามข้อกำหนดได้โดยการแก้ไขข้อมูล เช่น หมายเลขกรมธรรม์หรือชื่อผู้ป่วย

มาดูตัวอย่างสรุปการจำหน่ายของผู้ป่วย เราใช้ Amazon Comprehend DetectPiiEntities API เพื่อตรวจจับเอนทิตี PII ภายในเอกสารและปกป้องความเป็นส่วนตัวของผู้ป่วยโดยแก้ไขเอนทิตีเหล่านี้:

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)

เราได้รับเอนทิตี PII ต่อไปนี้ในการตอบกลับจาก detect_pii_entities() เอพีไอ :

จากนั้น เราสามารถแก้ไขเอนทิตี PII ที่ตรวจพบจากเอกสารโดยใช้เรขาคณิตของกล่องขอบเขตของเอนทิตีจากเอกสาร เราใช้เครื่องมือตัวช่วยที่เรียกว่า amazon-textract-overlayer. สำหรับข้อมูลเพิ่มเติม โปรดดูที่ ตัวทับข้อความ. ภาพหน้าจอต่อไปนี้เปรียบเทียบเอกสารก่อนและหลังการแก้ไข

คล้ายกับ Amazon Comprehend DetectPiiEntities API เรายังสามารถใช้ DetectPHI API เพื่อตรวจจับข้อมูล PHI ในข้อความทางคลินิกที่กำลังตรวจสอบ สำหรับข้อมูลเพิ่มเติม โปรดดูที่ ตรวจจับพี

ขั้นตอนการทบทวนและตรวจสอบ

ในขั้นตอนการตรวจสอบและยืนยันเอกสาร ตอนนี้เราสามารถตรวจสอบได้ว่าแพ็คเกจการเคลมตรงตามข้อกำหนดของธุรกิจหรือไม่ เนื่องจากเรามีข้อมูลทั้งหมดที่รวบรวมจากเอกสารในแพ็คเกจจากขั้นตอนก่อนหน้า เราสามารถทำได้โดยแนะนำมนุษย์ในวงที่สามารถตรวจสอบและตรวจสอบฟิลด์ทั้งหมดหรือเพียงแค่กระบวนการอนุมัติอัตโนมัติสำหรับการเรียกร้องเงินดอลลาร์ต่ำก่อนที่จะส่งแพ็คเกจไปยังแอปพลิเคชันดาวน์สตรีม เราสามารถใช้ อเมซอน เสริม AI (Amazon A2I) เพื่อทำให้กระบวนการตรวจสอบโดยเจ้าหน้าที่สำหรับการประมวลผลการเคลมประกันเป็นไปโดยอัตโนมัติ

ตอนนี้เราได้ดึงข้อมูลที่จำเป็นทั้งหมดและทำให้เป็นมาตรฐานจากการประมวลผลการอ้างสิทธิ์โดยใช้บริการ AI สำหรับ IDP แล้ว เราสามารถขยายโซลูชันเพื่อผสานรวมกับบริการ AWS Analytics เช่น AWS Glue และ Amazon Redshift เพื่อแก้ไขกรณีการใช้งานเพิ่มเติมและให้การวิเคราะห์และการแสดงภาพเพิ่มเติม

ตรวจจับการเคลมประกันฉ้อฉล

ในโพสต์นี้ เราใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ซึ่งข้อมูลที่ดึงออกมาและประมวลผลถูกจัดเก็บไว้ใน Data Lake และใช้เพื่อตรวจจับการเรียกร้องค่าสินไหมทดแทนที่เป็นการฉ้อโกงโดยใช้ ML เราใช้ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) เพื่อจัดเก็บข้อมูลที่ประมวลผล เราก็สามารถใช้ AWS กาว or อเมซอน EMR เพื่อล้างข้อมูลและเพิ่มฟิลด์เพิ่มเติมเพื่อให้เป็นวัสดุสิ้นเปลืองสำหรับการรายงานและ ML หลังจากนั้นเราใช้ Amazon RedShift ML เพื่อสร้างแบบจำลอง ML การตรวจจับการฉ้อโกง สุดท้าย เราสร้างรายงานโดยใช้ อเมซอน QuickSight เพื่อรับข้อมูลเชิงลึกเกี่ยวกับข้อมูล

ตั้งค่าสคีมาภายนอกของ Amazon Redshift

เพื่อจุดประสงค์ของตัวอย่างนี้ เราได้สร้าง a ชุดข้อมูลตัวอย่าง จำลองเอาท์พุตของกระบวนการ ETL (แยก แปลง และโหลด) และใช้ AWS Glue Data Catalog เป็นแค็ตตาล็อกข้อมูลเมตา ขั้นแรก เราสร้างฐานข้อมูลชื่อ idp_demo ใน Data Catalog และสคีมาภายนอกใน Amazon Redshift ที่เรียกว่า idp_insurance_demo (ดูรหัสต่อไปนี้) เราใช้ an AWS Identity และการจัดการการเข้าถึง บทบาท (IAM) ในการให้สิทธิ์แก่คลัสเตอร์ Amazon Redshift เพื่อเข้าถึง Amazon S3 และ อเมซอน SageMaker. สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการตั้งค่าบทบาท IAM นี้โดยมีสิทธิ์น้อยที่สุด โปรดดูที่ จัดกลุ่มและกำหนดค่าการตั้งค่าสำหรับการดูแลระบบ Amazon Redshift ML.

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

สร้างตารางภายนอกของ Amazon Redshift

ขั้นตอนต่อไปคือการสร้างตารางภายนอกใน Amazon Redshift โดยอ้างอิงตำแหน่ง S3 ที่ไฟล์นั้นตั้งอยู่ ในกรณีนี้ ไฟล์ของเราเป็นไฟล์ข้อความที่คั่นด้วยเครื่องหมายจุลภาค เรายังต้องการข้ามแถวส่วนหัวจากไฟล์ ซึ่งสามารถกำหนดค่าได้ในส่วนคุณสมบัติของตาราง ดูรหัสต่อไปนี้:

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

สร้างการฝึกอบรมและทดสอบชุดข้อมูล

หลังจากที่เราสร้างตารางภายนอกแล้ว เราจะเตรียมชุดข้อมูลสำหรับ ML โดยแบ่งเป็นชุดการฝึกและชุดทดสอบ เราสร้างตารางภายนอกใหม่ที่เรียกว่า claim_trainซึ่งประกอบด้วยระเบียนทั้งหมดที่มี ID <= 85000 จากตารางการอ้างสิทธิ์ นี่คือชุดการฝึกที่เราฝึกโมเดล ML ของเรา

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

เราสร้างตารางภายนอกอื่นที่เรียกว่า claim_test ที่ประกอบด้วยระเบียนทั้งหมดที่มี ID >85000 เพื่อเป็นชุดทดสอบที่เราทดสอบแบบจำลอง ML บน:

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

สร้างโมเดล ML ด้วย Amazon Redshift ML

ตอนนี้เราสร้างแบบจำลองโดยใช้ สร้างแบบจำลอง คำสั่ง (ดูรหัสต่อไปนี้) เราเลือกคอลัมน์ที่เกี่ยวข้องจาก claims_train ตารางที่สามารถระบุธุรกรรมที่เป็นการฉ้อโกง เป้าหมายของโมเดลนี้คือการคาดการณ์มูลค่าของ fraud คอลัมน์; ดังนั้น, fraud ถูกเพิ่มเป็นเป้าหมายการทำนาย หลังจากฝึกโมเดลแล้ว จะสร้างฟังก์ชันที่ชื่อว่า insurance_fraud_model. ฟังก์ชันนี้ใช้สำหรับการอนุมานขณะรันคำสั่ง SQL เพื่อทำนายค่าของ fraud คอลัมน์สำหรับบันทึกใหม่

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

ประเมินเมตริกโมเดล ML

หลังจากที่เราสร้างแบบจำลองแล้ว เราสามารถเรียกใช้แบบสอบถามเพื่อตรวจสอบความถูกต้องของแบบจำลองได้ เราใช้ insurance_fraud_model ฟังก์ชันทำนายค่าของ fraud คอลัมน์สำหรับบันทึกใหม่ เรียกใช้แบบสอบถามต่อไปนี้บน claims_test ตารางเพื่อสร้างเมทริกซ์ความสับสน:

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;

ตรวจจับการฉ้อโกงโดยใช้โมเดล ML

หลังจากที่เราสร้างโมเดลใหม่ เมื่อมีการแทรกข้อมูลการอ้างสิทธิ์ใหม่ลงในคลังข้อมูลหรือ Data Lake เราก็สามารถใช้ insurance_fraud_model ฟังก์ชันคำนวณธุรกรรมที่เป็นการฉ้อโกง เราทำสิ่งนี้โดยการโหลดข้อมูลใหม่ลงในตารางชั่วคราวก่อน จากนั้นเราใช้ insurance_fraud_model ฟังก์ชันคำนวณค่า fraud แฟล็กสำหรับธุรกรรมใหม่แต่ละรายการและแทรกข้อมูลพร้อมกับแฟล็กลงในตารางสุดท้าย ซึ่งในกรณีนี้คือ claims ตาราง

เห็นภาพข้อมูลการเรียกร้อง

เมื่อข้อมูลพร้อมใช้งานใน Amazon Redshift เราสามารถสร้างการแสดงภาพโดยใช้ QuickSight จากนั้น เราสามารถแบ่งปันแดชบอร์ด QuickSight กับผู้ใช้ทางธุรกิจและนักวิเคราะห์ได้ ในการสร้างแดชบอร์ด QuickSight คุณต้องสร้างชุดข้อมูล Amazon Redshift ใน QuickSight ก่อน สำหรับคำแนะนำ โปรดดูที่ การสร้างชุดข้อมูลจากฐานข้อมูล.

หลังจากที่คุณสร้างชุดข้อมูล คุณสามารถสร้างการวิเคราะห์ใหม่ใน QuickSight โดยใช้ชุดข้อมูล ต่อไปนี้คือรายงานตัวอย่างบางส่วนที่เราสร้างขึ้น:

• จำนวนการเรียกร้องทั้งหมดตามรัฐ จัดกลุ่มโดย fraud สนาม – แผนภูมินี้แสดงสัดส่วนของธุรกรรมที่เป็นการฉ้อโกงเมื่อเปรียบเทียบกับจำนวนธุรกรรมทั้งหมดในรัฐหนึ่งๆ
• ผลรวมของมูลค่าเงินดอลลาร์ทั้งหมดของการเรียกร้อง จัดกลุ่มโดย fraud สนาม – แผนภูมินี้แสดงให้เราเห็นสัดส่วนของจำนวนเงินดอลลาร์ของการทำธุรกรรมที่เป็นการฉ้อโกง เมื่อเทียบกับจำนวนเงินรวมของการทำธุรกรรมในรัฐหนึ่งๆ
• จำนวนธุรกรรมทั้งหมดต่อบริษัทประกันภัย จัดกลุ่มโดย fraud สนาม – แผนภูมินี้แสดงจำนวนการเรียกร้องค่าสินไหมทดแทนสำหรับบริษัทประกันภัยแต่ละแห่ง และจำนวนที่เป็นการฉ้อโกง

• ผลรวมของธุรกรรมฉ้อโกงตามรัฐที่แสดงบนแผนที่ของสหรัฐอเมริกา – แผนภูมินี้แสดงธุรกรรมที่เป็นการฉ้อโกงและแสดงค่าใช้จ่ายทั้งหมดสำหรับธุรกรรมเหล่านั้นตามรัฐบนแผนที่ สีฟ้าที่เข้มกว่าหมายถึงประจุรวมที่สูงขึ้น เราสามารถวิเคราะห์เพิ่มเติมตามเมืองภายในรัฐนั้นและรหัสไปรษณีย์กับเมืองเพื่อให้เข้าใจถึงแนวโน้มได้ดีขึ้น

ทำความสะอาด

เพื่อป้องกันไม่ให้มีการเรียกเก็บเงินกับบัญชี AWS ของคุณในอนาคต ให้ลบทรัพยากรที่คุณจัดเตรียมไว้ในการตั้งค่าโดยทำตามคำแนะนำใน ส่วนการล้างข้อมูล ใน repo ของเรา

สรุป

ในซีรีส์สองส่วนนี้ เราได้เห็นวิธีสร้างไปป์ไลน์ IDP ตั้งแต่ต้นทางถึงปลายทางโดยมีประสบการณ์ ML เพียงเล็กน้อยหรือไม่มีเลย เราได้สำรวจกรณีการใช้งานการประมวลผลการเคลมในอุตสาหกรรมประกันภัยและวิธีที่ IDP สามารถช่วยทำให้กรณีการใช้งานนี้เป็นแบบอัตโนมัติโดยใช้บริการต่างๆ เช่น Amazon Text, Amazon Comprehend, Amazon Comprehend Medical และ Amazon A2I ในส่วนที่ 1 เราสาธิตวิธีใช้บริการ AWS AI สำหรับการดึงเอกสาร ในส่วนที่ 2 เราได้ขยายขั้นตอนการสกัดและดำเนินการปรับปรุงข้อมูล สุดท้าย เราได้ขยายข้อมูลที่มีโครงสร้างที่ดึงมาจาก IDP สำหรับการวิเคราะห์เพิ่มเติม และสร้างการแสดงภาพเพื่อตรวจจับการอ้างสิทธิ์ที่เป็นการฉ้อโกงโดยใช้บริการ AWS Analytics

เราขอแนะนำให้ตรวจสอบส่วนความปลอดภัยของ Amazon Text, เข้าใจ Amazonและ อเมซอน A2I เอกสารและปฏิบัติตามแนวทางที่ให้ไว้ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับราคาของโซลูชัน ให้ตรวจสอบรายละเอียดราคาของ Amazon Text, เข้าใจ Amazonและ อเมซอน A2I.

เกี่ยวกับผู้เขียน

ชินมยีระเนะ เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญ AI/ML ที่ Amazon Web Services เธอหลงใหลเกี่ยวกับคณิตศาสตร์ประยุกต์และการเรียนรู้ของเครื่อง เธอมุ่งเน้นที่การออกแบบโซลูชันการประมวลผลเอกสารอัจฉริยะสำหรับลูกค้า AWS นอกงาน เธอชอบเต้นซัลซ่าและบาคาต้า

อุทัย นารายณ์นันท์ เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญด้านการวิเคราะห์ที่ AWS เขาสนุกกับการช่วยลูกค้าค้นหาโซลูชันที่เป็นนวัตกรรมเพื่อรับมือกับความท้าทายทางธุรกิจที่ซับซ้อน จุดสนใจหลักของเขาคือการวิเคราะห์ข้อมูล ระบบข้อมูลขนาดใหญ่ และการเรียนรู้ของเครื่อง ในเวลาว่าง เขาชอบเล่นกีฬา ดูรายการทีวีอย่างเมามาย และเดินทาง

โซนาลี ซาฮู เป็นผู้นำทีมสถาปนิกโซลูชัน AI/ML Solutions ของการประมวลผลเอกสารอัจฉริยะที่ Amazon Web Services เธอเป็นคนที่หลงใหลในเทคโนโลยีและชอบที่จะทำงานร่วมกับลูกค้าในการแก้ปัญหาที่ซับซ้อนโดยใช้นวัตกรรม จุดสนใจหลักของเธอคือปัญญาประดิษฐ์และการเรียนรู้ของเครื่องสำหรับการประมวลผลเอกสารอัจฉริยะ